Type of constants in the NF

[rfranke]

See the following example:

  model m
    input Real a(start = 1);
    output Real b;
  equation
    b = min(a, 100);
  end m;

The old frontend (omc) generates:

class m
  input Real a(start = 1.0);
  output Real b;
equation
  b = min(a, 100.0);
end m;

The new frontend (omc -d=newInst) generates:

class m
  input Real a(start = 1.0);
  output Real b;
equation
  b = min(a, 100);
end m;

This generates problems during C++ compilation, because there is no template for min(double&, int).

Who is right and who should fix it?

[casella]

Probably a duplicate of #4868, but I'll leave it open anyway

[rfranke]

That's 250 tickets and 5 months back!
Not very motivating for start using the new Frontend.

[perost]

Fixed in fa177e77.

[casella]

Replying to rfranke:

That's 250 tickets and 5 months back!
Not very motivating for start using the new Frontend.

@rfranke it's not that bad, 114 tickets concerning the NF were open in that period (the others belong to other parts of the software), of which 74 have already been fixed.

It's also a matter of prioritization, we are currently focusing on those changes that have a wider impact on coverage, you may later check ​here what was the impact of this commit. Keep in mind that the goal here is 2.0.0, not 1.13.0 or 1.14.0. Eventually all these issues will be fixed.

If you look at the coverage of MSL in the last five months the improvement has been dramatic, with successful simulation going from 15% to 65%. Consider that there are many false negatives in the verification stage, so a good estimate of models working correctly is probably half-way between the simulation and the verification curve.

Taking into account the effect of the summer break and assuming the progress does not slow down too much towards the end (which shouldn't be the case), it will take another 3-4 months to get close to 100%, so based on this data I expect the new front-end to be mostly usable in time for the next Annual Meeting.

[rfranke]

The graph looks impressive. OK, I'm motivated again :-)
Thank you for the fast fix!

I wonder by how much the coverage would further grow if scoping for default function arguments worked (see #5125).

[adrpo]

We'll see it in a little while, I started the new inst job after Per fixed #5125.
​https://test.openmodelica.org/hudson/job/OpenModelica_TEST_LIBS_RIPPER/2208

[casella]

Replying to rfranke:

I wonder by how much the coverage would further grow if scoping for default function arguments worked (see #5125).

As far as I can tell from my analysis of the remaining open issues, there's few silver bullets left. The two biggest open issues are proper handling of function calls and record constructors, as well as partial function evaluation. These largely affect all models using Modelica.Media and Complex, which are numerous. I understand this may take a while to be implemented efficiently, but will have a major impact, though possibly revealing other minor bugs that are currently hidden because of failure of the model building process.

Then, there are about 40 smaller issue that I identified on Hudson test reports of some libraries ( mostly MSL and ScalableTestSuite, but also Buildings, HelmholtzMedia, PlanarMechanics), which may take on average one or two days each to fix, each affecting a relatively small number of models. Once these libraries are mostly covered, I will also look into other libraries, e.g. ThermoPower and PowerSystems, until all covered libraries perform better than with the old FE, at which time we can release 2.0.0.

Finally, we have about 15 historical front-end issues (e.g., the very bad #2858) that have been lingering for several years because they basically could not be fixed in the old front-end. I hope at some point we'll find them fixed because the other ones were - I check this regularly. For some of them, we may need some additional work, hopefully not much because of the better structure of the new front-end.

For me, there's good reasons to be optimistic :)