I just wanted to make sure that I understand how to map insulation correctly and I also have a few thoughts about how materials of variable thickness could work.
In EPD’s for a typical insulation product such as Flexibatts 37 from ROCKWOOL the declared unit is 1 m2 and 37 mm thick.
I will for example need to use this insulation on a 12 m2 wall in a thickness of 240 mm.
Does this mean that I can’t simply map 12 m2 of the product, since this is only 37 mm thick, when I need it to be 240 mm thick?
Should I calculate it as:
240 mm/37 mm=6.486 (I would need around 6.5 layers of 37 mm insulation to create a thickness of 240 mm)
12 m2*6,486=77,838 m2 (I would need around 78 m2 of the declared unit of insulation just to create a thick enough layer on my specific area)
When working with products of variable thickness it would be nice for the declared unit to be based on volume, this would solve the problem. But this is decided in the EPD, not by Real-Time, so is there anything to do?
Even when creating constructions of inhomogeneous layers of insulation+posts, the two materials won’t combine in the same layer, because insulation is declared as m2 and wood often in m3.
This is another reason why having the option for inulation in volume would be nice and more user friendly.
You are correct that the declared unit is decided by the EPD, therefore we cant change that.
For your two proposed calculations, both methods are correct since it yields the same end result. Personally i think the first method makes most sense, the one with 240mm/37mm=6,486. Using this thought, i would recommend to create a construction that factors the amount of insulation for the needed thickness.
So in the case of needing 240mm rockwool flexibatts i would create a construction named “Flexibatts 37, 240mm” and add the EPD to the construction and set the amount 6,486m2 flexibatts 37 pr. m2 construction.
Then when you map with this construction you will have the correct amount of flexibatts, without having to change any values of the walls square metres. This means though that you have to create a new construction for each insulation thickness.
We are working on updating the construction feature. Here you are able to create the inhomogeneous layer that need. Furthermore this means that you can have a construction with a declared unit in m3 and mapping an EPD with a declared unit in m2 to it. Thus fx. you can make the rockwool EPD practically act as an material declared in m3 as you talk about.
In the example above I have been given both length, area and volume of a material layer. This adds up a layer thickness of 70mm. If I map the Flexibatts 37 material from ROCKWOOL, the area will be chosen as the preferred material take-off and all other units will be ignore. And then the volume will behind the scenes be changed to V = Area x Thickness in EPD = 64,13 m2 x 0,037 m = 2,37 m3, without showing the change in the screenshot above.
This is really dangerous, as changing the volume will make significant errors in the calculation. This obviously stresses the importance of never using EPD’s blindly - even if they are easily available in a material library.
You suggest a feature, where you can adjust the thickness by creating a separate construction with said material. But that is still a lot of work with aaall the e.g. insulation material you might find out there. Might I suggest another solution?
Most EPD’s include a conversion factor. Would it be possible to enter an EPD in your library using the emissions data from the EPD according to the declared unit, but then add a field where you can specify the conversion factor? That way, EPD’s with a certain prespecified thickness can be converted to 1 m3, etc.
Until a liable solution is found, I suggest that a yellow pop-up message is given every time you map a construction with a material that isn’t declared in m3. That way, we as users are reminded to QA the mapped EPD.
Yes i agree that you should always make sure that you use the EPD correctly before using it.
The conversion factor idea is actually something we have briefly talked about, but it’s not something i’d suspect would be implemented in the near future, for now atleast.
