Opened 6 years ago

Last modified 3 years ago

#5291 new defect

Issue with Modelica.Mechanics.MultiBody.Examples.Elementary.RollingWheel in OMEdit

Reported by: Francesco Casella Owned by: Adeel Asghar
Priority: critical Milestone:
Component: OMEdit Version:
Keywords: Cc: Adrian Pop, Martin Sjölund

Description

If I open Modelica.Mechanics.MultiBody.Examples.Elementary.RollingWheel with the latest OMEdit nightly build and run it, it works fine, even though there are some warnings about state selection, which apparently are not critical.

If I now set -d=initialization,newInst in the setup menu and re-run the model, I get the following run-time error message:

Failed to solve linear system of equations (no. 21) at time 0.000000, system is singular for U[2, 2].
The default linear solver fails, the fallback solver with total pivoting is started at time 0.000000. That might raise performance issues, for more information use -lv LOG_LS.
Matrix singular!
Failed to solve linear system of equations (no. 22) at time 0.000000, system is singular for U[2, 2].
The default linear solver fails, the fallback solver with total pivoting is started at time 0.000000. That might raise performance issues, for more information use -lv LOG_LS.
Matrix singular!
under-determined linear system not solvable!
Error solving linear system of equations (no. 22) at time 0.000000.
Solving linear system 22 fails at time 0. For more information use -lv LOG_LS.

The first weird thing is that the very same model run by Hudson fails with a completely different runtime error:

assert            | debug   | division by zero at time 0, (a=4.940656458412465e-324) / (b=0), where divisor b expression is: sqrt(wheel1.rollingWheel.aux[1] ^ 2.0 + wheel1.rollingWheel.aux[2] ^ 2.0)
assert            | info    | simulation terminated by an assertion at initialization

If I now click on the Debug more link, the Debugger window opens and equation 22, linear, unknown variables:3 is highlighted.

Here there are other two weird things: one is that the former equation is number 21 and the subsequent one is 23, which is odd, because in other places systems with N equations normally take up N+1 slots in the sequence, one for the system as a whole, and N, each for one equation in the system.

The other weird thing is that if I click on this equation, the source browser window and the Equation Operations window remain rigorously empty, which is not the case for other linear systems equations found further on, e.g. number 120, for which I can select every individual equation and see the source line and the all the transformations that brought to the run-time solved form. So, basically, I'm told there's a problem on a linear system, but there's no chance of understanding how this system looks like, and where its equations come from.

Last, but not least, if I now close OMEdit (remember I previously set -d=newInst in the simulation options), re-open it, re-select the same model and try to run it, I immediately get this error:

[1] 01:05:46 Symbolic Error
[Modelica.Mechanics.MultiBody.Interfaces: 732:5-733:65]:
Assertion triggered during translation: 
"Connector frame_a of visualizer object is not connected".

@adeas31, can you shed some light on this rather puzzling behaviour?

Attachments (1)

script.mos (235 bytes ) - added by Adeel Asghar 6 years ago.

Download all attachments as: .zip

Change History (12)

comment:1 by Adeel Asghar, 6 years ago

The first weird thing is that the very same model run by Hudson fails with a completely different ​runtime error:

I don't know what settings and version does Hudson have but I have tried to simulate the model on my machine with latest master and I get the same error from OMEdit and CLI. See the attached the script.

I have only tested the model yet. Will look into the Debug more issue soon.

by Adeel Asghar, 6 years ago

Attachment: script.mos added

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

Replying to adeas31:

I have only tested the model yet. Will look into the Debug more issue soon.

Don't forget part three: opening the model in OMEdit when -d=newInst has previously been set.

comment:3 by Adeel Asghar, 6 years ago

Yeah I tested with -d=newInst and I get the runtime error message given in the description.

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

Replying to adeas31:

I don't know what settings and version does Hudson have

They are reported here:

Optimization level: -Os -march=native

Reference Files: $MSLREFERENCE/v3.2.2+build.0-beta.3

Verified using: OpenModelica 1.12.0 (diffSimulationResults)
Flags:

setCommandLineOptions("-d=newInst,-frontEndUnitCheck")
setCommandLineOptions("-d=nogen");
setCommandLineOptions("-d=initialization");
setCommandLineOptions("-d=backenddaeinfo");
setCommandLineOptions("-d=discreteinfo");
setCommandLineOptions("-d=stateselection");
setCommandLineOptions("-d=execstat");
setMatchingAlgorithm("PFPlusExt");
setIndexReductionMethod("dynamicStateSelection");
if not setCommandLineOptions("--std=3.2") then exit(1); end if;

Unfortunately the Windows nightly's been broken since Jan 23 (#5306), so I can't check with an up-to-date version now. Will try later.

comment:5 by Adeel Asghar, 6 years ago

Cc: Martin Sjölund added

Here there are other two weird things: one is that the former equation is number 21 and the subsequent one is 23, which is odd, because in other places systems with N equations normally take up N+1 slots in the sequence, one for the system as a whole, and N, each for one equation in the system.

I have no idea about it. Perhaps Martin can help with this.

The other weird thing is that if I click on this equation, the source browser window and the Equation Operations window remain rigorously empty, which is not the case for other linear systems equations found further on, e.g. number 120, for which I can select every individual equation and see the source line and the all the transformations that brought to the run-time solved form. So, basically, I'm told there's a problem on a linear system, but there's no chance of understanding how this system looks like, and where its equations come from.

The problem is that source info in stored inside equation in this case which makes the json inconsistent. I think there is something wrong with the generation of the json. Normally source key is at top level.

Last, but not least, if I now close OMEdit (remember I previously set -d=newInst in the simulation options), re-open it, re-select the same model and try to run it, I immediately get this error:

[1] 01:05:46 Symbolic Error
[Modelica.Mechanics.MultiBody.Interfaces: 732:5-733:65]:
Assertion triggered during translation: 
"Connector frame_a of visualizer object is not connected".

I did the same but I am not getting this error. Maybe you have some other setting as well.

comment:6 by Francesco Casella, 6 years ago

I still see the same problem, I'm not sure what other setting could I have. The log transcript follows, could you compare it with what you get?

cd("C:/Users/Francesco Casella/AppData/Local/Temp/OpenModelica/OMEdit/Modelica.Mechanics.MultiBody.Examples.Elementary.RollingWheel") 14:19:18:915
"C:/Users/Francesco Casella/AppData/Local/Temp/OpenModelica/OMEdit/Modelica.Mechanics.MultiBody.Examples.Elementary.RollingWheel" 14:19:18:915
#s#; 0.001; 69.063; 'cd("C:/Users/Francesco Casella/AppData/Local/Temp/OpenModelica/OMEdit/Modelica.Mechanics.MultiBody.Examples.Elementary.RollingWheel")'

clearCommandLineOptions() 14:19:18:918
true 14:19:18:918
#s#; 0; 69.063; 'clearCommandLineOptions()'

setMatchingAlgorithm("PFPlusExt") 14:19:18:920
true 14:19:18:921
#s#; 0.003; 69.066; 'setMatchingAlgorithm("PFPlusExt")'

setIndexReductionMethod("dynamicStateSelection") 14:19:18:921
true 14:19:18:931
#s#; 0.01; 69.076; 'setIndexReductionMethod("dynamicStateSelection")'

setCommandLineOptions("+simCodeTarget=C") 14:19:18:931
true 14:19:18:931
#s#; 0; 69.076; 'setCommandLineOptions("+simCodeTarget=C")'

setCommandLineOptions("+target=gcc") 14:19:18:931
true 14:19:18:931
#s#; 0; 69.076; 'setCommandLineOptions("+target=gcc")'

setCommandLineOptions("-d=initialization,newInst") 14:19:18:931
true 14:19:18:931
#s#; 0; 69.076; 'setCommandLineOptions("-d=initialization,newInst")'

setCommandLineOptions("+ignoreCommandLineOptionsAnnotation=false") 14:19:18:931
true 14:19:18:931
#s#; 0; 69.076; 'setCommandLineOptions("+ignoreCommandLineOptionsAnnotation=false")'

setCommandLineOptions("+ignoreSimulationFlagsAnnotation=false") 14:19:18:931
true 14:19:18:931
#s#; 0; 69.076; 'setCommandLineOptions("+ignoreSimulationFlagsAnnotation=false")'

setCommandLineOptions("+profiling=none") 14:19:18:931
true 14:19:18:931
#s#; 0.004; 69.08; 'setCommandLineOptions("+profiling=none")'

setCommandLineOptions("-d=infoXmlOperations") 14:19:18:935
true 14:19:18:935
#s#; 0; 69.08; 'setCommandLineOptions("-d=infoXmlOperations")'

translateModel(Modelica.Mechanics.MultiBody.Examples.Elementary.RollingWheel,startTime=0, stopTime=4, numberOfIntervals=500, method="dassl", tolerance=1e-06, outputFormat="mat", variableFilter=".*") 14:19:18:935
false 14:19:19:166
#s#; 0.231; 69.311; 'translateModel(Modelica.Mechanics.MultiBody.Examples.Elementary.RollingWheel,startTime=0, stopTime=4, numberOfIntervals=500, method="dassl", tolerance=1e-06, outputFormat="mat", variableFilter=".*")'

errors:=getMessagesStringInternal() 14:19:19:166
{record OpenModelica.Scripting.ErrorMessage
    info = record OpenModelica.Scripting.SourceInfo
    filename = "C:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica 3.2.2/Mechanics/MultiBody/Interfaces.mo",
    readonly = false,
    lineStart = 732,
    columnStart = 5,
    lineEnd = 733,
    columnEnd = 65
end OpenModelica.Scripting.SourceInfo;,
    message = "Assertion triggered during translation: \"Connector frame_a of visualizer object is not connected\".",
    kind = .OpenModelica.Scripting.ErrorKind.symbolic,
    level = .OpenModelica.Scripting.ErrorLevel.error,
    id = 98
end OpenModelica.Scripting.ErrorMessage;} 14:19:19:173
#s#; 0.007; 69.318; 'errors:=getMessagesStringInternal()'

comment:7 by Francesco Casella, 6 years ago

The problem when opening the model with d=-newInst is now fixed, all other issues are still there

comment:8 by Francesco Casella, 5 years ago

Milestone: 1.14.01.16.0

Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2. This issue is rescheduled to 1.16.0

comment:9 by Francesco Casella, 4 years ago

Milestone: 1.16.01.17.0

Retargeted to 1.17.0 after 1.16.0 release

comment:10 by Francesco Casella, 4 years ago

Milestone: 1.17.01.18.0

Retargeted to 1.18.0 because of 1.17.0 timed release.

comment:11 by Francesco Casella, 3 years ago

Milestone: 1.18.0

Ticket retargeted after milestone closed

Note: See TracTickets for help on using tickets.