Specify the specific heat of a material with Revit 2017 Python API - revit-api

With Revit 2017 Python API, I am trying to create new materials, and then assembling some of these to create new type of walls.
It goes pretty well for all properties, except for the specific heat!
Basically, what I do is:
create a thermalAsset:
themalA = ThermalAsset('Test', ThermalMaterialType.Solid)
Set the different thermal properties for that thermal asset (dummy values):
thermalA.ThermalConductivity = 0.01
thermalA.SpecificHeat = 0.001
thermalA.Density = 1000.0
Then I create a PropertySetElement with that thermal asset:
pse = PropertySetElement.Create(doc, thermalA)
Then I assign it to my material (that I previously created):
mat.SetMaterialAspectByPropertySet(MaterialAspect.Thermal, pse)
Afetr that, I take a look in my materials list in Revit, and look at the thermal properties. Everything seems ok, except the Specific Heat, which remains at 0.0239 btu/(lb. F), whatever the value I input when I assign the specific heat. Density is ok, thermal conductivity is ok, but not specific heat.
I got no error message.
What am I missing?
Thanks a lot for any help.
Arnaud.

Is the value you specify in the expected unit? Feet per Kelvin, squared-second. Cf., http://thebuildingcoder.typepad.com/blog/2013/04/whats-new-in-the-revit-2014-api.html > ThermalAsset.SpecificHeat.
I submitted this to the development team for further analysis as issue REVIT-111206 [API: setting ThermalAsset SpecificHeat fails]. Can you please provide a full reproducible case for them to test, e.g., a minimal RVT model with an embedded macro to run, cf., http://thebuildingcoder.typepad.com/blog/about-the-author.html#1b? Thank you!

Related

Table values moved after being added to old QGIS version: behaves normally on current version

I am teaching a man the basics of QGis for a project he needs to do at his work. He has very little computer knowledge and would like to standardise the work as much as possible (specific workarounds would complicate it too much for him). His QGis version is 3.16 "Hannover" and as this is a work laptop he does not have permission to download a newer version.
We have been having problem with one specific table. The first few rows are below, written exactly as they are originally.
Baum-Nr. Baumart BHD Alter Y X Biotopbaum Klassifizierung Bemerkungen
1 Buche 86 120 49.1356 11.0488 A Altbaum Freistellen !!!
2 Kiefer 45 100 49.13561 11.04883 Hlb,Bs,Th Höhlenbaum
3 Kiefer 32 100 49.13571 11.04579 Hlb,Sw,Th Höhlenbaum
4 Kiefer 74 120 49.13513 11.0495 A Altbaum
After adding it from Excel to QGis through "add vector layer", the header "Klassifizierung" becomes one of the coordinates and I believe one of the columns are switched (unfortunately, I can't remember specifics. This is a small side job and I haven't had time to look into it for days. I should have taken a photo, but this isn't possible anymore). We have attempted to copy the column into a new Excel document and transferring it to QGis again, and this time the headers were shoved one cell to the right such that "Y" was placed over "X" and "Biotopbaum" over "Klassifizierung", for example.
I could not find a way to fix the import problem in his laptop. He e-mailed me the problematic table and I opened it successfully in my QGis 3.26 "Buenos Aires".
I believe this may be a problem with his QGis version, but it is curious that we only encountered it with this one table. All other tables we have worked with have the same headers and the same kind of data on their respective rows.
Is this a known problem, or have other people faced similar situations? Could someone explain what could be causing it? Would there be a way to fix it such that we can successfully import the table without having to edit it in QGis? This is not a solution the man would accept.
Thank you in advance.
Remove the commas in the Biotopbaum field or replace them with a less common delimiter. In fact, remove all punctionation (e.g., Baum-Nr. >> remove the period ".").
Also save the table into a csv format and try to import.

Take mean of feature set using openSMILE audio feature extractor

My problem is taking mean of all features from different frames in one sample .wav file. I am trying cFunctionals in "chroma_fft.conf" file which belongs to latest OpenEar framework. For best explanation, i am writing these essential codes which i wrote in "chroma_fft.conf" and it is shown below;
[componentInstances:cComponentManager]
instance[functL1].type = cFunctionals
[functL1:cFunctional]
reader.dmLevel = chroma
writer.dmLevel = func
frameMode = full
frameSize=0
frameStep=0
functionalsEnabled = Means
Means.amean = 1
[csvSink:cCsvSink]
reader.dmLevel = func
..NOT-IMPORTANT......
..NOT-IMPORTANT......
However, when i run from command prompt in windows, i got error;
"(ERROR) [1] in configManager : base instance of field 'functL1.reader.dmInstance' not found in configmanager!"
Very similar code is running succesfully from "emo_large.conf" but this code got error. If any body knows how to use OpenSmile audio feature extractor, can give advice or answer why it has error and how to use "cFunctionals" properly to take mean, variance, moments etc. of large feature sets.
Thanks!
In this case you have a typo in
[functL1:cFunctional]
which should be
[functL1:cFunctionals]
I admit the error message
"(ERROR) [1] in configManager : base instance of field 'functL1.reader.dmInstance' not found in configmanager!"
is not intutive, but it refers to the fact that openSMILE expects a configuration section functL1 of type cFunctionals in the config to read the mandatory (sub-)field functL1.reader.dmInstance, which it then cannot find, because the section (due to the typo) is not defined.
Cheers,
Florian

2 Sequential Transactions, setting Detail Number (Revit API / Python)

Currently, I made a tool to rename view numbers (“Detail Number”) on a sheet based on their location on the sheet. Where this is breaking is the transactions. Im trying to do two transactions sequentially in Revit Python Shell. I also did this originally in dynamo, and that had a similar fail , so I know its something to do with transactions.
Transaction #1: Add a suffix (“-x”) to each detail number to ensure the new numbers won’t conflict (1 will be 1-x, 4 will be 4-x, etc)
Transaction #2: Change detail numbers with calculated new number based on viewport location (1-x will be 3, 4-x will be 2, etc)
Better visual explanation here: https://www.docdroid.net/EP1K9Di/161115-viewport-diagram-.pdf.html
Py File here: http://pastebin.com/7PyWA0gV
Attached is the python file, but essentially what im trying to do is:
# <---- Make unique numbers
t = Transaction(doc, 'Rename Detail Numbers')
t.Start()
for i, viewport in enumerate(viewports):
setParam(viewport, "Detail Number",getParam(viewport,"Detail Number")+"x")
t.Commit()
# <---- Do the thang
t2 = Transaction(doc, 'Rename Detail Numbers')
t2.Start()
for i, viewport in enumerate(viewports):
setParam(viewport, "Detail Number",detailViewNumberData[i])
t2.Commit()
Attached is py file
As I explained in my answer to your comment in the Revit API discussion forum, the behaviour you describe may well be caused by a need to regenerate between the transactions. The first modification does something, and the model needs to be regenerated before the modifications take full effect and are reflected in the parameter values that you query in the second transaction. You are accessing stale data. The Building Coder provides all the nitty gritty details and numerous examples on the need to regenerate.
Summary of this entire thread including both problems addressed:
http://thebuildingcoder.typepad.com/blog/2016/12/need-for-regen-and-parameter-display-name-confusion.html
So this issue actually had nothing to do with transactions or doc regeneration. I discovered (with some help :) ), that the problem lied in how I was setting/getting the parameter. "Detail Number", like a lot of parameters, has duplicate versions that share the same descriptive param Name in a viewport element.
Apparently the reason for this might be legacy issues, though im not sure. Thus, when I was trying to get/set detail number, it was somehow grabbing the incorrect read-only parameter occasionally, one that is called "VIEWER_DETAIL_NUMBER" as its builtIn Enumeration. The correct one is called "VIEWPORT_DETAIL_NUMBER". This was happening because I was trying to get the param just by passing the descriptive param name "Detail Number".Revising how i get/set parameters via builtIn enum resolved this issue. See images below.
Please see pdf for visual explanation: https://www.docdroid.net/WbAHBGj/161206-detail-number.pdf.html

