Issues with redundant initial conditions in Buildings model?

[Francesco Casella]

Please check ​Buildings.Experimental.DistrictHeatingCooling.Validation.HeatingCoolingHotWaterSmall. The backend fails with

Warning: It was not possible to determine if the initialization problem is consistent, because of not evaluable parameters/start values during compile time: pla.coo.con.vol.dynBal.medium.p = pla.coo.con.vol.dynBal.p_start (pla.sinCoo.p = pla.coo.con.vol.dynBal.p_start)
Warning: It was not possible to determine if the initialization problem is consistent, because of not evaluable parameters/start values during compile time: pla.hea.eva.vol.dynBal.medium.p = pla.hea.eva.vol.dynBal.p_start (pla.sinHea.p = pla.hea.eva.vol.dynBal.p_start)
Notification: Performance of analyzeInitialSystem (initialization): time 0.195/7.507, allocations: 29.7 MB / 2.141 GB, free: 0.611 GB / 1.292 GB
Notification: Performance of solveInitialSystemEqSystem (initialization): time 9.535e-05/7.507, allocations: 24 kB / 2.141 GB, free: 0.611 GB / 1.292 GB
Error: Internal error IndexReduction.pantelidesIndexReduction failed! System is structurally singular and cannot be handled because the number of unassigned equations is larger than the number of states. Use -d=bltdump to get more information.
Error: No system for the symbolic initialization was generated

I guess the problem is that there initial equations made redundant by state constraints, and the backend can't deal with them because they are parameter-dependent.

In this case, I would suggest the backend to make those parameters structural and constant-evaluate them. I tried to do that by turning on the evaluate all parameters option, but unfortunately this doesn't work because the model uses external functions and the frontend cannot evaluate them.

[Andreas Heuermann]

The relevant function getConsistentEquation has a matchcontinue. I'm not a big fan and would replace it directly. The newBackend won't use matchcontinue at all. It makes finding errors very difficult.

With a bit of debugging it should be simple to find the exact location of the thrown error.

Either fixing getConsistentEquation or move the check to simulation time for cases where it is not possible to resolve all parameters at compile time.

[Francesco Casella]

Replying to AnHeuermann:

move the check to simulation time for cases where it is not possible to resolve all parameters at compile time.

We may assume they are all equal for the equation processing (so that getConsistentEquation() can eliminate the redundant ones), and then check this condition at runtime, throwing an error if it doesn't hold. If this turns out to be complicated, just evaluate them at compile time.

Being able to change these parameters without recompiling is of course a nice-to-have feature but it's much less important than getting the model to actually run.