testcase: multizone_office_simple_hydronic

[icupeiro]

this issue is to track the two-zone office model based on real practice experience by DeltaQ

[icupeiro]

@dhblum the model is currently working with MSL4.0.0.

How should we tackle this issue? Is it possible to combine it with the work in #422 or should I revert to MSL3.2.3 for the moment?

[dhblum]

What compiler are you using with MSL4?

[icupeiro]

I used Modelon Impact (OCT) to create and simulate the model so far

[dhblum]

I aim to tackle #422 this coming year to switch the default compiler we use for unit testing from JModelica to OpenModelica, as much as possible at least following on improvements to OpenModelica being made this year to simulate Buildings Library models. Do you know if the model simulates with the nightly build of OpenModelica? For now I'll also add your model to the tracking in #422.

[dhblum]

And how close is the model to being done? Are there signal exchange blocks, test case .csv data, and documentation all done? I ask because I'm trying to gauge how quickly you're trying to or would be ready to add this model to the repo, compared to how long #422 will take to complete.

[icupeiro]

hey @dhblum,

I just tried to compile it in OM, unsucessfully but so far due to the more strict requirements of OM with the Modelica standards (e.g. many each statements missing). I will have a look at this

Test case .csv data is there, doc and exchange blocks are missing so far but I just had a meeting with @JavierArroyoBastida to discuss these points, so they'll be there soon.

The idea is to have something fully ready by the next IBPSA meeting

[icupeiro]

Update: signal exchange blocks are ready, model compiles with OM (but simulation fails at initialization)

[icupeiro]

Follow-up update: after adding some energy dynamics (changing from steady-state) in some components here and there, the model now compiles and SIMULATES in OM for one whole year.
However results seemed a bit different in the preliminary assessment. I was able to track down some of the differences, which were coming from 'greater' blocks (I had to set a threshold from 0 to 0.01 to make it work). The resulting difference in zone temperatures between the model run with OCT and the model run with OM is on average about 0.05K, with a maximum difference a bit less than 0.35K. Since our purpose is bench-marking, we should watch out with these differences.

[icupeiro]

Update on compilation process:

Tried to substitute line 45 in parser.py from compile_fmu() to give the path of the FMU compiled in OM
Failed due to an error loading the FMU binaries

Traceback (most recent call last): File "compile_fmu.py", line 39, in <module> fmupath = compile_fmu() File "compile_fmu.py", line 33, in compile_fmu fmupath = parser.export_fmu(modelpath, [mopath]) File "/usr/local/testing/parsing/parser.py", line 215, in export_fmu instances, signals = parse_instances(model_path, file_name) File "/usr/local/testing/parsing/parser.py", line 48, in parse_instances fmu = load_fmu(fmu_path) File "src/pyfmi/fmi.pyx", line 8084, in pyfmi.fmi.load_fmu File "src/pyfmi/fmi.pyx", line 7135, in pyfmi.fmi.FMUModelME2.__init__ File "src/pyfmi/fmi.pyx", line 3848, in pyfmi.fmi.FMUModelBase2.__init__ pyfmi.fmi.FMUException: Error loading the binary. Could not load the FMU binary: /lib/x86_64-linux-gnu/libm.so.6: version 'GLIBC_2.29' not found (required by /tmp/JModelica.org/jm_tmpvfZW0h/binaries/linux64/BuildingEmulators_BuildingSystem.so)

Tried the same thing using OCT and the process can continue. However I was stopped also at line 182, regarding the compilation of the wrapper.fmu. What I did to circunvent the problem so far is to take the wrapper.mo, load and compile it into my OCT and again substitute the compile_fmu() by the path of the wrapper.fmu.

Still to-do:

• Determine the days.json
• Write documentation
• Write and run unit tests

[dhblum]

Moving recent problems from open-ideas/IDEAS#1343 to here.

Setup

OS: Ubuntu 20.04
Dymola: v2023x
OM: v1.23.0~dev-206-g00d3636
OCT: v1.43
Buildings: master 37287eb3d9174cc0e9efa65e2bca2cbd28f17bae (dev after v11.0.0)
IDEAS: branch issue1343_BoptestMultizoneOffice 172e272535e22b3af4c6ef001ecb61d307b81c24 (dev after 3.0.0)
Emulator: icupeiro/project1-boptest model commit fea7a9d96623240b5d038f5e9707b4be2d00c9fe