Error series vanishes on resizing window

Following plot has a error series Series2 which is not displayed on this chart, but legends says about its existence. This series needs to be displayed with minimum y value as infinity. But, Tee chart doesn't have any provision to specify -Infinity directly. So, we defined a huge negative number instead; which is significantly larger than the y axis to give an appearance of -Infinity to the user. But, if the chart area becomes too small compared to this huge negative number, the series (here series2) vanishes entirely.
Here is the series data used -
Series2 Points:
X-------------------->>Bar-------------------->>Std. Error
1432 --------->> -50.19380462 ----------->> 50.20619538
1797 ---------->> 50.19380462 ----------->> 50.20619538
2164 ---------->> -50.19380462 ----------->> 50.20619538
2529 --------->> -50.19380462 ----------->> 50.20619538
Can anyone please help to resolve this issue?
Thanking you.
The next release of TeeChart for .NET includes support for extended Axis ranges, from Double.MinValue to Double.MaxValue, and goes some way further to handle infinite value issues. That doesn't say for sure that it will resolve the issue you describe here. If you are able to send Steema Support a sample project that shows the issue we can test it with the new release.

Resolving an error in using the Crf++ toolkit

To all those who have had experience with using the crf++ toolkit (refer: http://crfpp.sourceforge.net/)
Please find the error message which pops up on trying to execute the CRF++ training program:
CRF++: Yet Another CRF Tool Kit
Copyright (C) 2005-2009 Taku Kudo, All rights reserved.
encoder.cpp(280) [feature_index.open(templfile, trainfile)] feature_index.cpp(86) [max_size == size] inconsistent column size: 21 20 train.data
I'm not sure how to interpret the error message.
There are 20 features in my training file and the 21st token is the class value.
I have created the Crf++ template file as per the instructions on the site.
It looks like a training data format issue, make sure the number of columns are consistent across all sentences.
I got this error today, and found that crf++ toolkit just set tab character(\t) to default column separator whereas my train data file using one white space lead to error.
Some points to check:
1. Check if you have a new line after each sentence
2. Check if your columnar values does not contain any sp
Error suggests that your number of columns in rows are not same among all. Your maximum number of columns are 21 and that should be consistent through out the training file but crf_learn finds it 20 somewhere in your train.data training file. So locate such row and remove/repair it.

Resources