HB Model to OSM in Rhino.Inside Revit Error - Simulation does not run

soup · November 15, 2022, 8:46pm

Hi,

When running a HB Model to OSM node in Rhino.Inside from Revit I get the following error:

Runtime error (IndexOutOfRangeException): index out of range: 0
Traceback:
line 224, in script

The node stops after a message of: ‘Done with Model Translation!’ in the cmd window.

This only happens when running from Rhino.Inside, when the exact same geometry and graph is run from Rhino standalone, the OSM node runs and outputs results.

What I have tried:
When installing different versions of IronPython to the system I get different errors from this node.
When any version of IronPython other than 2.7.12 is installed as the system IronPython install, I get an error of _sqlite3 not found. The Model to OSM node does however run in this case. Again this error regarding _sqlite3 occurs from Rhino.Inside and not rhino Standalone, which works with any version of IronPython installed. _sqlite3 can also not be found when no version of IronPython is installed to the system and running from Rhino.Inside.

I have installed Honeybee Tools from within grasshopper running from Rhino.Inside, I have run the ‘set_python_path’ file from ‘C:\Users\User\ladybug_tools’.

Is there anything I am missing? Is there any way to force Revit to use the exact configuration as that which Rhino uses?

Thanks in advance.

chris · November 17, 2022, 12:07am

Hm. It seems like you’re not using the same Iron python that ships natively with Rhino and I imagine that matching the two versions could solve it.

If not and this is actually the line that is failing for you, I have a suggestion of how you could edit this line of code to just hack it and get it to work for now:

github.com

ladybug-tools/honeybee-grasshopper-energy/blob/master/honeybee_grasshopper_energy/src/HB Model to OSM.py#L224

    
      
              strings_to_inject=str_inject)
          
          
# run the measure to translate the model JSON to an openstudio measure
          silent = True if run_ == 3 else False
          if run_ > 0 and not no_report_meas:  # everything must run with OS CLI
              osm, idf = run_osw(osw, measures_only=False, silent=silent)
              sql, zsz, rdd, html, err = output_energyplus_files(os.path.dirname(idf))
          elif run_ > 0:  # no reporting measure; simulate separately from measure application
              osm, idf = run_osw(osw, silent=silent)
              # process the additional strings
              if add_str_ != [] and add_str_[0] is not None and idf is not None:
                  add_str = '\n'.join(add_str_)
                  with open(idf, "a") as idf_file:
                      idf_file.write(add_str)
              if idf is None:  # measures failed to run correctly; parse out.osw
                  log_osw = OSW(os.path.join(directory, 'out.osw'))
                  errors = []
                  for error, tb in zip(log_osw.errors, log_osw.error_tracebacks):
                      if 'Cannot create a surface' in error:
                          error = 'Your Rhino Model units system is: {}. ' \
                              'Is this correct?\n{}'.format(units_system(), error)

Just change that if add_str_ != [] to if len(add_str_) != 0.

If that solves it, then I’ll probably change that line of the component.

soup · November 17, 2022, 6:33am

Chris,

Thanks for the reply, I’ve implemented your solution and it is working now.
I’ve tested the change both from Rhino.Inside, and Rhino standalone, both work with the change.

In the meantime I used the workaround of simply commenting out the offending code as I was not using the add_str_ input in the project.

thanks again.

chris · November 18, 2022, 1:27pm

Thanks for testing this, @soup .

I made the change official in the latest development version of the plugin:

I can see why my previous check was not the best use of Python since it meant additional strings always had to be a Python list and not some other iterable like a tuple or (likely in your case) a .NET array. In any event, thank you for bringing this to our attention.