(1) Dymola/OCT Compilation

OCT fails compilation with errors:

Error at line 25, column 36, in file '/home/dhbubu20/git/ibpsa/project1-boptest-iago/project1-boptest/testcases/multizone_office_simple_hydronic/models/BuildingEmulators/Components/IdealProduction.mo':
  The component TSetIn is conditional: Access of conditional components is only valid in connect statements

Error at line 27, column 62, in file '/home/dhbubu20/git/ibpsa/project1-boptest-iago/project1-boptest/testcases/multizone_office_simple_hydronic/models/BuildingEmulators/Components/IdealProduction.mo':
  The component TSetIn is conditional: Access of conditional components is only valid in connect statements

Error at line 36, column 5, in file '/home/dhbubu20/git/ibpsa/project1-boptest-iago/project1-boptest/testcases/multizone_office_simple_hydronic/models/BuildingEmulators/Components/IdealProduction.mo':
  The component TSet is conditional: Access of conditional components is only valid in connect statements

Error at line 36, column 10, in file '/home/dhbubu20/git/ibpsa/project1-boptest-iago/project1-boptest/testcases/multizone_office_simple_hydronic/models/BuildingEmulators/Components/IdealProduction.mo':
  The component TSetIn is conditional: Access of conditional components is only valid in connect statements

Error at line 38, column 9, in file '/home/dhbubu20/git/ibpsa/project1-boptest-iago/project1-boptest/testcases/multizone_office_simple_hydronic/models/BuildingEmulators/Components/IdealProduction.mo':
  The component TSet is conditional: Access of conditional components is only valid in connect statements

Error at line 187, column 3, in file '/home/dhbubu20/git/ideas/IDEAS/IDEAS/Buildings/Components/Interfaces/RectangularZoneTemplateInterface.mo':
  The component mSenFac is declared multiple times and differs from other declaration(s) with the same name:
    they have min attribute expressions with different values.
  This difference was found when comparing the components declared:
    in  IDEAS.Buildings.Components.Interfaces.PartialZone, inherited into IDEAS.Buildings.Components.Interfaces.RectangularZoneTemplateInterface, then IDEAS.Buildings.Components.RectangularZoneTemplate
    and IDEAS.Buildings.Components.Interfaces.RectangularZoneTemplateInterface, inherited into IDEAS.Buildings.Components.RectangularZoneTemplate

The error with IDEAS.Buildings.Components.RectangularZoneTemplate is aiming to be fixed in open-ideas/IDEAS#1344. The errors with TSet and TSetIn are related to open-ideas/IDEAS#1343 (comment) and open-ideas/IDEAS#1343 (comment), which were needed for compilation in Dymola. Reverting those changes might fix the compilation for OCT. To try.

(2) Dymola/OM Results

I see a problem where the simulation results for Dymola and OM do not agree. Here are results for the first 10 days of simulation (I get the same results respectively in each tool whether I use cvode or euler with a timestep of 15s). In OM, the temperature for zone 2 is not meeting setpoint. I haven't done further diagnostics at this point.

Dymola

OM

[dhblum]

Update here. Per here, the issue with RectangularZoneTemplateInterface should be resolved in OCT if use updated IDEAS branch with open-ideas/IDEAS@54c2464. I also reverted the Emulator commit back to icupeiro@81decbb, before any conditional input refactoring.

These two things enables OCT to compile OK and simulate OK for the first 10 days. However, a yet third trajectory (below) which doesn't match OM nor Dymola shown above. @icupeiro were any other changes made between icupeiro@81decbb and icupeiro@fea7a9d that would cause a new trajectory?

@jelgerjansen FYI

[icupeiro]

Hi @dhblum ,

Yes, you skipped this commit

It includes changes in the BMS to comply with the HP maximum supply temperatures, from 70degC (previously, a gas boiler), to a maximum of 50degC

Regarding the difference in results, the culprit is an AND block that activates the heating pump of the south zone depending on the weekday and holiday calendars. For some reason works in the north zone, but not in the south zone. See below

North zone

South zone

)

I solved it by changing the formulation from a connect statement to a simple equality

