This is a pretty significant one in terms of impact but a trivial fix.
Problem
IDFs have no concept of layers, so thickness of course lives within Material definitions in the IDF, unlike Archetypal, where thickness lives in the MaterialLayer. When constructions are added to an IDF, they add their underlying materials with the designated thickness but only use the materials' names as the IDF object name. This results in erroneous propagation of thicknesses to any other constructions which use the same material but different thickness, since the older instance of the material in the IDF gets replaced with the new one due to having the same name. This would even happen within a single construction if the same material is used twice but with different thicknesses.
Code
Each of the to_epbunch methods for Glazing/Gas/OpaqueMaterial accept a thickness (usually passed in when an [Opaque/Glazing]Construction object's call to to_epbunch in turn invokes the to_epbunch method of each of the underlying XMaterial objects in the construction's Layers list), e.g. here:
Probably the simplest and best approach is to add the thickness to the material name, e.g. Name=f"{self.Name}+{self.Thickness:0.4f}". This will mean each instance of a material with a given thickness gets its own entry in the IDF; constructions which have layers with identical material and thickness will still share the same material entry in the IDF. con is that the naming is a little ugly.
Option 2
Give the XMaterial.to_epbunch method an optional suffix argument. If provided, it gets added to the material's name when adding it to the IDF. The invoking Construction could pass in is name/id to the underlying material's to_epbunch as a suffix. Pro is that it makes the name is clearly traceable, but there are a few cons: doesn't actually fix the problem for constructions which use the same material twice but with different thicknesses (e.g. a double paned window with two separate gas layers). You could add the layer index to the suffix that is passed in to remedy this. Another con is that the IDF gets a lot heavier since even if two constructions have layers with the same material AND same thickness, they will still get separate entries. Another con is that a user who is directly calling the XMaterial.to_epbunch method may unintentionally overwrite another copy of the material with different thickness if they don't provide a suffix.
Option 3
Most rigorous, but also least performant. Within the XMaterial.to_epbunch method, check the IDF list of materials for instances of the same name (up to an integer suffix); if one with the same thickness exists, add with the same name including the suffix of the one found, thus overwriting the matching instance but no others (for instance if you were intentionally updating the material properties and did indeed want it to propagate). If you don't find any with matching thickness, add it to the IDF with a suffix which is the count of how many already exist in the same file with same name but different thickness.
This is a pretty significant one in terms of impact but a trivial fix.
Problem
IDFs have no concept of layers, so thickness of course lives within
Materialdefinitions in the IDF, unlike Archetypal, where thickness lives in theMaterialLayer. When constructions are added to an IDF, they add their underlying materials with the designated thickness but only use the materials' names as the IDF object name. This results in erroneous propagation of thicknesses to any other constructions which use the same material but different thickness, since the older instance of the material in the IDF gets replaced with the new one due to having the same name. This would even happen within a single construction if the same material is used twice but with different thicknesses.Code
Each of the
to_epbunchmethods forGlazing/Gas/OpaqueMaterialaccept a thickness (usually passed in when an[Opaque/Glazing]Constructionobject's call toto_epbunchin turn invokes theto_epbunchmethod of each of the underlyingXMaterialobjects in the construction'sLayerslist), e.g. here:https://github.com/samuelduchesne/archetypal/blob/4e0b389127a87c3dfbda96518fdb2c88802d103c/archetypal/template/constructions/opaque_construction.py#L569-L577
The material name is for the IDF without differentiating by thickness:
Opaque Materials
https://github.com/samuelduchesne/archetypal/blob/4e0b389127a87c3dfbda96518fdb2c88802d103c/archetypal/template/materials/opaque_material.py#L490-L519
Glazing Materials
https://github.com/samuelduchesne/archetypal/blob/4e0b389127a87c3dfbda96518fdb2c88802d103c/archetypal/template/materials/glazing_material.py#L349-L366
Gas Materials
https://github.com/samuelduchesne/archetypal/blob/4e0b389127a87c3dfbda96518fdb2c88802d103c/archetypal/template/materials/gas_material.py#L174-L179
Solution
Option 1
Probably the simplest and best approach is to add the thickness to the material name, e.g.
Name=f"{self.Name}+{self.Thickness:0.4f}". This will mean each instance of a material with a given thickness gets its own entry in the IDF; constructions which have layers with identical material and thickness will still share the same material entry in the IDF. con is that the naming is a little ugly.Option 2
Give the
XMaterial.to_epbunchmethod an optionalsuffixargument. If provided, it gets added to the material's name when adding it to the IDF. The invoking Construction could pass in is name/id to the underlying material'sto_epbunchas a suffix. Pro is that it makes the name is clearly traceable, but there are a few cons: doesn't actually fix the problem for constructions which use the same material twice but with different thicknesses (e.g. a double paned window with two separate gas layers). You could add the layer index to the suffix that is passed in to remedy this. Another con is that the IDF gets a lot heavier since even if two constructions have layers with the same material AND same thickness, they will still get separate entries. Another con is that a user who is directly calling theXMaterial.to_epbunchmethod may unintentionally overwrite another copy of the material with different thickness if they don't provide a suffix.Option 3
Most rigorous, but also least performant. Within the
XMaterial.to_epbunchmethod, check the IDF list of materials for instances of the same name (up to an integer suffix); if one with the same thickness exists, add with the same name including the suffix of the one found, thus overwriting the matching instance but no others (for instance if you were intentionally updating the material properties and did indeed want it to propagate). If you don't find any with matching thickness, add it to the IDF with a suffix which is the count of how many already exist in the same file with same name but different thickness.Repro
material_epbunch_problem.ipynb.zip