OM Simulation Error with IDEAS.Examples.IBPSA.SingleZoneResidentialHydronicHeatPump

[dhblum]

I'm hoping this helps with in getting IDEAS supported by OM, and will maybe show up in tests started with #1254.

OM Version: 1.20.0~dev-13-g85ae74c, Nightly build Ubuntu 18.04 x64
MSL Version: 4.0.0 distributed as OMEdit system library
IDEAS Version: master commit ad502f4
Model Path: IDEAS.Examples.IBPSA.SingleZoneResidentialHydronicHeatPump

In OMEdit, simulation error with both Dassl and Euler (tol 1e-6, start time = 0, final time = 864000) right after a seemingly successful initialization:

Process crashed Simulation process failed. Exited with code 11.
/tmp/OpenModelica_dhbubu18/OMEdit/IDEAS.Examples.IBPSA.SingleZoneResidentialHydronicHeatPump/SingleZoneResidentialHydronicHeatPump -port=45317 -logFormat=xmltcp -override=startTime=0,stopTime=864000,stepSize=30,tolerance=1e-6,solver=dassl,outputFormat=mat,variableFilter=.* -r=/tmp/OpenModelica_dhbubu18/OMEdit/IDEAS.Examples.IBPSA.SingleZoneResidentialHydronicHeatPump/SingleZoneResidentialHydronicHeatPump_res.mat -w -lv=LOG_STATS -inputPath=/tmp/OpenModelica_dhbubu18/OMEdit/IDEAS.Examples.IBPSA.SingleZoneResidentialHydronicHeatPump -outputPath=/tmp/OpenModelica_dhbubu18/OMEdit/IDEAS.Examples.IBPSA.SingleZoneResidentialHydronicHeatPump
The following assertion has been violated during initialization at time 0.000000
pum.nominalValuesDefineDefaultPressureCurve
*** Warning: You are using a flow or pressure controlled mover with the
             default pressure curve.
             This leads to approximate calculations of the electrical power
             consumption. Add the correct pressure curve in the record per
             to obtain an accurate computation.
             Setting nominalValuesDefineDefaultPressureCurve=true will suppress this warning.
The following assertion has been violated during initialization at time 0.000000
fan.nominalValuesDefineDefaultPressureCurve
*** Warning: You are using a flow or pressure controlled mover with the
             default pressure curve.
             This leads to approximate calculations of the electrical power
             consumption. Add the correct pressure curve in the record per
             to obtain an accurate computation.
             Setting nominalValuesDefineDefaultPressureCurve=true will suppress this warning.
The initialization finished successfully with 3 homotopy steps.
division by zero at time 0, (a=-0) / (b=-0), where divisor b expression is: -0.0
Process crashed

[dhblum]

And debug information from OMEdit (pretty useful, although I can't nail down the problem anymore):

[Mathadon]

@dhblum I pushed a potential fix. A temperature sensor was connected backwards. If this fixes the problem it indicates a bug in OpenModelica though since the model had allowFlowReversal=true and therefore the port connection order shouldn't matter.

[dhblum]

Thanks @Mathadon this indeed allows the model to simulate in OMEdit. However, a new problem: the results don't match those from Dymola. I simulated both with cvode tol 1e-6 for 10 days. Outputs are 300s interval with no events stored. Some key variables plotted below (heat pump power, zone temperature, outside dry bulb temperature). Haven't looked into any further, just reporting for now.

[dhblum]

Regarding the backwards temp sensor, a simple model like this still simulates ok (with allowFlowReversal=true):

[Mathadon]

@dhblum remarkable results.. I'm getting (visually) the same results for dymola.

My guess is that the temperature set point is computed incorrectly since this strongly affects the control signal in dymola:

The set point depends on the CalendarTime block, which uses time events in a relatively complex way. I'm guess that OM causes different results due to that.

[dhblum]

Good point looking at heating set point, indeed it is not being set correctly for the PI controller for the heat pump. The problem is solved if the following changes are made:

• Setting the expression in TSetHea to if yOcc.y > 0.5 then TSetHeaOcc else TSetHeaUno instead of if yOcc.y > 0 then TSetHeaOcc else TSetHeaUno
• Setting const.k=0.5 instead of const.k=0.

Looks like yOcc.y is not exactly 0 when unoccupied.