search

open-ideas / IDEAS

Modelica library allowing simultaneous transient simulation of thermal and electrical systems at both building and feeder level.
133 stars 58 forks source link

Boundary condition for pressure in zone model #796

Closed Mathadon closed 6 years ago

Mathadon commented 6 years ago

The zone model currently only has two fluid ports for connecting ventilation and has no boundary conditio for the pressure. This leads to some problems. E.g. users can try to inject a mass flow rate on one port, which will not work if the other port is not connected. Also, setting an absolute pressure to a zone requires that the absolute pressure is connected to either of the two ports, while these ports may already be used for supply and return air flow connections. The port will then contain two connections, which introduces mixing equations. This may cause the mixing to occur 'outside' of the zone, while physically it occurs 'inside' the zone. The model is then not physical. Moreover, these mixing equations are causing trouble for MPC. Also, users should not have to worry about setting the absolute pressure boundary temperature and absolute humidity, etc.

Therefore it would make sense to include an absolute pressure boundary inside of the zone air model. This boundary should be replaceable by a more detailed model, e.g. #769 . It would also make sense to group it together with the simplified air infiltration model that we currently have. In the future we would then be able to select multiple air flow model complexities, while now we would only have constant pressure and fixed infiltration flow rate.

This change would not be backward-compatible since connecting a boundary_pT to a zone model would lead to a singularity.

Any feedback on this?

Mathadon commented 6 years ago

A major downside would be that it would no longer be possible to directly couple to zones to each other using fluid ports since then the flow rate between the two zones is undefined..

Mathadon commented 6 years ago

A less intrusive option would be to add one additional port, or a vector of ports in addition to the two ports that are currently available. This is also what I did for the Solarwind model. This would also be backward compatible.

icupeiro commented 6 years ago

@Mathadon I would keep two ports, it is easier to keep track which are the entering flows and the outgoing flows, and a connection to a boundary inside to avoid crashes due to pressure?

Mathadon commented 6 years ago

Ok, if we make the internal connection optional then this is indeed an option. Otherwise we'll get major reverse incompatibilities. I would then look into this together with #769 . @damienpicard @GlennReynders what do you think about this suggestion?

Mathadon commented 6 years ago

closed in #807