A very wrong result without any warning or error message

[massimo ceraolo]

The attached package test contains model testOM.
This model contains the sine-wave source "fem". When it is simulated, the model compiles and runs without warnings and errors, but the shape of fem is totally different from a sine wave!

I propose blocker priority since this is really tricky because the user should be allowed to trust a result obtained without a warning.

tested on a Windows system using
OMEdit v1.13.0-dev-95-g4eb7a19 (64-bit)
Connected to v1.13.0-dev-380-g8b177b9 (64-bit)

[Francesco Casella]

I ran this model with OMEdit v1.13.0-dev-94-gbfd3af3 (64-bit), connected to v1.13.0-dev-357-g105aad9 (64-bit), which is one week old. The simulation runs for 0.06 seconds and fem.p.v shows a nice sinusoid with 40 V amplitude and three full periods.

@ceraolo, are you experiencing problems with a later nightly?

[massimo ceraolo]

In "fem.png" what I gat using

OMEdit v1.13.0-dev-95-g4eb7a19 (64-bit)
Connected to v1.13.0-dev-380-g8b177b9 (64-bit)

on Win

[massimo ceraolo]

I have a simpler test showing the issue. I attach simpler.mo and simpler.png to ease debug.

[massimo ceraolo]

My fault: I forgot to remove "-d=newInst"
I'm going to close this.

[Francesco Casella]

In fact the issue is absolutely relevant for the new front-end and its interaction with the run-time.

For further analysis of the bug, remove the protected marker so that everything is visible in the simulation result, consider the two variables fem.p.v and pwmPulser.carrier.y and compare the results with the old and new FE.

When the new FE is used, the voltage oscillates beween the true value and the value of zero with a period that is twice the communication interval length, while the carrier output oscillates between the true value and -1. If the communication interval is reduced, so is the oscillation period. If noEquidistanTimeGrid is selected, the simulation gets stuck at time 0 due to chattering on the zero crossing function pwmPulser.greater.u1 > pwmPulser.greater.u2.

I couldn't say what in the NF ouput could cause this kind of issues in the code generation. The expressions determining those two values when instantiating the model with OMEdit are identical or virtually identical

OF:  fem.signalSource.y = fem.signalSource.offset + (if time < fem.signalSource.startTime then 0.0 else fem.signalSource.amplitude * sin(6.283185307179586 * fem.signalSource.freqHz * (time - NF: fem.signalSource.startTime) + fem.signalSource.phase));
  fem.signalSource.y = fem.signalSource.offset + (if time < fem.signalSource.startTime then 0.0 else fem.signalSource.amplitude * sin(2.0 * 3.141592653589793 * fem.signalSource.freqHz * (time - fem.signalSource.startTime) + fem.signalSource.phase));

OF: pwmPulser.carrier.y = pwmPulser.carrier.offset + (if time < pwmPulser.carrier.startTime or pwmPulser.carrier.nperiod == 0 or pwmPulser.carrier.nperiod > 0 and pwmPulser.carrier.count >= pwmPulser.carrier.nperiod then 0.0 else if time < pwmPulser.carrier.T_start + pwmPulser.carrier.T_rising then pwmPulser.carrier.amplitude * (time - pwmPulser.carrier.T_start) / pwmPulser.carrier.rising else if time < pwmPulser.carrier.T_start + pwmPulser.carrier.T_width then pwmPulser.carrier.amplitude else if time < pwmPulser.carrier.T_start + pwmPulser.carrier.T_falling then pwmPulser.carrier.amplitude * (pwmPulser.carrier.T_start + pwmPulser.carrier.T_falling - time) / pwmPulser.carrier.falling else 0.0);
NF: pwmPulser.carrier.y = pwmPulser.carrier.offset + (if time < pwmPulser.carrier.startTime or pwmPulser.carrier.nperiod == 0 or pwmPulser.carrier.nperiod > 0 and pwmPulser.carrier.count >= pwmPulser.carrier.nperiod then 0.0 else if time < pwmPulser.carrier.T_start + pwmPulser.carrier.T_rising then pwmPulser.carrier.amplitude * (time - pwmPulser.carrier.T_start) / pwmPulser.carrier.rising else if time < pwmPulser.carrier.T_start + pwmPulser.carrier.T_width then pwmPulser.carrier.amplitude else if time < pwmPulser.carrier.T_start + pwmPulser.carrier.T_falling then pwmPulser.carrier.amplitude * (pwmPulser.carrier.T_start + pwmPulser.carrier.T_falling - time) / pwmPulser.carrier.falling else 0.0);

maybe @lochel or @wbraun should have a look and comment on this.

[Per Östlund]

It looks to me like this model now simulate correctly with the new instantiation, please confirm.

[massimo ceraolo]

I've just checked with OM 1.13.0-dev-460-g9c759d9 (64-bit, Win)
and everything is ok for me.