Bogus accounting of (discrete?) equations and variables in Buildings

[Francesco Casella]

Please check ​Buildings.Controls.DemandResponse.Examples.ClientLBNL90. The frontend reports

Notification: Model statistics after passing the front-end and creating the data structures used by the back-end:
 * Number of equations: 11299
 * Number of variables: 11299

The backend then reports

Notification: Performance of Generate backend data structure: time 0.08858/0.4659, allocations: 35.17 MB / 0.7867 GB, free: 14.35 MB / 0.6667 GB
Notification: Performance of prepare preOptimizeDAE: time 5.442e-05/0.466, allocations: 8.031 kB / 0.7867 GB, free: 14.34 MB / 0.6667 GB
Notification: Performance of preOpt normalInlineFunction (simulation): time 0.0131/0.4791, allocations: 3.61 MB / 0.7902 GB, free: 10.69 MB / 0.6667 GB
Notification: Performance of preOpt evaluateParameters (simulation): time 0.03833/0.5175, allocations: 10.55 MB / 0.8005 GB, free: 48 kB / 0.6667 GB
Notification: Performance of preOpt simplifyIfEquations (simulation): time 0.635/1.152, allocations: 2.522 MB / 0.803 GB, free: 80.17 MB / 0.6667 GB
Notification: Performance of preOpt expandDerOperator (simulation): time 0.01173/1.164, allocations: 3.745 MB / 0.8067 GB, free: 78.93 MB / 0.6667 GB
Error: An independent subset of the model has imbalanced number of equations (11256) and variables (312).

Then, 312 variables are listed, and then a set of equations is then reported, with equations numbered from 1 to 290, which is less than 312 and a lot less than 11256.

I can't really make sense of this output, but I guess @Karim can figure that out easily by looking at the output of this example and doing a bit of debugging.

[Francesco Casella]

Same issue with ​Buildings.Controls.Predictors.Validation.ConstantInput, which is one order of magnitude smaller, so possibly easier to debug.

[Francesco Casella]

Ticket retargeted after milestone closed

[Francesco Casella]

1.18.0 blocker tickets moved to 1.19.0

[Francesco Casella]

As of 15 Oct 2021, the original model reported in this ticket now fails during code generation for some other reason, while the smaller one is running successfully.