@mwetter here are a couple of things to discuss.

1. We have defined variables sizZon.tCoo and sizZon.tHea. I'd like us to think about what the reported time represents. Presumably it should be elapsed seconds from 00:00 on January 1st, but the question is from what date and/or weather period. As it is now, there can be many design days and the EnergyPlus sizing algorithm will find the peak loads among those days. Do we need a mechanism to indicate which design day resolved as the greatest load. Without something like this the reported time will lack important context. A different route might be to contstrain the sizing algorithm to the weather file only, but I think that might be limiting.
2. We have some question marks in the current design documentation related to outdoor air. I think we can support the EnergyPlus design specification objects, but in order for it to mean anything, I would need to add a mechanism such as Ideal Air Loads to actually deliver air.

Regarding 1, the time should be seconds since 0:00 on January 1, or the start of the day if a design day causes the highest load. The associated outdoor conditions are to be reported as shown in the table in section https://lbl-srg.github.io/soep/softwareArchitecture.html#coupling-of-the-envelope-model
This way all necessary information for a complete sizing is known (as far as I can tell).

Regarding 2, zones should have no outdoor air exchange during the sizing; this needs to be added on the Modelica side (as the HVAC model determines whether for example a zone is over-pressurized and has no infiltration).

For item 1, I believe the, "or the start of the day if a design day causes the highest load" answers my question. Though, I'm still unsure about how this information will be used and if we're giving what is needed. How would someone know if the reported time was offset from January 1st (presumable because design load was driven from the weather file) or alternatively the reported time is offset from one of the design days? I don't see how a client would know, and if they don't then how is the information useful?

Another nuance about item 1, is that when sizing from the weather file using SizingPeriod:WeatherFileDays, you still prescribe a specific day in the weather file as the sizing period. Considering this, would we perhaps want to report time from the start of the day, even if that day is one of the days in the weather file? That would bring some consistency to how we are proposing to report time in the case of RunPeriod:DesignDay.

On item 2. It seems like we are going to report sizes that are too low if we do not include some kind of ventilation in the sizing run. Is the idea that additional capacity will be added on the Modelica side on top of the load reported by EnergyPlus?

@mwetter

Here is the Linux build that contains all of the new autosizing variables. We can discuss the details at tomorrow's meeting.

https://spawn.s3.us-east-1.amazonaws.com/custom/Spawn-light-0.6.0-5297abe3fb-Linux.tar.gz

@kbenne : With this binary and the code at 33eaa4d I get a segmentation fault. The output below is from running Buildings.ThermalZones.EnergyPlus_24_2_0.Examples.SingleFamilyHouse.Unconditioned in OMEdit, after setting
logLevel = Buildings.ThermalZones.EnergyPlus_24_2_0.Types.LogLevels.Debug in the instance building.
Note that this is an old example that does not invoke the autosizing.

The suspicious lines are

/tmp/OpenModelica_mwetter/OMEdit/spawn-Unconditioned/binaries/linux64/epfmi_0d9ac28350d8851ecc3a6a4ea669661d.so(_ZN5spawn10energyplus11zone_sizing9MinCoolOAERKN10EnergyPlus14EnergyPlusDataEi+0x20)[0x7f394d15b310] 
/tmp/OpenModelica_mwetter/OMEdit/spawn-Unconditioned/binaries/linux64/epfmi_0d9ac28350d8851ecc3a6a4ea669661d.so(_ZN5spawn8variable4zone11MOutCooFlow6UpdateERN10EnergyPlus14EnergyPlusDataE+0x30)[0x7f394d125450] 
/tmp/OpenModelica_mwetter/OMEdit/spawn-Unconditioned/binaries/linux64/epfmi_0d9ac28350d8851ecc3a6a4ea669661d.so(_ZN5spawn8variable9Variables16UpdateParametersERN10EnergyPlus14EnergyPlusDataE+0x30)[0x7f394d125d40] 

