Skip to content
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

Open
larissakuehn opened this issue Dec 6, 2022 · 2 comments
Open

Input for moisture supply into ROM #1669

larissakuehn opened this issue Dec 6, 2022 · 2 comments

Comments

@larissakuehn
Copy link

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:
Deviations

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?

@mwetter
Copy link
Contributor

mwetter commented Dec 6, 2022

That sounds to me like quite a special application, for which it may be better to try one of these approaches

  • extend from the model, and make a specialized version as most users won't need this complexity.
  • make a separate model that draws air from the volume, adds the latent gain, and returns the air back to the volume (for example using Movers.BaseClasses.IdealSource with Fluid.Interfaces.StaticTwoPortConservationEquation in series). This would also have a few advantages, such as
    • the rate of evaporation could be computed based on the moisture and temperature of the air, which can both be accessed in such a model
    • the model could also be used if air is circulated through a space with plants (AIT has such a system in which the supply air is drawn through a space with plants)
    • contaminants, such as chlorine, could be added in swimming pools
    • the model could also be used with other more detailed room models.

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.

@larissakuehn
Copy link
Author

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants