Introduce wrapFunctionCalls and CSE also for the initial equations

[Francesco Casella]

In some cases (e.g., steady-state initialization of steam power plant models using homotopy) the initial equations could end up being evaluated a large number of times, and therefore could benefit a lot from CSE if expensive function calls can be spared.

Please introduce wrapFunctionCalls also within -initOpt

[Martin Sjölund]

Ticket retargeted after milestone closed

[jhagemann]

You can use --initOptModules+=wrapFunctionCalls now (​PR1499), but it seems that it exists problems in codegen. So you can test your models with the flag from above.

[Martin Sjölund]

Milestone moved to 1.12.0 due to 1.11.0 already being released.

[Francesco Casella]

Milestone moved to 1.13.0 due to 1.12.0 already being released.

[Francesco Casella]

Rescheduled to 1.14.0 after 1.13.0 releasee

[Francesco Casella]

Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2. This issue is rescheduled to 1.16.0

[Karim Adbdelhak]

I activated wrapFunctionCalls for the initialization in ​PR710. It could not be activated before, because the lambda 0 system for homotopy initialization was assumed to have the same variables as the regular one. Which is not necessarily true applying wrapFunctionCalls. I changed it and it works fine (on the model from #5727 at least). Let's see how the test results go.

For the model from #5727 it improved to:

    timeFrontend = 1.37957711,
    timeBackend = 20.866203866,
    timeSimCode = 1.497791234,
    timeTemplates = 2.41936087,
    timeCompile = 26.729432772,
    timeSimulation = 22.064069041,
    timeTotal = 74.956539517

If the tests run fine i am able to push and you can test it for yourself @Francesco!

This solution may also be the first step to resolve #5806.

[Francesco Casella]

Great!

I saw some problem with the fmu checker in the pull request reports, no idea why that happens.

[Francesco Casella]

See comments in ​PR 710.

In particular, it seems like the possibility of variables that occur only in the initial and not in the regular system (which happens applying CSE on initial equations) was not considered implementing that.

[Francesco Casella]

Solving this problem is not trivial, because many places in the current initialization pipeline assume that the variables of the initial problem are same as the simulation problem, which is not the case if CSE is applied.

[Francesco Casella]

(Update)

For the solution of this issue, we can safely assume that the $cse variables that are generated for the regular equations are also fine for the initial equations.

In most cases, initial equations are simple equations such as x = x_0 or der(x) = 0, CPU-intensive function calls are normally found in the regular equations.

This is true in particular in the case of thermo-hydraulic systems such as the case reported in this ticket.

[Karim Adbdelhak]

Unfortunately this is still way harder as expected. Here are some small details on why:

• The initialization system gets analyzed before the simulation system has its post-optimization phase (where wrapFunctionCall takes place). So in order to pass information from the simulation wrapFunctionCalls to the initialization we would need to reverse this.
• Initialization produces information the simulation system depends on, or at least structurally it is build that way. Therefore reversal of the pipeline is not really easy.
• Some information from the initial system is discarded after it is created to not contradict information from the simulation system and confuse code generation (mostly stuff about known variables). This really needs to be changed, discarding information seems bad. This also results in the artificial dependency of the systems and forces the simulation system to be post optimized after the initial system, they should be independent)
• One could think that we could apply wrapFunctionCalls on the initial system and instead pass information to the simulation system, but this also does not always work, because some necessary information gets discarded, as i just mentioned (this is also the original reason it does not work in general for the initial system).

All of this comes from the assumption that both systems have to have the same variables and are tried to be kept in sync. This directly results from the fact the both systems have their own vector of variables, which we should change.

I consulted some colleagues, mainly Andreas and Lennart and we came to the conclusion that this particular problem results from old design mistakes. In conjunction with designing the structural changes for array analysis, we are designing the new backend structure such that the variables are independent from the actual systems. I do not want to go into detail, the new backend structure design is still in its first draft phase.

We will postpone this for now and hope that we can get this fixed with the new design. The old design could be fixed by preventing to discard the information, but that is a lot of work and will break many other things, so we should directly work on the new design to provide a better base to work on. Synchronizing the systems is a bad idea, they should directly work on the same structures.

[Francesco Casella]

I looks like I'll have to wait until the FlexiCaL system initialization becomes reasonably fast. I'll try to make sure we use as few homotopy steps as possible.

[Karim Adbdelhak]

Replying to casella:

I looks like I'll have to wait until the FlexiCaL system initialization becomes reasonably fast. I'll try to make sure we use as few homotopy steps as possible.

You can still try to use --initOptModules+=wrapFunctionCalls. For some models it works it just can't be made standard right now.

[Francesco Casella]

I'll try that. Maybe we can still apply some small fixes to get the FlexiCaL model working with this special flag?

[Karim Adbdelhak]

Replying to casella:

I'll try that. Maybe we can still apply some small fixes to get the FlexiCaL model working with this special flag?

Sure! Hopefully they don't have those convoluted problems.

[Francesco Casella]

Retargeted to 1.17.0 after 1.16.0 release

[Francesco Casella]

Retargeted to 1.18.0 because of 1.17.0 timed release.

[Francesco Casella]

Ticket retargeted after milestone closed