Comparing two different skin in terms of energy efficiency

[AbrahamYezioro]

@chris

Your diagnosis of the IDF Editor issue sounds likely

Hi @chris,
Indeed there is an issue to display the idf in the idfeditor when the number of fields exceed the Energy+idd definitions. To allow the display the IDD file needs to be edited adding the amount of fields you need/want. For the above case there is a need more than 200 of them, so i’ll let it go. Fortunately the simulation does run correctly thanks to the addition of the \extensible parameter in the IDD. Can’t track when it was implemented but probably somewhere around E+9.0. Before that also the simulation failed.

@chris

I was able to figure out a way to get Honeybee’s mesh-based visualizations to display the holes correctly

This is great! It is always to have WYSIWYG but in this case, even better, WYGIWYS.

I guess the topc can be declared closed officially … :-).
@SimaKhayami94 , do you agree?

Thanks again @chris,
-A.

[AbrahamYezioro]

Maybe one more thing … (sorry about that).

@chris

I was able to figure out a way to get Honeybee’s mesh-based visualizations to display the holes correctly

When dumping the model into the DumpGBXML and loading again with the LoadGBXML the shades are flat (a mesh of 2 faces). Is it possible to do the trick also for the dumping model?

-A.

[chris]

Ah, thank you for catching that, @AbrahamYezioro . You are right that we should be converting the objects with holes to a single list of vertices before exporting to gbXML. I just pushed a fix for that case:

fix(serialize): Ensure auto-calculated properties make it to gbXML

… and you now get the holes being exported correctly to gbXML:

That should take care of all of the places where the fix was needed. Thanks again, @AbrahamYezioro !

[AbrahamYezioro]

Thank you @chris!
-A.

[SimaKhayami94]

Hi @AbrahamYezioro
Yes I think so. Thanks to your accurate detection the problem solved and analysis ran correctly.