Startup Events

[DeadParrot]

Some of the Buildings models, such as ASHRAE2006, have "zero-crossing" events at the simulation start time of the type that the event indicators starts at zero and moves away. With traditional solvers these crossings will be detected at a time just after startup but QSS currently only considers predicted crossing events at future times so these "crossings" won't be detected (unless numerical differentiation error pushes the predicted crossing to a time after startup).

If QSS must handle such models (rather than requiring that they be reformulated to avoid such startup "crossings") a robust mechanism must be added both to accept "move away from zero" as "crossings" and to check for such crossings at startup. Numerical differentiation error could still place such crossing events before startup, in which case a tolerance would be needed to allow it to accept those as startup crossings.

[DeadParrot]

Versions

The issue was observed with these component versions (may occur with others):

Component	Version	Date
OCT	OCT-r23206_JM-r14295	2021/05
Buildings	9c37781	2021/05/04
QSS	e4a0f62	2021/06/08

Build

Build the FMU with bld from the OCT directory as described in the Status page.

The dependencies can be examined in the modelDescription.xml file.

Run

Run the models with PyFMI or QSS from a console configured as described in the Status page.

PyFMI: Use run under the model OCT directories to generate the CVode simulation.

QSS: Use run under the model QSS directory in a method subdirectory such as QSS2.

[mwetter]

@DeadParrot : I think this can be closed, as the model has been corrected through lbl-srg/modelica-buildings#2571

[DeadParrot]

@mwetter I also see what look like startup time events in TwoFloor_TwoZone and this could also be present in other models.

We should decide if we are considering startup time events as disallowed/bugs in the model or if QSS needs to add support for them. The problem with making them disallowed is that QSS can't currently detect them so results will differ from other solvers. It may be as much effort to have QSS detect them as to handle them: I could make this an Issue to be addressed in QSS.

[mwetter]

If it takes as much work to detect them as to handle them, then I think we should handle them in QSS.

(Note however that I don't see start up events anymore in TwoFloor_TwoZone. This should have disappeared with the above commit in the Buildings library. The first event during simulation is at t=67:

Model: Buildings.Examples.ScalableBenchmarks.BuildingVAV.Examples.TwoFloor_TwoZone
Integration started at 0 using integration method:
cvode from sundials

Expression controlBus[1].TRooMin+modeSelector[1].delTRooOnOff/2 > modeSelector[1].TRooSetHeaOcc became false ( (controlBus[1].TRooMin+modeSelector[1].delTRooOnOff/2)-(modeSelector[1].TRooSetHeaOcc) = -5.68434e-14 )
Iterating to find consistent restart conditions.
      during event at Time :  67.88847917953144

)

[DeadParrot]

I added a QSS issue for looking at detecting and/or supporting startup time events. Since this is now avoided in the current Buildings models this is something we can probably make a lower priority.

[DeadParrot]

Since this appears to be eliminated for the Buildings models in this repository and should be handled by QSS in the future I will close this issue.