New (corrected) results look in compliance with Dymola

Why is this happening? Honestly I have no idea, but I am always suspicious of the quality of OpenModelica solvers

Before doing any further commits (including the connection to equation change), can we agree on the tooling? Personally I would go for a pragmatic approach and disregard Dymola (their FMUs are not free of license). I would also suggest to do the testing with the FMU itself, which is the file that BOPTEST will use. However (correct me if I am wrong because I am not 100% sure) I think the FMU packs the solvers from the tool itself, so deciding to compile either with OM or OCT is important here.

Despite it may have lower quality with the solvers, I prefer to go with OM just for the reason that is freely available for everyone, which for me is the strongest point when trying to outreach and aim to have an open-source tool such as BOPTEST

[dhblum]

Thanks @icupeiro. I've done more thinking and testing here.

1. Regarding tooling, we need to consider open-source options but also tool capabilities. I prefer OM too, but OM fails to export the model as an FMU. Furthermore, OM simulates different results than Dymola and OCT, which produce the same results (see point 2. below). Seeing as OCT agrees with Dymola, and that OCT can produce a license-free FMU, I might prefer an OCT-compiled FMU for the time being, until OM is sufficiently capable.

2. Regarding the results comparison I mention in 1, I did the following tests:

• OS: Ubuntu 20.04
• Buildings: branch master (commit 9c5d5286b0ec2c125a693c900f8274a0b9140046)
• IDEAS: branch BOPTEST (commit 7bb2772a30e7c4b30e55f777567c99fe1b247e9b)
• Dymola: v2024x, Test Case branch issue465_multizone_office_simple_hydronic (commit fea7a9d), cvode w/ tol=1e-6 & dassl w/ tol=1e-6
• OCT: v1.43, Test Case branch issue465_multizone_office_simple_hydronic (commit 81decbb) + changes for heat pump temps implemented in this commit, cvode w/ tol=1e-6
• OM: v1.22.1 & v1.23.0~dev-244-g94d196d, Test Case branch issue465_multizone_office_simple_hydronic (commit 81decbb) + changes for heat pump temps implemented in this commit + changes for connect statements mentioned in this comment, cvode w/ tol=1e-6 & euler w/ step=15s & dassl w/ tol 1e-6
• Note I've got the test case changes for OCT and OM committed to branches locally. Can push to fork if you like.

OCT vs Dymola (Match)

OCT vs OM (OM Drifts)

[icupeiro]

Hey @dhblum ,

I agree to use OCT as the compiler. However, already from the start of the year we do not have a license anymore at dnergy, which can make testing an iterative between us that can lead to further delays. I do not know if sharing a license for a few days would be an option from your side. We can also set up a meeting and sit down together to finish up the emulator. Let me know if any of this options work for you or you have further suggestions!

[dhblum]

@icupeiro Is there more modeling work on the emulator you intended to do, other than maybe a final review? The heat pump's been implemented which I thought was the main thing.

[dhblum]

@icupeiro Here's what I propose:

1. I push my local version of your fork branch back to your fork, which compiles the model ok with OCT 1.43. I actually just tried but I need you to give me permissions to push to your fork, if that's ok.
2. I replace the PR Issue465 multizone office simple hydronic #469 with a new one that merges my new branch to a staging branch ibpsa:issue465_multizone_office_simple_hydronic.
3. I work on the staging branch to make sure unit tests are all organized and ultimately push the wrapped.fmu. I also read through the documentation and have a couple comments I'm hoping you could help address in parallel (I'll comment on the PR and you can make a PR to the staging branch with a few changes).
4. Once things are settled, final review and any last things, and then voila.

Let me know what you think or any other things.

[icupeiro]

hey @dhblum sorry for the delay I was on vacation

Sounds good! I think I've sent you an invite!

[dhblum]

@icupeiro Yeup got it thanks!! Welcome back.

[dhblum]

Hey @icupeiro I hate to delay this further, but I was reviewing the simulation results from this test case again and noticed that there is simultaneous heating and cooling in the mornings every day, when I'm not sure it makes sense to have it. For example, see the screenshot below for the summer case where I can't imagine heating being needed, although similar happens in winter with cooling power being consumed . Also, all the pumps turn on and use power regardless of whether heating or cooling is needed or not. Finally, the electric power for cooling is negative, which is an issue for KPI calculation. I think these things need to be addressed in some way.

