hi @mostapha
I had created materials, assigned inside constructions and construction sets.
One was mispelled “Concrete block 20mm” instead of “20cm”.
When I changed its name the changes couldnt be updated within the constructions and I had to duplicate the material and reassign it everywhere one by one.
Is there a solution for this to update “parametrically” let’s say ?
Hi @olivierdambron - I’m not sure if I fully understand the question here. Can you tell me which one is the problem here:
hi @mostapha
Its number 2.
When I renamed a material that I had already been assigned in constructions, I realized that the construction was still looking for the old name. So I had to update all constructions manually by reassigning the new material.
Which is far from being the end of the world, I can just be much more careful when naming materials in the first place.
Hi Mingbo, This is a bug! We should update the references to the material/construction once it has been renamed.
That said, don’t we use the ID in this case? Or do we use the display name since they are unique?
Thank you, @olivierdambron! Now it is clear. I assigned Mingbo to the task so he can provide more insight.
Hi @mostapha, it was using the GUID for the resource object’s identifiers, and the DisplayName is an independent property. But at some point, we decided to make identifiers “user friendly” and made them auto-generated by the display name so that the display name is carried to osm and E+ files.
But I think the issue in Rhino Plugin should have a higher priority than the readability in osm and e+; Hi @chriswmackey what do you think if I use GUID for all resource objects (Material, Modifier, Construction, Schedule, etc)?
Hi @olivierdambron, I have updated the UI library and it will be included in the next release.
Hi @mingbo,
If you ask me, they are both equally important. One of the main workflows that are used by Pollination users is to export their models to other platforms like EnergyPlus and OpenStudio. Using UUIDs make those file really hard to use.
Hey @mingbo ,
You know that I’m a fan of UUIDs and I can’t begin to say how many headaches I have avoided in the LBT Grasshopper plugin by just making the default behavior with auto-generated IDs. It’s just far easier to tell an advanced user that they need to use an extra component or command to overwrite the ID than it is to deal with hundreds of new users who haven’t learned their lessons in unique naming yet.
So I am all for making the default behavior reliant on a UUID. Or maybe you could just set the identifier to something constant upon initialization, which could still be derived from display_name but does not change as people edit the display_name.
We’ll still need an answer for those advanced users who want to change the identifier but this can be separate from the default behavior, which should favor “easy to start” safety measures over the full flexibility that an advanced user wants. If the answer for advanced users right now is “duplicate the object and re-assign it,” I think it’s alright for now but eventually having an automated solution would be helpful.
Here is an example where I’m struggling with fetching results of a specific room, especially when there are many rooms, because the identifier are not easily recognizable, and the indexing may not always be consistent between the list of rooms in Pollination and the E+ SQL results.
Furthermore, this makes it impossible to use honeybee_energy.result.match.match_rooms_to_data() to select results for a specific room
Hey @olivierdambron ,
If you really want the Room IDs to be set based on the display_names, the PO_ResetIdentifier command has options that let you do this. However, this statement does not seem 100% correct to me:
This command should always work to get the results of the Room as long as you have the identifier of that Room. Am I misunderstanding here? Is the issue instead that you are having trouble getting the Room identifier from the Room’s display_name? If so, the suggestion above should address this.
thanks for your reply.
My question was more towards getting the ID of the zones inside the IDF according to the displayName.
Is that possible?
Hi @olivierdambron - the command that @chriswmackey mentioned above should help you with that. Watch the video at the bottom of the page. I believe it walks you through the process.
