mwetter commented 7 years ago

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

There is AixLib.HVAC, but this has its own connectors, hence IBPSA.HVAC is probably a bad idea as its models will be incompatible.
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.
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.
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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

We discussed in https://github.com/open-ideas/IDEAS/issues/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 commented 7 years ago

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

thorade commented 6 years ago

No objections from Berlin regarding the restructuring. @nytschgeusen

ibpsa / modelica-ibpsa

IBPSA.{Air,Fluid.Water} package #778

Notes