0.000 Unconditioned.building: Calling fmi2_import_setup_experiment: Setting up experiment building at 0x17bfcf90 with startTime = 0.000000. 
0.000 Unconditioned.building: Returned from setting up experiment with status OK. 
0.000 Unconditioned.building: fmi2_import_enter_initialization_mode: Enter initialization mode of FMU with name /tmp/OpenModelica_mwetter/OMEdit/spawn-Unconditioned/EnergyPlus.fmu. 
0.000 Unconditioned.building: Switching to mode initialization 
0.000 Unconditioned.zon: Getting parameters from EnergyPlus, bui at 0x17bfcf90, Spawn object at 0x17c01200, parameter at 0x17bfdd80. 
0.000 Unconditioned.zon: Getting real variables from EnergyPlus, mode = initialization. 
Process crashed
EnergyPlus Starting EnergyPlus, Version 24.2.0-5297abe3fb, YMD=2025.01.08 09:40 Adjusting Air System Sizing Adjusting Standard 62.1 Ventilation Sizing Initializing Simulation Reporting Surfaces Beginning Primary Simulation Initializing New Environment Parameters Warming up {1} Warming up {2} Warming up {3} Warming up {4} Warming up {5} Warming up {6} Warming up {7} Warming up {8} Warming up {9} Warming up {10} Starting Simulation at 01/01/2006 for SPAWN-RUNPERIOD 
[VERBOSE][FMILIB] Allocating FMIL context [VERBOSE][FMILIB] Detect
ing FMI standard version [VERBOSE][FMIZIP] Unpacking FMU into /tmp/OpenModelica_mwetter/OMEdit/spawn-Unconditioned [VERBOSE][FMIXML] Parsing XML to detect FMI standard version [VERBOSE][FMIXML] XML specifies FMI 2.0 [INFO][FMILIB] XML specifies FMI standard version 2.0 [VERBOSE][FMILIB] Parsing model description XML [VERBOSE][FMI2XML] Parsing XML element fmiModelDescription [VERBOSE][FMI2XML] Parsing XML element ModelExchange [VERBOSE][FMI2XML] Parsing XML element UnitDefinitions [VERBOSE][FMI2XML] Parsing XML element LogCategories [VERBOSE][FMI2XML] Parsing XML element ModelVariables [VERBOSE][FMI2XML] Building alias index [VERBOSE][FMI2XML] Parsing XML element ModelStructure [VERBOSE][FMILIB] Parsing finished successfully [INFO][FMILIB] Loading 'linux64' binary with 'default' platform types [VERBOSE][FMICAPI] Loaded FMU binary from /tmp/OpenModelica_mwetter/OMEdit/spawn-Unconditioned/binaries/linux64/epfmi_0d9ac28350d8851ecc3a6a4ea669661d.so [VERBOSE][FMICAPI] Loading functions for the model exchange interface [VERBOSE][FMILIB] Successfully loaded all the interface functions [VERBOSE][FMICAPI] Calling fmi2SetupExperiment [VERBOSE][FMICAPI] Calling fmi2EnterInitializationMode  Limited backtrace at point of segmentation fault /lib/x86_64-linux-gnu/libpthread.so.0(+0x14420)[0x7f3959c6b420] 
/tmp/OpenModelica_mwetter/OMEdit/spawn-Unconditioned/binaries/linux64/epfmi_0d9ac28350d8851ecc3a6a4ea669661d.so(_ZN5spawn10energyplus11zone_sizing9MinCoolOAERKN10EnergyPlus14EnergyPlusDataEi+0x20)[0x7f394d15b310] 
/tmp/OpenModelica_mwetter/OMEdit/spawn-Unconditioned/binaries/linux64/epfmi_0d9ac28350d8851ecc3a6a4ea669661d.so(_ZN5spawn8variable4zone11MOutCooFlow6UpdateERN10EnergyPlus14EnergyPlusDataE+0x30)[0x7f394d125450] 
/tmp/OpenModelica_mwetter/OMEdit/spawn-Unconditioned/binaries/linux64/epfmi_0d9ac28350d8851ecc3a6a4ea669661d.so(_ZN5spawn8variable9Variables16UpdateParametersERN10EnergyPlus14EnergyPlusDataE+0x30)[0x7f394d125d40] 
/tmp/OpenModelica_mwetter/OMEdit/spawn-Unconditioned/binaries/linux64/epfmi_0d9ac28350d8851ecc3a6a4ea669661d.so(_ZN5spawn5Spawn5startEv+0x527)[0x7f394d120527] /tmp/OpenModelica_mwetter/OMEdit/spawn-Unconditioned/binaries/linux64/epfmi_0d9ac28350d8851ecc3a6a4ea669661d.so(fmi2GetReal+0x27)[0x7f394d100697] 
/home/mwetter/test/modelica-buildings-dev/Buildings/Resources/Library/linux64/libModelicaBuildingsEnergyPlus_24_2_0.so(getVariables+0x3f)[0x7f395ae4779f] 
/home/mwetter/test/modelica-buildings-dev/Buildings/Resources/Library/linux64/libModelicaBuildingsEnergyPlus_24_2_0.so(initialize_Spawn_EnergyPlus_24_2_0+0xaa)[0x7f395ae4984a] 
/tmp/OpenModelica_mwetter/OMEdit/Buildings.ThermalZones.EnergyPlus_24_2_0.Examples.SingleFamilyHouse.Unconditioned/Unconditioned(omc_Buildings_ThermalZones_EnergyPlus__24__2__0_BaseClasses_initialize+0x15)[0x41cd75] 
/tmp/OpenModelica_mwetter/OMEdit/Buildings.ThermalZones.EnergyPlus_24_2_0.Examples.SingleFamilyHouse.Unconditioned/Unconditioned(residualFunc140+0xa5)[0x41ebc4] /usr/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so(updateInnerEquation+0xbf)[0x7f395a8e6daf] /usr/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so(solve_nonlinear_system+0x17b)[0x7f395a8e72e5] 
/tmp/OpenModelica_mwetter/OMEdit/Buildings.ThermalZones.EnergyPlus_24_2_0.Examples.SingleFamilyHouse.Unconditioned/Unconditioned(Unconditioned_eqFunction_140+0x8a)[0x421968] 
/tmp/OpenModelica_mwetter/OMEdit/Buildings.ThermalZones.EnergyPlus_24_2_0.Examples.SingleFamilyHouse.Unconditioned/Unconditioned(Unconditioned_functionInitialEquations_0+0x748)[0x424478] 
/tmp/OpenModelica_mwetter/OMEdit/Buildings.ThermalZones.EnergyPlus_24_2_0.Examples.SingleFamilyHouse.Unconditioned/Unconditioned(Unconditioned_functionInitialEquations+0x14)[0x424847] 