The electric cooling power being negative is easy to address. But do you know why the simultaneous cooling and heating is happening?

[icupeiro]

@dhblum Let's go step by step. Regarding the distribution pumps of the AHU, the RBC describes in the documentation:

The AHUs are controlled based on the building occupancy.
Whenever the building is occupied, the AHUs supply and extract air at their nominal flow rate.
The baseline controller does not have any feedback from the CO<sub>2</sub> measurements in the zones.
The distribution pumps connected to the ventilation system are activated following the same schedule. 

The distribution pumps work as intended by the RBC. The RBC is inspired by actual controls of many buildings we control at dnergy, including their flaws. I agree the control is not optimal, but what we agreed in the past is to have a controller that represents the reality (including flaws to be addressed and having room for improvement), not optimize the baseline controller of the building.

Then, the AHU doesn't seem to be providing heating. It looks more like the pre-conditioning of the fan coil units. But I would need more information to debug this. If it is not too much work, a pandas parquet file with the read/write values of the model + weather data for the specific period would be useful for further data analysis

[dhblum]

@icupeiro I made the change regarding the absolute value on cooling power.

Regarding simultaneous heating and cooling, I found two things.

1: Schedule-based maximum activation of fan coil fan, cooling valve, and heating valve every morning

The control block "FcuInternal_ove_Control" shown below uses the activation signals for the circuits to control the fan speed, heating valve, and cooling valve during unoccupied times. In the morning, when the heating and cooling circuits are enabled by schedule, the fan, heating coil valve, and cooling coil valve are also controlled to maximum positions. So basically, every morning, the fan is on maximum speed, the cooling coil is providing maximum cooling, and then the heating coil is providing maximum heating (causing an even higher heating load since first overcoming the cooling being provided), until the occupied period starts at which point set point control takes over.

Meanwhile, there is a control block "FcuInternalControl" in the package which only implements the set point control.

If I use the FcuInternalControl (second plot below), rather than FcuInternal_ove_Control (first plot below), the simultaneous heating and cooling in the morning goes away, since even though both circuit pumps may be enabled, at least the valves and fan are still just being controlled to meet set point.

There are flaws in real buildings, but the maximum simultaneous heating and cooling every morning still seems hard to defend as a baseline control for boptest. I would suggest using FcuInternalControl if there are not other implications.

FcuInternal_ove_Control

FcuInternalControl

Plot of heating and cooling production power with FcuInternal_ove_Control (top) and FcuInternalControl (middle). Zone temperatures in each case plotted in the bottom.

[dhblum]

@icupeiro The second thing is:

2: Summertime heating in the AHU in afternoons

In the afternoons in the summer when there is no need for heating at the zone level, there is still heating production, due to heating in the AHU. I can't really explain the behavior of the temperature downstream of the heat recovery when the bypass is activated. It seems to become a constant value that is below the supply air temperature set point (thus requiring heating), when I'd expect it to equal the outside air temperature? See the figure below. I can check if this is a tool thing with solving the equations or I'm misunderstanding the design and operation intent, but thought I'd also see if you notice(d) anything odd here.

System Diagram with Temperature of Interest

Plot of Performance

[dhblum]

I've made progress on 2: Summertime heating in the AHU in afternoons. It seems the component BuildingEmulators.Components.AirHandlingUnit.junRec has the parameter portFlowDirection_3 set incorrectly to Modelica.Fluid.Types.PortFlowDirection.Entering where it should be Modelica.Fluid.Types.PortFlowDirection.Leaving. Then the temperature of the flow is calculated correctly when leaving the component when the bypass is enabled. See the results below when correcting this, which look correct with respect to recirculation air temperature when bypass is enabled, compared to the results in my previous comment.

As a result, there is less simultaneous heating and cooling in the afternoons. There is still some though, due to the control in the AHU opening both the heating coil and cooling to meet the supply air temperature set point. It seems the enable/disable for using only one or the other at a time is faulty.

[dhblum]

With updates from #654 and compiling and simulating with OCT 1.51.6, the plots for Day 185 - 190 now look good. Seems that Problems 1 and 2 described above are solved:

[dhblum]

Closed by #619.