simulate API function does not complain on wrong parameters

[Francesco Casella]

Consider the following simple test case:

model Test
  Real x = sin(1000*time);
end Test;

if I call the following API function from OMShell (or OMEdit)

simulate(Test, stopTime = 1, numberOfIntervales=5000)

the compiler silently accepts numberOfIntervales (which is mis-spelled), and still uses the default number of intervals (i.e., 500).

IMHO, API function calls with nonexisting input arguments should generate an error.

[Martin Sjölund]

:)

[Francesco Casella]

In this case I did not write a semicolon, and the output is:

record SimulationResult
    resultFile = "D:/temp/lab/Test_res.mat",
    simulationOptions = "startTime = 0.0, stopTime = 1.0, numberOfIntervals = 500, tolerance = 0.000001, method = 'dassl', fileNamePrefix = 'Test', storeInTemp = false, noClean = false, options = '', outputFormat = 'mat', variableFilter = '.*', measureTime = false, cflags = '', simflags = ''",
    messages = "",
    timeFrontend = 0.04695093929535737,
    timeBackend = 0.04471573901152241,
    timeSimCode = 0.014321373247158507,
    timeTemplates = 0.02281658702432851,
    timeCompile = 1.7051429720816473,
    timeSimulation = 0.4068994802412038,
    timeTotal = 2.240976157584274
end SimulationResult;

It is true that one can see numberOfIntervals = 500 there, but this information is mixed with a lot of other stuff. I still think that in this case an error should be generated, e.g. "Unknown input 'numberOfIntervales' in simulate function"

[Martin Sjölund]

It sure is an error...

[Adrian Pop]

I'll take care of this one.

[Martin Sjölund]

Postponed until 1.9.1

[Martin Sjölund]

This ticket was not closed for 1.9.1, which has now been released. It was batch modified for milestone 1.9.2 (but maybe an empty milestone was more appropriate; feel free to change it).

[Martin Sjölund]

Milestone changed to 1.9.3 since 1.9.2 was released.

[Martin Sjölund]

Moved to new milestone 1.9.4

[Francesco Casella]

One more example, I tried the following script:

loadFile("ScalableTestSuite/package.mo"); getErrorString();
simulate(ScalableTestSuite.Mechanical.Strings.ScaledExperiments.StringModelica_N_16, 
         method = euler, numberOfIntervals = 1e6, stopTime = 100);
getErrorString();

and I get dassl and 500 intervals. Why? Because I forgot the "" around the method input, which should be a String. Not easy to understand for beginners.

So, if there is a wrong input, not only I am not notified of an error, but subsequent modifiers are also ignored.

Would it be possible to fix this for 1.9.4?

[Francesco Casella]

Quick update, I just understood why I also got 500 intervals. Contrary to what the ​documentation says, numberOfIntervals is of course an Integer, not a Real, so 1e6 is (silently) ignored. If I write numberOfIntervals=1000000, it works as expected.

That's even more confusing, without error messages.

Please also fix the documentation of the simulate() API function.

[Martin Sjölund]

Milestone pushed to 1.9.5

[Martin Sjölund]

Milestone renamed

[Martin Sjölund]

Ticket retargeted after milestone closed

[Martin Sjölund]

Milestone moved to 1.12.0 due to 1.11.0 already being released.

[Francesco Casella]

Today I used OMNotebook in class for the usual lab activity, and I had several students struggling with it, because they thought they changed the tolerance or number of intervals but would get the same result nonwithstanding.

Closer inspection revealed arguments to simulate like tollerance (that's for Italian-speaking people), StopTime (should be stopTime), numberOfintervals (should be numberOfIntervals etc.

As usual, OMC silently discards the wrong argument without producing an error. This is *extremely* confusing for beginners, particularly if they don't have a CS background.

Please make sure calls to the API with wrong parameters produce clear error messages!

[Per Östlund]

Partially fixed in a1d7895, we now check that the named arguments to simulate actually exist (also for buildModel and some other API calls that share the argument handling code with simulate). Interestingly we had 8 tests in the testsuite with invalid arguments to simulate.

This unfortunately makes simulate fail with no output at all (rather than the expected "false"), but that's not so easy to fix. The whole API really needs to be overhauled some day though, right now it's just a huge mess of call-specific behaviour.