Failures in the simulation of MSL 3.1 examples

[Adrian Pop]

I ran the attached script and got the attached trace.zip

Summary:
  MSL3.1 Examples (without Media & Fluid):           126 (+3 commented out)
  Working (some not fully) but they generate a .plt:  75
  Failing:                                            51

[Martin Sjölund]

I'll fix the issue with #ifndef Modelica.Mechanics.MultiBody.Examples.Elementary.DoublePendulum__functions__H

not being a legal C token :)

The problem with {{{division_alloc_real_array_scalar(&1.0, 1e-13, &tmp13072,"string");

tmp13072;}}}

is probably that it has some array-div type but is in fact scalar. I find it a bit weird that the result is not even used. Of course I also find it a bit weird that we generate equations to check for division by zero even for equations that has a constant non-zero divisor.

[Adrian Pop]

I also ran the script for the branch that does not contain the back-end redesign.
The results are similar so at least we know that these problems are inherited since before the back-end redesign.
If you fix any of the simulations, please add a test into:
trunk/testsuite/libraries/msl31/simulation/.

[Adrian Pop]

Email history :)

Well, I had to kill some of the simulations, i.e.
   Modelica.Electrical.Analog.Examples.*WithArc
   Modelica.Electrical.Analog.Examples.NandGate  // died with crash
   Modelica.Electrical.Analog.Examples.Rectifier
   Modelica.Electrical.Analog.Examples.ThyristorBehaviourTest

Infinite loop in the back-end (before Code gen) or maybe just very slow:
   Modelica.Mechanics.MultiBody.Examples.Loops.EngineV6
   Modelica.Mechanics.MultiBody.Examples.Loops.EngineV6_analytic
   Modelica.Mechanics.MultiBody.Examples.Systems.RobotR3.fullRobot

Cheers,
Adrian Pop/

On 2010-11-25 08:22, Martin Sjölund wrote:
> > At least for the DoublePendulum, all errors are in the
> > bound_parameters() function. So it might be a quite small fix that is
> > needed. After code generation is fixed, I believe a test using at least
> > buildModel() should be added (advanced simulations can spin for what
> > seems like infinity, but is just really slow).
> >
> > --
> > Martin Sjölund
> >
> > On 2010-11-25 08:05, Adrian Pop wrote:
>> >>
>> >>
>> >> Hi Jens,
>> >>
>> >> I ran checkModel on all these models and that works fine,
>> >> see attached script/trace.
>> >> So (i really think) most of the problems are in the back-end.
>> >>
>> >> Cheers,
>> >> Adrian Pop/
>> >>
>> >> On 2010-11-25 08:00, Jens.Frenkel wrote:
>>> >>> Hi all,
>>> >>>
>>> >>> I guess we need a more detailed statistic to make a decision. Adrian
>>> >>> could you please run the script with instantiate, translate and
>>> >>> simulate. So we know how much work has to be done for the frondend, the
>>> >>> backend, code generation and c_runtime.
>>> >>>
>>> >>> I agree with Adrian to fix the bugs before the 1.6 release.
>>> >>>
>>> >>> Jens
>>> >>>

[Adrian Pop]

Added the script and the trace to:
trunk/testsuite/libraries/msl31/simulate
See SCM Commits.

[Jens Frenkel]

Modelica.Magnetic.FluxTubes.Examples.MovingCoilActuator.Components.PermeanceActuator is also structurally singulare in Dymola.
Modelica.Magnetic.FluxTubes.Examples.MovingCoilActuator.Components.ConstantActuator is also structurally singulare in Dymola.
Modelica.Magnetic.FluxTubes.Examples.SolenoidActuator.Components.SimpleSolenoid is also structurally singulare in Dymola.

Modelica.Magnetic.FluxTubes.Examples.SolenoidActuator.Components.AdvancedSolenoid derivative of function Modelica.Magnetic.FluxTubes.Material.SoftMagnetic.mu_rApprox is not defined. 

[Adrian Pop]

Removed the supporting models pointed by Jens F. as only the top level models
from Path.To.Examples.NAME can be simulated. See SCM Commits.

[Adrian Pop]

We seems to have a lot of problems with DAE.CREF type not being set correctly.
There are two ways of dealing with this:

1. create DAE.CREF via a function that checks that the type set is the same as the type in the component reference.
   
2. remove DAE.CREF.ty completely. This might be slower as we have to get the type from component reference all the time.
   

Which one do you prefer?

[Jens Frenkel]

Because performance is not unimportant I prefer the first solution.

[Adrian Pop]

Ok. I will start replacing all DAE.CREF building with a Expression.buildExpCref function that can check the given type with the type of the given cref and report an error otherwise.

[Jens Frenkel]

• Error with %%(font-family: monospace; white-space: pre) Modelica.Mechanics.MultiBody.Examples.Elementary.DoublePendulum fixed in revision 7238%%

[Adrian Pop]

updated statistics

[Jens Frenkel]

for example Modelica.Mechanics.MultiBody.Examples.Systems.RobotR3.oneAxis

I guess there is an inexactness in the model. The submodel Modelica.Blocks.Sources.KinematicPTP2 defines the functions postion, position_der and positon_der2. The function position_der is the derivative of position and the function position_der2 is the derivative function of position_der. The modelica specification (3.1 and 3.2) define the restriction key word "order". This key word is importend for the inputs and the derivative of the inputs. The function position_der has the inputs:

input Real q_qd_qdd[3]
        "Required values for position, speed, acceleration";
       input Real dummy
        "Just to have one input signal that should be differentiated to avoid possible problems in the Modelica tool (is not used)";
       input Real dummy_der;

annotation (derivative(noDerivative=q_qd_qdd) = position_der2,
          Dymola_InlineAfterIndexReduction=true);

 and the function position_der2 has the inputs:    

      input Real q_qd_qdd[3]
        "Required values for position, speed, acceleration";
       input Real dummy
        "Just to have one input signal that should be differentiated to avoid possible problems in the Modelica tool (is not used)";
       input Real dummy_der;
       input Real dummy_der2;

This is not correct because the specification define one derivative input for each inpute of subtype of real  for the order 1. Because of position_der2 has the order 2 the annotation of position_der should be derivative(order=2,noDerivative=q_qd_qdd) = position_der2%%(font-family: 'Courier New,courier') %%. The question is has the compiler to detect this (position_der2 has order 2) or should be the annotion extendet with the restriction? 

[Adrian Pop]

The compiler could probably detect this as:
function position
has:
annotation(derivative(noDerivative=q_qd_qdd) = position_der, ...)
and then
function position_der
has:
annotation (derivative(noDerivative=q_qd_qdd) = position_der2,...)
So, you have two levels of derivative annotations starting from function position
and the compiler could detect that and add order=2 to the annotation in: function position_der.
However, if is hard to fix we can just add order=2 to the MSL 3.1 that we deliver
with OpenModelica.

[Adrian Pop]

Disregard this comment, i used wrong "cvs" instead of "csv".

Modelica.Electrical.Analog.Examples.NandGate.exe
crashes even with
outputFormat="cvs"

[Adrian Pop]

Modelica.Electrical.Analog.Examples.NandGate

example has annotation:

experiment(StopTime=1e-007)

Maybe we should really retrieve this annotation and use it for the simulate command!

[Adrian Pop]

I will go through all the examples and see what the "experiment"
annotation say and change our tests to match.

[Martin Sjölund]

These are mostly fixed. The compiler is quite different from where it was 2 years ago.