mwetter
commented
1 year ago 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.IdealSourcewithFluid.Interfaces.StaticTwoPortConservationEquationin 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
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?