Open KremerMartin opened 4 years ago
@KremerMartin : Since #310 is closed, does it mean this issue can also be closed?
@PMehrfeld No. The intention was to close the old issue and provide more details here. The developed AHU model (until now developed in GitLab) will be transferred into a branch related to this issue on the next hackday.
Added first version by commit 8bdd32b73519e23adfc9b0be678b662f32dbc14a
@KremerMartin What is the current status? Maybe an issue for the hackday?
@XucYin As I see it, there is no progress on this issue since the hackday at the beginning of this year. @KFinkbeiner Am I right with this assumption or have you provided some progress on the model by now? Maybe I find some time during the hackday to make some progress.
For the next steps I would suggest:
[x] check functionality of single components
[x] prepare every possible component combination and connections with condition expressions in one model
[x] define operation scenarios for comparison with the existing AHU model
[x] apply the modular AHU model in those scenarios, whose components and predefined internal connections can be activated/inactivated on demand using parameter selections
[x] Maybe we could rework the modular model, that has been implemented, but not finished, with RealPassThrough
- models instead of if-conditions. This would simplify the code.
[ ] search possible reasons for result deviations
any new developments here? maybe something for hackday tomorrow @martinkremer ?
Following results are recorded when comparing the modular AHU model with the AixLib.Airflow.AirHandlingUnit.AHU
for a stationary heating case with the heat recovery system deactivated (efficiency both set to 0). With various outdoor air temperature, the result deviations are small but the relative deviations are not linearly proportional to the temperature difference.
One reason is the different specific heat capacity of the dry air used in the two models. When using the same value (1005 J/kg/K), smaller deviations are to be observed.
@KremerMartin found another reason: At lower outdoor temperature inputs, the relative deviations increase because the existing model AixLib.Airflow.AirHandlingUnit.AHU
decreases the inputed absolute humidity when the relative humidity exceeds 100%, which is physically correct but not directly visible for users.
Any updates here? Maybe this is something for the upcoming hackday?
Update: I cleaned the branch, deleted some old obsolete models and model parts. Open ToDos:
Since the old air handling unit model does not contain the functionalities for heat recovery only or steam humidification no verification will be possible for these cases.
The current differences in the two ahu models:
Dehumdification results get closer, if the bypass-factor dehumidification of old ahu is set to zero. This is striking. Needs to be checked if old model is correctly implemented.
Update on the progress:
Since results of the AixLib.Airflow.AirHandlingUnit.AHU
are in many operation points not quite reliable, a comparison as planned seems not sensible.
Therefore the new models shall be compared to analogue models in the Fluid
package.
First test cases for validation of the sub-components have been implemented, showing good agreement.
Open ToDos:
Fluid
package
What is the problem?
Currently we are using the AHU model provided by @PMehrfeld to calculate the energy consumption of the air handling unit in building simulation. This model is fixed in its configuration. We want to resolve this restriction, by providing an AHU model consisting of sub-models for the AHU components.
How do we want to solve it? Describe the solution you'd like
We will provide one model each for every component in the air handling unit. By combining these models one will get an AHU configured the way it should be. In a next step we will think of a possibility to provide a configurable AHU model to the user via parameter tab.
Every component will be adressable in the way the old model adresses the different fuctions, by using set-Value conditions for the outlet temperature/humidity. Moreover a possibility to use heatPorts and mass flow rates will be provided to use the components as well for some control tests.
Closes #310 .