In between blinds translation error with HBModelToOSM v1.6.1

Hi everyone,

I get an error when trying to simulate my model with OpenStudio/EnergyPlus.
You can see below the corresponding error :

undefined method to_openstudio' for nil:NilClass C:/Program Files/ladybug_tools/resources/measures/honeybee_openstudio_gem/lib/to_openstudio/construction/windowshade.rb:194:in split_gas_gap’
C:/Program Files/ladybug_tools/resources/measures/honeybee_openstudio_gem/lib/to_openstudio/construction/windowshade.rb:107:in to_openstudio' C:/Program Files/ladybug_tools/resources/measures/honeybee_openstudio_gem/lib/to_openstudio/model.rb:296:in block in create_constructions’
C:/Program Files/ladybug_tools/resources/measures/honeybee_openstudio_gem/lib/to_openstudio/model.rb:264:in each' C:/Program Files/ladybug_tools/resources/measures/honeybee_openstudio_gem/lib/to_openstudio/model.rb:264:in create_constructions’
C:/Program Files/ladybug_tools/resources/measures/honeybee_openstudio_gem/lib/to_openstudio/model.rb:154:in create_openstudio_objects' C:/Program Files/ladybug_tools/resources/measures/honeybee_openstudio_gem/lib/to_openstudio/model.rb:93:in to_openstudio_model’
C:/Program Files/ladybug_tools/resources/measures/honeybee_openstudio_gem/lib/measures/from_honeybee_model/measure.rb:115: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:1174:in execute' :/openstudio_cli.rb:804:in execute’
:/openstudio_cli.rb:1973:in <main>' 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:
undefined method `to_openstudio’ for nil:NilClass

The bug occurs precisely when I change the shading location (HB Window Construction Shade) from “Exterior” to “Between”. The model is running well when blinds are set as “Exterior” or “Interior” but it fails when set as “Between”.

Could you help me solving this bug ?

Regards,

Does anyone have a clue ?
Are “in between” located blinds working well for you ?
You can find attached the geasshopper definition if needed.
EnergySimulation_BetweenShades.gh (87.6 KB)

Any help would be very appreciated :slight_smile:

Regards,

Hi Aymeric
I’m getting the same issue when I try to run a ‘between’ shade material.
I found a related issue that the HB Shade Material component dist_to_glass variable is overridden by the adjacent open_mult variable. But when I set all of them to something feasible (0.002m) it still doesn’t work. I’m going to try to play around with the idf file to see.
I’ll let you know if I found a fix.

Thanks Angela,
I ended up writing the .idf with interior blinds with honeybee and editing the .idf file to replace with correct settings for “in between” blinds. If you find a better way to solve the issue, I will be interrested !
Regards,

1 Like

Hi Aymeric & Angela
I’ve got a similar problem.
I took your suggestion Aymeric and got it to work by changing the idf. But I’d really like to have it parametric, so hopefully this component is fixed soon. @chris the text workaround is pretty straight forward, so I expect the error is a basic/obvious one. The component appears to be correctly changing the thickness of the split air gaps to account for the thickness of the shade itself. Maybe its just not correctly changing the shading type to “BetweenGlassShade” as per the E+ IO p374? i.e. maybe the user input should be “BetweenGlass” rather than just “Between”

1 Like

Thank you all and sorry for the late response. I just put together a fix for this issue so that you don’t need to do a complex workaround.

I will merge is shortly and you should be able to get the fix on your end with the LB Versioner in another day or so.

Thanks again for bringing this to my attention.

2 Likes

Hi Chris,
Thank for for implementing this. I believe it is working, however I have hit another associated error that is stopping my construction from working.

  1. ** Severe ** GetHTSubSurfaceData: The gap width(s) for the unshaded window construction SHADEDWINDOWCONSTRUCTION_6B99DDBB

Scrolling through the attached.idf, I see two new air gaps have been generated: “AirGap20.006” and “AirGap2_Split0.005”. The latter is correctly ‘split’ to 5mm, which accounts for the 2mm blind thickness I have defined (AirGap2 is the air gap for the ‘base’ construction without a blind, which is 12mm wide). However, it is the former air gap that has been applied to the relevant construction. See below.

Construction,
Glz3, !- Name
outer, !- Layer 1
AirGap1, !- Layer 2
mid, !- Layer 3
AirGap20.006, !- Layer 4 <<< should be “AirGap2_Split0.005”
CCFBlind, !- Layer 5
AirGap20.006, !- Layer 6 <<< should be “AirGap2_Split0.005”
inner; !- Layer 7

Construction,
ShadedWindowConstruction_6b99ddbb, !- Name
outer, !- Layer 1
AirGap1, !- Layer 2
mid, !- Layer 3
AirGap2, !- Layer 4
inner; !- Layer 5

Regards

Daniel
in.idf (161.6 KB)

Hi @Daniel_Andj ,

I’m sorry for the very late response but I have not been able to recreate anything that is like what is in your IDF using the latest LBT plugin. Are you sure that you ran the LB Versioner to get the latest development version? If so, can you upload a Grasshopper file that recreates the IDF that you have there?

Ah, I take it back, @Daniel_Andj . It took a little effort but I was able to recreate it. It was a rounding error on my part and I just fixed it as part of this PR:

The fix should be available via the LB Versioner in an hour or so.

Thanks for bringing this to my attention!