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


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
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.

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:

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.

1 Like


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.

1 Like

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.