Re-run osm component - old error: solution exception:expected path

I have tried a trial run of this one component, before linking it to the energy balance Hydra example.

With simple and complex versions of the path length, and with version 2.7 and now 2.8 of Open Studio installed, and with the text panel with the file names fed directly to the re-run OS widget or via a path I get this “expected path, got scr” message. I have run the update HB and LB widgets while setting up the hydra example. I cannot see what else I can do.

m

Hi @MichaelDonn,

This is because of a breaking change in the OpenStudio API which has already been addressed in Honeybee. Did you update the file after updating the installation?

Hi Mostapha.

Thanks for rapid response. I ran update options for HB + LB. I installed latest OS. Then i used just the new re-run osm widget to be sure there was no complexity from the hydra example making things tricky.

I will try again.

M

([Just to clarify] The problem persists: I have run the update objects in Ladybug and Honeybee a couple of times.

I have also exited Grasshopper and Rhino, and re-started them, then re-built the test file from scratch.

The test file comprises a path for each of the osm files, and the re-run osm widget plus a couple of output panels… (further explanation)

M

Not sure if my reply to my post becomes something that draws attention any longer, so I am trying again…

Hi Mostapha.

I am about to give up on this. I have not yet used the somewhat complex Hydra script yet. I have made sure ladybug and honeybee are as up to date as possible. I have set up a new simple process that just uses the import osm files widget, nothing else.

The error that i have seen listed in past posts remains…

Help? Anyone?

Hi @mostapha

Two issues:

  1. This original question is still proving a headache.
  2. I tried a clean install of everything on a colleague’s machine, but we cannot get the @chrismackey Hydra Energy Balance script to run. At least for us the window in the attached test building is not being ‘read’ by Honeybee as a window (when I decompose the included geometry based on type and visualise the model to show my colleague there is no window geometry.)

M

It looks like the “re-run OSM” hasn’t been fixed yet, c.f. https://github.com/ladybug-tools/honeybee-legacy/pull/737

Hi there

This problem is still bothersome. It probably should not be under this heading “solution exception”, but I am unsure of the etiquette of starting a new thread for an old problem that i am only coming to terms with better.

I can get the job done, but only at home. Anyone with some ideas about why the Honeybee Component GBXMLtoHB should work on a computer that I have full control over, and not on a university computer where I have only slightly less control to install software would be listened to with great care.

I am still trying to get the Energy Balance script to work.

I get different results at home using the same script and the same data from the same Dropbox folder.

At home, the result looks good.

At work the result cannot discern the window surface through which to calculate the heat losses, so we have a much bigger “Storage” component.

The problem seems to be in the different operation of the GBXMLtoHB component as when I parse the output at home the model looks like this.

And using the same XML file from the same Dropbox folder, at work it looks like this:

And, for now, I am not even going to comment about the difference in the units on the graph, using the same script with the same input files!

I attach the script and the .idf file as the output .csv and .eio file are too big to upload here.

The input txt file is just a marker to a list of multiple files to enable the script to be run 32 times.

Energy_Balance_updated-11-21.gh (552.8 KB)pre-preprocess.idf (135.5 KB)

I may have the solution! (Embarassed face). The base units on Rhino at work was millimeters, not meters. The issue appears to disappear, when I get the units right!

@MichaelDonn ,

Going back to the beginning of this post, I am really sorry for now seeing this bug sooner. @souliane contributed a fix for this issue, which we just merged in. The Re-run OSM component should now work and let us know if you encounter any more issues with it.

1 Like