Hi I just wanted to know how can I visualize and edit an existing IDF file in the NEW version of honeybee
The HB Load gbXML does double-duty in that it also allows you to import IDF files. So just connect the IDF file path to that component and you should be able to load it as a Honeybee model.
1 Like
Hi @chris,
Get to the point that i need to load and idf file (V9.3 from the E+ examples folder). Iâm trying the HB > Load gbXML OSM IDF component but i get the following error:
Runtime error (FileNotFoundException): Could not find file âC:\Users\ayezi\simulation\airflownetwork3zvent.hbjsonâ.
Traceback:
line 116, in script
It is looking for a hbjson file ⌠which doesnât exist of course.
Is this a bug in the component or idf files alone can not be loaded?
Thanks,
-A.
Hey @AbrahamYezioro and @chris
Iâve got the same error while trying to import a idf.
The legacy component seemed to work properly.
I was wondering if maybe it has to do with the energy plus version since I run it directly in energy plus and not in honeybee.
I donât think so.
In any case iâ still investigating. I see that the try to perform the import/load happens at:
C:\Users\USERNAME\simulation\temp_translate
Some files and folders are created there but the job fails. There is a log file in the folder run, which is inside the previous mentioned.
run.log (7.9 KB)
Hoping this can help to debug.
-A.
Hey @AbrahamYezioro ,
Weâve been making some improvements to the IDF import but, from your log file, it seems like the issue is more basic than that since the file path the the IDF is reported as an empty string. Can you try updating your IDF from version 9.3 to version 9.6 using the IDF Version Updater?
Or could you try importing it in the OpenStudio App to see if that is successful? Then you can save out an updated IDF.
If this does not fix it, can you upload the IDF so that I can see if thereâs a a bug I should fix?
1 Like
Hi @chris,
The OSApp doesnât like the 9.3 idf and asks for 9.6 ⌠
This is one of the files iâm trying (Iâm checking the AFN examples from E+).
Thanks,
-A.
AirflowNetwork_Multizone_HorizontalOpening.idf (102.9 KB)
Thanks, @AbrahamYezioro . I was able to find the real error by digging through the out.osw from the translation process:
[openstudio.energyplus.ReverseTranslator] <1> Check that IDF is of correct version and that all fields are valid against Energy+.idd.
[openstudio.energyplus.ReverseTranslator] <1> The collection is INVALID at strictness level âDraftâ, because of the errors:
Field level data error of type DataType .
Error is in an object of type âBuildingSurface:Detailedâ, named âSurface_1â, in field 7.
Additional information about the error type: field-level data is of an incorrect type.
Field level data error of type NumericBound .
Error is in an object of type âBuildingSurface:Detailedâ, named âSurface_1â, in field 9.
Additional information about the error type: numeric data violates a min or max bound.
In any event, I have no issues loading the EnergyPlus 9.6 version of this sample file as long as I use the latest development version of the LBT plugin, which has a fix for one of the schedule type limits in the IDF.
AirflowNetwork_Multizone_HorizontalOpening.idf (104.8 KB)
Iâll see if I can implement some better reporting of the OpenStudio stdout for cases like this where the difference in version makes the IDF un-import-able.
Also, on a side note, none of the AFN properties are imported by OpenStudio (and for that reason, Honeybee). So just bear that in mind when you are importing these samples. You can see a full table of properties that are supported in the import here.
1 Like
FIY, I also improved the reporting of error messages from the OpenStudio translators whenever the import process fails:
4 posts were split to a new topic: How to Open the DoE Commercial Reference Buildings in Ladybug Tools
Kia ora tatou
This issue of importing idf files remains contentious. It is after all the lingua franca of energy modelling.
I have always been suspicious of the idea of Open Studio - no matter its robust data structures - limiting what it deigns to build into its data systems.
I have a recent example where to work with an external body who use the Design Builder interface to EnergyPlus: .idf is what they can export so we can understand their model and perhaps modify it in LBT.
However, we get the classic error message: on running the neat little HB import idf operator:
[openstudio.energyplus.ReverseTranslator] <1> Idf file at path =âF:/Block3Geometry (1).idfâ is not valid to draft strictness.
[openstudio.energyplus.ReverseTranslator] <1> Check that IDF is of correct version and that all fields are valid against Energy+.idd.
[openstudio.energyplus.ReverseTranslator] <1> The collection is INVALID at strictness level âDraftâ, because of the errors:
Field level data error of type NumericBound .
Error is in an object of type âAirflowNetwork:MultiZone:Component:DetailedOpeningâ, named â314:Hall_Partition_2_0_0_0_0_0_Holeâ, in field 17.
Additional information about the error type: numeric data violates a min or max bound.
```
Cannot load IDF file at ââ
- C:/Program Files/ladybug_tools/resources/measures/honeybee_openstudio_gem/lib/from_openstudio/model.rb:110:in `translate_from_idf_fileâ*
- C:/Program Files/ladybug_tools/resources/measures/honeybee_openstudio_gem/lib/measures/from_idf_model/measure.rb:91:in `runâ*
- :/ruby/2.7.0/gems/openstudio-workflow-2.3.1/lib/openstudio/workflow/util/measure.rb:517:in `apply_measureâ*
- :/ruby/2.7.0/gems/openstudio-workflow-2.3.1/lib/openstudio/workflow/util/measure.rb:114:in `block in apply_measuresâ*
- :/ruby/2.7.0/gems/openstudio-workflow-2.3.1/lib/openstudio/workflow/util/measure.rb:67:in `each_indexâ*
- :/ruby/2.7.0/gems/openstudio-workflow-2.3.1/lib/openstudio/workflow/util/measure.rb:67:in `apply_measuresâ*
- :/ruby/2.7.0/gems/openstudio-workflow-2.3.1/lib/openstudio/workflow/jobs/run_os_measures.rb:70:in `performâ*
- :/ruby/2.7.0/gems/openstudio-workflow-2.3.1/lib/openstudio/workflow/run.rb:291:in `stepâ*
- :/ruby/2.7.0/gems/openstudio-workflow-2.3.1/lib/openstudio/workflow/run.rb:233:in `runâ*
- :/openstudio_cli.rb:1187:in `executeâ*
- :/openstudio_cli.rb:817:in `executeâ*
- :/openstudio_cli.rb:1984:in `'*
- eval:188:in `evalâ*
- eval:188:in `require_embedded_absoluteâ*
- eval:173:in `block in require_embeddedâ*
- eval:167:in `eachâ*
- eval:167:in `require_embeddedâ*
- eval:126:in `requireâ*
- eval:3:in `'*
Runtime error (PythonException): Failed to run OpenStudio CLI:
Cannot load IDF file at ââ
Traceback:
- line 160, in script*
Having toyed with various interpretations and edits focused on object 17, I looked a little further and found this post, and the subsequent post about importing the E+ files for the DOE Commercial Reference Buildings. These suggest that importing E+ format IDF files is likely always to be fraught because of what appears to be a stringency in version-to-version compatibility of file structures. Given that E+, when installed in its raw form, comes with a huge inventory of exemplar files this information is disappointing. Referring to these "how-to" models has always been inspirational in the past.
This is made worse by the limits of the .osm Open Studio format. For example, the file we wish to import and examine uses the AirFlow Network to model real, naturally-ventilated apartments. But, as @chris has so clearly documented, Open Studio does not handle this information well:
https://discourse.ladybug.tools/t/how-to-open-the-doe-commercial-reference-buildings-in-ladybug-tools/22978?u=michaeldonn
from: https://github.com/pollination/pollination-docs/blob/master/rhino-plugin/interoperability/rhino-import-export.md
Any thoughts as to how to translate from Design Builder naturally ventilated model to LBT and avoiding the error, but at least preserving the geometry would be gratefully received.how do i do this?, i donât understand is it just in copy paste?