IBPSA.{Air,Fluid.Water} package

[mwetter]

For EnergyPlus/OpenStudio, we will need packages that are closer to what HVAC engineers typically deal with.

We work with @michael-okeefe from Big Ladder to design how to best set up a library that is closer to what HVAC engineers expect.

For example, we will need to have packages such as

Buildings.Air.Fans.xxx
             .Humidifiers.Steam_X
                         .SprayAirWasher_X
         .Water.Pumps.xxx

rather than

Buildings.Fluid.Movers.xxx
         .Fluid.Humidifiers.SteamHumidifier_X
                           .SprayAirWasher_X

The rationale is to make it easier for users to find and use models, and
to avoid having to set the medium.

Having Air and Water parallel to Fluid is probably easiest to understand.

Also, we need some 4 ports models for air-to-water heat exchangers that have ports such as

wat_a  ---------  wat_b
      |         |
air_b  ---------  air_a

instead of

port_a1 --------- port_b1
        |       |
port_b2 --------- port_a2

as it is not obvious that index 1 is water and 2 is air.
Similarly, we will also need to have parameters such as
mWat_flow_nominal rather than m1_flow_nominal
(which is inherited from the base class)
as associating 1 with water and 2 with air is inconvenient.

Also, chillers and heat pumps would ideally have ports

con_a  ---------  con_b
      |         |
eva_b  ---------  eva_a

Therefore, this issue is to add packages IBPSA.Air and IBPSA.Water and do the
following

• Move models that can only work with one of the medium, such as
  the humidifier, to IBPSA.Air or IBPSA.Water (e.g., for the expansion vessel)
  and assign the respective media.
• Extend (or instantiate) other models such as the Movers and some Sensors in
  IBPSA.{Air,Water},
  assign the respective media and copy the documentation
  (which is not ideal but needed so that the doc is together with the model).
  There are quite a few models that need to be in both packages,
  and some would need to be renamed.
  For example, a mover becomes a fan or pump.
• Add new base classes to allow better port names such as {air,wat}_{a,b}.

Notes

1. There is AixLib.HVAC, but this has its own connectors, hence IBPSA.HVAC is
   probably a bad idea as its models will be incompatible.

2. If there is much code duplication, then the "original" source code
   could be put in a template, and we could generate the code as part of our
   development using for example http://www.makotemplates.org/,
   http://jinja.pocoo.org/docs/2.9/ or https://github.com/jawher/moulder-j
   http://kirank.in/posts-output/2016-01-06-notebook/.
   In this case, the continuous integration will include a test to make sure that
   all generated .mo files are up-to-date.

3. The style guide will be that domain specific models (such as a valve) is only
   in IBPSA.Water. Shared code such as the Movers.FlowControlled_dp is in IBPSA.Fluid from which it either is extended

     within IBPSA.Fan;
     model FlowControlled_dp "Fan with controlled head"
       extends IBPSA.Movers.FlowControlled_dp(
         redeclare replaceable package Medium = IBPSA.Media.Air);
     ...
   

   or, alternatively, {Fluid.Movers, Air.Fans, Water.Pumps}.FlowControlled_dp
   are generated from a template Fluid/Movers/FlowControlled_dp.template.
   As Modelica development is done quite interactive in an IDE,
   I think we should however avoid excessive use of templates as any change
   in .mo will need to be added back to the template file.

   Note that the Medium is replaceable so that it shows up in
   the parameter window and users can redeclare it or add trace substances C.

4. To avoid having to copy the info and revision section, we could have
   in IBPSA/Air/Fans/FlowControlled_dp.mo
   vendor annotations that will cause the info section to be copied
   and some text replace applied, such as

      __IBPSA(info(src = IBPSA.Fluid.Movers.FlowControlled_dp,
                   replace = ["fan or pump", "fan";
                              "Fan or pump", "Fan"])
   

   This way, users will see a complete info section, but there is only
   one source which can be edited in a Modelica IDE.

How do the other library developers see this? LBNL will have to make such packages
anyway for the Spawn of EnergyPlus, and I rather like to do it in IBPSA than only in Buildings.

[marcusfuchs]

We will discuss this internally for AixLib and give our feedback soon.

Regarding your Note 1 for AixLib.HVAC: This is no longer the case, as we removed the HVAC package with incompatible connectors in RWTH-EBC/AixLib#283 . Therefore, this should not be an issue.

[marcusfuchs]

As we discussed in RWTH-EBC/AixLib#386, our group of users and developers is largely in favor of the proposed restructuring. We would favor a library structure that is user-friendly and intuitive from an engineer's perspective

As we expect this to require a significant effort, it would be necessary from our perspective to have a detailed discussion of the new structure and make sure we all agree on it, so that we only have to do the restructuring once, if possible.

Regarding the templating, my personal opinion is that we should be very careful about adding that extra-layer of complexity. I would consider code-duplications the lesser evil in many cases.

[Mathadon]

We discussed in open-ideas/IDEAS#728 . We would also like to avoid having another level of complexity related to scripts. I'm also wondering why we should suddenly start assigning default media?

[mwetter]

The media will be replaceable, but by default assigned to IBPSA.Medium.{Air,Water} so the user does not have to assign it.

[thorade]

No objections from Berlin regarding the restructuring.
@nytschgeusen