perost
commented
10 months ago 11626 improves things a bit by simplifying e.g. {x[1], x[2]} + {y[1], y[2]} => {x[1] + y[1], x[2] + y[2]}. It was only really meant to get rid of the zero-arrays at the start of the expressions, which are used as start values when simplifying sum/product reductions and were not simplified away earlier. But it actually improves this model quite a bit, lowering the time to ~5s and reducing the output to "only" about 2MB. I'm not sure why though, it doesn't affect the smaller model from #11412 in the same way.
As for the fact that B is mostly non-zero, it's not really something the frontend can use since B is both a variable and defined by equations. I think the best solution would be for the frontend to not expand the sum expressions at all and leave it to the backend, which does seem to work fine if I manually disable things in the code. Ideally we should expand expressions a lot less, but it tends to break the backend in surprising ways unfortunately.
casella
Steps to reproduce
Get the Flex package from https://github.com/casella/FlexBeam and instantiate
Flex.Test.FreeVibrationwith the following test script:Flattening this model takes about 30 s on my computer, which I'd say is a bit too much for a model with 1803 equations. This is the breakdown:
More than half of the time is taken to output the flat model in textual format, despite a significant amount of time (6 seconds) spent in simplifying it.
Analysis
The output file is huge, over 40 MB of size. I singled out what the problem is: the equation for
beam.Ithth_bar11_deralone is 14 million character long.Its defining equation is
The problem of this apparently innocuous equation is that if one fully expands the matrix products inside the reduction, the number of elements that needs to be summed is mind-blowing. Most of them are zero, because array
B[:,:,]is very sparse, but they are currently taken into account anyway, leading to a monstrous inflation of terms.Obviously, the solution to this problem cannot be to leave it to the backend to simplify the expression, because that's too late.
Proposed fix
As I understand, the only way to handle this model is to curb the elements of the sum reduction expression that are zero right away while computing the reduction, not afterwards. Dymola swallows this model without a hiccup and has been doing that for 15 years, so I guess it does something like that.
The simplification of terms multiplied by variables equal to one can be left to the backend, as they are not that many.
@perost do you think this is easily doable in the NF?
For a smaller MWE, you can re-use model
Test3DArrayfrom #11412. That model is now flattened in about one second, but still contains an expression which is much longer than it ought to be:which comes from the reduction expression in
That equation should be expanded into a much shorter expression, as there are only a handful of non-zero
B[:,:,:]elements.The question for @kabdelhak and @phannebohm is how they want to handle this with the new backend. I guess in this case the trick will be that the array-preserving NF does not even try to expand the RHS of the equation shown above and passes it straight to the NB. Then, they will have to figure out a smart way to handle the sparse matrix product efficiently, without ever fully expanding it, which is a killer.