Hi,
I would like to model heat, air and moisture transfer through the building elements.
I know that EnergyPlus has this ability through it’s Combined Heat and Moisture Transfer (HAMT) Model calculation engine. However, I have no idea how to access it either through Honeybee or OpenStudio.
Looking through some of the previous forum questions, one that seems quite relevant was the forum question about the green facade.
Chris solved the issue with an example file. This file included a script that set the ‘moisture diffusion calcuation method’ to advanced. I believe that this then activated the HAMT Model calculation engine?
If so, is there any way to set accurate moisture diffusion resistance values or moisture storage values for the construction materials?
I will be using WUFI Plus, though my understanding is that EnergyPlus does have this capability embedded deep in the engine and I would like to explore the option to use Grasshopper further.
I’m also curious if Ladybug Tools can be used to tap into this possibly quasi-WUFI capability of EnergyPlus from the comfort of the grasshopper/honeybee environment. Any other comments here re this?
I have talked to Fraunhofer for a several times, they don’t have any plan to make public APIs. There is nothing we can do here, unless their users push them.
I used the Effective Moisture Penetration Depth algorithm in Energy Plus some time ago, which seemed a more accesible version only for indoor humidity absorption/release (I dont think it accounts for vapour transfer through the envelope). The HAM model is theoretically more accurate, but getting the material inputs to use it seemed imposible back then.
It was a case related to earth construction systems, so even any hygrothermal property for the EMPD model was quite tricky to find.
Implementing the EMPD in GH should be fairly doable through the additional strings input in the Export to OS component, but back then I just did it in E+. If it helps I could look into my old files and share it.
That said, I don´t really know how the EMPD model compares to HAM or WUFI but WUFI´s material library is a huge asset - it´s sad to hear they are not willing to open their API.
Actually, if you are willing to get to the bottom of it, E+ engineering reference explains the calculation procedure and points to this report for validation.
Thanks all for your responses. @RafaelA thanks for digging through the E+ documentation and linking the referenced report!
It is a shame that the HAMT model can not be activated through the user interface, although I would still be extremely interested in how you previously implemented the EMPD model in GH. If you are happy to share your old filed that would be great.
While the EMPD model may not be so useful from a vapour transfer perspective, it would still be very interesting for some of the research that I am looking at, which concerns the moisture buffering effects of internal surfaces.
Here’s to hoping that Fraunhofer may be happy be collaborate in the future.
I’ve now managed to dig out my script with the EMPD implementation. EMPD_Forum.gh (1.0 MB)
As you’ll see the model is set up as a regular HB model with two additional features that plug into the additional strings input of the Export to OS component:
The first panel sets EnergyPlus HeatBalanceAlgorithm to MoisturePenetrationDepthConductionTransferFunction and controls general settings.
A second of panels control the Moisture buffering properties of the materials. These properties need to match exactly the material names created for your HB constructions.
The implementation is quite basic and I’m sure it could be made more user friendly than having all the settings embedded into text panels. I didn’t develop it further since I never needed it since then, but I can see how it could be useful in some particular cases.
I’m curious to know if you manage to get somewhere with the HAMT model, I found it terribly difficult to get all the material specs needed to use it.
I hope you find it helpful - if you have some trouble going around it, I’m happy to help you further.
As a WUFI user (who would much rather be able to stay in Grasshopper with ladybugtools as the UI) what would the best way to add some pressure on them for this be?
Even if using inter-operability tools from Ladybug to add the WUFI engine into the mix required a Wufi licence; I don’t see how this is something that would be harmful to Fraunhofer from a business perspective, if anything it would make WUFI a more attractive tool because it would allow it to be added into evolutionary tools and the other parts of the ladybug toolset and not make WUFI the undesirable part of the workflow.
