Bogus linear tearing in Buildings model

[Francesco Casella]

Please check ​Buildings.Electrical.AC.ThreePhasesUnbalanced.Validation.IEEETests.Test4NodesFeeder.BalancedStepDown.YD. The model fails during lambda0 initialization with

Failed to solve linear system of equations (no. 569) at time 0.000000, system is singular for U[2, 2].
Matrix U
        -0 
Output vector x
[ 1]                    0
The default linear solver fails, the fallback solver with total pivoting is started at time 0.000000. That might raise performance issues, for more information use -lv LOG_LS.

The debugger shows that system 569 is torn in this way:

linear (torn), unknowns: 3, iteration variables: 1 (transformer.conv2.terminal_p.i[1])
(torn) transformer.conv3.terminal_p.i[1] := transformer.conv2.terminal_p.i[1] - line2.i3[1]
(torn) transformer.conv1.terminal_p.i[1] := transformer.conv2.terminal_p.i[1] + line2.i2[1]
(residual) line2.i1[1] + transformer.conv1.terminal_p.i[1] - transformer.conv3.terminal_p.i[1] = 0

It is immediate to see that the term transformer.conv2.terminal_p.i[1] appears both in transformer.conv3.terminal_p.i[1] and in transformer.conv1.terminal_p.i[1], so when those two are subtracted to compute the residual, its sensitivity w.r.t. its unknown is zero.

I don't know what criterion is used to perform linear tearing, but it's obviously not a good one. Linear systems should be solved with proper pivoting; solving some equations according only to structural information but disregarding the coefficient values can be very dangerous.

Until this issue is solved, I would recommend to disable linear tearing by default. This will sure enough solve a lot of problems in the testsuite. BTW, now that we have sparse solvers to deal with large linear systems, the usefulness of linear tearing is probably quite limited.

[Andreas Heuermann]

Until this issue is solved, I would recommend to disable linear tearing by default. This will sure enough solve a lot of problems in the testsuite. BTW, now that we have sparse solvers to deal with large linear systems, the usefulness of linear tearing is probably quite limited.

I totally agree with you. I would even go a step further and don't spend time to improve linear tearing, but instead invest the time in sparse and parallelized (?) linear solvers to work better in the C and/or Cpp runtime.

Also linear tearing was disabled for a long time due to performance reasons. I'm not sure if anybody did a recent benchmark to compare linear tearing + dense linear solver against no linear tearing + sparse linear solver.
Maybe a nice task for a Bachelor thesis or student project?

[Francesco Casella]

Replying to AnHeuermann:

Until this issue is solved, I would recommend to disable linear tearing by default. This will sure enough solve a lot of problems in the testsuite. BTW, now that we have sparse solvers to deal with large linear systems, the usefulness of linear tearing is probably quite limited.

I totally agree with you.

Can you make the required PR so we can have some test results before feature freeze? Mabye wait a few days before merging it, since we are currently trying out moving to NF by default, I'd try not to mix up the results.

I would even go a step further and don't spend time to improve linear tearing, but instead invest the time in sparse and parallelized (?) linear solvers to work better in the C and/or Cpp runtime.

Possibly. I guess using parallel solvers only makes sense for really big systems. How big I'm not sure, maybe you really need tens or hundreds of thousands variables to really see a difference.

Also linear tearing was disabled for a long time due to performance reasons.

I'm not sure what you mean here. We have ​--maxSizeLinearTearing = 200 by default, with the limit set because of performance. Do you mean it was set to zero and later increased to 200?

Anyway, I would just set --maxSizeLinearTearing = 0 by default. Next week please, to avoid confusion with test results.

I'm not sure if anybody did a recent benchmark to compare linear tearing + dense linear solver against no linear tearing + sparse linear solver.

I'm not aware of any.

Maybe a nice task for a Bachelor thesis or student project?

Why not? We have more pressing priorities, but this is an interesting subject anyway. The only problem I see is to have enough good test cases. One could use some test cases from the ScalableTestSuite library, but maybe they are somewhat artificial.

[Andreas Heuermann]

Anyway, I would just set --maxSizeLinearTearing = 0 by default. Next week please, to avoid confusion with test results.

I think it was disabled slightly different. I would need to search for the exact commit. But yeah, disabling linear tearing for default simulation is no problem.
I'll create a PR in the next days.

[Francesco Casella]

Replying to AnHeuermann:

I think it was disabled slightly different.

Yes, by using ​--disableLinearTearing. But that is said to be deprecated, so we should set the maximum size to zero instead :)

I'll create a PR in the next days.

Sounds good. You can actually create it right away, only put a comment to Adrian to wait pushing it until a moment when we are not playing around with the default NF or other major commits.

[Francesco Casella]

A fix is pending in ​PR 6969, waiting to be merged onto master.

[Francesco Casella]

Fine to have this in 1.17.0, if possible.

[Francesco Casella]

Rescheduled to 1.18.0