Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#5126 closed defect (fixed)

Type of constants in the NF

Reported by: Rüdiger Franke Owned by: Per Östlund
Priority: high Milestone: 2.0.0
Component: New Instantiation Version:
Keywords: Cc: Peter Fritzson

Description

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?

Change History (7)

comment:1 by Francesco Casella, 6 years ago

Milestone: 1.13.02.0.0
Summary: Type of constantsType of constants in the NF

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

comment:2 by Rüdiger Franke, 6 years ago

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

Last edited 6 years ago by Rüdiger Franke (previous) (diff)

comment:3 by Per Östlund, 6 years ago

Resolution: fixed
Status: newclosed

Fixed in fa177e77.

in reply to:  2 comment:4 by Francesco Casella, 6 years ago

Cc: Peter Fritzson added

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.

https://libraries.openmodelica.org/branches/history/newInst/Modelica_trunk.svg

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.

comment:5 by Rüdiger Franke, 6 years ago

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).

Last edited 6 years ago by Rüdiger Franke (previous) (diff)

comment:6 by Adrian Pop, 6 years ago

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

in reply to:  5 comment:7 by Francesco Casella, 6 years ago

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 :)

Last edited 6 years ago by Francesco Casella (previous) (diff)
Note: See TracTickets for help on using tickets.