I’m new to the Pollination Rhino plugin, and I’ve been having trouble getting my first model to run as expected when exporting directly to OpenStudio. I’ve gone through the forum posts and tried some of the solutions provided, but many seem to only offer partial fixes.
To clarify, I’m hoping to get help with the following issues:
1. OpenStudio Room Names: There’s an issue where Rhino room names are not properly carried over to OpenStudio unless they consist of unique alphanumeric strings. The suggested fix on the forum is to use the PO_ResetIdentifier command, but this only partially works. The room names in OpenStudio still end up with a _space prefix at the end.
2. Load Definitions in OpenStudio: I’m also facing difficulties with load definitions. The load names in OpenStudio are still coming through as unidentifiable strings due to the use of alphanumeric characters. Is there a more comprehensive fix for this? The same applies to Construction sets and Schedules.
Yes. We have since implemented an easier way to use the display names without resetting the identifiers. There are two options to use the display names for geometry and resources including schedules, constructions and loads.
Please note that while the construction set and room name exports to OpenStudio worked well, I have encountered a few additional issues related to program types and service hot water:
The built-in program types export fine to OpenStudio, but when I create a custom program type through the room properties, it exports as an ID text string instead of the custom name I assigned.
I also tried duplicating a built-in program type and renaming it, but the export process seems to ignore my new name and retains the original built-in program type name.
Any further insights or suggestions on how to resolve these issues would be greatly appreciated and/or alternative workflow processes that might help.
Hi @carey, while we are waiting for @chriswmackey I just remembered that this was a bug that was fixed in the latest release. Are you using the latest release of the Rhino plugin (v1.51.2)?
I’m not sure that I completely understand the difference between what you are getting and what you are expecting but I will lay out what I think you are saying.
In the source code, you see that setting the resource IDs to be generated from display names changes the ID of the whole Program/SpaceType to match the display_name that you assign in Rhino:
So the name of the SpaceType should match the name you gave it in Rhino. Now, the individual load definitions underneath the Program also have their own names and identifiers but neither of these names or IDs are exposed in the interface of the Pollination Rhino plugin. As you can see, there’s no slot for you to specify the name or ID of Lighting, People, etc.:
So, even if I were to add something to set the ID of these loads from the name, it would not matter as the names of these load objects are not set-able in Rhino. Granted, there are plenty of ways to set these load IDs/names if you are creating the program with the LBT Grasshopper components or you are editing the JSON definition of the program in your user standards library. But I imagine that you want to do this all in Rhino.
So, given that this seems to be more of a request for exposing the names of the loads within the Rhino plugin interface, I am re-assigning this topic to @mingbo since he’s the best one to expose this.
Also, the SHW Systems always use the name of the system for the hot water loop when translating to OpenStudio. So just make sure that you are setting the name when you make the system and you’ll get what you want:
Thanks for your response. However, to provide more clarity, please refer to the attached screengrabs, which better illustrates the issues encountered after exporting the model to OpenStudio, particularly related to the program type and service hot water. Your feedback on this specific issue would be appreciated, as well as any guidance on the next steps.
I see that this may now be assigned to @mingbo, but your initial feedback would be helpful to ensure we are on the same page.
I’m just letting you know that I added some code that sets the identifiers of the load objects to be derived from their names whenever you save the OSM with the “Set resource id by display name” checked. The change is here:
So, once @mingbo exposes the ability for you to set the names of the different loads under the program, these names will be carried into the resulting OSM.
On a side note, @mingbo , if it will take a lot of effort to expose the display_names of the individual load objects in the Rhino interface, there is a a faster improvement that would probably be just as helpful for @carey identify what objects are in the OSM. You could just set the names of these load objects using the name of the program under the hood without exposing it on the ProgramTpyeManager interface. So, if someone names their program “Museum Office,” the names of all the loads would be set to “Museum Office People,” “Museum Office Lighting,” etc. This way, you could at least tell what they are in the OSM if the names of the Programs have been set well.
Thanks @chriswmackey,
I think it is better to expose them all to users.
I spent some time adding display name to all loads for both Room Property and Program Type dialogs.
