OpaqueMaterial to use `clean_and_id_ep_string()` for identifier

[ed-p-may]

Hi,

In reference to the Post on the discourse forum: "Check for Duplicate Material Names":

User-messages are certainly helpful when this problem occurs, but a possible fix to avoid the issue entirely would be to use clean_and_id_ep_string() on the user-provided name instead of just clean_ep_string()

---

Existing:

honeybee-grasshopper-energy/honeybee_grasshopper_energy/src/HB Opaque Material.py

. . . 
name = clean_and_id_ep_string('OpaqueMaterial') if _name_ is None else \
    clean_ep_string(_name_) 
. . . 

---

Proposed:

. . . 
name = clean_and_id_ep_string('OpaqueMaterial') if _name_ is None else \
    clean_and_id_ep_string(_name_)  #<---- Set the identifier to always have an ID number
. . . 

---

Unless there is another reason that the identifier and the display_name have to always be the same?

---

Example GH File:

material_test.gh.zip

[chriswmackey]

Hey @ed-p-may ,

Funny that we are coming back to this. The very first version of Ladybug Tools that I released did exactly what you suggested here but I got so much pushback from other users about the "random IDs added to the end of names" even when I gave everyone a component that lets them overwrite the ID of anything that they want. So, while I kept the auto-generated ID for geometry objects like Face and Room, I loosened the restriction for energy or radiance objects like constructions or modifiers.

This system appeared to be (mostly) working well since the complaints about the "random IDs" have largely went away and, until now, I had not encountered anyone creating constructions or materials without knowing that they should give them unique names (or, if they are new users, they tend to leave the name blank, in which case a unique name is auto-generated).

So given all of the rounds that this issue went thorough already, I would rather not change it again. How many users have you found making this mistake about not using unique ids? If it comes back a few times, then I'll concede that maybe we could change it again.

[ed-p-may]

Hi @chriswmackey , ha - things come full circle.

That makes sense - I'm sure there are other ways to manage this issue - as you noted: the 'validate model' component is helpful once users know to add it into their GH files.

I guess I'm surprised that anyone had an issue with the identifier string being ugly like that though? Wanting the display-name to be clean of course makes sense, but in my mind the 'identifier' is assumed to always be something for the machine to read, not for the person to read? Odd.

Though I guess the identifier is used as the name field in the IDF though, right? So that's where folks end up seeing it and don't like it?

[mostaphaRoudsari]

Hi @ed-p-may,

I guess I'm surprised that anyone had an issue with the identifier string being ugly like that though? Wanting the display-name to be clean of course makes sense, but in my mind the 'identifier' is assumed to always be something for the machine to read, not for the person to read? Odd.

The ugly identifiers won't bother you if you stay in the Ladybug Tools/Pollination ecosystem but once you export them to other platforms like EnergyPlus and OpenStudio or you want to write some measure or Python code that relies on the materials/construction names it starts to get noticed.

Though I guess the identifier is used as the name field in the IDF though, right? So that's where folks end up seeing it and don't like it?

Yes. That's how it works. Using identifier will ensure the generated file will be valid.