I’m working with my supervisor, @MichaelDonn, on calibrating an energy model using a gbXML file (Fig.1). We’ve encountered an issue where the zones get reordered whenever we restart the program (Rhino & Grasshopper) or switch between different devices using this script (Fig.2).
As a result, we often need to restart the software 3 to 5 times to get all the rooms in the test unit to return to their correct locations or to be reordered correctly (Fig.3).
The Dump to save the model after import the gbxml as json file. And the load to load it from there each time you need the model and not using the gbxml which is giving you trouble.
Hope this helps.
-A.
Interesting. I guess in my opinion: I would assume consistent order of rooms is not guaranteed, especially when going between formats like that.
I think you are much better off doing as you do in ‘Fig-2’ and using some form of ‘key’ (in your case, room name) to sort/filter/find which room is which.
Perhaps I don’t follow, but it seems that your ‘Fig-2’ is giving you the output you desired, no? Is there a problem with doing it that way?
Kia ora Ed (@edpmay) I think the issue is how the Design Builder file was built from which the gbxml was created.
It seems the originator of the gbxml was just focused on the input of all the rooms in a multi apartment building model.
Unfortunately, the conditions of confidentiality under which we have access to the file preclude sharing. We hoped some other folks might have encountered the issue. Even editing the text of the xml does not reveal a hint at some level of organization by apartment identifier.
What is surprising is each time the xml is read the order of rooms is different. We could of course manually do this once and save that model, but it seemed worth discovering what we are missing about the read order.
This is probably more of a question for the OpenStudio team on unmenthours than for me. I know all of our Ladybug Tools Python code preserves the order of Rooms but the OpenStudio gbXML translators that we use to import a gbXML file into an OSM that we can translate to a Honeybee model might not be preserving order. I know that OpenStudio SDK has some “unordered list” data structures that govern some things that go on in the background. So they might be the cause of the order changing each time.
You could find out for sure by importing the gbXML into the OpenStudio Application and seeing if the order of the Zones or Spaces changes each time. If it does, then it’s a question for the OpenStudio team.
Or you could just do something like sorting the Rooms alphabetically as soon as you import them from gbXML to give them a consistent order. Similar to what you were suggesting, @edpmay .
It has (finally) occurred to me that the solution - as hinted by @Chris and originally suggested by @AbrahamYezioro is two separate scripts.
import the gbXML file and manually visualise the 3 rooms x 24 apartments. Then create models with Apartment names that are immediately HB Dumped.
Then, these files have all the attributes we want and we can set up to run multiple apartment or single apartment studies from a couple of hard-coded drop-down lists with the names we have assigned. (Royal “we” of course)
Thank you @MichaelDonn, for clearly explaining everything.
And many thanks to @AbrahamYezioro@edpmay and @chris for your helpful recommendations. As my Supervisor explained, we tried all the suggested options yesterday and it finally worked!
