Support the inverse annotation

[Francesco Casella]

The inverse annotation, as specified in Section 12.8 of the language specification, should be implemented in the backend.

This is a minimalistic test model, that should run without the need of any implicit nonlinear solver.

package TestInverse
  function f 
    input Real x;
    output Real y;
  algorithm
    y := x*abs(x);
  annotation(Inline = false,
    inverse(y=g(x)));
  end f;
  
  function g
    input Real y;
    output Real x;
  algorithm
    x := sqrt(abs(y))*sign(y);
  annotation(Inline = false);
  end g;
  
  model Test
    Real x, y;
  equation
    y = time - 5;
    y = f(x);
  annotation(experiment(StopTime = 10));
  end Test;
end TestInverse;

[dariomangoni@…]

+1

[dariomangoni@…]

I will add this: there are many models that are strongly asymmetric. For these models, it should be our priority to provide an effective and efficient way to handle the problem also when inverted.
I think that the 'inverse' annotation should be a top priority for developers.

[Francesco Casella]

@dariomangoni, do you have any concrete application cases that you can mention?

I tentatively scheduled this enhancement for 2.1.0, because we have to prioritize our fairly scarce resources, and the goal of 2.0.0 is to get as many models as possible in the available open source libraries to run successfully. Doing that *efficiently* is of course important, but in general comes next, unless you have compelling reasons for that (i.e., really dramatic performance improvements), or if you are willing to sponsor a directly funded development with the OSMC.

[dariomangoni@…]

Many models are quite fit to be implemented as signal-based, but still they might be provided in a model-based language for consistency of the library.
I have, in my case, a not-so-complex permanent motor model that has a quartic function to be solved and on whose roots influence the behaviour of the model itself.
To simplify the description: it's easy, given the current, to output the torque (just a function evaluation); it's way worse to have the current based on the torque.
Here I need an inverse function that would effectively handle the inversion; I cannot simply have an iterative solution.

[Francesco Casella]

I see. Let' see if we can get this in 2.0.0.