EnergyPlus emits a warning at the end of the simulation

[mwetter]

EnergyPlus seems to emit an empty warning message when it finishes the simulation. In Dymola, this looks like:

When changing

diff --git a/Buildings/Resources/src/ThermalZones/EnergyPlus/C-Sources/BuildingInstantiate.c b/Buildings/Resources/src/ThermalZones/EnergyPlus/C-Sources/BuildingInstantiate.c
index 1a541c69e2..b3f5c731a0 100644
--- a/Buildings/Resources/src/ThermalZones/EnergyPlus/C-Sources/BuildingInstantiate.c
+++ b/Buildings/Resources/src/ThermalZones/EnergyPlus/C-Sources/BuildingInstantiate.c
@@ -652,7 +652,7 @@ void spawnLogger(
 {
   /* EnergyPlus has for category always "EnergyPlus message", so we don't report this here */
   int len;
-  const char* signature = "%.3f %s: %s from EnergyPlus: %s\n";
+  const char* signature = "%.3f %s: %s from EnergyPlus: %s -- end of msg.\n";
   char msg[SPAWN_LOGGER_BUFFER_LENGTH];

   FMUBuilding* bui = (FMUBuilding*)env;

and running

rm -rf build && mkdir build && cd build &&   cmake ../ && cmake --build . --target install &&   cd .. && rm -rf build
jm_ipython.sh jmodelica.py Buildings.ThermalZones.EnergyPlus.Examples.SingleFamilyHouse.AirHeating

the log file of OCT is:

FMIL: module = Model, log level = 3: [WARNING][FMU status:Warning]       <ModelicaMessage category="warning"><value name="msg">"3600.000 AirHeating.building: Warning from EnergyPlus: Relative Humidity being reset to 100.0% -- end of msg.&#10;"</value></ModelicaMessage>
FMIL: module = Model, log level = 3: [WARNING][FMU status:Warning] <ModelicaMessage category="warning"><value name="msg">"86400.000 AirHeating.building: Warning from EnergyPlus:  ** Warning ** Calculated Relative Humidity out of range (PsyRhFnTdbWPb) -- end of msg.&#10;"</value></ModelicaMessage>
FMIL: module = Model, log level = 3: [WARNING][FMU status:Warning] <ModelicaMessage category="warning"><value name="msg">"86400.000 AirHeating.building: Warning from EnergyPlus:  -- end of msg.&#10;"</value></ModelicaMessage>

The entry Warning from EnergyPlus: -- end of msg looks like an empty message with log level set to warning being sent from EnergyPlus to Modelica.

Tested with Buildings Library master at 8fe3dc12d718a244287d4c8e51bc5be3fa0c2218

[mwetter]

@kbenne : The new version fails on my system to load the dll, probably because its name is changed dynamically. The error is

0.000 AirHeating.building: Loading dllfmu.
Error: The following error was detected at time: 0
Could not create the DLL loading mechanism (C-API) for /home/mwetter/proj/ldrd/bie/modeling/github/lbl-srg/modelica-buildings/Buildings/spawn-AirHeating/EnergyPlus.fmu.
The stack of functions is:
Buildings.ThermalZones.EnergyPlus_9_6_0.BaseClasses.initialize
Buildings.ThermalZones.EnergyPlus_9_6_0.BaseClasses.initialize(
zon.fmuZon.adapter, 
building.isSynchronized)

and the place where it occurs is at https://github.com/lbl-srg/modelica-buildings/blob/6441a35dc56d45a3f5fece5cefcbe4c3ad652e17/Buildings/Resources/src/ThermalZones/EnergyPlus_9_6_0/C-Sources/BuildingInstantiate.c#L754

Is there anything that needs to be changed? I noticed your tests work, and wonder if your tests pick up ./Resources/bin/spawn-0.3.0-ee6614d522/linux64/lib/epfmi.so rather than ./spawn-AirHeating/binaries/epfmi_6002af9111e310af08e69ed00440e083.so.

To reproduce, run

git clone -b issue2863_spawn_ep_warning --single-branch git@github.com:lbl-srg/modelica-buildings.git
cd modelica-buildings/Buildings
Buildings.ThermalZones.EnergyPlus_9_6_0.Examples.SingleFamilyHouse.AirHeating  # gets the current binaries

and simulate for example Buildings.ThermalZones.EnergyPlus_9_6_0.Examples.SingleFamilyHouse.AirHeating

If simulated with OMEdit, I get

...
Generating fmuEPFMIPath: "/tmp/OpenModelica_mwetter/OMEdit/spawn-Buildings.ThermalZones.EnergyPlus_9_6_0.Examples.SingleFamilyHouse.AirHeating/EnergyPlus/binaries/epfmi_696abfa415b237a4b05f153888cb9830.so"

[FATAL][FMICAPI] Could not load the FMU binary: /tmp/OpenModelica_mwetter/OMEdit/spawn-Buildings.ThermalZones.EnergyPlus_9_6_0.Examples.SingleFamilyHouse.AirHeating/binaries/linux64/epfmi_696abfa415b237a4b05f153888cb9830.so: cannot open shared object file: No such file or directory

Note that it generates ...AirHeating/EnergyPlus/binaries/... but it tries to load ...AirHeating/binaries/linux64/...

The content is

$ tree /tmp/OpenModelica_mwetter/OMEdit/spawn-Buildings.ThermalZones.EnergyPlus_9_6_0.Examples.SingleFamilyHouse.AirHeating
/tmp/OpenModelica_mwetter/OMEdit/spawn-Buildings.ThermalZones.EnergyPlus_9_6_0.Examples.SingleFamilyHouse.AirHeating
├── binaries
│   ├── epfmi_696abfa415b237a4b05f153888cb9830.so
│   └── linux64
│       └── epfmi.so
├── EnergyPlus.fmu
├── eplusout
│   ├── eplusout.audit
│   ├── eplusout.bnd
│   ├── eplusout.dxf
│   ├── eplusout.edd
│   ├── eplusout.eio
│   ├── eplusout.end
│   ├── eplusout.err
│   ├── eplusout.eso
│   ├── eplusout.mdd
│   ├── eplusout.mtd
│   ├── eplusout.rdd
│   ├── eplusout.shd
│   ├── eplustbl.htm
│   └── SingleFamilyHouse_TwoSpeed_ZoneAirBalance.spawn.idf
├── modelDescription.xml
├── ModelicaBuildingsEnergyPlus.json
└── resources
    ├── Energy+.idd
    ├── model.spawn
    ├── SingleFamilyHouse_TwoSpeed_ZoneAirBalance.idf
    └── USA_IL_Chicago-OHare.Intl.AP.725300_TMY3.epw

[kbenne]

I simulated with Spawn but I can't replicate this. I especially don't understand how you ended up with two instances of the epfmi library in different locations. I think it would require two things to happen.

1. You have cruft from a previous simulation
2. The CI builds are misconfiguring the fmi platform at build time resulting in an empty string instead of "linux64". I use Modelon's cmake logic to configure the fmi platform https://github.com/NREL/Spawn/blob/develop/cmake/fmiplatform.cmake. The result of this gets compiled into the software and made available as a function that is used at runtime https://github.com/NREL/Spawn/blob/develop/util/config.cpp.in#L30.

When I use Spawn itself to run a simulation I get the following tree... (yes I don't advertise it but the Spawn cli does have primitive capability to drive a simulation spawn fmu --simulate Buildings_ThermalZones_EnergyPlus_9_6_0_Examples_SingleFamilyHouse_AirHeating.fmu).

➜  build git:(develop) ✗ tree spawn-AirHeating
spawn-AirHeating
├── binaries
│   └── linux64
│       └── epfmi_0c348c142d9526c29f8b995de81c2123.so
├── EnergyPlus.fmu
├── eplusout
│   ├── eplusout.audit
│   ├── eplusout.bnd
│   ├── eplusout.dxf
│   ├── eplusout.edd
│   ├── eplusout.eio
│   ├── eplusout.end
│   ├── eplusout.err
│   ├── eplusout.eso
│   ├── eplusout.mdd
│   ├── eplusout.mtd
│   ├── eplusout.rdd
│   ├── eplusout.shd
│   ├── eplustbl.htm
│   └── SingleFamilyHouse_TwoSpeed_ZoneAirBalance.spawn.idf
├── modelDescription.xml
├── ModelicaBuildingsEnergyPlus.json
└── resources
    ├── Energy+.idd
    ├── model.spawn
    ├── SingleFamilyHouse_TwoSpeed_ZoneAirBalance.idf
    └── USA_IL_Chicago-OHare.Intl.AP.725300_TMY3.epw

I have not tried to simulate with OMEdit as I don't have it setup in my environment, but that might be stage two triage. Before going there, I think there are a couple of other things.

1. On your end, double check that you don't have a preexisting spawn-AirHeating directory before the simulation starts.
2. As I was researching this issue, I noticed that the version of MBL that is pulled into Spawn and ultimately used for the automated tests is a bit out of date. Often it isn't too big of an issue when there is some lag, but you made a significant change to the MBL directory structure that incorporates the EnergyPlus version number, and that is notable. It is hard to predict all of the side effects of that change on the Spawn cli, but I spent the last couple of days making some adjustments to account for this change. https://github.com/NREL/Spawn/commit/f34ccbf6c4e90e2ebb11d255fca9f69bcb91027a

I recommend that I send you a new build that takes into account the new MBL structure, and have you test with that, making sure to start with a clean simulation directory if you haven't done that already. That will at least give us a solid basis to work from.

[mwetter]

@kbenne : yes, lets try with a new build. I will be away from my main PC tomorrow but should be able to test on Friday.

[kbenne]

Here it is https://gitlab.com/kylebenne/spawn/-/pipelines/526345985

[mwetter]

@kbenne : The cause of the failure is that EnergyPlus.fmu stores the *.so file in resources rather than in resources/linux64.

The following output was generated with 40a8c0a578b016f61278c308eef11ca402d7553d (branch issue2863_spawn_ep_warning), after running Buildings/Resources/src/ThermalZones/EnergyPlus_9_6_0/install.py (because I did not push the large binaries for this iteration) and then running Buildings.ThermalZones.EnergyPlus_9_6_0.Examples.SingleFamilyHouse.AirHeating in OMEdit.

Not sure yet what causes different structure in the EnergyPlus.fmu file compared to the master branch, which generates an fmu with binaries/linux64/epfmi.so

$ tree /tmp/OpenModelica_mwetter/OMEdit/
/tmp/OpenModelica_mwetter/OMEdit/
├── Buildings.ThermalZones.EnergyPlus_9_6_0.Examples.SingleFamilyHouse.AirHeating
│   ├── AirHeating
│   ├── AirHeating_info.json
│   ├── AirHeating_init.xml
│   ├── AirHeating.log
│   └── AirHeating_res.mat
├── DocumentationWidget.html
├── omeditcommands.mos
├── omeditcommunication.log
├── omeditoutput.txt
├── omscommunication.log
├── omslog.txt
└── spawn-Buildings.ThermalZones.EnergyPlus_9_6_0.Examples.SingleFamilyHouse.AirHeating
    ├── binaries
    │   └── epfmi_39f15677e212d8849707be17ca329507.so
    ├── EnergyPlus.fmu
    ├── modelDescription.xml
    ├── ModelicaBuildingsEnergyPlus.json
    └── resources
        ├── Energy+.idd
        ├── model.spawn
        ├── SingleFamilyHouse_TwoSpeed_ZoneAirBalance.idf
        └── USA_IL_Chicago-OHare.Intl.AP.725300_TMY3.epw

4 directories, 19 files
mwetter@srg-mw:~/prg/windows-virtualbox-shared/modelica-buildings/Buildings$ zipinfo /tmp/OpenModelica_mwetter/OMEdit/spawn-Buildings.ThermalZones.EnergyPlus_9_6_0.Examples.SingleFamilyHouse.AirHeating/EnergyPlus.fmu
Archive:  /tmp/OpenModelica_mwetter/OMEdit/spawn-Buildings.ThermalZones.EnergyPlus_9_6_0.Examples.SingleFamilyHouse.AirHeating/EnergyPlus.fmu
Zip file size: 65271891 bytes, number of entries: 8
-rw-rw-r--  6.3 unx     5163 b- stor 22-Apr-29 08:44 modelDescription.xml
drwxrwxrwx  6.3 unx        0 b- stor 22-Apr-29 08:44 binaries/
-rw-r--r--  6.3 unx 59246176 b- stor 22-Apr-29 08:44 binaries/epfmi_39f15677e212d8849707be17ca329507.so
drwxrwxrwx  6.3 unx        0 b- stor 22-Apr-29 08:44 resources/
-rw-rw-r--  6.3 unx    89792 b- stor 22-Apr-29 08:44 resources/SingleFamilyHouse_TwoSpeed_ZoneAirBalance.idf
-rw-rw-r--  6.3 unx  1640283 b- stor 22-Apr-29 08:44 resources/USA_IL_Chicago-OHare.Intl.AP.725300_TMY3.epw
-rw-r--r--  6.3 unx  4288807 b- stor 22-Apr-29 08:44 resources/Energy+.idd
-rw-rw-r--  6.3 unx      560 b- stor 22-Apr-29 08:44 resources/model.spawn
8 files, 65270781 bytes uncompressed, 65270781 bytes compressed:  0.0%

[kbenne]

@kbenne : The cause of the failure is that EnergyPlus.fmu stores the *.so file in resources rather than in resources/linux64.

You must mean binaries/linux64 not resources/linux64 right?

This makes a bit more sense. You must have had an old run causing you to see two instances of epfmi before. But why is the platform directory being omitted? I can't reproduce that. I do have a lead to track down though. I wonder if the CI builds are not configuring the platform correctly.

[mwetter]

@kbenne Sorry, I meant binaries/linux64/*.so inside the FMU to comply with the standard.

[kbenne]

The platform prefix has been used for a long time, but something on your build has apparently regressed. See the cmake logic from Modelon that I linked above. I recently rebuilt the Linux CI computer and I think that might be the source of the issue.

[kbenne]

Also. There are tests that capture this, but they don't run on the CI at the moment because I don't have a license for OCT on the CI so some tests are omitted.

[kbenne]

The other (very remote) possibility is that there is some difference related to OpenModelica, but I don't think that is likely. The platform tag gets configured at build time.

[mwetter]

The problem also occurs with Dymola and OCT.

[kbenne]

See the commit referenced above. It looks like it is unique to the "light" builds, and I think I have fixed it. The builds are still running now, but it looks ok on my development build.

[kbenne]

https://gitlab.com/kylebenne/spawn/-/pipelines/528183754

[mwetter]

@kbenne The build https://gitlab.com/kylebenne/spawn/-/pipelines/528183754 does not remove the warning reported at the very top of this issue on my system. Does it remove it on yours?

It does however fix https://github.com/lbl-srg/modelica-buildings/issues/2220 which will be closed through https://github.com/lbl-srg/modelica-buildings/pull/2984

[kbenne]

@mwetter I added a test in the commit referenced right above here. The tail of the output is...

Writing tabular output file results using HTML format.
EnergyPlus Run Time=00hr 00min  0.32sec
EnergyPlus Completed Successfully.
<ModelicaMessage category="warning"><value name="msg">"0.000 AirHeating.building: Info from EnergyPlus: Simulation Error Summary *************&##10;"</value></ModelicaMessage>
<ModelicaMessage category="warning"><value name="msg">"0.000 AirHeating.building: Info from EnergyPlus: There are 34 unused objects in input.&##10;"</value></ModelicaMessage>
<ModelicaMessage category="warning"><value name="msg">"0.000 AirHeating.building: Info from EnergyPlus: Use Output:Diagnostics,DisplayUnusedObjects; to see them.&##10;"</value></ModelicaMessage>
<ModelicaMessage category="warning"><value name="msg">"0.000 AirHeating.building: Info from EnergyPlus: There are 6 unused schedules in input.&##10;"</value></ModelicaMessage>
<ModelicaMessage category="warning"><value name="msg">"0.000 AirHeating.building: Info from EnergyPlus: Use Output:Diagnostics,DisplayUnusedSchedules; to see them.&##10;"</value></ModelicaMessage>
<ModelicaMessage category="warning"><value name="msg">"0.000 AirHeating.building: Info from EnergyPlus: EnergyPlus Warmup Error Summary. During Warmup: 0 Warning; 0 Severe Errors.&##10;"</value></ModelicaMessage>
<ModelicaMessage category="warning"><value name="msg">"0.000 AirHeating.building: Info from EnergyPlus: EnergyPlus Sizing Error Summary. During Sizing: 0 Warning; 0 Severe Errors.&##10;"</value></ModelicaMessage>
<ModelicaMessage category="warning"><value name="msg">"0.000 AirHeating.building: Info from EnergyPlus: EnergyPlus Completed Successfully-- 0 Warning; 0 Severe Errors; Elapsed Time=00hr 00min  0.32sec&##10;"</value></ModelicaMessage>
<ModelicaMessage category="warning"><value name="msg">"0.000 AirHeating.building: fmi2_import_destroy_dllfmu: destroying dll fmu.&##10;"</value></ModelicaMessage>
[VERBOSE][FMILIB] Releasing FMU CAPI interface
[VERBOSE][FMICAPI] Successfully unloaded FMU binary
[VERBOSE][FMILIB] Releasing allocated library resources

This is with the Modelica log and the building log turned up to max power. I do not see the final "WARNINGS have been issued" message. Do you believe that this is generated by Dymola? I'm inclined to think so. Since I cleaned up all of the "real" warnings, what remains from EnergyPlus is Info.

namespace EnergyPlus {

enum class Error : int
{
    Continue = 0,
    Info = 1,
    Warning = 2,
    Severe = 3,
    Fatal = 4
};

} // namespace EnergyPlus

One possibility is that I could filter out level 1, Info, messages and prevent them from going out to the Modelica logger. They would still go to the EnergyPlus eplusout.err file so they wouldn't be entirely lost. Also, I think we would want to keep level 0, Continue because those are normally the continuation of level 2 and above. I have a hunch that if no messages, including info are passed to Modelica, then we won't see the final message.

[mwetter]

@kbenne : I still get the EnergyPlus Completed Successfully with a warning symbol in Dymola with the latest Buildings master. My suspicion is that this makes Dymola think there was a warning. I could look into it next week and try to suppress the propagation of the message when I see this string.

[kbenne]

Yeah. That's what I'm saying. I know you still see EnergyPlus Completed Successfully. That is considered a level Info "error" message by EnergyPlus. What I'm contemplating is do we want to filter out info level messages so that the Modelica error logger doesn't see them. If I do that you certainly won't see message such as EnergyPlus Completed Successfully.

[mwetter]

Filtering these information out would be good. I always felt this output to be noise that distracts from other messages users should pay attention too.

[kbenne]

Alrighty. It shall be then.

[mwetter]

@kbenne With Spawn 0.3.0-0fa49be497, Dymola still shows the message at the very top of this issue. It is however not in dslog.txt. In OCT, the message is not show, hence I think it won't get through the logging, but maybe it is a console output of EnergyPlus that Dymola pipes to its gui?

With OMEdit, I get

[kbenne]

@mwetter I think you are on the right track. You are seeing EnergyPlus messages that are sent to stdout. This is different from the messages that EnergyPlus sends to eplusout.err file via the EnergyPlus logging system. The Modelica/FMI logger callback function should receive all of the content from the eplusout.err logging system minus that Info level messages that I am now filtering. The EnergyPlus stdout messages should not show up in the Modelica log, however if the Modelica log is itself logging to stdout it might be difficult to differentiate.

It would be difficult for me to prevent the EnergyPlus messages that it is sending to stdout.

[mwetter]

I will close this issue as it sounds like suppressing the EnergyPlus stdout is too hard. Deleted branch issue2863_spawn_ep_warning.

[kbenne]

Not impossible, but it would require us to branch from the mainline of EnergyPlus to make the changes. I've been working to move Spawn in the other direction such that it uses standard EnergyPlus builds.

[kbenne]

Please do make sure that the actual log channel is clean. That we can control with filtering such as what I just implemented to weed out empty log messages as well as Info level messages. Based on the models that I've looked at, it is indeed clean.

[mwetter]

This messages do not get through spawnLogger, otherwise they would start with the signature:

  const char* signature = "%.3f %s: %s from EnergyPlus: %s\n";

It looks like the Modelica tool pipes all stdout to its console.

[kbenne]

ah. Ugh. Sorry about that.