-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Input for moisture supply into ROM #1669
Comments
That sounds to me like quite a special application, for which it may be better to try one of these approaches
If it were added to the existing model, it should at the minimum be disabled by default as this is a special usage. To keep the existing model simple, which is the purpose of a ROM, I would however much prefer not to add it to that model. A high level comment is that I am a bit surprised about the demand for such high accuracy in view of (i) the likely uncertainty in determining the latent gain, and (ii) the fact that the ROM model has no moisture buffering in the materials, which likely leads to a much larger error than the 2% indicated in the above plot. |
I understand the criticism and that the deviation is not great. Nevertheless, we would like to consider the correct temperature when adding moisture, but I'll take a closer look at your proposed approaches. Especially the second approach sounds promising for me. Thank you very much for the quick response and the feedback to my issue! |
Current Status:
Currently, the input for moisture calculation into ROM is QLat_flow. The water flow rate is then calculated by dividing QLat_flow by the enthalpy of a condensing gas at a temperature of 37 °C (h_fg).
At our institute (Institute for Energy Efficient Buildings and Indoor Climate, RWTH Aachen), we want to use the ROM to represent different building types for which the assumption of a constant evaporating temperature of 37°C leads to errors. These are for example:
• Swimming halls, with swimming pools at different temperature levels (24°C – 34°C)
• Sauna and fitness centers (80-100 °C for saunas)
• Greenhouses (17 – 25°C)
• Offices with green/plant walls or water walls as humidifiers (corresponding room temperatures of offices, 20 – 26°C)
All these building types have different temperature levels for evaporation, which are dynamically changing in some cases. The magnitude of the error depends on the temperature. This results in the following relative deviations depending on the temperature for the listed examples:
For swimming pools with high water evaporation, for example, this leads to large absolute errors. Depending on the pool temperature, type and occupancy level of the pool absolute errors can be between 4 kg and 15 kg per day and pool.
Suggested changes:
To model the different types of above mentioned buildings with moisture balances considering corresponding temperatures, I would like to suggest the following changes:
• Change single input QLat_flow to an array
• Add additional array input for temperatures
• Calculate the moisture input with the latent heat flow and the evaporation enthalpy of the corresponding temperature.
• Sum up all QLat_flow and mWat_flow and connect it to the corresponding ports of volMoiAir
To make it backward compatible and avoid necessary changes in all models that extend the ROM, an additional Boolean parameter could be introduced, e.g. use_varEvaTem. Based on this, all before mentioned components would be realized as conditional components. Per default use_varEvaTem would be false. In that case there would still only be one input for QLat_flow and a constant evaporation temperature of 37°C. It could also be implemented the other way around with use_conEvaTem, which is true by default.
I would be happy to implement my thoughts on this within a new branch as a first draft. @mwetter, could you give me your feedback on this issue?
The text was updated successfully, but these errors were encountered: