This model crashes omedit

[massimo ceraolo]

Steps to reproduce::
1) load open source library "Photovoltaics"
2) load the attached package "TestPkg"
3) open model "SimpleModule"
4) run model -> CRASH

Note that this model has an issue, but should not cause a crash.

In Dymola, this model produces the following message:

Translation of TestPkg.SimpleModule:
Missing support for the zero-sized record variable module.diode.

The conditions of the following assert statements are always false:
assert(mod(module.moduleData.ns, module.moduleData.nb) == 0, "Simple: number of bypassed cells cannot be determined unambiguously");

Translation aborted.
ERRORS have been issued.

[Adeel Asghar]

The model crashes when translateModel is called. The only useful info I found in the stack trace is,

ob = {buf = 0x641132e0 "0x14053f4e : C:\\OpenModelica\\build\\bin\\libOpenModelicaCompiler.dll : boxptr_NFComponent_Component_Attributes_toDAE \n0x1405a0aa : C:\\OpenModelica\\build\\bin\\libOpenModelicaCompiler.dll : boxptr_NFCompon"..., sz = 16384, ptr = 9985}

[Martin Sjölund]

In Linux I got a floating point exception in ExpressionSimplify. So I am guessing somewhere there is an undefined value returned. (Note that I pass the entire frontend)

[Per Östlund]

There seems to be a couple of different issues here. With the old frontend it fails in the backend, because it uses the ExpressionSimplify module from the frontend to simplify some expressions including mod(3, 0) from the assert in the description. I've changed this so that ExpressionSimplify ignores mod(x, 0) expressions, which instead causes an error during runtime. Perhaps it would be better to give an error earlier, but an error is at least better than crashing.

The new frontend fails earlier since it tries to do a similar simplification during the frontend phase, and for some reason only div and rem checked for 0 but not mod. I fixed that too so that an error is printed when trying to constant evaluate mod(x, 0) in certain situations. However, the error is ignored during expression simplification (we also don't have the source information available there), since it's not really an error to fail to simplify an expression, so it's just ignored like in the old frontend and left to the backend to handle. We could perhaps add a check in the VerifyModel module to catch the issue earlier.

The new frontend has some other issues with the model though, which causes the model to be unbalanced. This is one of the array modifier issues that I've been trying to fix for some time, so no need to open another ticket for that.

[Francesco Casella]

Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2.

This issue, previously marked as blocker for 1.14.0, is rescheduled to 1.15.0

[Per Östlund]

Fixed in 4cf73067 and b4fe245.

[Francesco Casella]

Backported to 1.14.0