Dymola also crashes. Can you reproduce this?

The json file is below.

ModelicaBuildingsEnergyPlus.json

Hi @mwetter. I see it now. Yes there is an exception in my test, but it is caught and the test continues so I didn't notice it. I think I will have a fix tomorrow.

Update: I owe a comment on this as I was expecting a fix 3 days ago. Sadly this is not an update that comes with a new binary, but (maybe) getting there. The cause of your (@mwetter) particular issue was easy for me to fix and I have, which was that I did not properly account for models that were not fully setup for autosizing. I was expecting certain state to be populated that is not when autosizing is not on.

But along the way I've found more issues. Specifically, I'm realizing that I need more of the EnergyPlus model than I realized for this to work properly. Specifically, I need to keep thermostats and zone HVAC connections, even if there is no HVAC. I miight even need some kind of minimal (ideal air loads) system to get the sizing algo to work properly. I suspected this early on during the conceptualization of this feature, but I thought I had avoided these complications, which turns out to not be true. I'm working on sorting it out and will have more to say soon.

@kbenne : Thanks, appreciate the update. No problem if it takes a bit longer.

@mwetter can you please take a look at this build?

https://spawn.s3.us-east-1.amazonaws.com/custom/Spawn-light-0.6.0-47c6610ff8-Linux.tar.gz

Key changes are:

• Avoid trying to access certain state variables if a sizing run has not been done. This will fix your original issue.
• But the big thing is, Insert an Ideal Air System. The sizing algorithm needs this to work properly, so I have created a function to insert an ideal system as part of the process that we already do to prepare the idf for a Spawn simulation. There is an assumption that key related system input objects are in place, including the design OA spec, Sizing:Zone, and ZoneControl:Thermostat. We might want to discuss how we communicate the requirements to end users.

• In https://lbl-srg.github.io/soep/softwareArchitecture.html and other documentation, state that *SpaceList is not supported, and it will stop the translation with an error.
• Currently, and ideal air system is added to idf if autosizing is enabled. @kbenne to see if this can be in idf but disabled with an availability schedule so that a proper E+ simulation would not operate the system.

@kbenne : I still get a segmenation fault by running the same setup and example as in #3866 (comment).

The log file of OpenModelica is attached.

This is with commit 1a58aee

Does this run on your installation?

Unconditioned.log

Just for our due diligence, can you confirm the md5 for the package you are using is fdae56450af5d088e781bc99bff94a43 Spawn-light-0.6.0-47c6610ff8-Linux.tar.gz

I have good test coverage that runs the underlying idf, SingleFamilyHouse_TwoSpeed_ZoneAirBalance/SingleFamilyHouse_TwoSpeed_ZoneAirBalance.idf, as an FMU, outside of the context of Modelica, but I don't have testing with this running with Modelica in the loop. Perhaps the issue only shows up in Modelica, but I'm still investigating. If you can double check that the md5 matches and that you don't have a stale build that would be good.

I just rerun it with a clean clone, verified that I have the same hash, and get the same error as reported above.

Perhaps you can send me the spawn json file that is involved? The paths won't be portable, but I think I will get useful information from it.

See attached.
ModelicaBuildingsEnergyPlus.json

I've determined that the issue is related to the grouping of zones via the hvacZones property. There are certain assumptions I made about how the model is setup that are probably not guaranteed. If you remove the hvacZones your model will probably work. I am trying to implement a fix now.