Abnormal memory consumption during compilation of models with inlined functions and symbolic differentiation

[Francesco Casella]

Please consider the SmoothSat model in the attached Save Total file. The inline smoothSat function

function smoothSat "Smooth saturation function"
  input Real x;
  input Real xmin "Lower bound of range where y = x";
  input Real xmax "Upper bound of range where y = x";
  input Real dxmin "Width of lower smoothing range";
  input Real dxmax=dxmin "Width of upper smoothing range";
  output Real y;
algorithm
   y := if x < xmin + dxmin then xmin + dxmin - dxmin*(xmin + dxmin - x)/(dxmin^4 + (xmin + dxmin - x)^4)^0.25 else if x > xmax - dxmax then xmax - dxmax + dxmax*(x - xmax + dxmax)/(dxmax^4 + (x - xmax + dxmax)^4)^0.25 else x;
  annotation (smoothOrder=4, InLine=true);
end smoothSat;

gets differentiated 5 times in the test model SmoothSat.

The Cryogenics_Test_SmoothSat.c file defines about 10000 temporary expressions. Most of them are repeated a lot of times: for example, (1.0 + (0.1 - time)) is repeated 5021 times, (time + -1.7) is repeated 4520 times.

When compiling the C code under MinGW with the default settings, cc1.exe allocates over 3 GB of memory (!). Removing the 5th differentiation brings down memory allocation to 300 MB.

Differentiating an expression 5 times is probably a bit extreme (the idea was to check that the first 4 derivatives are continuous, and only the 5th is discontinuous), however there is something going badly wrong with common subexpressions in the differentiated functions, and I guess this is worth having a look at.

[Francesco Casella]

C file generated by omc

[Martin Sjölund]

Moved to new milestone 1.9.4

[Martin Sjölund]

Milestone pushed to 1.9.5

[Martin Sjölund]

Milestone renamed

[Martin Sjölund]

Ticket retargeted after milestone closed

[Martin Sjölund]

Milestone moved to 1.12.0 due to 1.11.0 already being released.

[Francesco Casella]

As of v1.13.0-dev-226-ga72f165, the problem is still present, the only difference is that now the C files have been split, so the 3 GB of RAM are allocated by several cc1.exe processes running in parallel.

As already noted, this is quite an extreme example, but maybe it can point out in a somewhat exaggerated way some shortcoming of CSE when doing automatic differentiation.

@ptaeuber, @vwaurich, could you have a look? Maybe you can use a modified version of this test cases with just, say, 3 differentiation to avoid the extreme memory blow-up

[Francesco Casella]

Save Total file

[Patrick Täuber]

I think this is not about inline integration as the title says?

I do not know how the module comSubExp works, but there is a comment that this is just a basic prototype.

I had a short look and tested the cseBinary module, which is not activated by default. It does not find any cse-variable either. This is because of the fact that it does not look into the if-branches. If I compile it only with the first branch the module finds 121 cse variables, which is also not very appropriate. This module is just a simple prototype, as well.

[Francesco Casella]

Of course it's not inline integration, but rather function inlining, I have updated the summary

[Volker Waurich]

comSubExpis a pre-optimization module and won't handle this.

[Francesco Casella]

Could we add an (optional?) post-optimization call to it?

[Volker Waurich]

comSubExp is not capable of substituting these terms. cseBinary is the module which should deal with this.
btw. I commited a simplification rule to simplify (1.0 + (0.1 - time)) to (1.1 - time)). Unfortunately, this did not lead to further simplications. Only 100KB smaller c-files.

[Francesco Casella]

OK, I guess this is a fairly extreme corner case, it's probably not such a high priority to fix this now.

I wonder if you could add a few words in the documentation to explain the difference between these two functions. From the current documentation, which says

• cseBinary (Common Sub-expression Elimination)
• comSubExp (replaces common sub expressions)

it is hard to tell what the difference is.