ticket summary component version milestone type owner status created _changetime _description _reporter 2132 getComponentAnnotations should evaluate the parameters Interactive Environment trunk 1.19.0 defect Adrian Pop assigned 2013-03-28T10:14:12Z 2021-09-13T19:50:28Z "getComponentAnnotations should evaluate the parameters inside the annotations and return the correct annotations result. For example, {{{ loadModel(Modelica) getComponentAnnotations(Modelica.Mechanics.MultiBody.World) }}} {{{ true {{Placement(true,0.0,0.0,84.0,-16.0,116.0,16.0,0.0,0.0,0.0,-,-,-,-,0.0)},{},{Dialog(error)},{Dialog(error)},{},{},{},{Dialog(error)},{},{Dialog(error)},{},{Dialog(error)},{Dialog(error)},{Dialog(error)},{Dialog(error)},{Dialog(error)},{Dialog(error)},{Dialog(error)},{Dialog(error)},{Dialog(error)},{Dialog(error)},{Dialog(error)},{Dialog(error)},{Dialog(""Defaults"",""Parameters"",true,false,"""",false)},{Dialog(""Defaults"",""Parameters"",true,false,"""",false)},{Dialog(""Defaults"",""Parameters"",true,false,"""",false)},{Dialog(""Defaults"",""Parameters"",true,false,"""",false)},{Dialog(""Defaults"",""Parameters"",true,false,"""",false)},{Dialog(""Defaults"",""Parameters"",true,false,"""",false)},{Dialog(""Defaults"",""Parameters"",true,false,"""",false)},{Dialog(""Defaults"",""Parameters"",true,false,"""",false)},{Dialog(""Defaults"",""Parameters"",true,false,"""",false)},{Dialog(""Defaults"",""Parameters"",true,false,"""",false)},{Dialog(""Defaults"",""Parameters"",true,false,"""",false)},{Dialog(""Defaults"",""Parameters"",true,false,"""",false)},{Dialog(""Defaults"",""Parameters"",true,false,"""",false)},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{}} }}}" Adeel Asghar 2926 Check uses-annotation on loadFile Frontend trunk 1.19.0 defect Per Östlund assigned 2014-10-22T17:04:22Z 2021-09-13T19:50:28Z "The front-end will now load models from the uses-annotation of a package.mo when loadFile is used. To disable this behaviour, use loadFile(""M/package.mo"", uses=false)." Martin Sjölund 3424 Incorrect result with diffModelicaFileListings Interactive Environment trunk 1.19.0 defect Martin Sjölund reopened 2015-08-26T14:12:55Z 2021-09-13T19:50:28Z `diffModelicaFileListings` produces an incorrect result when `addComponent` is used. Run the attached script. Adeel Asghar 3535 duplicate function names are not detected Interactive Environment 1.19.0 defect Adrian Pop assigned 2015-10-31T19:56:28Z 2021-09-13T19:50:28Z "When a function name is accidentally used twice in a module one might get cryptic messages: Either a not really helping {{{... Failed to elaborate expression ...}}} or a in some cases a more helpful C compiling error: {{{ redefinition of ... with a different type ... }}} Which one depends one usage of the duplicate function." Willi Braun 4372 model replaceable path changes when the model icon is moved and the model becomes no more replaceable OMEdit v1.12.0 1.19.0 defect Adrian Pop accepted 2017-03-27T11:01:56Z 2021-09-13T19:50:28Z "Please consider the following models (also attached): {{{ package P1 model M1 extends Modelica.Blocks.Interfaces.SISO; Boolean Flag = false; Real x = if Flag then u else 0; equation y = 0.5*x; end M1; model M2 extends Modelica.Blocks.Interfaces.SISO; replaceable model Mx = P1.M1; Mx mx annotation(Placement(visible = true, transformation(origin = {-2, 0}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); equation connect(u, mx.u) annotation(Line(points = {{-120, 0}, {-14, 0}}, color = {0, 0, 127})); connect(mx.y, y) annotation(Line(points = {{9, 0}, {110, 0}}, color = {0, 0, 127})); end M2; model M3 P1.M2 m2(redeclare model Mx=P1.M1(Flag=true)) annotation(Placement(visible = true, transformation(origin = {-2, 0}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Blocks.Sources.Step step1(startTime = 0.5) annotation(Placement(visible = true, transformation(origin = {-36, 0}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); equation connect(step1.y, m2.u) annotation(Line(points = {{-24, 0}, {-14, 0}}, color = {0, 0, 127})); end M3; end P1; }}} The model M2 defines the model Mx as replaceable and the model M3 uses M2 redeclaring the model Mx in order to change the Flag parameter value from false to true. Simulating the model M3 the results is according I expect, the Flag parameter value is changed (from false to true) and the step is propagated to the model m2 output. Now open the model M2 and simply move the model mx the line: {{{ Mx mx annotation(Placement(visible = true, transformation(origin = {-2, 0}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); }}} is changed by OmEdit in: {{{ P1.M2.Mx mx annotation(Placement(visible = true, transformation(origin = {-2, 0}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); }}} and the model {{{Mx}}} now seems to be no more replaceable, in fact, re-simulating the model M3 the Flag parameter value now is not propagated and the output y of model m2 stays fixed to 0. Attached are: package P1, output before M1 moving, output after M1 moving. OMEdit 1.12.0~dev-250-g0f5c07d Connected to OpenModelica 1.12.0~dev-561-gc489db1 sysop: Ubunti 14.04 - 34 bit" Andrea Bartolini 4608 Unit string lost in Modelica.Media inheritance chain Interactive Environment v1.13.0-dev-nightly 1.19.0 defect Adrian Pop assigned 2017-11-03T11:39:02Z 2021-09-13T19:50:28Z "Please open the attached test package in OMEdit. Open M2 and double-click on m to set parameters. {{{p1}}} and {{{p2}}} have the correct display unit. {{{p3}}} doesn't show any unit information. Now, {{{p3}}} is of type {{{Modelica.Media.Water.StandardWater.AbsolutePressure}}}, which inherits from {{{Modelica.SIunits.AbsolutePressure}}}, that has {{{unit=""Pa""}}} and {{{displayUnit = ""bar""}}}. This information is somhow lost in the inheritance chain. Please make sure this information is passed correctly to the new API that will be rolled out in 1.13.0 and uses the new front end." Francesco Casella 4809 OMEdit cannot deal with component parameters deriving from more than one inheritance step OMEdit 1.19.0 defect Adeel Asghar new 2018-03-16T16:10:06Z 2021-09-13T19:50:28Z "Please consider the attached test package. Model M1 contains a step source with some parameters. Model M2 extends M1 and changes them to some other values. Model M3 extends model M2. Now, if I double-click on the step source in M3 I see the parameters defined in M1, not in M2. Furthermore, whatever numbers I input as new parameters, they are just ignored by OMC. Maybe this problem is already fixed with the new front-end API, please check." Francesco Casella 4848 Linear equations are not detailed in the debugger OMEdit 1.19.0 defect Adeel Asghar new 2018-03-29T12:28:23Z 2021-09-13T19:50:28Z "Please run the following model in OMEdit with the debugger {{{ model foo Real x, y, z; equation der(z) = 1; x + 3*y = z; x - 2*y = z; annotation(__OpenModelica_commandLineOptions=""--maxSizeLinearTearing=0""); end foo; }}} The linear system of 2 equation is reported twice in the equation browser, once in the set of initial equations and once in the set of regular equation. In both cases, however, only one line is reported {{{ linear, unknowns: 2, iteration variables: 2 }}} with only one index instead of two. There is no information about which variables the system depends, in this case {{{z}}}. Last, but not least, no information at all is given about the A and b matrices. Is this a bug or a feature? " Francesco Casella 5276 Issue with OMEdit formatting due to bug in diffModelicaListings Interactive Environment v1.14.0-dev-nightly 1.19.0 defect Martin Sjölund assigned 2019-01-15T12:25:22Z 2021-09-13T19:50:28Z "Steps to reproduce: see [https://trac.openmodelica.org/OpenModelica/ticket/5187?replyto=8#comment:8 ticket:5187#comment:8] and attachments therein. Probably related to #3424, #3743" Francesco Casella 5328 ODE solver behaves erratically in two MultiBody examples with dynamic state selection Run-time v1.14.0-dev-nightly 1.19.0 defect Karim Adbdelhak new 2019-02-11T16:40:10Z 2021-09-13T19:50:28Z "Steps to reproduce: - set {{{-d=newInst,stateselection}}} - simulate {{{Modelica.Mechanics.MultiBody.Examples.Elementary.SpringDamperSystem}}} The simulation terminates successfully, but the solver statistics and the fairly long simulation time point to some issue with the solver {{{ solver: dassl 53347 steps taken 139199 calls of functionODE 76637 evaluations of jacobian   394 error test failures 25259 convergence test failures 4.2913s time of jacobian evaluation }}} Most importantly, if you cross-check {{{body1.w_a[3]}}} and its derivative, they are definitely not consistent with each other until about time = 2.4; afterwards, they seem more in synch with each other, at first sight. This is strange, because the state selection includes {{{body1.w_a[3]}}} as a state, so the relationship among the two should be derivative/integral, with a relative tolerance of less than 1e-6. If you reduce the tolerance to 1e-7, the shape of the state curve changes, but it remains inconsistent with the derivative during the first two and a half seconds. Maybe the indication of the state selection is incorrect, and what I am seeing is a wrongly computed dummy derivative. The reported state selection is the expected one, maybe the solver is doing something else in the background. This problem does not show up if the old frontend is used to flatten the model, and I am currently investigating what is the difference among the two. Nevertheless, this kind of things should never happen anyway." Francesco Casella 5347 Issues with MSL library handling in Linux Third-Party Libraries 1.19.0 defect Martin Sjölund reopened 2019-02-18T16:00:55Z 2021-09-13T19:50:28Z "Two more models fail in [https://libraries.openmodelica.org/branches/newInst/Modelica_3.2.3/Modelica_3.2.3.html MSL 3.2.3/newInst] than in [https://libraries.openmodelica.org/branches/newInst/Modelica_trunk/Modelica_trunk.html MSL_trunk/newInst]. The failures happen at runtime. [https://libraries.openmodelica.org/branches/newInst/Modelica_3.2.3/files/Modelica_3.2.3_Modelica.Utilities.Examples.readRealParameterModel.sim Modelica.Utilities.Examples.readRealParameterModel] returns: {{{ assert | debug | Not possible to construct full path name of ""modelica://Modelica/Resources/Data/Utilities/Examples_readRealParameters.txt"" | | | | No such file or directory }}} while [https://libraries.openmodelica.org/branches/newInst/Modelica_3.2.3/files/Modelica_3.2.3_Modelica.Electrical.Digital.Examples.RAM.sim Modelica.Electrical.Digital.Examples.RAM] returns {{{ assert | debug | Not possible to construct full path name of ""modelica://Modelica/Resources/Data/Electrical/Digital/Memory_Matrix.txt"" | | | | No such file or directory }}} I'm not sure if something went wrong with the MSL codebase, or if the lack of the statement {{{ if not setCommandLineOptions(""--std=3.2"") then exit(1); end if; }}} in the simulation flags is relevant." Francesco Casella 5405 OMEdit cannot generate 'each' modifiers for parameters of arrays of components NF API 1.19.0 defect Adrian Pop assigned 2019-03-25T23:33:21Z 2021-09-13T19:50:28Z "Drag any component from the Modelica Standard Library into a test system model. Right-click on it, select Attributes and give the component some array dimension (e.g., [3]). Then, try to modify any of the parameters of the component array: the parameter window only allows me to input an array value for each parameter. There is no way to use the {{{each}}} modifier, allowing to only input one value if it is the same for all the components. We should introduce a way to do so in an intuitive way, e.g. with an by adding an {{{each}}} checkbox side by side to the value input field (of course only in the case of arrays of components). BTW, we should also allow to make the parameter final, but that's probably the topic for another ticket." Francesco Casella 5452 Numerical issues due to missing index reduction Backend 1.19.0 defect Karim Adbdelhak reopened 2019-05-02T18:25:29Z 2021-09-13T19:50:28Z "Please consider the results of the simulation of [https://libraries.openmodelica.org/branches/newInst/Modelica_3.2.3/files/Modelica_3.2.3_Modelica.Electrical.Machines.Examples.AsynchronousInductionMachines.AIMC_InverterDrive.sim Modelica.Electrical.Machines.Examples.AsynchronousInductionMachines.AIMC_InverterDrive]. The initialization terminates correctly, but when the simulation starts, the step length is reduced down to 7e-15, and then the simulation fails. It looks like the DAE system is somewhat singular (e.g., locally index 2), in the sense that all state derivatives cannot be uniquely computed at the beginning of the state-space simulator. The same behviour takes place with the old front-end. The exact reason of this singularity is yet unknown, it should be analyzed and then fixed." Francesco Casella 5574 Failed to solve linear system of equations because of wrong dynamic state selection Backend v1.13.2 1.19.0 defect Lennart Ochel new 2019-07-08T19:10:09Z 2021-09-13T19:50:28Z "Dear OM-team, I hope I have assigned correctly the solver problem to Backend. I developed the enclosed small library about DC braking of induction machines for my lectures. There are 4 variants / layouts: Y3 and Y2 simulate without complaints. D2 and D3 fail (but they simulate in Dymola 2020). I have no idea why the linear solver fails - could be a problem of index reduction? Please analyze the problem: * This should improve OM quality. * This would enable me to let students simulate the applications. In case of any questions, do not hesitate to contact me. Many thanks & best regards, Anton Haumer" ahaumer@… 5577 Translation Error When Export FMU Using -d=newInst NF API v1.14.0-dev-nightly 1.19.0 defect Adrian Pop reopened 2019-07-10T12:46:15Z 2021-09-13T19:50:28Z " {{{ import load = ModelicaServices.ExternalReferences.loadResource; Modelica.Blocks.Sources.CombiTimeTable combiTimeTable1(extrapolation = Modelica.Blocks.Types.Extrapolation.Periodic, fileName = load(""modelica://TestPackage/Folder/TestFile.txt""), smoothness = Modelica.Blocks.Types.Smoothness.ConstantSegments, tableName = ""TestTable"", tableOnFile = true); }}} when trying to export above model with uncheck {{{Enable old frontend for code generation}}} option or using {{{-d=newInst}}} with said option enabled, i got following translation error: {{{ [1] 14:39:48 Translation Error Error building simulator. Build log: gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica//include/omc/c/fmi -c -o Test.o Test.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica//include/omc/c/fmi -c -o Test_functions.o Test_functions.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica//include/omc/c/fmi -c -o Test_records.o Test_records.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica//include/omc/c/fmi -c -o Test_01exo.o Test_01exo.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica//include/omc/c/fmi -c -o Test_02nls.o Test_02nls.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica//include/omc/c/fmi -c -o Test_03lsy.o Test_03lsy.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica//include/omc/c/fmi -c -o Test_04set.o Test_04set.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica//include/omc/c/fmi -c -o Test_05evt.o Test_05evt.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica//include/omc/c/fmi -c -o Test_06inz.o Test_06inz.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica//include/omc/c/fmi -c -o Test_07dly.o Test_07dly.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica//include/omc/c/fmi -c -o Test_08bnd.o Test_08bnd.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica//include/omc/c/fmi -c -o Test_09alg.o Test_09alg.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica//include/omc/c/fmi -c -o Test_10asr.o Test_10asr.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica//include/omc/c/fmi -c -o Test_11mix.o Test_11mix.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica//include/omc/c/fmi -c -o Test_12jac.o Test_12jac.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica//include/omc/c/fmi -c -o Test_13opt.o Test_13opt.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica//include/omc/c/fmi -c -o Test_14lnz.o Test_14lnz.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica//include/omc/c/fmi -c -o Test_15syn.o Test_15syn.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica//include/omc/c/fmi -c -o Test_16dae.o Test_16dae.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica//include/omc/c/fmi -c -o Test_17inl.o Test_17inl.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica//include/omc/c/fmi -c -o Test_init_fmu.o Test_init_fmu.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica//include/omc/c/fmi -c -o Test_FMU.o Test_FMU.c In file included from Test_FMU.c:54:0: fmi-export/fmu2_model_interface.c.inc: In function 'omc_assert_fmi_common': fmi-export/fmu2_model_interface.c.inc:162:16: warning: passing argument 1 of 'GC_vasprintf' from incompatible pointer type [-Wincompatible-pointer-types] GC_vasprintf(&str, msg, args); ^ In file included from openmodelica_func.h:52:0, from Test_FMU.c:10: util/modelica_string.h:71:5: note: expected 'const char **' but argument is of type 'char **' int GC_vasprintf(const char **strp, const char *fmt, va_list ap); ^ Test_FMU.c: In function 'setDefaultStartValues': Test_FMU.c:81:82: error: incomplete universal character name \U comp->fmuData->modelData->stringParameterData[0].attribute.start = mmc_mk_scon(""C:\Users\trari\Documents\TestPackage\Folder\TestFile.txt""); ^ Test_FMU.c:81:82: warning: unknown escape sequence: '\D' Test_FMU.c:81:82: warning: unknown escape sequence: '\T' Test_FMU.c:81:82: warning: unknown escape sequence: '\F' Test_FMU.c:81:82: warning: unknown escape sequence: '\T' : recipe for target 'Test_FMU.o' failed make: *** [Test_FMU.o] Error 1 make: *** Waiting for unfinished jobs.... }}}" Trista Arinomo 5590 Bad dynamic state selection leads to singular initialization Backend 1.19.0 defect Karim Adbdelhak new 2019-07-16T13:53:48Z 2021-09-13T19:50:28Z "Consider {{{ModelicaTest.MultiBody.Joints.RevolutePlanarLoopConstraint}}}. It currently fails at initialization because of a [https://libraries.openmodelica.org/branches/master/ModelicaTest_trunk/files/ModelicaTest_trunk_ModelicaTest.MultiBody.Joints.RevolutePlanarLoopConstraint.sim singularity]. The test model has four joints connected in a closed kinematic loop. Dymola chooses two dynamic state selection sets, one with two out of four joint angles, the other with two out of four joint angular velocities. It starts by selecting as states the angle and speed of joints 2 and 4, then later toggles the second speed state between joint 4 and joint 3. OMC statically selects the joint angles 2 and 3 as states, which is probably wrong. It then selects two dynamic states, but I can't see which they are, because {{{-d=bltdump}}} and {{{-d=optdaedump}}} will crash OMEdit. The initialization problem is then singular, most likely due to a bad choice of states. {{{ModelicaTest.MultiBody.InitializationConversion.Joints}}} [https://libraries.openmodelica.org/branches/master/ModelicaTest_trunk_cpp/files/ModelicaTest_trunk_cpp_ModelicaTest.MultiBody.InitializationConversion.Joints.sim fails at initialization] with the C++ runtime, probably for similar reasons, though I did not investigate further. " Francesco Casella 5609 Redeclared model shows icon of base class NF API 1.19.0 defect Adrian Pop new 2019-07-31T16:39:50Z 2021-09-13T19:50:28Z "Please load the attached test package in OMEdit. When opening Test2, the model in the diagram should have an icon with ""M2"". Instead, the icon of the base class, ""M1"", is shown." Francesco Casella 5610 Implement IconMap and DiagramMap annotations OMEdit 1.18.0-dev 1.19.0 defect Adeel Asghar reopened 2019-07-31T16:56:17Z 2021-09-13T19:50:28Z "The {{{IconMap}}} and {{{DiagramMap}}} annotations were introduced in Modelica 3.0 long time ago, but they are still not implemented in OpenModelica. The attached package provides a simple test case. The icon of the model in {{{Test2}}} should only show ""M2"", and the diagram should be rescaled compared to the diagram of {{{M1}}}." Francesco Casella 5621 Issue with FMI import FMI 1.19.0 defect Lennart Ochel reopened 2019-08-28T11:35:45Z 2021-09-13T19:50:28Z "Consider the package fbSystemTest.mo added to ticket #5581 created on 2019-07-12. That ticket was created using OMEdit v1.14.0-dev-5826 (64 bit, win), which was able to create an fmu, and run a system containing that fmu, with a small accuracy issue detailed in that ticket. I repeated that procedure today, using OpenModelica v1.14.0-dev-26545 and got a worse result. In fact, upon trying to run fbSystemFMU one receives the following error message: {{{ [fbSystemPkg: 364:9-364:39]: Operator reinit may only be used in the body of a when equation. }}} the error message points to the first of the reinit rows in following code snippet, automatically generated when creating the fmu: {{{ when {triggerDSSEvent > flowStatesInputs, pre(nextEventTime) < time, terminal()} then newStatesAvailable := fmi2Functions.fmi2EventUpdate(fmi2me); nextEventTime := fmi2Functions.fmi2nextEventTime(fmi2me, flowStatesInputs); if newStatesAvailable then fmi_x_new := fmi2Functions.fmi2GetContinuousStates(fmi2me, numberOfContinuousStates, flowStatesInputs); reinit(fmi_x[3], fmi_x_new[3]); reinit(fmi_x[2], fmi_x_new[2]); reinit(fmi_x[1], fmi_x_new[1]); end if; end when; }}} Appearently, those reinits were well accepted up to last July. Since the issue comes from a VERY basic modelica model, since it used to work just a few weeks ago, I set milestone for this ticket to 1.14.0 " massimo ceraolo 5629 OMEdit does allow to set connectorSizing parameters in some cases OMEdit v1.14.0-dev-nightly 1.19.0 defect Adeel Asghar reopened 2019-09-07T09:33:59Z 2021-09-13T19:50:28Z "If you instantiate the following block in a model: {{{ Modelica.Blocks.MathBoolean.And }}} its parameter pop-up in the graphical view does not show the '''''nu''''' parameter, defined in the {{{ Modelica.Blocks.Interfaces.PartialBooleanMISO }}} interface (used by the '''And''' Block). OMEdit - OpenModelica Connection Editor Connected to OpenModelica 1.14.0~dev-26688-gbe00c7f sysop Ubuntu 18.04" Andrea.bartolini 5639 Issues with WasteWater library *unknown* 1.19.0 defect Per Östlund new 2019-09-20T17:28:56Z 2021-09-13T19:50:28Z "@dietmarw reports some issues with the WasteWater library that we shuould address, because they may also affect other libraries and users quite badly. The first issue is reported in ticket:5461#comment:16 > I think I found another related quirk. I described in the small screen cast. The library version I used to demonstrate is this: https://github.com/dietmarw/WasteWater/releases/tag/v3.0.0-alpha.2 > > Here the screen cast: https://www.dropbox.com/s/7i1pu67j2iyqw46/2019-09-20_OMCNameLookup.mkv?dl=0 On one hand, probably due to component lookup failure by the API, one component icon does not show up. This is a new issue, since some time ago the diagram was displayed correctly. Could be either a NF issue or a nfAPI issue. I don't see anything strange with that lookup, @perost could you comment on that? Furthermore, if a new component is added manually to the text layer, all the icons get broken, as demonstrated in the video. This is quite scary and shouldn't really happen. Additionally, it seems that there are some issues with inner/outer lookup: if I check the model, I get the following error: {{{ [1] 19:22:19 Translation Error [WasteWater.Components: 231:3-231:95]: Variable WWS.BioTreat not found in scope Deni. }}} Now, {{{WWS}}} is the system object, that shows up neatly in the bottom left corner of the diagram, and {{{BioTreat}}} is a parameter of that model, so this is also quite strange. @perost, @adrpo, @adeas31, can you please download the library, check the video, and comment on what is going on in this case? I guess since we have a regression we should try to fix this for 1.14.0. If this turns out to be too time-consuming, we'll reschedule to the next release. Thanks! " Francesco Casella 5649 Summary of issues with diffModelicaListings Interactive Environment 1.19.0 defect Adeel Asghar new 2019-10-01T17:20:31Z 2021-09-13T19:50:28Z "There are some remaining issues with diffModelicaListings which cause OMEdit to apply unwanted modifications to the source code. I collected all the relevant tickets here: #3424, #3567, #4781, #5276, #5644. Ideally we should fix them for 1.14.0, or in some further bug-fix release." Francesco Casella 5650 OMEdit does not update the cache OMEdit v1.14.0-dev-nightly 1.19.0 defect Adeel Asghar new 2019-10-02T07:13:27Z 2021-09-13T19:50:28Z "Working with complex model structure, especially when more tabs are opened, it seems that sometimes OMEdit does not update the cache after modifications made in the text view, either by directly editing the text or, more frequently, after text has been changed using find&replace function. The effect is that a correct model, for example, fails the check, and to have a correct check it is necessary to close and re-open OMEdit. Another strange behavior is happened in diagram view: after diagram modification, changing the tab I've obtained a diagram in which all diagrams present in the opened tabs are overlapped... Unfortunately is not ease to reproduce these malfunctions, especially with small models... My suggestion is to check the code which provides the cache update... OMEdit - OpenModelica Connection Editor Connected to OpenModelica 1.14.0~dev-26749-gf42a582 sysop: Ubuntu 18.04" Andrea Bartolini 5709 Equidistant time grid not working properly *unknown* 1.19.0 defect somebody new 2019-11-23T15:53:53Z 2021-09-13T19:50:28Z "The Simulation setup, checking the option ""equidistant time grid"", while simultaneously unchecking ""Store Variables at events"", should give, in my understanding, control on the number of points stored in the output file. This is very important when one wants to post-process results, for instance using an algorithm to find harmonics in periodic curves, which often require uniform sampling time. Take for instance: Modelica.Electrical.PowerConverters.Examples.DCAC.SinglePhaseTwoLevel.SinglePhaseTwoLevel_R Let us set: - set Stop time: 0.1 - set Number of Intervals 5000 - select ""Equidistant time Grid"" - unselect ""Store Variables at Events"". According to these options, I would expect to have exactly 5001 points in the output file, and, in fact, with Dymola this is what happens. With OM, instead, I produce 4901 points. I suspect that these are not equidistant. " massimo ceraolo 5720 Do not allow to install on directories where the user does not have admin rights Installation program v1.16.0-dev 1.19.0 defect Adeel Asghar new 2019-12-01T09:57:21Z 2021-09-13T19:50:28Z "Since several weeks the windows installation fails for the nightly builds of Openmodelica on my machine. Latest test was today with OpenModelica-v1.16.0-dev-62-g43c7a2d1e3-64bit.exe The error was always the same. I don't know if the problem only appears on my machine. The installation path on the dialog is correct, but the error message seems to indicate that the installer adds \\?\ in front of C: which of course does not exist (see attachement)." anonymous 5724 Make sure OMEdit doesn't break if inappropriate flags are selected OMEdit 1.19.0 defect Adeel Asghar new 2019-12-03T14:46:09Z 2021-09-13T19:50:28Z "OMEdit allows to set any compilation flag by means of the {{{Tools|Options|Simulation|Additional Translation Flags}}} input field. Ticket #5680 shows that at least in one instance, the use of some flags (in this case {{{-m}}}) can cause errors or incorrect/inappropriate behaviour of OMEdit. We should analyze all the [https://openmodelica.org/doc/OpenModelicaUsersGuide/latest/omchelptext.html compilation flags] besides {{{-m}}} to figure out which ones break the correct behaviour of OMEdit. Then, we should issue an error when any of them is included in the setup menu. In case there are some that may still be useful for advanced experimentation or debugging, but potentially dangerous otherwise, we should issue a warning when they are set." Francesco Casella 5732 Translation out of sync OMEdit 1.19.0 defect Adeel Asghar assigned 2019-12-05T00:18:15Z 2021-09-13T19:50:28Z "The swedish translation files, and probably the other languages too, are out currently out of sync. This causes e.g. different error messages than the ones intended to be displayed. For example this model when instantiated with the NF: {{{#!mo model M Integer n; Real x[:] = {i for i in 1:n}; end M; }}} gives the error message: {{{ Error: Det första argumentet av 1:n måste vara ett vektoruttryck. }}} which is the translation for a different error than the error one gets when using english." Per Östlund 5737 "Need to manually insert ""each"" before fixed = false or true statement when initializing a vector" OMEdit v1.14.0-dev.beta2 1.19.0 defect Adrian Pop assigned 2019-12-06T11:25:13Z 2021-09-13T19:50:28Z "When using an initialization such as a_0(start={0,0,0}) and clicking ""fixed"" in OMedit, the word ""each"" is not inserted in front of fixed = true. The translator/compiler does not accept this. So it should read a_0(each fixed=true, start={0,0,0}), but OMEdit now inserts a_0(fixed = true,start={0,0,0}) everytime something is changed using the dialog of a MultiBody component. It took me some time to guess I needed to insert ""each"" in front of the ""fixed"" keyword and it is annoying that I need to do that everytime whenever I use a dialog to change a parameter. Applies at least to Modelica.Mechanics.MultiBody.Parts.Body" gijs.schimmel@… 5743 Export of plotted variables broken for parameters Scripts v.1.15.0-dev 1.19.0 defect somebody new 2019-12-10T17:49:33Z 2021-09-13T19:50:28Z "When using OMEdit to export simulation results (saved as .mat) to .csv files values of parameters are wrong. See for example this CSV snippet with parameters `e` and `g` at some values at start time and end time: {{{ ""time"",""der(h)"",""der(v)"",""e"",""g"",""h"",""v"",""v_new"" 0,0,-9.81,0.7,9.81,1,0,0 0.002,-0.01962,-9.81,0.7,9.81,0.99998,-0.01962,0 0.004,-0.03924,-9.81,0.35,8.50496e-315,0.999922,-0.03924,0 ... 0.982,-2.10336,-9.81,nan,4.45019e-308,0.264509,-2.10336,3.10061 ... 1,-2.27994,-9.81,4.24399e-314,1.3907e-307,0.22506,-2.27994,3.10061 }}} Probably the conversion from .mat to .csv is doing something wrong for constant data. In addition OMEdit can't open the broken csv-files. Related tickets: #2920, #2876" Andreas Heuermann 5775 memory leak in FMUs using CombiTimeTable FMI 1.19.0 defect Lennart Ochel new 2020-01-09T10:42:00Z 2021-09-13T19:50:28Z "Take an extremely simple model with a CombiTimeTable loading a text file. Export the model in FMU. Run the FMU 10000 times: the RAM occupation increases until leading to crash (segmentation error or killed process). The files simulate_fmpy.py and simulate_pyfmi.py in attachment simulate the FMU simple.fmu a few thousands times with the respective libraries FMPY and PyFMI. Running each of them leads to crash." gerrer@… 5799 Initialization solver hangs or fails at start of homotopy process without a clue what it is doing *unknown* 1.19.0 defect Adrian Pop assigned 2020-01-22T23:14:38Z 2021-09-13T19:50:28Z "Please try simulating {{{PowerGrids.Examples.Tutorial.IslandOperation.TwoGeneratorsLocalInitialization}}}. If you add {{{lv=LOG_NLS_V,LOG_INIT_V}}} and simulate it, the solver outputs {{{ ... Global homotopy with equidistant step size started The homotopy path will be exported to PowerGrids.Examples.Tutorial.IslandOperation.TwoGeneratorsLocalInitialization_equidistant_global_homotopy.csv. }}} then it hangs indefinitely at 0% progress. What I find weird is that I get no log output at all. Any idea what is it doing? " Francesco Casella 5828 [NFApi] The -d=nfAPI misses parameters in dialogs Interactive Environment 1.19.0 defect somebody new 2020-02-04T10:57:01Z 2021-09-13T19:50:28Z "Open Modelica.Fluid.Examples.PumpingSystem and double click on pipe to display parameters. When using {{{-d=nfAPI}}} the parameter {{{isCircular}}} is missing and the grouping layout is different. See attached PDF." Adrian Pop 5842 When installing OpenModelica under Ubuntu, MSL 3.2.2 is installed Installation program 1.19.0 defect Martin Sjölund reopened 2020-02-14T14:35:25Z 2021-09-13T19:50:28Z "When installing OpenModelica from scratch on Ubuntu, MSL v. 3.2.2 is installed. Advanced users have developed various strategies to fix this issue and somehow get MSL 3.2.3 going on their system. However, we can't expect beginners to do so. If I ship someone a library with {{{ annotation(uses(Modelica(version=""3.2.3""))); }}} I'd expect it to work out of the box as expected. Why shouldn't it? Can we please fix this in all our currently released versions? " Francesco Casella 5974 OMEdit allows a second simulation to run before first one has quit which causes mysterious crashes OMEdit v.1.15.0-dev 1.19.0 defect Adeel Asghar reopened 2020-05-23T11:39:53Z 2021-09-13T19:50:28Z "If you click on the Simulate button while a simulation is already running (or being compiled) the second process clashes with the first one and either causes errors due to corrupted files, or a core dump if you are more unlucky. It's likely that experienced users are avoiding this so they don't encounter it, but it's a problem in the following scenario. You start up an example and decide that the default ""Stop Time"" of one second is too short, so you open the ""Simulation Setup"" dialog, change it to 10 seconds and click ""Okay"". Now you go back and click on the ""Simulate with Animation"", wait for a few seconds and it mysteriously crashes. Then you try again, wait for a few seconds, and it works. The problem is caused by the ""Simulation Setup"" dialog unhelpfully kicking off a ""Simulate"" process when you clicked ""Okay"", which you didn't know about and you don't even want, because you're going to have to simulate it all over again to see it with animation. At least make the simulate buttons inactive when there is already a simulation running so people don't get these crashes." julian@… 5982 Support macros text strings within diagrams OMEdit 1.19.0 defect Adeel Asghar new 2020-05-26T00:04:44Z 2021-09-13T19:50:28Z "The Modelica Specification, [https://specification.modelica.org/v3.4/Ch18.html#text section 18.6.5.5] allows to put macros in text strings placed in icons and diagrams referring to parameter values. As of 1.16.0, this feature works if the text field shows up in the icon layer, but not if it shows up in the diagram layer, as demonstrated by the attached test case. @adeas31, do you think this can be fixed quickly? I'm not sure if this is an API or an OMEdit problem. I would need that for a demo that could help promoting OpenModelica in the biomedical community." Francesco Casella 5999 icon generator does not work with classnames ending on numeral Scripts v1.16.0-dev 1.19.0 defect Martin Sjölund assigned 2020-06-05T22:48:17Z 2021-09-13T19:50:28Z "When trying to generate the HTML help for the latest 4.0.0 MSL release I noticed that the `generate_icons.py` does not seem to like class names ending on a numeral. So you get an error for `ObsoleteModelica4` {{{ 2020-06-05 23:53:01.154984 Generating SVGs for package(s) ['ObsoleteModelica4'] 2020-06-05 23:53:01,194 - generate_icons.py - INFO - Loading package: ObsoleteModelica4 Traceback (most recent call last): File ""/usr/lib/python3.8/runpy.py"", line 193, in _run_module_as_main return _run_code(code, main_globals, None, File ""/usr/lib/python3.8/runpy.py"", line 86, in _run_code exec(code, run_globals) File ""/usr/lib/python3.8/cProfile.py"", line 196, in main() File ""/usr/lib/python3.8/cProfile.py"", line 189, in main runctx(code, globs, None, options.outfile, options.sort) File ""/usr/lib/python3.8/cProfile.py"", line 19, in runctx return _pyprofile._Utils(Profile).runctx(statement, globals, locals, File ""/usr/lib/python3.8/profile.py"", line 62, in runctx prof.runctx(statement, globals, locals) File ""/usr/lib/python3.8/cProfile.py"", line 100, in runctx exec(cmd, globals, locals) File ""/usr/bin/../share/doc/omc/testmodels/generate_icons.py"", line 1335, in sys.exit(main()) File ""/usr/bin/../share/doc/omc/testmodels/generate_icons.py"", line 1279, in main logger.critical('Failed to load packages in %.1f seconds: %s' % (time.time()-t,omc.sendExpression('getErrorString()'))) File ""/home/dietmarw/.venv/ttws3/lib/python3.8/site-packages/OMPython/__init__.py"", line 606, in sendExpression answer = OMTypedParser.parseString(result) File ""/home/dietmarw/.venv/ttws3/lib/python3.8/site-packages/OMPython/OMTypedParser.py"", line 120, in parseString return omcGrammar.parseString(string)[0] File ""/home/dietmarw/.venv/ttws3/lib/python3.8/site-packages/pyparsing.py"", line 1955, in parseString raise exc File ""/home/dietmarw/.venv/ttws3/lib/python3.8/site-packages/pyparsing.py"", line 3814, in parseImpl raise ParseException(instring, loc, self.errmsg, self) pyparsing.ParseException: Expected end of text, found '4' (at char 117), (line:2, col:38) }}} Unfortunately that error will cause also other icons from being generated. Looking at https://build.openmodelica.org/Documentation/ObsoleteModelica3.html this is an issue that has been around for some time. " Dietmar Winkler 6017 FMUs don't export libopenblas.so FMI v1.16.0-dev 1.19.0 defect Andreas Heuermann assigned 2020-06-17T14:50:08Z 2021-09-13T19:50:28Z "I'm building a static C FMU 2.0 for ModelExchange with OpenModelica and try to simulate it with FMPy in a clean testing environment without omc available. Our OpenModelica FMUs can't be simulated with FMPy since they are missing openblas.so '''How to reproduce''' Note: You will need omc and docker in your path. Also you have to trust my docker container or build your own ;-) Run in your shell: {{{ $ omc buildFMU.mos true """" ""/home/.../ticket6010/BouncingBall.fmu"" """" $ docker run -it --rm -v $(pwd):/testDir anheuermann/fmpy:focal-arm64 /bin/bash root@19cd9af7df5a:/# cd /testDir/ root@19cd9af7df5a:/testDir# ls *.fmu BouncingBall.fmu root@19cd9af7df5a:/testDir# python3 Python 3.8.2 (default, Apr 27 2020, 15:53:34) [GCC 9.3.0] on linux Type ""help"", ""copyright"", ""credits"" or ""license"" for more information. >>> from fmpy import * >>> fmu='BouncingBall.fmu' >>> result = simulate_fmu(fmu) Traceback (most recent call last): File ""/usr/local/lib/python3.8/dist-packages/fmpy/fmi1.py"", line 142, in __init__ self.dll = cdll.LoadLibrary(libraryPath) File ""/usr/lib/python3.8/ctypes/__init__.py"", line 451, in LoadLibrary return self._dlltype(name) File ""/usr/lib/python3.8/ctypes/__init__.py"", line 373, in __init__ self._handle = _dlopen(self._name, mode) OSError: libopenblas.so.0: cannot open shared object file: No such file or directory During handling of the above exception, another exception occurred: Traceback (most recent call last): File """", line 1, in File ""/usr/local/lib/python3.8/dist-packages/fmpy/simulation.py"", line 557, in simulate_fmu fmu = instantiate_fmu(unzipdir, model_description, fmi_type, visible, debug_logging, logger, fmi_call_logger, use_remoting) File ""/usr/local/lib/python3.8/dist-packages/fmpy/simulation.py"", line 646, in instantiate_fmu fmu = FMU2Model(**fmu_args) File ""/usr/local/lib/python3.8/dist-packages/fmpy/fmi2.py"", line 409, in __init__ super(FMU2Model, self).__init__(**kwargs) File ""/usr/local/lib/python3.8/dist-packages/fmpy/fmi2.py"", line 85, in __init__ super(_FMU2, self).__init__(**kwargs) File ""/usr/local/lib/python3.8/dist-packages/fmpy/fmi1.py"", line 144, in __init__ raise Exception(""Failed to load shared library %s. %s"" % (libraryPath, e)) Exception: Failed to load shared library /tmp/tmprujxrrsu/binaries/linux64/BouncingBall.so. libopenblas.so.0: cannot open shared object file: No such file or directory >>> }}} buildFMU.mos {{{ loadString("" model BouncingBall parameter Real e=0.7 \""coefficient of restitution\""; parameter Real g=9.81 \""gravity acceleration\""; Real h(fixed=true, start=1) \""height of ball\""; Real v(fixed=true) \""velocity of ball\""; Boolean flying(fixed=true, start=true) \""true, if ball is flying\""; Boolean impact; Real v_new(fixed=true); Integer foo; equation impact = h <= 0.0; foo = if impact then 1 else 2; der(v) = if flying then -g else 0; der(h) = v; when {h <= 0.0 and v <= 0.0,impact} then v_new = if edge(impact) then -e*pre(v) else 0; flying = v_new > 0; reinit(v, v_new); end when; end BouncingBall;""); getErrorString(); buildModelFMU(BouncingBall, version=""2.0"", fmuType=""me"", fileNamePrefix=""BouncingBall"", platforms={""static""}); getErrorString(); }}}" Andreas Heuermann 6048 FMI testing of models without states behaves in a bizarre way Testing Framework 1.19.0 defect Martin Sjölund new 2020-07-04T17:38:29Z 2021-09-13T19:50:28Z "Please check this [https://libraries.openmodelica.org/branches/history/master-fmi/2020-06-30%2001:01:22..2020-07-02%2001:04:58.html Jenkins report]. About 200 FMI test cases went from almost instantaneous to slightly above 50 seconds. About another 200 went the other way round. The timeout of these tests is set to 50 s, so this may hold a clue. Apparently, what all these tests have in common is that the models have no continuous states. I guess this causes something to go wrong somewhere." Francesco Casella 6052 Issue with analyzeInitialSystem in HanserModelica Initialization 1.19.0 defect Karim Adbdelhak new 2020-07-07T14:25:18Z 2021-09-13T19:50:28Z "There are three models in the HanserModelica library that fail for unspecified reasons during {{{analyzeInitialSystem}}}, see: - [https://libraries.openmodelica.org/branches/newInst/HanserModelica/files/HanserModelica_HanserModelica.Machines.TestDoubleLayer7over9.err HanserModelica.Machines.TestDoubleLayer7over9] - [https://libraries.openmodelica.org/branches/newInst/HanserModelica/files/HanserModelica_HanserModelica.Machines.TestDoubleLayer10over12.err HanserModelica.Machines.TestDoubleLayer10over12] - [https://libraries.openmodelica.org/branches/newInst/HanserModelica/files/HanserModelica_HanserModelica.Machines.TestSingleLayer12over12.err HanserModelica.Machines.TestSingleLayer12over12] @Karim, would you mind having a look at your earliest convenience? I think we should solve these for the next release, so we can claim 100% support over this nice library for teaching." Francesco Casella 6053 Issue with ASCC and state selection in HanserModelica Backend 1.19.0 defect Karim Adbdelhak new 2020-07-07T14:56:28Z 2021-09-13T19:50:28Z "Please check [https://libraries.openmodelica.org/branches/newInst/HanserModelica/files/HanserModelica_HanserModelica.SynchronousMachines.SMEE_ShortCircuit2.err HanserModelica.SynchronousMachines.SMEE_ShortCircuit2]. The backend processing fails at some point because of singular linear equations / circular equalities. I suspect the ASCC algorithm may be involved, since the system contains an induction motor with the usual three-phase inductors current constraint. More specifically, {{{-d=bltdump}}} reports a fixed state selection {{{ 1: smee.phiMechanical:STATE(1,smee.wMechanical)(start = -(3.141592653589793 + gamma0) / /*Real*/(smee.p) unit = ""rad"" fixed = true ) ""Mechanical angle of rotor against stator""HanserModelica.SynchronousMachines.SMEE_ShortCircuit2, Modelica.Magnetic.FundamentalWave.BasicMachines.SynchronousInductionMachines.SM_ElectricalExcited type: Real 2: smee.excitation.electroMagneticConverter.Phi.re:STATE(1)(unit = ""Wb"" ) ""Real part of complex number""HanserModelica.SynchronousMachines.SMEE_ShortCircuit2, Modelica.Magnetic.FundamentalWave.BasicMachines.SynchronousInductionMachines.SM_ElectricalExcited, Modelica.Magnetic.FundamentalWave.BasicMachines.Components.SinglePhaseWinding, Modelica.Magnetic.FundamentalWave.Components.SinglePhaseElectroMagneticConverter, Modelica.SIunits.ComplexMagneticFlux type: Real 3: smee.stator.core.Phi.im:STATE(1)(unit = ""Wb"" ) ""Imaginary part of complex number""HanserModelica.SynchronousMachines.SMEE_ShortCircuit2, Modelica.Magnetic.FundamentalWave.BasicMachines.SynchronousInductionMachines.SM_ElectricalExcited, Modelica.Magnetic.FundamentalWave.BasicMachines.Components.SymmetricMultiPhaseWinding, Modelica.Magnetic.FundamentalWave.Components.EddyCurrent, Modelica.SIunits.ComplexMagneticFlux type: Real 4: smee.stator.core.Phi.re:STATE(1)(unit = ""Wb"" ) ""Real part of complex number""HanserModelica.SynchronousMachines.SMEE_ShortCircuit2, Modelica.Magnetic.FundamentalWave.BasicMachines.SynchronousInductionMachines.SM_ElectricalExcited, Modelica.Magnetic.FundamentalWave.BasicMachines.Components.SymmetricMultiPhaseWinding, Modelica.Magnetic.FundamentalWave.Components.EddyCurrent, Modelica.SIunits.ComplexMagneticFlux type: Real 5: smee.stator.zeroInductor.i0:STATE(1)(unit = ""A"" ) HanserModelica.SynchronousMachines.SMEE_ShortCircuit2, Modelica.Magnetic.FundamentalWave.BasicMachines.SynchronousInductionMachines.SM_ElectricalExcited, Modelica.Magnetic.FundamentalWave.BasicMachines.Components.SymmetricMultiPhaseWinding, Modelica.Electrical.MultiPhase.Basic.ZeroInductor type: Real }}} and immediatly afterwards reports a singularity {{{ [3] 16:47:38 Symbolic Warning The linear system: 1 : smee.is[2] = -smee.is[1] 2 : 3.0 * smee.stator.zeroInductor.i0 = smee.is[1] + smee.is[2] + smee.is[3] [ 1.0 , 1.0 ; -1.0 , -1.0 ] * [ smee.is[2] ; smee.is[1] ] = [ 0.0 ; smee.is[3] + (-3.0) * smee.stator.zeroInductor.i0 ] might be structurally or numerically singular for variable smee.is[1] since U(2,2) = 0.0. It might be hard to solve. Compilation continues anyway. }}} I am pretty sure {{{smee.stator.zeroInductor.i0}}} shouldn't be a state, maybe @christiankral can comment on that. For your reference, Dymola selects a fixed state and four dynamically selected states {{{ Statically selected continuous time states constantSpeed.phi Dynamically selected continuous time states There is one set of dynamic state selection. There are 4 states to be selected from: smee.excitation.electroMagneticConverter.Phi.re smee.is[1] smee.rotorCage.electroMagneticConverter.singlePhaseElectroMagneticConverter[1].Phi.re smee.rotorCage.electroMagneticConverter.singlePhaseElectroMagneticConverter[2].Phi.im smee.stator.electroMagneticConverter.singlePhaseElectroMagneticConverter[1].Phi.re smee.stator.electroMagneticConverter.singlePhaseElectroMagneticConverter[2].Phi.im }}} " Francesco Casella 6071 "Don't show parameter edits in FMU created with ""Evaluate all parameters""" FMI v1.16.0-dev 1.19.0 defect Lennart Ochel assigned 2020-07-28T09:50:02Z 2021-09-13T19:50:28Z "When we create an FMU while ""Evaluate all parameters"" is active, parameter values are hard-coded in the FMU. When we later use the FMU, no trace of this characteristic is there. Steps to reproduce: - open FMUissue.mo. - create a ME FMU from Gain - load the FMU, open Test and connect the output of realExpression to the FMU input - simulate: the output is (correctly) constantly equal to 2 - change K from 2 to 4 in the variables Browser => the output does not change to 4. This is because in reality K=2 was hardcoded in the FMU - go in the modeling perspective, double click on the FMU and change gain1_k from 2 to 4, and simulate => the output is still 2 (again, this is because K=2 is hard-coded in the FMU). This behaviour, although correct, and clear once one has understood what happens, can be very confusing in the beginning. I think that when we create FMUs with the option ""Evaluate all parameters"" active, it should be made impossible to change parameters either from the FMU dialog (before simulating) or from the Variables Browser (before re-simulating). I mean, the edits containing these parameters shud be non-editable." massimo ceraolo 6085 Problem with licensed models OMEncryption 1.19.0 defect Adeel Asghar new 2020-08-17T11:32:00Z 2021-09-13T19:50:28Z "If you open a licensed library with OMEdit, you can also read subpackages for a licensed feature for which you are not authorized. For the following example, you can also open the {{{SubLibrary}}} subpackage, even if you only have access to the feature {{{test_licensed_feature}}}. {{{ package LicenseOptionTest ""License Features"" model Component1 extends LicenseOptionTest.Internal.InternalComponent1; Real a = 1; end Component1; model Component2 extends LicenseOptionTest.Internal.InternalComponent2; Real b = 1; end Component2; package Internal model InternalComponent1 Real internalA = 1; end InternalComponent1; model InternalComponent2 Real internalB = 2; end InternalComponent2; end Internal; package SubLibrary model SubComponent1 end SubComponent1; annotation ( Protection( access = Access.nonPackageDuplicate, features={""test_licensed_feature2""}, )); end SubLibrary; annotation ( Protection( access = Access.nonPackageDuplicate, features={""test_licensed_feature""}, )); end LicenseOptionTest; }}}" Niklas Worschech 6098 (possibly) wrong type mapping for bool in record passed to external object Code Generation 1.19.0 defect Mahder Alemseged Gebremedhin accepted 2020-08-27T06:55:23Z 2021-09-13T19:50:28Z "Summary: A boolean in a record, passed to a external object will result in a wrong C struct for the record. Boolean will be translated to ""signed char"" instead of ""int"". See https://modelica.org/documents/ModelicaSpec34.pdf#page=169 Given a record record MyRecord Real MyReal; Boolean MyBoolean; end MyRecord; that will be passed to a function: function bmaxxAufladung ""Aufladung"" output MyRecord mRecord; external ""C"" externalCFunction(mRecord); end bmaxxAufladung; will result in ""MyModelName_functions.h"" typedef struct { modelica_real _MyReal; modelica_boolean _MyReal; } ModelName_MyRecord; modelica_boolean is defined as ""typedef signed char modelica_boolean;"" in include/omc/c/openmodelica_types.h" Roman 6102 IDAS sensitivity yields absurd results Backend 1.19.0 defect Karim Adbdelhak new 2020-09-02T13:24:21Z 2021-09-13T19:50:28Z "I run forward sensitivity analysis using IDA (https://openmodelica.org/doc/OpenModelicaUsersGuide/latest/parametersensitivity.html) on the following model: model basic parameter Real mu = 2; parameter Real lambda = -1; Real y(start=2, fixed=true); equation der(y) = mu*y + lambda; end basic; Analytic solution of this model is : y(t) = (mu + lambda/mu)*exp(mu*t) - lambda/mu. Analytic sensitivities are thus: s_lambda(t) = (exp(mu*t) - 1/mu (--> increases with time) s_mu(t) = (big nonzero thing)*exp(mu*t) + ctt (--> increases with time) But sensitivity computation yields: $Sensitivities.lambda.y = [0.0, ..., 0.0] $Sensitivities.mu.y = [0.0, ..., 0.0]." gerrer@… 6118 MSVC does not work with Cpp runtime under Windows Build Environment v1.16.0-dev 1.19.0 defect assigned 2020-09-14T17:45:49Z 2021-09-13T19:50:28Z "Selecting msvc15 in OMEdit under Windows, the compilation fails do to spaces in the *.makefile: {{{ include C:/Program Files (x86)/OpenModelica1.16.0-dev-32bit/include/omc/cpp/ModelicaConfig_msvc.inc include C:/Program Files (x86)/OpenModelica1.16.0-dev-32bit/include/omc/cpp/ModelicaLibraryConfig_msvc.inc }}} Attempting to fix the spaces and call `Compile.bat` manually, the compilation continues to fail, then with syntax error for `!IF`. Selecting MinGW, the respective includes become: {{{ include $(OMHOME)/include/omc/omsicpp/ModelicaConfig_gcc.inc include $(OMHOME)/include/omc/omsicpp/ModelicaLibraryConfig_gcc.inc }}} Why `omsicpp` and not `cpp` -- it seems to work though? " Rüdiger Franke 6123 Preserve order of modifiers in OMEdit OMEdit 1.19.0 defect Adeel Asghar new 2020-09-17T09:46:26Z 2021-09-13T19:50:28Z "When parameter values are changed in OMEdit, for some reason the way the changes are applied to the code is that all the modifiers are removed first, and then they are re-applied with modifications. Sometimes this causes the order of the modifiers to change in the declaration of the component instance, particularly if the original model was created by another Modelica tool. This has no consequence per se on the semantics of the model, but it can create lots of bogus diff's in the source code if revision control systems are used, and even create completely bogus merge conflicts, which are particularly annoying to fix. The attached test package demonstrates the issue. Model {{{M}}} has five parameters declared in a certain order. When I create {{{S}}} by dragging an instance of {{{M}}} in it, if I then open the parameter window, the parameters are shown in the same order they are declared. However, if I change them, the modifiers that are saved in the {{{.mo}}} file are lexicographically ordered, as the code of {{{S}}} demonstrates. I then duplicated {{{S}}} into {{{S1}}}, where I kept the same order of the modifiers, but I put each of them on a separate line, which is something people often do to make the source code easier to read, or to allow more fine-grained tracking of modifications on a RCS. I then duplicated {{{S1}}} into {{{S2}}}, doubled-clicked on {{{m}}}, changed the value of {{{b}}}, and saved the file. In this case, the order of the modifiers was preserved, so that only one line in the source code (the one containing the modifier for {{{b}}}) was actually changed. Subsequently, I duplicated {{{S1}}} into {{{S3}}}, where I changed the order of the modifiers with respect to the lexicographical one. This is perfectly legitimate, and may represent how code generated by other Modelica tools, or possibly written manually using a text editor, could look like. Finally, I duplicated the rearranged {{{S3}}} into {{{S4}}}, double-clicked on {{{m}}}, changed the value of {{{b}}} and saved. The result, as you can see, is that the modifiers were reordered lexicographically, thus causing a lot more diff's in the source code than required. Additionally, something went wrong with the diff module, so that some whitespace was added and some was removed. This is a critical issue, because if you open a model created by anther tool (e.g. Dymola) and just change one parameter value, the whole set of modifiers is garbled up. As a consequence, for example, it is not possible to use OMEdit to maintain Modelica Standard Library models that were developed with other tools without messing them up badly. In fact, I always end up using a text editor when working with the MSL, which is safe but not particularly user friendly, because I can't check the code for correctness and I always have to unload and reload the whole MSL all the time, which is really ugly. Thus, I set this as a blocker for 1.17.0. @adeas31, I guess this can be fixed easily by not enforcing lexicographical ordering and by preserving the order of declaration of existing modifiers in the code. I understand this will also need to be applied to the handling of modifiers in redeclared classes and components. @adrpo mentioned an existing ticket on this topic. I couldn't find it, maybe it was on some forum post. If you find it out, please handle it as required. " Francesco Casella 6126 Error while compiling wind turbine model from PowerSystems library New Instantiation 1.19.0 defect Per Östlund assigned 2020-09-20T08:12:37Z 2021-09-13T19:50:28Z "I am getting this error messages while simulating wind turbine example from system library: Power system: [1] 13:39:00 Scripting Warning Requested package Modelica of version 3.2.2, but this package was already loaded with version 3.2.3. You might experience problems if these versions are incompatible. [2] 13:39:00 Translation Error [PowerSystems.AC3ph.Machines: 2208:3-2208:47]: Could not evaluate structural parameter (or constant): n_r which gives dimensions of array: L_r[n_r]. Array dimensions must be known at compile time. [3] 13:39:00 Translation Error Error occurred while flattening model PowerSystems.Examples.Wind.WindTurbine_IG " anonymous 6129 choicesAllMatching doesn't return the appropriate class references Interactive Environment 1.19.0 defect Adrian Pop accepted 2020-09-21T09:52:08Z 2021-09-13T19:50:28Z "Please check the attached simple model, I just dragged a pressure source component {{{boundary}}} in it. When I double-click on {{{boundary}}}, and then click on the Medium drop-down menu, I get about 30 possible classes for redeclarations. However, there are several issues there - some are partial packages, which obviously cannot be used, e.g., {{{Modelica.Media.Interfaces.TemplateMedium}}} - some are found within models but are not encapsulated, so according to [https://specification.modelica.org/v3.4/Ch5.html#composite-name-lookup Section 5.3.2] of the specification, they shouldn't even be looked up, e.g. {{{Modelica.Media.Examples.Tests.Components.ShortPipe.Medium}}} - some are even found inside partial models, e.g. {{{Modelica.Media.Examples.Tests.Components.PartialTestModel.Medium}}} On the other hand, not even one of the actually usable models, e.g. {{{Modelica.Media.Air.SimpleAir}}} or {{{Modelica.Media.Water.StandardWater}}} actually show up. This issue makes OMEdit actually unusable with Modelica Media/Fluid " Francesco Casella 6147 OpenModelica 1.16.0-dev.beta1-64bit OMPython Install Problem OMPython v1.16.0-dev 1.19.0 defect Adeel Asghar assigned 2020-10-01T13:22:56Z 2021-09-13T19:50:28Z "Following the directions at https://github.com/OpenModelica/OMPython Windows 10 Python 3.7.9 Latest pip 20.2.3 Just downloaded OpenModelica Wednesday, September 30. c:\Program Files\OpenModelica1.16.0-dev.beta1-64bit\share\omc\scripts\PythonInterface>python -m pip install -U ERROR: You must give at least one requirement to install (see ""pip help install"") Command Prompt - Regular user or Administrator - same result. It was working with 1.14." anonymous 6150 The debugger output with dummy derivatives is inconsistent and confusing Backend 1.19.0 defect Karim Adbdelhak new 2020-10-05T17:15:55Z 2021-09-13T19:50:28Z "Please consider the following test case (also attached) {{{ model TestDummyDer Real x1(stateSelect = StateSelect.avoid); Real x2(stateSelect = StateSelect.avoid); Real z1(stateSelect = StateSelect.prefer); Real z2(stateSelect = StateSelect.prefer); equation der(x1) = -x1 + x2; der(x2) = x2 - x1; z1 = 4*x1 + 3*x2; z2 = 3*x1 - 2*x2; end TestDummyDer; }}} The debugger shows the following regular equations: {{{ linear (torn), unknowns: 2, iteration variables: 1 (torn) x2 := 1.5 * x1 - 0.5 * z2 (residual) 3.0 * x2 + 4.0 * x1 - z1 = 0 (assign) der(x2) := x2 - x1 (assign) der(x1) := x2 - x1 (assign) der(z1) := 4.0 * $DER.x1 + 3.0 * $DER.x2 (assign) der(z2) := 3.0 * $DER.x1 + (-2.0) * $DER.x2 }}} On the right-hand sides I see symbols {{{$DER.XXX}}} that apparently indicate dummy derivatives. Unfortunately, they are not used on the left-hand sides, nor do they ever show up in the Depends windows. This is very confusing. Shouldn't we use consistent symbols everywhere?" Francesco Casella 6175 stateSelect regression from v1.14.1 to v1.16.0 Backend 1.19.0 defect Karim Adbdelhak assigned 2020-11-03T11:13:00Z 2021-09-13T19:50:28Z The attached model of the 6DOF Rotary Stewart Platform (a parallel mechanism) works with v1.14.1 (64-bit) on Win 10 but doesn't work with the current stable (v1.16.0). Miloš Petrašinović 6196 Undetected high-index DAE or incorrectly handled overdetermined initialization in Buildings model (was: Bogus linear tearing in Buildings model) Backend 1.19.0 defect Karim Adbdelhak assigned 2020-11-08T23:51:41Z 2021-11-15T00:42:19Z "Please check [https://libraries.openmodelica.org/branches/master/Buildings_7.0.0/files/Buildings_7.0.0_Buildings.Electrical.AC.ThreePhasesUnbalanced.Validation.IEEETests.Test4NodesFeeder.BalancedStepDown.YD.sim Buildings.Electrical.AC.ThreePhasesUnbalanced.Validation.IEEETests.Test4NodesFeeder.BalancedStepDown.YD]. The model fails during lambda0 initialization with {{{ Failed to solve linear system of equations (no. 569) at time 0.000000, system is singular for U[2, 2]. Matrix U -0 Output vector x [ 1] 0 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. }}} The debugger shows that system 569 is torn in this way: {{{ linear (torn), unknowns: 3, iteration variables: 1 (transformer.conv2.terminal_p.i[1]) (torn) transformer.conv3.terminal_p.i[1] := transformer.conv2.terminal_p.i[1] - line2.i3[1] (torn) transformer.conv1.terminal_p.i[1] := transformer.conv2.terminal_p.i[1] + line2.i2[1] (residual) line2.i1[1] + transformer.conv1.terminal_p.i[1] - transformer.conv3.terminal_p.i[1] = 0 }}} It is immediate to see that the term {{{transformer.conv2.terminal_p.i[1]}}} appears both in {{{transformer.conv3.terminal_p.i[1]}}} and in {{{transformer.conv1.terminal_p.i[1]}}}, so when those two are subtracted to compute the residual, its sensitivity w.r.t. its unknown is zero. I don't know what criterion is used to perform linear tearing, but it's obviously not a good one. Linear systems should be solved with proper pivoting; solving some equations according only to structural information but disregarding the coefficient values can be very dangerous. Until this issue is solved, I would recommend to disable linear tearing by default. This will sure enough solve a lot of problems in the testsuite. BTW, now that we have sparse solvers to deal with large linear systems, the usefulness of linear tearing is probably quite limited. " Francesco Casella 6228 Updated SUNDIALS KINSOL failing on Cpp runtime Cpp Run-time v1.17.0-dev 1.19.0 defect Andreas Heuermann reopened 2020-11-13T14:53:50Z 2021-09-13T19:50:28Z "With the update of SUNDIALS to 5.4.0 we got some [https://libraries.openmodelica.org/branches/history/newInst/2020-11-09%2020:32:27..2020-11-10%2020:33:05.html new failing test] from MSL with the Cpp runtime. Let's look at the example Modelica.Mechanics.MultiBody.Examples.Loops.Fourbar1 from MSL 3.2.1: {{{ loadModel(Modelica,{""3.2.1""}); getErrorString(); setCommandLineOptions(""-d=newInst --simCodeTarget=Cpp""); getErrorString(); simulate(Modelica.Mechanics.MultiBody.Examples.Loops.Fourbar1); getErrorString(); }}} KINSOL will fail with `KIN_LSETUP_FAIL -11 The linear solver’s setup function failed in an unrecoverable manner.` The Cpp runtime before the [https://github.com/OpenModelica/OpenModelica/commit/cafcb06c93f4c91a97aee51abb0e86f69ed5769a SUNDIALS upgrade PR] passed this test." Andreas Heuermann 6237 Wrong behaviour with conditional equation driven by boolean variable Backend 1.16.0 1.19.0 defect Karim Adbdelhak new 2020-11-22T21:37:19Z 2021-09-13T19:50:28Z "Simulate the model {{{System1}}} in the attached package. Despite {{{closed}}} being identically bound to {{{true}}}, the current {{{T.port_a.i}}} remains identically zero during simulation. The correct simulation is obtained by uncommenting the equation without the conditional expression in {{{TransmissionLine}}}. Given the binding of {{{closed}}}, the two should obviously be identical." Francesco Casella 6294 The complexity of matching and sorting deteriorated badly between 1.13 and 1.14 Backend 1.16.0 1.19.0 defect Karim Adbdelhak new 2020-12-17T16:47:01Z 2021-09-13T19:50:28Z "Please compare the performance of SteamPipe_N in the ScalableTestSuite, between [https://libraries.openmodelica.org/branches/v1.13/ScalableTestSuite_noopt/ScalableTestSuite_noopt.html v. 1.13] and [https://libraries.openmodelica.org/branches/v1.14/ScalableTestSuite_noopt/ScalableTestSuite_noopt.html v 1.14]. The times spent by matching and sorting are || N || 1.13 || 1.14 || 160 || 0.21 || 6.1 || || 320 || 0.06|| 21.8|| || 640 || 1.44|| 91.6|| We already discussed this issue extensively in #5952, but apparently there is still someting wrong there. @Karim, can you please check?" Francesco Casella 6363 MSL 4.0.0 including Clocked supported by OM 1.16.2? *unknown* 1.16.2 1.19.0 defect Andreas Heuermann assigned 2021-02-01T17:16:20Z 2021-09-13T19:50:28Z "It seems to me: yes, but 2 aspects seem to be wrong: 1. It seems to me that the initial trigger is ignored. E.g. the sampled setpoint (Examples 3 and 4) starts with zero, then jumps. 2. One example (3. BoilerClocked) is horribly wrong: the control error doesn't vanish. I played around with clocked while preparing a course, and implemented a simple boiler model step by step with different controllers: 1. BoilerTriac using a continuous LimPID. 2. BoilerSampled sampling I/O of the continuous LimPID. 3. BoilerClocked using a clocked section with the continuous LimPID. 4. BoilerDiscrete using a clocked section with a discrete PI." ahaumer@… 6377 Avoid generating dense Jacobian above a certain size and set default solvers accordingly *unknown* 1.18.0-dev 1.19.0 defect Karim Adbdelhak assigned 2021-02-15T18:56:11Z 2021-09-13T19:50:28Z "From what I can understand, the choice between using dense and sparse solvers is deferred to the runtime, since simulation flags such as {{{-s}}}, {{{-idaLS}}}, {{{-nls}}}, {{{-nlsLS}}} etc. allow to pick which one is used after the code has been compiled. This is relevant in several contexts where Jacobians are needed: - initial equations - lambda0-initial equations - algebraic loops in {{{odeMode}}} - symbolic Jacobians for stiff ODE solvers - DAE Jacobians in {{{daeMode}}} I guess setting {{{-daeMode}}} avoids the generation and use of dense Jacobians for the direct DAE solution, which is really only possible with sparse solvers. @Karim, @AnHeuermann, could you please confirm that? Anyway, I guess we should also skip building, analyzing, and generating code for dense jacobians in all other contexts, as soon as their size/density exceeds a certain threshold, which should be defined by compiler flags, and later read and used as default by the runtime. For sure it makes no sense to waste time and memory handling dense matrices with more than a few hundred lines and columns, if they are sparse and sparse solvers are available. See also #6342 for a discussion on the criteria. Doing this should automatically ensure that reasonable choices are taken by default in terms of whether or not generating code for sparse/dense solvers, and in terms of automatic choice of the right solver given the structure and size of the problem." Francesco Casella 5297 Support of conversion scripts Interactive Environment 1.19.0 enhancement Per Östlund assigned 2019-01-24T22:12:00Z 2021-09-15T13:17:03Z "The decision of the MAP-LIB group for the next release of the MSL is that we make a major 4.0.0 release with a thorough clean-up, that will require the use of conversion scripts to update other libraries to this new version. The requirement is that the conversion can be made 100% automatic with the available conversions in the Modelica specification. This will probably take about two years before the release. This means OpenModelica will need to support conversion scripts to work with the next MSL version. I think we should have this feature ready for omc 2.0.0, though we could postpone it to 2.1.0 based on the status of MSL 4.0.0 at the time of the omc 2.0.0 release. In fact, I already proposed to the MAP-LIB group that we use the OpenModelica CI infrastructure to test that the provided conversion scripts are fine, by running them on all the open-source libraries that we have in the testsuite and then testing them with MSL 4.0.0-development. Once we have the scripts implemented, I understand this feature requires very little setup work of Hudson/Jenkins, although it may require some additional hardware resources - we could ask the MA to pay for that, and offer this service to the MAP-LIB developers." Francesco Casella 5487 Add -nfAPI flag to existing API tests in the testsuite Testing Framework 1.19.0 enhancement Adrian Pop new 2019-05-17T08:26:16Z 2021-09-13T19:50:28Z As agreed with Adrian at today's Board Meeting. Francesco Casella 5488 Complete coverage test of MSL 3.2.3 OMEdit NF API calls Testing Framework 1.19.0 enhancement Adrian Pop new 2019-05-17T08:32:45Z 2021-09-13T19:50:28Z "Before we release 1.14.0, we need to make sure that OMEdit won't crash because of some bugs when trying to open models in the GUI and changing their parameters and replaceable classes or components. I think making sure that doesn't happen with MSL 3.2.3 is a good starting point, we may later extend this to the whole library, if this doesn't take too much time (maybe we could run the entire testuite only once per week or so). As the NF is much faster than the OF, this should now be feasible. This requires setting up a test script that makes all the NF API calls that are required to - display all the diagrams of MSL 3.2.3 models that have components with graphical annotations - display all the parameters and replaceable classes/components of components of MSL 3.2.3 models that have graphical annotations " Francesco Casella 5731 One-click bug report solution for OMEdit OMEdit 1.19.0 enhancement Adeel Asghar new 2019-12-04T07:52:52Z 2021-09-13T19:50:28Z "Current status: Reporting a bug requires the user of OMEdit to know: - that OpenModelica is using trac for issue tracking - how to generate a log file and where it is stored on his machine Furthermore he will have to: - login to trac, open a ticket - find the version number in the about box and copy&past it in the ticket, - explain the problem, - enable logging, reproduce the error, - find and attach the log file. Conclusion: These are a lot of steps and some require knowledge that is not obvious, not easily discoverable from the UI or not even well documented on the OpenModelica website. As bug reports are a very valuable asset for reaching a higher level of software quality we should lower the threshold for users to report their findings. Proposal: OMEdit should provide a ""Report Bug"" command in the help menu. This should open a window that gives some basic information and provides the following features to: - enable logging - empty the log file - open the file location to the log file - open a new ticket: - go to the trac login site - create a new ticket - fill in the version information and Component: ""OMEdit""" Oliver Lenord 5811 Install OMC for Jenkins in the most problematic paths Testing Framework 1.19.0 enhancement Adrian Pop new 2020-01-30T10:50:29Z 2021-09-13T19:50:28Z "OMC has always been plagued by issues in the installation and working directory path, as soon as it contains spaces and non-ASCII characters, which happens very frequently under Windows, where {{{Program Files}}} is the norm for the former and {{{Documents and Settings}}} is often the norm for the latter, not to mention usernames with spaces, accented or cyrillic characters. There are dozens (hundreds?) of scripts being run by OMC on various occasions that can go wrong because of this, not to mention related tools such as OMNotebook, OMSens, OMSimulator, etc. We already took the decision to support all those cases, see #4504, so we should test this systematically. I would suggest that we install the Windows testing machine on a directory such as {{{ c:\Program Files\OpenModelica1.16.0-dev-64bit\ }}} and set the default temp directory to something like {{{ c:\Temp\Users\Martin Sjölund\ }}} so that we make sure everything works in those potentially critical case. " Francesco Casella 5862 Make it possible to manage variable modifiers in OMEdit OMEdit 1.19.0 enhancement Adeel Asghar new 2020-02-24T12:08:56Z 2021-09-13T19:50:28Z "One way to manage input variables in Modelica is through modifiers. There are in fact two basic patterns: {{{ model M1 input Real u; end M1; model M2 Real u = 0; end M2; model S M1 m1(u = sin(time)); M2 m2(u = cos(time)); end S; }}} The former makes it mandatory to provide a binding equation when instantiating the model. The latter makes it optional, since it provides a default binding in the model code. This pattern is used extensively by the {{{PowerGrids}}} library. Currently, OMEdit only allows to use this pattern from the text view of models. For example, if you take the attached test case package, open model {{{S}}} and double-click on {{{m}}}, there is indeed a Modifier tab in the parameter window, but you can't put a modifier like {{{u = 3}}} in there. We need to provide two additional functionalities: - be able to provide binding equations for public variables - make them clearly visible and editable when the parameter window is later re-opened @adrpo, @adeas31, can you please assess how much work is required and report it here? I tentatively schedule this feature for 1.16.0, but we may postpone it to a later version if it turn out to be non-trivial to implement." Francesco Casella 6029 Add new MSL 4.0.0 reference files to Jenkins for Cppruntime Testing Framework 1.19.0 enhancement Martin Sjölund new 2020-06-24T01:14:48Z 2021-09-13T19:50:28Z From this [https://github.com/modelica/MAP-LIB_ReferenceResults GIT LFS repo] Francesco Casella 6039 Allow to change parameters before resimulating when -iif is used to import start values Run-time 1.19.0 enhancement Andreas Heuermann new 2020-06-30T10:18:18Z 2021-09-13T19:50:28Z "The [https://openmodelica.org/doc/OpenModelicaUsersGuide/latest/simulationflags.html#simflag-iif -iif] flag allows to import start values for parameters and variables from the results of previous simulations. These can be used to ensure the convergence of the initialization equations, or possibly be used directly to start the simulation, if [https://openmodelica.org/doc/OpenModelicaUsersGuide/latest/simulationflags.html#simflag-iim -iim=none] is also set. These flags can be set in OMEdit from the Simulation Setup window, Simulation Flags, Equation System Initialization File/Time. As far as I understand, when the simulation executable is run, it first reads in the start values from the {{{_init.xml}}} file, and then it overwrites whatever values are found in the {{{-iif}}} file before starting the simulation. @AnHeuermann, please correct me if I'm wrong here. Unfortunately, this means that it is not possible to import all the start values and parameters of a previous simulation, ''change some parameter values'' in the Variables Browser, and then restart a simulation that will produce results different from the imported simulation, because the the changed parameter values will end up in the {{{_init.xml}}} file and will be overriden by the imported values. As a matter of fact, this makes the whole {{{-iif/-iim}}} thing not very useful in practice, if used from OMEdit, because it only allow to re-run an existing simulation, possibly only changing the solver or the solver parameters. We need to find a way to make this possible, in an easy and intuitive way. The most natural idea that comes to my mind is to have another runtime option, say {{{-iis}}}, which selects what start values should actually be imported from the file when the {{{-iif}}} option is activated. Possible values: - {{{-iis=all}}} (default) import everything, as it happens today - {{{-iis=nostates}}} import everything, except start values of state variables - {{{-iis=noparams}}} import everything, except start values of {{{fixed = true}}} parameters - {{{-iis=nostatesnoparams}}} combines the two previous options Adding this option to the Simulation Setup | Translation Flag window will solve this issue, enabling a wide range of interesting use cases, without the need of further work in OMEdit. In particular, it will make possible to change parameters and/or initial state values before resimulating. The {{{-iis=noparams}}} option should only affect {{{fixed = true}}} parameters, which are the ones that can be changed from the Variables Browser before resimulating. {{{fixed = false}}} parameters are determined by initial equations, so I think it makes more sense to keep the imported start values for them, to avoid convergence problems. The only shortcoming I see of this solution is that the {{{-iis}}} flag will apply broadly to the entire set of parameters/initial states. This means, it won't be possible, e.g., to import all the parameter and initial states from the file ''except some'', that may be changed before resimulating. It would be nice if we could actually do that, but I'm afraid this can't be done easily with the current OMEdit workflow, which is based on the GUI updating the {{{_init.xml}}} file, which is always read before {{{-iif}}} is applied. Any suggestion about how to overcome this limitation in a simple way would be welcome, I have no idea how to do that." Francesco Casella 6051 Provide better feedback on advance rate of simulations in OMEdit OMEdit 1.19.0 enhancement Adeel Asghar new 2020-07-06T15:59:02Z 2021-09-13T19:50:28Z "As of today, the Simulation Output windows has a progress bar, that shows to which point the simulation has progressed so far, in terms of simulated time, e.g. if StartTime = 0 and StopTime = 1000, 35% means the simulation reached 350 s. When the simulation becomes difficult for some reason (e.g. chattering, highly nonlinear behaviour) the step size of adaptive solvers is drastically reduced, and the progress bar remains stuck forever at a particular percentage value, without providing any useful feedback on what is going on. It would be nice if we also added two textual outputs to the progress bar: one is the current simulation time (with at least 5 significant digits) and one is the value of the current simulation step length, or possibly the average of the last N step lengths. The typical use case is very lengthy simulations (requiring e.g. 20 minutes of CPU times) which get stuck at some specific point. Being able to pinpoint when this happens with high precision helps to speed up the debugging dramatically." Francesco Casella 6142 Allow to set parameter values in redeclared elements in OMEdit OMEdit 1.19.0 enhancement Adrian Pop new 2020-09-29T08:30:19Z 2021-09-13T19:50:28Z "After #2079 was closed, OMEdit can handle replaceable classes and redeclare statements without modifiers. It should also be possible to set modifiers on parameters (and possibly replaceable classes) of the redeclared class. The attached package provides a non-trivial test case involving multiple inheritance." Francesco Casella 6416 Error in Implementation of the delay function Code Generation 1.16.5 1.19.0 task Andreas Heuermann assigned 2021-03-10T12:54:17Z 2021-09-13T19:50:28Z "Greetings! I hope you're having a nice day! So please hear me out. I am relatively an advanced beginner in OpenModelica and I am currently working on a project for my thesis. I need to use the delay function in my code for a Real variable. However, while the function works perfectly on one of the variables I need delayed, there are multiple variables that I need delayed. When I implement this for multiple variables with the same time delay constant, I get an error. If you could help me interpret and resolve this error, it would be greatly helpful. {{{ error: 'equationIndexes' undeclared (first use in this function) #define DIVISION_SIM(a,b,msg,equation) (__OMC_DIV_SIM(threadData, a, b, msg, equationIndexes, data->simulationInfo->noThrowDivZero, data->localData[0]->timeValue, initial())) note: in expansion of macro 'DIVISION_SIM' storeDelayedExpression(data, threadData, 1, DIVISION_SIM(data->simulationInfo->realParameter[42] /* k4 PARAM */,data->localData[0]->realVars[67] /* v variable */,""v"",equationIndexes), data->localData[0]->timeValue, data->simulationInfo->realParameter[78] /* tDelay PARAM */, data->simulationInfo->realParameter[78] /* tDelay PARAM */); note: each undeclared identifier is reported only once for each function it appears in #define DIVISION_SIM(a,b,msg,equation) (__OMC_DIV_SIM(threadData, a, b, msg, equationIndexes, data->simulationInfo->noThrowDivZero, data->localData[0]->timeValue, initial())) note: in expansion of macro 'DIVISION_SIM' storeDelayedExpression(data, threadData, 1, DIVISION_SIM(data->simulationInfo->realParameter[42] /* k4 PARAM */,data->localData[0]->realVars[67] /* v variable */,""v"",equationIndexes), data->localData[0]->timeValue, data->simulationInfo->realParameter[78] /* tDelay PARAM */, data->simulationInfo->realParameter[78] /* tDelay PARAM */); Compilation process failed. Exited with code 2. }}} I'd be thankful for any help! Thanks in advance!" Guru Charan Das M 2282 Dynamic State Selection doesn't work on simple planar pendulum model Run-time trunk 2.0.0 defect Karim Adbdelhak assigned 2013-07-15T14:01:08Z 2019-04-04T22:26:20Z see OM forum [https://openmodelica.org/index.php/forum/topic?id=966] Willi Braun 2484 Expandable connector resolution misses components New Instantiation trunk 2.0.0 defect Per Östlund assigned 2013-11-17T11:34:57Z 2019-05-10T08:03:45Z "The following model is fine in Dymola (and AFAIK according to the spec): {{{ #!mo model Test import Modelica.Constants.small; expandable connector Bus end Bus; expandable connector SubBus end SubBus; connector C Real x; end C; model Component1 Bus bus; SubBus subBus; C c; equation connect(bus.subBus, subBus); connect(subBus.c, c); c.x = 42; end Component1; Component1 component; C c; Bus bus; equation connect(bus, component.bus); connect(c, bus.subBus.c); end Test; }}} omc complains about subBus not being part of bus. This can be fixed (although not in this test case due to #2385) by adding explicit connections for each subcomponent. Version used: 1.9.0 (r17628) " Christoph Höger 2850 Redeclared models use wrong icon OMEdit trunk 2.0.0 defect Adeel Asghar new 2014-09-29T18:47:26Z 2016-08-25T21:53:20Z "I created a base object, and then extended it to create other objects. I then used the base as a replaceable object inside another model. So, far so good. If I then create another model, based on that, but redeclare that object, OMEdit shows the ""lower"" object, and not the extended one. That means, for example, that I can't see new connections that have been added by extending. The underlying code works fine, but there is no graphical way to make connections to this object, since I can see the ports, and can't click on them to connect. But, if I do the connections, by editing the text file, the actual simulations does run fine. As the above is probably not as clear as I would like, I have generated a simple test case. In the attached, Test2 does not run, since I have not made the extra connection (and the connection is not shown) and Test3 does work, but again, there is no visible connection between the second sine source, and the object. But, more specifically, Test2 and Test3 both show an object that appears to be ""ObjectSuper1"" but the code behaves, correctly, as though these are ""ObjectSuper2"". So OMEdit, should be showing the icons for these as ""ObjectSuper2"". I believe that I am correctly using replaceable, extends and redeclare, but that OMEdit, is not following them correctly. I am using OMEdit 22485 on a Mac. " Adam Dershowitz 4120 Out-of-bounds array elements undetected by front-end New Instantiation 2.0.0 defect Per Östlund assigned 2016-10-29T19:21:42Z 2020-05-11T08:35:27Z "{{{ model foo function f input Real[2] x; output Real[2] y; output Real[2] z; algorithm y[1] := 2*x[1]^2 + 1; y[2] := 3*x[2]^3 + 2; z[1] := -y[1]/2+1/2+7; z[2] := -y[2]/3+2/3-7; annotation(Inline=true); end f; Real[2] y(each start = -1); Real[2] w(each start = -1); Real z1, z2, z3; equation (, w) = f({y[1] + z3, y[2]}); (, w) = f({y[1] + w[1], y[2] + w[3]}); der(y[1]) = -z1*y[2] +1; der(y[2]) = -z2*y[1] + z1*y[2] +3; z3 = time; end foo; }}} where `w[3]` is undefined." Vitalij Ruge 4141 Important missing feature: Allow save and opening of Modelica files containing syntax errors OMEdit v1.11.0 2.0.0 defect Adeel Asghar new 2016-11-15T11:53:25Z 2016-11-15T12:20:21Z "The current implementation of the OMEdit text editor makes it unfortunately unsuitable to use for teaching Modelica for beginners. The issue is the following. New beginner do mistakes when they work on their models. And since they are beginners it might take time to fix all the issues. But since OMEdit does neither save nor open Modelica files with syntax errors the students are actually afraid to use that tool at all in order to do the modelling work. Because not being able to save your work means loosing it. The only work around is to have to work in an external editor and try loading a file until it is fixed. This is cumbersome and also encourages to actually use other file editors instead because OMEdit is basically flawed. Not good at all. So I would like you go give this a very high priority since this is from our practically experience with students who are running away from OMEdit and which results in Modelica leaving a bad taste." Dietmar Winkler 4143 Initialization of systems with dynamic state selection is not handled properly Backend 2.0.0 defect Karim Adbdelhak assigned 2016-11-15T22:56:55Z 2019-07-08T22:57:25Z "Lennart Ochel wrote me: There is no approach in OpenModelica to select properly the initial states for the state sets yet [for the initialization of dynamic state selection]. Right now we choose the states randomly that are used for the initialization phase. This should be fixed for the 2.0.0 release. " Francesco Casella 4293 Bad strategy to solve rational equations Backend 2.0.0 defect Karim Adbdelhak assigned 2017-03-01T21:19:38Z 2020-11-09T17:58:39Z "Please consider the package contained in the attached .mo file. It contains a model with an implicit rational equation to compute {{{mu}}} given {{{p}}} and {{{T}}} {{{ T = r_mu * (p *1e-5) / (mu * 1e7 - c_mu) - a_mu / (mu * 1e7 * (mu * 1e7 + b_mu) + b_mu * (mu * 1e7 - b_mu)); }}} The equation is equivalent to a polynomial equation, which is obtained by multiplying both sides of the equation by the product of all the denominators. The polynomial equation has the same roots, but its residual is more well-behaved, as it doesn't have singular points (vertical asymptotes). So, it might be convenient to turn the original equation into a cubic one for improved convergence robustness. However, OMC does it by fully expanding the polynomials, thus obtaining this very complex expression that I got from the info.json file {{{ -2e+016 * p * r_mu * b_mu * 10000000.0 * mu ^ 4.0 + c_mu * p * r_mu * b_mu * -2000000000.0 * c_mu * mu ^ 2.0 + 10000000.0 * p * r_mu * -1e+016 * (10000000.0 * mu - c_mu) * mu ^ 4.0 + 100000000000000.0 * T * b_mu * (10000000.0 * mu - c_mu) ^ 3.0 * mu ^ 2.0 + T * 1e+021 * (10000000.0 * mu - c_mu) ^ 3.0 * mu ^ 2.0 * mu + 100000000000000.0 * b_mu * T * 10000000.0 * ((10000000.0 * mu - c_mu) * mu) ^ 2.0 * mu + (10000000.0 * mu - c_mu) * ((-c_mu) * (a_mu + (-b_mu) * b_mu * T) - ((-a_mu) - (-b_mu) * b_mu * T) * 10000000.0 * mu) * (10000000.0 * mu - c_mu) ^ 2.0 + b_mu * T * c_mu * -100000000000000.0 * ((10000000.0 * mu - c_mu) * mu) ^ 2.0 + p * r_mu * b_mu ^ 2.0 * 1e-005 * (10000000.0 * mu - c_mu) ^ 3.0 + c_mu ^ 2.0 * -200.0 * p * r_mu * b_mu * (10000000.0 * mu - c_mu) * mu + c_mu ^ 2.0 * -1000000000.0 * p * r_mu * (10000000.0 * mu - c_mu) * mu ^ 2.0 + (-c_mu) * -10000000.0 * b_mu * T * c_mu * 10000000.0 * (10000000.0 * mu - c_mu) * mu ^ 2.0 + -100000000000000.0 * c_mu * 10000000.0 * b_mu * T * (10000000.0 * mu - c_mu) * mu ^ 2.0 * mu + 1e+016 * r_mu * p * c_mu * mu ^ 3.0 * (10000000.0 * mu - c_mu) + (-c_mu) * 10000000.0 * T * b_mu * (10000000.0 * mu - c_mu) * mu * (10000000.0 * mu - c_mu) ^ 2.0 + (-c_mu) * 100000000000000.0 * T * (10000000.0 * mu - c_mu) ^ 3.0 * mu ^ 2.0 + (-c_mu) * 10000000.0 * b_mu * T * -10000000.0 * c_mu * (10000000.0 * mu - c_mu) * mu ^ 2.0 + c_mu * -10000000.0 * b_mu * T * c_mu ^ 2.0 * (10000000.0 * mu - c_mu) * mu + 2000000000.0 * c_mu * p * r_mu * b_mu * (10000000.0 * mu - c_mu) * mu ^ 2.0 + 1e+016 * c_mu * p * r_mu * (10000000.0 * mu - c_mu) * mu ^ 3.0 + mu ^ 3.0 * c_mu * 4.000000000000001e+016 * p * r_mu * b_mu }}} This expression is about 10 times more time consuming to compute. Furthermore it is numerically ill-conditioned, since it involves the summation of very large terms that may be both positive and negative, which is well known as a numerical no-no. Polynomials should be computed using Horner's rule, not by expanding them to individual power terms. As a consequence, the nonlinear solver behaves erratically, while the original equation has a rather well-behaved shape in a large neighbourhood of the solution. The attached test.mos file provides two test cases demonstrating the problem. In the first case, the default solver is used. The log file shows that the solver fumbles around for a while, then eventually accepts the start value as the solution (!!), probably because of really bad scaling of the residual. This is really unacceptable, because no error is issued, though the solution is completely bogus. It is OK if we cannot solve some problems, but claiming they're solved when they aren't is really dangerous. Please also note that all the involved variables have nominal values for scaling. If the kinsol solver is used, the simulation fails at initialization, which is at least a consistent behaviour. Dymola can solve this equation without problems. Apparently, it does not transform it to an equivalent polynomial form at all. Q1: What is the rationale behind the symbolic transformation carried out by the back-end? Q2: Is it possible to turn it off and see what happens? Q3: Why does the default solver accept such a bad solution for the equation?" Francesco Casella 4496 Complex 'sum' does not work New Instantiation 2.0.0 defect Per Östlund assigned 2017-08-09T16:33:43Z 2019-05-09T06:50:51Z "Please consider the following example: {{{ model TestComplexSum parameter Complex a[2]={Complex(1,2),Complex(2,3)}; parameter Complex sum1 = Modelica.ComplexMath.'sum'(a); parameter Complex sum2 = Complex(sum(a.re),sum(a.im)); end TestComplexSum; }}} The sum of vector {{{a}}} is calculated in two different ways, so the results shall be equal. However, in OpenModelica {{{sum2}}} is calculated correctly, whereas {{{sum1}}} results in {{{ sum1.re -> 0 sum2.re -> 0 }}} Too bad: The application of function {{{'sum'}}} is utilized in the actual trunk version of the MSL in order to calculate the the total apparent power in {{{Modelica.Electrical.QuasiStationary.MultiPhase.Sensors.MultiSensor}}}. I would not really like to switch to the alternative calculation of sum1... Do you think there is a chance, that this issue is going to be fixed in OpenModelica 1.12? The reason I am asking is that I am planning to refer to OpenModelica in a publication so, so I am not sure if can include a related example or not." Christian Kral 4536 OMEdit fails to update relative class names to absolute ones upon duplicate Interactive Environment 2.0.0 defect Per Östlund assigned 2017-09-29T08:44:15Z 2017-10-10T12:38:35Z "I noticed that when one duplicates a class or package of classes and the new location is outside the current level, OMEdit will not update the class references contained in the classes to be duplicated. This renders them simply useless. Example: 0. Create a new package ""Test"" on top level. This actually is another bug that one needs a top-level package. Normally one should be able to create a new model/package also on top-level via duplicate 1. Right click on `Modelica.Electrical.Machines.Examples.AsynchronousInductionMachines.AIMC_DOL` and choose ""duplicate"" 2. Select the ""Test"" package and click OK. 3. Open the newly duplicated package and notice that several components are broken since they were originally using relative references that are not updated when duplicating them. This is actually quite sever since I teach beginners to play around with '''existing''' examples from the MSL. And the only way to do changes to them is to duplicate them and then change parameters etc." Dietmar Winkler 4598 OMEdit should not hang for more than a few seconds OMEdit 2.0.0 defect Adeel Asghar new 2017-10-30T01:25:59Z 2017-12-07T14:21:51Z "A typical end-user experience when using OMEdit is that some action is initiated via the GUI, the pointer turns into an hourglass for a long (sometimes very long) time, without any possibility of interaction and without any feedback. This is quite annoying and gives a general impression of lousiness of the tool, as one has no idea if and when he/she will be back in control. For operations involving the browsing of libraries and the graphical building of models by dragging and dropping, the problem is well-known, see #2960, and it should hopefully be solved by the new API based on the new front-end, which is expected to be one order of magnitude faster or more. For operations like starting a simulation, however, the availability of the new front end will not be enough. There are reasonable and not particularly large end-user models that can take one or two minutes for flattening, back-end processing and code generation. During this time, the end-user should continuously get feedback about what is going on, as well as be allowed to do other things with OMEdit that do not involve the current simulation, e.g., browsing simulation results or other Modelica models. No more hourglass, please :) In particular, the ""Compilation"" tab of the simulation output windows should report at least the main milestones of the code generation, such as those that you can get out of -d=exectstat, see also #3565 and the discussion therein. It could also be nice if the bottom slice of the OMEdit window, which contains the Modelling, Plotting and Debugging tab selectors, also showed some indication of the CPU and disk activity of the OMEdit process and of its children, which can be very resource-intensive, as we all know. In this way, one gets a feeling that OMEdit is doing something and is not simply stuck. On Windows, I always run the Task Manager for this purpose, and htop on Linux, but that's not something that the newbie user would do, and it's not particularly user-friendly anyway. Last, but not least, it should be possible to abort the compilation of a model anytime, also during the first phases such as flattening. If one accidentally starts a very lengthy compilation it makes no sense that he/she needs to wait forever for it to be finished, or, even worse, to kill the OMEdit process, restart it, and reload all the libraries and all the simulation results manually. IMO, this feature is really needed to convey a professional feeling of the OMEdit GUI, so we should aim at getting it for 2.0.0." Francesco Casella 4611 Processing arrays of records fails Backend 2.0.0 defect Karim Adbdelhak reopened 2017-11-04T14:08:58Z 2020-09-29T23:51:28Z "This is similar but different from #4606 I hope the solution is as straightforward as it was in that case! Consider the following code: {{{ package NumEqBug model TestLineZb parameter Real y[:] = {8, 10} ; Complex Z[2, 2]; equation Z =LineZb( y=y ); end TestLineZb; function LineZb import Modelica.ComplexMath; input Real y[2]; output Complex Z[2, 2]; algorithm Z:=fill(Complex(1,1),2,2); end LineZb; end NumEqBug; }}} Checking TestLineZb I get 4 equations and 8 variables. I would expect 8 equations and 8 variables. Note that y[] was included in the code even if it is not used because otherwise in the flattened code the function call is not included. Tested with v1.13.0-dev-188-g2c5818d (64-bit) for Win" massimo ceraolo 4835 Get Complex numbers to work without compromises *unknown* 2.0.0 defect Francesco Casella assigned 2018-03-21T08:22:34Z 2021-12-13T14:32:12Z "Complex numbers are increasingly used in Modelica, particularly for power system models. They are used by {{{Modelica.Electrical.QuasiStationary}}}, and also by other libraries being developed for electro-mechanical modelling of power systems. OMC supports complex numbers, but there are still some issue that prevents their full, uncompromised use. This ticket collects all of them in the attempt of solving the pending problems soon. In most, possibly all, cases, the best strategy to solve equations involving Complex variables is to turn them into scalar Real equations and then apply all possible symbolic simplifications. This is particularly important when Complex number that happen to be purely real or imaginary are used. In simple cases, this already happens. If you compile this model {{{ model TestComplex Complex z1, z2; equation z1+z2 = Complex(0); z2 = Complex(1,2); end TestComplex; }}} the record equations are turned into scalar equations and solved symbolically, so eventually z1 and z2 are evaluated at initialization, because they are constant. Unfortunately, in some cases this does not happen, for reasons that need to be investigated. In #4354 and #4808 this issue leads to problems solving otherwise trivial equations, in #4157 it leads to problems with equations in when statements. #4611 is a slightly more involved case, where arrays of Complex constructors are involved. #4973 has a test case for the new front-end, while #4974 shows an issue with the missing inlining of ComplexMath functions. The code generation for algorithms involving Complex numbers needs to be fixed, see #4055. There are also some issues with Complex equations and {{{removeSimpleEquations}}}, see #4793. Last, but not least, the sum of Complex numbers should be supported, see #4297. " Francesco Casella 5005 Issue with DASSL/IDA and implicit systems with non-smooth functions Run-time 2.0.0 defect Willi Braun assigned 2018-06-27T10:53:51Z 2018-10-17T20:22:10Z "Please check the results of the verification of the [https://libraries.openmodelica.org/branches/master/Modelica_trunk/files/Modelica_trunk_Modelica.Electrical.Analog.Examples.AmplifierWithOpAmpDetailed.diff.html Modelica.Electrical.Analog.Examples.AmplifierWithOpAmpDetailed]. Starting from time = 0.0008946, the results start diverging, see, e.g, [https://libraries.openmodelica.org/branches/master/Modelica_trunk/files/Modelica_trunk_Modelica.Electrical.Analog.Examples.AmplifierWithOpAmpDetailed.diff.opAmp.v_in.html opAmp.v_in]. I made some analysis of what happens there and I report the conclusions here. If you use the declarative debugger, it turns out that all system equations are analytic execept for the following three ones: {{{ (assign) der(opAmp.v_source) := smooth(0, if noEvent(der(opAmp.x) > opAmp.sr_p_val) then opAmp.sr_p_val else if noEvent(der(opAmp.x) < opAmp.sr_m_val) then opAmp.sr_m_val else der(opAmp.x)) (assign) opAmp.q_sum_help := Modelica.Electrical.Analog.Basic.OpAmpDetailed.FCNq_sum_limit(opAmp.q_sum, opAmp.q_fp1, constantVoltage.V, constantVoltage1.V, opAmp.vcp_abs, opAmp.vcm_abs) (torn) opAmp.i_out := Modelica.Electrical.Analog.Basic.OpAmpDetailed.FCNiout_limit(opAmp.v_source, resistor2.v, opAmp.Rout, opAmp.Imaxsi_val, opAmp.Imaxso_val) }}} The first two are assignments in the causalized system, while the third shows up in a nonlinear torn implicit system of equations, using {{{resistor2.v}}} as a tearing variable. As far as I understand, in all three cases the right-hand sides are continuous functions, but not smooth ones, as hard limiters are involved. Since noEvent() and non-inlined functions are involved, this strains the solvers a bit. In fact, I'm not sure why the decision was made to avoid events in this case, but I understand the idea is that as long as there are no hard discontinuities, solvers should manage without events. BTW, Dymola (which was used to generate the reference results) does manage without any issue. I tried to replicate the results reported on Hudson on my local OMEdit setup. If I run the example out of the box, I get the correct result up to time = 0.0013944, then it starts to deviate from the reference (and correct) one. This is possibly because some of the settings on Hudson are different, I'm not sure. I then tried to change the ODE solver to IDA, and/or the nonlinear solver to Kinsol, and/or to switch off Equidistant time grid. Each combination of these factors causes the simulation to veer off course at different points, but none of them provided the correct results. Also {{{--daeMode=new}}} leads to the same kind of problems. The only way I could get the correct result was to set {{{--maxSizeNonlinearTearing=0}}}. DASSL provided the correct result right away, while IDA still got some glitches and required to set {{{-noEquidistantTimeGrid}}} to get the correct result. IDA in {{{--daeMode=new}}} still failed to produce the correct results. I guess this means that the interaction between the ODE/DAE solver and the nonlinear equations with non-smooth terms is to blame here. BTW, Dymola selects a different tearing variable, {{{resistor2.i}}}, which may explain why it works fine. So, my conclusion is that the way we currently deal with these systems, that contain smooth(0, ..) expressions and/or continuous but non-smooth functions, is numerically fragile, for reasons that need to be further investigated. I believe this is a serious issue that probably affects many other models in the MSL and in other libraries, so it should be fixed with high priority, and most definitely addressed for version 2.0.0" Francesco Casella 5036 Better code generation for constant arrays Code Generation v1.13.0-dev-nightly 2.0.0 defect Lennart Ochel new 2018-07-05T15:08:17Z 2018-07-05T21:34:45Z "There are two issues in the code generation that together creates problems for the new frontend. The first issue is that constants in the DAE are not handled by the code generation. They are added to the SimCode structure, but then it seems they're mostly ignored by the code generation. This can be seen by changing: {{{#!mo if replaceConstants and node_var <= Variability.STRUCTURAL_PARAMETER then }}} to: {{{#!mo if replaceConstants and variability <= Variability.STRUCTURAL_PARAMETER then }}} in NFTyping.typeCrefExp, which will revert the NF to the old behaviour of only evaluating constants if their subscripts are also constant. Running this script will then return garbage results for `y`: {{{#!mo loadString("" model M constant Real x[3] = {1, 2, 3}; parameter Integer i = 2; Real y = x[i]; end M; ""); simulate(M); readSimulationResult(""M_res.mat"", y); }}} The code generated in `M.c` is: {{{#!c data->localData[0]->realVars[0] /* y variable */ = (&data->localData[0]->realVars[0] /* x[1] CONST */)[calc_base_index_dims_subs(1, 3, (modelica_integer)data->simulationInfo->integerParameter[0])]; }}} Note how `data->localData[0]->realVars[0]` is used for both `y` and `x`. There doesn't seem to be any code generated for `x` at all. The second issue is that the code generation for ASUB sometimes decides that the result of the ASUB must be a scalar. This can currently be seen in e.g. [https://libraries.openmodelica.org/branches/newInst/ModelicaTest_trunk/files/ModelicaTest_trunk_ModelicaTest.Blocks.Continuous.err ModelicaTest.Blocks.Continuous]. The old frontend seems to be aware of that and doesn't evaluate constants that would cause that issue, but then you run into the issue above that constants aren't initialized. The old frontend also evaluates much more in general, including things it shouldn't, so it doesn't run into as much problems with this. These issues combined means that the NF needs to evaluate all constants, but can't do so since it then has to generate ASUBs which sometimes aren't accepted by the code generation. The exception are local constants in functions, for which literal expressions are generated in the C code. Treating constant arrays (scalars can always be evaluated) declared in the DAE as literals in the same way we do for constants in functions would be one solution, and probably the most efficient. Improving the code generation for ASUB would also be a solution, but probably less straightforward." Per Östlund 5240 NFEvalFunction.evaluateExternal is not yet implemented New Instantiation 2.0.0 defect Per Östlund reopened 2018-12-12T00:11:56Z 2021-02-26T11:55:35Z It eventually should. Francesco Casella 5252 Misleading and incomplete output regarding conflicting start and nominal attributes Backend 2.0.0 defect Lennart Ochel new 2018-12-17T19:12:55Z 2019-06-04T14:22:08Z "Please consider the following test case (also attached) {{{ package TestPriorities type Pressure = Real(start = 1e5, nominal = 1e6); model M parameter Pressure pstart = 2e5; parameter Pressure pnom = 3e5; Pressure p1; Pressure p2(start = pstart, nominal = pnom); equation p1 = p2; p1 + log(p1) = 2e5; end M; model Test M m1; M m2(pstart = 5e5, pnom = 6e5); end Test; end TestPriorities; }}} In both {{{m1}}} and {{{m2}}} the expected behaviour is that the start and nominal value of {{{p2}}} are chosen, namely 2e5 and 3e5 for {{{m1}}} and 5e6, 6e5 for {{{m2}}} By simulating {{{Test}}} with the {{{LOG_NLS_V}}} simulation flag, it is possible to check that these values are indeed chosen, so OMC is working as expected. However, the following notification is issued {{{ [1] 19:44:16 Symbolic Warning The model contains alias variables with conflicting start and/or nominal values. It is recommended to resolve the conflicts, because otherwise the system could be hard to solve. To print the conflicting alias sets and the chosen candidates please use -d=aliasConflicts. }}} This statement is both inaccurate and misleading. If the conflicting start/nominal attribute have different confidence number, the intended behaviour is to use the one with a lower number, as explained in Section 8.6.2 of the specification. This is what every modeller would expect. Manually propagating start and nominal values to resolve the conflict in this case would a completely unnecessary, very tedious and definitely ''not'' according to an object-oriented declarative modelling paradigm. For example, it is intended that the start/nominal attributes of internal model variables, which are set by parameters such as {{{pstart}}} and {{{pnom}}}, override the default values of connector variables they are connected to, which have lower priority. Manually resolving this conflict would be a very dumb thing to do. A warning should only be issued if there are conflicting start/nominal attributes with the ''same'' confidence number. If I turn on the {{{-d=aliasConflicts}}} flag, I only get output regarding the nominal attributes {{{ [1] 19:26:50 Translation Warning Alias set with conflicting nominal values * Candidate: m2.p2(nominal = m2.pnom = 600000.0, confidence number = 2) * Candidate: m2.p1(nominal = 1000000.0, confidence number = 7) => Select value from m2.p2(nominal = m2.pnom = 600000.0) for variable: m2.p1 [2] 19:26:50 Translation Warning Alias set with conflicting nominal values * Candidate: m1.p2(nominal = m1.pnom = 300000.0, confidence number = 2) * Candidate: m1.p1(nominal = 1000000.0, confidence number = 7) => Select value from m1.p2(nominal = m1.pnom = 300000.0) for variable: m1.p1 }}} First and foremost, this should be a ''notification'', not a ''warning'', unless the selected value has the same confidence number of some other conflicting alias. Second, the same output should also be issued for the start attributes, not only for the nominal attributes." Francesco Casella 5302 PowerSystems models with redundant intial conditions cannot be handled by backend Backend 2.0.0 defect Lennart Ochel new 2019-01-28T13:48:00Z 2021-11-16T01:44:57Z "The following models in the {{{PowerSystems}}} library {{{ PowerSystems.Examples.AC1ph_DC.Inverters.InverterToGrid PowerSystems.Examples.AC3ph.Generation.PowerAngle PowerSystems.Examples.AC3ph.Generation.Vsource PowerSystems.Examples.AC3ph.Inverters.InverterToGrid PowerSystems.Examples.AC3ph.Transformation.PhaseShifts PowerSystems.Examples.AC3ph.Transmission.DoubleRXline PowerSystems.Examples.AC3ph.Transmission.DoublelLine }}} have redundant consistent initial conditions, as diagnosed by Dymola. OMC has some heuristics to detect them and remove them, but apparently we have a problem handling this case in OMC. Regarding the first option, I analyzed the {{{d=optdaedump}}} output of {{{PowerSystems.Examples.AC3ph.Generation.Vsource}}}. After running Pantelides' algorithm, there are 26 variables/equations: {{{ 1: grd2.term.i:VARIABLE(flow=true unit = ""A"" ) ""Current flowing into the pin"" annotation(unassignedMessage = ""An electrical current cannot be uniquely calculated. The reason could be that - a ground object is missing (Modelica.Electrical.Analog.Basic.Ground) to define the zero potential of the electrical circuit, or - a connector of an electrical component is not connected."") type: Real 2: grd1.term.i:VARIABLE(flow=true unit = ""A"" ) ""Current flowing into the pin"" annotation(unassignedMessage = ""An electrical current cannot be uniquely calculated. The reason could be that - a ground object is missing (Modelica.Electrical.Analog.Basic.Ground) to define the zero potential of the electrical circuit, or - a connector of an electrical component is not connected."") type: Real 3: infBus.theta:DUMMY_STATE(flow=false start = 0.0 unit = ""rad"" stateSelect=StateSelect.prefer protected = true ) ""absolute angle"" type: Real 4: line.omega[2]:VARIABLE(flow=false unit = ""rad/s"" protected = true ) type: Real [2] 5: line.i[3]:STATE(1)(flow=false start = line.i_start[3] unit = ""A"" nominal = 1.0 ) type: Real [3] 6: line.i[2]:STATE(1)(flow=false start = line.i_start[2] unit = ""A"" nominal = 1.0 ) type: Real [3] 7: line.i[1]:STATE(1)(flow=false start = line.i_start[1] unit = ""A"" nominal = 1.0 ) type: Real [3] 8: line.v[2]:VARIABLE(flow=false start = line.v_start[2] unit = ""V"" nominal = 1000.0 ) type: Real [3] 9: line.v[1]:VARIABLE(flow=false start = line.v_start[1] unit = ""V"" nominal = 1000.0 ) type: Real [3] 10: line.term_n.v[2]:VARIABLE(flow=false unit = ""V"" nominal = 1000.0 ) ""voltage vector"" type: Real [3] 11: line.term_n.v[1]:VARIABLE(flow=false unit = ""V"" nominal = 1000.0 ) ""voltage vector"" type: Real [3] 12: sensor.p[3]:VARIABLE(flow=false ) ""{active, reactive, DC} power, term_p to term_n"" annotation(Placement(transformation(origin = {0, 100}, extent = {{-10, -10}, {10, 10}}, rotation = 90))) type: Real [3] 13: sensor.p[2]:VARIABLE(flow=false ) ""{active, reactive, DC} power, term_p to term_n"" annotation(Placement(transformation(origin = {0, 100}, extent = {{-10, -10}, {10, 10}}, rotation = 90))) type: Real [3] 14: sensor.p[1]:VARIABLE(flow=false ) ""{active, reactive, DC} power, term_p to term_n"" annotation(Placement(transformation(origin = {0, 100}, extent = {{-10, -10}, {10, 10}}, rotation = 90))) type: Real [3] 15: Vsource.omega[2]:VARIABLE(flow=false unit = ""rad/s"" protected = true ) type: Real [2] 16: Vsource.omega[1]:VARIABLE(flow=false unit = ""rad/s"" protected = true ) type: Real [2] 17: Vsource.i[3]:DUMMY_STATE(flow=false start = 0.0 unit = ""A"" nominal = 1.0 protected = true ) type: Real [3] 18: Vsource.i[2]:DUMMY_STATE(flow=false start = 0.0 unit = ""A"" nominal = 1.0 protected = true ) type: Real [3] 19: Vsource.i[1]:DUMMY_STATE(flow=false start = 0.0 unit = ""A"" nominal = 1.0 protected = true ) type: Real [3] 20: Vsource.v[3]:VARIABLE(flow=false start = line.v_start[3] unit = ""V"" nominal = 1000.0 protected = true ) type: Real [3] 21: Vsource.v[2]:VARIABLE(flow=false start = 0.0 unit = ""V"" nominal = 1000.0 protected = true ) type: Real [3] 22: Vsource.v[1]:VARIABLE(flow=false start = 20000.0 unit = ""V"" nominal = 1000.0 protected = true ) type: Real [3] 23: $DER.Vsource.i[1]:DUMMY_DER(flow=false fixed = false ) type: Real [3] 24: $DER.Vsource.i[2]:DUMMY_DER(flow=false fixed = false ) type: Real [3] 25: $DER.Vsource.i[3]:DUMMY_DER(flow=false fixed = false ) type: Real [3] 26: $DER.infBus.theta:DUMMY_DER(flow=false fixed = false ) ""absolute angle"" type: Real Equations (26, 26) ======================================== 1/1 (1): $DER.infBus.theta = 314.1592653589793 [dynamic |0|0|0|0|] 2/2 (1): line.omega[2] = Vsource.omega[2] [dynamic |0|0|0|0|] 3/3 (1): Vsource.L * $DER.Vsource.i[1] + Vsource.R * Vsource.i[1] - Vsource.i[2] * Vsource.omega[2] * Vsource.L = Vsource.V * cos(Vsource.alpha0) - Vsource.v[1] [dynamic |0|0|0|0|] 4/4 (1): Vsource.L * $DER.Vsource.i[2] + Vsource.i[1] * Vsource.omega[2] * Vsource.L + Vsource.R * Vsource.i[2] = Vsource.V * sin(Vsource.alpha0) - Vsource.v[2] [dynamic |0|0|0|0|] 5/5 (1): Vsource.L0 * $DER.Vsource.i[3] + Vsource.R * Vsource.i[3] = -Vsource.v[3] [dynamic |0|0|0|0|] 6/6 (1): (-1.732050807568877) * line.i[3] - grd1.term.i = 0.0 [dynamic |0|0|0|0|] 7/7 (1): sensor.p[1] = Vsource.v[1] * line.i[1] + Vsource.v[2] * line.i[2] [dynamic |0|0|0|0|] 8/8 (1): sensor.p[2] = Vsource.v[2] * line.i[1] - Vsource.v[1] * line.i[2] [dynamic |0|0|0|0|] 9/9 (1): sensor.p[3] = Vsource.v[3] * line.i[3] [dynamic |0|0|0|0|] 10/10 (1): line.omega[2] = $DER.infBus.theta [dynamic |0|0|0|0|] 11/11 (1): line.v[1] = Vsource.v[1] - line.term_n.v[1] [dynamic |0|0|0|0|] 12/12 (1): line.v[2] = Vsource.v[2] - line.term_n.v[2] [dynamic |0|0|0|0|] 13/13 (1): line.L * der(line.i[1]) - line.i[2] * line.omega[2] * line.L + line.R * line.i[1] = line.v[1] [dynamic |0|0|0|0|] 14/14 (1): line.L * der(line.i[2]) + line.i[1] * line.omega[2] * line.L + line.R * line.i[2] = line.v[2] [dynamic |0|0|0|0|] 15/15 (1): line.L0 * der(line.i[3]) + line.R * line.i[3] = Vsource.v[3] [dynamic |0|0|0|0|] 16/16 (1): line.term_n.v[1] = infBus.V * cos(infBus.alpha0) [dynamic |0|0|0|0|] 17/17 (1): line.term_n.v[2] = infBus.V * sin(infBus.alpha0) [dynamic |0|0|0|0|] 18/18 (1): 1.732050807568877 * line.i[3] - grd2.term.i = 0.0 [dynamic |0|0|0|0|] 19/19 (1): Vsource.omega[1] = line.omega[1] [dynamic |0|0|0|0|] 20/20 (1): $DER.Vsource.i[3] = der(line.i[3]) [dynamic |0|0|0|0|] 21/21 (1): $DER.Vsource.i[2] = der(line.i[2]) [dynamic |0|0|0|0|] 22/22 (1): $DER.Vsource.i[1] = der(line.i[1]) [dynamic |0|0|0|0|] 23/23 (1): Vsource.i[1] = line.i[1] [dynamic |0|0|0|0|] 24/24 (1): Vsource.i[2] = line.i[2] [dynamic |0|0|0|0|] 25/25 (1): Vsource.i[3] = line.i[3] [dynamic |0|0|0|0|] 26/26 (1): infBus.theta = 314.1592653589793 * time [dynamic |0|0|0|0|] }}} There are 4 initial equations: {{{ Initial Equations (4, 8) ======================================== 1/1 (1): sqrt(Vsource.v[1] ^ 2.0 + Vsource.v[2] ^ 2.0) = 20000.0 * Vsource.v_start [initial |0|0|0|0|] 2/2 (1): PowerSystems.AC3ph.Sources.VsourceRX.atan2(Vsource.v[2], Vsource.v[1]) = Vsource.alpha_start [initial |0|0|0|0|] 3/3 (3): der(Vsource.i) = {(-Vsource.i[2]) * Vsource.omega[1], Vsource.i[1] * Vsource.omega[1], 0.0} [dynamic |0|0|0|0|] 4/6 (3): der(line.i) = {(-line.i[2]) * line.omega[1], line.i[1] * line.omega[1], 0.0} [dynamic |0|0|0|0|] }}} The last two equations are three-dimensional array equations, so we have a total of eight scalar initial equations. When the initial system of equations is finally created, it is reported as: {{{ ######################################## created initial system ######################################## unknown partition ======================================== Variables (44) ======================================== 1: Vsource.v0:VARIABLE(flow=false start = 1.0 unit = ""V/V"" fixed = false protected = true final = true ) ""voltage behind reactance"" type: Real 2: Vsource.V:VARIABLE(flow=false start = 20000.0 unit = ""V"" nominal = 1000.0 protected = true final = true ) = 20000.0 * Vsource.v0 type: Real 3: Vsource.alpha0:VARIABLE(flow=false start = 0.0 unit = ""rad"" fixed = false protected = true final = true ) ""phase angle of voltage b r"" type: Real 4: grd2.term.v:VARIABLE(flow=false unit = ""V"" ) = 0.0 ""Potential at the pin"" annotation(unassignedMessage = ""An electrical potential cannot be uniquely calculated. The reason could be that - a ground object is missing (Modelica.Electrical.Analog.Basic.Ground) to define the zero potential of the electrical circuit, or - a connector of an electrical component is not connected."") type: Real 5: grd1.term.v:VARIABLE(flow=false unit = ""V"" ) = 0.0 ""Potential at the pin"" annotation(unassignedMessage = ""An electrical potential cannot be uniquely calculated. The reason could be that - a ground object is missing (Modelica.Electrical.Analog.Basic.Ground) to define the zero potential of the electrical circuit, or - a connector of an electrical component is not connected."") type: Real 6: system.omega:VARIABLE(flow=false start = 314.1592653589793 unit = ""rad/s"" ) = 314.1592653589793 type: Real 7: infBus.V:VARIABLE(flow=false unit = ""V"" nominal = 1000.0 protected = true ) = 20000.0 * infBus.v0 type: Real 8: line.term_n.v[3]:VARIABLE(flow=false unit = ""V"" nominal = 1000.0 ) = 0.0 ""voltage vector"" type: Real [3] 9: line.term_p.theta[1]:DUMMY_STATE(flow=false ) = 0.0 ""optional vector of phase angles"" type: Real [2] 10: line.omega[1]:VARIABLE(flow=false unit = ""rad/s"" protected = true ) = 0.0 type: Real [2] 11: system.receiveFreq.w_h:VARIABLE(flow=false ) = 0.0 ""Dummy potential-variable to balance flow-variable w_H"" type: Real 12: system.receiveFreq.h:VARIABLE(flow=false ) = 0.0 ""Dummy potential-variable to balance flow-variable H"" type: Real 13: system.receiveFreq.w_H:VARIABLE(flow=true unit = ""rad"" ) = 0.0 ""angular velocity, inertia-weighted"" type: Real 14: system.receiveFreq.H:VARIABLE(flow=true unit = ""s"" ) = 0.0 ""inertia constant"" type: Real 15: grd2.term.i:VARIABLE(flow=true unit = ""A"" ) ""Current flowing into the pin"" annotation(unassignedMessage = ""An electrical current cannot be uniquely calculated. The reason could be that - a ground object is missing (Modelica.Electrical.Analog.Basic.Ground) to define the zero potential of the electrical circuit, or - a connector of an electrical component is not connected."") type: Real 16: grd1.term.i:VARIABLE(flow=true unit = ""A"" ) ""Current flowing into the pin"" annotation(unassignedMessage = ""An electrical current cannot be uniquely calculated. The reason could be that - a ground object is missing (Modelica.Electrical.Analog.Basic.Ground) to define the zero potential of the electrical circuit, or - a connector of an electrical component is not connected."") type: Real 17: infBus.theta:DUMMY_STATE(flow=false start = 0.0 unit = ""rad"" stateSelect=StateSelect.prefer protected = true ) ""absolute angle"" type: Real 18: line.omega[2]:VARIABLE(flow=false unit = ""rad/s"" protected = true ) type: Real [2] 19: $DER.line.i[3]:VARIABLE(flow=false start = line.i_start[3] unit = ""A"" nominal = 1.0 ) type: Real [3] 20: line.i[3]:VARIABLE(flow=false start = line.i_start[3] unit = ""A"" nominal = 1.0 ) type: Real [3] 21: $DER.line.i[2]:VARIABLE(flow=false start = line.i_start[2] unit = ""A"" nominal = 1.0 ) type: Real [3] 22: line.i[2]:VARIABLE(flow=false start = line.i_start[2] unit = ""A"" nominal = 1.0 ) type: Real [3] 23: $DER.line.i[1]:VARIABLE(flow=false start = line.i_start[1] unit = ""A"" nominal = 1.0 ) type: Real [3] 24: line.i[1]:VARIABLE(flow=false start = line.i_start[1] unit = ""A"" nominal = 1.0 ) type: Real [3] 25: line.v[2]:VARIABLE(flow=false start = line.v_start[2] unit = ""V"" nominal = 1000.0 ) type: Real [3] 26: line.v[1]:VARIABLE(flow=false start = line.v_start[1] unit = ""V"" nominal = 1000.0 ) type: Real [3] 27: line.term_n.v[2]:VARIABLE(flow=false unit = ""V"" nominal = 1000.0 ) ""voltage vector"" type: Real [3] 28: line.term_n.v[1]:VARIABLE(flow=false unit = ""V"" nominal = 1000.0 ) ""voltage vector"" type: Real [3] 29: sensor.p[3]:VARIABLE(flow=false ) ""{active, reactive, DC} power, term_p to term_n"" annotation(Placement(transformation(origin = {0, 100}, extent = {{-10, -10}, {10, 10}}, rotation = 90))) type: Real [3] 30: sensor.p[2]:VARIABLE(flow=false ) ""{active, reactive, DC} power, term_p to term_n"" annotation(Placement(transformation(origin = {0, 100}, extent = {{-10, -10}, {10, 10}}, rotation = 90))) type: Real [3] 31: sensor.p[1]:VARIABLE(flow=false ) ""{active, reactive, DC} power, term_p to term_n"" annotation(Placement(transformation(origin = {0, 100}, extent = {{-10, -10}, {10, 10}}, rotation = 90))) type: Real [3] 32: Vsource.omega[2]:VARIABLE(flow=false unit = ""rad/s"" protected = true ) type: Real [2] 33: Vsource.omega[1]:VARIABLE(flow=false unit = ""rad/s"" protected = true ) type: Real [2] 34: Vsource.i[3]:DUMMY_STATE(flow=false start = 0.0 unit = ""A"" nominal = 1.0 protected = true ) type: Real [3] 35: Vsource.i[2]:DUMMY_STATE(flow=false start = 0.0 unit = ""A"" nominal = 1.0 protected = true ) type: Real [3] 36: Vsource.i[1]:DUMMY_STATE(flow=false start = 0.0 unit = ""A"" nominal = 1.0 protected = true ) type: Real [3] 37: Vsource.v[3]:VARIABLE(flow=false start = line.v_start[3] unit = ""V"" nominal = 1000.0 protected = true ) type: Real [3] 38: Vsource.v[2]:VARIABLE(flow=false start = 0.0 unit = ""V"" nominal = 1000.0 protected = true ) type: Real [3] 39: Vsource.v[1]:VARIABLE(flow=false start = 20000.0 unit = ""V"" nominal = 1000.0 protected = true ) type: Real [3] 40: $DER.Vsource.i[1]:DUMMY_DER(flow=false fixed = false ) type: Real [3] 41: $DER.Vsource.i[2]:DUMMY_DER(flow=false fixed = false ) type: Real [3] 42: $DER.Vsource.i[3]:DUMMY_DER(flow=false fixed = false ) type: Real [3] 43: $DER.infBus.theta:DUMMY_DER(flow=false fixed = false ) ""absolute angle"" type: Real 44: system.initime:DISCRETE(flow=false unit = ""s"" fixed = false ) type: Real Equations (43, 47) ======================================== 1/1 (1): sqrt(Vsource.v[1] ^ 2.0 + Vsource.v[2] ^ 2.0) = 20000.0 * Vsource.v_start [initial |0|0|0|0|] 2/2 (1): PowerSystems.AC3ph.Sources.VsourceRX.atan2(Vsource.v[2], Vsource.v[1]) = Vsource.alpha_start [initial |0|0|0|0|] 3/3 (3): {$DER.Vsource.i[1], $DER.Vsource.i[2], $DER.Vsource.i[3]} = {(-Vsource.i[2]) * Vsource.omega[1], Vsource.i[1] * Vsource.omega[1], 0.0} [dynamic |0|0|0|0|] 4/6 (3): {$DER.line.i[1], $DER.line.i[2], $DER.line.i[3]} = {(-line.i[2]) * line.omega[1], line.i[1] * line.omega[1], 0.0} [dynamic |0|0|0|0|] 5/9 (1): infBus.theta = 314.1592653589793 * time [dynamic |0|0|0|0|] 6/10 (1): Vsource.i[3] = line.i[3] [dynamic |0|0|0|0|] 7/11 (1): Vsource.i[2] = line.i[2] [dynamic |0|0|0|0|] 8/12 (1): Vsource.i[1] = line.i[1] [dynamic |0|0|0|0|] 9/13 (1): $DER.Vsource.i[1] = $DER.line.i[1] [dynamic |0|0|0|0|] 10/14 (1): $DER.Vsource.i[2] = $DER.line.i[2] [dynamic |0|0|0|0|] 11/15 (1): $DER.Vsource.i[3] = $DER.line.i[3] [dynamic |0|0|0|0|] 12/16 (1): Vsource.omega[1] = line.omega[1] [dynamic |0|0|0|0|] 13/17 (1): 1.732050807568877 * line.i[3] - grd2.term.i = 0.0 [dynamic |0|0|0|0|] 14/18 (1): line.term_n.v[2] = infBus.V * sin(infBus.alpha0) [dynamic |0|0|0|0|] 15/19 (1): line.term_n.v[1] = infBus.V * cos(infBus.alpha0) [dynamic |0|0|0|0|] 16/20 (1): line.L0 * $DER.line.i[3] + line.R * line.i[3] = Vsource.v[3] [dynamic |0|0|0|0|] 17/21 (1): line.L * $DER.line.i[2] + line.i[1] * line.omega[2] * line.L + line.R * line.i[2] = line.v[2] [dynamic |0|0|0|0|] 18/22 (1): line.L * $DER.line.i[1] - line.i[2] * line.omega[2] * line.L + line.R * line.i[1] = line.v[1] [dynamic |0|0|0|0|] 19/23 (1): line.v[2] = Vsource.v[2] - line.term_n.v[2] [dynamic |0|0|0|0|] 20/24 (1): line.v[1] = Vsource.v[1] - line.term_n.v[1] [dynamic |0|0|0|0|] 21/25 (1): line.omega[2] = $DER.infBus.theta [dynamic |0|0|0|0|] 22/26 (1): sensor.p[3] = Vsource.v[3] * line.i[3] [dynamic |0|0|0|0|] 23/27 (1): sensor.p[2] = Vsource.v[2] * line.i[1] - Vsource.v[1] * line.i[2] [dynamic |0|0|0|0|] 24/28 (1): sensor.p[1] = Vsource.v[1] * line.i[1] + Vsource.v[2] * line.i[2] [dynamic |0|0|0|0|] 25/29 (1): (-1.732050807568877) * line.i[3] - grd1.term.i = 0.0 [dynamic |0|0|0|0|] 26/30 (1): Vsource.L0 * $DER.Vsource.i[3] + Vsource.R * Vsource.i[3] = -Vsource.v[3] [dynamic |0|0|0|0|] 27/31 (1): Vsource.L * $DER.Vsource.i[2] + Vsource.i[1] * Vsource.omega[2] * Vsource.L + Vsource.R * Vsource.i[2] = Vsource.V * sin(Vsource.alpha0) - Vsource.v[2] [dynamic |0|0|0|0|] 28/32 (1): Vsource.L * $DER.Vsource.i[1] + Vsource.R * Vsource.i[1] - Vsource.i[2] * Vsource.omega[2] * Vsource.L = Vsource.V * cos(Vsource.alpha0) - Vsource.v[1] [dynamic |0|0|0|0|] 29/33 (1): line.omega[2] = Vsource.omega[2] [dynamic |0|0|0|0|] 30/34 (1): $DER.infBus.theta = 314.1592653589793 [dynamic |0|0|0|0|] 31/35 (1): system.initime = time [dynamic |0|0|0|0|] 32/36 (1): Vsource.V = 20000.0 * Vsource.v0 [initial |0|0|0|0|] 33/37 (1): grd2.term.v = 0.0 [initial |0|0|0|0|] 34/38 (1): grd1.term.v = 0.0 [initial |0|0|0|0|] 35/39 (1): system.omega = 314.1592653589793 [initial |0|0|0|0|] 36/40 (1): infBus.V = 20000.0 * infBus.v0 [initial |0|0|0|0|] 37/41 (1): line.term_n.v[3] = 0.0 [initial |0|0|0|0|] 38/42 (1): line.term_p.theta[1] = 0.0 [initial |0|0|0|0|] 39/43 (1): line.omega[1] = 0.0 [initial |0|0|0|0|] 40/44 (1): system.receiveFreq.w_h = 0.0 [initial |0|0|0|0|] 41/45 (1): system.receiveFreq.h = 0.0 [initial |0|0|0|0|] 42/46 (1): system.receiveFreq.w_H = 0.0 [initial |0|0|0|0|] 43/47 (1): system.receiveFreq.H = 0.0 [initial |0|0|0|0|] }}} Here, I cannot follow exactly what the back-end is doing. On one hand, additional equations and variables have been added on top of the 26+8 that I expected at the end of Pantelides. On the other hand, it seems that the two array initial equations have disappeared. In fact, three of them are redundant, because of index reduction, but the other three are not. Eventually the initial system is unbalanced, but there are a number of fishy things going on here, and I'm not sure what is the root cause of the issue with these models. I need someone proficient with the backend to continue the analysis. I suspect that the three-dimensional array initial equations are somehow lost, but I'm not sure if I am interpreting the {{{optdaedump}}} output correctly." Francesco Casella 5346 Duplicate model function in OMEdit should work without compromises OMEdit 2.0.0 defect Adeel Asghar new 2019-02-18T15:32:19Z 2022-10-22T15:12:10Z "A very common model development pattern, particularly among beginners, is to start duplicating existing and working models, possibly putting them in a completely different package, and then applying some changes. OMEdit currently falls short of providing this basic feature, because the duplicated models are often invalid for various reasons. Expert users can try to fix them manually, but this is not an option for beginners. I had a discussion at the last Modelica Design meeting with Leo Gall, and basically on of the reasons why he can't start using OMC seriously with his customers is that he cannot follow this pattern. Christian Kral is also suffering with his students, and I guess many others are longing for this feature, even though they don't open tickets. I think having a decent Duplicate functionality is definitely a must-have for 2.0.0, so I'm opening this combo ticket as a blocker for that release. Currently open issues on this topic are: #4240, #4536, #4799, #4875, #5191, #5343, #5344, #5393. We should have them all fixed in time for 2.0.0 Of course it would be nice if at least the issues that are easier to fix are done in time for 1.14.0. @adeas31, what do you think?" Francesco Casella 5350 MSL 3.2.3 FFT function does not work correctly Run-time 2.0.0 defect Martin Sjölund new 2019-02-20T16:34:52Z 2019-05-28T13:09:09Z "The [https://libraries.openmodelica.org/branches/master/Modelica_3.2.3/files/Modelica_3.2.3_Modelica.Math.FastFourierTransform.Examples.RealFFT1.diff.html Modelica.Math.FastFourierTransform.Examples.RealFFT1] model calls the {{{Modelica.Math.FastFourierTransform.realFFT}}} function, which apparently returns only zero values, since the simulation results and the saved files only contain zero amplitude and phase values for all frequency. I'm not sure what exactly goes wrong in the chain of calls that ultimately calls the external C function {{{ModelicaFFT_kiss_fftr()}}}, this should be further investigated." Francesco Casella 5395 OMEdit generates invalid displayUnit modifiers for arrays of parameters OMEdit 2.0.0 defect Adeel Asghar new 2019-03-18T18:59:26Z 2019-06-25T14:04:38Z "Please check the attached example package. System model {{{S}}} contains one instance {{{m}}} of model {{{M}}}. Parameters were input using the parameter windows, and the unit was changed using the drop down menu. Unfortunately, the generated code misses the {{{each}}} prefix, so it cannot be run with the new frontend. Please make sure that in case the parameter is an array, the each modifier is added to the {{{displayUnit}}} modifiers." Francesco Casella 5407 Make the input of array parameters a humane experience OMEdit 2.0.0 defect Adeel Asghar new 2019-03-26T18:48:21Z 2019-03-26T22:26:41Z "Currently, the input of array parameters in OMEdit is a rather inhumane experience, particularly for beginners: - it is not at all clear if the parameter is a scalar, an array, or an N-dimensional array, one has to guess or to look at the source code or at the documentation to find that out - there is no (obvious) way to use {{{each}}} - if a literal value is to be input, one has to get the syntax right - even for advanced users, you may spend 10 solid minutes typing in an elaborate literal array expression, hit return, and discover you just lost ''all'' your work because of a stupid syntax error, e.g. {{{ [3] 19:35:48 Scripting Error Unable to set the component modifier value using command setComponentModifierValue( BasicAeroEngines.Tests.TestTurboJet, fuelFlow.table, $Code(=[0, 0.4;])) }}} I would strongly suggest that we improve the end user experience on this front, at least in these directions: - include some hint in the parameter window so as to the dimension of array parameters - allow to use {{{each}}} from the GUI (mandatory with the NF) - add a GUI for one- and two-dimensional array input - check for the syntax validity before closing the input window, and in case of error give some error message but do not discard the wrong input, rather keep it available for correction" Francesco Casella 5408 GUI annotations are not inherited correctly Interactive Environment 2.0.0 defect somebody new 2019-03-26T19:12:30Z 2019-07-04T21:05:25Z "Please consider the attached test package. The {{{DataType}}} record has a {{{defaultComponentName}}} and a {{{defaultPrefixes}}} annotation. The {{{MyData}}} record extends {{{DataType}}}, so it should also have them. However, if I open M and drag and drop {{{DataType}}} into it, I get the correct name and prefix, while if I drag and drop {{{MyData}}} I get the default name and no prefixes. I tried to flatten {{{MyData}}} with both OF and NF, using {{{--showAnnotations}}}, but I didn't see the annotation in either case. According to Sect. 7.1 of the Specification The elements of the flattened base class become elements of the flattened enclosing class, and are added at the place of the extends-clause: specifically components and classes, the equation sections, algorithm sections, optional external clause, ''and the contents of the annotation at the end of the class.'' I guess the underlying API suffers the same issue. I'm not sure whether it just needs to be fixed in the NF or if the API shoud also be fixed." Francesco Casella 5418 Avoid confusing error messages from the solvers OMEdit 2.0.0 defect Adeel Asghar new 2019-04-02T17:45:46Z 2019-04-03T06:55:07Z "Oftentimes, solvers encounter problems during the initialization or the simulation of the system. Error are issued in threatening red characters, but the the initialization and possibly the simulation are completed successfully (see one example screenshot attached). This is quite confusing, particularly for beginners. If solvers take too bold steps, fail, but then recovers and successfully completes the task, there's no reason to issue red error messages. A warning could be issued, but not more. It would be nice to fix this for 2.0.0" Francesco Casella 5426 Compiler fails when model name is too long in OMEdit Frontend v1.14.0-dev-nightly 2.0.0 defect Adrian Pop assigned 2019-04-08T14:02:21Z 2020-02-18T09:24:31Z "I know it's an almost-duplicate ticket compared to [https://trac.openmodelica.org/OpenModelica/ticket/5315], but I think it's conceptually very different: this is specifically for OMEdit, where the user does *not* handle directly the `fileNamePrefix` as if it was for the `buildModel` and `buildModelFMU` script commands (except if it specifically sets the equivalent option in the Simulation Setup>Output>File Name Prefix). Long-name models (even those whose name comes from a deep nesting) fail to build with no meaningful error message. Such a problem could be very annoying to debug if someone does not know about the modelname length problem: if allowing long names it's a problem, then at least the user should be warned about the issue. The very simple model {{{ model shortModelName Real t; equation t = time; end shortModelName; }}} when nested into something like this: {{{ model longModelName model longModelName model longModelName model longModelName model longModelName model longModelName model shortModelName Real t; equation t = time; end shortModelName; end longModelName; end longModelName; end longModelName; end longModelName; end longModelName; end longModelName; }}} gives the following error: {{{ [1] 15:55:51 Scripting Error Error writing to file BipartiteGraph_longModelName.longModelName.longModelName.longModelName.longModelName.longModelName.shortModelName.graphml. }}} Obviously, I'm not playing to make long names on purpose! I hit this problem when I had to run a real model: `CrtVehicleTesting.Mechanics.Rotational.Differentials.DifferentialElectronicLimitedSlipTest` " dariomangoni@… 5462 Inaccurate simulation of systems with noEvent and saturations using the C runtime Run-time 2.0.0 defect Andreas Heuermann assigned 2019-05-08T14:05:34Z 2019-06-07T13:35:23Z "When signal saturations are modelled using {{{noEvent()}}}, the C runtime has some issues, as exemplified by the {{{Modelica.Electrical.Analog.Examples.OpAmps.Multivibrator}}} model. 1. When simulating the model with OMEdit, some numerical errors are reported during the simulation, around some of the events. In fact, the simulation reaches {{{stopTime}}} successfully, but for some reason the final solver statistics and the end message ""The simulation finished successfully."" are not displayed. This should be corrected. 2. The testsuite reports a verification failure, see, e.g., the plot of [https://libraries.openmodelica.org/branches/newInst/Modelica_3.2.3/files/Modelica_3.2.3_Modelica.Electrical.Analog.Examples.OpAmps.Multivibrator.diff.opAmp.out.v.html opAmp.out.v], which shows how the period of the OMC simulation is significantly shorter than the one of the reference plot. The experiment annotation sets StopTime = 1, Tolerance = 1e-6, and Interval = 0.001. If the simulation is run with these parameters (as Jenkins does), the last commutation of {{{opAmp.out.v}}} takes place at time {{{0.975}}}, much earlier than the value of {{{0.9835}}} of the reference plot, which was computed by Dymola using the same parameters. If I now decrease the Interval to 0.0002, the last commutation takes place at time 0.9826, which is much closer to the reference plot. However, the precision of the location of time events shouldn't really depend so much on the reporting interval length, so there is probably something fishy going on here. On the other hand, if I turn off Equidistant time grid off, and keep the tolerance to 1e-6, the last commutation takes place even earlier than with 0.001 communication interval, at time 0.97266. Only if I decrease the tolerance to 1e-10 do I get the last commutation to take place at time 0.9843, which is probably very close to the exact result, and is the same that I get with Dymola using the same settings. Summing up, even with a fairly tight tolerance setting (1e-6), it seems that the actual choice of communication interval (or the absence thereof) has an excessivly high impact on the accuracy of the solution of a simple system (it is a first-order ODE) that has state events. On the other hand, Dymola (which basically uses the same ODE solver, DASSL) doesn't show such a dependency, which probably means there is something wrong with our implementation. This is immediately apparent if you check the plots of [https://libraries.openmodelica.org/branches/newInst/Modelica_3.2.3/files/Modelica_3.2.3_Modelica.Electrical.Analog.Examples.OpAmps.Multivibrator.diff.c.v.html c.v], which is the only state variable of the system. If you zoom in around time = 0.034, it is apparent how the OMC solution change direction at a value of -7.4, much earlier than the correct value of -7.5 which is shown by the reference solution. It looks like the event is not triggered at the zero-crossing time, but rather at the previous step (or communication interval). This seems quite a serious issue for the simulation of systems that heavily depend on state events. Karim, Andreas, Lennart, can you please have a look? " Francesco Casella 5473 AST_BatchPlant test case fails Third-Party Libraries 2.0.0 defect Martin Sjölund new 2019-05-10T19:08:57Z 2020-06-25T23:59:20Z "The [https://libraries.openmodelica.org/branches/newInst/Modelica_3.2.3/files/Modelica_3.2.3_Modelica.Fluid.Examples.AST_BatchPlant.BatchPlant_StandardWater.sim Modelica.Fluid.Examples.AST_BatchPlant.BatchPlant_StandardWater] model fails because of numerical issues. Deeper analysis reveals that the model is quite ill-conditioned. I opened [https://github.com/modelica/ModelicaStandardLibrary/pull/2925 PR #2925] on the MSL repo with a fix to address this issue. Once accepted into the MSL master branch, this should then be patched onto MSL 3.2.3/maintenance, and used to update the version of MSL we ship with OMC." Francesco Casella 5482 Further speed up of NF API NF API 2.0.0 defect Adrian Pop reopened 2019-05-14T21:52:38Z 2019-06-01T12:16:42Z Collect here the discussion on making the OMEdit faster when displaying models. Francesco Casella 5489 Allow setting each and final prefixes via the API Interactive Environment 2.0.0 defect Adrian Pop accepted 2019-05-17T08:54:10Z 2019-06-05T19:07:24Z Currently `setComponentModifierValue` only allows to set the modifier value. Extend it to make it possible to include `each` and `final` prefixes. There is also an example available in #5395. Adeel Asghar 5509 Make Simulation Setup dependent of target language OMEdit v1.14.0-dev-nightly 2.0.0 defect Adeel Asghar new 2019-05-29T15:10:22Z 2019-05-29T18:32:34Z "When setting target language to a different setting than C in OMEdit the Simulation Setup window should change some stats. E.g the available solver methods and log flags are different for Cpp. (CVODE is the standard integrator for Cpp but only dassl is shown). The Cpp-Runtime ignores the setting for the chosen integrator method set via OMEdit Simulation Setup window. It could use dassl but ignores it. Not all logging flags are supported by OMEdit. So they should not be visible in the dialog. For example for `LOG_RES_INIT` OMEdit returns {{{ Warning: unrecognized logging LOG_RES_INIT }}}" Andreas Heuermann 5535 Inheritence of classes with same elements results in doubling OMEdit v1.14.0-dev-nightly 2.0.0 defect Adeel Asghar new 2019-06-18T13:26:48Z 2019-06-18T13:44:18Z "If a class gets inherited by extends clause, which have the same element (e.g. parameter, with exactly the same name) the parameter appears twice in the dialog of the flattened enclosing class. Same case if a model extends two base classes with same elements. See attached test package for minimal example. As far as I know (see ModelicaSpec 3.4 chapter 7.1 Inheritance—Extends Clause) only the first element in order is kept, rest will be ignored. thank you in advance. " Sven.Baetzing@… 5543 OMEdit does not check if added connections are valid NF API 2.0.0 defect Adrian Pop new 2019-06-22T15:38:56Z 2019-06-25T08:03:21Z "When connecting any two ports, OMEdit should check that the two connectors are compatible. This is currently not the case: if you connect one electrical pin of the attached example with the thermal port of the thermal capacitor, the connection is accepted. What is even more problematic is that the resulting model can be compiled, but this is the subject of another ticket, see #5542" Francesco Casella 5581 FMU - ME accuracy FMI v1.14.0-dev-nightly 2.0.0 defect Lennart Ochel new 2019-07-12T15:27:27Z 2020-08-05T07:48:04Z "I'm not aware of possible reasons for which a simulation containing a FMU-ME created form a Modelica source should behave differently from a full-modelica simulation. Indeed I expect, at least in the simplest cases, perfect matching. Consider the enclosed package fbSystemTest.mo. It contains: - fbSystem, a simple modelica model of a system to regulate the speed of the rotating inertia inertia1 - fbSybSysDX, a part of fbSystem, with is used to create the enclosed fbSystemPkg.fbSubSysDX.fmu - fbSystemFMU, which corresponds to fbSystem, but contains the created fmu. In principle the rotational speed of inertia1 should be the same when simulating fbSystem and fbSystemFMU. However, when everything is done with OpenModelica, significant differences are shown. Note that if I use the same package fbSystemTest.mo to compare the two simulations, but do everything (including the fmu creation) with Dymola, no difference between the two simulations is shown. The values appear to be exactly the same, up to the last digit shown with numerical cursor. These two behaviours can be checked looking at the enclosed ""FMU issue.pdf"", which compares plots from Dymola and from OM. So I suppose there is a bug that causes the OM simulations not to have exactly the same values. " massimo ceraolo 5594 Some Model C-files are not included in modelDescription.xml FMI v1.14.0-dev-nightly 2.0.0 defect Martin Sjölund assigned 2019-07-17T12:09:05Z 2020-05-15T11:05:28Z "Exporting a model with 5804 equations as a FMU resulting in several parts of {{{06inz.c}}} and {{{08bnd.c}}} such as: {{{ ModelName_06inz_part0.c; ModelName_06inz_part1.c; ModelName_06inz_part2.c; ModelName_08bnd_part3.c; ModelName_08bnd_part4.c }}} that are not included in {{{modelDescription.xml}}}" Trista Arinomo 5597 Two examples of the new Modelica.Electrical.Batteries package do not work with the new frontend New Instantiation v1.14.0-dev-nightly 2.0.0 defect Per Östlund new 2019-07-18T10:47:03Z 2020-04-30T10:25:37Z "I tested the new [https://github.com/modelica/ModelicaStandardLibrary/pull/3054/commits/1fc121c3b0114a37ac971b5a5710fd0580b0f4bf Batteries package] which is going to be included in the MSL by [https://github.com/modelica/ModelicaStandardLibrary/pull/3054 modelica/ModelicaStandardLibrary#3054]. When investigating the three examples of the Batteries library I was running into problems with two of the examples: === Modelica.Electrical.Batteries.Examples.BatteryDischargeCharge === Error message with new frontend: {{{ [4] 12:38:18 Translation Error [/var/lib/jenkins3/ws/LINUX_BUILDS/tmp.build/openmodelica-1.14.0~dev-26599-g88bb448/OMCompiler/Compiler/NFFrontEnd/NFCeval.mo: 1401:9-1402:94]: Internal error NFCeval.evalRelationLessEq failed to evaluate ‘Modelica.Electrical.Batteries.ParameterRecords.RCData.R <= 0.0‘ [5] 12:38:18 Translation Error [/var/lib/jenkins3/ws/LINUX_BUILDS/tmp.build/openmodelica-1.14.0~dev-26599-g88bb448/OMCompiler/Compiler/NFFrontEnd/NFCeval.mo: 2459:20-2459:79]: Internal error NFCeval.evalBuiltinSum got invalid arguments (cellData2.rcData.R) [6] 12:38:18 Translation Notification [Modelica.Electrical.Batteries.Examples.BatteryDischargeCharge: 42:3-51:71]: From here: [7] 12:38:18 Translation Error [Modelica.Blocks.Tables: 11:5-13:80]: Constant cellData2 is used without having been given a value. [8] 12:38:18 Translation Notification [Modelica.Electrical.Batteries.ParameterRecords.CellData: 6:3-8:47]: From here: [9] 12:38:18 Translation Error [Modelica.Blocks.Tables: 11:5-13:80]: Constant battery2.cellData.useLinearSOCDependency is used without having been given a value. }}} So {{{[5]}}} may be the relevant hint, since the calculation of the sum seems to fail. The example simulates OK with the old frontend === Modelica.Electrical.Batteries.Examples.CCCVcharging === Pretty much the same error message with the new frontend. The old frontend compiles and simulates fine. " Christian Kral 5600 removeEqualFunctionCalls should be better documented and merged with comSubExp Backend 2.0.0 defect Lennart Ochel new 2019-07-19T21:26:22Z 2019-07-19T21:26:22Z "In the process of fixing #5458, the {{{removeEqualFunctionCalls}}} was temporarily disabled, which caused some problems. We also discovered that it does a lot more that the documentation says, as documented in the comments to that ticket. It was eventually reinstated with [https://github.com/OpenModelica/OpenModelica/pull/341 PR #341], causing some [https://libraries.openmodelica.org/branches/history/newInst/2019-07-19%2011:29:24..2019-07-19%2015:35:39.html regressions]. We should improve the [https://openmodelica.org/doc/OpenModelicaUsersGuide/latest/omchelptext.html documentation] of this module, or possibly merge it with {{{comSubExp}}}, and try to fix the regressions, assuming they are actually due to that PR." Francesco Casella 5605 Parameter with only start value not accepted New Instantiation 2.0.0 defect Per Östlund new 2019-07-26T18:22:30Z 2019-07-26T18:59:35Z "A parameter with evaluate=true and only a start value (no binding equation) can be accepted? Consider model Modelica.Electrical.Machines.Examples.SMPM_NoLoad. If in the machine we delete the boolean value useDamperCage, the model does not run with NF, while it runs with OF, which issues the following warning: {{{ Parameter smpm.useDamperCage has no value, and is fixed during initialization (fixed=true), using available start value (start=true) as default value. }}} " massimo ceraolo 5645 Bad quality of SVG export of diagram view OMEdit v1.14.0-dev-nightly 2.0.0 defect Adeel Asghar new 2019-09-29T11:08:06Z 2019-11-24T15:28:14Z "I want to use the SVG export of diagram circuit in a document. I pick one example of the Modelica Standard Library here: {{{Modelica.Electrical.Analog.Examples.HeatingRectifier}}}: In OpenModelica the diagram view looks nice. I make a right click on the diagram view of the model and export the SVG file {{{HeatingRectifier.svg}}}. If I convert the SVG file with one of the methods shown in https://notesofaprogrammer.blogspot.com/2017/03/converting-svg-to-pdf-on-linux-command.html the outputs are all of bad quality: * {{{rsvg-convert.pdf}}} and its screenshot {{{rsvg-convert.png}}} * {{{convert.pdf}}} * {{{inkscape.pdf}}} Even if I import the file in LibreOffice Draw, the file looks as bad * {{{LibreOfficeDraw.png}}} shows the screenshot of the imported SVG file If import the file SVG manually in Inkscape, ungroup all lines and try to make it look nice by changing the line thickness, I totally fail. The change to a uniform stroke style of 2 pt is shown in image {{{Inkscape_Stroke_style.png}}} " Christian Kral 5767 Issues with BranchingDynamicPipes and homotopy-based initialization Run-time v1.16.0-dev 2.0.0 defect Andreas Heuermann new 2020-01-05T02:07:19Z 2020-01-05T02:07:19Z "Please check [https://libraries.openmodelica.org/branches/newInst/Modelica_3.2.3/files/Modelica_3.2.3_Modelica.Fluid.Examples.BranchingDynamicPipes.sim Modelica.Fluid.Examples.BranchingDynamicPipes]. The initialization of this model in MSL 3.2.3 and 4.0.0 (trunk) was broken when [https://libraries.openmodelica.org/branches/history/newInst/2019-12-13%2020:28:57..2019-12-16%2020:28:52.html homotopy was activated by default]. It is currently unclear to me where the problem is. Strangely enough, if I run it on my PC, I eventually get a solution, but it takes a lot of time. The model in MSL 3.2.2 got slower but still works, maybe that holds some clue to the solution of this issue." Francesco Casella 5768 Model HeatExchangerSimulation fails when using homotopy Run-time v1.16.0-dev 2.0.0 defect Andreas Heuermann new 2020-01-05T02:10:17Z 2020-01-05T02:10:17Z "The initialization of model [https://libraries.openmodelica.org/branches/newInst/Modelica_3.2.3/files/Modelica_3.2.3_Modelica.Fluid.Examples.HeatExchanger.HeatExchangerSimulation.sim https://libraries.openmodelica.org/branches/newInst/Modelica_3.2.3/files/Modelica_3.2.3_Modelica.Fluid.Examples.HeatExchanger.HeatExchangerSimulation.sim] got broken when [https://libraries.openmodelica.org/branches/history/newInst/2019-12-13%2020:28:57..2019-12-16%2020:28:52.html homotopy was activated by default]. It is still unclear to me what the problem is." Francesco Casella 5784 Problems displaying text on menus and other elments OMEdit v1.13.2 2.0.0 defect Adeel Asghar new 2020-01-13T14:23:43Z 2020-01-15T12:36:55Z The space to be allocated for the text of some graphical elements in the IDE (e.g. menus, tabs) is not calculated correctly and quickly becomes unreadable. See picture. asoppelsa@… 5788 Cannot input parameters redefined in child models using OMEdit OMEdit 2.0.0 defect Adeel Asghar new 2020-01-15T22:57:49Z 2020-05-25T21:02:56Z "Steps to reproduce the issue: - open {{{PowerGrids.Examples.IEEE14bus.IEEE14busStaticNetwork}}} - double click on {{{bus1}}} - the parameter {{{UStart}}} shows up in two separate tabs (General and Initialization - if I type in any value for any parameter, the OK button remains greyed out and I cannot input any value" Francesco Casella 5837 Unit checking is not performed on operator record equations New Instantiation 2.0.0 defect Per Östlund new 2020-02-11T22:07:45Z 2020-08-25T00:23:19Z "Consider the following test case: {{{ partial model M Modelica.SIunits.ComplexVoltage v; Modelica.SIunits.ComplexCurrent i; Modelica.SIunits.ComplexImpedance Z; Modelica.SIunits.ComplexAdmittance Y; Modelica.SIunits.Reactance X; equation i = Z*i; Y = Complex(0,X); Z = Y; Z + Y = Complex(0); end M; }}} All the equations are obviously wrong, and unit checking could easily allow to spot the errors. Unfortunately, if I check the model in OMEdit I get no error or warning at all. When doing unit checking of record equations, we should carry out unit inference through all the operators and make sure all the equivalent Real equations are dimensionally consistent." Francesco Casella 5847 Constant is used without having been given a value New Instantiation v1.16.0-dev 2.0.0 defect Per Östlund new 2020-02-17T13:27:56Z 2020-02-19T16:33:37Z "The initialization of parameters through function at initial algorithm produces (non-blocking) errors. This happens when such parameters are then used to initialise other model instances. with old frontend only vector-output functions fail, while with the new one both scalar and vector output fail. {{{ [1] 14:26:06 Translation Notification [InitializationInInitial: 17:5-17:58]: From here: [2] 14:26:06 Translation Error [Modelica.SIunits: 471:7-471:53]: Constant is used without having been given a value. }}}" dariomangoni@… 5855 Achieve successful simulation of 100% MSL 4.0.0 models *unknown* 2.0.0 defect Francesco Casella new 2020-02-18T23:20:46Z 2020-06-23T18:13:40Z "According to the current [https://github.com/modelica/ModelicaStandardLibrary/wiki/MSL-v4.0.0-release MSL 4.0.0 release schedule], MSL 4.0.0 will be ready by the end of March 2020, possibly a few weeks or months later if there are delays with regression testing. This is the [https://libraries.openmodelica.org/branches/newInst/Modelica_trunk/Modelica_trunk.html Jenkins MSL 4.0.0 report]. As of 19 Feb 2020, there are 30 models that do not simulate, corresponding to a 94% success rate. We should try to - fetch the reference results to check if there are wrong results at the end of apparently successful simulations - make sure there are no issues in the library before the rc.1 release (4 March 2020) - bring the success rate close to 100% for release 2.0.0 of OMC." Francesco Casella 5857 MSL OpAmp simulation results in OM Backend v1.16.0-dev 2.0.0 defect Lennart Ochel new 2020-02-19T21:15:58Z 2020-02-19T21:48:59Z "I am referring to the recent PRs in the MSL 4.0.0 (and 3.2.3 respectively): In [https://github.com/modelica/ModelicaStandardLibrary/pull/3432 Modelica PR #3432] the parameter strict was changed from false to true. I investigated both cases with Dymola and OM (see attached {{{SignalGenerator.png}}}) Dymola shows pretty much the same result for {{{strict = true}}} and {{{strict = false}}}. OM shows practically the negative signals for time < 0.2 and more and more strange results towards the end of the simulation. " dr.christian.kral@… 5860 Provide correct and efficient event handling in --daeMode Run-time 2.0.0 defect Andreas Heuermann assigned 2020-02-20T21:24:33Z 2021-01-19T16:05:52Z "AnHeuermann reports in ticket:5843#comment:1: Let's start with a first class of problems: '''Verification failed''' See e.g. Modelica.Blocks.Examples.BooleanNetwork1. This model has integer and boolean variables, which are not treated correctly. The values are not updated after events and remain constant. Enabling tearing (minimal, cellier, omc) and looking at the tearing dumps shows that no discrete variables are moved to inner variables. That makes sense for ode case, since there are no loops. But for the dae mode we want to causalize the discrete variables. And how should the dae mode handle discrete state variables? Actually when looking at the discrete states we have for ode {{{ * Number of discrete states: 12 (falling.not_u,rising.u,set1.y,changing.u,triggeredAdd.y,booleanTable.combiTimeTable.nextTimeEventScaled,onDelay.t_next,onDelay.delaySignal,$whenCondition3,$whenCondition2,booleanTable.combiTimeTable.nextTimeEvent,rSFlipFlop.pre.u) }}} and for dae the dump is not working(?): {{{ * Number of states: 0 () * Number of discrete states: 0 () }}} And why is `$whenCondition3` a state in the first case at all? " Francesco Casella 5866 Update Save Total to NF New Instantiation 2.0.0 defect Per Östlund new 2020-02-25T14:09:41Z 2020-02-25T14:09:41Z "During today's devmeeting, I understood from @adrpo that the NF currently lacks proper dependency analysis, that would be required to perform class renaming and the corresponding code refactoring properly. I also understood that Save Total (which obviously requires such a functionality) doesn't use the new NF, but rather some previous and incomplete version of it, which may produce wrong output. I guess this should be fixed with releatively high priority, for sure before the 2.0.0 release." Francesco Casella 5926 Save a proper result file when interrupting a simulation Run-time 2.0.0 defect Lennart Ochel new 2020-04-25T10:45:44Z 2022-05-19T07:58:17Z "Everybody's happy when a simulation terminates successfully: you look at the results and then either they are good for you, or if they are not you can figure out what's wrong, change something, and re-simulate. However, there are many cases in which simulations get stuck, because of chattering or any other reason. This happens all the time in real life. After some time, you just need to kill the simulation process. Unfortunately, when you do so the process does not die gracefully as it should, and in particular ''no valid simulation results are saved'' up to that point, which makes it real hard to figure out what's wrong and apply suitable remedies. This is a MWE of such a situation: {{{ model Chattering Real x(start = 1, fixed = true); equation der(x) = noEvent(if x > 0 then -1 else 1); annotation(experiment(StopTime = 2)); end Chattering; }}} If you simulate it in OMEdit, the simulation gets stuck indefinitely at 50% of the simulation time span. When you finally hit the Cancel Simulation button you get {{{ Process crashed Simulation process failed. Exited with code 62097. }}} and if you try to check the results in the Variables Browser, you get an error window saying: {{{ Corrupt file. nvar 0 }}} I think this behaviour is really not professional. Particularly if it takes place after your precious simulation has been running for half an hour. This is what we need to happen in case the Cancel Simulation button is pressed: - A terminate signal is sent to the simulation executable - The simulation executable stops doing whatever it is doing, saves the simulation results obtained so far, and terminates with an error message like: ""Simulation stopped by the user at time = "". - The simulation results from StartTime to current_time are loaded in the Variables Browser. I guess this requires updates to OMEdit as well as to the runtime. I would assign this provisionally to @adeas31, please coordinate with @karim, @AnHeuermann, @mahge930 and @niklwors to come up with a working solution. @sjoelund.se may also be interested, since this has connections with the debugger. I think this is really a must-have for 2.0.0. It would be nice to have it in 1.16.0 already." Francesco Casella 5940 MSL example model AIMC_InverterDrive fails to simulate Run-time v1.16.0-dev 2.0.0 defect Andreas Heuermann assigned 2020-05-06T15:31:46Z 2020-06-25T22:44:20Z "I noticed that the following MSL example fails to simulate: `Modelica.Electrical.Machines.Examples.AsynchronousInductionMachines.AIMC_InverterDrive` See also https://libraries.openmodelica.org/branches/newInst/Modelica_3.2.3/files/Modelica_3.2.3_Modelica.Electrical.Machines.Examples.AsynchronousInductionMachines.AIMC_InverterDrive.sim" Dietmar Winkler 5981 OMEdit does not handle correctly modified inherited parameters OMEdit 2.0.0 defect Adeel Asghar new 2020-05-25T21:01:35Z 2020-05-25T21:03:39Z "Please check the attached test package. Open the model {{{S}}} and double-click on {{{m2}}}. I would expect to see two fields, one for {{{p}}} with default value {{{s}}}, one for {{{q}}} and one for {{{s}}}. What I get instead is two times {{{p}}} with default {{{q}}}, besides {{{q}}} and {{{s}}}." Francesco Casella 6047 The NF incorrectly infers the variability of a function call in Modelica.Media New Instantiation 2.0.0 defect Per Östlund new 2020-07-03T18:36:35Z 2020-07-10T15:06:59Z "Please check [https://libraries.openmodelica.org/branches/newInst/Modelica_3.2.3/files/Modelica_3.2.3_Modelica.Media.Examples.ReferenceAir.MoistAir1.err Modelica.Media.Examples.ReferenceAir.MoistAir1]. The NF fails with {{{ [Modelica 3.2.3/Media/package.mo:4985:5-4989:75:writable] Error: Component h_default of variability constant has binding 'Modelica.Media.Examples.ReferenceAir.MoistAir1.Medium.specificEnthalpy_pTX(Medium.p_default, Medium.T_default, Medium.X_default)' of higher variability parameter. }}} The offending code is found [https://github.com/modelica/ModelicaStandardLibrary/blob/f0e7c0d4aa6244d579e175283873ada421c89458/Modelica/Media/package.mo#L4985 here]: {{{ constant SpecificEnthalpy h_default=specificEnthalpy_pTX( p_default, T_default, X_default) }}} Obviously, if all the inputs to the function are constant, so should be its output." Francesco Casella 6149 The NF accepts illegal type declarations? New Instantiation 2.0.0 defect Per Östlund new 2020-10-05T16:53:22Z 2020-10-05T17:06:16Z "Please consider the following test model {{{ model TestComplex type ComplexPU = Complex(re(final unit = ""1""), im(final unit = ""1"")); constant ComplexPU j = Complex(0,1); end TestComplex; }}} OMC accepts it and compiles it, while Dymola complains that {{{ A type may only inherit from the same kind of specialized class, but ComplexPU inherited from record Complex. }}} and only accepts the model if I replace {{{type}}} with {{{operator record}}}. I couldn't find the place in the specification that explains what you can put in {{{type}}} declarations, but I guess OMC is too lax here." Francesco Casella 6383 Omc doesn't check correctly the constraining-clause New Instantiation 1.18.0-dev 2.0.0 defect Per Östlund new 2021-02-17T16:30:12Z 2021-02-17T16:30:12Z "consider the following package (also attached) {{{ package Test function f1 input Real u1; end f1; function f2 input Boolean b1; end f2; model M1 replaceable function fr = f1 constrainedby f2; end M1; end Test; }}} The functions f1 and f2 aren't ""plug-compatible"" because they have different inputs (different name and different type) without default value, so the {{{default}}} type and the {{{constrainedby}}} type of the replaceable function {{{fr}}} in the model {{{M1}}} doesn't match. Checking the model M1 no errors nor warnings are risen by omc. OMEdit - OpenModelica Connection Editor Connected to OpenModelica 1.18.0~dev-49-gc5c5e43 sysop: ubuntu 18.04 " Andrea Bartolini 6386 Better diagnostics for over- and under-determined systems *unknown* 1.16.2 2.0.0 defect Karim Adbdelhak new 2021-02-18T17:36:11Z 2021-02-19T12:18:37Z "Consider the following (trivial) case {{{ model M1 Real x, y, z; equation x + y = 2; x - y = 10; end M1; }}} In this case, we already get some useful diagnostics: {{{ [1] 18:15:27 Symbolic Error Too few equations, under-determined system. The model has 2 equation(s) and 3 variable(s). [2] 18:15:27 Symbolic Warning [MM: 2:3-2:15]: Variable z does not have any remaining equation to be solved in. The original equations were: }}} However, consider this slightly less trivial case {{{ model M2 Real x, y, z; Real a, b, c; equation x + y = 1; y + z = -3; a + b + c = 4; a - c = 2; b + c = 4; end M2; }}} Here, we currently get {{{ [1] 18:20:06 Symbolic Error Too few equations, under-determined system. The model has 5 equation(s) and 6 variable(s). }}} In this simple case, inspection shows that {{{a}}}, {{{b}}}, and {{{c}}} are fully determined, while there is a missing equation involving at least one variable in the set {{{ {x, y, z} }}}. If you have a much larger number of equations and variables, this kind of intel could be precious to find out where the problem is. Another interesting case is the following one: {{{ model M3 Real x, y, z; Real a, b, c; equation x + z = 0; x + z = 2; x + y + z = 0; a + b + c = 4; a - c = 2; b + c = 4; end M3; }}} Currently we get (with {{{-d=bltdump}}}): {{{ [2] 18:27:51 Translation Error Internal error IndexReduction.pantelidesIndexReduction failed! Found empty set of continuous equations. Use -d=bltdump to get more information. [3] 18:27:51 Symbolic Error [M3: 6:3-6:12]: Model is structurally singular, error found sorting equations 1: 0.0 = 2.0 for variables 1: x:VARIABLE() M3 type: Real }}} This seems somehow to hint that there is some problem related to variable {{{x}}}, but this information doesn't help much. Better diagnostics should point out the fact that the first two equations are inconsistent, and on the other hand there is not enough information to resolve the ambiguity between {{{x}}} and {{{y}}} I wonder if we could make good use of linear algebra to do this, beyond structural analysis. The SVD analysis of the Jacobian of the system of equations would easily allow to identify the culprits of the singularity. If J = U*S*V', the non-zero elements of each columns of U that correspond to the zero (or near-zero) singular values in S indicate a set of equations involved in a singularity, and the nonzero elements of the columns of V indicate a set of variables involved in the singularity. The only problem I see is that we should actually evaluate that Jacobian numerically at an early stage of the backend. " Francesco Casella 2152 Handle time events efficiently Run-time trunk 2.0.0 enhancement Karim Adbdelhak assigned 2013-04-12T09:03:54Z 2020-07-13T17:11:28Z "The relations {{{ time >= time < }}} can be handled as time events without resorting to crossing functions, thus leading to more efficient simulation code (see Modelica Specification 3.2 rev1, sect. 8.5). We can look for expressions containing only pre(discrete), constant, or parameter expressions. Then it is always possible to calculate the next exact time of this event indicator, by replacing >= (or <) with == and solving for time. If time is <= current time, no more events occur, otherwise schedule next time event and deal with it as with sample() " Martin Sjölund 2891 Hierarchical editing of models OMEdit trunk 2.0.0 enhancement Adeel Asghar new 2014-10-15T18:55:35Z 2022-10-22T15:12:48Z "Consider this conceptual example model {{{ model Car replaceable FrontSuspension frontSuspension; replaceable RearSuspension rearSuspension; ... end Car; model MyCar extends Car(frontSuspension(leftUpperLink(k = 2.4e4))); end MyCar; model CompareCars Car car1(frontSuspension(leftUpperLink(k = 2.4e4))); Car car2(frontSuspension(leftUpperLink(k = 3.6e4))); Car car3(redeclare CustomSuspension frontSuspension); Car car4(rearSuspension(wheel(omega(start = 200)))); end CompareCars; }}} First you build the car model using elements in a library having default values of all the parameters. Then, you want to customize it by changing one value (or one start attribute, or one replaceable class/component) in an inherited class, or to apply changes to different instances of the same model. It should be possible to perform these activities from the GUI. For example, starting from the top level diagram of MyCar, one should be able to show the actual instance of the front suspension, and then change the parameter of the stiffness of the upper link using its parameter window. In the case of CompareCars, one first clicks on car1, then on frontSuspension, then changes the value of the k parameter; or, one clicks on car3, select the frontSuspension, and selects the redeclared class from a drop-down menu with all the choices possible based on the choices annotation. Of course these changes only affect MyCar or CompareCars, not the classes in the library from which Car and FrontSuspension where instantiated. One should be able to navigate across the different levels of a specific model and apply modifers to parameters by (recursively) ""opening"" an instance of a model to see what's inside, and eventually using the parameter window of the corresponding components, or the redeclare feature for replaceable components that have an icon in the diagram view. It would also be nice to be able to navigate this hierarchy on a tree view. These features would be similar to the ""Show component"" and ""Component browser"" windows of Dymola. They are essential to handle models which do not have a flat structure from the GUI. " Francesco Casella 2894 Summary of improvements for OMEdit GUI usability OMEdit trunk 2.0.0 enhancement Adeel Asghar accepted 2014-10-15T19:33:03Z 2021-03-11T12:03:47Z "This ticket is meant to collect and prioritize the improvements that need to be done to the OMEdit GUI in order to make it usable with the MSL and with most modern Modelica 3.4 compliant libraries. Each item is covered by a specific ticket. == Features requiring the new front end to be in place == All the features listed here depend on the front-end to provide correct information to OMEdit, and to do so rapidly. This is now possible by using the new front-end (see #4138), which is exploited by new API functions which are much faster than previously. Version 1.14.0 will use these features by default. * #2079 Replaceable classes and replaceable objects (e.g. the Medium package in all Modelica.Fluid models, or the HeatTransfer model in the Modelica.Fluid.Vessels.ClosedVolume) should show up in the parameter window, with a drop-down menu filled in based on the {{{choices}}} or {{{choicesAllMatching}}} annotations. Once a specific choice is made, it should be possible to change the parameters and/or replaceable classes/models of the redeclared model/component, e.g. by clicking on a button. This feature is essential for the Modelica.Fluid library, as well as for many user libraries such as ThermoPower. * #2081 Conditional connectors should be displayed correctly. This feature is used extensively in the Modelica.Mechanics and Modelica.Electrical libraries. It requires that the API functions return the correct visibility attribute. * #2661 Update parameter-dependent Dialog annotations correctly * #2132 Display conditional connectors correctly by evaluating the corresponding parameters * #2891 Hierarchical editing of systems for graphical modification of parameters and replaceable classes in sub-models. Requires substantial work to implement some API function, as well as in OMEdit to display the information properly. * #3915 Rename feature missing == Other features == * #6417 Keyboard shortcuts for frequent actions such as simulate, switch view * #5529 Insufficient precision when storing sine phases * #4449 Allow several curves in the same parametric plot window * #4645 and #4839 Use blank pixels around lines to enhance readability * #3776 Allow copying/pasting models across diagrams * #3287 Allow input of common parameters and replaceable classes in a multiple component selection. This can shorten the time to set up a model dramatically * #2166 See exact simulation values through snap to curve feature == Past improvements == * #4508 Reduce the installation time under Windows by making the installation of contributed open source libraries optional * #2909, #3788 Drastically reduce the waste of HD space by eliminating useless intermediate output files and reducing the number of useful files * #3054 Clarify ""Revert from previous"" button * #2908 Changes in sub-models should be reflected in models using them immediately, not only when changes to the latter models are made. * #2906 Drop-down choices for enumeration (and possibly boolean) parameters * #2845 Consistent view between textual view and library browser view of packages should be always guaranteed. Requires to update the views in OMEdit whenever the focus is changed between the different sub-windows. * #2391 Improved handling of custom modifers (e.g. start attributes) from the GUI. Modifers, once applied, should still show up when the parameter window is re-opened later. * #2390 Fully support the showStartAttribute annotation, which is widely used in Modelica.Mechanics. * #2190 Copy class feature within the same package. * #2903 Add option to output protected variables to simulation setup window, output tag. * #2477 Better snap-to-grid features when using blocks from the MSL * #2506 Keep connecting lines manhattanized and allow no-nonsense editing of models copied from the MSL (e.g. it should be possible to move one component without weird side-effects on the diagram) * #2611 Zoom issue should be fixed. * #2988 Zoom In/Out with MouseWheel. * #2392 Show default values differently in the Component Parameters window. * #2956 Moving a complete model disassembles everything * #2596 Re-simulate with changed options. Currently if we want to make a new simulation with different simulations options, e.g. a different final time we have to re-build the whole executable, that is a waste of time. * #2985 Updating submodel icons where they are used. This ticket is not really urgent. But it is related to #2908, that has already been fixed, so fixing this one is sort of completion of the job. In case it is difficult to fix it could be postponed. * #1900 Handle connections to expandable connectors in OMEdit * #2250 Support DisplayUnit and unit conversion for parameter input in OMEdit * #3558: Flip icons with text boxes correctly * #2676 Handle models in separate files * #2905 Comment- and formatting-preserving parsing and unparsing is required to avoid that OMEdit scrambles up the code of existing Modelica classes when saving them on file. * #2892 Undo/Redo feature in the Diagram view of the model editor. * #2190 Copy class to a different package. * #2696: Display enhancement of very large and very small numbers on vertical axis * #2960 Speed up the exploration of the package tree and the drag-n-drop actions. * #4504 Allow to install OpenModelica anywhere in the file system, including the default installation directories (such as {{{C:\Program Files}}}) that include spaces * #2395 - Support the connectorSizing annotation. Required by many libraries including Modelica.Fluid, PNLib, iPSL, OpenIPSL " Francesco Casella 3915 Rename feature missing in OMEdit OMEdit 2.0.0 enhancement Adeel Asghar new 2016-05-18T06:37:33Z 2018-02-28T11:31:31Z "There is currently no feature to rename a model in OMEdit; one has to make a copy of the model with the new name and delete the old one. However, all the classes using this model are broken if one does so. It would be nice to have a feature such as in Dymola, whereby upon renaming of a class A into B, all references to A in loaded classes are renamed to B automatically. Would this be hard to implement?" Francesco Casella 3977 Better diagnostics for non-balanced models New Instantiation 2.0.0 enhancement Lennart Ochel new 2016-06-25T15:49:53Z 2020-07-14T02:05:39Z "OMC currently does not help at all determining why a model is not balanced, and it does not exploit Modelica 3.x rules for doing so. Consider the following simple example: {{{ model M Modelica.Blocks.Sources.RealExpression m1(y = 1); Modelica.Blocks.Continuous.FirstOrder m2(k = 1, T = 1); Modelica.Blocks.Sources.IntegerExpression m3(y = 1); Modelica.Blocks.Math.IntegerToReal m4; end M; }}} Trying to simulate it produces the following output: {{{ Error: Too few equations, under-determined system. The model has 4 equation(s) and 6 variable(s). Error: pre-optimization module clockPartitioning (simulation) failed. }}} It's good to know that the simulation failed because of an unbalanced model, but it would be much better to have some hints as to how to fix the problem. In this case, it would be quite easy to see by Modelica 3.x rules (sect. 4.7) that the local number of unknowns of the top-level model is 2, i.e., the sum of the top level public input variables, while the local number of equations is zero, so that the most probable cause of the error is the lack of connect statements involving those input variables. On the other hand, it can be easily determined that the four models m1, m2, m3, and m4 are locally balanced. Furthermore, running the simulation with {{{-d=execstat}}} reveals that a number of pre-optimization back-end operations are performed on the model: {{{ preOpt normalInlineFunction (simulation), preOpt evaluateReplaceProtectedFinalEvaluateParameters (simulation) preOpt simplifyIfEquations (simulation) preOpt expandDerOperator (simulation) preOpt removeEqualFunctionCalls (simulation) }}} IMHO, this a waste of time, as it is already clear from the output of the front-end that the number of equations does not match the number of variables, so that attempting any further optimization is futile. Even worse, any back-end optimization can only have the effect of making the root cause of this problem more obscure to find out, as soon as some diagnostics is in place. My recommendations: - Check that the global number of equations and unknowns are matched for each basic type (Real, Integer, and Boolean) right after the front-end phase, and if they are not, do not proceed with the back-end phase and start the diagnostic phase right away - If the model is globally balanced but later phases of the back-end reveal some singularity, e.g., some parts of the model have too few equations and some others too many, then stop the back-end processing and start the diagnostic phase right away - For the diagnostic phase, check that the models are locally balanced, starting from the top-level model and proceeding in breadth-first fashion in the analysis of the model instantiation graph" Francesco Casella 5245 Trim or possibly remove library patch files Third-Party Libraries 2.0.0 enhancement Martin Sjölund new 2018-12-13T00:24:00Z 2019-06-04T14:13:39Z "The [https://github.com/OpenModelica/OMLibraries OMLibraries] sub-project contains several patch files to adapt shipped libraries to OMC. These patches are provided to serve two purposes - fix language non-conformities, that OMC does not accept, and that were put there by library authors using Modelica tools that do not enforce the standard rigorously - work around OMC current limitations Patches are, well, patches: they serve their purpose, but they are not nice to see, and they require maintenance every time the source library is changed in those parts which are affected. Also, very importantly, they create problems for library developers, that cannot use the patched libraries shipped with OMC, but rather use the source code of the GIT repo directly. For the first purpose, the proper solution is to fix the library source code (e.g. by submitting pull requests on GitHub). For the second purpose, the proper solution is to improve OMC so that the limitations are overcome. It is also well possible that some of those patches are no longer needed. For release 1.14.0, I would suggest that we tentatively try to remove them during the development process, run the entire testsuite, analyze the regressions, and then try as much as possible to solve the issues in the proper way once and for all. Only for those cases that are demonstrated to still be critical, we could reintroduce them as an interim solution. " Francesco Casella 5288 Achieve successful simulation of 100% MSL 3.2.3 models with NF *unknown* 2.0.0 enhancement Francesco Casella assigned 2019-01-21T11:16:35Z 2020-01-15T07:37:25Z "We have a strategic goal of simulating 100% of the MSL models with {{{annotation(experiment(StopTime))}}}, using the new frontend. This involves some remaining issues with the NF, but also some back-end/runtime issues, that were already present with the old FE and are not solved by the new one. At this point in time, there are 15 models that do not simulate successfully in MSL 3.2.3, and other 23 models that don't pass the verification phase. There are also 55 models that still don't have a reference result file, see #5296. I have already identified the following open issues: - New front-end: #5015, #5240, #5284, #5332 - Back-end: #5170, #5235 - Testing infrastructure: #5176 I will update the list as I identify the root cause of the remaining failing models. I think it would be nice if we could fix them before we release 1.14.0. That would be a clearly recognizable milestone for that release." Francesco Casella 5394 Perform CI testing on OMEdit OMEdit 2.0.0 enhancement Adeel Asghar new 2019-03-16T12:20:16Z 2019-05-28T16:44:05Z "Every now and then serious issues pop up with OMEdit, such as losing code or crashing unexpectedly while working with the GUI, see, e.g. #5392, #5393. I'm always unsure whether they are existing problems being finally revealed, or rather actual new problems popping up. For version 2.0.0, we should try hard to set up an automated testing framework for the GUI, that re-enacts pre-recorded command sequences from end-users, for example mimicking the building of new models in a library, and checks if the saved result at the end of the sequence remains the same. This should at least prevent regressions during the compiler development. We can't afford not to have any CI testing on the GUI, which is an essential part for the normal end-user experience. I can volunteer to provide the sequences, but we need: - a recording feature in OMEdit - a testing feature in Hudson/Jenkins to replay the recorded sequences" Francesco Casella 5427 Proper handling of library versions in OMEdit OMEdit 2.0.0 enhancement Adeel Asghar new 2019-04-09T13:13:44Z 2019-04-10T12:31:44Z "The current handling of library versions in OMEdit is quite limited. If a package is opened that has a uses annotation, and the used library is installed in the modelicapath, then it is loaded automatically. However, all kinds of version conflicts are not handled at all, the user just gets this message: Scripting Warning: Requested package NNN of version x.y.z, but this package was already loaded with version a.b.c. You might experience problems if these versions are incompatible. which belongs to the category of the error messages that may scare off inexperienced users, who may wonder: what problems, and, what can I do about it? In particular, the latest version of MSL is pre-loaded in OMEdit, which is a good idea if one wants to start a new project, but may lead to problems if one is using code that requires an older version for any reason. MSL 4.0.0 is planned to be rolled out in one year, and it will not be backwards compatible, thus requiring conversion scripts. We may expect that for some time people may want to keep on using MSL 3.2.3, so by that time, we need to have a comprehensive user-friendly solution in place. This is a first sketch of the user requirements, but I think we should iterate on it until we find it completely satisfactory. - OMEdit preloads the latest version of the MSL at startup (or a previous version, if specified in the OMEdit setup, this could be handy during the MSL 4.0.0 transition). - When a package is loaded that uses a previous version of an already loaded package (including the MSL), a dialog should be provided with the options of - unload the current version of the used library and load the older one instead, either from modelicapath, or by opening a file - update the loaded library to the current version of the used library, running conversion scripts if necessary (see #5297) - keep using the current library without updating the loaded library (assuming you know what your're doing, do it at your own risk). This mechanism should work consistently even in the case of multiple dependencies; for example, if I first load library A that requires MSL 3.2.2 and I decide to load that instead of MSL 3.2.3, if I then load library B that wants 3.2.3 instead we can't just unload MSL 3.2.2, because that would break library A. I still don't know exactly what is the best way to handle these situations, I guess we should brainstorm a bit. In case the {{{conversion ( noneFromVersion = VERSION-NUMBER)}}} is present, the dialogs should make it clear that the conversion requires no changes and it should not generate issues. The presence of conversion scripts, once supported, should be notified, and we may suggest the user to check the library release notes for news about the updates. It would be nice if the version annotations contained library-specific information about the conversion, maybe we should make this proposal to the MAP-LANG group. " Francesco Casella 5547 Including c-files from external_solvers for nonlinearSolverHomotopy FMI v1.14.0-dev-nightly 2.0.0 enhancement Lennart Ochel new 2019-06-24T13:48:41Z 2020-06-05T08:43:00Z "When exporting some FMU, '''' is included in the modelDescription.xml. When trying to integrate the FMU for a real-time test bench,it is often that the source files will be recompiled to make a rt-application and i always get the 'linearSolverWrapper' error because dgesv.c is not included in the modelDescription. Adding dgesv.c manually resulting in more undefined referenced, taht resolved by including these c-file: {{{ dgesv.c; xerbla.c; dgetrf.c; dgetrs.c; ilaenv.c; dgetf2.c; dlaswp.c; dtrsm.c; dgemm.c; lsame.c; s_camp.c; iparamq.c; ieeeck.c; s_copy.c; dlamch.c; idamax.c; dswap.c; dger.c; dscal.c and i_nint.c }}} Would it be possible to include above files in modelDescription.xml when exporting FMU? thanks in advance" Arinomo 5985 Code foldings for ssp source code OMEdit 2.0.0 enhancement Adeel Asghar new 2020-05-26T08:43:23Z 2020-06-12T13:56:37Z Code folding for xml nodes would help a lot, especially because text editing is only supported for the root node (entire model). Adeel Asghar 6135 Support of Visual Studio in OMEdit on Windows Run-time 2.0.0 enhancement Mahder Alemseged Gebremedhin accepted 2020-09-23T08:54:41Z 2020-09-24T07:22:45Z "The VS compiler is extremely fast, because it is specifically optimized for the Windows/Intel combination. We should enable the possiblity of using it to compile simulation executables, to reduce the lag from the pressing of the simulation button to the start of the actual simulation. I tentatively assign this to mahge930, since he's already been working with CMAKE and has some experience on this topic." Francesco Casella 6340 Automatically recognize if a model is best run with daeMode *unknown* 1.16.0 2.0.0 enhancement Andreas Heuermann new 2021-01-13T23:06:10Z 2021-02-05T19:13:41Z "Power systems models built with the {{{PowerGrids}}} library have a peculiar property: while the Jacobian of the DAE system is highly sparse, if the system is causalized, the ODE formulation has a dense Jacobian, which makes using implicit ODE integration extremely less efficient than direct DAE integration. This is a structural property that is easily recognisable by looking at the sparsity ratio of the DAE and of the ODE Jacobians. If the former is much lower than the latter, we should issue a warning and propose the end user to use {{{--daeMode}}} for more efficient integration. In OMEdit, it should be possible in this case to set the flag in an annotation by just clicking on some button. We should probably do the same for models that have very large nonlinear strong components, because in that case there is a nested iteration of large nonlinear implicit solvers (the inner algebraic solver, and the outer BDF solver) that will be much less efficient than solving both at once with the BDF solver. Dymola has been giving this warning for a while." Francesco Casella 4032 Using Extern C function compiler generates duplicate variables. Code Generation v1.9.4-v1.9.x Future defect Lennart Ochel new 2016-08-26T15:02:27Z 2016-09-05T11:55:51Z "When using an external C function, the simulation returns the following error: {{{ Error: Error building simulator. Build log: gcc -falign-functions -msse2 -mfpmath=sse -I""C:/OpenModelica1.9.6//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o IntegrateInterpolatedExternalVector.o IntegrateInterpolatedExternalVector.c gcc -falign-functions -msse2 -mfpmath=sse -I""C:/OpenModelica1.9.6//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o IntegrateInterpolatedExternalVector_functions.o IntegrateInterpolatedExternalVector_functions.c gcc -falign-functions -msse2 -mfpmath=sse -I""C:/OpenModelica1.9.6//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o IntegrateInterpolatedExternalVector_records.o IntegrateInterpolatedExternalVector_records.c gcc -falign-functions -msse2 -mfpmath=sse -I""C:/OpenModelica1.9.6//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o IntegrateInterpolatedExternalVector_01exo.o IntegrateInterpolatedExternalVector_01exo.c gcc -falign-functions -msse2 -mfpmath=sse -I""C:/OpenModelica1.9.6//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o IntegrateInterpolatedExternalVector_02nls.o IntegrateInterpolatedExternalVector_02nls.c IntegrateInterpolatedExternalVector_functions.c: In function 'omc_VectorTable_destructor': IntegrateInterpolatedExternalVector_functions.c:14: error: redeclaration of '_table_ext' with no linkage IntegrateInterpolatedExternalVector_functions.c:13: note: previous declaration of '_table_ext' was here IntegrateInterpolatedExternalVector_functions.c:17: error: void value not ignored as it ought to be mingw32-make: *** [IntegrateInterpolatedExternalVector_functions.o] Error 1 mingw32-make: *** Waiting for unfinished jobs.... RESULT: 2 }}} I went to file IntegrateInterpolatedExternalVector_functions.c (attached) and found that variables are actually being declared twice. " guillegiraldo@… 4222 Previously simulating models do not work any more Initialization Future defect Lennart Ochel accepted 2017-01-19T20:28:28Z 2017-01-29T14:05:59Z "We are currently developing the PhotoVoltaics Modelica library on GitHub. Please consider https://github.com/christiankral/PhotoVoltaics/tree/c79bd0d93cfc9b5b2eae2a6f2ea991d781419195 The model {{{PhotoVoltaics.Examples.SimpleModuleShadow}}} was compiling in a previous model of the OpenModelcia but it does not work any more in the actual Nightly Build OMEdit 1.12.0~dev-129-g0ee4ed0 Connected to OpenModelica 1.12.0~dev-242-g7d151a2 Linux Mint 18.1 The actual error message after compiling the model is {{{ stdout | OMEditInfo |

/tmp/OpenModelica_christian/OMEdit/PhotoVoltaics.Examples.SimpleModuleShadow -port=46358 -logFormat=xmltcp -override=startTime=0,stopTime=1,stepSize=0.001,tolerance=1e-06,solver=dassl,outputFormat=mat,variableFilter=.* -r=PhotoVoltaics.Examples.SimpleModuleShadow_res.mat -jacobian=coloredNumerical -w -lv=LOG_STATS

LOG_NLS | warning |

nonlinear system 1329 fails: at t=0

LOG_NLS_V | warning |

proper start-values for some of the following iteration variables might help

LOG_NLS_V | warning |

[1] Real module.cell[46].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[2] Real module.cell[45].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[3] Real module.cell[44].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[4] Real module.cell[43].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[5] Real module.cell[42].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[6] Real module.cell[41].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[7] Real module.cell[40].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[8] Real module.cell[39].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[9] Real module.cell[38].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[10] Real module.cell[37].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[11] Real module.cell[36].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[12] Real module.cell[35].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[13] Real module.cell[34].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[14] Real module.cell[33].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[15] Real module.diode[3].v(start=0, nominal=1)

LOG_NLS_V | warning |

[16] Real module.cell[31].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[17] Real module.cell[30].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[18] Real module.cell[29].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[19] Real module.cell[28].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[20] Real module.cell[27].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[21] Real module.cell[26].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[22] Real module.cell[25].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[23] Real module.cell[24].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[24] Real module.cell[23].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[25] Real module.cell[22].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[26] Real module.cell[21].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[27] Real module.cell[20].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[28] Real module.cell[19].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[29] Real module.cell[18].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[30] Real module.cell[17].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[31] Real module.cell[16].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[32] Real module.cell[15].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[33] Real module.cell[14].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[34] Real module.cell[13].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[35] Real module.cell[12].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[36] Real module.cell[11].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[37] Real module.cell[10].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[38] Real module.cell[9].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[39] Real module.cell[8].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[40] Real module.cell[7].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[41] Real module.cell[6].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[42] Real module.cell[5].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[43] Real module.cell[4].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[44] Real module.cell[3].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[45] Real module.cell[2].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[46] Real module.cell[1].diode.v(start=0, nominal=1)

LOG_NLS_V | warning |

[47] Real module.cell[48].v(start=0, nominal=1)

LOG_NLS_V | warning |

[48] Real module.diode[1].i(start=1e-11, nominal=1)

LOG_NLS_V | warning |

[49] Real module.cell[1].diode.i(start=0, nominal=1)

LOG_NLS_V | warning |

[50] Real module.cell[37].diode.i(start=0, nominal=1)

LOG_NLS_V | warning |

[51] Real module.cell[22].diode.i(start=0, nominal=1)

assert | debug |

Solving non-linear system 1329 failed at time=0.
For more information please use -lv LOG_NLS.

assert | info |

simulation terminated by an assertion at initialization

stdout | error |

Simulation process failed. Exited with code 255.

}}} I tried to propose more ""exact"" start values to the model, especially for {{{module.cell[#].diode.v(start=0, nominal=1)}}}, but this did not help either. " Christian Kral 4766 Updating 3rdParty and OMCompiler in the PR job does not work Build Environment Future defect Martin Sjölund assigned 2018-02-15T17:15:28Z 2018-02-15T21:32:45Z If you give a PR for both OMCompiler and 3rdParty the 3rdParty is not updated in OMCompiler. Adrian Pop 6004 Cpp runtime on Windows can't handle spaces in install path Cpp Run-time v1.16.0-dev Future defect Adrian Pop assigned 2020-06-12T10:23:34Z 2020-06-13T20:26:36Z "The C++ runtime can't handle the default installation location `C:\Program Files\OpenModelica1.16.0-dev-64bit\` on Windows because of the space. For omsicpp sim code target: test.mos: {{{ loadString(""model M end M;""); getErrorString(); setCommandLineOptions(""-d=newInst --simCodeTarget=omsicpp""); getErrorString(); simulate(M); getErrorString(); }}} Run mos script: {{{ true """" true """" record SimulationResult resultFile = """", simulationOptions = ""startTime = 0.0, stopTime = 1.0, numberOfIntervals = 500, tolerance = 1e-006, method = 'dassl', fileNamePrefix = 'M', options = '', outputFormat = 'mat', variableFilter = '.*', cflags = '', simflags = ''"", messages = ""Failed to build model: M"", timeSimulation = 0.0, timeTotal = 0.3822554 end SimulationResult; ""Error: Error building simulator. Build log: mingw32-make: Entering directory 'D:/WORKSP~1/TESTIT~1/M82C0~1.FMU' \""mkdir.exe\"" -p M.fmutmp/sources M.fmutmp/sources/include M.fmutmp/sources/libs \""mkdir.exe\"" -p M.fmutmp/resources \""mkdir.exe\"" -p M.fmutmp/binaries/win64 # Basic OMSI and OMSIC files cp -a C:/Program Files/OpenModelica1.16.0-dev-64bit/include/omc/omsi/* M.fmutmp/sources/include/ cp: cannot stat 'C:/Program': No such file or directory cp: cannot stat 'Files/OpenModelica1.16.0-dev-64bit/include/omc/omsi/*': No such file or directory M_FMU.makefile:69: recipe for target 'copyFiles' failed mingw32-make: *** [copyFiles] Error 1 mingw32-make: Leaving directory 'D:/WORKSP~1/TESTIT~1/M82C0~1.FMU' RESULT: 2 "" }}} And for `--simCodeTarget=cpp` I get: {{{ $ ""C:\Program Files\OpenModelica1.16.0-dev-64bit\bin\omc"" BouncingBallFMI20_cpp.mos --locale=en true """" true """" record SimulationResult resultFile = """", simulationOptions = ""startTime = 0.0, stopTime = 1.0, numberOfIntervals = 500, tolerance = 1e-006, method = 'dassl', fileNamePrefix = 'M', options = '', outputFormat = 'mat', variableFilter = '.*', cflags = '', simflags = ''"", messages = ""Simulation execution failed for model: M WARNING: other : Warning: unrecognized command line options Files/OpenModelica1.16.0-dev-64bit/lib//omc/omsicpp/ Simulation stopped with error in model factory: Failed loading SimController library from path C:\\Program\\libOMCppSimController.dll"", timeFrontend = 0.0003001, timeBackend = 0.0066663, timeSimCode = 0.0004555, timeTemplates = 0.0507363, timeCompile = 7.3837476 end SimulationResult; """" }}} " Andreas Heuermann 3565 OMC does not tell the user what it is doing *unknown* defect new 2015-11-18T16:23:54Z 2021-09-13T11:58:21Z "When compiling models of significant size (not necessarily very large), omc can take a few minutes (or possibly hours) to complete the process. It is often the case that nothing is printed to the console or log file for a long time, so one doesn't have a clue about what is happening, and can only stare at a blank window, wait indefinitely and hope for the best. This can be really frustrating from an end-user perspective. Proposal: - add a debug flag (e.g. {{{+d=logCompilationPhases}}} that prints a message on stdout every time a major phase in the compilation process is started (e.g. front-end, back-end, simcode, templates, C compilation), and that records the time spent for each phase once completed - add a debug flag (e.g. {{{+d=logCompilationPhasesDetailed}}} that prints a message on stdout every time a specific activity is started (e.g. for the back-end it could be every single optimization module, for the front-end and code generation I don't know) and record the time spent for each phase once completed - flush the stream after each message is written, so that it can actually be captured by the console or by OMEdit, displayed in a timely manner, and not get lost if the process needs to be killed because of timeout or too much memory allocation All these messages could have some common header, so that OMEdit can filter them out and display them nicely in some window showing the progress in the compilation phase." Francesco Casella 3905 findZeroCrossings scales as O(N^2) Backend defect Martin Sjölund new 2016-05-12T16:49:21Z 2021-09-13T11:58:21Z "As demonstrated by the {{{BreakerCircuit}}} models of the {{{ScalableTestSuite}}}, the findZeroCrossing function scales as O(N^2^). It is currently the biggest bottleneck in our large network models, when including line breakers and current protections, which generate up to 40000 zero-crossing functions. @hkiel reports that findZeroCrossings uses lots of listAppend() in wrong order (mostly appending a single element). Either someone can switch the code to build the lists in reverse order (does order matter annyhow?) or use the DoubleEndedList. I'm currently too busy to do such a huge task. In fact the order doesn't matter at all, so I guess DoubleEndedList would do the job." Francesco Casella 4024 Bugs in generating xml files Code Generation v1.11.0 defect Lennart Ochel new 2016-08-11T17:21:45Z 2021-09-13T11:58:21Z "Hi guys, I found several new bugs for OpenModelica v1.11.0-dev-54-g4ec62d0. I attached the xml file and model file. 1.On line 159 of xml file, I think we should exchange line 159 and line 160, since 'exp:QualifiedNamePart' on line 153 does not close. {{{ 150: 151: 152: 153: 154: 155: 156: 1 157: 158: 159: 160: 161: }}} 2.On line 2985, the 'min' attribute should be '-100000.0'. {{{ 2985: }}} 3.On line 10160, based on the schema '​https://svn.jmodelica.org/trunk/XML/daeEquations.xsd', 'equ:Equation' is not allowed inside 'exp:Sub'. {{{ 10158: 10159: 10160: 10161: 10162: }}} 4.On line 31810, it is illegal based on schema '​https://svn.jmodelica.org/trunk/XML/daeFunctions.xsd' {{{ 31810: }}} 5. On line 20240, we miss '' in schema. Actually not only 'Homotopy', a lot of other builtin functions are missing. For example, 'semiLinear', 'dealy', and so on. {{{ 20240: }}}" anonymous 4215 Cannot access connectors within icon graphics or nested models OMEdit defect Adeel Asghar reopened 2017-01-13T08:01:26Z 2021-09-13T11:58:21Z "Some models place connectors or whole models within the icon graphics. OMEdit does not give access to them, making it impossible to use the models graphically. See for example: - `Modelica.Blocks.Examples.InverseModel`: it is impossible to use the connectors of `firstOrder1` with the mouse or to open the parameter dialog of `firstOrder1` (OMEdit only activates the surrounding inverseBlockConstraints). - `Modelica_Synchronous.Examples.Systems.ControlledMixingUnit`: same behavior for `invMixingUnit` -- just more interesting example Moreover OMEdit renders the connector `y2` of `Modelica.Blocks.Math.InverseBlockConstraints` at a wrong place. " Rüdiger Franke 4370 Modelica.Mechanics.Translational.Components.Fixed rises an error when parameter is changed Run-time v1.12.0 defect Adrian Pop assigned 2017-03-25T17:48:09Z 2021-09-13T11:58:21Z "Please consider the following model: {{{ model pippo Modelica.Mechanics.Translational.Components.Fixed fixed1 annotation( Placement(visible = true, transformation(origin = {0, 2}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); annotation( uses(Modelica(version = ""3.2.2""))); end pippo; }}} Now open the parameter window and insert the following value for the s0 parameter: (1+2)/3 the following error is thrown and the parameter value is not set: [1] 18:40:33 Scripting Error Unable to set the component modifier value using command setComponentModifierValue(pippo, fixed1.s0, $Code((1+2)/3)) [2] 18:40:34 Translation Error Class setComponentModifierValue not found in scope (looking for a function or record). The problem seems linked to the use of the parenthesis in the parameter value... OMEdit 1.12.0~dev-250-g0f5c07d Connected to OpenModelica 1.12.0~dev-561-gc489db1 sysop Ubuntu 14.04 - 64 bit" Andrea Bartolini 4410 moving a replaceable object in the block diagram duplicates the graphical annotation in text view OMEdit v1.12.0 defect Adrian Pop accepted 2017-05-02T17:11:46Z 2021-09-13T11:58:21Z "consider the following model (also attached): {{{ package test partial model A annotation( Diagram, Icon(graphics = {Rectangle(extent = {{-100, 100}, {100, -100}}), Text(origin = {2, -1}, extent = {{-32, 41}, {32, -41}}, textString = ""A"")})); end A; model B extends A; end B; model C replaceable B b1 constrainedby A annotation( Placement(visible = true, transformation(origin = {0, 0}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); end C; end test; }}} now open the model C and move the model B in the block diagram, the graphical annotation in the text view is duplicated as follows: {{{ model C replaceable test.B b1 annotation( Placement(visible = true, transformation(origin = {-24, 0}, extent = {{-10, -10}, {10, 10}}, rotation = 0))) constrainedby A annotation( Placement(visible = true, transformation(origin = {0, 0}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); end C; }}} this behavior seems depend from the presence of the clause ""constrainedby"" OMEdit 1.12.0~dev-290-g1b6ac20 Connected to OpenModelica 1.12.0~dev-703-g46bfb1f sysop: linux Ubuntu 16.04 " Andrea Bartolini 4477 C++ Runtime Regression for pre(array) crefs Cpp Run-time defect somebody new 2017-07-24T06:28:18Z 2021-09-13T11:58:21Z "When simplifying equations like `{x[1], ..., x[n]}` into `x`, it seems the C++ runtime could not handle this for pre-expressions. There is an easy way to fix the problem by disabling the new optimization module collapseArrayExps for the C++ runtime only. But I think the generated code should handle pre of arrays instead (or possibly to not collapse pre() of arrays). See [http://libraries.openmodelica.org/branches/history/master/2017-07-20%2023:12:31..2017-07-21%2013:04:17.html the regression testing] for affected models." Martin Sjölund 4510 Importance of residual scaling for the proper operation of the default nonlinear solver Run-time defect somebody new 2017-09-04T20:56:18Z 2021-09-13T11:58:21Z "This test is similar to the one shown in #4395, but it uses the standard nonlinear solver, see the attached file. Test2 is nicely scaled by itself. Test3 is badly scaled, but has all the nominal attributes needed to scale it up correctly. Test2 runs in 0.7 seconds on my PC. Test3 takes 51 seconds. My conjecture is that if residuals are scaled as suggested in ticket:4395#comment:3 (a trivial operation) there is no reason performance on Test3 should not be about the same as on Test2." Francesco Casella 4656 Small delays give badly wrong results Run-time defect Willi Braun new 2017-12-04T18:37:32Z 2021-09-13T11:58:21Z "Detailed transmission lines models require the use of cascaded pure time delays. High-resolution models require a large number of very small cascaded delays. Unfortunately, in this situation the way OMC handles delays is totally unsatisfactory. The following model demonstrates the problem: {{{ model TestDelay parameter Integer N = 100; parameter Real Tau = 10; parameter Real dt = Tau/N; Real y[N+1](start = zeros(N+1)); Real out = y[N+1]; Real x(start = 0, fixed = true); equation y[1] = if time < 1 then 0 else 1; for j in 2:N+1 loop y[j] = delay(y[j-1], dt); end for; der(x) = 1-x; annotation( experiment(StartTime = 0, StopTime = 20, Tolerance = 1e-06, Interval = 0.02)); end TestDelay; }}} This model apparently works fine: the variable {{{out}}} follows {{{y[1]}}} with a delay of 10 seconds. The output interval in this case is 20 ms, and each individual delay is 100 ms, which is an exact multiple. If you change Interval so that each individual delay is not an exact multiple of the interval itself, e.g. 30 ms, the output is warped. If the Interval is more than the delay, e.g. 120 ms, the result is severely wrong. If noEquidistantTimeGrid is activated, the result is even worse, apparently because of the large size of many steps (i.e, intervals in this case) compared to the individual time delays. Dymola provides the correct results in all these cases. In general, the correctness of the final state of a simulation should not depend on the communication interval length, at least if variable step-size solvers are used for the continuous-time part. In particular, it seems weird that to ensure the correctness of the delay() operator output, it is necessary to have a communication interval which is much shorter than the delay itself. Can you please fix the implementation of the delay operator so as to avoid this syndrome? " Francesco Casella 4658 OMEdit does not show pop-up list of enumeration type in parameter's pop-up window OMEdit v1.13.0-dev-nightly defect Adeel Asghar new 2017-12-06T09:17:51Z 2021-09-13T11:58:21Z "Consider the following test (also attached) {{{ package Test model A type ActionType = enumeration (direct ""action is direct"", reverse ""action is reverse""); end A; model B extends A; parameter ActionType action1; parameter Test.A.ActionType action2; end B; model C B b1 annotation( Placement(visible = true, transformation(origin = {-50, -2}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); end C; end Test; }}} Open the model C and double-click on model b1: in parameters pop-up window the pop-up list is shown only for the parameter {{{action2}}}. The problem seems related to the path in parameter definition. OMEdit 1.13.0~dev-65-g33fb188 Connected to OpenModelica 1.13.0~dev-438-g85aa869 sysop linux Ubuntu 16.04 - 64 bit" Andrea Bartolini 4693 Changing input values in interactive simulation fails for model sizes above a certain threshold Interactive Environment v1.13.0-dev-nightly defect somebody new 2017-12-19T18:52:19Z 2021-09-13T11:58:21Z "Hi all, Some part of OM shows broken behavior when simulating a model interactively. In the following model, the target was to set the external input u1 to some value (say 1) during interactive simulation. {{{ model test Real M1; Real M2; Real M3; Real M4; Real M5; Real M6; Real M7; Real M8; Real M9; Real M10; Real M11; Real M12; Real M13; Real M14; Real M15; Real M16; Real M17; Real M18; Real M19; Real M20; //Real M21; Modelica.Blocks.Interfaces.RealInput u1; Real y; equation y = 2 * u1; M1 = 100; M2 = 100; M3 = 100; M4 = 100; M5 = 100; M6 = 100; M7 = 100; M8 = 100; M9 = 100; M10 = 100; M11 = 100; M12 = 100; M13 = 100; M14 = 100; M15 = 100; M16 = 100; M17 = 100; M18 = 100; M19 = 100; M20 = 100; //M21 = 100; end test; }}} With the above model, it works as expected. Now retry the same with the following model: {{{ model test Real M1; Real M2; Real M3; Real M4; Real M5; Real M6; Real M7; Real M8; Real M9; Real M10; Real M11; Real M12; Real M13; Real M14; Real M15; Real M16; Real M17; Real M18; Real M19; Real M20; Real M21; Modelica.Blocks.Interfaces.RealInput u1; Real y; equation y = 2 * u1; M1 = 100; M2 = 100; M3 = 100; M4 = 100; M5 = 100; M6 = 100; M7 = 100; M8 = 100; M9 = 100; M10 = 100; M11 = 100; M12 = 100; M13 = 100; M14 = 100; M15 = 100; M16 = 100; M17 = 100; M18 = 100; M19 = 100; M20 = 100; M21 = 100; end test; }}} Here, after setting u1 = 1 in interactive mode, u1 takes a wrong and extremely small value, around 3e-304. This behavior seems to depend on model size (in this case, at least). I also observe this behavior when not using the OMedit interactive environment but using UAexpert to connect to the created OPC UA server and change the value of u1 there. " anonymous 4886 OMCompiler fails to build with lapack 3.8.0 Build Environment v1.14.0-dev-nightly defect Martin Sjölund new 2018-04-16T21:34:00Z 2021-09-13T11:58:21Z "I'm currently building package of openmodelica for openSUSE. Some days ago, after the uploading of lapack 3.8.0 on factory and then tumbleweed openmodelica fails to build with : [ 1646s] /home/abuild/rpmbuild/BUILD/openmodelica-1.13.0dev~git20180416/OMCompiler/Compiler/runtime/libomcruntime-boot.so: undefined reference to `dgeqpf_' [ 1646s] /home/abuild/rpmbuild/BUILD/openmodelica-1.13.0dev~git20180416/OMCompiler/Compiler/runtime/libomcruntime-boot.so: undefined reference to `dgegv_' [ 1646s] /home/abuild/rpmbuild/BUILD/openmodelica-1.13.0dev~git20180416/OMCompiler/Compiler/runtime/libomcruntime-boot.so: undefined reference to `dgelsx_' Here is the full build log : https://build.opensuse.org/package/live_build_log/home:bosconovic:openomdelica/openmodelica-dev/openSUSE_Tumbleweed/x86_64" bosconovic@… 4903 Memory leak? Backend v1.13.0-dev-nightly defect Lennart Ochel new 2018-04-27T05:59:35Z 2021-09-13T11:58:21Z "I attached a fairly simple model that uses the AixLib for simulating a simple heat pump operation. To run the model, within OMEdit: - load AixLib (either installed default lib version 0.5.2 or github version) - load all models in ""components"" subdirectory of archive - load HPStorage_System4.mo - run model (simulation time 1 year = 31536000 s, output steps 10 min = 600 s), use either colored jacobian (or numerical dense)... When running the attached model I notice two things: 1. performance is extremely low on Windows - model takes approx. 50 mins, OpenModelica on Linux (same machine) takes about 10 mins, whereas Dymola takes only 32 seconds... might be an indication that something is going wrong??? 2. during simulation the model continuously takes up memory starting with a few hundret Mb up to > 2 Gb of memory. That looks strange and may contribute to the performance problem. " Andreas Nicolai 4994 Is startTime a built-in variable in OMC? OMEdit defect Adeel Asghar assigned 2018-06-20T14:45:09Z 2021-09-13T11:58:21Z "Consider this test case {{{ model Test parameter Real startTime = 1; end Test; }}} When simulating it with OMC, the value of startTime is computed to be the value of StartTime in the simulation setup window, completely disregarding the binding equation. Since startTime is a perfectly legal Modelica parameter name, if you use it in a model some nasty surprises will ensue..." Francesco Casella 5041 assert on parameters are not called in the right order Backend defect Lennart Ochel new 2018-07-10T18:02:28Z 2021-09-13T11:58:21Z "Please consider the following test case {{{ model TestInitialAssert parameter Real p = 0; parameter Real q = 1/p; initial equation assert(p > 0, ""p must be positive""); end TestInitialAssert; }}} OMEdit fails with {{{ assert | debug | division by zero at time 0, (a=1) / (b=0), where divisor b expression is: p }}} In fact, the model contains an assertion on {{{p}}} that could convey more useful information to the end user, but which is not triggered because the expression {{{1/p}}} is evaluated first and causes the initialization to fail, which is precisely the reason why the assertion was put there in the first place. Recommendation: assertions should be evaluated as early as possible in the BLT, i.e. as soon as the variables/parameters they depend on have been computed. In this case, the assertion on {{{p}}} should be computed right after the binding equation {{{p = 1}}} has been evaluated, also in the case the assertion is put in the {{{equation}}} section." Francesco Casella 5175 OMEdit cannot create models as separate .mo files OMEdit defect Adeel Asghar new 2018-10-16T14:30:37Z 2021-09-13T11:58:21Z "Steps to replicate the issue: - open the attached package - right-click on TestPackage, select New Modelica class - create a Model Unfortunately there is no way to select whether you want the model to be saved as a separate .mo file or within the existing (package.mo) file. This is only possible with Packages. Ditto for other types of classes like function, connector, etc. Of course you can create a package as a separate file, then edit its code and change the {{{package}}} keyword into {{{model}}} or other types of classes, but that's more like a hack." Francesco Casella 5291 Issue with Modelica.Mechanics.MultiBody.Examples.Elementary.RollingWheel in OMEdit OMEdit defect Adeel Asghar new 2019-01-23T00:14:49Z 2021-09-13T11:58:21Z "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 [https://libraries.openmodelica.org/branches/newInst/Modelica_trunk/files/Modelica_trunk_Modelica.Mechanics.MultiBody.Examples.Elementary.RollingWheel.sim 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?" Francesco Casella 5682 Provide information about wrong graphical annotations when checking models in OMEdit Interactive Environment defect Adrian Pop assigned 2019-10-31T00:34:37Z 2021-09-13T11:58:21Z "Some time ago, we decided to suppress a lot of warnings issued by OMC when interacting with OMEdit, that were really confusing for end-users, who just saw lots of issues without having any means to understand them, let alone fix them. See #5048. I think this is the correct approach from an end-user perspective. Hoever, @lochel correctly pointed out that, in his role of library developer, he does not get any error message regarding wrong graphical annotations, which however has serious consequences (-> wrong diagram displayed). This is demonstrated by the attached model, which has a wrong annotation ({{{exxtent}}} is misspelled). This has a consequence on the displayed diagram (which uses the default extent instead), but there is no way to have OMEdit report where the problem is. We agreed that the best solution is that those messages are normally suppressed, but are indeed shown when the model is ''checked''. I'm not sure if this should be done by the frontend, or if rather some extra API call should be performed after checking, without suppressing the output. @adeas31, can you please take care of that?" Francesco Casella 5714 Build linux stable release only when tagging new versions on maintenance branch Installation program defect Adrian Pop assigned 2019-11-25T13:03:42Z 2021-09-13T11:58:21Z "Currently, the stable release on Linux is re-built every night from whatever is found on the {{{HEAD}}} revisio of the {{{maintenance}}} branch. This is kind of nice because it provides a sort of ""nightly build"" for beta versions, but on the other hand it is not the same as in Windows and it can be quite confusing, as well as potentially dangerous if something wrong is done on the mainteance branch before tagging a new beta. I would suggest to only build the Linux version when tagging a new beta release, as implicitly suggested in the [https://openmodelica.org/download/download-linux download page]." Francesco Casella 5725 Issues with start values in ThermoSysPro Backend defect Karim Adbdelhak new 2019-12-03T15:09:33Z 2021-09-13T11:58:21Z "During today's Board meeting, I discussed with Daniel Bouskela of an issue that they are frequently encountering with ThermoSysPro models. All the models in the library work with Dymola, but many of them do not work in OpenModelica because of some missing start values. One way to avoid this issue is to make sure that we expoit the information which is implicitly given by the modeller when adding start values in the model, i.e., to prefer those variables as iteration variables when using tearing. We already did something along these lines in #5458, but apparently this is not enough. For example, the model [https://libraries.openmodelica.org/branches/master/ThermoSysPro/files/ThermoSysPro_ThermoSysPro.Examples.Book.SimpleExamples.HeatExchanger.TestDynamicTwoPhaseFlowPipe.sim ThermoSysPro.Examples.Book.SimpleExamples.HeatExchanger.TestDynamicTwoPhaseFlowPipe] fails during initialization, while it works with Dymola. Daniel suggests that we implement a feature to load the missing start values from an existing solution (e.g. a {{{.mat}}} result file obtained from Dymola) and automatically add modifiers to the model to ensure convergence. This can be considered as a last resort measure, which can useful in a context where you have a few Dymola licenses and you want people to reuse those models with open-source tools. I would personally prefer to understand first if we can avoid these failures by exploiting all the available information in the original Modelica model. Karim, Andreas, if you are interested you could have a quick look, by comparing how Dymola solves the equation where OMC fails." Francesco Casella 5813 Improve selection of start attributes for alias variables Backend defect Francesco Casella new 2020-01-30T16:41:14Z 2021-10-18T17:06:05Z "The selection of start attributes in alias variable sets is a crucial issue: oftentimes one element of the alias variable set has a carefully user-selected value, while the other ones have default values. It is of paramount importance that the user-selected value is used by the back-end, e.g. to set up the initial guess of iterative solvers, and that this value is not overridden by other less relevant defaults. This issue has been well-known in the Modelica community for a long time, and actually brought to [https://specification.modelica.org/v3.4/Ch8.html#recommended-selection-of-start-values Section 8.6.2] of the Modelica specification. However, it seems to me that the criterion put forward there doesn't cover all the cases satisfactorily. This leads to the detection of start value conflicts which aren't really there, or (worse) to the selection of the wrong start values, which is what I am constantly experiencing with steam power plant models. Consider the following examples {{{ package Aliases type Temperature = Real(start = 300, unit=""K""); type Power = Real(unit=""W""); connector Port Temperature T; flow Power Q; end Port; model TemperatureSource parameter Temperature Tstart = 320; Temperature T1; Temperature T2(start = 310); Temperature T3(start = Tstart); Port port; equation port.T = T1; T1 = T2; T2 = T3; T1+1e-6*sin(T1) = 300 ""Implicit equation on T1""; end TemperatureSource; model PowerSource parameter Temperature Tstart = 320; Port port; Temperature T1; Temperature T2(start = 330); Temperature T3(start = Tstart); equation port.T = T1; T1 = T2; T2 = T3; port.Q - (port.T-300) = sin(time); end PowerSource; model WrappedTemperatureSource parameter Temperature Tstart = 345; Port port; TemperatureSource ts(Tstart = Tstart); equation connect(ts.port, port); end WrappedTemperatureSource; model WrappedPowerSource parameter Temperature Tstart = 345; Port port; PowerSource ps(Tstart = Tstart); equation connect(ps.port, port); end WrappedPowerSource; model System1 TemperatureSource ts; PowerSource ps; equation connect(ts.port,ps.port); end System1; model System2 TemperatureSource ts(Tstart = 350); PowerSource ps; equation connect(ts.port,ps.port); end System2; model System3 TemperatureSource ts(T1(start = 360)); PowerSource ps; equation connect(ts.port,ps.port); end System3; model System4 WrappedTemperatureSource ts(Tstart = 370); PowerSource ps; equation connect(ts.port,ps.port); end System4; model System5 TemperatureSource ts; WrappedPowerSource ps(Tstart = 380); equation connect(ts.port, ps.port); end System5; model System6 WrappedTemperatureSource ts(ts(T1(start = 390))); WrappedPowerSource ps(Tstart = 400); equation connect(ts.port, ps.port); end System6; end Aliases; }}} At the end of the day, after alias elimination, each of these models has two unknowns: a power flow and a temperature. Everything else are aliases. As an end-user and library developer, I would like the following start values to be selected for the temperature: - System1: 320 - System2: 350 - System3: 360 - System4: 370 - System5: 380 - System6: 390 As far as I understand, the current rules of Section 8.6.2 do not guarantee these choices are taken. In fact, with the current 1.16.0-dev version of OMC, I get: - System1: 330 - System2: 330 - System3: 330 - System4: 330 - System5: 300 - System6: 330 which is ''never'' the value I would expect. I haven't checked with Dymola yet, but I suspect the results will be similar. We should 1. figure out rules to guarantee those choices are made 2. understand how to collect the relevant information in the frontend and pass it to the backend 3. promote a discussion with the MAP-LIB and MAP-LANG projects to standardize the solution Regarding point 1, I have some loosely formulated requirements, but they need to be formalized into actual rules for the compiler - type defaults have the lowest priority, they should only be used if there are no other start value specification overriding them - start values set by modifications when instantiating components should have higher priority than start values set by default binding equations in component declarations - the priority of start values given by parameters should be determined on the basis of where the actual parameter value is specified - direct specifications of the start value from the top level of the model to be simulated via nested modifiers should have the precedence over the other start values specified insied the lower-level components - even in case the parameters are evaluated, the priority information should be computed by the frontend (particularly when evaluating parameters!) and then passed along to the backend, in order to be able to make the correct choices when performing alias elimination Any ideas/comments?" Francesco Casella 5814 for loop in algorithm section gets wrong values Code Generation v1.14.1 defect Mahder Alemseged Gebremedhin accepted 2020-01-31T13:35:24Z 2021-09-13T11:58:21Z "The following example is a simple demonstration of the bug. {{{#!modelica connector AgentInPort input Real Temp; input Real MassFlow; end AgentInPort; connector AgentOutPort output Real Temp; output Real MassFlow; end AgentOutPort; model MyAgentAcc parameter Integer nports; AgentInPort[nports] In; AgentOutPort Out; Real sumTemp, sumMassFlow; Real mf[nports], te[nports]; algorithm for i in 1:nports loop te[i] := In[i].Temp; sumTemp := sumTemp + In[i].Temp; mf[i] := In[i].MassFlow; sumMassFlow := sumMassFlow + In[i].MassFlow; end for; equation Out.MassFlow = sumMassFlow; Out.Temp = sumTemp; end MyAgentAcc; model Tester MyAgentAcc TestAcc(nports=2); AgentOutPort VL1, VL2; equation VL1.Temp = 14; VL1.MassFlow = 1; VL2.Temp = 28; VL2.MassFlow = 2; connect(VL1, TestAcc.In[1]); connect(VL2, TestAcc.In[2]); end Tester; }}} The expected output is: TestAcc.Out.MassFlow = 3 TestAcc.Out.Temp = 42 TestAcc.mf[1] = 1 TestAcc.mf[2] = 2 TestAcc.te[1] = 14 TestAcc.te[2] = 28 But the output is: TestAcc.Out.MassFlow = 15 TestAcc.Out.Temp = 16 TestAcc.mf[1] = 1 TestAcc.mf[2] = 14 TestAcc.te[1] = 14 TestAcc.te[2] = 2 In the for loop i=1 is working as expected, but with i=2 we get wrong values! " r8KZbITHbJBHykci96Mg@… 5823 Verification of FMI models has interpolation issues FMI defect Lennart Ochel new 2020-02-03T14:44:16Z 2021-09-13T11:58:21Z "As Lennart pointed out in the Annual Workshop, the reported verification performance of FMI on MSL 3.2.3 is abysmal: the [https://libraries.openmodelica.org/branches/master-fmi/Modelica_3.2.3/Modelica_3.2.3.html verification success ratio] is currently 68/424. I checked some of the results. In many cases they are just plain wrong, see, e.g., [https://libraries.openmodelica.org/branches/master-fmi/Modelica_3.2.3/files/Modelica_3.2.3_Modelica.Electrical.PowerConverters.Examples.DCDC.HBridge.HBridge_RL.diff.inductor.i.html this one]. However, in some cases I understand this mismatch is just an artifact. Consider for example [https://libraries.openmodelica.org/branches/master-fmi/Modelica_3.2.3/files/Modelica_3.2.3_Modelica.Mechanics.MultiBody.Examples.Elementary.PendulumWithSpringDamper.diff.prismatic.s.html this report]. The FMI output is piecewise linear; the corners are fitting exactly with the reference results, but of course errors in-between those points can be quite large. I guess the problem here is just that the FMI is not correctly interpolating the results on the same grid as the reference results, or maybe just some problem with how the CSV compare is working with the FMI simulation results." Francesco Casella 5902 "Icon view ""Bring to front"" not working" OMEdit v1.14.1 defect Adeel Asghar new 2020-04-01T19:01:11Z 2021-09-13T11:58:21Z "In Icon view, ""Bring to front"", ""Bring to back"", etc. are disabled. Trying with standard shapes and text. For an Icon with filled colored Square, I cannot get the model name (%name) on top if I create the text object first." Magnus Eek 5918 Size of Cpp FMU increased by more than 300% with OMSI Cpp Run-time v1.16.0-dev defect Niklas Worschech assigned 2020-04-15T14:37:07Z 2021-09-13T11:58:21Z "The size of Cpp FMUs increased tremendously with OMSI. For instance the model dll of a simple integrator with one input, one state and one output grew by 7MB. Please remove unnecessary link dependencies! Take this example: {{{#!mo setCommandLineOptions(""+simCodeTarget=Cpp""); setCommandLineOptions(""-d=newInst""); translateModelFMU(Modelica.Blocks.Continuous.Integrator, version=""2.0""); }}} The size of a win32 FMU grew from 693KB to 2239KB. The size of the extracted binaries/win32/Modelica_Blocks_Continuous_Integrator.dll grew from 2780KB to 9938KB!" Rüdiger Franke 5919 Error of Microsoft Visual C++ Runtime Library OMEdit v1.14.1 defect Adeel Asghar new 2020-04-20T11:30:01Z 2021-09-13T11:58:21Z "Hi, I have recently installed the latest version of OpenModelica (32bit) on my Win7-based laptop. Once I start to do modeling, OMEdit crashes with appearing this error message:""This application has requested the Runtime to terminate in an unusual way. Please contact the application's support team for more information"". Even I realized that I cannot save any class file. Any solution to resolve this problem would be highly appreciated. Thank you. " butresearch@… 5971 TLM pendulum example error OMSimulator defect Lennart Ochel new 2020-05-22T11:49:30Z 2021-09-13T11:58:21Z "When executing the pendulum example as in ''https://www.openmodelica.org/doc/OpenModelicaUsersGuide/v1.11.0-dev.beta2/tlmcosimulation.html'' I get the following scripting and simulation errors (attachments). I also load the OM_TLM library. How should I run it to be able to simulate? Thank you." lluc@… 5975 Numerical problems with initialization of thermofluid model in BuildingSystems Run-time v1.14.1 defect Lennart Ochel new 2020-05-23T17:05:26Z 2021-09-13T11:58:21Z "Hi, I'm new to OM. So I hope, that this issue can be solve by more experienced people... I want to simulate a thermal building under weather conditions. For this i mostly use Blocks from the BuildingSystems library. I just cant get the following code working. I'm German, so there are some German expression in the comments or the name-declarations. {{{ model Wohncontainer ""Wohncontainer in Putlos"" extends Modelica.Icons.Example; parameter Integer nSurfaces = 8; parameter Modelica.SIunits.Position Laenge = 5.758; parameter Modelica.SIunits.Position Breite = 2.174; parameter Modelica.SIunits.Position Hoehe = 2.290; parameter Real C_max(final unit=""l/m3"")=1; parameter Real C_Zuluft(final unit=""l/m3"")=0.35; parameter Real C_CO2Atmen(final unit=""1"")=0.04; parameter Real Vdot_Atmen(final unit=""l/h"")=240; Real nNutzer; Real Luftwechsel(final unit=""1/h""); Real CO2AustossNutzer; record wand extends BuildingSystems.Buildings.Data.Constructions.OpaqueThermalConstruction(nLayers=3, thickness={0.012,0.284,0.004}, material={Sperrholz(), Isolierung(), Stahl()}); end wand; record boden extends BuildingSystems.Buildings.Data.Constructions.OpaqueThermalConstruction(nLayers=4, thickness={0.002,0.018,0.278,0.004}, material={PVCBelag(), Sperrholz(), Isolierung(), Stahl()}); end boden; record fenster extends BuildingSystems.Buildings.Data.Constructions.TransparentConstruction(nPanes=2, thickness={0.003,0.003}, UValGla = 1.0, UValFra = 1.5, g = 0.52, b0 = 0.7); end fenster; record Isolierung extends BuildingSystems.HAM.Data.MaterialProperties.BaseClasses.MaterialThermalGeneral ( id=11, name=""Isolierung"", lambda=0.03, c=1400, rho=35); end Isolierung; record PVCBelag extends BuildingSystems.HAM.Data.MaterialProperties.BaseClasses.MaterialThermalGeneral ( id=13, name=""PVCBelag"", lambda=0.15, c=850, rho=138); end PVCBelag; record Sperrholz extends BuildingSystems.HAM.Data.MaterialProperties.BaseClasses.MaterialThermalGeneral ( id=12, name=""Sperrholz"", lambda=0.17, c=2100, rho=720); end Sperrholz; record Stahl extends BuildingSystems.HAM.Data.MaterialProperties.BaseClasses.MaterialThermalGeneral ( id=10, name=""Stahl"", lambda=50, c=490, rho=7900); end Stahl; BuildingSystems.Buildings.Constructions.Doors.Door door( redeclare wand constructionData, angleDegAzi=180.0, angleDegTil=90.0, calcAirchange = false,height=2.0, width=0.9) annotation( Placement(visible = true, transformation(origin = { -54, -88}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); BuildingSystems.Buildings.Constructions.Walls.WallThermal1DNodes wall3(height=Hoehe, width=Breite, angleDegAzi=180.0, angleDegTil=90.0, redeclare wand constructionData, AInnSur=door.width*door.height) annotation( Placement(visible = true, transformation(origin = {-30, -44}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); BuildingSystems.Buildings.Constructions.Walls.WallThermal1DNodes wall4(height=Hoehe, width=Laenge, angleDegAzi=-90.0, angleDegTil=90.0, redeclare wand constructionData) annotation( Placement(visible = true, transformation(origin = {-30, -70}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); BuildingSystems.Buildings.Constructions.Walls.WallThermal1DNodes ceiling(height=Laenge, width=Breite, angleDegAzi=0.0, angleDegTil=180.0, redeclare wand constructionData) annotation( Placement(visible = true, transformation(origin = {-30, 32}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); BuildingSystems.Buildings.Constructions.Walls.WallThermal1DNodes bottom(height=Laenge, width=Breite, angleDegAzi=0.0, angleDegTil=0.0, redeclare boden constructionData) annotation( Placement(visible = true, transformation(origin = {-30, 56}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); BuildingSystems.Buildings.Constructions.Windows.Window window( redeclare fenster constructionData,angleDegAzi=0.0, angleDegTil=90.0, calcAirchange = false,height=1.2, width=0.9) annotation( Placement(visible = true, transformation(origin = {-48, -4}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); BuildingSystems.Buildings.Constructions.Walls.WallThermal1DNodes wall1(height=Hoehe, width=Breite, angleDegAzi=0.0, angleDegTil=90.0, redeclare wand constructionData, AInnSur=window.width*window.height) annotation( Placement(visible = true, transformation(origin = {-30, 8}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); BuildingSystems.Buildings.Constructions.Walls.WallThermal1DNodes wall2(height=Hoehe, width=Laenge, angleDegAzi=90.0, angleDegTil=90.0, redeclare wand constructionData) annotation( Placement(visible = true, transformation(origin = {-30, -20}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); BuildingSystems.Buildings.Ambience ambience(redeclare block WeatherData = BuildingSystems.Climate.WeatherDataMeteonorm.Germany_Berlin_Meteonorm_ASCII, nSurfaces = nSurfaces) annotation( Placement(visible = true, transformation(origin = {-102, -4}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); BuildingSystems.Buildings.Zones.ZoneTemplateAirvolumeMixed zone( Q_flow_coolingMax = -2000, Q_flow_heatingMax = 2000,T_start = 293.15,V=Laenge*Breite*Hoehe, airchange = Luftwechsel, calcIdealLoads=true, heatSources = true, height = Hoehe, heightAirpath = {0.5, 1.7, 0.0, 2.0}, moistureSources = true, nAirpaths = 4, nConstructions = 8, nMoistureSources = 0, prescribedAirchange = false, x_start = 0.005) annotation( Placement(visible = true, transformation(origin = {28, -4}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Blocks.Sources.Constant TSetHeating(k = 293.15) annotation( Placement(visible = true, transformation(origin = {4, 16}, extent = {{-3, -3}, {3, 3}}, rotation = 0))); Modelica.Blocks.Sources.Constant TSetCooling(k = 297.15) annotation( Placement(visible = true, transformation(origin = {4, 6}, extent = {{-3, -3}, {3, 3}}, rotation = 0))); BuildingSystems.Buildings.Surfaces.SurfaceToAir surfaceToAirWall1(T(fixed = true)) annotation( Placement(visible = true, transformation(origin = {-38, 8}, extent = {{10, -10}, {-10, 10}}, rotation = 0))); BuildingSystems.Buildings.Surfaces.SurfaceToAir surfaceToAirWall2(T(fixed = true)) annotation( Placement(visible = true, transformation(origin = {-38, -20}, extent = {{10, -10}, {-10, 10}}, rotation = 0))); BuildingSystems.Buildings.Surfaces.SurfaceToAir surfaceToAirWall3(T(fixed = true)) annotation( Placement(visible = true, transformation(origin = {-38, -44}, extent = {{10, -10}, {-10, 10}}, rotation = 0))); BuildingSystems.Buildings.Surfaces.SurfaceToAir surfaceToAirWall4(T(fixed = true)) annotation( Placement(visible = true, transformation(origin = {-38, -70}, extent = {{10, -10}, {-10, 10}}, rotation = 0))); BuildingSystems.Buildings.Surfaces.SurfaceToAir surfaceToAirCeiling(T(fixed = true)) annotation( Placement(visible = true, transformation(origin = {-38, 32}, extent = {{10, -10}, {-10, 10}}, rotation = 0))); BuildingSystems.Buildings.Surfaces.SurfaceToAir surfaceToAirWindow(T(fixed = true)) annotation( Placement(visible = true, transformation(origin = {-70, -4}, extent = {{10, -10}, {-10, 10}}, rotation = 0))); BuildingSystems.Buildings.Surfaces.SurfaceToAir surfaceToAirDoor(T(fixed = true)) annotation( Placement(visible = true, transformation(origin = {-74, -88}, extent = {{10, -10}, {-10, 10}}, rotation = 0))); BuildingSystems.Buildings.Surfaces.SurfaceToAir surfaceToAirBottom(T(fixed = true)) annotation( Placement(visible = true, transformation(origin = {-40, 56}, extent = {{10, -10}, {-10, 10}}, rotation = 0))); equation nNutzer = Modelica.Math.Special.erfc((time - 25200)/2000) + 1000 * Modelica.Math.Distributions.Normal.density(time, mu=43200, sigma=1000) + Modelica.Math.Special.erf((time - 61200)/2000) + 1; //random number generator einfuegen * Modelica.Math.Random.Generators.Xorshift64star.random(Modelica.Math.Random.Generators.Xorshift64star.initialState( 614657, 30020)) CO2AustossNutzer = C_CO2Atmen * Vdot_Atmen * nNutzer; Luftwechsel = CO2AustossNutzer / ((C_max - C_Zuluft) * Laenge * Breite * Hoehe); connect(bottom.toSurfacePort_2, zone.toConstructionPorts[8]) annotation( Line(points = {{-28, 56}, {28, 56}, {28, -4}})); connect(ceiling.toSurfacePort_2, zone.toConstructionPorts[1]) annotation( Line(points = {{-28, 32}, {-9, 32}, {-9, -4}, {28, -4}})); connect(wall1.toSurfacePort_2, zone.toConstructionPorts[2]) annotation( Line(points = {{-28, 8}, {-9, 8}, {-9, -4}, {28, -4}})); connect(wall2.toSurfacePort_2, zone.toConstructionPorts[4]) annotation( Line(points = {{-28, -20}, {-9, -20}, {-9, -4}, {28, -4}})); connect(wall3.toSurfacePort_2, zone.toConstructionPorts[5]) annotation( Line(points = {{-28, -44}, {-9, -44}, {-9, -4}, {28, -4}})); connect(wall4.toSurfacePort_2, zone.toConstructionPorts[7]) annotation( Line(points = {{-28, -70}, {28, -70}, {28, -4}})); connect(window.toSurfacePort_2, zone.toConstructionPorts[3]) annotation( Line(points = {{-46, -4}, {28, -4}})); connect(door.toSurfacePort_2, zone.toConstructionPorts[6]) annotation( Line(points = {{-52, -88}, {28, -88}, {28, -4}})); connect(TSetHeating.y, zone.T_setHeating) annotation( Line(points = {{7, 16}, {11.5, 16}, {11.5, 3}, {17, 3}}, color = {0, 0, 127})); connect(TSetCooling.y, zone.T_setCooling) annotation( Line(points = {{7, 6}, {9.5, 6}, {9.5, 1}, {17, 1}}, color = {0, 0, 127})); connect(ambience.TAirRef, zone.TAirAmb) annotation( Line(points = {{-110, 4}, {-126, 4}, {-126, -32}, {0, -32}, {0, -10}, {18, -10}, {18, -8}}, color = {0, 0, 127})); connect(ambience.xAir, zone.xAirAmb) annotation( Line(points = {{-110, 2}, {-124, 2}, {-124, -34}, {2, -34}, {2, -12}, {18, -12}, {18, -10}}, color = {0, 0, 127})); connect(surfaceToAirWall1.toConstructionPort, wall1.toSurfacePort_1) annotation( Line(points = {{-38, 8}, {-32, 8}, {-32, 8}, {-32, 8}})); connect(surfaceToAirWall2.toConstructionPort, wall2.toSurfacePort_1) annotation( Line(points = {{-38, -20}, {-32, -20}, {-32, -20}, {-32, -20}})); connect(surfaceToAirWall3.toConstructionPort, wall3.toSurfacePort_1) annotation( Line(points = {{-38, -44}, {-32, -44}, {-32, -44}, {-32, -44}})); connect(surfaceToAirWall4.toConstructionPort, wall4.toSurfacePort_1) annotation( Line(points = {{-38, -70}, {-32, -70}, {-32, -70}, {-32, -70}})); connect(surfaceToAirCeiling.toConstructionPort, ceiling.toSurfacePort_1) annotation( Line(points = {{-38, 32}, {-32, 32}, {-32, 32}, {-32, 32}})); connect(surfaceToAirWindow.toConstructionPort, window.toSurfacePort_1) annotation( Line(points = {{-69, -4}, {-50, -4}})); connect(surfaceToAirDoor.toConstructionPort, door.toSurfacePort_1) annotation( Line(points = {{-73, -88}, {-56, -88}})); connect(ambience.toSurfacePorts[1], surfaceToAirCeiling.toSurfacesPort) annotation( Line(points = {{-92, 0}, {-88, 0}, {-88, 36}, {-38, 36}, {-38, 36}})); connect(ambience.toSurfacePorts[2], surfaceToAirWall1.toSurfacesPort) annotation( Line(points = {{-92, 0}, {-88, 0}, {-88, 12}, {-38, 12}, {-38, 12}})); connect(ambience.toSurfacePorts[3], surfaceToAirWindow.toSurfacesPort) annotation( Line(points = {{-92, 0}, {-71, 0}})); connect(ambience.toSurfacePorts[4], surfaceToAirWall2.toSurfacesPort) annotation( Line(points = {{-92, 0}, {-88, 0}, {-88, -16}, {-38, -16}, {-38, -16}})); connect(ambience.toSurfacePorts[5], surfaceToAirWall3.toSurfacesPort) annotation( Line(points = {{-92, 0}, {-88, 0}, {-88, -40}, {-38, -40}, {-38, -40}})); connect(ambience.toSurfacePorts[6], surfaceToAirDoor.toSurfacesPort) annotation( Line(points = {{-92, 0}, {-88, 0}, {-88, -84}, {-75, -84}})); connect(ambience.toSurfacePorts[7], surfaceToAirWall4.toSurfacesPort) annotation( Line(points = {{-92, 0}, {-88, 0}, {-88, -66}, {-38, -66}, {-38, -66}})); connect(ambience.toAirPorts[1], surfaceToAirCeiling.toAirPort) annotation( Line(points = {{-92, -8}, {-84, -8}, {-84, 28}, {-38, 28}, {-38, 28}})); connect(ambience.toAirPorts[2], surfaceToAirWall1.toAirPort) annotation( Line(points = {{-92, -8}, {-84, -8}, {-84, 4}, {-38, 4}, {-38, 4}})); connect(ambience.toAirPorts[3], surfaceToAirWindow.toAirPort) annotation( Line(points = {{-92, -8}, {-71, -8}})); connect(ambience.toAirPorts[4], surfaceToAirWall2.toAirPort) annotation( Line(points = {{-92, -8}, {-84, -8}, {-84, -24}, {-38, -24}, {-38, -24}})); connect(ambience.toAirPorts[6], surfaceToAirDoor.toAirPort) annotation( Line(points = {{-92, -8}, {-84, -8}, {-84, -92}, {-75, -92}})); connect(ambience.toAirPorts[7], surfaceToAirWall4.toAirPort) annotation( Line(points = {{-92, -8}, {-84, -8}, {-84, -74}, {-38, -74}, {-38, -74}})); connect(surfaceToAirBottom.toConstructionPort, bottom.toSurfacePort_1) annotation( Line(points = {{-38, 56}, {-32, 56}, {-32, 56}, {-32, 56}})); connect(ambience.toSurfacePorts[8], surfaceToAirBottom.toSurfacesPort) annotation( Line(points = {{-92, 0}, {-88, 0}, {-88, 60}, {-38, 60}, {-38, 60}})); connect(ambience.toAirPorts[8], surfaceToAirBottom.toAirPort) annotation( Line(points = {{-92, -8}, {-84, -8}, {-84, 52}, {-38, 52}, {-38, 52}})); connect(ambience.toAirPorts[5], surfaceToAirWall3.toAirPort) annotation( Line(points = {{-92, -8}, {-84, -8}, {-84, -48}, {-38, -48}, {-38, -48}})); //31536000s = 1 Jahr, 86400s = 1 Tag connect(door.port_b1, zone.airpathPorts[1]) annotation( Line(points = {{-52, -82}, {-2, -82}, {-2, 26}, {18, 26}, {18, 8}, {22, 8}}, color = {0, 127, 255})); connect(window.port_b1, zone.airpathPorts[2]) annotation( Line(points = {{-46, 2}, {-42, 2}, {-42, -2}, {-6, -2}, {-6, 30}, {22, 30}, {22, 8}}, color = {0, 127, 255})); connect(window.port_a2, zone.airpathPorts[3]) annotation( Line(points = {{-46, -10}, {-42, -10}, {-42, -6}, {-4, -6}, {-4, 28}, {20, 28}, {20, 8}, {22, 8}}, color = {0, 127, 255})); connect(door.port_a2, zone.airpathPorts[4]) annotation( Line(points = {{-52, -94}, {-8, -94}, {-8, 32}, {24, 32}, {24, 8}, {22, 8}}, color = {0, 127, 255})); connect(ambience.toAirpathPorts[1], door.port_a1) annotation( Line(points = {{-96, 6}, {-56, 6}, {-56, -82}, {-56, -82}}, color = {0, 127, 255})); connect(ambience.toAirpathPorts[2], door.port_b2) annotation( Line(points = {{-96, 6}, {-64, 6}, {-64, -94}, {-56, -94}, {-56, -94}}, color = {0, 127, 255})); connect(ambience.toAirpathPorts[3], window.port_a1) annotation( Line(points = {{-96, 6}, {-54, 6}, {-54, 2}, {-50, 2}, {-50, 2}}, color = {0, 127, 255})); connect(ambience.toAirpathPorts[4], window.port_b2) annotation( Line(points = {{-96, 6}, {-54, 6}, {-54, -10}, {-50, -10}, {-50, -10}}, color = {0, 127, 255})); annotation(experiment(StartTime=0, StopTime=86400), uses(BuildingSystems(version = ""2.0.0-beta""), Modelica(version = ""3.2.3""))); end Wohncontainer; }}} Currently I am getting the following Error, when trying to simulate: {{{ ... loading ""tab1"" from ""F:\OpenModelica\lib\omlibrary\BuildingSystems 2.0.0-beta\Climate\weather\Germany_Berlin.txt"" Wohncontainer_functions.c:196: Invalid root: (-4.409e-016)^(0.4) simulation terminated by an assertion at initialization Simulation process failed. Exited with code -1. }}} When I simulate in Debug-mode, it outputs the following: {{{ stdout | info | ... loading ""tab1"" from ""F:\OpenModelica\lib\omlibrary\BuildingSystems 2.0.0-beta\Climate\weather\Germany_Berlin.txt"" assert | debug | F:/OpenModelica/lib/omlibrary/BuildingSystems 2.0.0-beta/Buildings/Functions/vWind.mo:16: Invalid root: (-4.409e-016)^(0.4) assert | info | simulation terminated by an assertion at initialization You can't do that without a process to debug. }}} I hope that someone can help me with this. " hendrikjob98@… 6000 "Expected ""XXX"" to be a class, but found component instead." OMEdit v.1.15.0-dev defect Adeel Asghar assigned 2020-06-07T13:05:38Z 2021-09-13T11:58:21Z "I keep coming across an error of a form ""Expected 'XXX' to be a class, but found component instead."" when I try to insert a model into another model and I can't work out what is causing it. It seems to happen sporadically and I can't really work out what is causing it. Most recently I was working on the attached ""frame_model_pack"" This contains ""frame_model"" which references two other models ""keel"" and ""control_frame"". This was working fine, then I made some minor adjustments to ""control_frame"" (changing the icon and tweaking some initial conditions) and now I get this error: {{{ [1] 13:52:42 Translation Error [frame_model_pack: 16:3-17:117]: Expected control_frame to be a class, but found component instead. }}} Unfortunately I saved the model and re-opened OMEdit so I can't simply undo back to the working state! I simply don't understand why it went from working to not working like this. If I reference ""control_frame"" in another model outside of ""frame_model_pack"" then it does still work. Also 'keel' is inside ""frame_model_pack"" and that has no problem being referenced by ""frame_model"", so it's not that you can't reference a model from within the same package (and as I say, this was working until I made some minor tweaks to control_frame)." timswait@… 6019 previous(y) is chattering in a discrete-time model Run-time v1.16.0-dev defect Lennart Ochel new 2020-06-18T10:01:40Z 2021-09-13T11:58:21Z "Hi, I built a small wrapping counter with time-discrete blocks. When simulating in openmodelica, One of the available outputs is previous(y). As you see in the attached screenshot, the variable behaves very strange, quite different from y itself. Additionally I'm confused by the fact that variables i and y are calculated ''between'' sampling ticks. This is not how I understand how it was intended (https://ep.liu.se/ecp/076/001/ecp12076001.pdf) Best regards, Paul van der Hulst" p.van.der.hulst@… 6038 Mac OMEdit fails to build Build Environment defect Martin Sjölund new 2020-06-29T18:42:29Z 2021-09-13T11:58:21Z "I have openmodelica-devel installed through Macports: 1.16.0~dev-443-g5ab5bb3_0. I have not been able to get any of the recent updates to build successfully. The most recent log is attached. " Adam Dershowitz 6057 impeuler poor performance and Restart Kinsol: change linear solver to KINDense. Run-time v1.16.0-dev defect Andreas Heuermann new 2020-07-16T12:17:46Z 2021-09-13T11:58:21Z "Selecting impeuler as solve produces the following message at every step: Restart Kinsol: change linear solver to KINDense. In addition for large models, performance is degraded. The problem seems to be related to all implicit fixed step solvers, such as imprugekutta." federico.terraneo@… 6155 Z-axis not working in OMEdit OMEdit v1.16.0-dev defect Adeel Asghar new 2020-10-10T03:53:20Z 2021-09-13T11:58:21Z "In OMEdit context menu items ""Bring to Front"", ""Bring Forward"", ""Send to Back""; ""Send Forward"" are greyed and cannot be used neither in icon nor in diagram view. Tested with dev-648 I propose critical priority, since the functionality must be there, probably it is just disabled for some reason and is easy to re-activate by 1.16 release date. EDIT 12 October: I don't know whether if this is a regression. If it is it is not a recent one: the issue was there also in 1.14.1." massimo ceraolo 6166 Fluid/Examples/PumpingSystem can't be simulated Backend v1.16.0-dev defect Andreas Heuermann assigned 2020-10-25T13:01:56Z 2021-09-13T11:58:21Z "When trying to run /Fluid/Examples/PumpingSystem.mo in OpenModelica v1.16.0-dev.beta1 (64-bit). I get errors and can’t start the simulation. It's the same for latest v1.16.0. Forum post about the same issue: https://www.openmodelica.org/forum/default-topic/3118-fluid-examples-pumpingsystem-can-t-be-simulated I can be contacted there is for information is requierd {{{ [1] 14:48:00 Symbolic Warning The model contains alias variables with redundant start and/or conflicting nominal values. It is recommended to resolve the conflicts, because otherwise the system could be hard to solve. To print the conflicting alias sets and the chosen candidates please use -d=aliasConflicts. [2] 14:48:00 Translation Error Internal error IndexReduction.pantelidesIndexReduction failed! System is structurally singular and cannot be handled because the number of unassigned equations is larger than the number of states. Use -d=bltdump to get more information. [3] 14:48:00 Translation Error post-optimization module replaceHomotopyWithSimplified (initialization) failed. [4] 14:48:00 Translation Error No system for the symbolic initialization was generated }}} " victor 6249 Inconsistent behaviour when opening a new class from a tab with syntactically wrong code OMEdit 1.16.0 defect Adeel Asghar new 2020-11-26T17:21:46Z 2021-09-13T11:58:21Z "Steps to reproduce - open attached {{{P.mo}}} file - double click on {{{M2}}} - write some invalid code (e.g. Real x) At this point you can actually open {{{M1}}} (which is on the same .mo file) with right-click | Open class. This is fine, provided that #6248 is resolved. However, if you double-click on {{{M1}}} instead, an error dialog pops up that forces you to resolve the issues with the invalid code. This behaviour is unwanted, because one should be allowed to inspect other classes while writing code, and should be made consistent with the right-click behaviour. Related to #6248." Francesco Casella 6254 Backend fails with discrete-time first order model Backend 1.16.0 defect Andreas Heuermann assigned 2020-11-28T17:35:00Z 2021-09-13T11:58:21Z "OpenModelica works with lots of discrete-time models, including also more sophisticated ones than here, see e.g. 4 states with implicit Euler: https://github.com/OpenModelica/OpenModelica-testsuite/blob/master/openmodelica/cppruntime/fmu/modelExchange/2.0/testCSTR.mos However, a simple model with one linear state fails. The below model samples a FirstOrder model. -d=backenddaeinfo says: {{{ [7] 18:26:42 Symbolisch Meldung Torn system details for strict tearing set: * Linear torn systems: 1 {(1,100.0%) 1} * Non-linear torn systems: 0 }}} -d=dumpSimCode shows the following equation system -- without Jacobian and with index: -1 !? {{{ 10: (LINEAR) index:0 jacobian: false variables: index: -1: firstOrder.y (no alias) initial: firstOrder.y_start no arrCref index:() [] b-vector: 8: $DER.firstOrder.y=(firstOrder.k * firstOrder.u - firstOrder.y) / firstOrder.T [Real] 9: interval() * (if firstTick() then 0.0 else $DER.firstOrder.y) + previous(firstOrder.y) - firstOrder.y (RESIDUAL) }}} The C runtime reports ""Failed to solve linear system of equations (no. 10) at time 0.000000, system is singular for U[2, 2]."". The Cpp runtime removes the equation during code generation. {{{#!mo model DiscreteTimeLoop Modelica.Blocks.Continuous.FirstOrder firstOrder(T = 1) annotation( Placement(visible = true, transformation(origin = {18, 10}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica_Synchronous.RealSignals.Sampler.SampleClocked sample1 annotation( Placement(visible = true, transformation(origin = {-24, 10}, extent = {{-6, -6}, {6, 6}}, rotation = 0))); Modelica_Synchronous.ClockSignals.Clocks.PeriodicRealClock periodicClock1(period = 0.1) annotation( Placement(visible = true, transformation(origin = {-54, -44}, extent = {{-6, -6}, {6, 6}}, rotation = 0))); Modelica.Blocks.Interfaces.RealInput u(start = 1) annotation( Placement(visible = true, transformation(origin = {-82, 10}, extent = {{-8, -8}, {8, 8}}, rotation = 0), iconTransformation(origin = {-72, 10}, extent = {{-20, -20}, {20, 20}}, rotation = 0))); equation connect(u, sample1.u) annotation( Line(points = {{-82, 10}, {-32, 10}, {-32, 10}, {-32, 10}}, color = {0, 0, 127})); connect(sample1.y, firstOrder.u) annotation( Line(points = {{-18, 10}, {6, 10}, {6, 10}, {6, 10}}, color = {0, 0, 127})); connect(periodicClock1.y, sample1.clock) annotation( Line(points = {{-48, -44}, {-24, -44}, {-24, 2}, {-24, 2}}, color = {175, 175, 175})); annotation( uses(Modelica(version = ""3.2.3""), Modelica_Synchronous(version = ""0.93.0""))); end DiscreteTimeLoop; }}}" Rüdiger Franke 6269 Creating new Composite model freezes OMEdit (WSL) OMEdit v1.17.0-dev defect Adeel Asghar new 2020-12-04T11:14:44Z 2021-09-13T11:58:21Z "When trying to create a new composit from the drop-down menu with OMEdit nothing happens. How to reproduce: Click `File->New Composite Model` and notice how nothing is happening. See screenshot_1.png. After that I can't do anything in OMedit but don't get a crash report either. When trying to close OMEdit asks me if I want to save changes to the newly created composite models. See screenshot_2.png. I'm running OMEdit with OMCompiler v1.17.0-dev.239+gaa3317f58f and OMSimulator v2.0.0.post268-ga355ad0-linux on Ubuntu 20.04." Andreas Heuermann 6272 installPackage does not work on Windows Installation program v1.17.0-dev defect Adrian Pop new 2020-12-04T16:54:04Z 2021-09-13T11:58:21Z "When trying to install packages with OMEdit - OpenModelica Compiler CLI `installPackage` will fail. How to reproduce: {{{ installPackage(ModelicaReference, ""3.2.3+maint.om"", exactMatch=true) false getErrorString() ""Error: The MODELICAPATH (C:/Program Files/OpenModelica1.17.0-dev-64bit/lib/omlibrary) does not contain C:/Users/Andreas/AppData/Roaming/.openmodelica/libraries/, so the package index cannot be used. [C:/Users/Andreas/AppData/Roaming/.openmodelica/libraries/index.json:0:0-0:0:readonly] Error: The package index did not contain an entry for package ModelicaReference that provides version 3.2.3+maint.om. "" }}} I have the following environment variables: `OPENMODELICAHOME C:\Program Files\OpenModelica1.17.0-dev-64bit\` `OPENMODELICALIBRARY C:\Program Files\OpenModelica1.17.0-dev-64bit\lib\omlibrary` which get set by the installer. When I remove these and restart OMEdit it will work." Andreas Heuermann 6285 Minimal tearing failing for example from MSL Backend v1.17.0-dev defect Andreas Heuermann reopened 2020-12-16T09:42:00Z 2021-09-13T11:58:21Z "When disabling linear tearing for PR https://github.com/OpenModelica/OpenModelica/pull/6969 (related ticket #6196) we have some examples from the testsuite that are failing to simulate. They are working with normal tearing and without tearing, but not with minimal tearing. For example for `Modelica.Electrical.Machines.Examples.AsynchronousInductionMachines.AIMC_Transformer` we can run: {{{ cd(""temp""); loadModel(Modelica,{""3.2.3""}); getErrorString(); setCommandLineOptions(""-d=newInst --tearingMethod=minimalTearing""); getErrorString(); simulate(Modelica.Electrical.Machines.Examples.AsynchronousInductionMachines.AIMC_Transformer); getErrorString(); }}} and see that the linear solver will fail to solve linear system 536 in every time step: {{{ LOG_LS | info | Start solving Linear System 536 (size 28) at time 0.002621 with Lapack Solver LOG_LS | warning | Failed to solve linear system of equations (no. 536) at time 0.002621. Residual norm is 104868561.449326. LOG_LS | warning | The default linear solver fails, the fallback solver with total pivoting is started at time 0.002621. That might raise performance issues, for more information use -lv LOG_LS. LOG_LS | info | Start solving Linear System 536 (size 28) at time 0.002621 with Total Pivot Solver }}} The relevant loop should be {{{ ################################################################################ dumpLoops: SORTED COMPONENT ################################################################################ torn linear Equationsystem: internal vars (0) residual vars (28) 1: transformer.l2sigma.v[2]:VARIABLE(unit = ""V"" ) ""Voltage drops of the two polyphase plugs"" type: Real [3] 2: $DER.transformer.l2sigma.inductor[2].i:DUMMY_DER(fixed = false ) ""Current flowing from pin p to pin n"" type: Real [3] 3: transformer.l1sigma.inductor[2].i:STATE(1)(start = 0.0 unit = ""A"" ) ""Current flowing from pin p to pin n"" type: Real [3] 4: transformer.l1sigma.v[2]:VARIABLE(unit = ""V"" ) ""Voltage drops of the two polyphase plugs"" type: Real [3] 5: transformer.l1sigma.plug_n.pin[2].v:VARIABLE(flow=false unit = ""V"" ) ""Potential at the pin"" type: Real [3] 6: transformer.core.v1[2]:VARIABLE(unit = ""V"" ) type: Real [3] 7: transformer.core.v3[2]:VARIABLE(unit = ""V"" ) type: Real [3] 8: transformer.core.plug_p2.pin[2].v:VARIABLE(flow=false unit = ""V"" ) ""Potential at the pin"" type: Real [3] 9: transformer.core.v2[2]:VARIABLE(unit = ""V"" ) type: Real [3] 10: transformer.l1sigma.inductor[3].i:STATE(1)(start = 0.0 unit = ""A"" ) ""Current flowing from pin p to pin n"" type: Real [3] 11: $DER.transformer.l2sigma.inductor[3].i:DUMMY_DER(fixed = false ) ""Current flowing from pin p to pin n"" type: Real [3] 12: transformer.l2sigma.v[3]:VARIABLE(unit = ""V"" ) ""Voltage drops of the two polyphase plugs"" type: Real [3] 13: transformer.core.plug_p2.pin[3].v:VARIABLE(flow=false unit = ""V"" ) ""Potential at the pin"" type: Real [3] 14: transformer.core.v3[3]:VARIABLE(unit = ""V"" ) type: Real [3] 15: transformer.core.v1[3]:VARIABLE(unit = ""V"" ) type: Real [3] 16: transformer.core.v2[3]:VARIABLE(unit = ""V"" ) type: Real [3] 17: transformer.starpoint1.v:VARIABLE(flow=false unit = ""V"" ) ""Potential at the pin"" type: Real 18: transformer.l1sigma.plug_n.pin[1].v:VARIABLE(flow=false unit = ""V"" ) ""Potential at the pin"" type: Real [3] 19: transformer.l1sigma.v[1]:VARIABLE(unit = ""V"" ) ""Voltage drops of the two polyphase plugs"" type: Real [3] 20: $DER.transformer.l1sigma.inductor[1].i:DUMMY_DER(fixed = false ) ""Current flowing from pin p to pin n"" type: Real [3] 21: $DER.transformer.l2sigma.inductor[1].i:DUMMY_DER(fixed = false ) ""Current flowing from pin p to pin n"" type: Real [3] 22: transformer.l2sigma.v[1]:VARIABLE(unit = ""V"" ) ""Voltage drops of the two polyphase plugs"" type: Real [3] 23: transformer.core.plug_p2.pin[1].v:VARIABLE(flow=false unit = ""V"" ) ""Potential at the pin"" type: Real [3] 24: transformer.core.v3[1]:VARIABLE(unit = ""V"" ) type: Real [3] 25: transformer.core.v1[1]:VARIABLE(unit = ""V"" ) type: Real [3] 26: transformer.core.v2[1]:VARIABLE(unit = ""V"" ) type: Real [3] 27: transformer.l1sigma.v[3]:VARIABLE(unit = ""V"" ) ""Voltage drops of the two polyphase plugs"" type: Real [3] 28: transformer.l1sigma.plug_n.pin[3].v:VARIABLE(flow=false unit = ""V"" ) ""Potential at the pin"" type: Real [3] internal equations (0) residual equations (28) 1/1 (1): transformer.l1sigma.v[3] = transformer.r1.plug_n.pin[3].v - transformer.l1sigma.plug_n.pin[3].v [dynamic |0|0|0|0|] 2/2 (1): transformer.l1sigma.inductor[3].L * der(transformer.l1sigma.inductor[3].i) = transformer.l1sigma.v[3] [dynamic |0|0|0|0|] 3/3 (1): transformer.core.v1[1] = transformer.core.n12 * transformer.core.v2[1] [dynamic |0|0|0|0|] 4/4 (1): transformer.core.v1[1] = transformer.core.n13 * transformer.core.v3[1] [dynamic |0|0|0|0|] 5/5 (1): transformer.core.v2[1] = transformer.core.plug_p2.pin[1].v - transformer.core.v3[1] [dynamic |0|0|0|0|] 6/6 (1): transformer.l2sigma.v[1] = transformer.l2sigma.plug_p.pin[1].v - transformer.core.plug_p2.pin[1].v [dynamic |0|0|0|0|] 7/7 (1): transformer.l2sigma.inductor[1].L * $DER.transformer.l2sigma.inductor[1].i = transformer.l2sigma.v[1] [dynamic |0|0|0|0|] 8/8 (1): 0.0 = $DER.transformer.l1sigma.inductor[1].i + $DER.transformer.l2sigma.inductor[1].i / transformer.core.n12 + $DER.transformer.l2sigma.inductor[1].i / transformer.core.n13 [dynamic |0|0|0|0|] 9/9 (1): transformer.l1sigma.inductor[1].L * $DER.transformer.l1sigma.inductor[1].i = transformer.l1sigma.v[1] [dynamic |0|0|0|0|] 10/10 (1): transformer.l1sigma.v[1] = transformer.r1.plug_n.pin[1].v - transformer.l1sigma.plug_n.pin[1].v [dynamic |0|0|0|0|] 11/11 (1): transformer.core.v1[1] = transformer.l1sigma.plug_n.pin[1].v - transformer.starpoint1.v [dynamic |0|0|0|0|] 12/12 (1): transformer.core.v1[3] = transformer.l1sigma.plug_n.pin[3].v - transformer.starpoint1.v [dynamic |0|0|0|0|] 13/13 (1): transformer.core.v1[3] = transformer.core.n12 * transformer.core.v2[3] [dynamic |0|0|0|0|] 14/14 (1): transformer.core.v1[3] = transformer.core.n13 * transformer.core.v3[3] [dynamic |0|0|0|0|] 15/15 (1): transformer.core.v2[3] = transformer.core.plug_p2.pin[3].v - transformer.core.v3[3] [dynamic |0|0|0|0|] 16/16 (1): transformer.l2sigma.v[3] = transformer.l2sigma.plug_p.pin[3].v - transformer.core.plug_p2.pin[3].v [dynamic |0|0|0|0|] 17/17 (1): transformer.l2sigma.inductor[3].L * $DER.transformer.l2sigma.inductor[3].i = transformer.l2sigma.v[3] [dynamic |0|0|0|0|] 18/18 (1): 0.0 = der(transformer.l1sigma.inductor[3].i) + $DER.transformer.l2sigma.inductor[3].i / transformer.core.n12 + $DER.transformer.l2sigma.inductor[3].i / transformer.core.n13 [dynamic |0|0|0|0|] 19/19 (1): $DER.transformer.l1sigma.inductor[1].i + der(transformer.l1sigma.inductor[2].i) + der(transformer.l1sigma.inductor[3].i) = 0.0 [dynamic |0|0|0|0|] 20/20 (1): transformer.core.v1[2] = transformer.core.n12 * transformer.core.v2[2] [dynamic |0|0|0|0|] 21/21 (1): transformer.core.v2[2] = transformer.core.plug_p2.pin[2].v - transformer.core.v3[2] [dynamic |0|0|0|0|] 22/22 (1): transformer.core.v1[2] = transformer.core.n13 * transformer.core.v3[2] [dynamic |0|0|0|0|] 23/23 (1): transformer.core.v1[2] = transformer.l1sigma.plug_n.pin[2].v - transformer.starpoint1.v [dynamic |0|0|0|0|] 24/24 (1): transformer.l1sigma.v[2] = transformer.r1.plug_n.pin[2].v - transformer.l1sigma.plug_n.pin[2].v [dynamic |0|0|0|0|] 25/25 (1): transformer.l1sigma.inductor[2].L * der(transformer.l1sigma.inductor[2].i) = transformer.l1sigma.v[2] [dynamic |0|0|0|0|] 26/26 (1): 0.0 = der(transformer.l1sigma.inductor[2].i) + $DER.transformer.l2sigma.inductor[2].i / transformer.core.n12 + $DER.transformer.l2sigma.inductor[2].i / transformer.core.n13 [dynamic |0|0|0|0|] 27/27 (1): transformer.l2sigma.inductor[2].L * $DER.transformer.l2sigma.inductor[2].i = transformer.l2sigma.v[2] [dynamic |0|0|0|0|] 28/28 (1): transformer.l2sigma.v[2] = transformer.l2sigma.plug_p.pin[2].v - transformer.core.plug_p2.pin[2].v [dynamic |0|0|0|0|] }}} With tearing enabled this loop will look like {{{ ################################################################################ dumpLoops: SORTED COMPONENT ################################################################################ torn linear Equationsystem: internal vars (25) 1: $DER.transformer.l2sigma.inductor[2].i:DUMMY_DER(fixed = false ) ""Current flowing from pin p to pin n"" type: Real [3] 2: transformer.l2sigma.v[2]:VARIABLE(unit = ""V"" ) ""Voltage drops of the two polyphase plugs"" type: Real [3] 3: transformer.l1sigma.v[2]:VARIABLE(unit = ""V"" ) ""Voltage drops of the two polyphase plugs"" type: Real [3] 4: transformer.core.plug_p2.pin[2].v:VARIABLE(flow=false unit = ""V"" ) ""Potential at the pin"" type: Real [3] 5: transformer.l1sigma.plug_n.pin[2].v:VARIABLE(flow=false unit = ""V"" ) ""Potential at the pin"" type: Real [3] 6: transformer.core.v3[2]:VARIABLE(unit = ""V"" ) type: Real [3] 7: transformer.core.v2[2]:VARIABLE(unit = ""V"" ) type: Real [3] 8: transformer.starpoint1.v:VARIABLE(flow=false unit = ""V"" ) ""Potential at the pin"" type: Real 9: $DER.transformer.l2sigma.inductor[3].i:DUMMY_DER(fixed = false ) ""Current flowing from pin p to pin n"" type: Real [3] 10: transformer.l2sigma.v[3]:VARIABLE(unit = ""V"" ) ""Voltage drops of the two polyphase plugs"" type: Real [3] 11: transformer.l1sigma.v[3]:VARIABLE(unit = ""V"" ) ""Voltage drops of the two polyphase plugs"" type: Real [3] 12: $DER.transformer.l1sigma.inductor[1].i:DUMMY_DER(fixed = false ) ""Current flowing from pin p to pin n"" type: Real [3] 13: $DER.transformer.l2sigma.inductor[1].i:DUMMY_DER(fixed = false ) ""Current flowing from pin p to pin n"" type: Real [3] 14: transformer.l1sigma.v[1]:VARIABLE(unit = ""V"" ) ""Voltage drops of the two polyphase plugs"" type: Real [3] 15: transformer.l2sigma.v[1]:VARIABLE(unit = ""V"" ) ""Voltage drops of the two polyphase plugs"" type: Real [3] 16: transformer.core.plug_p2.pin[3].v:VARIABLE(flow=false unit = ""V"" ) ""Potential at the pin"" type: Real [3] 17: transformer.l1sigma.plug_n.pin[1].v:VARIABLE(flow=false unit = ""V"" ) ""Potential at the pin"" type: Real [3] 18: transformer.core.v1[1]:VARIABLE(unit = ""V"" ) type: Real [3] 19: transformer.core.v3[1]:VARIABLE(unit = ""V"" ) type: Real [3] 20: transformer.core.v2[1]:VARIABLE(unit = ""V"" ) type: Real [3] 21: transformer.core.plug_p2.pin[1].v:VARIABLE(flow=false unit = ""V"" ) ""Potential at the pin"" type: Real [3] 22: transformer.l1sigma.plug_n.pin[3].v:VARIABLE(flow=false unit = ""V"" ) ""Potential at the pin"" type: Real [3] 23: transformer.core.v1[3]:VARIABLE(unit = ""V"" ) type: Real [3] 24: transformer.core.v3[3]:VARIABLE(unit = ""V"" ) type: Real [3] 25: transformer.core.v2[3]:VARIABLE(unit = ""V"" ) type: Real [3] residual vars (3) 1: transformer.l1sigma.inductor[3].i:STATE(1)(start = 0.0 unit = ""A"" ) ""Current flowing from pin p to pin n"" type: Real [3] 2: transformer.core.v1[2]:VARIABLE(unit = ""V"" ) type: Real [3] 3: transformer.l1sigma.inductor[2].i:STATE(1)(start = 0.0 unit = ""A"" ) ""Current flowing from pin p to pin n"" type: Real [3] internal equations (25) 1/1 (1): 0.0 = der(transformer.l1sigma.inductor[2].i) + $DER.transformer.l2sigma.inductor[2].i / transformer.core.n12 + $DER.transformer.l2sigma.inductor[2].i / transformer.core.n13 [dynamic |0|0|0|0|] 2/2 (1): transformer.l2sigma.inductor[2].L * $DER.transformer.l2sigma.inductor[2].i = transformer.l2sigma.v[2] [dynamic |0|0|0|0|] 3/3 (1): transformer.l1sigma.inductor[2].L * der(transformer.l1sigma.inductor[2].i) = transformer.l1sigma.v[2] [dynamic |0|0|0|0|] 4/4 (1): transformer.l2sigma.v[2] = transformer.l2sigma.plug_p.pin[2].v - transformer.core.plug_p2.pin[2].v [dynamic |0|0|0|0|] 5/5 (1): transformer.l1sigma.v[2] = transformer.r1.plug_n.pin[2].v - transformer.l1sigma.plug_n.pin[2].v [dynamic |0|0|0|0|] 6/6 (1): transformer.core.v1[2] = transformer.core.n13 * transformer.core.v3[2] [dynamic |0|0|0|0|] 7/7 (1): transformer.core.v1[2] = transformer.core.n12 * transformer.core.v2[2] [dynamic |0|0|0|0|] 8/8 (1): transformer.core.v1[2] = transformer.l1sigma.plug_n.pin[2].v - transformer.starpoint1.v [dynamic |0|0|0|0|] 9/9 (1): 0.0 = der(transformer.l1sigma.inductor[3].i) + $DER.transformer.l2sigma.inductor[3].i / transformer.core.n12 + $DER.transformer.l2sigma.inductor[3].i / transformer.core.n13 [dynamic |0|0|0|0|] 10/10 (1): transformer.l2sigma.inductor[3].L * $DER.transformer.l2sigma.inductor[3].i = transformer.l2sigma.v[3] [dynamic |0|0|0|0|] 11/11 (1): transformer.l1sigma.inductor[3].L * der(transformer.l1sigma.inductor[3].i) = transformer.l1sigma.v[3] [dynamic |0|0|0|0|] 12/12 (1): $DER.transformer.l1sigma.inductor[1].i + der(transformer.l1sigma.inductor[2].i) + der(transformer.l1sigma.inductor[3].i) = 0.0 [dynamic |0|0|0|0|] 13/13 (1): 0.0 = $DER.transformer.l1sigma.inductor[1].i + $DER.transformer.l2sigma.inductor[1].i / transformer.core.n12 + $DER.transformer.l2sigma.inductor[1].i / transformer.core.n13 [dynamic |0|0|0|0|] 14/14 (1): transformer.l1sigma.inductor[1].L * $DER.transformer.l1sigma.inductor[1].i = transformer.l1sigma.v[1] [dynamic |0|0|0|0|] 15/15 (1): transformer.l2sigma.inductor[1].L * $DER.transformer.l2sigma.inductor[1].i = transformer.l2sigma.v[1] [dynamic |0|0|0|0|] 16/16 (1): transformer.l2sigma.v[3] = transformer.l2sigma.plug_p.pin[3].v - transformer.core.plug_p2.pin[3].v [dynamic |0|0|0|0|] 17/17 (1): transformer.l1sigma.v[1] = transformer.r1.plug_n.pin[1].v - transformer.l1sigma.plug_n.pin[1].v [dynamic |0|0|0|0|] 18/18 (1): transformer.core.v1[1] = transformer.l1sigma.plug_n.pin[1].v - transformer.starpoint1.v [dynamic |0|0|0|0|] 19/19 (1): transformer.core.v1[1] = transformer.core.n13 * transformer.core.v3[1] [dynamic |0|0|0|0|] 20/20 (1): transformer.core.v1[1] = transformer.core.n12 * transformer.core.v2[1] [dynamic |0|0|0|0|] 21/21 (1): transformer.core.v2[1] = transformer.core.plug_p2.pin[1].v - transformer.core.v3[1] [dynamic |0|0|0|0|] 22/22 (1): transformer.l1sigma.v[3] = transformer.r1.plug_n.pin[3].v - transformer.l1sigma.plug_n.pin[3].v [dynamic |0|0|0|0|] 23/23 (1): transformer.core.v1[3] = transformer.l1sigma.plug_n.pin[3].v - transformer.starpoint1.v [dynamic |0|0|0|0|] 24/24 (1): transformer.core.v1[3] = transformer.core.n13 * transformer.core.v3[3] [dynamic |0|0|0|0|] 25/25 (1): transformer.core.v1[3] = transformer.core.n12 * transformer.core.v2[3] [dynamic |0|0|0|0|] residual equations (3) 1/1 (1): transformer.l2sigma.v[1] = transformer.l2sigma.plug_p.pin[1].v - transformer.core.plug_p2.pin[1].v [dynamic |0|0|0|0|] 2/2 (1): transformer.core.v2[3] = transformer.core.plug_p2.pin[3].v - transformer.core.v3[3] [dynamic |0|0|0|0|] 3/3 (1): transformer.core.v2[2] = transformer.core.plug_p2.pin[2].v - transformer.core.v3[2] [dynamic |0|0|0|0|] }}}" Andreas Heuermann 6315 Issue with initial equation generation in Physiolibrary Backend v1.17.0-dev defect Karim Adbdelhak new 2020-12-30T12:46:08Z 2021-09-13T11:58:21Z "Please check [https://libraries.openmodelica.org/branches/master/Physiolibrary/files/Physiolibrary_Physiolibrary.Fluid.Examples.MinimalRespiration.err Physiolibrary.Fluid.Examples.MinimalRespiration]. The backend fails with {{{ Error: No system for the symbolic initialization was generated }}} Why is this error generated?" Francesco Casella 6351 Severe memory management issue in Ubuntu Backend 1.16.0 defect Martin Sjölund reopened 2021-01-26T12:34:00Z 2021-09-13T11:58:21Z "Please consider the attached test case, which handles a 116.000 equations model of a power grid. The model is large, but definitely not huge, and it should be handled by the current OMC. When running the Test_N_6_M_4.mos script under Linux Ubuntu 18.04 LTS, the code generation process aborts with the following error message: {{{ mmap(PROT_NONE) failed Aborted (core dumped) }}} Note that the same model is run successfully under Windows 10. By adding {{{ setCommandLineOptions(""-d=exectstat,optdaedump"");getErrorString(); }}} to the script before the {{{simulate()}}} command, I got some more intel about what goes wrong. The log file reports {{{ pre-optimization done. ... Index reduction done. ######################################## created initial system ######################################## ... BackendDAEType: initialization Known variables only depending on parameters and constants - globalKnownVars (75826) ... ######################################## partitioned initial system ######################################## ... BackendDAEType: initialization Known variables only depending on parameters and constants - globalKnownVars (75826) }}} the crash happens at the end of the list of known variables. Unfortunately the buffer is not flushed when the crash takes place, so I can't see the last lines, but I guess the crash takes place during the {{{analyzeInitialSystem}}} phase. Currently this issue prevents me to test models above 50.000 equations. This is too bad, considering that four years ago we tested systems with 750.000 equations and almost 1.000.000 initial equations. Please investigate." Francesco Casella 6373 Electrical Quasistationary MutualInductor in standard library not working in OM New Instantiation 1.16.2 defect Per Östlund assigned 2021-02-10T08:14:40Z 2021-09-13T11:58:21Z "The component Electrical.Quasistationary.MultiPhase.Basic.MutualInductor from the standard library does not work in OpenModelica. The problem can be reproduced simply by opening the component in OMEdit and running a check, which gives [1] Translation Error [Modelica.Electrical.QuasiStationary.MultiPhase: 1337:9-1337:54]: Expected a reduction function with type signature ('A,'B) => 'B, but got .sum() => #NORETCALL#. The issue seems to be that the sum function does not work for complex arrays. (It works in Dymola.) " anonymous 6441 "User Guide: Chapter ""7.1.2 FMI Import"" defective" Documentation v1.17.0-dev defect Martin Sjölund new 2021-03-31T10:41:50Z 2021-09-13T11:58:21Z "chapter ""7.1.2 FMI Import"" is defective, it does not ""build"" correctly as indicated by the error message: ""Traceback (most recent call last): File ""/var/lib/jenkins/ws/OpenModelica_maintenance_v1.17/doc/UsersGuide/source/sphinxcontribopenmodelica"" " ralph.paul@… 4362 Always check how new methods scale with the problem size Backend discussion Lennart Ochel new 2017-03-23T18:23:46Z 2021-09-13T11:58:21Z "Dear developers, allow me this reflection triggered by the discussion on [https://github.com/OpenModelica/OMCompiler/pull/1561 PR 1561]. When we started to play around with models with more than 100000 equations, interesting results popped out. In particular, it turned out that many methods in the back-end and code-generation phase had an execution time and/or memory requirements scaling as O(N^2^) or, even worse, O(N^3^). Which means that above a certain threshold size, some methods take a ludicrous amount of time (tens of minutes) and space (tens of Gigabytes) to complete, which was totally unjustified. With help from Martin and Lennart we got rid of some of the worst instances of this problem, see, e.g., #3491, #3681, #3685, #4005. However, there are still many that should be fixed, see #4146 for a non-exhaustive list of pending issues. There's nothing wrong per se with algorithms with superlinear complexity. The problem is if this complexity stems from a careless implementation: if every step of an O(N) algorithm actually takes O(N) seconds because the wrong data structure is used, we end up with O(N^2^) execution time. In the past most of the focus was in getting OMC to work, even on the simplest models. Now that we are approaching 100% coverage with the new front-end (which will also be way faster, see #4071), the bottleneck will increasingly be the time spent by the back-end and code-generation phases. IMHO it is very important to avoid introducing further methods that do not scale well, besides fixing existing models that already do not do so. I would propose the following guidelines: - Experimental methods, which are turned off by default, are allowed to have bad scaling performance. The focus in this case is on the concept and on the correctness of the algorithm, not on the efficiency of implementation - Production-quality methods, which are turned on by default, should instead have strict requirements on performance, which should scale as the theoretical complexity of the algorithm, not more than that - Scaling properties can be easily checked by running the LibraryExperimental task on Hudson onto the ScalableTestSuite library, setting the appropriate flags. Some time ago Lennart developed a script to generate nice reports, see e.g. [https://trac.openmodelica.org/OpenModelica/attachment/ticket/3491/HeatingSystem_v1.9.4-dev.539%2Bgc45436a.pdf this example]. He could probably put it on GitHub somewhere so everybody can use it, or it could even be triggered automatically by Hudson - If some algorithms still have superlinear complexity because of intrinsic reasons, an upper limit should be set on the problem size, so that the algorithm is not applied to systems with larger size. A flag to change the value of this threshold should be added I would also invite Martin and/or Lennart to prepare and link a short wiki page with hints and programming patterns to avoid this kind of problems (e.g. use tail recursion instead of plain recursion, or prefer some data structures to others in certain contexts). Some developers are not really experts in these efficiency issues, and it would be good if we capitalize on what some of us have already learned by spreading the information, rather than repeating the same errors times and again. Comments?" Francesco Casella 5746 Translation Error from Timer block *unknown* v1.14.0 discussion Andreas Heuermann assigned 2019-12-12T09:46:10Z 2021-09-13T11:58:21Z "This is a duplicate from my entry on openmodelcia forum from july 2019: Connecting two of my models (model A and model B) resulting in a Translation Error {{{ [16] 10:21:48 Translation Warning There are discrete tearing variables because otherwise the system could not have been torn (unsolvables). This may lead to problems during simulation. [17] 10:21:48 Translation Error [Modelica.Blocks.Logical: 819:7-819:23]: The language feature non-linear equations within when-equations is not supported. Suggested workaround: Perform non-linear operations outside the when-equation (this is slower, but works) [18] 10:21:48 Translation Error Internal error function createNonlinearResidualEquations failed [19] 10:21:48 Translation Error [C:/dev/OM64bit/OMCompiler/Compiler/SimCode/SimCodeUtil.mo: 3306:9-3306:50]: Internal error function createOdeSystem failed for component torn nonlinear Equationsystem{{{107:45}, {110:141}, {106:43}, {105:44}, {104:51}, {102:136}, {101:1}, {100:2}, {81:46}, {80:47}, {99:4}, {82:50,49,48,127}, {85:140}, {83:42}, {98:26}, {97:137}, {96:12}, {95:11}, {88:31,33,128,29,28,130,132,133,37,30,131,40,35,36,129,134,39,34,38,32}, {94:10}, {93:9}, {92:8}, {90:23}, {87:14}, {86:19}, {91:22}, {89:13}, {109:27}}, {84, 103, 108:55, 3, 41} Size: 3 [20] 10:21:48 Translation Error [C:/dev/OM64bit/OMCompiler/Compiler/SimCode/SimCodeUtil.mo: 1478:5-1478:77]: Internal error createEquationsForSystems failed [21] 10:21:48 Translation Error [C:/dev/OM64bit/OMCompiler/Compiler/SimCode/SimCodeUtil.mo: 746:5-746:146]: Internal error function createSimCode failed [Transformation from optimised DAE to simulation code structure failed] }}} Simulation each model on their own works perfectly. The translation error points to Timer block, which is present multiple time in both model A and B, so i can not pinpoint the exact block causing this problem. is there any flags that can help me debug this error? P.S: I can not share the models and trying to figure it out how can i reproduce this error with a simplify models." trista.arinomo@… 5869 NULL-Pointer Exception caused by pool_malloc FMI v1.14.0 discussion Lennart Ochel new 2020-02-27T07:42:08Z 2021-09-13T11:58:21Z "'''Background:''' Integrating FMU from OM in a real-time simulation for Hardware in the Loop test using dSPACE HW & SW. After 3 hours of test the simulation is stopped due to NULL-Pointer exception. dSPACE support report that exception caused by pool_malloc. I try to defined the OMC_NO_THREADS when compiling the rt-app in case the pthread was the problem to no avail. I check the FMU with FMUChecker for -s 11000 -h 1e-3 and it doesn't seem to have any problem. '''Questions:''' Since the problem is reproducible and alway happend after around 10700s - 11000s (~3h)simulation time, could it be a memory leak issue? Any idea on how to debugg it further? or the underlying problem is another thing? " trista.arinomo@… 3105 Parameters and variables available in FMI FMI trunk enhancement Lennart Ochel accepted 2015-01-27T14:39:09Z 2021-09-13T11:58:21Z "Hello, I would like to create a FMU of a model where parameters and variables don't appear in the text description, or at least where i could chose which ones will appear. I would also like to be able to chose wich parameters will appear in the result file. For instance, in Dymola, user has the possibility to chose to include all variables (or not) during FMU export. It's critical to for us to hide some parameters when exchanging the models and to provide clear result files with only interesting variables." llachassagne@… 5099 Merging min/max attributes for alias elimination Backend enhancement Karim Adbdelhak new 2018-08-29T16:32:37Z 2021-09-13T11:58:21Z "Min/max attributes can have an important influence on the correctness and performance of Modelica models. In particular, this is critical for the optimization of the {{{inStream()}}} operator, see Section 9.2 of the Modelica Specification. The current implementation of {{{inStream()}}} (see #3885) opimizes away terms with {{{min >= 0}}} and {{{max <= 0}}} after alias elimination. It is thus essential that min/max information is not lost in the process: when many variables in an alias set are represented by one variable in the problem that will be solved numerically, the min/max attributes of this variable should span the intersection of the min/max intervals of each variable in the set. In particular, it is important to merge the min/max attributes of variables showing up in alias equations that can stem from connect statements and from typical modelling equations involving flow variables, that is: x = y x + y = 0 (-x) + y = 0 x + (-y) = 0 x = -y -x = y This functionality is partially implemented as of 29/08/2018 (see e.g. [https://github.com/OpenModelica/OMCompiler/blob/master/Compiler/BackEnd/RemoveSimpleEquations.mo#L1372 here] and [https://github.com/OpenModelica/OMCompiler/blob/master/Compiler/BackEnd/RemoveSimpleEquations.mo#L944 here]), but there are still problems. On the one hand, I'm not sure that all cases listed above are covered. On the other hand, when running the following simple test case with {{{-d=optdaedump}}} {{{ model TestMinMax Real x(min = 0); Real y; Real z; equation x+y=0; z = x; y = time; end TestMinMax; }}} the following output is obtained {{{ 1: z:VARIABLE() .TestMinMax type: Real 2: y:VARIABLE() .TestMinMax type: Real 3: x:VARIABLE(min = 0.0 ) .TestMinMax type: Real }}} while one would expect to see min = 0 on z and max = 0 on y. This issue should preferably be solved in 1.13.0, because it has an impact on the optimization of stream connectors, that are widely used in a number of Modelica libraries. It should also be addressed in the {{{removeSimpleEquations=new}}} module which is currently under development." Francesco Casella 5147 Log scale OMEdit enhancement Adeel Asghar new 2018-10-02T07:32:56Z 2021-11-23T08:01:07Z "Hi , The log scale grid does'nt work properly : There is only grids for 1,4,6,8, but not 2[[Image()]]" yvan.abbe@… 5925 Reduced installation Installation program v1.16.0-dev enhancement Adeel Asghar new 2020-04-25T06:46:21Z 2021-09-13T11:58:21Z "We have to replace lots of lab experiments by simulations due to the Corona pandemic, and students are not allowed to go to the University. Distant learning, students have to work at home. OM is a very important tool! Although I have a decent notebook, the installation of OM 1.16 takes ages and installs a lot of libraries not needed by students. For students (and myabe other users) it would be a big advantage to be able to choose the components that have to be installed, minimum OMedit (to be able to simulate) + MSL, no other libraries. Is there any chance to get a solution within short?" Anton Haumer 5964 Link relevant OpenModelica workshop presentations and project deliverables to OMC User's Guide Documentation enhancement Adeel Asghar new 2020-05-18T23:23:51Z 2021-09-13T11:58:21Z "Lots of developments of OpenModelica are described in technical presentations given at the OpenModelica Annual Workshop, and oftentimes detailed technical information is contained in publicly accessible reports of research projects. Unfortunately, people who did not participate directly in these developments are not even aware of the existence of this documentation. My advice is to add hyperlinks pointing to this documentation to the [https://openmodelica.org/doc/OpenModelicaUsersGuide/latest/index.html OpenModelica User's Guide], which is the reference for all users. This would ensure that these documents can be accessed, and provide detailed and valuable information about how the tool works. Commercial tools have a point at keeping this secret, we should instead promote being open about these details. My advice is that people and organization that worked on OMC-related funded projects that produced deliverables, as well as people who presented technical developments at the Annual Meetings, could send the links to @adeas31, and he could then add them to the documentation. Do you agree?" Francesco Casella 6034 Briefly explain the compilation pipeline and the role of compilation vs. simulation flags Documentation enhancement Adeel Asghar assigned 2020-06-26T00:36:20Z 2021-09-13T11:58:21Z "Today I had an interesting discussion with Tobias Krenz, a German master student using OMC to study sulphuric acid production plants. He told me he was quite confused by the difference between compilation and simulation flags. Eventually he read the book by Peter Fritzson and got it, but maybe having some indications in the User's Guide would be nice. We could add a short section in the Introduction, after System Overview and before Interactive session, where we explain what the main steps do (front-end, backend, code generation, C code compilation, simulation execution) and the role of compilation and simulation flags. @Karim, @AnHeuermann, would you mind doing that? Otherwise, I can take care of that myself. Thanks!" Francesco Casella 2173 simulate API function does not complain on wrong parameters Interactive Environment trunk 2.0.0 defect Adrian Pop accepted 2013-05-03T11:21:22Z 2018-09-17T16:08:35Z "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." Francesco Casella 3186 Partial binding of record sub-components in functions are lost New Instantiation trunk 2.0.0 defect Per Östlund assigned 2015-03-03T19:22:45Z 2019-04-04T21:03:45Z "The modifiers on record S, variable s in function precalculation are lost during flattening. See the model below. Today's test show an increase from 74 to 89 built models for the PowerSystems library, see https://test.openmodelica.org/libraries/history/PowerSystems-trend.svg This is due to the introduction of the workaround M3 of #3183, see https://github.com/modelica/PowerSystems/commit/bb0593fd7db98de8af4ead2c2047a280267955ef Interestingly no compilation error occurs. The simulations fail with divisions by zero, because the record constructor functions are not called. See the following example: {{{#!mo package MissingPrecalculation record R parameter Integer nr; Real[nr] vr; end R; record S parameter Integer ns; Real[ns] vs; end S; function precalculation input R r; output S s(ns = r.nr); algorithm s.vs := 2*r.vr; end precalculation; model M3 parameter R r(nr = 2, vr = {1, 2}); record S2 = S(ns = r.nr); parameter S2 s = precalculation(r); end M3; end MissingPrecalculation; }}} Flattening results in: {{{#!mo function MissingPrecalculation.precalculation input MissingPrecalculation.R r; output MissingPrecalculation.S s; algorithm s.vs := r.vr * 2.0; end MissingPrecalculation.precalculation; class MissingPrecalculation.M3 parameter Integer r.nr = 2; parameter Real r.vr[1] = 1.0; parameter Real r.vr[2] = 2.0; parameter Integer s.ns = s.r.nr; parameter Real s.vs[1]; parameter Real s.vs[2]; end MissingPrecalculation.M3; }}} Couldn't the the modifier for ns be kept in the precalculation function and the function call be placed in initial equations: {{{#!mo function MissingPrecalculation.precalculation input MissingPrecalculation.R r; output MissingPrecalculation.S s(ns = r.nr); algorithm s.vs := r.vr * 2.0; end MissingPrecalculation.precalculation; class MissingPrecalculation.M3 parameter Integer r.nr = 2; parameter Real r.vr[1] = 1.0; parameter Real r.vr[2] = 2.0; parameter Integer s.ns(fixed = false); parameter Real s.vs[1](fixed = false); parameter Real s.vs[2](fixed = false); initial equation s = /*.MissingPrecalculation.S*/(MissingPrecalculation.precalculation(/*.MissingPrecalculation.R*/(r))); end MissingPrecalculation.M3; }}} Any other idea?" Rüdiger Franke 4050 Array of component: Too many equations. Backend 2.0.0 defect Lennart Ochel new 2016-09-22T08:30:48Z 2019-01-07T12:57:52Z "I need to create an array of `PC` components, similar to the minimal example below. When doing so, OpenModelica reports 142 equations and 126 variables. {{{#!mo model test inner PNlib.Settings settings annotation(Placement(visible = true, transformation(origin = {-30, 30}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); PNlib.PC P1[2] annotation(Placement(visible = true, transformation(origin = {0, 0}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); annotation(uses(PNlib(version = ""1.4""))); end test; }}} " Lennart Ochel 5531 Implicit cast from Real to Integer Backend v1.14.0-dev-nightly 2.0.0 defect Andreas Heuermann assigned 2019-06-13T13:42:16Z 2019-06-14T14:16:12Z "Is the following model legal Modelica syntax? {{{ model TestInt Real x(start=1); Integer y; equation der(x) = x; y = x; end TestInt; }}} A real is casted to an integer and no warning or error is printed by OMC. In my opinion it is not 100% defined what should happen an the user should explicit state what he wants, e.g. use `ceil(x)`, `floor(x)` or `integer(x)`. Dymola will report: {{{ Translation of TestInt: The problem is structurally singular. It has 2 scalar unknowns and 2 scalar equations. The Real part has 1 unknowns and 2 equations. The Integer part has 1 unknowns and 0 equations. The Boolean part has 0 unknowns and 0 equations. The String part has 0 unknowns and 0 equations. Attempting to further localize singularity. Singularity of TestInt is at the top level. The model TestInt is structurally singular. The problem is structurally singular for the element type Real. The number of scalar Real unknown elements are 1. The number of scalar Real equation elements are 2. Part of the problem for Real elements is overdetermined. There are 1 scalar equations too many in the set: y = x; der(x) = x; which was derived from der(x) = x; The problem is structurally singular for the element type Integer. The number of scalar Integer unknown elements are 1. The number of scalar Integer equation elements are 0. The following variables are considered as unknowns, but are not appearing in the equations. y Translation aborted. WARNINGS have been issued. ERRORS have been issued. }}} My suggestion: Throw an error (while parsing or from the Frontend) and only accept a correct version like: {{{ model TestInt Real x(start=1); Integer y; equation der(x) = x; y = integer(x); end TestInt; }}} Or give a warning and implicit cast all non-real variables to integers like above. For the example above it's pretty clear what should happen. But what is the correct solution for the following model? {{{ model TestInt2 Real x(start=1); Real y; Integer z; equation der(x) = x; z = x; der(y) = z; end TestInt2; }}} `der(y)` should now be discrete (equals 1 up to time=0.69 and after that equals 2) but it's computed solution is in fact equal to `der(x)`. Whit a warning or error a user would notice that this model doesn't make much sense." Andreas Heuermann 5616 Handling of indexing in arrays of records Code Generation 2.0.0 defect Lennart Ochel new 2019-08-11T10:52:21Z 2019-08-11T13:39:00Z "See also: https://openmodelica.org/forum/default-topic/2772-problem-while-iterating-on-records Build Test22 has issues: {{{#!mo package Structure2 record TestRecord2 Real Tc[2]; end TestRecord2; function Suma input Real tc[2]; output Real a; algorithm a:=tc[1]+tc[2]; end Suma; model RecordTestBase2 constant TestRecord2 test1(Tc={5.0,50.0}); constant TestRecord2 test2(Tc={10.0,100.0}); constant TestRecord2 test[2] = {test1,test2}; Real A; end RecordTestBase2; model Test21 extends RecordTestBase2; algorithm A:=0.0; for i in 1:2 loop A:=A+test[i].Tc[1]+test[i].Tc[2]; end for; end Test21; model Test22 extends RecordTestBase2; algorithm A:=0.0; for i in 1:2 loop A:=A+Suma(test[i].Tc); end for; end Test22; end Structure2; }}} {{{ ""[CodegenCFunctions.tpl:6583:13-6583:13:writable] Error: Template error: ASUB non-scalar {{5.0, 50.0}, {10.0, 100.0}}[i]. The inner exp has type: Real[2, 2]. After ASUB it is still an array: Real[2].. [C:/home/adrpo33/dev/OpenModelica/OMCompiler/Compiler/SimCode/SimCodeMain.mo:471:7-471:78:writable] Error: Internal error C:\home\adrpo33\dev\OpenModelica\build\bin\omc.exe: [unknown function name] failed [CodegenCFunctions.tpl:6583:13-6583:13:writable] Error: Template error: ASUB non-scalar {{5.0, 50.0}, {10.0, 100.0}}[i]. The inner exp has type: Real[2, 2]. After ASUB it is still an array: Real[2].. [C:/home/adrpo33/dev/OpenModelica/OMCompiler/Compiler/SimCode/SimCodeMain.mo:471:7-471:78:writable] Error: Internal error C:\home\adrpo33\dev\OpenModelica\build\bin\omc.exe: [unknown function name] failed }}} " Adrian Pop 5943 Get rid of OPENMODELICAHOME (and OPENMODELICALIBRARY) Interactive Environment 2.0.0 defect somebody new 2020-05-07T20:17:01Z 2020-05-14T21:29:15Z "Currently we use OPENMODELICAHOME to point to the OM installation in Windows. We should remove the need for this variable as: - would simplify having multiple installations on the same computer #5809 - would make handling of installation directory homogeneous on all platforms Issues: - some clients are using this OPENMODELICAHOME variable to find omc (MDT, OMPython, etc) - the build process is using the OPENMODELICAHOME variable All references of OPENMODELICAHOME in OpenModelica/ (filter on files: {{{*.mo *.tpl *.cpp *.c *.h *.hpp, *akefile*, CMake*}}}) {{{ Search ""OPENMODELICAHOME"" (100 hits in 35 files) e:\dev\OpenModelica\OMCompiler\CMakeLists.txt (3 hits) Line 17: SET(OPENMODELICAHOME $ENV{OPENMODELICAHOME}) Line 17: SET(OPENMODELICAHOME $ENV{OPENMODELICAHOME}) Line 18: SET(OMC_DEBUG ${OPENMODELICAHOME}/bin/omc.exe) e:\dev\OpenModelica\OMCompiler\Compiler\BackEnd\OpenTURNS.mo (2 hits) Line 683: returns $OPENMODELICAHOME/share/omc/scripts/OpenTurns/"" Line 695: returns $OPENMODELICAHOME/share/omc/scripts/OpenTurns/FILE_NAME e:\dev\OpenModelica\OMCompiler\Compiler\FrontEnd\ModelicaBuiltin.mo (6 hits) Line 1044: String OPENMODELICAHOME, OPENMODELICALIBRARY, OMC_PATH, SYSTEM_PATH, OMDEV_PATH; Line 1482: function setInstallationDirectoryPath ""Sets the OPENMODELICAHOME environment variable. Use this method instead of setEnvironmentVar."" Line 1489: function getInstallationDirectoryPath ""This returns OPENMODELICAHOME if it is set; on some platforms the default path is returned if it is not set."" Line 1510:

To override the default path (OPENMODELICAHOME/lib/omlibrary/:~/.openmodelica/libraries/), set the environment variable OPENMODELICALIBRARY=...

Line 3825:

You will also need to start an m3d backend to render the results. We hid them in $OPENMODELICAHOME/lib/omlibrary-modelica3d/osg-gtk/dbus-server.py (or blender2.59).

Line 4929: Redirecting to the on-line release notes (you can also find the release notes in the locally installed version of the user's guide, OPENMODELICAHOME/share/doc/OpenModelicaUsersGuide). e:\dev\OpenModelica\OMCompiler\Compiler\Main\Main.mo (4 hits) Line 723: System.setEnv(""OPENMODELICAHOME"",omHome,true); Line 746: print(""We could not find some needed MINGW paths in $OPENMODELICAHOME or $OMDEV. Searched for paths:\n""); Line 898: print(""Error: OPENMODELICAHOME was not set.\n""); Line 900: print("" Most OpenModelica release distributions have scripts that set OPENMODELICAHOME for you.\n\n""); e:\dev\OpenModelica\OMCompiler\Compiler\NFFrontEnd\NFModelicaBuiltin.mo (6 hits) Line 1247: String OPENMODELICAHOME, OPENMODELICALIBRARY, OMC_PATH, SYSTEM_PATH, OMDEV_PATH; Line 1667: function setInstallationDirectoryPath ""Sets the OPENMODELICAHOME environment variable. Use this method instead of setEnvironmentVar."" Line 1674: function getInstallationDirectoryPath ""This returns OPENMODELICAHOME if it is set; on some platforms the default path is returned if it is not set."" Line 1695:

To override the default path (OPENMODELICAHOME/lib/omlibrary/:~/.openmodelica/libraries/), set the environment variable OPENMODELICALIBRARY=...

Line 3958:

You will also need to start an m3d backend to render the results. We hid them in $OPENMODELICAHOME/lib/omlibrary-modelica3d/osg-gtk/dbus-server.py (or blender2.59).

Line 5002: Redirecting to the on-line release notes (you can also find the release notes in the locally installed version of the user's guide, OPENMODELICAHOME/share/doc/OpenModelicaUsersGuide). e:\dev\OpenModelica\OMCompiler\Compiler\runtime\settingsimpl.c (5 hits) Line 71: fprintf(stderr, ""could not deduce the OpenModelica installation directory from executable path: [%s], please set OPENMODELICAHOME"", omhome); Line 86: const char *path = getenv(""OPENMODELICAHOME""); Line 116: const char *path = getenv(""OPENMODELICAHOME""); Line 270: /* set the env-var to created string this is useful when scripts and clients started by omc wants to use OPENMODELICAHOME*/ Line 280: commonSetEnvVar(""OPENMODELICAHOME"",value); e:\dev\OpenModelica\OMCompiler\Compiler\runtime\systemimpl.c (1 hit) Line 2649: fprintf(stderr, ""Warning: environment variable OPENMODELICAHOME is not set. Cannot load locale.\n""); e:\dev\OpenModelica\OMCompiler\Compiler\Script\CevalScript.mo (7 hits) Line 243: // We only need to set OPENMODELICAHOME on Windows, and set doesn't work in bash shells anyway Line 246: // OPENMODELICAHOME that we set will contain a SPACE at the end! Line 247: // set OPENMODELICAHOME=DIR && actually adds the space between the DIR and && Line 249: omhome := ""set OPENMODELICAHOME="" + System.stringReplace(omhome_1, ""/"", ""\\"") + ""&& ""; Line 287: // Check that it is a correct OPENMODELICAHOME, on Windows only Line 290: Error.addMessage(Error.SIMULATOR_BUILD_ERROR, {stringAppendList({""command "",s_call,"" not found. Check $OPENMODELICAHOME""})}); Line 1650: vars_1 = {""OPENMODELICAHOME"", e:\dev\OpenModelica\OMCompiler\Compiler\Script\CevalScriptBackend.mo (8 hits) Line 1588: Settings.getInstallationDirectoryPath() ""simulation fail for some other reason than OPENMODELICAHOME not being set."" ; Line 1600: ""\nEnvironment variable OPENMODELICAHOME not set."", Line 2595: // get OPENMODELICAHOME Line 2656: // get OPENMODELICAHOME Line 3066: // get OPENMODELICAHOME Line 3868: // get OPENMODELICAHOME Line 5532: $OPENMODELICAHOME/work if the file was not saved yet"" Line 5561: omhome = Settings.getInstallationDirectoryPath() ""model not yet saved! change to $OPENMODELICAHOME/work"" ; e:\dev\OpenModelica\OMCompiler\Compiler\SimCode\SerializeInitXML.mo (1 hit) Line 116: File.write(file, "" OPENMODELICAHOME = \""""); e:\dev\OpenModelica\OMCompiler\Compiler\Template\CodegenCpp.tpl (16 hits) Line 3144: OMHOME=<%if boolOr(stringEq(makefileParams.platform, ""win32""),stringEq(makefileParams.platform, ""win64"")) then '$(OPENMODELICAHOME)' else makefileParams.omhome%> Line 3226: OMHOME=<%if boolOr(stringEq(makefileParams.platform, ""win32""),stringEq(makefileParams.platform, ""win64"")) then '$(OPENMODELICAHOME)' else makefileParams.omhome%> Line 3324: OPENMODELICAHOME := $(subst \,/,$(OPENMODELICAHOME)) Line 3324: OPENMODELICAHOME := $(subst \,/,$(OPENMODELICAHOME)) Line 3377: IDE_INCLUDES = -I$(WIND_BASE)/target/h -I$(WIND_BASE)/target/h/wrn/coreip -I$(MLPI_SDK_01)/mlpiCore/include -I$(OPENMODELICAHOME)/include/omc/omsicpp -I$(OPENMODELICAHOME)/include/omc/omsicpp/Core -I$(OPENMODELICAHOME)/include/omc/omsicpp Line 3377: IDE_INCLUDES = -I$(WIND_BASE)/target/h -I$(WIND_BASE)/target/h/wrn/coreip -I$(MLPI_SDK_01)/mlpiCore/include -I$(OPENMODELICAHOME)/include/omc/omsicpp -I$(OPENMODELICAHOME)/include/omc/omsicpp/Core -I$(OPENMODELICAHOME)/include/omc/omsicpp Line 3377: IDE_INCLUDES = -I$(WIND_BASE)/target/h -I$(WIND_BASE)/target/h/wrn/coreip -I$(MLPI_SDK_01)/mlpiCore/include -I$(OPENMODELICAHOME)/include/omc/omsicpp -I$(OPENMODELICAHOME)/include/omc/omsicpp/Core -I$(OPENMODELICAHOME)/include/omc/omsicpp Line 3379: IDE_LIBRARIES = $(OPENMODELICAHOME)/lib/omc/omsicpp/vxworks/SimCore.a Line 3426: com.boschrexroth.$(MODEL_NAME)/$(MODE_DIR)/% : IDE_INCLUDES = -I$(WIND_BASE)/target/h -I$(WIND_BASE)/target/h/wrn/coreip -I$(MLPI_SDK_01)/mlpiCore/include -I$(OPENMODELICAHOME)/include/omc/omsicpp -I$(OPENMODELICAHOME)/include/omc/omsicpp/Core -I$(OPENMODELICAHOME)/include/omc/omsicpp Line 3426: com.boschrexroth.$(MODEL_NAME)/$(MODE_DIR)/% : IDE_INCLUDES = -I$(WIND_BASE)/target/h -I$(WIND_BASE)/target/h/wrn/coreip -I$(MLPI_SDK_01)/mlpiCore/include -I$(OPENMODELICAHOME)/include/omc/omsicpp -I$(OPENMODELICAHOME)/include/omc/omsicpp/Core -I$(OPENMODELICAHOME)/include/omc/omsicpp Line 3426: com.boschrexroth.$(MODEL_NAME)/$(MODE_DIR)/% : IDE_INCLUDES = -I$(WIND_BASE)/target/h -I$(WIND_BASE)/target/h/wrn/coreip -I$(MLPI_SDK_01)/mlpiCore/include -I$(OPENMODELICAHOME)/include/omc/omsicpp -I$(OPENMODELICAHOME)/include/omc/omsicpp/Core -I$(OPENMODELICAHOME)/include/omc/omsicpp Line 3427: com.boschrexroth.$(MODEL_NAME)/$(MODE_DIR)/% : IDE_LIBRARIES = $(OPENMODELICAHOME)/lib/omc/omsicpp/vxworks/SimCore.a Line 3478: com.boschrexroth.$(MODEL_NAME)_partialImage/$(MODE_DIR)/% : IDE_INCLUDES = -I$(WIND_BASE)/target/h -I$(WIND_BASE)/target/h/wrn/coreip -I$(MLPI_SDK_01)/mlpiCore/include -I$(OPENMODELICAHOME)/include/omc/omsicpp -I$(OPENMODELICAHOME)/include/omc/omsicpp/Core -I$(OPENMODELICAHOME)/include/omc/omsicpp Line 3478: com.boschrexroth.$(MODEL_NAME)_partialImage/$(MODE_DIR)/% : IDE_INCLUDES = -I$(WIND_BASE)/target/h -I$(WIND_BASE)/target/h/wrn/coreip -I$(MLPI_SDK_01)/mlpiCore/include -I$(OPENMODELICAHOME)/include/omc/omsicpp -I$(OPENMODELICAHOME)/include/omc/omsicpp/Core -I$(OPENMODELICAHOME)/include/omc/omsicpp Line 3478: com.boschrexroth.$(MODEL_NAME)_partialImage/$(MODE_DIR)/% : IDE_INCLUDES = -I$(WIND_BASE)/target/h -I$(WIND_BASE)/target/h/wrn/coreip -I$(MLPI_SDK_01)/mlpiCore/include -I$(OPENMODELICAHOME)/include/omc/omsicpp -I$(OPENMODELICAHOME)/include/omc/omsicpp/Core -I$(OPENMODELICAHOME)/include/omc/omsicpp Line 3479: com.boschrexroth.$(MODEL_NAME)_partialImage/$(MODE_DIR)/% : IDE_LIBRARIES = $(OPENMODELICAHOME)/lib/omc/omsicpp/vxworks/SimCore.a e:\dev\OpenModelica\OMCompiler\Compiler\Template\CodegenFMU.tpl (1 hit) Line 3040: simulationInfo->OPENMODELICAHOME = ""<%makefileParams.omhome%>""; e:\dev\OpenModelica\OMCompiler\Compiler\Template\CodegenFMUCpp.tpl (2 hits) Line 649: OMHOME=<%if boolOr(stringEq(makefileParams.platform, ""win32""),stringEq(makefileParams.platform, ""win64"")) then '$(OPENMODELICAHOME)' else makefileParams.omhome%> Line 728: OMHOME=<%if boolOr(stringEq(makefileParams.platform, ""win32""),stringEq(makefileParams.platform, ""win64"")) then '$(OPENMODELICAHOME)' else makefileParams.omhome%> e:\dev\OpenModelica\OMCompiler\Compiler\Template\CodegenJava.tpl (1 hit) Line 1257: top_dir = ${OPENMODELICAHOME}/ e:\dev\OpenModelica\OMCompiler\Compiler\Util\Flags.mo (1 hit) Line 364: Gettext.gettext(""Disables warnings on Windows if OPENMODELICAHOME/MinGW is missing."")); e:\dev\OpenModelica\OMCompiler\SimulationRuntime\c\simulation\modelinfo.c (2 hits) Line 491: const char *omhome = data->simulationInfo->OPENMODELICAHOME; Line 536: strcpy(buf, ""OPENMODELICAHOME missing""); e:\dev\OpenModelica\OMCompiler\SimulationRuntime\c\simulation\simulation_input_xml.c (4 hits) Line 554: read_value_string(findHashStringString(mi.md,""OPENMODELICAHOME""), &simulationInfo->OPENMODELICAHOME); Line 554: read_value_string(findHashStringString(mi.md,""OPENMODELICAHOME""), &simulationInfo->OPENMODELICAHOME); Line 555: infoStreamPrint(LOG_SIMULATION, 0, ""OPENMODELICAHOME: %s"", simulationInfo->OPENMODELICAHOME); Line 555: infoStreamPrint(LOG_SIMULATION, 0, ""OPENMODELICAHOME: %s"", simulationInfo->OPENMODELICAHOME); e:\dev\OpenModelica\OMCompiler\SimulationRuntime\c\simulation_data.h (1 hit) Line 709: const char *OPENMODELICAHOME; e:\dev\OpenModelica\OMCompiler\SimulationRuntime\c\util\java_interface.c (3 hits) Line 291: openmodelicahome = getenv(""OPENMODELICAHOME""); Line 293: fprintf(stderr, ""getenv(OPENMODELICAHOME) failed - Java subsystem can't find the Java runtime...\n""); Line 1105: return ""The exception handler triggered an exception.\nMake sure the java runtime is installed in $OPENMODELICAHOME/share/java/modelica_java.jar\n""; e:\dev\OpenModelica\OMCompiler\SimulationRuntime\OMSICpp\omcWrapper\omcZeroMQ\src\omc.cpp (2 hits) Line 167: std::string set_omhome_var = string(""OPENMODELICAHOME="") + openmodelicaHome; Line 170: status = SetEnvironmentVariable(""OPENMODELICAHOME"", TEXT(openmodelicaHome.c_str())); e:\dev\OpenModelica\OMCompiler\SimulationRuntime\OMSICpp\runtime\src\Core\ReduceDAE\com\ModelicaCompiler.cpp (2 hits) Line 23: char* omhome = getenv(""OPENMODELICAHOME""); //should get value for OM home Line 28: std::cout << ""OPENMODELICAHOME variable doesn't set"" << std::endl; e:\dev\OpenModelica\OMCompiler\SimulationRuntime\ParModelica\explicit\openclrt\ocl_offcomp.c (2 hits) Line 85: const char* OMHOME = getenv(""OPENMODELICAHOME""); Line 173: printf(""Couldn't find OPENMODELICAHOME!\n""); e:\dev\OpenModelica\OMCompiler\SimulationRuntime\ParModelica\explicit\openclrt\ocl_offcomp.cpp (2 hits) Line 680: const char* OMHOME = getenv(""OPENMODELICAHOME""); Line 768: printf(""Couldn't find OPENMODELICAHOME!\n""); e:\dev\OpenModelica\OMCompiler\SimulationRuntime\ParModelica\explicit\openclrt\omc_ocl_util.cpp (2 hits) Line 289: const char* OMHOME = getenv(""OPENMODELICAHOME""); Line 292: printf(""Couldn't find OPENMODELICAHOME!\n""); e:\dev\OpenModelica\OMEdit\OMEditLIB\OMEditApplication.cpp (1 hit) Line 68: const char *omhome = getenv(""OPENMODELICAHOME""); e:\dev\OpenModelica\OMEdit\OMEditLIB\Util\Helper.cpp (1 hit) Line 744: return tr(""Could not find environment variable OPENMODELICAHOME. Please make sure OpenModelica is installed properly.""); e:\dev\OpenModelica\OMNotebook\OMNotebook\OMNotebookGUI\cellapplication.cpp (3 hits) Line 118: const char *omhome = getenv(""OPENMODELICAHOME""); Line 121: QMessageBox::critical(0, tr(""Error""), tr(""OPENMODELICAHOME not set""), ""OK""); Line 162: QMessageBox::critical( 0, ""OpenModelica Error"", tr(""The environment variable OPENMODELICAHOME=%1 is not a valid directory"").arg(openmodelica) ); e:\dev\OpenModelica\OMOptim\OMOptim\Core\OMC\MOomc.cpp (1 hit) Line 1428: const char *omhome = getenv(""OPENMODELICAHOME""); e:\dev\OpenModelica\OMOptim\OMOptim\Core\OMC\OMCHelper.cpp (1 hit) Line 91: return ""Could not find environment variable OPENMODELICAHOME. Please make sure OpenModelica is installed properly.""; e:\dev\OpenModelica\OMOptim\OMOptim\Core\OMC\omcinteractiveenvironment.cpp (2 hits) Line 130: std::string OMCPath( getenv( ""OPENMODELICAHOME"" ) ); Line 133: throw std::runtime_error( ""Could not find environment variable OPENMODELICAHOME"" ); e:\dev\OpenModelica\OMOptim\OMOptim\Core\OpenModelica\OpenModelica.cpp (1 hit) Line 726: QString omHome = env.value(""OPENMODELICAHOME""); e:\dev\OpenModelica\OMOptim\OMOptim\Core\Util\Helper.cpp (1 hit) Line 592: return tr(""Could not find environment variable OPENMODELICAHOME. Please make sure OpenModelica is installed properly.""); e:\dev\OpenModelica\OMOptim\OMOptim\Core\Util\Utilities.cpp (2 hits) Line 83: QString om = env.value(""OPENMODELICAHOME""); Line 136: static QString om = env.value(""OPENMODELICAHOME"") + QDir::separator() + ""bin""; e:\dev\OpenModelica\OMOptim\OMOptim\GUI\Tabs\TabOMC.cpp (2 hits) Line 68: QString openmodelica( getenv( ""OPENMODELICAHOME"" ) ); Line 70: QMessageBox::critical( 0, ""OMShell Error"", ""Could not find environment variable OPENMODELICAHOME, command compleation will not work"" ); e:\dev\OpenModelica\OMShell\OMShell\OMShellGUI\oms.cpp (1 hit) Line 266: QMessageBox::critical( 0, ""OMShell Error"", ""Could not find environment variable OPENMODELICAHOME, command completion will not work"" ); }}} " Adrian Pop 6350 OMEdit cannot handle simulations with more than 10000 variable comfortably OMEdit v1.17.0-dev 2.0.0 defect Adeel Asghar new 2021-01-26T00:47:54Z 2021-04-01T11:59:30Z "I have recently tried to simulate some models with a few tens of thousands of equations, see, e.g., #6271. OMC is not super-fast in this size range, but kind of acceptable, maybe a few minutes for code generation and a few seconds for simulation. When that is finished, the pain begins: switching from the Modelling to the Plotting window sometimes takes forever, for no obvious reason. To reproduce the problem, please try the attached simple test package. When you run M_10000, visualization is a breeze. But if you then run M_15000, and possibly M_20000, switching to the plotting window may take minutes. With no clue how long it could take. This should be investigated and fixed for 1.18.0. If we plan on supporting large models with frontend and backend, OMEdit should be up to the task. " Francesco Casella 4596 Document the symbolic transformation carried out by the various back-end modules Documentation 2.0.0 enhancement Martin Sjölund new 2017-10-28T08:49:17Z 2017-10-28T08:49:17Z "The back-end modules do a lot of smart symbolic manipulations, most of which are documented somewhere in various papers. However, only developers with a long aquaintance to the code really know what they do, and we cannot expect end users to read the MetaModelica source code and perform bibliographic searches in order to find out what is done to their poor model's equations. In the spirit of open source development, I would suggest that we write a chapter of the User's Guide where we (shortly!) explain what the modules do. As ticket:4398#comment:30 clearly demonstrates, this is sometimes not really obvious even to exper users." Francesco Casella 5345 omc-based FMI import in OMEdit OMEdit 2.0.0 enhancement Adeel Asghar new 2019-02-18T13:33:14Z 2022-03-16T17:49:20Z "In today’s developer meeting we discussed to removing the omc-based FMI import. As a first step, we agreed on replacing the omc-based FMI import in OMEdit with a pointer to the OMSimulator documentation. If there is a good reason to keep the omc-based fmi import, please let us know. Otherwise the functionality will be completely replaced by OMSimulator at a later point in time." Lennart Ochel 5664 Reload feature in OMEdit OMEdit v1.14.0-dev-nightly 2.0.0 enhancement Adeel Asghar new 2019-10-17T18:18:36Z 2019-10-21T10:27:00Z "Hi there When editing code outside of OMEdit, it would be very useful to have a 'reload' option in OMEdit so that packages and/or models could be reloaded as required, to update OMEdit with the current file contents. Currently the process is a bit onerous -- one has to right-click to unload, then file->recent->(select name) to reload a single file. It should be noted that many text editors now automatically offer the user to re-load files, alerting the user to the fact that the file in the edit buffer is no longer the same as the filesystem version. Another use-case for this issue is when creating/editing icons for packages/models/etc. " john.pye@… 5917 New Backend proposal Backend 2.0.0 enhancement Karim Adbdelhak assigned 2020-04-14T12:01:18Z 2020-04-16T14:10:38Z "An initiative is on-going to gradually replace the existing back-end with a new, restructured one. The basic structure is currently being discussed here: https://github.com/OpenModelica/BackendDesign The repository will be made public as soon as the proposal has reached a stable enough state." Francesco Casella 5996 Graphical support to propagate parameters OMEdit 2.0.0 enhancement Adeel Asghar new 2020-06-03T06:41:00Z 2020-06-03T10:41:15Z Graphical support to propagate model parameters to a higher level of abstraction would be very beneficial. robert.hallqvist@… 5997 Improve CVODE in C-runtime to production-grade Run-time v1.16.0-dev 2.0.0 enhancement Andreas Heuermann new 2020-06-04T11:14:29Z 2020-06-04T17:47:08Z "CVODE is implemented in the nightly builds and running. See test overview at https://libraries.openmodelica.org/branches/cvode/Modelica_3.2.3/Modelica_3.2.3.html. When comparing with the default DASSL solver there are still some failing or unvverfied tests and the solver needs way way more steps. In addition most of the basic features DASSL and IDA offer are not implemented yet: - Non-Colored/Colored Numeric/Symbolic Jacobians - Sparse linear solver (KLU) - Improved error handling when failing to integrate - Additional user flags for most of the CVODE settings we use For 1.16 we should at least make sure that the implementation is error free and the results are correct." Andreas Heuermann 1478 Handling mixed systems containing discrete iteration variables Backend trunk Future defect somebody assigned 2011-04-12T13:46:16Z 2017-06-14T12:04:59Z "The attached model causes findDiscreteEquation to fail when compiling the Microwave model. Update: The compiler actually generates code anyway, which contains a huge residual functions (> 11000 lines) and segfaults when executed." Per Östlund 1814 Typechecker incorrectly unifies distinct types through polymorphic type variables Frontend trunk Future defect somebody new 2012-09-16T00:29:39Z 2017-11-14T22:08:53Z "I finally managed to get this reproduction down to a manageable size. It can probably be minimized further but this should be good enough to see the issue. If it's unclear I can try to make it even smaller. The issue is a unification that passes but should not, it ends up with me being able to pass a Tuple as the argument to a function expecting Integer through the use of replaceable types. I had a similar issue earlier where I managed to construct a list where one of the elements was another list. The issue stems from a bug in my code (using a tuple instead of an int) but it is hard to find and debug these bugs when the compiler accepts them. Actual Output: {{{ {true,true,true} true """" intEqual 1, 2284673025 false """" }}} Expected output: {{{ {true,true,true} false ""Some Type Error here"" }}} test.mos: {{{ setCommandLineOptions({""+d=rml,noevalfunc,failtrace"",""+g=MetaModelica"",""+showAnnotations""}); loadFile(""test.mo""); getErrorString(); // First element Test.test(1, 1); getErrorString(); }}} test.mo: {{{ encapsulated package Collection replaceable type State subtypeof Any; replaceable type Element subtypeof Any; partial function Next input State state; output Element current; output State nextState; end Next; partial function IsEmpty input State state; output Boolean empty; end IsEmpty; partial function Equality input A x; input A y; output Boolean isEqual; end Equality; function eq input Next next; input Equality equalityFunction; input A element; input State it; output Boolean res; protected // Side note: Element is unified with A implicitly here, but if this line is changed to // A currentElement; // an error is thrown: // Type mismatch in pattern currentElement\n actual type: polymorphic\n expected type:\n polymorphic Element currentElement; algorithm // call next, which will be Test.next in the test (currentElement, _) := next(it); res := equalityFunction(element, currentElement); end eq; end Collection; package Test protected import Collection.{eq}; function intEqual input Integer x; input Integer y; output Boolean equal; algorithm // This line prints x correctly, but y is a tuple and its address (?) is printed. print(""intEqual\n"" +& intString(x) +& "", "" +& intString(y) +& ""\n""); equal := x == y; end intEqual; function next input Integer it; output Tuple currentElement; output Integer nextIt; algorithm // Incorrectly return a tuple even though intEqual(Int,Int) => Bool and not intEqual(Int,Tuple) => Bool currentElement := (it, it); nextIt := it; end next; function test input Integer element; input Integer i; output Boolean res; algorithm res := Collection.eq(next, intEqual, element, i); // fails properly // res := intEqual(element, (element,element)); end test; end Test; }}}" adabe588@… 2221 Documentation of Scripting and Communication Protocol Interactive Environment trunk Future defect somebody new 2013-06-05T13:00:05Z 2013-06-05T13:01:49Z " Feedback from Bill Janssen: Document the current OM scripting and communication protocol (e.g. as used between OMEdit and OMC), and in the longer term redesign part of it to make it more consistent. This is important for eliminating some bugs and misunderstandings in the OM clients, and making the Adeel: OpenModelica scripting environment is already documented https://build.openmodelica.org/Documentation/OpenModelica.Scripting.html. The only problem is that it doesn’t include the interactive module which is almost half of the scripting environment. We should move all the stuff from interactive to CevalScript & ModelicaBuiltin. Martin had been suggesting this from a very long time now. PeterF: We can start now by documenting the existing interactive module API including small examples, right now, before moving it to ModeliaBuiltin which will involve some redesign." Peter Fritzson 2222 OMPython interface loses sequence info and OMPython exit bug OMPython trunk Future defect Alachew Mengist new 2013-06-05T13:28:33Z 2013-06-05T13:54:31Z " This is related to #2221: Documentation of Scripting and Communication Protocol Ticket URL: The bad state of documentation contributes to bugs as the one below. Initially Reported July 7, 2012, by Bill Janssen, Xerox Parc (email: janssen@parc.com) Reported once more in person to Peter Frizson during Modelica Design meeting June 4,2013 I'm trying to use the new Python interface to OpenModelica to pull the graphics annotations out of a model, so that I can render them as SVG. However, when I pull the graphics for an icon, for example: >>> OMPython.execute(""getIconAnnotation(Modelica.Electrical.Analog.Basic >>> .Ground)"") I get something like this (pretty-printed): {'SET1': {'Set1': [-100.0, -100.0, 100.0, 100.0, True, 0.1, 2.0, 2.0]}, 'SET2': {'Elements': {'Line1': {'Properties': {'Set1': [0.0, 0.0], 'Set2': [0, 0, 255], 'Set3': ['Arrow.None', 'Arrow.None'], 'Subset1': {'Set1': [-60, 50], 'Set2': [60, 50]}, 'Values': [True, 0, 'LinePattern.Solid', 0.25, 3, 'Smooth.None']}}, [ ... more Line elements deleted ...] Now, just for comparison, pulling it via OMShell-terminal looks like {-100.0,-100.0,100.0,100.0,true,0.1,2.0,2.0,{Line(true, {0.0, 0.0}, 0, {{-60, 50}, {60, 50}}, {0, 0, 255}, LinePattern.Solid, 0.25, {Arrow.None, Arrow.None}, 3, Smooth.None), [... more Line elements deleted ...] The additional and pointless key-value layers are simply a design flaw and an annoyance, but mapping ordered lists into unordered sets of name-value pairs is a bug. Take SET2:Elements:Line1:Properties:Subset1, for instance. Apparently a Line can have many points (the Modelica spec is unclear on this), and they are given in order in the annotation. However, the order in the Python value is only given by a properly constructed sort of the keys of that dict, and the default sort will not produce the correct results for sufficiently large sets of points ('Set10' will sort before 'Set2'). Let me suggest that all {} Modelica arrays be turned into Python lists, and that typed 'objects' (like Line) be turned into Python tuples giving the object type name ('Line'), and a list of values. So in that mapping, we'd see {-100.0,-100.0,100.0,100.0,true,0.1,2.0,2.0,{Line(true, {0.0, 0.0}, 0, {{-60, 50}, {60, 50}}, {0, 0, 255}, LinePattern.Solid, 0.25, {Arrow.None, Arrow.None}, 3, Smooth.None), ... become [-100.0,-100.0,100.0,100.0,true,0.1,2.0,2.0, ('Line', [true, [0.0, 0.0], 0, [[-60, 50], [60, 50]], [0, 0, 255], 'LinePattern.Solid', 0.25, ['Arrow.None', 'Arrow.None'], 3, 'Smooth.None'), ... It's a shame we're not actually using the cumbersome CORBA system that's somewhat pointlessly built into the Python interface. If the IDL was fleshed out with the various method calls and data types that go across it, we could use it to generate network API documentation, and coherent APIs in Python and other languages. 'Arrow' would actually be an enumeration, and 'Arrow.None' would be a real Python value. Bill One more bug: Bill: I find that running a Python program which invokes OMPython results in an omc server *still running* after the Python program exits. There should be an ""atexit"" hook there to shut down the server. To make matters worse, if you try to do OMPython.execute('quit()'), the module calls sys.exit(1) itself, a major no-no for a library module. Just mark it as 'omc not running', and re-start omc if the user tries to use it again. Bill " Peter Fritzson 2548 libs paramerter of SimCode.makefileParams for msvc is not correct Backend trunk Future defect Adrian Pop assigned 2014-01-27T16:38:31Z 2017-11-14T22:08:53Z "The libs parameter of SimCode.makefileParams is not correct generated if msvc code generation is activated. It generates a lib string ""-LD:[libname]"" which is not a valid nmake command. " Niklas Worschech 2634 underdetermined initialization problems lead to division by zero Backend trunk Future defect Lennart Ochel new 2014-03-21T13:50:52Z 2017-11-14T22:08:53Z "In some cases underdetermined initialization problems lead to division by zero errors. This happens if a bad set of variables is selected for which additional initial conditions get introduced. {{{#!mo model test Real a(start = 1); Real b(start = 1); parameter Real p = 0; initial equation b = p * a; equation der(b) = 0; der(a) = 0; end test; }}} {{{ Warning: Assuming fixed start value for the following 1 variables: b:VARIABLE(start = 1.0 ) .test, .Real type: Real assert | debug | division by zero at time 0, (a=1) / (b=0), where divisor b expression is: p }}} In this example, an additional initial condition should get introduced for a instead of b." Lennart Ochel 2648 wrong simulation results for pulsed voltage source Run-time trunk Future defect Willi Braun accepted 2014-04-02T13:09:30Z 2017-11-14T22:08:53Z "Hi, the model Modelica.Electrical.Spice3.Sources.V_pulse which occurs for example in the Spice3.Inverter model is simulated wrongly. I put a tiny model in testsuite\simulation\modelica\functions_eval\pulseSource.mos Actually, there should be 3 voltage pulses during 1e-11 sec simulationtime but the omc outputs a constant voltage of 0. compareSimulationResults says ""Files Equal"" which is not true(maybe due to the very short pulses which occure in the tolerance of the event comparison) In fact, the events for the pulses are triggered correctly somehow because values for the time step back(!) at the points where the pulses should be. So there happens at least something but the time should not move backwards and the voltage should rise to 5V. " Volker Waurich 2685 Connector with record fails with code generation issues Code Generation trunk Future defect Mahder Alemseged Gebremedhin assigned 2014-05-07T09:17:53Z 2017-11-14T22:08:53Z "Hello everyone, working on some controller model omc fails to reduce the variables using pantelides. The error log is: Error: Too many equations - overconstrained system. The model has 8 equations and 4 variables. Error: Transformation Module PFPlusExt index Reduction Method Pantelides failed! Find attached an examplemodel. Unfortunately it is a bit complex therefore here is a short description. A Record (with integer for value and enumeration for datatype)is used as connector (input and output). within a block the value of the input changes to the output using an algorithm (simplification is done here!). If you need further information with the model, let me know. " Adrian Pop 2734 numeric evaluation of expressions in the symbolic pre-processing Frontend trunk Future defect somebody new 2014-06-23T09:11:15Z 2017-11-14T22:08:53Z "There are a lot of simplification rules, e.g. in ExpressionSimplify, that introduce numeric weaknesses. Just a few examples: {{{ 1/3 -> 0.3333333333333333 sqrt(2) -> 1.414213562373095 sin(2*1.23456) = 2*sin(1.23456)*cos(1.23456) -> 0.6229222061594161 = 0.6229222061594162 }}} I think the symbolic pre-processing should not evaluate any expression numerically. Any comments? " Lennart Ochel 2870 Non-linear solver is unable to handle HeatingSystem (msl32) properly Run-time trunk Future defect Willi Braun new 2014-10-07T10:03:28Z 2017-11-14T22:08:53Z "The non-linear solver is not able to proper handle a system of HeatingSystem (msl32). {{{ Modelica.Fluid.Examples.HeatingSystem }}} It produces tons of warnings but does not fail: {{{ stdout | warning | While solving non-linear system an assertion failed during initialization. | | | | | The non-linear solver tries to solve the problem that could take some time. | | | | | It could help to provide better start-values for the iteration variables. | | | | | For more information simulate with -lv LOG_NLS stdout | warning | While solving non-linear system an assertion failed at time 0. | | | | | The non-linear solver tries to solve the problem that could take some time. | | | | | It could help to provide better start-values for the iteration variables. | | | | | For more information simulate with -lv LOG_NLS stdout | warning | While solving non-linear system an assertion failed at time 0. | | | | | The non-linear solver tries to solve the problem that could take some time. | | | | | It could help to provide better start-values for the iteration variables. | | | | | For more information simulate with -lv LOG_NLS stdout | warning | While solving non-linear system an assertion failed at time 0.012. | | | | | The non-linear solver tries to solve the problem that could take some time. | | | | | It could help to provide better start-values for the iteration variables. | | | | | For more information simulate with -lv LOG_NLS stdout | warning | While solving non-linear system an assertion failed at time 0.012. | | | | | The non-linear solver tries to solve the problem that could take some time. | | | | | It could help to provide better start-values for the iteration variables. | | | | | For more information simulate with -lv LOG_NLS [...] }}}" Lennart Ochel 2946 events are treated badly Run-time trunk Future defect somebody new 2014-10-31T14:19:39Z 2017-11-14T22:08:53Z "I attached four models to show why OpenModelica treats events badly: {{{#!mo model test1 parameter Real p = 1.5; Real t = if time < p then time else p; Boolean d = t > p and t >= p; Boolean e; algorithm e := true; if t > p then e := false; end if; annotation(experiment(StartTime = 0, StopTime = 3)); end test1; }}} {{{test2}}} is equal to {{{test1}}} but without variable d. {{{test3}}} is equal to {{{test1}}} but with {{{if t > p then}}} as condition in the algorithm section. {{{test4}}} is equal to {{{test3}}} but without variable d. I attached also the simulation results of OpenModelica and Dymola for variable e of all four examples. I think Dymola handles the examples correctly. OpenModelica handles at least the first three examples different." Lennart Ochel 3389 make [dist]clean broken Build Environment trunk Future defect Martin Sjölund new 2015-07-24T13:44:26Z 2015-07-24T15:36:08Z I've been trying to switch compilers for the OMC sub project in a checked out git tree (last pull on July 23rd). It seems that issuing a make clean or make distclean does not properly clean all directories and dependencies, neither in the super project nor in the OMCompiler project. Some 3rd party packages are not cleaned properly and it seems that some CMake cache files still exist that prevent the new compiler from actually being changed. That is a pain and consumes a lot of time, since the build might succeed but the linking of models fails due to dependencies pulled in by runtime libraries still being built with the old compiler. In this state, the build system is unusable. joseph.schuchart@… 3399 Add more granularity to function evaluation Frontend trunk Future defect somebody new 2015-08-07T10:17:51Z 2017-11-14T22:08:53Z "Currently, we have -d=gen and -d=evalFunc to control how to evaluate functions at compile-time. We need some additional granularity. A good default would be: * Interpret functions whenever * Compile+dynamically load functions only as a fall-back when calling a function from the scripting interface I propose an enumeration flag: `--functionEvaluation=default|interpret|dynload|interpretDynload` A string list flag could also be used, but this one I expect would be checked a lot during runtime and integer comparison is cheaper. Any comments?" Martin Sjölund 3510 inline function *unknown* Future defect Willi Braun assigned 2015-10-14T10:09:43Z 2016-03-23T09:53:49Z "OM generate for the following example: {{{#!modelica model foo function f input Real x; output Real y; protected Real tmp1; Real tmp2; algorithm tmp1 := sin(x) + 1 + 2 + 3 + 4 + 5; tmp2 := cos(tmp1) * tmp1 - tmp1; y := exp(tmp1 * tmp2) + abs(tmp1); annotation(Inline = true); end f; Real y = f(time ^ 2); end foo; }}} the following code: {{{#!modelica y = exp((15.0 + sin(time ^ 2.0)) * (cos(15.0 + sin(time ^ 2.0)) * (15.0 + sin(time ^ 2.0)) - (15.0 + sin(time ^ 2.0)))) + abs(15.0 + sin(time ^ 2.0)) }}} The tmp-vars are removed. (probaly losing a lot of speed) In the spec. p. 214 we find: ''If “Inline = true”, the model developer proposes to inline the function. This means, that the body of the function is included at all places where the function is called.'' expectation code with function body: {{{ #!modelica model foo Real f_x_1 = time ^ 2; Real f_tmp1_1 = sin(f_x_1) + 1 + 2 + 3 + 4 + 5; Real f_tmp2_1 = cos(f_tmp1_1) * f_tmp1_1- f_tmp1_1; Real f_y_1 = exp(f_tmp1_1* f_tmp2_1) + abs(f_tmp1_1); Real y = f_y_1; end foo; }}} " Vitalij Ruge 3792 Variable override not working with restart Run-time Future defect Lennart Ochel accepted 2016-03-23T15:11:31Z 2019-04-18T09:34:00Z "I tried this on an old version and it used to work, but got broken at some point. I haven't tried it with -overrideFile, but it may have the same issue. {{{ loadString("" model restartOverrideBug parameter Real a = 1; Real x(start=1); Real y; equation y = der(x); der(y) = a * x; end restartOverrideBug; ""); getErrorString(); // Standard run: returns a=1 simulate(restartOverrideBug, simflags=""-output a,y""); // Restart without override: returns a=1 simulate(restartOverrideBug, simflags=""-r=tmp.mat -iit=1.0 -iif=restartOverrideBug_res.mat -iim=none -output a,y""); // Restart with override gives the same answer: returns a=1 (incorrect) simulate(restartOverrideBug, simflags=""-r=tmp.mat -iit=1.0 -iif=restartOverrideBug_res.mat -iim=none -output a,y -override a=2""); // No restart, but with override: returns a=2 (correct override) simulate(restartOverrideBug, simflags=""-r=tmp.mat -output a,y -override a=2""); }}}" crupp@… 3857 Error in Generated XML from Modelica Code Generation Future defect Adrian Pop accepted 2016-04-18T14:29:03Z 2016-08-05T14:09:16Z "Hi there, I am using the XML file generated by Modelica for modeling. I am getting the following error in the format each time- In bouncing ball, line 162 of generated xml file, <'''eq''': Equation> is generated within the , whereas it should be <'''equ''': Equation> as per the schema. Please let me know how/ when this can be resolved. I have attached the modelica model and the generated xml file." karan.singh@… 3937 ScalableTestSuite...OneGeneratorStepLoad fails for IDA solver Run-time Future defect somebody new 2016-05-28T10:06:50Z 2017-11-14T22:08:53Z "ScalableTestSuite.Power.ConceptualPowerSystem.Verification.OneGeneratorStepLoad fails since run of ScalableTestSuite on 2016-05-25 (was OK on 2016-05-22) Error message in simulation is: {{{ stdout | info | Maximum number of event iterations changed to 400 *** Error in `./ScalableTestSuite.Power.ConceptualPowerSystem.Verification.OneGeneratorStepLoad': realloc(): invalid old size: 0x00000000011d89a0 *** Aborted }}} " Henning Kiel 4131 Superfluous variables and parameters are part of the simulation Backend Future defect Lennart Ochel new 2016-11-09T13:57:12Z 2016-11-09T13:57:12Z "The backend does not remove evaluated parameters from the simcode, keeping these variables as allocated. These parameters (possibly also variables?) are only needed for writing the simulation result file and should be stored separate from the parameters/vars arrays. This would give us better data locality and for targets using -noemit (real-time / embedded simulations), it would also make the memory smaller. I just tried to evaluate all parameters when targeting AVR and got more variables stored than before (even though 0 of the 47 parameters were referenced in the simulation). Similarly, algebraic non-output variables might not be interesting and should be possible to optimize away since they only take up space and computations. (Unused parameters are similar)" Martin Sjölund 4221 OmOptim crashes after model selection OMOptim v1.11.0 Future defect Hubert Thieriot new 2017-01-19T16:53:04Z 2019-12-02T10:10:48Z "OMOptim is still not usable. 1) Start OMOptim 2) Load Modelica 3) Load Model (.mo) - I load some of my models 4) Select problem - optimization Crash! Win 8.1, 64b" filip.jezek@… 4502 Comparison fails for enumerations wrapped in uniontypes MetaModelica Future defect Martin Sjölund new 2017-08-18T13:56:22Z 2018-01-08T09:19:41Z "See the attached script, which simply wraps an enumeration in a uniontype and then tries to compare it. The expected output is: {{{ f: E.one f: E.two f: E.three }}} The actual output if no extra flags are given is: {{{ f: f: }}} The bigger issue though is that when code generation is forced on with '-d=noevalfunc,gen', representing what happens if you try to do something like this in the compiler, the output becomes: {{{ f: E.two f: f: }}} If the function is rewritten to use a match instead: {{{#!mo function f input UT ut; protected String s; algorithm print(""f: ""); s := match ut.e case E.one then ""E.one""; case E.two then ""E.two""; case E.three then ""E.three""; end match; print(s + ""\n""); end f; }}} then it behaves correctly when code generation is forced on but still gives the same output when using interpretation." Per Östlund 4674 Wrong return values for getParameterValue for inherited classes Interactive Environment Future defect somebody new 2017-12-12T14:05:56Z 2018-02-01T17:20:57Z "For this model {{{#!mo package ParameterExtendsTest model BaseRecord parameter Real a = 1; parameter Real b = 1; parameter Real c = 1; annotation (Icon(coordinateSystem(preserveAspectRatio=false)), Diagram(coordinateSystem( preserveAspectRatio=false))); end BaseRecord; model SpecialRecord extends ParameterExtendsTest.BaseRecord( a = 2.1, b = 4.1, c = 8.1); extends ParameterExtendsTest.Base2(d = 16.1); parameter Real e = 32.1; annotation (Icon(coordinateSystem(preserveAspectRatio=false)), Diagram(coordinateSystem( preserveAspectRatio=false))); end SpecialRecord; model Base2 parameter Real d = 1; annotation (Icon(coordinateSystem(preserveAspectRatio=false)), Diagram(coordinateSystem( preserveAspectRatio=false))); end Base2; end ParameterExtendsTest; }}} The OpenModelica API call for getting a parameter value returns not the overwritten value from the extended model {{{#!mo classes:= getInheritedClasses(ParameterExtendsTest.SpecialRecord);getErrorString(); for i in 1:size(classes,1) loop params := getParameterNames(classes[i]);getErrorString(); for j in 1:size(params,1) loop print(""parameter = ""+params[j]+ "" value="" +getParameterValue(classes[i],params[j]) +""\n""); end for; end for; }}} the output is: parameter = a value=1 parameter = b value=1 parameter = c value=1 parameter = d value=1 for {{{#!mo params:= getParameterNames(ParameterExtendsTest.SpecialRecord);getErrorString(); for i in 1:size(params,1) loop print(""parameter = ""+params[i]+ "" value="" +getParameterValue(ParameterExtendsTest.SpecialRecord,params[i]) +""\n""); end for; }}} it only returns: parameter = e value=32.1 But we expect: parameter = a value=2.1 parameter = b value=4.1 parameter = c value=8.1 parameter = d value=16.1 parameter = e value=32.1 " Niklas Worschech 4957 Inefficient code generated for record derivatives Code Generation v1.13.0-dev-nightly Future defect Lennart Ochel new 2018-05-28T11:36:03Z 2018-05-28T11:38:46Z "The backend generates very inefficent code in some cases involving records, for example in {{{ScalableTestSuite.Thermal.Advection.ScaledExperiments.SteamPipe_N_10}}} (and presumably any model using the same parts of Modelica.Media). Looking at the {{{omc_$DER$Modelica$PMedia$PWater$PIF97__Utilities$PwaterBaseProp__ph}}} function in the {{{_functions.c}}} file for example, there's a line in the Modelica code that looks like: {{{#!mo g := Modelica.Media.Water.IF97_Utilities.BaseIF97.Basic.g1(p, aux.T); }}} This is translated into the following C-code (line 6213 for me): {{{#!c tmp1 = omc_Modelica_Media_Water_IF97__Utilities_BaseIF97_Basic_g1(threadData, _p, _aux._T); _g._p = tmp1._p; _g._T = tmp1._T; _g._R = tmp1._R; _g._pi = tmp1._pi; _g._tau = tmp1._tau; _g._g = tmp1._g; _g._gpi = tmp1._gpi; _g._gpipi = tmp1._gpipi; _g._gtau = tmp1._gtau; _g._gtautau = tmp1._gtautau; _g._gtaupi = tmp1._gtaupi; }}} Assigning each field of {{{_g}}} separately is a bit weird but might be necessary for all I know, but at least it only calls the functions once. Immediately following this is the following code though (I've shortened the identifiers in the code to make it readable, the actual C-code is much larger): {{{#!c $funDERg._p = omc_$DER$g1(threadData, _p, _aux._T, $funDERp, $funDERaux._T)._p; $funDERg._T = omc_$DER$g1(threadData, _p, _aux._T, $funDERp, $funDERaux._T)._T; $funDERg._R = omc_$DER$g1(threadData, _p, _aux._T, $funDERp, $funDERaux._T)._R; $funDERg._pi = omc_$DER$g1(threadData, _p, _aux._T, $funDERp, $funDERaux._T)._pi; $funDERg._tau = omc_$DER$g1(threadData, _p, _aux._T, $funDERp, $funDERaux._T)._tau; $funDERg._g = omc_$DER$g1(threadData, _p, _aux._T, $funDERp, $funDERaux._T)._g; $funDERg._gpi = omc_$DER$g1(threadData, _p, _aux._T, $funDERp, $funDERaux._T)._gpi; $funDERg._gpipi = omc_$DER$g1(threadData, _p, _aux._T, $funDERp, $funDERaux._T)._gpipi; $funDERg._gtau = omc_$DER$g1(threadData, _p, _aux._T, $funDERp, $funDERaux._T)._gtau; $funDERg._gtautau = omc_$DER$g1(threadData, _p, _aux._T, $funDERp, $funDERaux._T)._gtautau; $funDERg._gtaupi = omc_$DER$g1(threadData, _p, _aux._T, $funDERp, $funDERaux._T)._gtaupi; }}} It seems like this is calculating some kind of derivative of {{{g}}}, but it does so by calling the {{{omc_$DER$g1}}} function once for each record field. This pattern is repeated all over the generated code, causing a huge amount of unnecessary function calls. And at least {{{g1}}} is quite large and expensive to call, so optimizing this to only call the function once would probably improve the simulation performance quite a bit for models like this." Per Östlund 5109 Nightly build 9/7/2018 installer issue Installation program v1.13.0-dev-nightly Future defect Adeel Asghar new 2018-09-07T16:15:18Z 2018-09-07T21:15:34Z "Hello, I used the ""OpenModelica-latest.exe"" of 9/7/2018 to install the nightly build. I let the installer uninstall the existing OpenModelica version. I am not sure if it was the installer or my computer, but the installer started uninstalling various programs besides OpenModelica such as MATLAB and Solidworks." anonymous 5148 Changes of integer input of FMU are ignored Backend v1.13.0-dev-nightly Future defect Lennart Ochel new 2018-10-02T15:06:16Z 2018-10-25T14:38:22Z "When simulating an FMU with an integer input that should trigger `when` condition in `algorithm` block, changes are ignored but the input is passed through correctly. == How to reproduce == TestInt.mo: {{{ #!modelica model TestInt input Integer inInt; output Integer outInt; output Integer passthrough; initial equation outInt = 0; algorithm when inInt > pre(inInt) then outInt := outInt + 1; end when; equation passthrough = inInt; end TestInt; }}} TestInt.mos: {{{ #!modelica print(buildModelFMU(TestInt, ""1.0"", ""me"")); print(getErrorString()); }}} input.csv: {{{ time;inInt 0.0;0 0.7;1 0.8;2 }}} Compile it with {{{ $ omc TestInt.mos TestInt.mo /home/trosinenko/TestInt.fmu $ ... }}} Simulate with FMUChecker (tested with 2.0.3): {{{ $ path/to/fmuCheck.linux64 -i input.csv TestInt.fmu [INFO][FMUCHK] FMI compliance checker Test [FMILibrary: Test] build date: Dec 19 2016 [INFO][FMUCHK] Called with following options: [INFO][FMUCHK] /path/to/fmuCheck.linux64 -i input.csv TestInt.fmu [INFO][FMUCHK] Will process FMU TestInt.fmu [INFO][FMILIB] XML specifies FMI standard version 1.0 [INFO][FMUCHK] Model name: TestInt [INFO][FMUCHK] Model identifier: TestInt [INFO][FMUCHK] Model GUID: {344d6ea1-babe-4fab-a4f1-a7a6ef710740} [INFO][FMUCHK] Model version: [INFO][FMUCHK] FMU kind: ModelExchange [INFO][FMUCHK] The FMU contains: 0 constants 0 parameters 3 discrete variables 1 continuous variables 1 inputs 2 outputs 1 internal variables 0 variables with causality 'none' 0 real variables 3 integer variables 0 enumeration variables 1 boolean variables 0 string variables [INFO][FMUCHK] Printing output file header ""time"",""outInt"",""passthrough"" [INFO][FMUCHK] Opening input file input.csv [INFO][FMUCHK] Detected separator character in input file: ; [INFO][FMILIB] Loading 'linux64' binary with 'standard32' platform types [INFO][FMUCHK] Version returned from FMU: 1.0 [INFO][FMUCHK] Initialized FMU for simulation starting at time 0 0.0000000000000000E+00,0,0 2.0000000000000000E-03,0,0 4.0000000000000001E-03,0,0 ... 7.9600000000000004E-01,0,1 7.9800000000000004E-01,0,1 8.0000000000000004E-01,0,2 8.0200000000000005E-01,0,2 ... 9.9600000000000022E-01,0,2 9.9800000000000022E-01,0,2 1.0000000000000000E+00,0,2 [INFO][FMUCHK] Simulation finished successfully at time 1 FMU check summary: FMU reported: 0 warning(s) and error(s) Checker reported: 0 Warning(s) 0 Error(s) }}} Changing line {{{ #!modelica when inInt > pre(inInt) then }}} to {{{ #!modelica when change(inInt) then }}} does not change behavior." anatoly.trosinenko@… 5263 [FMI] FMUs are linked with libModelicaExternalC compiled as a dynamic library Build Environment Future defect Martin Sjölund new 2019-01-07T16:30:18Z 2019-03-29T06:08:07Z If one uses Noise or Random (I guess tables also) models from MSL the C runtime FMUs will get linked with libModelicaExternalC.so which means that the FMU is not static / standalone. Adrian Pop 5612 OMPython fails to load model in enhanced mode due to ValueError OMPython v1.13.2 Future defect Alachew Mengist new 2019-08-02T11:56:40Z 2019-08-02T11:56:40Z "Hey, OMPython throws a {{{ValueError}}} exception when I try to load a modelica model with tables (CombiTimeTable, CombiTable1d) in it. This is thrown in the {{{__init__.py}}}. The code tries to parse the parameters where name is None and the else-clause defaults to convert to float. But some parameters with name None are like filename of the tables mentioned. (are those parameters implicitly generated? More likely it's a problem because I import those tables into my model...) I fixed it for myself by catching the exception and converting to string instead. I attached the code beginning from line 1094... Thanks for your support!! {{{ def __getParameterValues(self, paraName=None): """""" This method returns list of values of the quantities name that are parameters. It can be called: •without any arguments: return list of values of all quantities (parameter) name •with a single argument as parameter name in string format: returns value of the corresponding name •with a single argument as list of parameter names in string format: return list of values of the corresponding names. 1.If the list of names is more than one and it is being assigned by single variable then it returns the list of values of the corresponding names 2.If the list of names is more than one and it is being assigned by same number of variable as the number of element in the list then it will return the value to the variables correspondingly (python unpacking) """""" if paraName is None: if not self.pValuesList: for l in self.quantitiesList: if (l.variability == ""parameter""): str_ = l.start if ((str_ is None) or (str_ == 'true' or str_ == 'false')): if (str_ == 'true'): str_ = True elif str_ == 'false': str_ = False self.pValuesList.append(str_) else: try: self.pValuesList.append(float(str_)) #HOTFIX BAM except ValueError: self.pValuesList.append(str(str_)) #HOTFIX BAM return self.pValuesList }}} " Markus.Bauer@… 5748 FMU crashing matlab FMI v1.14.0 Future defect Lennart Ochel new 2019-12-16T06:51:49Z 2019-12-23T04:25:50Z any fmu model created in openmodelica using the latest stable release immediately crashes as soon as i simulate in matlab. using matlab r2019a. akhilnavasofficial@… 5888 Record's inheritance OMSimulator v1.14.1 Future defect Lennart Ochel new 2020-03-11T11:35:07Z 2020-03-11T11:35:07Z "Hey guys. There is some problem with records in OM v. 14 (and latest versions have same bug) You could see it very easy: just try to simulate any example (except first one) from system lybrary ""ElectricalEnergyStorage"". You'll get a critical message about some missing values in parameters. But they're not missed, it works fine in 13.2. As I see it — for some reason OM can't use default values of parameters in records when you don't give them in ""()"". I hope you could manage to fix this in next version. Thanks for your work! " AtaC29@… 1177 Redesign and set up restrictions for simplication of expressions *unknown* Future discussion Peter Aronsson new 2010-03-01T13:52:11Z 2017-10-12T22:46:18Z "Simplification of expressions can lead to numerical problems. For instance a/b/c can if rewritten to a/(b*c) lead to overflow and loss of precision. There is therefore a need to set up some rules and restrictions on what simplifications can be allowed. Also, the simplifier should probably not succeed and change an expression if it is not ""more simple"". The reason being that the modeller probably knows best and if he writes a/b/c instead of a/(b*c) he might have a good reason for it." Peter Aronsson 4330 Split OMEdit from systems librarys and introduce a library download manager Third-Party Libraries Future enhancement Martin Sjölund new 2017-03-16T19:16:33Z 2017-09-07T16:25:17Z "I realized that every OM nightbuild always includeds over 900MB of libraries! Thus the download is very big (~1GB) and will consume a lot space on your servers. Isn't it possible to split both things and offer (1) a '''slim version''' with OMEdit, MSL, OMPLot... (about 150MB) and (2) a '''library download manager''' which installs the libraries (about 900MB) on request. This has two benefits: 1.) Users who want to check out the latest OMEdit nightlybuild improvements don't need to (re)install 900MB of libraries. 2.) Users who want to check out the latest version of a library can use the library download manager and do not need to reinstall OpenModelica at all. As an addition, when OMEdit (slim version) starts for the first time the library download manager could pop up automatically to show the comprehensive library extent." Jan Kokert 6006 Migrate this Trac to Github *unknown* Future task somebody new 2020-06-13T20:32:41Z 2020-06-14T14:01:25Z "We should migrate the Trac to github. That is issues, milestones, components. The PRs we have now in Github are reaching close to 1000 so it would be good to do this asap as the tickets 146-1000 in Trac are dummy tickets. The tickets 1-146 can be moved after the last ticket, #6006 currently. I suggest we bring this up in the OSMC board meeting. There are some migrator tools available that we might be able to use." Adrian Pop 6367 Avoid C compilation bottleneck in OMC Code Generation 1.16.0 NeedsInput defect Martin Sjölund assigned 2021-02-05T19:04:10Z 2021-02-07T18:45:51Z "Comparing [https://libraries.openmodelica.org/branches/master/ScalableTestSuite/ScalableTestSuite.html ScalableTestSuite] and [https://libraries.openmodelica.org/branches/master/ScalableTestSuite_noopt/ScalableTestSuite_noopt.html ScalableTestSuite_noopt] it seems that the simulation may be 20-30% slower using {{{-O0}}} instead of {{{-Os}}}, but the C compilation time may be 3-4 times faster. This issue was already discussed in #4033 and #4879. Bottom line: there is no need to completely disable optimization, thus introducing an unnecessary trade-off. What is needed is - use the {{{OMC_DISABLE_OPT}}} macro to tell the compiler which functions should not be optimized. Basically, the ones involved in initialization (which are only executed a few times) should be marked with this macro - split the jac.c and nls.c files, so that they can be compiled in parallel Apparently, some code was added after #4879 was closed without the appropriate {{{OMC_DISABLE_OPT}}} macro that made it slow again. The examples attached to #6271 and the larger test cases in the ScalableTestSuite can be used as benchmarks. @sjoelund.se just opened [https://github.com/OpenModelica/OpenModelica/pull/7133 PR 7133] and [https://github.com/OpenModelica/OpenModelica/pull/7134 PR 7134] to improve things. I expect to see the two above-mentioned test reports to show similar C-code compilation time after the PRs are merged." Francesco Casella 1667 OMEdit does not have an interface to add custom directories for libraries OMEdit defect Martin Sjölund accepted 2011-12-05T10:53:58Z 2021-09-13T11:58:21Z The default is given by getModelicaPath(), but a user should be able to set additional directories to search. Martin Sjölund 1816 Fix getNthInheritedClass API Interactive Environment defect Adrian Pop assigned 2012-09-17T10:45:01Z 2021-09-13T11:58:21Z "The API call, {{{ #!div style=""font-size: 80%"" {{{#!python getNthInheritedClass(Modelica.Media.Interfaces.TemplateMedium.BaseProperties,1) }}} }}} Returns, {{{ #!div style=""font-size: 80%"" {{{#!python Modelica.Media.Interfaces.TemplateMedium.BaseProperties }}} }}} The API call should return, {{{ #!div style=""font-size: 80%"" {{{#!python Modelica.Media.Interfaces.PartialMedium.BaseProperties }}} }}}" Adeel Asghar 1931 Do not scalarize vector equations Frontend defect Jens Frenkel assigned 2012-11-08T08:07:55Z 2021-09-13T11:58:21Z "We should not scalarize equations, so we can reduce the number of function calls performed (here f is called once for each element in the matrix): {{{ model M function f input Real r1,r2; output Real o[2] := {r1,r2}; end f; Real rtime = time; Real r[:,:](each start = 1.5) = f(rtime,2:3); end M; model N M m; end N; }}} With a better frontend, we can generate this flat code: {{{ function M.f input Real r1; input Real r2; output Real[2] o = {r1, r2}; end M.f; class N Real m.rtime = time; Real m.r[1,1](start = 1.5); Real m.r[1,2](start = 1.5); Real m.r[2,1](start = 1.5); Real m.r[2,2](start = 1.5); equation m.r = {M.f(m.rtime, 2.0), M.f(m.rtime, 3.0)}; end N; }}}" Martin Sjölund 2122 Save API doesn't handle multiple classes Interactive Environment trunk defect Adeel Asghar assigned 2013-03-14T22:37:09Z 2021-09-13T11:58:21Z If a file contains several classes then calling a save API on one of these classes only save the file with this class and remove the other classes. Adeel Asghar 2292 wrong generated C code Backend trunk defect Lennart Ochel assigned 2013-07-29T09:42:21Z 2021-09-13T11:58:21Z "The compiler generate the wrong code for the following the algorithm, {{{ temper[i]:=17 + temper[i]; }}} The following C code is generated, {{{ real_array_create(&tmp0, ((modelica_real*)&($Ptemper)), 1, 10); (*real_array_element_addr(&$Ptemper, 1, (modelica_integer)$Pi)) = (17.0 + (*real_array_element_addr(&tmp0, 1, (modelica_integer)$Pi))); }}} I believe it should be, {{{ real_array_create(&tmp0, ((modelica_real*)&($Ptemper)), 1, 10); (*real_array_element_addr(&tmp0, 1, (modelica_integer)$Pi)) = (17.0 + (*real_array_element_addr(&tmp0, 1, (modelica_integer)$Pi))); }}} On the left hand side we should use &tmp0 instead of &$Ptemper. The simulation executable segfaults. The complete model is attached." Adeel Asghar 2520 model including two SpringDamper blocks leads to compiler error Backend trunk defect Karim Adbdelhak assigned 2013-12-17T09:09:23Z 2021-09-13T11:58:21Z "The attached model DamperBug1 terminates with the following error: Simulation process exited with code 253 Changing one of the SpringDamper blocks to a Spring works (cf. example DamperBug3). " Peter Junglas 2750 Units of derivatives in the variables browser Code Generation trunk defect Mahder Alemseged Gebremedhin assigned 2014-07-11T14:54:10Z 2021-09-13T11:58:21Z "Currently, if a certain variable v has the attribute unit = ""u"", then also its time derivative is displayed with the same unit ""u"". Of course it should be ""u/s""." Francesco Casella 3111 Convergence issues on nonlinear equations involving der() Backend trunk defect Willi Braun accepted 2015-01-29T11:39:00Z 2021-09-13T11:58:21Z "The nonlinear solver makes an excessively large number of iterations in some test cases where derivatives are involved as iteration variables (see, e.g., {{{ThermoPower.Examples.CISE.CISESim120501}}} or {{{ThermoPower.Test.DistributedParameterComponents.TestWaterFlow1DFEM_A}}}). In some cases involving external medium models, the solver actually fails to converge after a large number of iterations (over 1700). A workaround for this problem has been implemented, which adds alias algebraic variables equal to the derivatives and uses them as iteration variables. It can be turned on with the debug flag {{{+d=addDerAliases}}}. Unfortunately, it breaks some models in the testsuite, but it is very beneficial in the above-mentioned test cases. The problem still needs to be thoroughly assessed and solved in general. One interesting question is: what is the correct scaling factor for der(x)? Obviously, the nominal value of x is not necessarily good, because the magnitude of dx/dt also depends on how fast the variable changes. One possible option during variable step size integration is to use x_nominal/current_step_length. If the step length is short, it is likely that the variables are changing fast (possibly very fast if initial state values are given far from equilibrium), so it is reasonable to use a larger scaling factor. When the step length gets longer because the system is close to equilibrium, smaller values are employed. The main limitation of this approach is that it consider one time scale for the entire system, while an appropriate time scale should be selected for each single derivative. Also, it is not clear which value to use at initialization. Another idea could be to employ an adaptive approach: if one can detect that the convergence is hampered by the effect of very small changes of some der() variables, their scaling factor could be reduced by a factor of 10 or something like that." Francesco Casella 3116 Make warning/error message from the nonlinear solver more informative Backend trunk defect somebody new 2015-01-29T21:53:22Z 2021-09-13T11:58:21Z "When simulating the {{{ThermoPower.Examples.CISE.CISESim120501}}} example using OMEdit, a lot of red warning messages pop up, saying: - Matrix singular! - under-determined linear system not solvable! - Warning: maximal number of iteration reached but no root found These messages succeed in conveying the message that something goes wrong with the solver and scaring off the user. However, when it comes to try to understand the cause of the problem and fix it, these messages leave the poor user utterly clueless. I would definitely suggest to make these messages a bit more informative, e.g. by adding the number of the system that becomes singular, possibly with a direct link to the declarative debugger (Debug more!), or writing ''which'' matrix exactly has singularity problems and how can one understand why it is so (nullspace, rank, etc). This will give users a chance of understanding the cause of the problem and hopefully fix it. Otherwise, troubleshooting the model would require supernatural divination abilities that few people (if any) in the community possess :)" Francesco Casella 3118 Convergence issues on nonlinear equations not involving der() Backend trunk defect Willi Braun accepted 2015-01-29T23:09:00Z 2021-09-13T11:58:21Z "Please consider the {{{ThermoPower.Test.WaterComponents.TestValves}}}. It takes 11 seconds to simulate in OMC and 0.12 seconds in Dymola, with {{{+cseCall}}} active. Turning on {{{LOG_NLS_V}}} reveals the following behaviour: - at time 3.0000 the NLS requires 137 iterations to converge, which probably points to badly chosen scaling factors or tolerances - the main solver takes a step to 3.008 - the NLS now tries for 147 iterations, then it keeps trying doing other things for a long time, then eventually gives up - the main solver steps back to 3.00000004, NLS converges quickly - the main solver steps to 3.008, this time the convergence is very fast - the simulation proceeds normally Bottom line 1: at time 3.000 there are probably too many iterations. Bottom line 2: the first attempt at time 3.008 should have probably been aborted earlier, retrying a shorter step." Francesco Casella 3572 Clarifications in the Compiler Flag Documentation *unknown* defect Lennart Ochel accepted 2015-11-20T22:27:56Z 2021-09-13T11:58:21Z "The web page https://openmodelica.org/doc/OpenModelicaUsersGuide/latest/omchelptext.html lists all compiler flags, and is automatically generated from omc help info. The situation has improved dramatically once #2913 was addressed. However, there are four things that still need to be fixed. 1. The documentation gives {{{-d}}} and {{{--debug}}} as debug flags. However, in the page there are still three references to {{{+d}}}, which are very confusing because it is not clear whether that is a separate flag with different effects or not. Please always use the same notation {{{-d}}} everywhere. You may also mention in the documentation that the {{{+d}}} notation is deprecated but can still be found in existing code 2. The documentation https://openmodelica.org/doc/OpenModelicaUsersGuide/latest/omchelptext.html#omcflag-debug-section explains how to set up the {{{-d}}} flag. However, there are no examples. I would suggest to add one or two, and at least one where multiple flags are set and some are reset, for better clarity. 3. The documentation of {{{--preOptModules}}}, {{{--initOptModules}}} and {{{--postOptModules}}} does not contain any example, so it is not clear how one can actually set the options that are listed there. I would suggest to add a couple of examples from which it is clear what the syntax is. 4. The new flags introduced in https://github.com/OpenModelica/OMCompiler/pull/282 are not documented at all, please add the documentation of {{{--forceRecommendedOrdering}}} and also add the documentation about {{{+=}}} and {{{-=}}} to {{{--preOptModules}}}, and {{{--postOptModules}}}. BTW, can this also be used with {{{--initOptModules}}}, or should a special section dedicated to flags used in {{{initOptModules}}} be also introduced in the documentation?" Francesco Casella 3592 Eigen values fails with error Code Generation v1.14.0-dev-nightly defect Karim Adbdelhak assigned 2015-12-11T01:01:27Z 2021-09-13T11:58:21Z "Using `Matrices.eigenValues` results in following error, {{{ [CodegenCFunctions.tpl: 4698:15-4698:15]: Template error: This should have been handled in indexed assign and should not have gotten here. eigenvalues[:,2] }}} Use the attached file. If a parameter prefix is added to `Real A` then it works fine." Adeel Asghar 3689 Missing warning for StateSelect.always Backend v1.9.4-dev-nightly defect Karim Adbdelhak reopened 2016-02-17T10:03:08Z 2021-09-13T11:58:21Z "The following model does not generate warnings, but should in fact produce errors: {{{#!mo model M Real level(start=0, fixed=true, stateSelect=StateSelect.always) = r; Real r=2.0; end M; }}}" Martin Sjölund 3781 Fix scaling of detectJacobianSparsePattern Backend v1.10.0-dev-nightly defect Karim Adbdelhak assigned 2016-03-20T10:32:33Z 2021-09-13T11:58:21Z "{{{#!mo loadString(""model M constant Integer n=10000; Real r[n](each start=0, each fixed=true); equation for i in 1:n loop der(r[i]) = i*time; end for; end M;"");getErrorString(); translateModel(M);getErrorString(); }}} n=1000 {{{ Notification: Performance of postOpt detectJacobianSparsePattern (simulation): time 0.1987/1.124, memory: 185.4 MB / 0.5414 GB Total time: 1.576, memory: 0.7237 GB }}} n=2000 {{{ Notification: Performance of postOpt detectJacobianSparsePattern (simulation): time 0.7653/2.696, memory: 0.6772 GB / 1.388 GB Total time: 3.595, memory: 1.816 GB }}} n=10000 {{{ Notification: Performance of postOpt detectJacobianSparsePattern (simulation): time 18.73/28.87, memory: 16.02 GB / 19.54 GB Total time: 34.7, memory: 24 GB }}} Seems to be `O(N^2)` memory/time in detectJacobianSparsePattern, which is taking >50% of translation time for larger models." Martin Sjölund 3843 Write .log file directly to disk Run-time defect somebody new 2016-04-12T13:29:21Z 2021-09-13T11:58:21Z "If I simulate {{{ThermoPower.Examples.CISE.CISESim120501}}} with OMC for Windows 64 bit with the following flags: {{{ setCommandLineOptions(""+cseCall +cseEachCall --tearingMethod=omcTearing --preOptModules+=introduceDerAlias --preOptModules-=clockPartitioning -d=dumpSimCode,nogen,initialization,backenddaeinfo,discreteinfo, stateselection""); getErrorString(); simulate(ThermoPower.Examples.CISE.CISESim120501, simflags = ""-lv LOG_STATS""); getErrorString(); }}} I get this message on the console: {{{ Error: File too large to fit into a MetaModelica string: ThermoPower.Examples.CISE.CISESim120501.log. }}} and the log file does not contain the log of the solver. These log files can become huge (hundreds of megabytes). This is no big deal, as long as they are written directly to file. Having access to this information can be crucial for debugging. Please make sure this date goes straight to mass storage without being stored in a MetaModelica string." Francesco Casella 3851 optimized zero crossings for cpp runtime Backend defect Willi Braun assigned 2016-04-15T12:20:00Z 2021-09-13T11:58:21Z "Thus the cpp runtime can use the optimized zero crossings, that are zero crossings which could arise from combined relations like {{{ ((h)<=0)&&(v<=0)) }}} additional information in the backend is needed. At the moment all relations have an index in the backend which is used in the cpp code generation to replace the relations with condition variables {{{ if(h<=0) }}} is replaced with {{{ if(condition_[index]) }}} To use the optimized zero crossings, expressions for lbinary and lunary also needs this index to replace e.g {{{ if(h<=0 && v<=0) }}} with {{{ if(condition_[index]) }}} during code generation" Niklas Worschech 3966 zero detection or array index error Run-time v1.9.4-v1.9.x defect somebody new 2016-06-17T13:07:10Z 2021-09-13T11:58:21Z "I needed a table which can be modified runtime. I have implemented the table with the x indices (x1) as parameters and the y indices (y1) as variables that can be changed during the simulation. The table is setup as a linear interpolation between index pair and 'hold' last value for out of range input. Input is variable u and output is y. Although the code in not very elegant, it runs correctly with a constant input for u but fails for a time varying input like a input form timetable or step input. I am not able to understand where the error (assert | error |

Dimension 1 has bounds 1..5, got array subscript 0

) is coming form. I am guessing it has to do with the index but not able to figure out from which one. attaching the simulation files." rahul.dutta.bits@… 4003 OMEdit uses wrong modelica:// path Interactive Environment defect Adrian Pop reopened 2016-07-16T09:02:35Z 2019-06-03T12:40:55Z "The model `PowerSystems.Examples.PowerWorld.PowerWorld` uses table data from a file. The respective code is: {{{#!mo constant String PowerWorldResources = Modelica.Utilities.Files.loadResource(""modelica://PowerSystems.Examples.PowerWorld/Resources/""); Modelica.Blocks.Sources.CombiTimeTable wind( tableName=""tab"", fileName=PowerWorldResources + ""LoadData.txt"", tableOnFile=true); }}} The model works when `omc` is called from the command line. It also works in the nightly tests. OMEdit raises the error: {{{ Not possible to open file ""LoadData.txt"": No such file or directory }}} " Rüdiger Franke 4041 Wrong structural singular equation system Backend defect somebody assigned 2016-09-14T05:11:43Z 2021-09-13T11:58:21Z "The current tunc release reports the following error for `PowerSystems.Examples.Spot.Introduction.SimulationSteadyInitial`: {{{ Error: Initialization problem is structurally singular, error found sorting equations 78: $DER.lineB.i[3] = 0.0; 75: $DER.lineL.i[3] = 0.0; 14: $DER.lineR.i[3] + $DER.lineB.i[3] - $DER.lineL.i[3] = 0.0; 72: $DER.lineR.i[3] = 0.0; for variables meter.i[1](63), voltageL.V(70), $DER.lineR.i[3](77), meter.i[3](61), transPh.y[2](72) }}} See https://test.openmodelica.org/libraries/PowerSystems/files/PowerSystems.Examples.Spot.Introduction.SimulationSteadyInitial.err The solution to the reported equations appears obvious, even though it is for some reason overdetermined: all involved variables are zero. Why does OpenModelica report a structural singular equation system? Note 1: the model was working until August 29, see: https://test.openmodelica.org/libraries/history/PowerSystems/PowerSystems-2016-08-29.html The PowerSystems library changed around that time with the introduction of an enumeration for initialization options, replacing Booleans, see: https://github.com/modelica/PowerSystems/commit/7a8310bc7d36daee96538c4b0da4634d4a43343d Note 2: the AC3ph models use the dq0 representation. The third coordinate is zero unless there is an unsymmetry between the three phases. Many models are symmetric by definition: sources assign 0.0 to variables of the third coordinate; component models pass the 0.0 through and never mix the third 0-coordinate with the d- or the q-coordinate. Can't OpenModelica generally eliminate resulting equation systems with the rhs all zeros? " Rüdiger Franke 4080 Simulation success is depending on number of intervals Run-time defect Willi Braun assigned 2016-10-18T14:42:02Z 2021-09-13T11:58:21Z "Consider the attached inverter simulation model. * start time = 0 s * stop time = 0.3 s * number of intervals = 29997 The simulation is then not completed successfully. After changing the number of intervals to 30000 the simulation succeeds. The issue occurs with OpenModelica 1.11.0~dev-153-g45ed062 Connected to OpenModelica 1.11.0~dev-270-gd13b6b0 and previous versions. " Christian Kral 4085 OMEdit cross-compilation missing options OMEdit defect Adeel Asghar new 2016-10-20T05:38:11Z 2021-09-13T11:58:21Z "OMEdit lists options for cross-compilation based on which compilers it finds in the path, which works great for most architectures. However, one of the common cases would be amd64 cross-compiling to i386, and for this there is no cross-compiler needed (gcc compiles for both architectures). I propose to not have any special regex for this and just list `i686-linux-gnu` if `x86_64-linux-gnu` is available. And list `x86_64-linux-gnu` if `i?86-linux-gnu` is available." Martin Sjölund 4118 removeSimpleEquation failed Backend defect Lennart Ochel new 2016-10-29T18:57:30Z 2021-09-13T11:58:21Z "{{{#!modelica model foo function f input Real[2] x; output Real[2] y; output Real[2] z; algorithm y[1] := 2*x[1]^2 + 1; y[2] := 3*x[2]^3 + 2; z[1] := -y[1]/2+1/2+7; z[2] := -y[2]/3+2/3-7; end f; Real[2] y(each start = -1); Real[2] w(each start = -1); Real z1, z2, z3; equation (, w) = f({y[1] + z3, y[2]}); der(w) = f({y[1] + z3, y[2]}); der(y[1]) = -z1*y[2] +1; der(y[2]) = -z2*y[1] + z1*y[2] +3; z3 = time; end foo; }}} failed with {{{#!bash [/home/vruge/OM/OMCompiler/Compiler/Util/BaseHashTable.mo:119:5-119:104:writable] Error: Internal error Got internal hash table size 0 <1 Error: post-optimization module removeSimpleEquations (simulation) failed. }}}" Vitalij Ruge 4129 Inefficient array code generation Backend defect Lennart Ochel new 2016-11-05T12:38:59Z 2021-09-13T11:58:21Z "See the following example that just was added to the testsuite: {{{#!mo model AliasArrayTest Real[3,3] A = {{t, 2, 3}, {4, t, 6}, {7, 8, t}}; // RefArrayDim2 Real[:] b = (t + 1) * {1, 2, 3}; Real t = time; output Real[3] x; equation x = Modelica.Math.Matrices.solve(A, b); annotation(experiment(StopTime = 0)); end AliasArrayTest; }}} OpenModelica generates very inefficient simcode: {{{#!mo x[1] = Modelica.Math.Matrices.solve({{A[3,3], 2.0, 3.0}, {4.0, A[3,3], 6.0}, {7.0, 8.0, A[3,3]}}, {b[1], b[2], b[3]})[1]; x[2] = Modelica.Math.Matrices.solve({{A[3,3], 2.0, 3.0}, {4.0, A[3,3], 6.0}, {7.0, 8.0, A[3,3]}}, {b[1], b[2], b[3]})[2]; x[3] = Modelica.Math.Matrices.solve({{A[3,3], 2.0, 3.0}, {4.0, A[3,3], 6.0}, {7.0, 8.0, A[3,3]}}, {b[1], b[2], b[3]})[3]; }}} Meaning the equation system is solved once for each element of the solution vector and two temporary arrays are created for each call to solve. The generated simcode should read: {{{#!mo x = Modelica.Math.Matrices.solve(A, b); }}} A similar thing was solved recently for tuples, see [https://github.com/OpenModelica/OMCompiler/commit/1692f27c86cdbda67a641df8800ed2be35cb29a1 BackendDAE.ASSIGN can hold tuples on lhs]. This example can be simplified manually in the generated Cpp code (C as well I think). Then also the storage order of RefArray plays a role, see [https://github.com/OpenModelica/OMCompiler/commit/e657602228b40dc9eb103833607fc983e5d50ed2 Unify storage order of RefArray]." Rüdiger Franke 4164 OMEdit / OMNotebook do not open files at start on OS X OMEdit v1.11.0 defect Adeel Asghar new 2016-12-02T08:25:48Z 2021-09-13T11:58:21Z "On Linux and Windows, when dragging a .mo (.onb) file onto OMEdit (OMNotebook) the corresponding program is started and that file is opened (via argc/argv). On OS X this is not the case (argc is always 1). Instead an event is generated which shall handle opening of that file. See [http://doc.qt.io/qt-5/qfileopenevent.html]" Henning Kiel 4168 DAE index reduction in clocked partitions Backend defect Lennart Ochel new 2016-12-03T06:59:29Z 2021-09-13T11:58:21Z "Clocked partitions may contain high index DAEs, for instance when basing a discrete-time controller on an inverse continuous-time model, see: Modelica_Synchronous.Examples.Systems.ControlledMixingUnit Modelica_Synchronous.Examples.Systems.EngineThrottleControl OpenModelica produces wrong results for such models. OpenModelica currently discretizes differential equations by replacing `der(x)` with `(x - previous(x))/interval()` during clock partitioning (Euler). OpenModelica should reduce the DAE index inside a clocked partition prior to the discretization. See the failing test `synch.mos` (ControlledMixingUnit) https://github.com/OpenModelica/OpenModelica-testsuite/commit/ee09ab4b8551ce22514b4315cb04b88fdf2843ed" Rüdiger Franke 4236 Icon not rendered if visible annotation is used Interactive Environment defect Martin Sjölund assigned 2017-01-27T06:35:07Z 2021-09-13T11:58:21Z "We use various models that use the `visible` attribute in the graphical annotation of the form such as: {{{ visible = inputType == Buildings.Fluid.Types.InputType.Continuous, }}} It appears that OMEdit stops rendering all graphical elements of an icon once it encounters such a statement. The attached file `current.png` shows how `Buildings.Fluid.Movers.FlowControlled_m_flow` is currently rendered, while `expected.png` shows how it is rendered if I delete all `visible = ...` statements. If this statement causes problems, could you at least set `visible = true` and render all other graphical annotations? This would at a minimum make the icons recognizable." Michael Wetter 4238 OMEdit shows strange behavior when loading system libraries automatically Interactive Environment v1.11.0 defect Adrian Pop assigned 2017-01-27T12:52:00Z 2021-09-13T11:58:21Z "OMEdit ships with numerous so called System Libraries. They are currently loaded when invoking ""Check Model"". A couple of problems show up. This is why the automatic loading should happen earlier, e.g. when a model is loaded. See the attached file `ControlledMixingUnit2.mo`. So far OMEdit just reports upon file open: {{{ [1] 13:34:35 Übersetzung Fehler [ControlledMixingUnit2: 3:3-4:50]: Klasse Modelica_Synchronous.Examples.Systems.ControlledMixingUnit konnte nicht im Geltungsbereich von gefunden werden. }}} Check model reports: {{{ [1] 13:43:56 Skripting Meldung Automatically loaded package Modelica_Synchronous 0.92.1 due to uses annotation. [2] 13:43:57 Skripting Fehler Unable to find component feedback.y while parsing connection {feedback.y,gain.u, """"}. [3] 13:43:57 Skripting Fehler Unable to find component gain.y while parsing connection {gain.y,add.u2, """"}. [4] 13:43:57 Skripting Fehler Unable to find component inverseBlockConstraints.y2 while parsing connection {inverseBlockConstraints.y2,invMixingUnit.T_c, """"}. [5] 13:43:57 Skripting Fehler Unable to find component invMixingUnit.c while parsing connection {invMixingUnit.c,inverseBlockConstraints.u2, """"}. [6] 13:43:57 Skripting Fehler Unable to find component invMixingUnit.T while parsing connection {invMixingUnit.T,feedback.u1, """"}. [7] 13:43:57 Skripting Fehler Unable to find component filter.y while parsing connection {filter.y,inverseBlockConstraints.u1, """"}. [8] 13:43:57 Skripting Fehler Unable to find component hold1.y while parsing connection {hold1.y,mixingUnit.T_c, """"}. [9] 13:43:57 Skripting Fehler Unable to find component add.y while parsing connection {add.y,hold1.u, """"}. [10] 13:43:57 Skripting Fehler Unable to find component sample1.u while parsing connection {sample1.u,mixingUnit.T, """"}. [11] 13:43:57 Skripting Fehler Unable to find component sample1.y while parsing connection {sample1.y,feedback.u2, """"}. [12] 13:43:57 Skripting Fehler Unable to find component inverseBlockConstraints.y1 while parsing connection {inverseBlockConstraints.y1,add.u1, """"}. [13] 13:43:57 Skripting Fehler Unable to find component sample2.u while parsing connection {sample2.u,step.y, """"}. [14] 13:43:57 Skripting Fehler Unable to find component filter.u while parsing connection {filter.u,sample2.y, """"}. [15] 13:43:57 Skripting Fehler Unable to find component periodicClock1.y while parsing connection {periodicClock1.y,sample2.clock, """"}. [16] 13:43:57 Skripting Meldung Check of ControlledMixingUnit2 completed successfully. }}} Simulation works afterwards. The model graphics remains wrong though. " Rüdiger Franke 4270 Sorting of Eqns and Variable in Backend Backend defect Willi Braun reopened 2017-02-14T14:42:11Z 2021-09-13T11:58:21Z "In the attached script the simulation result of the model A and model B is different due to a different order of components in model definition. This may be caused by the modules removeSimpleEquation or Tearing (or maybe something else ?), since this modules based on heuristics that have a different output on different input. Also connected to #3397. We already have a modules that can fix the issue in the attached model {{{--preOptModules+=sortEqnsVars}}}. This pre-optimization module currently sorts the equations and variables by there amount of appearance in the adjacency matrix. This might be still not a fully deterministic behavior, so we probably need further criteria. Should this modules become enabled by default? " Willi Braun 4277 Add the documentation of the Git feature in OMEdit OMEdit defect Alachew Mengist assigned 2017-02-18T15:51:57Z 2021-09-13T11:58:21Z "The documentation of the Git feature in OMEdit currently missing. It should be added before the next release. I would also suggest to explain clearly if it is possible to use both the Git feature and the git command line (or TortoiseGIT) tools without messing up. I guess so, and this also seems a reasonable requirement, but I'm not sure if the current implementation allows it." Francesco Casella 4313 Read and write issues with KeyWordIO Run-time defect Adrian Pop assigned 2017-03-14T21:17:11Z 2021-09-13T11:58:21Z "The KeyWordIO library is included as System Library to OpenModelica. I am currently trying to make the library as compatible to OpenModelica, as possible. So please consider the Examples package of version https://github.com/christiankral/KeyWordIO/tree/1ac688f2e1185d1a1d06c72c2af26a9e2e7b6c07 * ReadRealParameter: works OK * ReadRealCSV: only the part of reading the tab separated file (line 8) is working; the other reading activities (line 10,12,14) do not work, although only the delimiter is different... the error message is {{{ stdout | error |

a->dim_size[0] != b->dim_size[0], 0 != 3
}}} * ReadStringCSV: compiles OK, but does not run * ReadStringCSVUnquoted: compiles OK, but does not run * ReadColumnByHeaderName: compiler error {{{ KeyWordIO.Examples.ReadColumnByHeaderName_08bnd.o: In function `KeyWordIO_Examples_ReadColumnByHeaderName_eqFunction_2': KeyWordIO.Examples.ReadColumnByHeaderName_08bnd.c:(.text+0x2c2): undefined reference to `string_get_2D' KeyWordIO.Examples.ReadColumnByHeaderName_08bnd.o: In function `KeyWordIO_Examples_ReadColumnByHeaderName_eqFunction_3': KeyWordIO.Examples.ReadColumnByHeaderName_08bnd.c:(.text+0x3c0): undefined reference to `string_get_2D' KeyWordIO.Examples.ReadColumnByHeaderName_08bnd.o: In function `KeyWordIO_Examples_ReadColumnByHeaderName_eqFunction_4': KeyWordIO.Examples.ReadColumnByHeaderName_08bnd.c:(.text+0x4c0): undefined reference to `string_get_2D' clang: error: linker command failed with exit code 1 (use -v to see invocation) KeyWordIO.Examples.ReadColumnByHeaderName.makefile:30: recipe for target 'omc_main_target' failed make: *** [omc_main_target] Error 1 Compilation process failed. Exited with code 2. }}} * WriteRealVariable: works OK * WriteRealVariables: works OK * CaseExamples.ElectricalCases: works OK, if parameter case is set to {{{cases = 6}}} instead of determining the case by the original implementation (which does NOT work) {{{ cases=KeyWordIO.readCaseNumbersCSV( fileName=fileName, header=header, delimiter=""\t"", cache=cache) ""Number of cases""; }}} " Christian Kral 4336 Problem with code generation involving arrays of components containing arrays of Real variables Code Generation defect Mahder Alemseged Gebremedhin accepted 2017-03-17T16:51:04Z 2021-09-13T11:58:21Z "Please consider the model {{{DEMOSimple.Test.Helium.TestCP}}} from the attached package. The model is accepted by the front-end, and it actually simulates successfully in Dymola. However, when compiling the C code generating by OMC, the following error message pops up: {{{ DEMOsimple.Test.Helium.TestCP_02nls.c: In function 'residualFunc53': DEMOsimple.Test.Helium.TestCP_02nls.c:53:3: error: '$OLD_$PheliumCP$PchB$lB2$rB$PTm$lBtmp3$rB' undeclared (first use in this function) $OLD_$PheliumCP$PchB$lB2$rB$PTm$lBtmp3$rB = $PheliumCP$PchB$lB2$rB$PTm$lBtmp4$rB; ^ }}} The involved variable is an element of a Real array inside an array of models. Can you please have a look and fix it?" Francesco Casella 4391 Weird behaviour with event detection Run-time defect somebody new 2017-04-09T21:25:59Z 2021-09-13T11:58:21Z "Please consider the following test model {{{ model Test Real a, b; discrete Real flag; algorithm when a > 0 and b > 0 then flag := 1; end when; initial algorithm if (a > 0) then flag := -1; end if; equation a = 1+time; b = if time < (-1) then -1 else time; annotation(experiment(StartTime=-2, StopTime=2)); end Test; }}} When simulating, the variable {{{flag}}} starts at -1, but only switches to +1 when time = 2, as if the event at time 0 was not caught. Why does this happen?" Francesco Casella 4396 IDA solver in DAE mode is inefficient with badly scaled systems Run-time defect Willi Braun reopened 2017-04-12T16:31:23Z 2021-09-13T11:58:21Z "Modelica models are often badly scaled because of the recommended use of variables in SI units, which often causes variables in the same model to differ by many orders of magnitude, up to 15 or more. The Modelica language allows to define nominal values for the scaling of variables, that can be used to set up properly scaled numerical problems in the runtime code. However, this mechanism seem not to work properly when using the IDA solver in DAE mode. The attached test case shows clearly the problem. The model is taken from #4395, with the end displacement {{{d_tot}}} no longer being a constant, but rather the solution of the trivial differential equation {{{der(d_tot)=1}}}. {{{Test1}}} is natively scaled in a benign way, with all variables of the order of unity or, in the worst case, of 1e-3. {{{Test2}}} is the same model as {{{Test1}}} with much higher stiffness constants, so that some of the unknowns during integration (the vector {{{F[N]}}}) now have order of magnitude 1e8. Note that, apart from the scaling factor, the solution has exactly the same shape. {{{Test3}}} is the same model as {{{Test2}}}, with the proper nominal attribute set on the vector {{{F[N]}}}. In principle, if the model gets properly scaled according to this information, {{{Test3}}} should numerically become exactly the same as {{{Test1}}}, and thus take more or less the same time to be solved. Note that is is only true if both the variables and the residuals are properly scaled. The following table summarizes the results obtained on my PC with running omc {{{v1.12.0-dev-354-gadf56d3}}} on Windows || Test || Steps || functionODE calls || Jacobian evaluations || Simulation time || || Test1 ||18||33||16|| 8.17|| || Test2 ||16||26||14|| 97.30|| || Test3 ||16||26||14|| 100.85|| Analyzing the results, one can take the following conclusions - the number of steps is only decided by the trivial differential equation, and is thus roughly constant - the time spent solving each step grows 10-fold for the badly scaled problem, though this only basically reflects a change in the units of variable {{{F[N]}}}, not a change in the nature of the problem - setting the nominal attribute on the badly scaled variables does not improve the situation - in fact, it makes it slightly worse One can expect that similar problems will arise when using IDA in DAE mode to solve real-life problems; as soon as the units of the variables are such that their order of magnitude (and the order of magnitude of equation residuals) is much different, there will be a performance penalty of one order of magnitude (or possibly more, for larger models) in terms of simulation time. I would suggest to investigate why this happens and to introduce the appropriate corrective measures, so that the simulation time of models {{{Test1}}} and {{{Test3}}} becomes comparable." Francesco Casella 4398 comSubExp scales as O(N^2) Backend defect Volker Waurich reopened 2017-04-25T22:03:51Z 2021-09-13T11:58:21Z "These are the times spent by the comSubExp (simulation) backend function when compiling the ScalableTestSuite.Thermal.Advection.ScaledExperiments.SimpleAdvection_N_XXX models, see https://test.openmodelica.org/libraries/ScalableTestSuite_Experimental/BuildModelRecursive.html ||= N =||=time=|| || 3200 || 30 || || 6400 || 213 || ||12800|| 1444 || The model is a very simple one {{{ model SimpleAdvection ""Basic thermal advection model with uniform speed"" parameter Integer N = 2 ""Number of nodes""; parameter Modelica.SIunits.Temperature Tstart[N]=ones(N)*300 ""Start value of the temperature distribution""; parameter Modelica.SIunits.Length L = 10 ""Pipe length""; final parameter Modelica.SIunits.Length l = L/N ""Length of one volume""; Modelica.SIunits.Velocity u = 1 ""Fluid speed""; Modelica.SIunits.Temperature Tin = 300 ""Inlet temperature""; Modelica.SIunits.Temperature T[N] ""Node temperatures""; Modelica.SIunits.Temperature Ttilde[N-1](start = Tstart[2:N], each fixed = true) ""Temperature states""; Modelica.SIunits.Temperature Tout; equation for j in 1:N-1 loop der(Ttilde[j]) = u/l*(T[j]-T[j+1]); end for; T[1] = Tin; T[N] = Tout; Ttilde = T[2:N]; end SimpleAdvection; }}} I'm not sure what are the common subexpressions that OMC is looking for here, but even if there were any, spending half an hour to find them doesn't really make sense. Anyway, the complexity of the algorithm shouldn't be so bad. The problem can be traced back to a commit on either Jan 16 or Jan 17, since from the history reports, it wasn't present with v1.12.0-dev.109+g6700d3e and it was present with v1.12.0-dev.116+g6f8bb14. " Francesco Casella 4412 Error with Protected Elements Backend v1.12.0 defect Lennart Ochel accepted 2017-05-04T10:30:47Z 2021-09-13T11:58:21Z "In the following model {{{ model ProtectedError Real var1; protected Real var2 = 1; equation var1 = var2; end ProtectedError; }}} should be prevented by the keyword {{{protected}}} that the variable {{{var2}}} is displayed in the output of OMEdit. However, both variables {{{var1}}} and {{{var2}}} are displayed. " timo.lask@… 4414 Protected (expandable) connectors within a component model are not suppressed in icon view of component when placed in other models OMEdit v1.11.0 defect Adeel Asghar new 2017-05-05T23:14:47Z 2021-09-13T11:58:21Z "1. Make a component with an expandable connector and appropriate icon (like Modelica.Icons.SignalBus) 2. Make that expandable connector protected in the component 3. View the icon layer of the component--you will see no connector icon 4. Place that component in another diagram--the protected connectors are displayed and are available to make connections." anonymous 4471 Support IdealizedContact Library Third-Party Libraries v1.11.0 defect Adrian Pop assigned 2017-07-15T11:53:51Z 2021-09-13T11:58:21Z "Simulating IdealizedContact.Examples.Example1 throws the following error message below. The IdealizedContact library is not listed under libray coverage. Are there any plans to support the idealized contact library in the future? [3] 13:49:45 Übersetzung Fehler [IdealizedContact: 16883:5-16919:11]: Class specialization violation: .Modelica.Icons.TypeString is a type, not a connector. [4] 13:49:45 Übersetzung Fehler Error occurred while flattening model IdealizedContact.Examples.Example1 " Oliver Lenord 4482 checkAndGetAlgorithmOutputs failed *unknown* v1.11.0 defect somebody new 2017-08-02T08:40:23Z 2021-09-13T11:58:21Z " I am working on a model where multiple instantiation of model is required and some equations are written in new model where these model are instantiated. I am instantiating ""reboiler"" model in ""column"". There is one array variable called mixMolFrac[2] in reboiler. I need to assign different values to this variable hence I am using if-else conditions. My if- else also coming inside for loop hence I am writing this in algorithm section since writing it in equation section was producing some extra equations. When I write it in algorithm in if- else as ""reboiler.feed.mixMolFrac[:] := {0, 0}"" it is showing [19] 01:26:52 Translation Error Internal error checkAndGetAlgorithmOutputs failed. [20] 01:26:52 Translation Error No system for the symbolic initialization was generated But if I write this in equation as ""reboiler.feed.mixMolFrac[:] = {0, 0}"" without if-else, it is giving right results. There are eight variables which I am writing in if-else in algorithm but only these two variables are giving problem. Thanks in advance. " pravinkumar.dalve@… 4538 OMPython is not reading simflags correctly Interactive Environment defect somebody new 2017-10-01T08:33:52Z 2021-09-13T11:58:21Z "I am using OMPython to automatically simulate and evaluate simulation models with OpenModelica. One of the new models IMC_YD is now included in the MSL but only simulates if I use the Newton solver for nonlinear equations in OpenModelica. I thus included {{{ __OpenModelica_simulationFlags(jacobian = """", nls = ""newton"", s = ""dassl"", lv = ""LOG_STATS"") }}} in the annotation of the model. So when I simulate the model in OMEdit, it works OK with no issues. If I instead use OMPython to run the model, it hangs -- which I suspect is for the reason of that the {{{__OpenModelica}}} annoation is not evaluated correctly. {{{ from OMPython import * omc = OMCSessionZMQ() omc.sendExpression(""loadModel(Modelica,{\""trunk\""})"") omc.sendExpression(""loadFile(\""/.../IMC_YD.mo\"")"") omc.sendExpression(""instantiateModel(IMC_YD)"") omc.sendExpression(""simulate(IMC_YD, NumberOfIntervals=25000)"") }}} I do not expect OMPython needs the simflags passed separately, since all other annotations (StopTime, etc.) are evaulated correctly, too. Even if I wanted to pass the OM simflags to the simulation process I would not understand how the syntax really is..." Christian Kral 4540 Cannot change CFLAGS for C++ FMI simulations Cpp Run-time defect somebody new 2017-10-02T07:00:23Z 2021-09-13T11:58:21Z The C++ runtime does not respect the optimization flags set by the user using the `setCFlags()` API function (and additionally you cannot query which flags are being used from within OM). Martin Sjölund 4542 Performance issues with medium-sized linear systems *unknown* defect Patrick Täuber new 2017-10-04T11:33:15Z 2021-09-13T11:58:21Z "Please consider the performance of the following models {{{ ScalableTestSuite.Electrical.DistributionSystemAC.ScaledExperiments.DistributionSystemLinear_N_10_M_10 ScalableTestSuite.Electrical.DistributionSystemAC.ScaledExperiments.DistributionSystemLinear_N_14_M_14 ScalableTestSuite.Electrical.DistributionSystemAC.ScaledExperiments.DistributionSystemLinear_N_20_M_20 ScalableTestSuite.Electrical.DistributionSystemAC.ScaledExperiments.DistributionSystemLinear_N_28_M_28 }}} reported [https://test.openmodelica.org/libraries/ScalableTestSuite_Experimental/BuildModelRecursive.html here]. ||= N =||= M =||= Time =|| || 10 || 10 || 5.8|| || 14 || 14 || 1961|| || 20 || 20 || FAIL|| || 28 || 28 || 38|| With the current default settings {{{--maxSizeLinearTearing = 4000}}} and {{{-lssMinSize=4001}}}, the first three are solved using tearing and the dense solver, while the fourth is solved without tearing and with the sparse solver. The diagnostic messages of the N = 14 and N = 20 cases report multiple messages such as {{{ warning | The default linear solver fails, the fallback solver with total pivoting is started at time 0.004864. That might raise performance issues, for more information use -lv LOG_LS. }}} The sparse solver without tearing obviously performs much better. I'm not sure if the problem with the other combination is that the dense solver is less efficient or that the tearing is questionable and leads to singularities, or both. Please investigate. If the tearing is bad, we should fix it, otherwise we may need to revise the default values of those two flags. I think it would be better to use defaults that optimize the performance of this batch of test cases, rather then using the arbitrary value 4000 set so far. We may revise the default later when we have more diverse test cases." Francesco Casella 4555 Redundantly inherited parameters (diamond inheritance) appear multiple times in parameters dialog of instantiated model OMEdit defect Adeel Asghar new 2017-10-10T15:10:55Z 2021-09-13T11:58:21Z "When a model is built by extending superclasses with diamond inheritance, the resulting model will show multiple instances of the same inherited parameter in its parameters dialog. A minimal working example is shown below. Open the model mwe_duplicate_parameters in OMEdit and open the Parameters dialog of thesubmodel. {{{ model mwe_duplicate_parameters model submodel extends extendme1; extends extendme2; end submodel; model extendme1 extends extendme0; end extendme1; model extendme2 extends extendme0; end extendme2; mwe_duplicate_parameters.submodel thesubmodel annotation( Placement( visible = true, transformation( origin = {0, 0}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); model extendme0 parameter Real p; end extendme0; annotation( Icon(coordinateSystem(grid = {1, 1}))); end mwe_duplicate_parameters; }}}" anonymous 4564 State machine tests fail with C run-time Run-time defect somebody new 2017-10-13T18:44:20Z 2021-09-13T11:58:21Z "The test suite contains two state machine tests (simulation/modelica/statemachines) which require the C++ run-time: - EnteringByReset.mos - SMGraphicalTestCases_DeepHierarchy.mos Both need the line `setCommandLineOptions({""+simCodeTarget=Cpp""});` in order to succeed, otherwise the tests fail. " Bernhard Thiele 4580 OMEdit does not show the boolean condition of the state machine transition OMEdit v1.13.0-dev-nightly defect Adeel Asghar new 2017-10-19T14:43:26Z 2021-09-13T11:58:21Z "As shown in attached screenshot, there are some issues in the visualization of boolean conditions of the state-machines transitions. OMEdit 1.13.0~dev-24-g095b0ef Connected to OpenModelica 1.13.0~dev-222-ga3c7ea2 sysop - Ubuntu 16.04 - 64 bit" Andrea Bartolini 4601 C-code compilation times are too large for models with many state variables Code Generation defect Martin Sjölund new 2017-10-30T07:39:10Z 2021-09-13T11:58:21Z "The ScalableTestSuite contains several models with a moderately high number of state variables (up to 25600, as of today) and a very simple structure, such as a cascade connection of first order systems: - CascadedFirstOrder - SimpleAdvection - AdvectionReaction The C compilation times shown in the latest [https://libraries.openmodelica.org/branches/master/ScalableTestSuite/ScalableTestSuite.html Hudson report] show both good and bad news. The good news is that at least the C compilation time scales linearly. The bad news is that, depending on the specific test case, the C compilation takes between 5 and 12 ms for each state variable. This means that a model with 50.000 state variables, which I think should be perfectly reasonable, would take between 4 and 10 minutes to compile the C sources. It is true that C source splitting and parallel compilation can help a lot, but yet 10 ms is an awful lot of time for a modern 4 GHz processor. I wonder if such a time is really necessary for each state variable, if the expression of the corresponding derivative is something as simple as {{{1/T*(x[i-1]-x[i])}}}. Could we try to streamline the generated code to reduce this substantially, without too much effort?" Francesco Casella 4603 Provide support for start-value selection according to the Modelica Specification New Instantiation defect Karim Adbdelhak assigned 2017-10-31T23:53:29Z 2021-09-13T11:58:21Z "The Modelica Specification, section 8.6.2, provides a non-normative procedure to select start values in case of alias variables. This requires the front-end to produce a ''confidence number'' based on the level at which the start value is set or modified. I understand from @ptauber that this number is not available in the back-end, so the selection is based on the ''cref depth'' instead. It would be nice if this information was computed by the new front end, so it could be used by the back-end." Francesco Casella 4605 rpath issues in runtime libraries on Ubuntu 17.10 Run-time defect Martin Sjölund accepted 2017-11-01T16:34:21Z 2021-09-13T11:58:21Z "Tests such as Crane_FMU2_CPP.mos currently fail on Ubuntu 17.10: {{{ messages = ""Simulation execution failed for model: cranes_crane_me_FMU Cannot open library: libomcgc.so.1: cannot open shared object file: No such file or directory Simulation stopped with error in model factory: Failed loading System library! /home/marsj/OpenModelica/testsuite/openmodelica/cppruntime/fmu/modelExchange/2.0/OMCppcranes_crane_me_FMU.so }}} If simCodeTarget is changed to C when compiling the model generated by importFMU, the code works fine. There is something preventing the C++ runtime from working correctly using this code." Martin Sjölund 4620 CodegenCFunctions.daeExp has stack overflow Susan (Templates) v1.13.0-dev-nightly defect Adrian Pop new 2017-11-09T21:34:01Z 2021-09-13T11:58:21Z "{{{ScalableTestSuite.Electrical.TransmissionLine.ScaledExperiments.TransmissionLineModelica_N_1280}}} leads to a stack overflow in {{{CodegenCFunctions.daeExp/daeExpBinary}}}: {{{ [src/OpenModelica/OMCompiler/Compiler/Template/Tpl.mo:2025:8-2025:159:writable] Error: Interner Fehler Stack overflow when evaluating function: [bt] #1 libOpenModelicaRuntimeC.dylib(mmc_setStacktraceMessages_threadData) [bt] #2 libOpenModelicaRuntimeC.dylib(mmc_do_stackoverflow) [bt] #3 libOpenModelicaCompiler.dylib(CodegenCFunctions.fun_682) [bt] #4 libOpenModelicaCompiler.dylib(CodegenCFunctions.daeExpBinary) [bt] #5 libOpenModelicaCompiler.dylib(CodegenCFunctions.fun_682) [bt] #6 libOpenModelicaCompiler.dylib(CodegenCFunctions.daeExpBinary) [bt] #7 libOpenModelicaCompiler.dylib(CodegenCFunctions.fun_682) [bt] #8 libOpenModelicaCompiler.dylib(CodegenCFunctions.daeExpBinary) ... }}}" Henning Kiel 4630 Rethink mathematical simplifications *unknown* v1.13.0-dev-nightly defect somebody new 2017-11-16T08:25:16Z 2021-09-13T11:58:21Z "I propose to have in this ticket a list of (more complex) mathematical simplifications to be implemented in OMC (ExpressionSimplify). To quote sjoelund.se from github discussion: {{{ acos(cos(x)) is not equal to x... For example acos(cos(13)) = 0.4336293856408271 And cos(acos(13)) is an error, not 13... acos(cos(x)) could be mod(x, pi)? }}} The same argumentation holds for typical math simplification {{{e^(ln(x)) = x}}} which is an error for {{{x<0}}} '''always correct simplifications''' - implement * ln(e^x^) = x * sin^2^(x)+cos^2^(x) = 1 * cosh^2^(x) - sinh^2^(x) = 1 * sin(acos(x)) = sqrt(1-x^2^) * cos(asin(x)) = sqrt(1-x^2^) * tan(atan(x)) = x questionable simplifications * asin(sin(x)) = ? * atan(tan(x)) = ? * sin(asin(x)) = ? * acos(cos(x)) = mod(x, pi) -> is wrong, it is a triangle function * asin(sin(x)) is shifted triangle function '''incorrect simplifications''' - do not implement * cos(acos(x)) = x (only true for -1<=x<=1) * sin(asin(x)) = x (only true for -1<=x<=1) * e^ln(x)^= x (only true for x>0) " Henning Kiel 4641 FMU exported from OpenModelica 1.13.0 does not integrate correctly until end of integration interval (time event missing) FMI defect Lennart Ochel new 2017-11-21T08:36:31Z 2021-09-13T11:58:21Z "A model has a time event defined at t=1, resulting in a step change of variable x1 from 0 to 1. The FMU generated from OpenModelica is integrated from 0.99 to 1.00. The output of x1 remains 0 also at the end of the integration interval, whereas a result of 1 is expected. See attached modelica model and exported FMU (Linux64)." Andreas Nicolai (andreas.nicolai@… 4692 OMEdit crashes in interactive simulation when reaching stopTime Interactive Environment v1.13.0-dev-nightly defect somebody new 2017-12-19T18:31:36Z 2021-09-13T11:58:21Z When an interactive simulation is carried out directly in OMEdit (Nightly build v1.13), both the compiled .exe and OMEdit hardcrash when the simulation reaches the stoptime. anonymous 4711 DrumBoiler model unnecessarily slow due to lack of analytic jacobiann Backend defect Patrick Täuber new 2018-01-16T22:34:32Z 2021-09-13T11:58:21Z "The model {{{Modelica.Fluid.Examples.DrumBoiler.DrumBoiler}}} is slower than necessary because of an implicit system that is not recognized as linear and thus solved iteratively, which wastes a lot of time because of the computation involved and the call to the IF97 {{{rhovl_p()}}} function, see ticket:4423#comment:16 for more details. The system is not recognized as linear because the analytical evaluation of the Jacobian fails. It would be worth investigating why that is the case and if it is possible to avoid this failure." Francesco Casella 4749 Error: variable wea.lat not found in scope (...) while flattening model *unknown* v1.13.0-dev-nightly defect Martin Sjölund assigned 2018-02-07T06:44:03Z 2021-09-13T11:58:21Z "We have a bug here arising from use of the latest nightly version of omc --version = ""OpenModelica 1.13.0~dev-614-g4bf4d98"". Previously our code gave no error, but since updating, we have an error relating to a Parameter value, initialised in a submodel, not being available in the parent model. The code which causes problems is visible here: https://github.com/SolarTherm/SolarTherm/blob/alberto-merge/examples/TroughWagner.mo That model in turn includes this one: https://github.com/SolarTherm/SolarTherm/blob/alberto-merge/SolarTherm/Systems/GenericSystem.mo In that model, you can see that 'wea' is instantiated and then immediately we refer to 'wea.lat', which currently results in the following compiler output: {{{ [2] 17:36:27 Translation Notification [SolarTherm.Models.Sources.Weather.WeatherSource: 15:2-15:49]: Moving binding to initial equation section and setting fixed attribute of wea.meta.name to false. [3] 17:36:27 Translation Notification [SolarTherm.Models.Sources.Weather.WeatherSource: 15:2-15:49]: Moving binding to initial equation section and setting fixed attribute of wea.meta.lat to false. [4] 17:36:27 Translation Notification [SolarTherm.Models.Sources.Weather.WeatherSource: 15:2-15:49]: Moving binding to initial equation section and setting fixed attribute of wea.meta.lon to false. [5] 17:36:27 Translation Notification [SolarTherm.Models.Sources.Weather.WeatherSource: 15:2-15:49]: Moving binding to initial equation section and setting fixed attribute of wea.meta.elev to false. [6] 17:36:27 Translation Notification [SolarTherm.Models.Sources.Weather.WeatherSource: 15:2-15:49]: Moving binding to initial equation section and setting fixed attribute of wea.meta.tzone to false. [7] 17:36:27 Translation Notification [SolarTherm.Models.Sources.Weather.WeatherSource: 15:2-15:49]: Moving binding to initial equation section and setting fixed attribute of wea.meta.tstart to false. [8] 17:36:27 Translation Error [SolarTherm.Systems.GenericSystem: 120:19-120:67]: Variable wea.lat not found in scope SolarTherm.Models.CSP.CRS.HeliostatsField.SteeredCL$CL. [9] 17:36:27 Translation Error Error occurred while flattening model TroughWagner }}} The error is that 'wea.lat' is not found in scope. This seems to closely relate to other issues we've been having recently with Parameters being set in submodels, so we think some regression has happened here. For example, see this related bug: https://trac.openmodelica.org/OpenModelica/ticket/4710 Also please note that the ""Translation Notification"" given above is new -- we never used to see this Notification before -- and seems likely to be related to this problem. Note in particular that the value wea.meta.lat is clearly understood by the compiler, but that the reassignment of wea.meta.lat to Parameter wea.lat in WeatherSource line 6, is not working, since the compiler doesn't then recognise that 'wea.lat' exists. " john.pye@… 4765 Problem with stacking of icons OMEdit v1.13.0-dev-nightly defect Adeel Asghar new 2018-02-15T14:44:32Z 2021-09-13T11:58:21Z "When on has a smaller icon in front of a larger one then the smaller should be clickable independent on the order the components appear in the code. The attached [attachment:M.mo M.mo] demonstrates the issue: `gain1` and `gain2` can not be selected unless the larger icon around is moved out of the way. `gain3` and `gain4` show the expected behaviour. Currently one needs to make sure that the larger icons appear first in the code in order that it works. " Dietmar Winkler 4782 Cannot pass a parameter value coming from a class to another class nested in another class!! OMEdit v1.13.0-dev-nightly defect Martin Sjölund assigned 2018-02-28T00:52:24Z 2021-09-13T11:58:21Z "Hello, I have been recently reporting a number of issues in relation to our OM library (i.e. SolarTherm available from: https://github.com/SolarTherm/SolarTherm/tree/alberto-merge) with the recent version of OMC, in particular the stable and the nightly build versions. In this specific issue, which I should mention that never happened in the previous versions of OMC (e.g. V1.11), one of our example model (i.e. TroughWagner.mo available form: https://github.com/SolarTherm/SolarTherm/blob/alberto-merge/examples/TroughWagner.mo) breaks because OM fails to pass a value from the class instance “wea” (i.e. wea.lat which is a parameter showing the latitude of a location, which itself is read from a weather data file) to another class (i.e. OptEff) which is itself nested in another class instance called CL. It should be mentioned that the model TroughWagner.mo itself is an extension of a base class called “GenericSystem.mo” which is available from: https://github.com/SolarTherm/SolarTherm/blob/alberto-merge/SolarTherm/Systems/GenericSystem.mo. Here is the piece of code in GenericSystem.mo that shows the issue that I have been trying to demonstrate: {{{ SolarTherm.Models.Sources.Weather.WeatherSource wea(file=wea_file, delay= wdelay); SolarTherm.Models.CSP.CRS.HeliostatsField.SteeredCL CL( redeclare model OptEff = SolarTherm.Models.CSP.CRS.HeliostatsField.FileOE ( file=opt_file, orient_north=if wea.lat < 0 then true else false), A=if match_sam then 1.0273*A_field else A_field, steer_rate=0.002, target_error=0.0001, actual_0=0.0); // ~8 minutes till fully on sun // if large can be large source of missing energy }}} And below is the error I get when I run TroughWagner.mo in OMEdit: {{{ [7] 11:18:24 Translation Error [SolarTherm.Systems.GenericSystem: 120:19-120:67]: Variable wea.lat not found in scope SolarTherm.Models.CSP.CRS.HeliostatsField.SteeredCL$CL. }}} Finally, I should mention that the package SolarTherm (from “alberto-merge” branch: https://github.com/SolarTherm/SolarTherm/tree/alberto-merge/SolarTherm) must be imported to OMEdit before running the above model as it contains a number of dependencies required by the model. I would appreciate it if you have a look and let me know what causes this error. Thanks, Ali Shirazi" ali.shirazi@… 4785 Memory is never given back *unknown* v1.13.0-dev-nightly defect somebody new 2018-02-28T18:02:23Z 2021-09-13T11:58:21Z "I've seen that OM (at least when used through OMEdit), never gives back memory. I understand that it uses Garbage collector, but AFAIK, at least periodically, if large amounts of memory are not allocated anymore, they should be sent back to the OS to give other processes a chance to exploit. Steps to reproduce (OM 1.13 dev 380, win 64 bit): 1) launch OMEdit Now Task manager reports 450 MB as allocated to OMEdit. 2) load Buildings library (5.0.0: should be the latest) and double-click on Air.Systems.SingleZone.Vav.ChillerDXHeatingEconomizer Memory reaches 3.65 GB 3) unload Buildings library. The loaded memory stays above 3.6 GB whatever you do, except closing OMEdit. BTW, the memory used seems to be too large: Dymola for the same case uses just 235 MB total. But this is another story (see discussion on ticket #4755)." massimo ceraolo 4845 Tearing of linear systems produces singular system out of moderately-sized, well-posed models Backend defect Andreas Heuermann assigned 2018-03-27T12:17:41Z 2021-09-13T11:58:21Z "Please consider the {{{ScalableTestSuite.Mechanical.HarmmonicOscillator.ScaledExperiments.HarmonicOscillatorNetwork_N_XX}}} test models. They require solving a linear system of N equations to compute the accelerations of the N point masses involved. For N > 40, the solver fails repeatedly with error messages like: {{{ Failed to solve linear system of equations (no. 322) at time 0.000000.  Residual norm is 14.0094302893603. 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 }}} In fact, the outcome is particularly bad, because the solver does not abort, but keeps on trying forever. Even if the {{{Cancel simulation}}} button is pressed, the .exe file keeps on running in the background unless it is killed with the Process Manager, which is quite bad. The debugger reveals that the linear system of size N is very effectively torn, ending up with just one tearing variable. Unfortunately, the resulting torn system is ill-conditioned for even moderate values of N. From what I understand, the problem is that the k+1-th torn variable is given by 3 times the k-th one, plus other terms. As a consequence, the N-th torn variable is ultimately depending on 3^N^ times the tearing variable, which is obviously not going to be numerically well-posed for N much larger than 20. The system per se is well-posed and solved without problems also for much larger sizes if tearing is switched off, and possibly a sparse solver is used for large values of N. Clearly, tearing is not a good idea to solve this class of systems. I think we need some mechanism to identify them and prevent (or limit) the use of tearing in such cases.. The current behaviour, i.e., get an ill-posed system and failing badly, is not acceptable. BTW, note that I did not build this test cases specifically to cause this outcome." Francesco Casella 4898 The variableFilter option of the simulate() API does not filter parameters and constants Command Prompt Environment defect somebody new 2018-04-21T08:57:07Z 2021-09-13T11:58:21Z "In the [https://openmodelica.org/doc/OpenModelicaUsersGuide/latest/scripting_api.html Scripting API] there are several commands, in particular {{{simulate()}}}, that have a {{{variableFilter}}} input, which accepts a regex to specify which variables should be saved. Unfortunately, no matter what I put in the regex, all the parameters of the model are always saved. It is true that parameter do not take much space in the result file, as they only have one or two time points. On the other hand, large structured models can have a lot of parameters with very long names, so the part of the result file that contains their name strings can have a significant size. Is this a bug or a feature?" Francesco Casella 4902 Tiny simulation steps after recent nightly build Backend v1.13.0-dev-nightly defect Francesco Casella assigned 2018-04-25T11:42:07Z 2021-09-13T11:58:21Z "I'm not sure exactly which build caused the problem, but after software updater did its thing sometime last week my models run with a tiny step-size in both DASSL and IDA whereas they have been just fine before. They are quite big models, but usually solve in 3-6 seconds. Now it takes many hours to simulate the same. I'm on Lubuntu 16.04 and I've used nightly builds from the repo for the last two years or so, updating the packages maybe once a week. It's for this reason difficult to say exactly which version I was using just before I encountered the problem. The package containing my models is at https://github.com/FishSim/LibRAS and LibRAS/Examples/Inline.mo is the one I suggest for testing. Even minimal working examples using my package run incredibly slowly due to tiny steps. In a short test, I got 495 s spent on jacobian for 560 s simulation time, according to DASSL statistics. Can not tell if this is normal or not, but it seems a bit high compared to MSL examples. Examples from the MSL run just fine, so I don't think it's my system. " stig 4952 Remove obsolete removeEqualFunctionCalls backend module Backend defect Lennart Ochel assigned 2018-05-23T20:44:56Z 2021-09-13T11:58:21Z "The {{{removeEqualFunctionCalls}}} module is currently active by default in the [https://openmodelica.org/doc/OpenModelicaUsersGuide/latest/omchelptext.html#omcflag-preoptmodules preOpt modules]. It detects patterns like {{{ a = f(b) c = f(b) }}} and turns them into {{{ a = f(b) c = a }}} The {{{wrapFunctionCalls}}} method, which assigns all function calls to cse variables, has a wider scope and in fact makes the {{{removeEqualFunctionCalls}}} method obsolete. I would suggest to remove the latter for good. " Francesco Casella 5026 C++ Runtime Static Linking is not working Cpp Run-time defect somebody new 2018-07-03T07:17:46Z 2021-09-13T11:58:21Z "I am disabling `Modelica.Electrical.Analog.Examples.CauerLowPassSC_cpp_static.mos` since it does not seem to work as expected. It seems to ignore the library path where sundials is installed (`lib/.../omc`) and only works if sundials is installed in the OS. And even when the test succeeds, it is linked against 25 dynamic libraries anyway, some which are listed below: {{{ libboost_filesystem.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.58.0 (0x00007fb7ebefd000) libsundials_nvecserial.so.0 => /usr/lib/libsundials_nvecserial.so.0 (0x00007fb7eb412000) liblapack.so.3 => /usr/lib/liblapack.so.3 (0x00007fb7ea398000) libf77blas.so.3 => /usr/lib/libf77blas.so.3 (0x00007fb7ea178000) libatlas.so.3 => /usr/lib/libatlas.so.3 (0x00007fb7e9bda000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fb7e9858000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb7e954f000) libomp.so.5 => /usr/lib/x86_64-linux-gnu/libomp.so.5 (0x00007fb7e9283000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb7e906d000) libblas.so.3 => /usr/lib/libblas.so.3 (0x00007fb7e8848000) libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007fb7e851d000) libcblas.so.3 => /usr/lib/libcblas.so.3 (0x00007fb7e82fb000) libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007fb7e80bc000) }}} The executable is clearly not statically linked and cannot easily be moved between computers." Martin Sjölund 5107 SymbolicJacobian.generateSparsePattern scales as O(N^2) Backend defect Willi Braun new 2018-09-05T07:11:22Z 2021-09-13T11:58:21Z "Please check [https://libraries.openmodelica.org/branches/master/ScalableTestSuite_noopt/files/ScalableTestSuite_noopt_ScalableTestSuite.Electrical.DistributionSystemAC.ScaledExperiments.DistributionSystemLinearIndividual_N_56_M_56.err ScalableTestSuite.Electrical.DistributionSystemAC.ScaledExperiments.DistributionSystemLinearIndividual_N_56_M_56]. The code generation fails with {{{ Warning: Out of memory! Faking a stack overflow. [/var/lib/hudson/slave/workspace/OpenModelica_TEST_LIBS/OpenModelica/OMCompiler/Compiler/BackEnd/BackendDAEUtil.mo:7076:3-7076:155:writable] Error: Internal error Stack overflow in BackendDAEUtil.getSolvedSystem... [bt] #1 /var/lib/hudson/slave/workspace/OpenModelica_TEST_LIBS/OpenModelica/OMCompiler/build/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaRuntimeC.so(mmc_setStacktraceMessages_threadData) [bt] #2 /var/lib/hudson/slave/workspace/OpenModelica_TEST_LIBS/OpenModelica/OMCompiler/build/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaRuntimeC.so(mmc_do_stackoverflow) [bt] #3 /var/lib/hudson/slave/workspace/OpenModelica_TEST_LIBS/OpenModelica/OMCompiler/build/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaRuntimeC.so(GC.set.max.heap.size) [bt] #4 /var/lib/hudson/slave/workspace/OpenModelica_TEST_LIBS/OpenModelica/OMCompiler/build/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(SymbolicJacobian.generateSparsePattern) [bt] #5 /var/lib/hudson/slave/workspace/OpenModelica_TEST_LIBS/OpenModelica/OMCompiler/build/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(SymbolicJacobian.detectSparsePatternODE) [bt] #6 /var/lib/hudson/slave/workspace/OpenModelica_TEST_LIBS/OpenModelica/OMCompiler/build/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(BackendDAEUtil.postOptimizeDAE) [bt] #7 /var/lib/hudson/slave/workspace/OpenModelica_TEST_LIBS/OpenModelica/OMCompiler/build/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(BackendDAEUtil.getSolvedSystem) [bt] #8 /var/lib/hudson/slave/workspace/OpenModelica_TEST_LIBS/OpenModelica/OMCompiler/build/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(SimCodeMain.translateModel) }}} From what I understand the issue is with {{{SymbolicJacobian.generateSparsePattern}}}, which is the last back-end function called before the out-of-memory exception is thrown and catched in disguise of a stack overflow. The [https://libraries.openmodelica.org/branches/newInst/ScalableTestSuite_noopt/files/ScalableTestSuite_noopt_ScalableTestSuite.Electrical.DistributionSystemAC.ScaledExperiments.DistributionSystemLinearIndividual_N_28_M_28.err M_28_N_28] and [https://libraries.openmodelica.org/branches/newInst/ScalableTestSuite_noopt/files/ScalableTestSuite_noopt_ScalableTestSuite.Electrical.DistributionSystemAC.ScaledExperiments.DistributionSystemLinearIndividual_N_40_M_40.err M_40_N_40] logs report: {{{ symbolicJacobian (simulation): time 6.066/47.78, allocations: 309.2 MB symbolicJacobian (simulation): time 28.94/121.6, allocations: 0.9772 GB }}} showing that execution time and memory allocations grow much faster than I'd expect, since the number of non-zero elements in the Jacobian of this system is O(N). I guess there is some sub-optimal handling of lists somewhere that scales as O(N^2^). @wbraun, I understand this is recent work of yours, would you mind having a look? @hkiel, would you be interested in trying to fix this? Thanks!" Francesco Casella 5108 Models with large arrays of parameters cause the runtime to segfault Run-time defect Lennart Ochel new 2018-09-05T07:30:22Z 2021-09-13T11:58:21Z "Please check [https://libraries.openmodelica.org/branches/newInst/ScalableTestSuite_noopt/files/ScalableTestSuite_noopt_ScalableTestSuite.Elementary.ParameterArrays.ScaledExperiments.Table_N_280_M_280.sim ScalableTestSuite.Elementary.ParameterArrays.ScaledExperiments.Table_N_280_M_280] [https://libraries.openmodelica.org/branches/newInst/ScalableTestSuite_noopt/files/ScalableTestSuite_noopt_ScalableTestSuite.Elementary.ParameterArrays.ScaledExperiments.Table_N_400_M_400.sim ScalableTestSuite.Elementary.ParameterArrays.ScaledExperiments.Table_N_400_M_400]. The models fail at runtime with {{{ Limited backtrace at point of segmentation fault /lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7fc506f6a890] /lib/x86_64-linux-gnu/libc.so.6(+0x9430e)[0x7fc506bfb30e] /lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x8c)[0x7fc506bfe0fc] /lib/x86_64-linux-gnu/libc.so.6(+0xf377b)[0x7fc506c5a77b] /lib/x86_64-linux-gnu/libc.so.6(+0xf3af7)[0x7fc506c5aaf7] /lib/x86_64-linux-gnu/libc.so.6(+0xf3af7)[0x7fc506c5aaf7] /lib/x86_64-linux-gnu/libc.so.6(+0xf3af7)[0x7fc506c5aaf7] /lib/x86_64-linux-gnu/libc.so.6(+0xf3af7)[0x7fc506c5aaf7] /lib/x86_64-linux-gnu/libc.so.6(+0xf3af7)[0x7fc506c5aaf7] /lib/x86_64-linux-gnu/libc.so.6(+0xf3af7)[0x7fc506c5aaf7] /lib/x86_64-linux-gnu/libc.so.6(+0xf3af7)[0x7fc506c5aaf7] /lib/x86_64-linux-gnu/libc.so.6(+0xf3af7)[0x7fc506c5aaf7] /lib/x86_64-linux-gnu/libc.so.6(+0xf3af7)[0x7fc506c5aaf7] /lib/x86_64-linux-gnu/libc.so.6(+0xf3af7)[0x7fc506c5aaf7] /lib/x86_64-linux-gnu/libc.so.6(+0xf3af7)[0x7fc506c5aaf7] }}} The first of the two models contains a two-dimensional parameter array with 78400 elements, the second with 160000 elemets. These are large arrays, but definitely not huge, about 600 kB and 1.2 MB of memory, respectively. OMC should be able to handle them without problems." Francesco Casella 5141 Issues with the solution of fluid system models with low delta-p components Run-time defect Lennart Ochel new 2018-09-26T17:57:36Z 2021-09-13T11:58:21Z "Consider the attached test case. Please note you need the latest version of ThermoPower (https://github.com/casella/ThermoPower/commit/e3d010caa7912e66dea9f17e862ff5a51cb38a0a [commit e3d010]) to avoid issues with min/max attributes. The test case models a circuit with a pressure source and a pressure sink around atmospheric pressure. In between, steam flows through a valve, a volume, two series-connected pressure losses, another volume, and another valve. At initialization, the flow is about 1 kg/s, and the total pressure difference between the two volumes, 10000 Pa, is most taken by the two valves, with 5000 Pa each. The two pressure losses take only 10 Pa in {{{Test1}}}; 10 and 50 Pa in {{{Test2}}}. Since there is no volume in-between, an algebraic loop is formed, with the mass flow rate through the two components {{{pressDrop1.w}}} as tearing variable. This situation is representative of hydraulic and pneumatic circuits, where components with relatively high absolute pressure states are connected by flow models with very small quadratic pressure losses, and where direct connections between flow models without control volumes in-between can happen because of the connections of modules having a flow model directly attached to the fluid connector on each side. This situation is in fact very commonplace. At time = 0.1 the two valves are completely closed, so that the inner circuit becomes isolated. Given the very small pressure losses between the two volumes, the expected physical behaviour is that the two volumes very quickly get to the same pressure, and the flow through the two series-connecteed pressure loss components becomes zero. As there is no inertia in the flow, the exact solution of the pressure transients is monotonous, with no oscillations. The algebraic loop to determine {{{pressDrop1.w}}} could be potentially critical when the flow rate approaches zero if a purely quadratic flow-dp relationship was used, because the Jacobian would become singular (i.e., zero in this case). However, a regularized flow-dp releationship has been used instead, which smoothly turns into a linear one with non-zero slope close to the origin, when the mass flow rate is below {{{wnf}}} (0.01) times the nominal value, so the system is definitely not singular, even though it's very sensitive to small changes of the pressure state variables. Once the equilibrium condition is reached, implicit adaptive step-size solvers such as dassl or ida should be able to increase the time step dramatically. Unfortunately, for some reason this doesn't happen. If you try running {{{Test1}}}, which has a tolerance of 1e-6 and both pressure losses with a nominal value of 10 Pa, once the valves are closed the pressures quickly get close to each other, but then a permanent numerical oscillation of the mass flow rates {{{pressDrop1.w}}} and {{{pressDrop2.w}}} with amplitude about 0.15 kg/s (which is 15% of the nominal value!) is triggered on the mass flow rate through the pressure losses. This oscillation goes on forever and does not allow the ODE solver to increase the step size above 0.2 ms, thus effectively killing the simulation performance. {{{Test2}}} produces the same situation with an asymmetric small pressure losses (nominal values 10 and 50 Pa, respectively). The frequency of the numerical oscillations is higher and the amplitude somewhat smaller, around 0.04 kg/s, but the final outcome is basically the same. So, the first two questions are: Q1: Why does this happen? Q2: Why do I get an extremely slow, totally unphysical simulation result without the solver complaining at all about anything being suspicious, odd, or close to singular during this transient? Trying to answer this question, I switched off {{{equidistantTimeGrid}}} to better understand what the ODE solver does: {{{Test3}}} has the same parameters as {{{Test1}}} except for this detail. I was indeed very surprised to see the number of steps increasing from 550 to 3000, and the simulation time to increase from 0.6 s to 40 s(!). The oscillation amplitude decreased from 0.15 to 0.05, but the frequency increased dramatically. This leads to two more questions: Q3. Why should {{{equidistantTimeGrid}}} affect the number of steps taken? I understood that the solver takes whatever step length is necessary, and then the solution is re-sampled on the grid if {{{equidistantTimeGrid}}} is enabled, but apparently I am missing something here. Please explain. Q4. Why is the time step per successful step increase 10-fold when {{{equidistantTimeGrid}}} is activated? Unfortunately profiling is currently broken (see #5030) so I can't see where most of the time is spent, but I suspect there's something wrong with the nonlinear system that solves for {{{pressDrop1.w}}} For the record, simulating the model with Dymola leads to the same bad situation, so I guess this is really a fundamental issue with the causalization approach at the solution of this model. Further decreasing the ODE solver tolerance to 1e-7 partially solves the problem, as demonstrated by {{{Test4}}}. The mass flow rate shows some small undershoot below zero, a couple of well-damped oscillations, and then settles down to a constant value of 0.008, which is relatively small w.r.t. the nominal value of one (but definitely non negligible!), at which point the step size starts increasing dramatically. The mass flow rate is somwhat still wrong (it should be zero!) but at least the simulation is not bogged down by fast oscillations. However, in some cases it is not really possible to tighen the tolerance so much, because other issues could arise, particularly in cases where the analytical Jacobian cannot be computed due to the complicated Media functions involved in the model, so that getting very high precision could become problematic. A significantly non-zero value of the flow in this case is non-physical and could lead to other issues with the simulation. Furthermore, these models usually have a lot of approximations, so seeking such a high precision in their time integration is really nonsense, in general. That one needs such a tight tolerance to avoid numerical issues is a sign of something odd going on. I find this situation confusing for an end user. One would expect that reducing the tolerance increases the simulation time, not the other way round, and even more importantly, that a very tight tolerance is not essential for successful simulation. Please note that in many practical applications, this kind of issues can actually cause the simulation to abort, making the simulation of fluid systems where some branches may occasionally be sealed off by closing valves a very critical task. Please note that the values of the parameters I selected are realistic (short pipes have very small dp's), so I'm in no way building an exotic test case just to stress the solver. Last, but not least, if I switch the nonlinear solver to Kinsol, the simulations gets much slower, and a lot of messages such as {{{ LOG_NLS_V | warning | kinsols line search did not convergence. Try without. LOG_NLS_V | warning | kinsols runs into issues retry with different configuration. LOG_NLS_V | warning |

Move forward with a less accurate solution. }}} show up, even though the simulation eventually reaches the end. I guess the root cause of this issue is that the error control is performed on the absolute pressures (which are around 1e5), while the mass flow rate between the two volumes is very sensitive to much smaller delta-p changes of 0.001 or less, ''and'' very strongly nonlinear. Therefore the solver accepts steps which are perfectly fine in terms of relative accuracy of the states (-> absolute pressures) but which can still cause significant perturbations of the flow rate and possibly lead to convergence issues at the next time step, even though the state values change very little between steps. The problem is that once the previous step has been accepted (based on the relative error on the pressure states), there is no way to undo it if the next step has convergence issues: the solver can try to reduce the time step a lot, but it can't go backward in time. According to this interpretation (which I believe in), the problem is not just that the system is ill-conditioned, but that it is also very strongly nonlinear. In fact, if I use ''linear'' pressure drop models with the same dp's, these problems do not show up at all. From this point of view, one option is to increase the {{{wnf}}} parameter of the pressure loss models, which makes the residual function of the algebraic loop much less strongly nonlinear close to zero (and with a larger Jacobian, which doesn't harm), thus helping the convergence. In fact, the empirical evidence is that higher values of {{{wnf}}} on small pressure loss components help avoiding this problem. This strategy somehow saved my neck so far. However, it would be nice if we had robust ways of solving these systems without the need of resorting to these tricks. One possible way of doing this would be to make a state variable change and use the absolute pressure of one volume and the pressure difference between the volumes as states, instead of the two absolute pressures. In this way, a reasonable tolerance like 1e-4 or 1e-5 on both states would avoid getting dp's large enough to cause significant mass flow rate oscillations. In fact, this approach works nicely, see {{{Test5}}}, where the sought after solution is found very quickly and with high accuracy even with a relative tolerance of 1e-3(!), or {{{Test6}}}, where the solution is found very quickly with the original accuracy of 1e-6. The only problem here is that doing this in an object-oriented way is really not possible, because this delta-p spans several components - in which component should I define the {{{p1 - p2}}} variable with the {{{stateSelect.prefer}}} attribute? Also, a static choice of which dp's to use may not be always feasible, in a circuit where valves are opened and closed and parts of the circuit dynamically sealed off from the rest. However, a smart enough back-end may automatically generate code to detect these situations and do the (dynamic) state variable change of its own initiative, selecting the right dp's as states to achieve robust and fast simulation. We may help the back-end doing this by re-using the branch-node mechanism of the overconstrained connectors. @bachmann, @karim.abdelhak, I guess this would be an interesting research topic for you. Another possible point of view on this issue could be to consider this problem as ""close to variable index"". With a purely quadratic flow-dp relationship, the solution at dp = 0 would locally correspond to an index-2 problem, so if the linear regularization around zero flow is not strong enough, the problem becomes ""almost index 2"" when the valves are closed. Maybe this could give you some ideas how to attack the problem. However, this doesn't really include the ""nonlinearity/convergence"" factor which I believe plays an important role. @wbraun, @bachmann, @karim.abdelhak, I would urge you to perform some analysis on this issue and try to come up with possible solutions. This issue has plagued many people doing fluid system modelling for 15+ years (not only myself) and it would be nice to finally get a robust solution based on sound theory, not just hacks. I'm available to help with all possible support on my side, because this is really important for us. At the very least, if this is really a fundamental problem of the underlying equations, then we should issue some diagnostic message to the end-user to try avoiding it, e.g. by suggesting to reduce the tolerance or to make the small dp's less nonlinear close to zero flow." Francesco Casella 5165 Weird behaviour of OMEdit when saving OMEdit defect Adeel Asghar new 2018-10-11T10:42:57Z 2021-09-13T11:58:21Z "I'm using the latest Windows 64 bit nightly build of OMEdit. Sometimes, when saving models, OMEdit takes a really long time to perform a task which is other times much faster. What is weird is that the CPU load reported by Windows for the OMEdit task is not 25% (which would mean one out of four virtual cores of my laptop is working full load) but more like 10-12%. The disk load is close to zero. It is as if the OMEdit process is waiting for some input, but if it not the disk, what could it be? I understand time spent waiting for cache misses response is reported by Windows as busy CPU, so it can't be that. Restarting OMEdit usually (but not always) solves the problem. I understand this is quite difficult to reproduce, but maybe others have observed this behaviour, or you may have an idea of what is causing it." Francesco Casella 5184 Larger models of ScalableTestSuite fail on Hudson because of code generation timeout Testing Framework defect Adrian Pop new 2018-10-24T18:01:21Z 2021-09-13T11:58:21Z "There are currently 4 large models of ScalableTestSuite https://libraries.openmodelica.org/branches/newInst/ScalableTestSuite_noopt/files/ScalableTestSuite_noopt_ScalableTestSuite.Electrical.DistributionSystemAC.ScaledExperiments.DistributionSystemLinearIndividual_N_56_M_56.err https://libraries.openmodelica.org/branches/newInst/ScalableTestSuite_noopt/files/ScalableTestSuite_noopt_ScalableTestSuite.Electrical.DistributionSystemAC.ScaledExperiments.DistributionSystemLinear_N_56_M_56.err https://libraries.openmodelica.org/branches/newInst/ScalableTestSuite_noopt/files/ScalableTestSuite_noopt_ScalableTestSuite.Electrical.DistributionSystemDC.ScaledExperiments.DistributionSystemModelica_N_112_M_112.err https://libraries.openmodelica.org/branches/newInst/ScalableTestSuite_noopt/files/ScalableTestSuite_noopt_ScalableTestSuite.Elementary.WhenEvents.ScaledExperiments.ManyEvents_N_8000_M_10.err }}} that fail with this error: {{{ Failed to read output from testmodel.py, exit status != 0: 2018-10-24 16:38:03,733 - OMPython - INFO - OMC Server is up and running at file:////tmp/openmodelica.hudson.port.e9d7cbe3c6cd4f7ab47b5a4bec8f92ee pid=8924 2018-10-24 16:38:03,997 - OMPython - INFO - OMC Server is up and running at file:////tmp/openmodelica.hudson.port.53feb0cd9bb84d7584d5d5df086e3d3a pid=9007 }}} The same models pass the building phase successfully when {{{--daeMode=new}}} is used (see [https://libraries.openmodelica.org/branches/newInst-daemode/ScalableTestSuite_noopt/ScalableTestSuite_noopt.html newInst-daemode report]). Looking at the times of the various phases in the [https://libraries.openmodelica.org/branches/newInst/ScalableTestSuite_noopt/ScalableTestSuite_noopt.html newInst report] and how they scale, it seems to me that the reason of failure is that the backend or compile time exceeds 300 seconds in those cases and for some reason this problem is not reported correctly. The problem doesn't show up if {{{daeMode=new}}} is used because apparently the backend and compile times scale better, but on the other hand a) daeMode still has other issues and b) it is interesting to be able to compare the times of odeMode and daeMode also for larger models. I would then suggest to increase the timeout of the code generation phases to 600 (or possibly even 1000) seconds. There are only four cases needing that extra time, so I guess this won't change the time to run the entire testsuite significantly." Francesco Casella 5208 IDA with dense numerical jacobian doesn't work well Run-time defect Willi Braun accepted 2018-11-07T23:08:17Z 2021-09-13T11:58:21Z "Please run the following test model in OMEdit {{{ model Thermal1D parameter Integer nx = 100; parameter Real g = 0.0314785; parameter Real c = 0.2707936; parameter Real Thi = 400; parameter Real Tlo = 0; Real T[nx]; initial equation for x in 1:100 loop T[x] = Tlo; end for; equation c * der(T[1]) = g * (T[2] - T[1]) + 2 * g * (Thi - T[1]); c * der(T[nx]) = g * (T[nx - 1] - T[nx]) + 2 * g * (Tlo - T[nx]); for x in 2:nx-1 loop c * der(T[x]) = g * (T[x - 1] - T[x]) + g * (T[x + 1] - T[x]); end for; annotation( experiment(StartTime = 0, StopTime = 100000, Tolerance = 1e-06, Interval = 200), __OpenModelica_simulationFlags(s = ""ida"")); end Thermal1D; }}} The whole simulation, using the IDA solver, takes about 345 steps, computed in 0.04 s on my laptop. Now, re-simulate the system choosing the (dense) {{{numerical}}} option of Jacobian computation. This time, the solver has lots of trouble increasing the step above a certain value, so it takes about 60000 steps and over 3 s to complete the simulation, and there are 29000 convergence test failures of the solver. This is rather weird, because the system is 100% linear, so there shouldn't be any convergence problem of the BDF algorithm with arbitrarily large time steps, nor should the computation of the Jacobian be problematic by any means. The system is intrinsecally well-scaled, without the need of resorting to nominal attributes for improved scaling. Coloured numeric jacobian works fine, so there is probably little reason to use the full 'dumb' numerical Jacobian, except for performance comparison reasons. In any case, if an option (numerical Jacobian in this case) is available, it should work correctly, otherwise I'd suggest to rather remove it." Francesco Casella 5217 Issue with daeMode result interpolation Run-time defect Willi Braun new 2018-11-12T13:04:17Z 2022-01-24T15:14:35Z "Please check the results of [https://libraries.openmodelica.org/branches/newInst-daemode/ScalableTestSuite_noopt/files/ScalableTestSuite_noopt_ScalableTestSuite.Thermal.Advection.ScaledExperiments.SimpleAdvection_N_200.diff.html ScalableTestSuite.Thermal.Advection.ScaledExperiments.SimpleAdvection_N_200]. A discrepancy is reported on {{{der(Ttilde[1])}}} at time 1.77. If you zoom in, you can see that while the reference results (produced with odeMode) are changing smoothly as expected, the {{{daeMode}}} results are such that one every 5 samples matched exactly, but then there are some irregularities that eventually trigger a verification error. Can you please identify their root cause and make sure the {{{odeMode}}} output is smooth as the daeMode one?" Francesco Casella 5220 Issue with sundials macports Testing Framework defect Adrian Pop new 2018-11-15T21:30:59Z 2021-09-13T11:58:21Z "The MacOSX nightly is broken since 12 Oct. Seems to be a sundials port issue. This should be fixed prior to the 1.13.0 release. " Francesco Casella 5256 Non-linear system iterations Run-time v1.13.0-dev.beta1 defect Francesco Casella assigned 2018-12-21T14:47:48Z 2021-09-13T11:58:21Z "Good afternoon, I'm modeling thermo-fluid systems with OpenModelica. These vectorial equations ""produce"" an algebraic loop (see model ""AlgebraicLoop.test""): Dn = VaporDn(P = P, T = T); Hn = VaporHn(P = P, T = T); The thermo functions are highly dependent on temperature. Every time that the algebraic loop is solved, a lot of iterations are needed: ############ Solve nonlinear system 37 at time 1 ############ initial variable values: [ 1]                       volume.P  =        100169.17         nom =           100000 [ 2]                       volume.T  =        499.97788         nom =              300 Solution status: SOLVED  number of iterations           : 1263  number of function evaluations : 4588  number of jacobian evaluations : 1263 solution values: [ 1]                       volume.P  =        100169.17 [ 2]                       volume.T  =        499.97788 Even when the initial values are really close to the solution, a lot of iterations are needed. Why is this happening? My time step is 1 second and the solver dassl. The thermo belongs to my company, is there a way to share the package only with the developers? Thanks in advance Jose " contacto@… 5258 Top-level parameter tolerance is replaced by OMEdit with the simulation tolerance OMEdit v1.12.0 defect Adeel Asghar new 2018-12-28T08:48:06Z 2021-09-13T11:58:21Z "Hello, Please load in OM the 2 files NewMaster.mo and OneState.mo. Run the model OneState. The parameter value for s.tolerance is correct (0.05) but the parameter value for bads.tolerance is not correct (1e-06). It looks like a bug. Best." J-Ph Tavella 5295 Support Modelica 3.4 lang spec Parser defect Martin Sjölund new 2019-01-24T15:08:04Z 2021-09-13T11:58:21Z " Add --std=3.4 option. See here for more changes: https://github.com/modelica/ModelicaStandardLibrary/commit/60286e021ebff0d0a021715ce790c8fe4a5caf91#commitcomment-32050719 We start with the Parser component (probably not needed) then we will move to support for extra operators in CF and NF and Backend. " Adrian Pop 5312 OMEdit does not handle final parameter bindings properly NF API v1.14.0-dev-nightly defect Adrian Pop assigned 2019-02-03T17:31:12Z 2021-09-13T11:58:21Z "Please consider the attached test package. There are currently three issues with OMEdit related to the final prefix. 1. If you open model B, display the graphic view, and double-click on {{{a}}}, you can't set/unset the {{{final}}} attribute on {{{p1}}} 2. If you open model {{{C}}} and double-click on {{{a}}}, you still see parameter {{{p1}}}, which shouldn't be the case, as it is modified with a {{{final}}} prefix in the ancestor model {{{B}}} 3. If you then open model {{{B}}}, change the value of {{{p1}}} in the GUI, and save the model, the {{{final}}} prefix is actually removed from the code OMEdit should allow to set/unset the {{{final}}} prefix when setting parameter values, and should also consider the {{{final}}} prefix in ancestor classes when deciding whether or not to display the parameter in the parameter window." Francesco Casella 5327 zoom factor in OMEdit animation OMEdit defect Volker Waurich new 2019-02-11T14:40:08Z 2021-09-13T11:58:21Z I'm simulating a small system (maximum size about 0,01 m) and finding that the zoom factor (rolling the mouse wheel) maxes out when the image is still very small. Adeel Asghar 5353 Enhance the LOG_STATS output to tell apart time spent by the solver and by the generated code Run-time defect Lennart Ochel new 2019-02-21T14:48:33Z 2021-09-13T11:58:21Z "At the heart of the process of optimizing simulation performance is the ability to tell apart how much time is spent by the solver (DASSL, IDA, etc.), and how much time is spent by omc-generated code to compute residuals, jacobians, variables, zero-crossing functions etc. The LOG_STATS output should contain a bit more detailed information about this." Francesco Casella 5358 Switch windows installer from SVN to GIT Installation program defect Adrian Pop accepted 2019-02-25T13:55:24Z 2021-09-13T11:58:21Z " For Windows release use scripts from: https://github.com/OpenModelica/OpenModelicaSetup instead of old SVN: https://openmodelica.org/svn/OpenModelica/installers/windows/OpenModelicaSetup " Adrian Pop 5360 Issues with diffModelicaFileListings Interactive Environment defect Martin Sjölund new 2019-02-26T10:16:20Z 2021-09-13T11:58:21Z When duplicating a class `diffModelicaFileListings` is used to preserve the formatting from source to destination class. Unfortunately the API fails for very basic cases. See the attached scripts. The duplication and diff at the top level works as expected (see attachment:toplevel.mos). However, the duplication and diff within a package doesn't work (see attachment:within.mos) Adeel Asghar 5361 Inconsistent Variable Filter between .mat and .csv format Run-time v1.13.0 defect Lennart Ochel new 2019-02-26T14:57:07Z 2021-09-13T11:58:21Z "Below is an arbitary model of electrical circuit with 5 resistors. When i apply the filter {{{R[0-9]\.p\.i}}} i expected to get all the current flow from each p pin of resistors (and some other variable due to alias variable). But somehow i got an unexpected results. For example:[[BR]][[BR]] R1.p.i and R2.p.i are not saved[[BR]] R4.i and R5.i are saved due to i=p.i in Interfaces.OnePort but not for R1-3[[BR]] with the .mat format i got all the current R(1-5).p.i; R4.i and R5.i are still there but not for R(1-3). why it is seem inconsistent? i understand the part where .mat saves the parameter but .csv not. but the filter variable result shoud be identical, is it not? thanks again for your time cheers {{{ model Arbitary Modelica.Electrical.Analog.Sources.ConstantCurrent constantCurrent1 annotation( Placement(visible = true, transformation(origin = {-80, 0}, extent = {{-10, -10}, {10, 10}}, rotation = 90))); Modelica.Electrical.Analog.Basic.Ground ground1 annotation( Placement(visible = true, transformation(origin = {-80, -30}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Electrical.Analog.Basic.Resistor R1(R = 1) annotation( Placement(visible = true, transformation(origin = {-64, 40}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Electrical.Analog.Basic.Resistor R2(R = 2) annotation( Placement(visible = true, transformation(origin = {-30, 40}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Electrical.Analog.Basic.Resistor R3(R = 3) annotation( Placement(visible = true, transformation(origin = { 0, -28}, extent = {{-10, -10}, {10, 10}}, rotation = -90))); Modelica.Electrical.Analog.Basic.Resistor R4(R = 5) annotation( Placement(visible = true, transformation(origin = {30, -28}, extent = {{-10, -10}, {10, 10}}, rotation = -90))); Modelica.Electrical.Analog.Basic.Resistor R5(R = 6) annotation( Placement(visible = true, transformation(origin = {60, -28}, extent = {{-10, -10}, {10, 10}}, rotation = -90))); Modelica.Electrical.Analog.Ideal.IdealOpeningSwitch switch annotation( Placement(visible = true, transformation(origin = {0, 10}, extent = {{-10, 10}, {10, -10}}, rotation = -90))); Modelica.Electrical.Analog.Basic.Ground ground2 annotation( Placement(visible = true, transformation(origin = {0, -56}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Electrical.Analog.Basic.Ground ground3 annotation( Placement(visible = true, transformation(origin = {30, -56}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Electrical.Analog.Basic.Ground ground4 annotation( Placement(visible = true, transformation(origin = {60, -56}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Electrical.Analog.Ideal.IdealCommutingSwitch switch1 annotation( Placement(visible = true, transformation(origin = {42, 10}, extent = {{-10, -10}, {10, 10}}, rotation = -90))); Modelica.Blocks.Sources.BooleanExpression booleanExpression1 annotation( Placement(visible = true, transformation(origin = {-32, 10}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Blocks.Sources.BooleanExpression booleanExpression2 annotation( Placement(visible = true, transformation(origin = {80, 10}, extent = {{10, -10}, {-10, 10}}, rotation = 0))); equation connect(booleanExpression2.y, switch1.control) annotation( Line(points = {{70, 10}, {56, 10}, {56, 10}, {54, 10}}, color = {255, 0, 255})); connect(booleanExpression1.y, switch.control) annotation( Line(points = {{-20, 10}, {-12, 10}, {-12, 10}, {-12, 10}}, color = {255, 0, 255})); connect(R2.n, switch1.p) annotation( Line(points = {{-20, 40}, {42, 40}, {42, 20}, {42, 20}}, color = {0, 0, 255})); connect(switch1.n1, R5.p) annotation( Line(points = {{46, 0}, {60, 0}, {60, -18}, {60, -18}}, color = {0, 0, 255})); connect(R2.n, switch.p) annotation( Line(points = {{-20, 40}, {0, 40}, {0, 20}}, color = {0, 0, 255})); connect(R3.p, switch.n) annotation( Line(points = {{0, -18}, {0, 0}}, color = {0, 0, 255})); connect(switch1.n2, R4.p) annotation( Line(points = {{42, 0}, {30, 0}, {30, -18}, {30, -18}}, color = {0, 0, 255})); connect(ground3.p, R4.n) annotation( Line(points = {{30, -46}, {30, -38}}, color = {0, 0, 255})); connect(ground4.p, R5.n) annotation( Line(points = {{60, -46}, {60, -46}, {60, -38}, {60, -38}}, color = {0, 0, 255})); connect(ground2.p, R3.n) annotation( Line(points = {{0, -46}, {0, -46}, {0, -38}, {0, -38}}, color = {0, 0, 255})); connect(R1.p, constantCurrent1.n) annotation( Line(points = {{-74, 40}, {-80, 40}, {-80, 10}, {-80, 10}}, color = {0, 0, 255})); connect(R2.p, R1.n) annotation( Line(points = {{-40, 40}, {-54, 40}, {-54, 40}, {-54, 40}}, color = {0, 0, 255})); connect(ground1.p, constantCurrent1.p) annotation( Line(points = {{-80, -20}, {-80, -20}, {-80, -10}, {-80, -10}}, color = {0, 0, 255})); annotation( Icon(coordinateSystem(preserveAspectRatio = false)), uses(Modelica(version = ""3.2.3"")), experiment(StartTime = 0, StopTime = 1, Tolerance = 1e-6, Interval = 0.002), __OpenModelica_simulationFlags(lv = ""LOG_STATS"", outputFormat = ""csv"", s = ""dassl""));end Arbitary; }}} " trista.arinomo@… 5384 An output is not correct with OM while the same model perfectly operates under Dymola Run-time v1.13.0 defect Karim Adbdelhak assigned 2019-03-12T16:44:27Z 2021-09-13T11:58:21Z "Dear All, Please open the attached file RealIssue.mo under OM and run the model TestRealTransmission in Basic.Tests for 6 s. Now,visualize the variables: realTransmission.u[4], and ealTransmission.y[4]. The starting value for y[4] is not correct as it should be initialized to 0.5 and keep this value during the first second. The same model perfectly runs under Dymola so this appears as a mistake. Best" Jean-Philippe Tavella 5389 Creation of Complex array fails Code Generation v1.14.0-dev-nightly defect Karim Adbdelhak assigned 2019-03-14T13:03:09Z 2021-09-13T11:58:21Z "Creating an array of Complex fails. I think I'm not doing anything wrong (Dymola compiles!) {{{ model complexArray Complex compl_arr_not_working[1]; Complex compl_working; Complex compl_arr_working[1] = {Complex(1.0)}; // this DOES work algorithm compl_arr_not_working := {Complex(1.0)}; // this does NOT work compl_working := Complex(1.0); // this DOES work end complexArray; }}} " dariomangoni@… 5398 getClassInformation returns wrong source info Interactive Environment defect somebody new 2019-03-19T17:45:03Z 2021-09-13T11:58:21Z "Run the attached script. `getClassInformation(Modelica.Mechanics.MultiBody.World.gravityAcceleration)` returns, {{{ (""function"","""",false,false,false,""C:/OpenModelica/build/lib/omlibrary/Modelica 3.2.3/Mechanics/MultiBody/package.mo"",false,1185,15,1188,8,{},false,false,"""","""",false,"""") }}} The line and column end information is wrong. It gives `1188` and `8` but it should be `1201` and `11`." Adeel Asghar 5404 Module RemoveSimpleEquations doesn't support synchronous systems Backend defect Karim Adbdelhak assigned 2019-03-25T15:23:04Z 2022-01-05T12:49:46Z "This simple synchronous equation system {{{#!modelica model Example1 Real x, y; equation when Clock(0.1) then x + y = 0; x - y = 0; end when; end Example1; }}} produce an under-determined system {{{ ######################################## dumpindxdae ######################################## clocked partition(1) ======================================== Variables (2) ======================================== 1: y:VARIABLE() type: Real 2: x:VARIABLE() type: Real Equations (2, 2) ======================================== 1/1 (1): -1.0 = 1.0 [dynamic |0|0|0|0|] 2/2 (1): y = -x [dynamic |0|0|0|0|] Matching ======================================== 2 variables and equations var 1 is solved in eqn 2 var 2 is solved in eqn 1 StrongComponents ======================================== {1:2} Size: 1 Generic Jacobian via directional derivatives {2:1} BackendDAEType: simulation Base partitions (1) ======================================== 1: Clock(0.1)[1] Sub partitions (1) ======================================== 1: factor(1/1) shift(0/1) event(false) }}} optdaedump output shows that module '''removeSimpleEquations''' skip synchronous equations and module '''comSubExp''' produce wrong equation system. {{{ ######################################## pre-optimization module comSubExp (simulation) ######################################## clocked partition(1) ======================================== Variables (2) ======================================== 1: y:VARIABLE() type: Real 2: x:VARIABLE() type: Real Equations (2, 2) ======================================== 1/1 (1): (-x) / x = 1.0 [dynamic |0|0|0|0|] 2/2 (1): x + y = 0.0 [dynamic |0|0|0|0|] no matching BackendDAEType: simulation Base partitions (1) ======================================== 1: Clock(0.1)[1] Sub partitions (1) ======================================== 1: factor(1/1) shift(0/1) event(false) }}} " Maksimov Doe 5410 Properly indent dragged-and-dropped components Interactive Environment defect Martin Sjölund assigned 2019-03-27T09:19:09Z 2021-09-13T11:58:21Z When dragging and dropping a component in a model, the corresponding declararion should be indented by 2 characters, according to the common custom of hand-written Modelica models Francesco Casella 5419 Interactive simulation crashing due to missed deadlines for all but the simplest models *unknown* v1.13.2 defect somebody new 2019-04-03T11:33:32Z 2021-09-13T11:58:21Z "I currently try to get to run interactive simulations decently, but I am struggling. I am using the stable OpenModelica 1.13.2 release. I compile Modelica.Mechanics.Rotational.Examples.First and run it with embedded server (standard settings, no stepping mode, port 4841). Connecting to the server via UAExpert works. I then set ""enableStopTime"" to false and set ""run"" to true. I then get several red error logs about ""Missed deadline at time XX"" and then the simulation process crashes. I quickly put together a very simple model with one RealInput u, which simply solves der(y) = u. If I compile it the same way as described above, it works as intended. I can even change at runtime (as would be expected). I do hope that the interactive simulation feature will not be falling into oblivion in the time to come. Especially from industrial perspective, I think it is an important feature, enabling lots and lots of different use cases. Hopefully my bug report is helpful. If not, please don't hesitate to ask. Thanks a lot. " RSchiemann 5421 New FMU (OMEdit 1.13.2) failed load from cffi in lisp FMI v1.13.2 defect Lennart Ochel new 2019-04-04T04:52:05Z 2021-09-13T11:58:21Z "Thank you for your great work. I am working on Debian 64bit on a personal project creating a lisp package that loads FMU using cffi interface (similar to the python). For info I am working with emacs+slime+sbcl last year. This all worked well so far and managed to connect to the fmu instance and fmi2-get-real or get-differential :-) if I may say. The instantiation of a model exchange interface worked fine until some modifications in the FMU export (I am working with me and cs exports) in OMEdit 1.13.2. Thank you for your support I am not asking about lisp and cffi here as it already worked with a previous fmu in an older OMEdit but could you give me some ideas about what has been modified in the new version ? I have checked the fmi2Functions.h of both FMUs the old and the new and nothing has changed here. The fmu2_model_interface.c has changed. Are you aware of any issues that might help me here to go a little bit further ? PS : Sorry I didn't track the previous OMEdit version that used to work :-( but it was definitely working last year. " FBXon2ROX 5438 Process crashed Simulation Process Failed. Exited with code -1073741511. OMEdit v1.13.2 defect Adeel Asghar new 2019-04-17T05:19:09Z 2019-04-23T10:17:07Z "Example: C:/OpenModelica/lib/omlibrary/Modelica 3.2.2/Electrical/Analog/Examples/ChuaCircuit.mo Error for OM v1.11, v1.12, v1.13 C:/OpenModelica/temp/Modelica.Electrical.Analog.Examples.ChuaCircuit.exe -port=52234 -logFormat=xmltcp -override=startTime=0,stopTime=50000,stepSize=1,tolerance=1e-06,solver=dassl,outputFormat=mat,variableFilter=.* -r=Modelica.Electrical.Analog.Examples.ChuaCircuit_res.mat -jacobian=coloredNumerical -w -lv=LOG_STATS Process crashed Simulation Process Failed. Exited with code -1073741511." kasandranas 5461 OMEdit crashes(Windows)/does nothing(Linux) when instance has same name as package OMEdit v1.14.0-dev-nightly defect Per Östlund reopened 2019-05-07T13:53:19Z 2021-09-13T11:58:21Z "In the attached small package the model `TestGen` contains an instance of the model `EMF` which is named ""DiscGenerator"" just like the package. This seems to cause all kinds of problems which crashes OMEdit on Windows and throws errors in Linux. Changing the instance name to something else like ""discGenerator"" solves the problem. (Mind the models in the example package contain other modelling errors, but are not of interest here. I wanted to keep the example as original as possible.)" Dietmar Winkler 5465 Issue with locked-rotor Asynchronous Machine model Run-time v1.14.0-dev-nightly defect Karim Adbdelhak assigned 2019-05-09T13:28:50Z 2021-09-13T11:58:21Z "I have a very simple test based on an MSL example: {{{#!mo model LockedRotorTest extends Modelica.Electrical.Machines.Examples.AsynchronousInductionMachines.AIMC_DOL(aimc(useSupport=true)); equation connect(aimc.support, aimc.flange) annotation (Line(points={{0,-50},{0,-40}}, color={0,0,0})); end LockedRotorTest; }}} It's basically an electrical machine that just got its rotor locked to the support. In Dymola simulating 1 second takes about 0.1 seconds. Trying the same in OMEdit bascially locks the machine. I've now been waiting for more than one hour and the simulation still does not finish. Is this simply a solver setting problem or more an underlying OMC problem? " Dietmar Winkler 5474 [NF] Lookup of inner class fails New Instantiation defect Per Östlund new 2019-05-10T20:15:18Z 2021-09-13T11:58:21Z "Trying to instantiate the inside model P fails with: {{{ ""C:/home/adrpo33/dev/OpenModelica/OMCompiler/Compiler/NFFrontEnd/NFLookup.mo:870:9-870:101:writable] Error: Internal error NFLookup.generateInner got top node with missing cache [C:/home/adrpo33/dev/OpenModelica/OMCompiler/Compiler/NFFrontEnd/NFInst.mo:2318:9-2318:91:writable] Error: Internal error NFInst.instComponentExpressions got invalid component Error: Class M.P not found in scope . "" }}} Script to reproduce: {{{#!mo loadModel(Modelica); getErrorString(); loadString("" class M extends .Modelica.Mechanics.MultiBody.Joints.FreeMotionScalarInit; class P parameter Real x; end P; end M;""); getErrorString(); instantiateModel(M.P); getErrorString(); }}} The problem is that the lookup is done before initialization of top scope cache for inners: {{{#!mo // Look up the class to instantiate and mark it as the root class. cls := Lookup.lookupClassName(classPath, top, Absyn.dummyInfo, checkAccessViolations = false); cls := InstNode.setNodeType(InstNodeType.ROOT_CLASS(InstNode.EMPTY_NODE()), cls); // Initialize the storage for automatically generated inner elements. top := InstNode.setInnerOuterCache(top, CachedData.TOP_SCOPE(NodeTree.new(), cls)); }}} " Adrian Pop 5480 Automatic formatting does not respect indentation OMEdit v1.14.0-dev-nightly defect Adeel Asghar new 2019-05-14T12:34:01Z 2021-09-13T11:58:21Z "Indentation is not respected when autoformatting. [[Image(https://imgur.com/a/Qn15AT7)]]" dariomangoni@… 5491 Interactive simulation ignores RealInput changes when using kinsol as nonlinear solver *unknown* v1.14.0-dev-nightly defect somebody new 2019-05-17T12:10:01Z 2021-09-13T11:58:21Z "Steps to reproduce the problem: Compile & run the following model with the following options: - stoptime 10, 500 Intervals - interactive simulation without steps on port 4841 - integration with dassl, tolerance 1e-4, jacobian symbolical - uncheck ""Evaluate all parameters"" - chose kinsol as nonlinear solver The model: {{{ model testUA Modelica.Blocks.Interfaces.RealInput u; Real y[1000]; equation der(y[1]) + y[1] = u; for i in 2:1000 loop der(y[i]) + y[i] = y[i-1]; end for; end testUA; }}} With the above parameters, I am not able to change u from UA Expert. When I change dassl tolerance to 1e-6, it works. It seems strange that the ability to change a simulation input depends on the solver tolerance. Can you please fix that? I have the following setup: OMEdit v1.14.0-dev-26461-gf6f5727072 (64-bit) Connected to v1.14.0-dev-26461-gf6f5727072 (64-bit) Connected to OMSimulator v2.1.0-dev-103-g9e04b31-mingw UA Expert 1.5.0 319" RSchiemann 5496 Model structure and Jacobian for vectorized models Backend defect Lennart Ochel new 2019-05-20T07:30:48Z 2021-09-13T11:58:21Z "FMU export with `-d,newInst,-nfScalarize` generates wrong FMI ModelStructure and Jacobian. See this example from the test suite: https://github.com/OpenModelica/OpenModelica-testsuite/blob/master/openmodelica/cppruntime/testVectorizedBlocks.mos Here is a version extended with the additional output `y_sum` and reduced to `n=3`: {{{#!mo model VectorizedBlocksTest parameter Integer n = 3; Modelica.Blocks.Interfaces.RealInput u[n](start = 1:n); Modelica_Synchronous.ClockSignals.Clocks.PeriodicRealClock periodicClock1(period = 0.1, useSolver=true, solverMethod=""ImplicitEuler""); Modelica_Synchronous.RealSignals.Sampler.AssignClockVectorized assignClock1(n = n); Modelica.Blocks.Continuous.Integrator integrator1[n](y_start = 1:n); Modelica.Blocks.Interfaces.RealOutput y[n]; Modelica.Blocks.Interfaces.RealOutput y_sum; equation y_sum = sum(y); connect(u, assignClock1.u); connect(periodicClock1.y, assignClock1.clock); connect(assignClock1.y, integrator1.u); connect(integrator1.y, y); annotation( uses(Modelica(version = ""3.2.2""), Modelica_Synchronous(version = ""0.92.1""))); end VectorizedBlocksTest; }}} Apply this command sequence {{{#!mo setCommandLineOptions(""--simCodeTarget=Cpp""); getErrorString(); setCommandLineOptions(""--std=3.3""); getErrorString(); setCommandLineOptions(""-d=newInst""); getErrorString(); //setCommandLineOptions(""-d=newInst,disableFMIDependency""); getErrorString(); //setCommandLineOptions(""-d=newInst,-nfScalarize""); getErrorString(); loadFile(""VectorizedBlocksTest.mo""); getErrorString(); translateModelFMU(VectorizedBlocksTest, version = ""2.0""); getErrorString(); }}} The flag `-d=newInst` gives the correct model structure (see modelDescription.xml): {{{#!xml }}} The flags `-d=newInst,disableFMIDependency` bypass dependency analysis and just list the correct variables in the model structure: {{{#!xml }}} The flags `-d=newInst,-nfScalarize` lead to a wrong dependency analysis: {{{#!xml }}} The vectorized sim code obtained with `-d=newInst,-nfScalarize,dumpSimCode` reads: {{{ 25: $CLKPRE.integrator1.y=integrator1.y [Real[3] ] 16: assignClock1.u=u [Real[3] ] 17: assignClock1.y=assignClock1.u [Real[3] ] 18: integrator1.u=assignClock1.y [Real[3] ] 19 FOR-LOOP: for $i in (1:3) loop $DER.integrator1[$i].y=integrator1[$i].u[Real ] end for; 20 FOR-LOOP: for i in (1:3) loop integrator1[i].y=(if firstTick() then 0.0 else $DER.integrator1[i].y) * interval() + previous(integrator1[i].y)[Real ] end for; 21: $outputAlias_y=integrator1.y [Real[3] ] 22: $outputAlias_y_sum=sum($outputAlias_y) [Real ] 23: y_sum=$outputAlias_y_sum [Real ] 24: y=$outputAlias_y [Real[3] ] }}} The Jacobian code of the backend needs to be extended with the treatment of - 1:1 assignments of arrays - for-loops - sum of vector" Rüdiger Franke 5501 Occuring of error while saving a modified model Interactive Environment v1.13.2 defect Adrian Pop assigned 2019-05-23T11:57:34Z 2021-09-13T11:58:21Z "Whenever I try to save my model after modifying its content; OMEdit show some abrupt behavior, for instance, the random line from my packages are shown or only a blank line is there and after that, It shows error at some random line {{{ ''Syntax Error: No viable alternative near token: ^'' }}} ; even if there is no change in that line. " mehulsutariya09@… 5570 DrumBoiler Backend v1.13.2 defect Karim Adbdelhak assigned 2019-07-08T12:16:49Z 2021-09-13T11:58:21Z "Hello, everyone! I tried to run the drumboiler example from Fluid library changing the medium from StandardWater to R134a_ph, but it doesn`t run. I duplicated and ran it with water first just to make sure it would work after de duplication (it did work after I added Modelica. on the places it was missing). When I try with R134a_ph it gives the following message: [1] 09:06:50 Symbolic Warning The model contains alias variables with conflicting start and/or nominal values. It is recommended to resolve the conflicts, because otherwise the system could be hard to solve. To print the conflicting alias sets and the chosen candidates please use -d=aliasConflicts. [2] 09:06:50 Translation Error Internal error Selection of DummyDerivatives failed due to negative system rank of -1! There are 1 unassigned equations and 0 potential states. [3] 09:06:50 Translation Error Internal error - IndexReduction.selectDummyDerivatives2new failed! [4] 09:06:50 Translation Error Internal error - IndexReduction.processComps4New failed! [5] 09:06:50 Translation Error Internal error - IndexReduction.dynamicStateSelectionWork failed! " Ref_systems 5580 --evaluateProtectedParameters should default to true Backend defect Karim Adbdelhak new 2019-07-12T13:12:02Z 2021-09-13T11:58:21Z "I scanned the specification looking for the various meanings of {{{protected}}}, trying to understand how should we deal with {{{protected}}} parameters. In particular, Section 4.1 states: A protected element, P, in classes and components may not be accessed via dot notation (e.g., A.P, a.P, a[1].P, a.b.P, .A.P; but there is no restriction on using P or P.x for a protected element P). They may not be modified or redeclared except for modifiers applied to protected elements in a base-class modification (not inside any component or class) and the modifier on the declaration of the protected element. As far as {{{final}}} is concerned, Section 7.2.6 states An element defined as final by the final prefix in an element modification or declaration cannot be modified by a modification or by a redeclaration We all agree that the interpretation of {{{final}}} can be extended to mean that you can't change the parameter value ''at runtime''. What I understand from the two excerpts of the specifications is that from this point of view there is no difference between a {{{final}}} parameter and a {{{protected}}} parameter: both cannot be modified. Redeclarations do not apply at runtime, because we are using statically compiled models,so they are ruled out anyway. Conclusion: - there is no reason to treat {{{protected}}} parameters differently from {{{final}}} parameters - {{{--evaluateProtectedParameters}}} should default to {{{true}}}." Francesco Casella 5614 error in FMU instantiate in case of large models FMI v1.13.2 defect Lennart Ochel new 2019-08-07T09:18:46Z 2021-09-13T11:58:21Z "Hi, I am working in the frame of a big project funded by the Italian electric transmission system operator (TSO). We are developing a dynamic simulator of electric grids of large dimensions. For this task we build the dynamic models using FMUs compiled by means of OpenModelica. FMUs are then called by an own developed main application which solves the DAE overall system using open source numerical solutors (Sundials and others). For this project we use Qt Creator 4.7.1 Based on Qt 5.9.7 (MSVC 2015, 32 bit). Till a month ago we were using an old version of OpenModelica (v1.12.0-dev.alpha1 32 bit for Windows) with satisfactory resuls even with huge models (with more than 10 thousands of FMU instances). Now trying to switch to the official last version of OpenModelica(v1.13.2 32 bit for Windows) we get a crash in the FMU instatiate of large models (with more than 1000 instances). In order to reproduce the error in a much less complex context we have developed a simple main application based on the main.c source code (from FMU SDK A C library by QTronic) downloaded from a link located in https://fmistandard.org/downloads/. This main.c has been sligtly modified in order to make many instances of the same FMU (a simple model with 1 input 1 output and 1 state) and the error has been reproduced. If it could help I can send you the source code. Best Regards Francesco Pretolani CESI S.p.A. Via Rubattino, 54 - 20134 Milano (Italy) email: pretolani@cesi.it" pretolani@… 5632 Error creating an fmu with 'Modelica_DeviceDrivers' (1.7.1) block 'Blocks.Communication.UDPSend' FMI defect Lennart Ochel new 2019-09-11T05:22:03Z 2021-09-13T11:58:21Z "Hi all, I'm running into some issues compiling an fmu containing the block 'Modelica_DeviceDrivers.Blocks.Communication.UDPSend' A Model which compiles with OM 1.12 and compiled with v1.14.0-dev-81-g38fd61a5f (64-bit) doesn't compile anymore using the latest nightly build. (also not with 1.13 release version) Error is something like: In file included from openmodelica_func.h:52:0, from TestSerialPackager_UDP_FMU.c:10: util/modelica_string.h:71:5: note: expected 'const char **' but argument is of type 'char **' int GC_vasprintf(const char **strp, const char *fmt, va_list ap); for testing you can duplicate the example 'TestSerialPackager_UDP' (you have to adapt ist as the 'addFloat' isn't recognized) my own model (converting two floats to integer and storing them to a string, and sending the string to UDP) compiles without any warings with with Dymola v2018-FD01, thus I think the model is ok. would be great if someone could find the root cause of the error and fix it. thanks a lot!! Gü PS: - installed OM 1.14 in C:\ - other models compile without any error - below the messages when running the model in OM, and creating an fmu _________________________________________ compiler messages when running the model: _________________________________________ C:/OpenModelica1.14.0-dev-64bit//share/omc/scripts/Compile.bat TestSerialPackager_UDP gcc mingw64 parallel 8 0 PATH = ""C:\OPENMO~1.0-D\tools\msys\mingw64\bin;C:\OPENMO~1.0-D\tools\msys\mingw64\bin\..\..\usr\bin;"" mingw32-make: Entering directory 'C:/Users/u12l96/AppData/Local/Temp/OPENMO~1/OMEdit/TESTSE~2' gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -I""C:/OpenModelica1.14.0-dev-64bit//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=TestSerialPackager_UDP -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o TestSerialPackager_UDP.o TestSerialPackager_UDP.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -I""C:/OpenModelica1.14.0-dev-64bit//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=TestSerialPackager_UDP -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o TestSerialPackager_UDP_functions.o TestSerialPackager_UDP_functions.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -I""C:/OpenModelica1.14.0-dev-64bit//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=TestSerialPackager_UDP -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o TestSerialPackager_UDP_records.o TestSerialPackager_UDP_records.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -I""C:/OpenModelica1.14.0-dev-64bit//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=TestSerialPackager_UDP -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o TestSerialPackager_UDP_01exo.o TestSerialPackager_UDP_01exo.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -I""C:/OpenModelica1.14.0-dev-64bit//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=TestSerialPackager_UDP -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o TestSerialPackager_UDP_02nls.o TestSerialPackager_UDP_02nls.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -I""C:/OpenModelica1.14.0-dev-64bit//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=TestSerialPackager_UDP -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o TestSerialPackager_UDP_03lsy.o TestSerialPackager_UDP_03lsy.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -I""C:/OpenModelica1.14.0-dev-64bit//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=TestSerialPackager_UDP -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o TestSerialPackager_UDP_04set.o TestSerialPackager_UDP_04set.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -I""C:/OpenModelica1.14.0-dev-64bit//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=TestSerialPackager_UDP -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o TestSerialPackager_UDP_05evt.o TestSerialPackager_UDP_05evt.c TestSerialPackager_UDP_functions.c: In function 'omc_Modelica__DeviceDrivers_Packaging_SerialPackager___addInteger': TestSerialPackager_UDP_functions.c:219:42: warning: passing argument 2 of 'MDD_SerialPackagerAddInteger' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] MDD_SerialPackagerAddInteger(_pkg_ext, (const int*) _u_c89, size_of_dimension_base_array(_u, ((modelica_integer) 1)), _byteOrder_ext); ^ In file included from TestSerialPackager_UDP_includes.h:4:0, from TestSerialPackager_UDP_functions.c:7: C:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include/MDDSerialPackager.h:243:16: note: expected 'int *' but argument is of type 'const int *' DllExport void MDD_SerialPackagerAddInteger(void* p_package, int * u, size_t n, int endian) { ^ gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -I""C:/OpenModelica1.14.0-dev-64bit//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=TestSerialPackager_UDP -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o TestSerialPackager_UDP_06inz.o TestSerialPackager_UDP_06inz.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -I""C:/OpenModelica1.14.0-dev-64bit//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=TestSerialPackager_UDP -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o TestSerialPackager_UDP_07dly.o TestSerialPackager_UDP_07dly.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -I""C:/OpenModelica1.14.0-dev-64bit//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=TestSerialPackager_UDP -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o TestSerialPackager_UDP_08bnd.o TestSerialPackager_UDP_08bnd.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -I""C:/OpenModelica1.14.0-dev-64bit//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=TestSerialPackager_UDP -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o TestSerialPackager_UDP_09alg.o TestSerialPackager_UDP_09alg.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -I""C:/OpenModelica1.14.0-dev-64bit//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=TestSerialPackager_UDP -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o TestSerialPackager_UDP_10asr.o TestSerialPackager_UDP_10asr.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -I""C:/OpenModelica1.14.0-dev-64bit//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=TestSerialPackager_UDP -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o TestSerialPackager_UDP_11mix.o TestSerialPackager_UDP_11mix.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -I""C:/OpenModelica1.14.0-dev-64bit//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=TestSerialPackager_UDP -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o TestSerialPackager_UDP_12jac.o TestSerialPackager_UDP_12jac.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -I""C:/OpenModelica1.14.0-dev-64bit//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=TestSerialPackager_UDP -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o TestSerialPackager_UDP_13opt.o TestSerialPackager_UDP_13opt.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -I""C:/OpenModelica1.14.0-dev-64bit//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=TestSerialPackager_UDP -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o TestSerialPackager_UDP_14lnz.o TestSerialPackager_UDP_14lnz.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -I""C:/OpenModelica1.14.0-dev-64bit//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=TestSerialPackager_UDP -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o TestSerialPackager_UDP_15syn.o TestSerialPackager_UDP_15syn.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -I""C:/OpenModelica1.14.0-dev-64bit//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=TestSerialPackager_UDP -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o TestSerialPackager_UDP_16dae.o TestSerialPackager_UDP_16dae.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -I""C:/OpenModelica1.14.0-dev-64bit//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=TestSerialPackager_UDP -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o TestSerialPackager_UDP_17inl.o TestSerialPackager_UDP_17inl.c gcc -I. -o TestSerialPackager_UDP.exe TestSerialPackager_UDP.o TestSerialPackager_UDP_functions.o TestSerialPackager_UDP_records.o TestSerialPackager_UDP_01exo.o TestSerialPackager_UDP_02nls.o TestSerialPackager_UDP_03lsy.o TestSerialPackager_UDP_04set.o TestSerialPackager_UDP_05evt.o TestSerialPackager_UDP_06inz.o TestSerialPackager_UDP_07dly.o TestSerialPackager_UDP_08bnd.o TestSerialPackager_UDP_09alg.o TestSerialPackager_UDP_10asr.o TestSerialPackager_UDP_11mix.o TestSerialPackager_UDP_12jac.o TestSerialPackager_UDP_13opt.o TestSerialPackager_UDP_14lnz.o TestSerialPackager_UDP_15syn.o TestSerialPackager_UDP_16dae.o TestSerialPackager_UDP_17inl.o ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -I""C:/OpenModelica1.14.0-dev-64bit//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=TestSerialPackager_UDP -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -L""C:/Users/u12l96/AppData/Local/Temp/OpenModelica/OMEdit/TestSerialPackager_UDP"" -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -I""C:/OpenModelica1.14.0-dev-64bit//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=TestSerialPackager_UDP -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -L""C:/OpenModelica1.14.0-dev-64bit//lib//omc"" -L""C:/OpenModelica1.14.0-dev-64bit//lib"" -Wl,--stack,16777216,-rpath,""C:/OpenModelica1.14.0-dev-64bit//lib//omc"" -Wl,-rpath,""C:/OpenModelica1.14.0-dev-64bit//lib"" -fopenmp -Wl,-Bstatic -lregex -ltre -lintl -liconv -lexpat -lomcgc -lpthread -loleaut32 -limagehlp -lhdf5 -lz -lszip -Wl,-Bdynamic -Wl,-Bstatic -lSimulationRuntimeC -Wl,-Bdynamic -Wl,-Bstatic -lomcgc -lregex -ltre -lintl -liconv -lexpat -static-libgcc -luuid -loleaut32 -lole32 -limagehlp -lws2_32 -llis -lumfpack -lklu -lcolamd -lbtf -lamd -lsundials_idas -lsundials_kinsol -lsundials_nvecserial -lipopt -lcoinmumps -lpthread -lm -lgfortranbegin -lgfortran -lquadmath -lmingw32 -lgcc_eh -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lopenblas -lcminpack -Wl,-Bdynamic -lwsock32 -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic mingw32-make: Leaving directory 'C:/Users/u12l96/AppData/Local/Temp/OPENMO~1/OMEdit/TESTSE~2' Compilation process finished successfully. _____________________________________________________________ messages when creating an fmu (cs) _____________________________________________________________ [1] 21:52:29 Skripting Warnung Requested package Modelica_Synchronous of version 0.92.2, but this package was already loaded with version 0.93.0. You might experience problems if these versions are incompatible. [2] 21:52:29 Skripting Warnung Requested package Modelica of version 3.2.2, but this package was already loaded with version 3.2.3. You might experience problems if these versions are incompatible. [3] 21:52:29 Skripting Warnung Requested package Modelica_DeviceDrivers of version 1.4.4, but this package was already loaded with version 1.7.1. You might experience problems if these versions are incompatible. [4] 21:52:29 Übersetzung Warnung Alias equations of external objects are not Modelica compliant as in: addInteger.pkgIn.pkg = packager.pkgOut.pkg addInteger.pkgOut[1].pkg = uDPSend.pkgIn.pkg addInteger.pkgOut[1].pkg = addInteger.pkgIn.pkg [5] 21:52:29 Übersetzung Meldung pthreads library is already available. It is not linked from the external library resource directory. [6] 21:52:29 Übersetzung Meldung Ws2_32 library is not needed under Windows. It is not linked from the external library resource directory. [7] 21:52:29 Übersetzung Fehler Fehler beim Bauen des Simulators. Build log: gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica1.14.0-dev-64bit//include/omc/c/fmi ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -c -o TestSerialPackager_UDP.o TestSerialPackager_UDP.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica1.14.0-dev-64bit//include/omc/c/fmi ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -c -o TestSerialPackager_UDP_functions.o TestSerialPackager_UDP_functions.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica1.14.0-dev-64bit//include/omc/c/fmi ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -c -o TestSerialPackager_UDP_records.o TestSerialPackager_UDP_records.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica1.14.0-dev-64bit//include/omc/c/fmi ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -c -o TestSerialPackager_UDP_01exo.o TestSerialPackager_UDP_01exo.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica1.14.0-dev-64bit//include/omc/c/fmi ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -c -o TestSerialPackager_UDP_02nls.o TestSerialPackager_UDP_02nls.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica1.14.0-dev-64bit//include/omc/c/fmi ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -c -o TestSerialPackager_UDP_03lsy.o TestSerialPackager_UDP_03lsy.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica1.14.0-dev-64bit//include/omc/c/fmi ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -c -o TestSerialPackager_UDP_04set.o TestSerialPackager_UDP_04set.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica1.14.0-dev-64bit//include/omc/c/fmi ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -c -o TestSerialPackager_UDP_05evt.o TestSerialPackager_UDP_05evt.c TestSerialPackager_UDP_functions.c: In function 'omc_Modelica__DeviceDrivers_Packaging_SerialPackager___addInteger': TestSerialPackager_UDP_functions.c:219:42: warning: passing argument 2 of 'MDD_SerialPackagerAddInteger' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] MDD_SerialPackagerAddInteger(_pkg_ext, (const int*) _u_c89, size_of_dimension_base_array(_u, ((modelica_integer) 1)), _byteOrder_ext); ^ In file included from TestSerialPackager_UDP_includes.h:4:0, from TestSerialPackager_UDP_functions.c:7: C:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include/MDDSerialPackager.h:243:16: note: expected 'int *' but argument is of type 'const int *' DllExport void MDD_SerialPackagerAddInteger(void* p_package, int * u, size_t n, int endian) { ^ gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica1.14.0-dev-64bit//include/omc/c/fmi ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -c -o TestSerialPackager_UDP_06inz.o TestSerialPackager_UDP_06inz.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica1.14.0-dev-64bit//include/omc/c/fmi ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -c -o TestSerialPackager_UDP_07dly.o TestSerialPackager_UDP_07dly.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica1.14.0-dev-64bit//include/omc/c/fmi ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -c -o TestSerialPackager_UDP_08bnd.o TestSerialPackager_UDP_08bnd.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica1.14.0-dev-64bit//include/omc/c/fmi ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -c -o TestSerialPackager_UDP_09alg.o TestSerialPackager_UDP_09alg.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica1.14.0-dev-64bit//include/omc/c/fmi ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -c -o TestSerialPackager_UDP_10asr.o TestSerialPackager_UDP_10asr.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica1.14.0-dev-64bit//include/omc/c/fmi ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -c -o TestSerialPackager_UDP_11mix.o TestSerialPackager_UDP_11mix.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica1.14.0-dev-64bit//include/omc/c/fmi ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -c -o TestSerialPackager_UDP_12jac.o TestSerialPackager_UDP_12jac.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica1.14.0-dev-64bit//include/omc/c/fmi ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -c -o TestSerialPackager_UDP_13opt.o TestSerialPackager_UDP_13opt.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica1.14.0-dev-64bit//include/omc/c/fmi ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -c -o TestSerialPackager_UDP_14lnz.o TestSerialPackager_UDP_14lnz.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica1.14.0-dev-64bit//include/omc/c/fmi ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -c -o TestSerialPackager_UDP_15syn.o TestSerialPackager_UDP_15syn.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica1.14.0-dev-64bit//include/omc/c/fmi ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -c -o TestSerialPackager_UDP_16dae.o TestSerialPackager_UDP_16dae.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica1.14.0-dev-64bit//include/omc/c/fmi ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -c -o TestSerialPackager_UDP_17inl.o TestSerialPackager_UDP_17inl.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica1.14.0-dev-64bit//include/omc/c/fmi ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -c -o TestSerialPackager_UDP_init_fmu.o TestSerialPackager_UDP_init_fmu.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica1.14.0-dev-64bit//include/omc/c/fmi ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -c -o TestSerialPackager_UDP_FMU.o TestSerialPackager_UDP_FMU.c In file included from TestSerialPackager_UDP_FMU.c:54:0: fmi-export/fmu2_model_interface.c.inc: In function 'omc_assert_fmi_common': fmi-export/fmu2_model_interface.c.inc:162:16: warning: passing argument 1 of 'GC_vasprintf' from incompatible pointer type [-Wincompatible-pointer-types] GC_vasprintf(&str, msg, args); ^ In file included from openmodelica_func.h:52:0, from TestSerialPackager_UDP_FMU.c:10: util/modelica_string.h:71:5: note: expected 'const char **' but argument is of type 'char **' int GC_vasprintf(const char **strp, const char *fmt, va_list ap); ^ g++ -shared -I. -o TestSerialPackager_UDP.dll TestSerialPackager_UDP.o TestSerialPackager_UDP_functions.o TestSerialPackager_UDP_records.o TestSerialPackager_UDP_01exo.o TestSerialPackager_UDP_02nls.o TestSerialPackager_UDP_03lsy.o TestSerialPackager_UDP_04set.o TestSerialPackager_UDP_05evt.o TestSerialPackager_UDP_06inz.o TestSerialPackager_UDP_07dly.o TestSerialPackager_UDP_08bnd.o TestSerialPackager_UDP_09alg.o TestSerialPackager_UDP_10asr.o TestSerialPackager_UDP_11mix.o TestSerialPackager_UDP_12jac.o TestSerialPackager_UDP_13opt.o TestSerialPackager_UDP_14lnz.o TestSerialPackager_UDP_15syn.o TestSerialPackager_UDP_16dae.o TestSerialPackager_UDP_17inl.o TestSerialPackager_UDP_init_fmu.o TestSerialPackager_UDP_FMU.o -DOMC_MINIMAL_RUNTIME=1 -DCMINPACK_NO_DLL=1 -IC:/OpenModelica1.14.0-dev-64bit//include/omc/c/fmi ""-IC:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica_DeviceDrivers 1.7.1/Resources/Include"" -L""C:/Users/u12l96/AppData/Local/Temp/OpenModelica/OMEdit/TestSerialPackager_UDP"" -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -L""C:/OpenModelica1.14.0-dev-64bit//lib//omc"" -Wl,-rpath,""C:/OpenModelica1.14.0-dev-64bit//lib//omc"" -fopenmp -Wl,-Bstatic -lregex -ltre -lintl -liconv -lexpat -lomcgc -lpthread -loleaut32 -limagehlp -lhdf5 -lz -lszip -Wl,-Bdynamic -lSimulationRuntimeFMI -Wl,-Bstatic -lregex -ltre -lintl -liconv -static-libgcc -lpthread -lm -lgfortranbegin -lgfortran -lquadmath -lmingw32 -lgcc_eh -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -limagehlp -lopenblas -lhdf5 -lz -lszip -Wl,-Bdynamic -llis -Wl,--kill-at TestSerialPackager_UDP_functions.o:TestSerialPackager_UDP_functions.c:(.text+0x42): undefined reference to `__imp_WSAPoll' TestSerialPackager_UDP_functions.o:TestSerialPackager_UDP_functions.c:(.text+0x53): undefined reference to `__imp_WSAGetLastError' TestSerialPackager_UDP_functions.o:TestSerialPackager_UDP_functions.c:(.text+0xbe): undefined reference to `__imp_recvfrom' TestSerialPackager_UDP_functions.o:TestSerialPackager_UDP_functions.c:(.text+0x166): undefined reference to `__imp_WSAStartup' TestSerialPackager_UDP_functions.o:TestSerialPackager_UDP_functions.c:(.text+0x198): undefined reference to `__imp_socket' TestSerialPackager_UDP_functions.o:TestSerialPackager_UDP_functions.c:(.text+0x1af): undefined reference to `__imp_WSAGetLastError' TestSerialPackager_UDP_functions.o:TestSerialPackager_UDP_functions.c:(.text+0x1b7): undefined reference to `__imp_WSACleanup' TestSerialPackager_UDP_functions.o:TestSerialPackager_UDP_functions.c:(.text+0x1f0): undefined reference to `__imp_htons' TestSerialPackager_UDP_functions.o:TestSerialPackager_UDP_functions.c:(.text+0x21a): undefined reference to `__imp_bind' TestSerialPackager_UDP_functions.o:TestSerialPackager_UDP_functions.c:(.text+0x228): undefined reference to `__imp_closesocket' TestSerialPackager_UDP_functions.o:TestSerialPackager_UDP_functions.c:(.text+0x236): undefined reference to `__imp_WSAGetLastError' TestSerialPackager_UDP_functions.o:TestSerialPackager_UDP_functions.c:(.text+0x240): undefined reference to `__imp_WSACleanup' TestSerialPackager_UDP_functions.o:TestSerialPackager_UDP_functions.c:(.text+0x2d1): undefined reference to `__imp_shutdown' TestSerialPackager_UDP_functions.o:TestSerialPackager_UDP_functions.c:(.text+0x2db): undefined reference to `__imp_WSAGetLastError' TestSerialPackager_UDP_functions.o:TestSerialPackager_UDP_functions.c:(.text+0x2f3): undefined reference to `__imp_closesocket' TestSerialPackager_UDP_functions.o:TestSerialPackager_UDP_functions.c:(.text+0x312): undefined reference to `__imp_WSACleanup' TestSerialPackager_UDP_functions.o:TestSerialPackager_UDP_functions.c:(.text+0x372): undefined reference to `__imp_shutdown' TestSerialPackager_UDP_functions.o:TestSerialPackager_UDP_functions.c:(.text+0x37c): undefined reference to `__imp_WSAGetLastError' TestSerialPackager_UDP_functions.o:TestSerialPackager_UDP_functions.c:(.text+0x394): undefined reference to `__imp_closesocket' TestSerialPackager_UDP_functions.o:TestSerialPackager_UDP_functions.c:(.text+0x40c): undefined reference to `__imp_WSACleanup' TestSerialPackager_UDP_functions.o:TestSerialPackager_UDP_functions.c:(.text+0x441): undefined reference to `__imp_htons' TestSerialPackager_UDP_functions.o:TestSerialPackager_UDP_functions.c:(.text+0x44f): undefined reference to `__imp_inet_addr' TestSerialPackager_UDP_functions.o:TestSerialPackager_UDP_functions.c:(.text+0x478): undefined reference to `__imp_sendto' TestSerialPackager_UDP_functions.o:TestSerialPackager_UDP_functions.c:(.text+0x486): undefined reference to `__imp_WSAGetLastError' collect2.exe: error: ld returned 1 exit status Makefile:31: recipe for target 'nozip' failed make: *** [nozip] Error 1 " guenter.lang@… 5634 Compilation on macOS fails *unknown* v1.14.0-dev-nightly defect somebody new 2019-09-12T08:41:50Z 2021-09-13T11:58:21Z "I get the followng error when building from a fresh {{{git clone}}}: {{{ ../../C-Sources/ModelicaStandardTablesUsertab.c:53:51: error: aliases are not supported on darwin double** table) __attribute__ ((weak, alias (""dummy_usertab""))); }}} " Henning Kiel 5638 The function readSimulationResultVars does not return the correct results. Interactive Environment v1.13.2 defect somebody new 2019-09-20T11:14:10Z 2021-09-13T11:58:21Z "For the attached file filterSimulationResults.mat the function readSimulationResultVars does not return the result variables. With the use of these calls we try to convert the mat file into a csv file. vars:=readSimulationResultVars(""filterSimulationResults.mat"",false,false); getErrorString(); filterSimulationResults(""filterSimulationResults.mat"",""filterSimulationResults.csv"",vars); getErrorString(); But the converted csv file only includes the variables ""_derdummy"",""_dummy"" " Niklas Worschech 5647 FMU export: Error in modelDescription.xml FMI v1.14.0-dev-nightly defect Lennart Ochel new 2019-09-30T12:53:07Z 2021-09-13T11:58:21Z "For some 3D Modelica models the FMU export generates wrong variable names in the modelDescription.xml file e.g. for: loadModel(Modelica); translateModelFMU(Modelica.Mechanics.MultiBody.Examples.Rotational3DEffects.GyroscopicEffects, version = ""2.0"",fmuType = ""me""); getErrorSting(); the fmu checker says: [ERROR][FMI2XML] Invalid structured ScalarVariable name ""der(der(bodyCylinder1.frame_b.r_0[1]))"": syntax error, unexpected DER, expecting NONDIGIT or Q_NAME ... " Niklas Worschech 5672 segfaul after 'Invalid root' error in *_functions.c Code Generation defect Karim Adbdelhak assigned 2019-10-23T17:11:06Z 2021-09-13T11:58:21Z "I received the following output from my call to the compiled model executable. These results can be reproduced from the code at https://github.com/SolarTherm/SolarTherm.git in the 'particle' branch, at this commit: https://github.com/SolarTherm/SolarTherm/commit/d532b6eeb9d9dfab1f24780e9745c120f3abc0c8 Obviously the modeller here (me) needs to ensure that functions being inverted don't lead to imaginary roots. However, there shouldn't need to be a segfault from such cases. Using GDB, I was able to get a little more information on the location of the crash, see further below. 2 warnings generated. /usr/bin/../lib/x86_64-linux-gnu/omc/libModelicaMatIO.a(ModelicaMatIO.o): In function `Mat_VarDelete': (.text+0x1cb3): warning: the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp' assert | debug | PhysicalParticleSystem_functions.c:488: Invalid root: (-15169.2)^(0.763767) assert | debug | Solving non-linear system 977 failed at time=9040492.36941685. | | | | For more information please use -lv LOG_NLS. Limited backtrace at point of segmentation fault /lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7f94c3c7a890] /usr/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so(solveNewton+0xcf)[0x7f94c51eff7b] /usr/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so(solveNLS+0xc3)[0x7f94c51d2613] /usr/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so(solve_nonlinear_system+0x2e9)[0x7f94c51d2b2b] ./PhysicalParticleSystem(PhysicalParticleSystem_eqFunction_977+0x7f)[0x41aa8a] ./PhysicalParticleSystem(PhysicalParticleSystem_functionDAE+0x496)[0x41d286] /usr/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so(updateDiscreteSystem+0x80)[0x7f94c51df3f4] ./PhysicalParticleSystem(PhysicalParticleSystem_performSimulation+0xc76)[0x417506] /usr/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so(solver_main+0x334)[0x7f94c51e6b5d] /usr/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so(+0x8466a)[0x7f94c520a66a] /usr/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so(startNonInteractiveSimulation+0xa16)[0x7f94c5209b2f] /usr/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so(_main_SimulationRuntime+0x72)[0x7f94c520bcbc] ./PhysicalParticleSystem(main+0x197)[0x41e191] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f94c3898b97] ./PhysicalParticleSystem(_start+0x2a)[0x4167ca] E ====================================================================== ERROR: test_sched (__main__.TestPhysicalParticleSystem) ---------------------------------------------------------------------- Traceback (most recent call last): File ""TestPhysicalParticleSystem.py"", line 28, in test_sched sim.simulate(start=0, stop='1y', step='5m',solver='dassl', nls='newton') File ""/home/john/.local/lib/python2.7/site-packages/solartherm/simulation.py"", line 360, in simulate sp.check_call(['./'+self.model] + sim_args + args) File ""/usr/lib/python2.7/subprocess.py"", line 190, in check_call raise CalledProcessError(retcode, cmd) CalledProcessError: Command '['./PhysicalParticleSystem', '-override', 'startTime=0.0,stopTime=31536000.0,stepSize=300.0', '-s', 'dassl', '-lv', '-LOG_SUCCESS,-stdout', '-f', 'PhysicalParticleSystem_init.xml', '-r', 'PhysicalParticleSystem_res.mat', '-nls', 'newton']' returned non-zero exit status -11 ---------------------------------------------------------------------- Ran 1 test in 10.996s GDB output: Thread 1 ""PhysicalParticl"" received signal SIGSEGV, Segmentation fault. 0x00007ffff7951f7b in solveNewton () from /usr/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so (gdb) where #0 0x00007ffff7951f7b in solveNewton () from /usr/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so #1 0x00007ffff7934613 in solveNLS () from /usr/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so #2 0x00007ffff7934b2b in solve_nonlinear_system () from /usr/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so #3 0x000000000041aa8a in PhysicalParticleSystem_eqFunction_977 () #4 0x000000000041d286 in PhysicalParticleSystem_functionDAE () #5 0x00007ffff79413f4 in updateDiscreteSystem () from /usr/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so #6 0x0000000000417506 in PhysicalParticleSystem_performSimulation () #7 0x00007ffff7948b5d in solver_main () from /usr/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so #8 0x00007ffff796c66a in ?? () from /usr/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so #9 0x00007ffff796bb2f in startNonInteractiveSimulation () from /usr/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so #10 0x00007ffff796dcbc in _main_SimulationRuntime () from /usr/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so #11 0x000000000041e191 in main () (gdb) " anonymous 5686 "Invalid FMU Export: Enumeration without start value and/or invalid combination of ""input"" and ""fixed""" FMI defect arunkumar palanisamy assigned 2019-11-07T10:48:24Z 2021-09-13T11:58:21Z "Hi all, I noticed that OpenModelica exports enumeration input values for example as follows: --- --- Importing such an FMU into a Co-Simulation master fails because the master does not have a valid initial value/selection for the enumeration value. According to the FMI standard, the combination of ""input"" and ""fixed"" is invalid, when no initial value is given (see ""Functional Mock-up Interface 2.0"", July 25, 2014, Page 48 of 126). I think this should be fixed by providing an initial value/selection for the enumeration. " andreas.nicolai@… 5705 Simplifications of boolean variables in initialization problems Backend defect Karim Adbdelhak new 2019-11-21T10:57:16Z 2021-09-13T11:58:21Z "We have a tough use case of a hydraulic circuit with homotopy-based initialization. The system is driven by a boolean variable. In the base case, the boolean variable is set to false by an equation, {{{ ... Boolean cmd; equation cmd = false; ... }}} and the initialization problem is solved successfully. If we set up simulations where the ''initial value'' of the boolean variable is false, but then it is later switched to true {{{ ... Boolean cmd(final start = false, final fixed = true); equation when time > 500 then cmd = true; end when; }}} or {{{ ... Boolean cmd; initial equation cmd = false; equation ... when time > 500 then cmd = true; end when; ... }}} then the initialization fails. IMHO the initialization problem should have exactly the same structure in the three cases. Why doesn't it?" Francesco Casella 5717 OMPython linearize function not working correctly OMPython defect Alachew Mengist new 2019-11-30T22:39:40Z 2021-09-13T11:58:21Z "Within the OMPython module the function linearize contains an if statement depending on self.inputFlag. In the ""else"" branch a requestAPI call is made using simflags as argument: linearizeResult = self.requestApi('linearize', cName, properties, simflags) However the simflags variable is not assigned. Work around that worked for me is to remove this argument. Please correct in the OMPython distribution " h.j.van.weers@… 5730 Issue with operator record constructors in NF New Instantiation defect Per Östlund new 2019-12-04T00:24:21Z 2021-09-13T11:58:21Z "Please check [https://libraries.openmodelica.org/branches/newInst/Modelica_LinearSystems2/files/Modelica_LinearSystems2_Modelica_LinearSystems2.Controller.Examples.InverseDoublePendulumWithObserver.err Modelica_LinearSystems2.Controller.Examples.InverseDoublePendulumWithObserver]. The NF reports {{{ [Modelica_LinearSystems2 2.3.5/DiscreteStateSpace.mo:26:5-29:54:writable] Error: Base class Modelica_LinearSystems2.DiscreteTransferFunction.Conversion.toDiscreteStateSpace not found in scope 'constructor'. }}} The sought-after function is defined [https://github.com/modelica/Modelica_LinearSystems2/blob/5485b6524c0ae9d8d9ecc48aef1db29d03714e6f/Modelica_LinearSystems2/DiscreteTransferFunction.mo#L1249 here]. The scope of {{{constructor}}} is encapsulated. However, [https://specification.modelica.org/v3.4/Ch5.html#simple-name-lookup Section 5.3.1 of the Specification] states that lookup is stopped for simple names, not composed using dot notation. " Francesco Casella 5757 parentJacobian member missing from linearSystemData Code Generation v.1.15.0-dev defect Karim Adbdelhak assigned 2019-12-18T10:36:25Z 2021-09-13T11:58:21Z "Unfortunately I cannot share source code, but I hit an issue '''that was not there in 1.14.0''' {{{ CrtVehicleTesting.Engines.EngineMapByMechTest_fromRecord_03lsy.c: In function 'CrtVehicleTesting_Engines_EngineMapByMechTest_fromRecord_initialLinearSystem': CrtVehicleTesting.Engines.EngineMapByMechTest_fromRecord_03lsy.c:107:22: error: 'LINEAR_SYSTEM_DATA {aka struct LINEAR_SYSTEM_DATA}' has no member named 'parentJacobian' linearSystemData[1].parentJacobian = NULL; ^ CrtVehicleTesting.Engines.EngineMapByMechTest_fromRecord_03lsy.c:122:22: error: 'LINEAR_SYSTEM_DATA {aka struct LINEAR_SYSTEM_DATA}' has no member named 'parentJacobian' linearSystemData[0].parentJacobian = NULL; ^ : recipe for target 'CrtVehicleTesting.Engines.EngineMapByMechTest_fromRecord_03lsy.o' failed mingw32-make: *** [CrtVehicleTesting.Engines.EngineMapByMechTest_fromRecord_03lsy.o] Error 1 }}} " dariomangoni@… 5764 OPC UA seems to miss DataType at the nodes attributes *unknown* v.1.15.0-dev defect Martin Sjölund assigned 2020-01-02T10:51:17Z 2021-09-13T11:58:21Z "Hi, just played around with the OPC UA Server in OpenModelica and tried to connect with different clients (UA Expert, Beckhoff TwinCat PLC OPC IO, Android Suppanel) to a simple model (Just a sine source, a resistor and ground). Connection to the OPC-UA server works fine and in UA Expert I can set values and watch variables changing. But there seems to be something broken between version 1.12 and 1.13+. The OPC clients can't reliably determine the datatype for the attributes presented by the OPC-UA server. UA Expert may work around that somehow, but the other clients I tested, reject using the variables - due to the missing variable information? Please see the following screenshots: '''OpenModelica v1.12.0''' [[Image(https://s19.directupload.net/images/200102/5fuez2h6.png)]] '''OpenModelica v1.13 to v1.15-dev''' [[Image(https://s19.directupload.net/images/200102/kqrkdtc3.png)]] " anonymous 5770 The backend incorrectly generates a large set of nonlinear equations Backend defect Karim Adbdelhak assigned 2020-01-07T18:47:57Z 2021-09-13T11:58:21Z "@Karim, I managed to come up with a test case for the slow behaviour in the power plant simulation that I mentioned during today's webmeeting. The test case has a reduced size to be more manageable. Please run the attached Save Total model. The backend identifies a nonlinear system with 18 unknowns and 7 iteration variables: {{{ der(fWPH_11_1.flowSTEAM.htilde[1]) der(fWPH_11_1.flowSTEAM.htilde[2]) der(fWPH_11_1.nusseltCondenser.hl) der(fWPH_11_1.nusseltCondenser.hv) der(fWPH_11_1.nusseltCondenser.p) der(fWPH_11_1.nusseltCondenser.Vv) fWPH_11_1.nusseltCondenser.ws_in }}} Dymola identifies a linear system instead, which has the 6 following unknowns after tearing. {{{ der(fWPH_11_1.flowSTEAM.h[2]) der(fWPH_11_1.flowSTEAM.h[3]) der(fWPH_11_1.nusseltCondenser.hl) der(fWPH_11_1.nusseltCondenser.hv) der(fWPH_11_1.nusseltCondenser.p) der(fWPH_11_1.nusseltCondenser.Vl) }}} The first two and the last ones aliases of the first two and of the sixth found by OMC. The simulation of this model is actually a steady-state, so there are only 19 variable step-size steps, and 500 communication intervals. Yet, the nonlinear system is reported by the debugger to be executed a whopping 48209 times. In the case of larger systems, this can be really become the bottleneck. I scanned the equations of the nonlinear system in the OMC debugger, but I couldn't understand why OMC considers them nonlinear. Could you please check? " Francesco Casella 5772 GenerateDoc does not handle HTML description strings Scripts v1.16.0-dev defect Adeel Asghar assigned 2020-01-07T20:46:39Z 2021-09-13T11:58:21Z "I was just made aware of that the current `GenerateDoc.mos` does not handle description strings in HTML format including not resolving Modelica URIs. Not sure if this can be easily fixed by feeding description strings into the same processing routine as the Documentation annotation currently. Example: https://build.openmodelica.org/Documentation/OpenHPL.html" Dietmar Winkler 5787 Flag -d=bltdump does not produce any output anymore Interactive Environment v1.14.0 defect somebody new 2020-01-14T11:11:11Z 2021-09-13T11:58:21Z "It seems that -d=bltdump does not produce any output since 1.14. Reported here: https://openmodelica.org/forum/default-topic/2865-compiler-flags-for-new- front-end Any way to bring this back?" Adrian Pop 5798 Allow adminstrators to install OM for all users Installation program defect Adeel Asghar new 2020-01-22T21:13:41Z 2021-09-13T11:58:21Z "Currently its possible to install OM for all users using the silent installation with `/S` switch. Update the installer so when its run with admin rights the user should be able to choose between current user or all users option. See also https://openmodelica.org/forum/default-topic/2267-openmodelica-not-installed-for-all-users" Adeel Asghar 5800 OMEdit fails to simulate example model from OpenHPL Backend v1.16.0-dev defect Per Östlund assigned 2020-01-23T14:07:13Z 2021-09-13T11:58:21Z "When testing some of the examples of https://github.com/simulatino/OpenHPL I got the following error message which I don't really know how to tackle. This happens when running `OpenHPL.Examples.HPSimple`: : {{{ [3] 14:08:06 Translation Error Internal error IndexReduction.pantelidesIndexReduction failed! System is structurally singulare and cannot handled because number of unassigned equations is larger than number of states. Use -d=bltdump to get more information. }}} So I did set the flag and got: {{{ [2] 14:08:06 Symbolic Error [OpenHPL.Waterway.SurgeTank: 119:3-119:16]: Model is structurally singular, error found sorting equations 36: surgeTank.Mdot = surgeTank.mdot * surgeTank.v 34: surgeTank.M = surgeTank.m * surgeTank.v 39: surgeTank.F_g = surgeTank.m * data.g * surgeTank.cos_theta 38: surgeTank.F_p = (surgeTank.p_n - data.p_a) * surgeTank.A 30: der(surgeTank.M) = surgeTank.Mdot + surgeTank.F 22: der(tail.m) = 0.0 18: tail.A = tail.H * (tail.w + 2.0 * tail.H * tan(0.0174532925199433 * tail.alpha)) 20: tail.F_f = 0.0 19: tail.m = data.rho * tail.A * tail.L 14: discharge.v = discharge.Vdot / discharge.A_ 13: discharge.Vdot = turbine.mdot / data.rho 21: 0.0 = tail.A * (data.p_a - discharge.p_o) + data.g * data.rho * tail.A * tail.H - tail.F_f 15: discharge.M = data.rho * discharge.L * discharge.Vdot 16: discharge.F_f = OpenHPL.Functions.DarcyFriction.Friction(discharge.v, discharge.D_, discharge.L, data.rho, data.mu, discharge.p_eps) 7: turbine.look_up_table.u[1] = control.offset + (if time < control.startTime then 0.0 else if time < control.startTime + control.duration then (time - control.startTime) * control.height / control.duration else control.height) 42: turbine.Vdot = if turbine.WaterCompress then turbine.mdot / (data.rho * (1.0 + data.beta * (turbine.p_i_tr - data.p_a))) else turbine.mdot / data.rho 17: der(discharge.M) = data.rho * discharge.Vdot ^ 2.0 * (1.0 / discharge.A_i + (-1.0) / discharge.A_o) + turbine.p_o_tr * discharge.A_i + discharge.m * data.g * discharge.cos_theta + (-discharge.F_f) - discharge.p_o * discharge.A_o 43: turbine.dp = turbine.Vdot ^ 2.0 * data.p_a / (turbine.C_v_ * turbine.look_up_table.u[1]) ^ 2.0 5: der(reservoir.m) = 0.0 1: reservoir.A = reservoir.H * (reservoir.w + 2.0 * reservoir.H * tan(0.0174532925199433 * reservoir.alpha)) 3: reservoir.F_f = 0.0 2: reservoir.m = data.rho * reservoir.A * reservoir.L 9: intake.v = intake.Vdot / intake.A_ 4: 0.0 = reservoir.A * (data.p_a - intake.p_i) + data.g * data.rho * reservoir.A * reservoir.H - reservoir.F_f 10: intake.M = data.rho * intake.L * intake.Vdot 11: intake.F_f = OpenHPL.Functions.DarcyFriction.Friction(intake.v, intake.D_, intake.L, data.rho, data.mu, intake.p_eps) 25: penstock.v = penstock.Vdot / penstock.A_ 44: turbine.dp = turbine.p_i_tr - turbine.p_o_tr 12: der(intake.M) = data.rho * intake.Vdot ^ 2.0 * (1.0 / intake.A_i + (-1.0) / intake.A_o) + intake.p_i * intake.A_i + intake.m * data.g * intake.cos_theta + (-intake.F_f) - surgeTank.p_n * intake.A_o 27: penstock.F_f = OpenHPL.Functions.DarcyFriction.Friction(penstock.v, penstock.D_, penstock.L, data.rho, data.mu, penstock.p_eps) 28: der(penstock.M) = data.rho * penstock.Vdot ^ 2.0 * (1.0 / penstock.A_i + (-1.0) / penstock.A_o) + surgeTank.p_n * penstock.A_i + penstock.m * data.g * penstock.cos_theta + (-penstock.F_f) - turbine.p_i_tr * penstock.A_o 26: penstock.M = data.rho * penstock.L * penstock.Vdot 6: intake.Vdot = data.rho 24: penstock.Vdot = turbine.mdot / data.rho 8: intake.Vdot = intake.mdot / data.rho 40: surgeTank.mdot = intake.mdot - turbine.mdot 33: surgeTank.mdot = data.rho * surgeTank.Vdot 37: surgeTank.F = surgeTank.F_p + (-surgeTank.F_f) - surgeTank.F_g 35: surgeTank.v = surgeTank.Vdot / surgeTank.A 29: der(surgeTank.m) = surgeTank.mdot 32: surgeTank.F_f = OpenHPL.Functions.DarcyFriction.Friction(surgeTank.v, surgeTank.D, surgeTank.l, data.rho, data.mu, surgeTank.p_eps) 31: surgeTank.m = data.rho * surgeTank.A * surgeTank.l for variables 20: surgeTank.Mdot:VARIABLE(unit = ""N"" ) ""Difference in influent and effulent momentum""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.SurgeTank type: Real 21: surgeTank.M:STATE(1)(unit = ""kg.m/s"" ) ""Water momuntum""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.SurgeTank type: Real 14: surgeTank.F_g:VARIABLE(unit = ""N"" ) ""Gravity force""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.SurgeTank type: Real 16: surgeTank.F_p:VARIABLE(unit = ""N"" ) ""Pressure force""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.SurgeTank type: Real 19: surgeTank.F:VARIABLE(unit = ""N"" ) ""Total force acting in the surge tank""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.SurgeTank type: Real 31: tail.m:STATE(1)(min = 0.0 unit = ""kg"" ) ""water mass""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.Reservoir type: Real 28: tail.H:VARIABLE(min = 0.0 unit = ""m"" ) ""water height""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.Reservoir type: Real 29: tail.F_f:VARIABLE(unit = ""N"" ) ""friction force""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.Reservoir type: Real 32: tail.A:VARIABLE(unit = ""m2"" ) ""vertiacal cross section""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.Reservoir type: Real 38: discharge.v:VARIABLE(unit = ""m/s"" ) ""Water velocity""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.Pipe type: Real 33: discharge.Vdot:VARIABLE(start = discharge.Vdot_0 unit = ""m3/s"" ) ""Flow rate""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.Pipe type: Real 35: discharge.p_o:VARIABLE(unit = ""Pa"" ) ""Outlet pressure""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.Pipe type: Real 36: discharge.M:STATE(1)(unit = ""kg.m/s"" ) ""Water momentum""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.Pipe type: Real 37: discharge.F_f:VARIABLE(unit = ""N"" ) ""Friction force""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.Pipe type: Real 2: turbine.look_up_table.u[1]:VARIABLE(flow=false ) ""Connector of Real input signals""OpenHPL.Examples.HPSimple, OpenHPL.ElectroMech.Turbines.Turbine, Modelica.Blocks.Tables.CombiTable1D type: Real [1] 5: turbine.Vdot:VARIABLE(unit = ""m3/s"" ) ""Flow rate""OpenHPL.Examples.HPSimple, OpenHPL.ElectroMech.Turbines.Turbine type: Real 7: turbine.p_o_tr:VARIABLE(unit = ""Pa"" ) ""Outlet pressure""OpenHPL.Examples.HPSimple, OpenHPL.ElectroMech.Turbines.Turbine type: Real 8: turbine.dp:VARIABLE(unit = ""Pa"" ) ""Turbine pressure drop""OpenHPL.Examples.HPSimple, OpenHPL.ElectroMech.Turbines.Turbine type: Real 49: reservoir.m:STATE(1)(min = 0.0 unit = ""kg"" ) ""water mass""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.Reservoir type: Real 46: reservoir.H:VARIABLE(min = 0.0 unit = ""m"" ) ""water height""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.Reservoir type: Real 47: reservoir.F_f:VARIABLE(unit = ""N"" ) ""friction force""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.Reservoir type: Real 50: reservoir.A:VARIABLE(unit = ""m2"" ) ""vertiacal cross section""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.Reservoir type: Real 45: intake.v:VARIABLE(unit = ""m/s"" ) ""Water velocity""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.Pipe type: Real 42: intake.p_i:VARIABLE(unit = ""Pa"" ) ""Inlet pressure""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.Pipe type: Real 43: intake.M:STATE(1)(unit = ""kg.m/s"" ) ""Water momentum""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.Pipe type: Real 44: intake.F_f:VARIABLE(unit = ""N"" ) ""Friction force""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.Pipe type: Real 27: penstock.v:VARIABLE(unit = ""m/s"" ) ""Water velocity""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.Pipe type: Real 9: turbine.p_i_tr:VARIABLE(unit = ""Pa"" ) ""Inlet pressure""OpenHPL.Examples.HPSimple, OpenHPL.ElectroMech.Turbines.Turbine type: Real 11: surgeTank.p_n:VARIABLE(unit = ""Pa"" ) ""Node pressure""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.SurgeTank type: Real 26: penstock.F_f:VARIABLE(unit = ""N"" ) ""Friction force""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.Pipe type: Real 25: penstock.M:STATE(1)(unit = ""kg.m/s"" ) ""Water momentum""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.Pipe type: Real 23: penstock.Vdot:VARIABLE(start = penstock.Vdot_0 unit = ""m3/s"" ) ""Flow rate""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.Pipe type: Real 40: intake.Vdot:VARIABLE(start = intake.Vdot_0 unit = ""m3/s"" ) ""Flow rate""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.Pipe type: Real 3: turbine.mdot:VARIABLE(unit = ""kg/s"" ) ""Mass flow rate""OpenHPL.Examples.HPSimple, OpenHPL.ElectroMech.Turbines.Turbine type: Real 39: intake.mdot:VARIABLE(unit = ""kg/s"" ) ""Mass flow rate""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.Pipe type: Real 10: surgeTank.mdot:VARIABLE(unit = ""kg/s"" ) ""Mass flow rate""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.SurgeTank type: Real 12: surgeTank.Vdot:VARIABLE(start = surgeTank.Vdot_0 unit = ""m3/s"" fixed = true ) ""Water flow rate""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.SurgeTank type: Real 15: surgeTank.F_f:VARIABLE(unit = ""N"" ) ""Friction force""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.SurgeTank type: Real 17: surgeTank.v:VARIABLE(unit = ""m/s"" ) ""Water velocity""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.SurgeTank type: Real 22: surgeTank.m:STATE(1,surgeTank.mdot)(min = 0.0 unit = ""kg"" ) ""Water mass""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.SurgeTank type: Real 18: surgeTank.l:VARIABLE(unit = ""m"" ) ""Length of water in the surge tank""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.SurgeTank type: Real 48: reservoir.Vdot_i:VARIABLE(unit = ""m3/s"" ) ""inlet flow rate""OpenHPL.Examples.HPSimple, OpenHPL.Waterway.Reservoir type: Real [3] 14:08:06 Translation Error Internal error Transformation Module PFPlusExt index Reduction Method Pantelides failed! }}} I'm not really sure what is missing here especially since the component that OM is complaining about `OpenHPL.Waterway.SurgeTank` is also used in `OpenHPL.Examples.HPSimple_Francis` which works perfectly fine. Needless to say that I did test in Dymola before reporting and there no problem occurs what so ever. " Dietmar Winkler 5820 OMJulia ModelicaSystem - BouncingBall.mo! NotFound OMJulia v.1.15.0-dev defect Adrian Pop new 2020-02-01T19:39:24Z 2020-02-05T18:32:57Z "Following the example at [https://openmodelica.org/doc/OpenModelicaUsersGuide/latest/omjulia.html] {{{ using OMJulia mod = OMJulia.OMCSession() ModelicaSystem(mod,""BouncingBall.mo"",""BouncingBall"") }}} I get the error message: BouncingBall.mo! NotFound Do I need to set a path or anything? (There is no component OMJulia, therefore I assigned it to OMPython.)" Oliver Lenord 5827 Have a setting for dynamic/static link of the generated executable Build Environment defect Martin Sjölund new 2020-02-04T10:44:10Z 2021-09-13T11:58:21Z "Currently it takes a lot of time to compile an executable (at least on Windows) because is statically link. Static link is nice because you can give the executable to somebody and it will still work. We should have a setting to have dynamic link by default and static link if the user wants it. Same as we already have now for FMI compilation. " Adrian Pop 5853 -d=-disableDirectionalDerivatives Fails FMI v1.16.0-dev defect Andreas Heuermann assigned 2020-02-18T12:41:34Z 2021-09-13T11:58:21Z "Hello, i want to enable the directional derivates in generated FMU. To do so, I set under tools -> options -> Simulation the flag ''-d=-disableDirectionalDerivatives'' Saving and generating the FMU via Data - Export - FMU gives me an FMU file. Opening it in Python (PyFMI) returns the Error: ''FMUException: This FMU does not provide directional derivatives'' ''Watching the flags shows following result: model = load_fmu('simuflag.fmu') model.get_capability_flags() Out[44]: {'needsExecutionTool': False, 'completedIntegratorStepNotNeeded': False, 'canBeInstantiatedOnlyOncePerProcess': False, 'canNotUseMemoryManagementFunctions': False, 'canGetAndSetFMUstate': False, 'canSerializeFMUstate': False, ''''providesDirectionalDerivatives': False,''' 'completedEventIterationIsProvided': True}'' Why is this flag still set as false? Any bug, or mishandling by myself? Best regards Henrik " bode-h@… 5865 Missing transformational debugger information for $cse implicit equations Backend defect Karim Adbdelhak new 2020-02-25T14:05:49Z 2021-09-13T11:58:21Z "Please run the attached test case with the OMEdit transformational debugger. The debugger shows the chain of symbolic transformations and a pointer to the original equation in the source code. However, this does not happen in the case of implicit equations defining the CSE variables. In standard odeMode, this happens for {{{ (residual) $cse2 - TestDaeMode.sq(w12, 0.01) = 0 (residual) $cse1 - TestDaeMode.sq(w34, 0.01) = 0 }}} while in daeMode (uncomment the vendor annotation to get it) this happens for {{{ (assign) $DAEres5 := TestDaeMode.sq(w34, 0.01) - $cse1 (assign) $DAEres0 := TestDaeMode.sq(w12, 0.01) - $cse2 }}} I guess this requires fixing one specific point of the backend or code generation, though I have no idea exactly where. I hope these two test cases allow to pinpoint the exact location easily." Francesco Casella 5881 Constants in a model cannot be read from a FMU FMI v1.16.0-dev defect arunkumar palanisamy new 2020-03-06T11:51:51Z 2021-09-13T11:58:21Z "Reported by Jan Peter: Constants in a model cannot be read from a FMU exported from OpenModelica. I think it is very practical for post-processing to be able to read out constants of a model from the FMU." Lennart Ochel 5886 Use of undeclared identifier and undefined reference to *_array_get function Code Generation v1.16.0-dev defect Mahder Alemseged Gebremedhin accepted 2020-03-10T09:25:33Z 2021-09-13T11:58:21Z "The following model (Top in the Bug package) fails compilation. For some reason, if {{{z}}} is {{{1}}}, omc produces C code including calls to a nonexistent function {{{Bug_Component_array_get}}}. The calls to this function also reference a parameter {{{components}}} which does not exist in the caller's context. Setting {{{z}}} to anything greater than {{{1}}} produces working code, where the {{{Bug_Component_array_get}}} is not declared not used anywhere." federico.terraneo@… 5897 OMSimulator header files missing in Ubuntu packages OMSimulator v1.16.0-dev defect Martin Sjölund assigned 2020-03-25T10:11:17Z 2021-09-13T11:58:21Z "The header files for /usr/include/omc/omsi and /usr/include/omc/omsic are not contained in any package on Ubuntu (eoan and bionic). Steps to reproduce: > apt -b source libomsimulator Then compare the contents of /usr/include/omc of a full installation with the contents of BUILD_PATH/openmodelica-1.16.0_VERSION/debian/tmp/usr/include/omc Possible solution: create new package ""libomsimulator-dev""" stille@… 5906 compilation error for curved bend Code Generation v1.14.1 defect Mahder Alemseged Gebremedhin accepted 2020-04-06T07:15:50Z 2021-09-13T11:58:21Z "I have build a model containing two boundary condition and two static pipes with one curved bend in between. The model is built without any error (as the number of variables = number of the equations). But during compiling model throws error given below for cured bend in the model. * I have attached error in the file and the model is given below. I appreciate your help regarding solving my problem. {{{ model LBendtest1 replaceable package Medium = Modelica.Media.Water.StandardWater; inner Modelica.Fluid.System system(energyDynamics = Modelica.Fluid.Types.Dynamics.FixedInitial) annotation( Placement(visible = true, transformation(origin = {-76, 82}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Fluid.Pipes.StaticPipe pipe(redeclare package Medium = Medium, diameter = 0.02, length = 50, p_a_start = 100000, p_b_start = 100000) annotation( Placement(visible = true, transformation(origin = {-42, -16}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Fluid.Pipes.StaticPipe pipe1(redeclare package Medium = Medium, diameter = 0.02, length = 50, p_a_start = 100000, p_b_start = 100000) annotation( Placement(visible = true, transformation(origin = {42, 42}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Fluid.Sources.MassFlowSource_T boundary(redeclare package Medium = Medium, T = 293.15, m_flow = 0.1, nPorts = 1) annotation( Placement(visible = true, transformation(origin = {-88, -16}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Fluid.Sources.Boundary_pT boundary1(redeclare package Medium = Medium, T = 293.15, nPorts = 1, p = 100000) annotation( Placement(visible = true, transformation(origin = {86, 42}, extent = {{-10, -10}, {10, 10}}, rotation = 180))); Modelica.Fluid.Fittings.Bends.CurvedBend curvedBend1(redeclare package Medium = Medium, geometry = Modelica.Fluid.Fittings.BaseClasses.Bends.CurvedBend.Geometry(d_hyd = 0.02, R_0 = 0.6)) annotation( Placement(visible = true, transformation(origin = {-2, 18}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); equation connect(boundary.ports[1], pipe.port_a) annotation( Line(points = {{-78, -16}, {-52, -16}, {-52, -16}, {-52, -16}}, color = {0, 127, 255})); connect(pipe1.port_b, boundary1.ports[1]) annotation( Line(points = {{52, 42}, {76, 42}}, color = {0, 127, 255})); connect(pipe.port_b, curvedBend1.port_a) annotation( Line(points = {{-32, -16}, {-32, 18}, {-12, 18}}, color = {0, 127, 255})); connect(curvedBend1.port_b, pipe1.port_a) annotation( Line(points = {{8, 18}, {17, 18}, {17, 42}, {32, 42}}, color = {0, 127, 255})); annotation( uses(Modelica(version = ""3.2.2""))); end LBendtest1; }}}" sachinjadhav2004@… 5911 NF API don't return qualified path Interactive Environment defect Adrian Pop assigned 2020-04-08T12:24:14Z 2021-09-13T11:58:21Z "Run the attached script. The first output of the components without `-d=nfAPI` is, {{{ {{P.M,m1,"""", ""public"", false, false, false, false, ""unspecified"", ""none"", ""unspecified"",{}},{P.M,m2,"""", ""public"", false, false, false, false, ""unspecified"", ""none"", ""unspecified"",{}},{P.C,c,"""", ""public"", false, false, false, false, ""unspecified"", ""none"", ""unspecified"",{}}} }}} Note the last component `P.C`. The second output of the components with `-d=nfAPI` is, {{{ {{P.M,m1,"""", ""public"", false, false, false, false, ""unspecified"", ""none"", ""unspecified"",{}},{P.M,m2,"""", ""public"", false, false, false, false, ""unspecified"", ""none"", ""unspecified"",{}},{C,c,"""", ""public"", false, false, false, false, ""unspecified"", ""none"", ""unspecified"",{}}} }}} Note that this time `C` is returned. OMEdit don't like it and shows the component as not defined with a red cross." Adeel Asghar 5932 DLL needs to be in working directory Run-time v1.14.0 defect Adrian Pop accepted 2020-05-01T15:00:50Z 2021-09-13T11:58:21Z "I have been working on creating a library for internal use at my company and we need to have some functions written in C/C++ that interface with the Modelica code. After reading through the language specifications and some examples I was perfectly able to use the method where you just use the ''Include'' statement to add a ''.c'' file. However, I had issues getting the exact same file to work when compiled into a ''.dll''. It would compile just fine, but I would get the following error during the simulation step: {{{ Process crashed Simulation process failed. Exited with code -1073741515. }}} The ''.h'' file is in ''LibraryName/External/Resources/Include'' and the ''.dll'' is in ''LibraryName/External/Resources/Library/win64''. The code block for the external function is as follows: {{{ function External_Lib ""External function in a library to generate signal"" input Real t; output Real x; external ""C"" x = External_Lib(t) annotation( LibraryDirectory = ""modelica://LibraryName/External/Resources/Library"", Library = ""External_Lib"", IncludeDirectory = ""modelica://LibraryName/External/Resources/Include"", Include = ""#include \""External_Lib.h\""""); end External_Lib; }}} After trying many different things I found that it will work if I also put the ''.dll'' in the working directory of OMEdit. My guess is that the issue is either that found libraries are not properly added to the PATH, or that the DLL dependencies are not properly being included." nnelsonwood@… 5953 Broken visualization code generation for models with components having same name Code Generation defect Volker Waurich assigned 2020-05-12T20:29:35Z 2021-09-13T11:58:21Z "Model '''VisualizationBug''' has two shapes with the same name '''body.sphere''' and '''foo.body.sphere''' and '''body.sphere''' is missing from 3D animation scene in OMEdit. {{{#!modelica model VisualizationBug model Foo Modelica.Mechanics.MultiBody.Parts.Body body( angles_fixed = true, m = 1, r_CM = {0, 0, 0}, r_0(each fixed = true, start = {0, 0, 0}), v_0(each fixed = true), w_0_fixed = true ); end Foo; Modelica.Mechanics.MultiBody.Parts.Body body( angles_fixed = true, m = 1, r_0(each fixed = true, start = {0, 1, 0}), r_CM = {0, 0, 0}, v_0(each fixed = true), w_0_fixed = true); inner Modelica.Mechanics.MultiBody.World world; VisualizationBug.Foo foo; end VisualizationBug; }}} I think that's because compiler generates wrong '''*_vis.xml''' file and shape '''body.sphere''' use '''foo.body.sphere''' parameters. {{{#!xml body.sphere sphere foo.body.sphere.R.T[1,1] foo.body.sphere.R.T[1,2] foo.body.sphere.R.T[1,3] foo.body.sphere.R.T[2,1] foo.body.sphere.R.T[2,2] foo.body.sphere.R.T[2,3] foo.body.sphere.R.T[3,1] foo.body.sphere.R.T[3,2] foo.body.sphere.R.T[3,3] foo.body.sphere.r[1] foo.body.sphere.r[2] foo.body.sphere.r[3] foo.body.sphere.r_shape[1] body.sphere.r_shape[2] body.sphere.r_shape[3] ... }}}" anonymous 5960 Large scale electrical models Initialization v1.14.1 defect Karim Adbdelhak assigned 2020-05-16T07:12:08Z 2021-09-13T11:58:21Z "Dear staff member, I am working on large scale electrical models and I am having lots of problems with the solvers. Especially when adding inductances and capacitors to the model, I get a lot of errors with the linear and non-linear systems that can't be solved. Should I use any particular non-linear solver? And send the model? I have already tried the different ones and limiting the tearing, but no results. Thank you" lluc@… 5962 We should check that major Linux distros work in the testsuite *unknown* defect Adrian Pop new 2020-05-18T14:25:47Z 2021-09-13T11:58:21Z "@rfranke reports issues with the C++ runtime if using Ubuntu 20.04 LTS, see #5948. This kind of issues is currently not detected in the testsuite. We compile OMC on a number of Linux distros, but only actually run tests on those version on which the CI framework is installed on. Running the entire testuite for each different distro is out of the question, but we should run a minimal testsuite at least on major distros to make sure that all basic functionalities work: C-runtime, C++ runtime, OMEdit, FMI export (both compiled and source code). " Francesco Casella 5965 Build FMUs with OMC_NO_THREADS Run-time defect Martin Sjölund new 2020-05-19T10:59:36Z 2021-09-13T11:58:21Z "[I report this on behalf of Maik] Do we have any documentation for the define `OMC_NO_THREADS` in our runtime code? It seems that it is not possible to build FMUs with this option, or at least some pthread functionality doesn't get removed from the code which makes this feature unusable, i.e. `pthread_setspecific`." Lennart Ochel 5983 Cleanup black box FMUs FMI defect arunkumar palanisamy new 2020-05-26T06:26:31Z 2021-09-13T11:58:21Z "FMUs contain log files and additional information for the transformational debugger. This might be okay in most of the cases, but those files should probably not end up in black box FMUs where people try to hide information. * /resources/.json * /resources/linux64.summary * /resources/static.log" Lennart Ochel 5995 FMU Export with Modelica.Utilities.Streams functions FMI defect Lennart Ochel assigned 2020-06-03T06:32:20Z 2021-09-13T11:58:21Z "The following error is communicated when exporting a model incorporating the functions Modelica.Utilities.Streams.readMatrixSize and matrixName, Modelica.Utilities.Streams.readMatrixSize: [CodegenUtil.tpl: 197:14-197:14]: Template error: initial value of unknown type: Modelica.Utilities.Streams.readRealMatrix(..., Modelica.Utilities.Streams.readMatrixSize(... It is possible to export FMUs incorporating these functions with competing FMI supporting tools " robert.hallqvist@… 6003 Code generation bug Backend v1.14.1 defect Karim Adbdelhak assigned 2020-06-11T13:20:22Z 2021-09-13T11:58:21Z "Hi, For a project at my new job I decided to move to openmodelica. My first experiment is an ideal time-division multiplexing system. It passes multiple signals through a single signal path during consecutive intervals. To make the model more realistic, I added a low-pass filter in the signal path. Now I get a compilation error: test_error_02nls.c: In function 'initializeStaticDataNLS14': test_error_02nls.c:45:87: error: 'INTEGER_ATTRIBUTE {aka struct INTEGER_ATTRIBUTE}' has no member named 'nominal' sysData->nominal[i] = data->modelData->integerVarsData[0].attribute /* MpxIndex.y */.nominal; Previous reports of this error message seem to be related to an algebraic loop. Lo and behold: inserting a unit delay before the filter did solve the problem. I find this strange, since at the model level it does not contain any loops. The most surprising thing is that in any other simulation program, a low-pass filter breaks an algebraic loop because it places an integrator in the loop. Here it ''creates'' an algebraic loop! I loaded the model in a trial version of dymola. Dymola has no problem with the model. Therefore I consider this an openmodelica bug. I'll enclose a demo project (main model: test_error.mo) Best regards, Paul van der Hulst PS I'm a newbie regarding (open)modelica, but have many years of experience simulating switched systems with simulink and various other simulation packages, including modification of an RK4 integration engine to properly handle state-events. " p.van.der.hulst@… 6008 OMEdir debugger support for quoted identifiers OMEdit defect Adeel Asghar new 2020-06-15T12:09:57Z 2021-09-13T11:58:21Z "The quoting of identifiers changed again: https://github.com/OpenModelica/OpenModelica/commit/b13895d183adac5f5d4a10a13d1541bdba0a0ce2" Martin Sjölund 6014 OMPython: Set structural parameter at initialization Interactive Environment v1.14.1 defect Adrian Pop assigned 2020-06-16T08:07:08Z 2021-09-13T11:58:21Z "Hello, there a view parameters that can't be set after compilation. For example parameters that define an array size. Is it possible to set these kind of parameters while compiling? Is there any compilerflag that allows this? best regards Lukas Koenemann" lukas.koenemann@… 6016 Unable to access Open Modelica from Scilab OMPython v1.16.0-dev defect Alachew Mengist new 2020-06-17T11:55:00Z 2021-09-13T11:58:21Z "I am using 'OpenModelica v1.16.0-dev-371-geb234c072 (64-bit)', 'Python 2.7.18' and 'Scilab-5.5.2'. I want to access Open Modelica from Scilab and to do so I am using Python as a bridge. I am using PIMS toolbox of Scilab to connect with Python and from there using OMPython to work with OpenModelica. But whenever I try to access an OMCSessionZMQ() from Scilab using Python. I get the following error -> '''''OMPython - ERROR - OMC Server is down. Please start it! Log-file says: Created ZeroMQ Server. Dumped server port in file: C:\Users\USER~1\AppData\Local\Temp\/openmodelica.port.69f1318e05e04a1eac6f7296ee05ebbb OMC did not exit after being sent the quit() command; killing the process with pid=9980 !--error 999 Method invocation: An error occurred: Unable to invoke the method: OMCSessionZMQ Python interpreter threw an exception: Traceback: File C:\Python27\lib\site-packages\OMPython_init.py, line 559, in init File C:\Python27\lib\site-packages\OMPython_init_.py, line 582, in connect_to_omc exceptions.Exception: OMC Server is down. Could not open file c:/users/user~1/appdata/local/temp/sci_tmp_8420/openmodelica.port.69f1318e05e04a1eac6f7296ee05ebbb_''''' Whereas if I try to do the same thing from the command line directly by running ""cmd"" command and starting a python session by executing the ""python"" command. Then it is working fine and giving the following result -> '''''OMPython - INFO - OMC Server is up and running at file:///c:/users/user~1/appdata/local/temp/openmodelica.port.4b6d2d21a95d499194d5bfb4fd58392a pid=2012''''' I tried executing the same thing by starting command line from Python in Scilab, but that also doesn't work out. Please help. Kindly also let me know if there are other methods to connect Scilab with OpenModelica." anonymous 6041 Fix FMU dependencies with CVODE FMI v1.16.0-dev defect Andreas Heuermann new 2020-07-01T14:53:05Z 2021-09-13T11:58:21Z "FMUs exported with CVODE are missing some libraries in the binary folder of the FMU. {{{ loadString("" model BouncingBall parameter Real e=0.7 \""coefficient of restitution\""; parameter Real g=9.81 \""gravity acceleration\""; parameter Real v_stick = 1e-4 \""below this velocity, the ball is stuck to the table\""; output Real h(fixed=true, start=1) \""height of ball\""; output Real v(fixed=true) \""velocity of ball\""; Boolean flying(fixed=true, start=true) \""true, if ball is flying\""; Boolean impact; Real v_new(fixed=true); Integer foo; equation impact = h <= 0.0; foo = if impact then 1 else 2; der(v) = if flying then -g else 0; der(h) = v; when h <= 0 then v_new = -e*pre(v); flying = v_new > v_stick; reinit(v, if flying then v_new else 0); end when; annotation( experiment(StartTime = 0, StopTime = 4, Tolerance = 1e-6, Interval = 0.006)); end BouncingBall;""); getErrorString(); setCommandLineOptions(""--fmiFlags=s:cvode""); getErrorString(); buildModelFMU(BouncingBall, version=""2.0"", fmuType=""cs"", platforms={""static""}); getErrorString(); }}} FMPy is reporting {{{ BouncingBall# fmpy simulate BouncingBall.fmu Traceback (most recent call last): File ""/usr/local/lib/python3.8/dist-packages/fmpy/fmi1.py"", line 142, in __init__ self.dll = cdll.LoadLibrary(libraryPath) File ""/usr/lib/python3.8/ctypes/__init__.py"", line 451, in LoadLibrary return self._dlltype(name) File ""/usr/lib/python3.8/ctypes/__init__.py"", line 373, in __init__ self._handle = _dlopen(self._name, mode) OSError: libsundials_cvode.so.1: cannot open shared object file: No such file or directory During handling of the above exception, another exception occurred: Traceback (most recent call last): File ""/usr/local/bin/fmpy"", line 8, in sys.exit(main()) File ""/usr/local/lib/python3.8/dist-packages/fmpy/command_line.py"", line 104, in main result = simulate_fmu(args.fmu_filename, File ""/usr/local/lib/python3.8/dist-packages/fmpy/simulation.py"", line 557, in simulate_fmu fmu = instantiate_fmu(unzipdir, model_description, fmi_type, visible, debug_logging, logger, fmi_call_logger, use_remoting) File ""/usr/local/lib/python3.8/dist-packages/fmpy/simulation.py"", line 632, in instantiate_fmu fmu = FMU2Slave(**fmu_args) File ""/usr/local/lib/python3.8/dist-packages/fmpy/fmi2.py"", line 496, in __init__ super(FMU2Slave, self).__init__(**kwargs) File ""/usr/local/lib/python3.8/dist-packages/fmpy/fmi2.py"", line 85, in __init__ super(_FMU2, self).__init__(**kwargs) File ""/usr/local/lib/python3.8/dist-packages/fmpy/fmi1.py"", line 144, in __init__ raise Exception(""Failed to load shared library %s. %s"" % (libraryPath, e)) Exception: Failed to load shared library /tmp/tmpxa7o573d/binaries/linux64/BouncingBall.so. libsundials_cvode.so.1: cannot open shared object file: No such file or directory }}}" Andreas Heuermann 6064 Changes after restart OMEdit v1.16.0-dev defect Adeel Asghar new 2020-07-23T07:23:37Z 2021-09-13T11:58:21Z "In the bottom of OMEdit tools|Options there is a label saying {{{ * The changes will take effect after restart. }}} Since not all options require restarting to see their effect, I assume that it should indicate which options require restarting. I have some recommendations about it: 1) the text is somewhat misleading, for me much better would be {{{ *These changes will take effect after restart. }}} 2) In some of the options sub-windows, e.g. ""Text editor"", ""Modelica editor"", etc. no item has an asterisk. When the user looks at these sub-windows the above-mentioned bottom label is misleading: should be hidden 3) at least in the following case the label is wrong: the check-box ""Enable front end for code generation"" has no asterisk, while it does require restarting to take effect " massimo ceraolo 6070 Incorrect warning during compilation of model with external component Code Generation v1.16.0-dev defect Adrian Pop assigned 2020-07-27T17:23:18Z 2021-09-13T11:58:21Z "Dear all, during compilation of a model using an external library (dll) on Windows. I receive incorrect warnings about the library be missing from any one of the reported folders. The point is that: 1. The library is not missing; 2. Compilation completes correctly. It would be better not to receive the warning because it can mislead the user when debugging. In fact, this is the last part of the reported output: {{{ External Objects (1) ======================================== 1: tsmh:EXTOBJ: SHCControls.TSModel.TSModelHandle() = SHCControls.TSModel.TSModelHandle.constructor(""C:\\Development\\shc-controls\\SHCLib\\Python\\tests\\cannonau2x2.mat"", ""Cannonau"") type: ExternalObject SHCControls.TSModel.TSModelHandle post-optimization done. [2] 18:58:16 Symbolic Notification The following Modelica-like model represents the back-end DAE for the 'dumpindxdae' stage: /* This is probably not complete. */ model SHCControls.TSModel.Test /* system #1 */ Real y[2](); Real y[1](); equation /* system #1 */ y = SHCControls.TSModel.tsmEval(tsmh, {0.5, 50000.0}, 2); end SHCControls.TSModel.Test; [3] 18:58:16 Translation Warning [SHCControls.TSModel: 8:5-19:20]: Could not find library TSModel-Interface in either of: /usr/lib//TSModel-Interface.dll /usr/lib//libTSModel-Interface.a /usr/lib//libTSModel-Interface.lib /lib//TSModel-Interface.dll /lib//libTSModel-Interface.a /lib//libTSModel-Interface.lib /usr/lib//TSModel-Interface.dll /usr/lib//libTSModel-Interface.a /usr/lib//libTSModel-Interface.lib /lib//TSModel-Interface.dll /lib//libTSModel-Interface.a /lib//libTSModel-Interface.lib C:/Program Files/OpenModelica1.14.1-64bit//lib//omc/TSModel-Interface.dll C:/Program Files/OpenModelica1.14.1-64bit//lib//omc/libTSModel-Interface.a C:/Program Files/OpenModelica1.14.1-64bit//lib//omc/libTSModel-Interface.lib C:/Program Files/OpenModelica1.14.1-64bit//lib//TSModel-Interface.dll C:/Program Files/OpenModelica1.14.1-64bit//lib//libTSModel-Interface.a C:/Program Files/OpenModelica1.14.1-64bit//lib//libTSModel-Interface.lib %APPDATA%/.openmodelica/binaries/SHCControls/TSModel-Interface.dll %APPDATA%/.openmodelica/binaries/SHCControls/libTSModel-Interface.a %APPDATA%/.openmodelica/binaries/SHCControls/libTSModel-Interface.lib /C:/Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release/mingw64/TSModel-Interface.dll /C:/Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release/mingw64/libTSModel-Interface.a /C:/Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release/mingw64/libTSModel-Interface.lib /C:/Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release/win64/TSModel-Interface.dll /C:/Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release/win64/libTSModel-Interface.a /C:/Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release/win64/libTSModel-Interface.lib /C:/Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release/TSModel-Interface.dll /C:/Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release/libTSModel-Interface.a /C:/Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release/libTSModel-Interface.lib [4] 18:58:16 Translation Warning [SHCControls.TSModel: 21:5-30:19]: Could not find library TSModel-Interface in either of: /usr/lib//TSModel-Interface.dll /usr/lib//libTSModel-Interface.a /usr/lib//libTSModel-Interface.lib /lib//TSModel-Interface.dll /lib//libTSModel-Interface.a /lib//libTSModel-Interface.lib /usr/lib//TSModel-Interface.dll /usr/lib//libTSModel-Interface.a /usr/lib//libTSModel-Interface.lib /lib//TSModel-Interface.dll /lib//libTSModel-Interface.a /lib//libTSModel-Interface.lib C:/Program Files/OpenModelica1.14.1-64bit//lib//omc/TSModel-Interface.dll C:/Program Files/OpenModelica1.14.1-64bit//lib//omc/libTSModel-Interface.a C:/Program Files/OpenModelica1.14.1-64bit//lib//omc/libTSModel-Interface.lib C:/Program Files/OpenModelica1.14.1-64bit//lib//TSModel-Interface.dll C:/Program Files/OpenModelica1.14.1-64bit//lib//libTSModel-Interface.a C:/Program Files/OpenModelica1.14.1-64bit//lib//libTSModel-Interface.lib %APPDATA%/.openmodelica/binaries/SHCControls/TSModel-Interface.dll %APPDATA%/.openmodelica/binaries/SHCControls/libTSModel-Interface.a %APPDATA%/.openmodelica/binaries/SHCControls/libTSModel-Interface.lib /C:/Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release/mingw64/TSModel-Interface.dll /C:/Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release/mingw64/libTSModel-Interface.a /C:/Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release/mingw64/libTSModel-Interface.lib /C:/Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release/win64/TSModel-Interface.dll /C:/Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release/win64/libTSModel-Interface.a /C:/Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release/win64/libTSModel-Interface.lib /C:/Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release/TSModel-Interface.dll /C:/Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release/libTSModel-Interface.a /C:/Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release/libTSModel-Interface.lib }}} but the library path is indeed: {{{ C:\Development\shc-controls\SHCLib\C-Cpp\Cpp-ModelicaInterface\Build\Release\win64\TSModel-Interface.dll }}} Moreover, some paths are printed with an extra slash at the beginning. I do hope this is useful. Anton P.S. If needed, the Modelica side of the source code is: {{{ within SHCControls; package TSModel extends Modelica.Icons.TypesPackage; class TSModelHandle extends ExternalObject; function constructor ""Gets an handle to a TSModel object loaded from file."" extends Modelica.Icons.Function; input String fileName; input String modelName; output TSModelHandle tsmh; external ""C"" tsmh = initTSModel(fileName, modelName) annotation( Library=""TSModel-Interface"", LibraryDirectory=""file:///C:/Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release""); //C:\\Development\\shc-controls\\SHCLib\\C-Cpp\\Cpp-ModelicaInterface\\Build\\Release end constructor; function destructor ""Release storage of the TSModel object."" extends Modelica.Icons.Function; input TSModelHandle tsmh; external ""C"" finalTSModel(tsmh) annotation( Library=""TSModel-Interface"", LibraryDirectory=""file:///C:/Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release""); // external ""C"" finalTSModel(tsmh) annotation(Library=""TSModel-Interface""); // If not specified looks in the default dir Library/win64 end destructor; end TSModelHandle; function tsmEval ""Evaluate model at point u"" extends Modelica.Icons.Function; input TSModelHandle tsmh; input Real u[:]; output Real y[ysize]; input Integer ysize; external ""C"" tsmEval(tsmh, u, size(u,1), y, size(y, 1)) annotation(Library=""TSModel-Interface"", LibraryDirectory=""file:///Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release""); end tsmEval; function invTsmEval ""Evaluate inverse model at point y"" extends Modelica.Icons.Function; input TSModelHandle tsmh; input Real u0[:]; input Real y[:]; output Real u[usize]; input Integer usize; external ""C"" tsmEvalInv(tsmh, u0, size(u0,1), y, size(y,1), u, size(u,1)) annotation(Library=""TSModel-Interface"", LibraryDirectory=""file:///Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release""); end invTsmEval; model Test ""Test of the TSModel package"" TSModelHandle tsmh = TSModelHandle(fileName = ""C:\\Development\\shc-controls\\SHCLib\\Python\\tests\\cannonau2x2.mat"", modelName = ""Cannonau""); // call initTSModel Real u[2] = {0.5, 50e3}; Real y[2]; equation y = tsmEval(tsmh, u, size(y,1)); end Test; end TSModel; }}} " Anton.Soppelsa@eurac.edu 6077 OM 1.16 fails to read XML parameters from input file Run-time v1.16.0-dev defect Andreas Heuermann reopened 2020-07-30T09:11:45Z 2021-09-13T11:58:21Z "Hi there, In SolarTherm (https://github.com/SolarTherm/SolarTherm), we make direct use of the compiled model executable ('C runtime') to run our simulations, and we pass modified parameters into each simulation by writing customised XML input files for each run-case. However we have noticed that since Modelica 1.16, we have not been able to use this feature successfully. It is as though OM 1.16 is *not reading* the XML file provided. We've written a test case to show the problem This case works correctly with OM 1.14 but fails with 1.16. https://github.com/SolarTherm/SolarTherm/blob/master/tests/TestXMLParameter.py This code basically compiles a simple model file, then modifies the XML input file and runs the simulation. If the updated value from the XML file has been successfully used, the test passes. If not, the test fails. Details on running this case are here: https://github.com/SolarTherm/SolarTherm/wiki/Building-SolarTherm I tested with Ubuntu 18.04. Note that there is ANOTHER bug with OM 1.16 which also impacts on successful running of this test, which I will report separately. Cheers JP" john.pye@… 6078 OPENMODELICALIBRARY and MODELICAPATH ignored? *unknown* v1.16.0-dev defect Martin Sjölund assigned 2020-07-30T09:24:20Z 2021-09-13T11:58:21Z "Hi there, With SolarTherm (https://github.com/SolarTherm/SolarTherm), we execute 'omc' directly to compile our models, and then we invoke the model executable ('C runtime') to run our simulations. We use CMake to install our model library in a user-selectable file location, and rely on the ability to set OPENMODELICALIBRARY environment variable to point correctly at the location of our bespoke model library. Normally we install our files to ~/.local/lib/omlibrary/SolarTherm, for example. With OM 1.14 and also (I believe) 1.15, this worked fine, and 'omc' would correctly find our models and simulation could proceed. However in OM 1.16, we have found that 'omc' doesn't find the model files, and gives us an error about failing to load the package and advising us of the current value of MODELICAPATH: {{{ john@thunder:~/solartherm/examples$ st_simulate --np 0 SimpleSystem.mo Compiling model Error processing file: /home/john/solartherm/examples/SimpleSystem.mo Failed to load library: SolarTherm! Notification: Automatically loaded package Complex 3.2.3 due to uses annotation. Notification: Automatically loaded package ModelicaServices 3.2.3 due to uses annotation. Notification: You can install the requested package using one of the commands: installPackage(SolarTherm, ""0.2.0-master"", exactMatch=true) installPackage(SolarTherm). Error: Failed to load package SolarTherm (default) using MODELICAPATH /usr/bin/../lib/omlibrary:/home/john/.openmodelica/libraries/. # Error encountered! Exiting... # Please check the error message and the flags. Failed to load library: SolarTherm! Execution failed! Traceback (most recent call last): File ""/home/john/.local/bin/st_simulate"", line 138, in sim.compile_model(args=mcargs) File ""/home/john/.local/lib/python2.7/site-packages/solartherm/simulation.py"", line 276, in compile_model + libs) File ""/usr/lib/python2.7/subprocess.py"", line 190, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['omc', '-s', '-q', '-n=0', '-i=SimpleSystem', '/home/john/solartherm/examples/SimpleSystem.mo', 'Modelica', 'SolarTherm']' returned non-zero exit status 1 john@thunder:~/solartherm/examples$ }}} I note that we have the OPENMODELICALIBRARY environment variable set as earlier advised: {{{ john@thunder:~/solartherm/examples$ env|grep MODELICA _OPENMODELICALIBRARY= OPENMODELICALIBRARY=/home/john/.openmodelica/libraries:/home/john/.local/lib/omlibrary:/usr/lib/omlibrary:/usr/local/lib/omlibrary }}} I note that if I set MODELICAPATH to equal our above value of OPENMODELICALIBRARY: {{{ john@thunder:~/solartherm/examples$ export MODELICAPATH=$OPENMODELICALIBRARY }}} THEN, it *still* doesn't work; I get the same error: {{{ john@thunder:~/solartherm/examples$ st_simulate --np 0 SimpleSystem.mo Compiling model Error processing file: /home/john/solartherm/examples/SimpleSystem.mo Failed to load library: SolarTherm! Notification: Automatically loaded package Complex 3.2.3 due to uses annotation. Notification: Automatically loaded package ModelicaServices 3.2.3 due to uses annotation. Notification: You can install the requested package using one of the commands: installPackage(SolarTherm, ""0.2.0-master"", exactMatch=true) installPackage(SolarTherm). Error: Failed to load package SolarTherm (default) using MODELICAPATH /usr/bin/../lib/omlibrary:/home/john/.openmodelica/libraries/. [...] }}} And to double check, {{{ john@thunder:~/solartherm/examples$ env|grep MODELICA MODELICAPATH=/home/john/.openmodelica/libraries:/home/john/.local/lib/omlibrary:/usr/lib/omlibrary:/usr/local/lib/omlibrary _OPENMODELICALIBRARY= OPENMODELICALIBRARY=/home/john/.openmodelica/libraries:/home/john/.local/lib/omlibrary:/usr/lib/omlibrary:/usr/local/lib/omlibrary }}} So it seems that whatever support previously existed for using environment variables to control 'omc' has become broken, and it seems that the error message being provided by OMC is inaccurate, since even setting MODELICAPATH doesn't seem to work. Any thoughts? Cheers JP" john.pye@… 6079 Conflict between modelica_synchronous and pulse source Backend defect Karim Adbdelhak new 2020-07-30T11:34:48Z 2021-09-13T11:58:21Z "Hi, I implemented a wrapping counter using the modelica_synchronous framework. There is also a pulse source in the same model, with the same period value. The presence of this source triggers the problem: Instead of incrementing at the same frequency as the pulse source, the counter doesn't increment until the 7th period. A hold function behind the wrapping counter outputs impulses, so something is going very wrong. After working properly for 7 periods, the counter stops See the attached image. When the pulse source is removed or set to a different period, the wrapping counter behaves as expected. Does anyone have a clue what's happening here? Best regards, Paul van der Hulst" p.van.der.hulst@… 6080 Changing parameters of a model via Python FMI v1.16.0-dev defect Lennart Ochel new 2020-07-31T12:18:00Z 2021-09-13T11:58:21Z " I created a minimal example (DC-Voltage, Load) in OpenModelica. Afterwards, I created an FMU and used it via Python. Problem summary: By using just a Resistor as a load, i can´t change the parameters via python. After adding an Inductor to the model, I can change some parameters and the simulation reacts to this changes. In this simple model, there is nothing which could cause troubles from the electrical engineering part, the problem must be somewhere else. '''Model Set-up''' Problematical Model: [[Image(https://i.stack.imgur.com/MFQz5.png)]] {{{ model testbench parameter Real v_DC (start = 100); Modelica.Blocks.Sources.RealExpression realExpression(y = v_DC) annotation( Placement(visible = true, transformation(origin = {-70, 70}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Electrical.Analog.Sources.SignalVoltage signalVoltage annotation( Placement(visible = true, transformation(origin = {-30, 46}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Electrical.Analog.Basic.Resistor resistor(R = 10) annotation( Placement(visible = true, transformation(origin = {-30, 14}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Electrical.Analog.Basic.Ground ground annotation( Placement(visible = true, transformation(origin = {28, 28}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); equation connect(realExpression.y, signalVoltage.v) annotation( Line(points = {{-58, 70}, {-30, 70}, {-30, 58}, {-30, 58}}, color = {0, 0, 127})); connect(signalVoltage.n, resistor.n) annotation( Line(points = {{-20, 46}, {-6, 46}, {-6, 14}, {-20, 14}, {-20, 14}}, color = {0, 0, 255})); connect(signalVoltage.n, ground.p) annotation( Line(points = {{-20, 46}, {28, 46}, {28, 38}, {28, 38}}, color = {0, 0, 255})); connect(resistor.p, signalVoltage.p) annotation( Line(points = {{-40, 14}, {-40, 14}, {-40, 46}, {-40, 46}}, color = {0, 0, 255})); annotation( uses(Modelica(version = ""3.2.3""))); end testbench; }}} Partly working model: [[Image(https://i.stack.imgur.com/w4ncq.png)]] {{{ model testbench parameter Real v_DC (start = 100); Modelica.Blocks.Sources.RealExpression realExpression(y = v_DC) annotation( Placement(visible = true, transformation(origin = {-70, 70}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Electrical.Analog.Sources.SignalVoltage signalVoltage annotation( Placement(visible = true, transformation(origin = {-30, 46}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Electrical.Analog.Basic.Resistor resistor(R = 10) annotation( Placement(visible = true, transformation(origin = {-30, 14}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Electrical.Analog.Basic.Ground ground annotation( Placement(visible = true, transformation(origin = {28, 28}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Electrical.Analog.Basic.Inductor inductor annotation( Placement(visible = true, transformation(origin = {-60, 14}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); equation connect(realExpression.y, signalVoltage.v) annotation( Line(points = {{-58, 70}, {-30, 70}, {-30, 58}, {-30, 58}}, color = {0, 0, 127})); connect(signalVoltage.n, resistor.n) annotation( Line(points = {{-20, 46}, {-6, 46}, {-6, 14}, {-20, 14}, {-20, 14}}, color = {0, 0, 255})); connect(signalVoltage.n, ground.p) annotation( Line(points = {{-20, 46}, {28, 46}, {28, 38}, {28, 38}}, color = {0, 0, 255})); connect(inductor.n, resistor.p) annotation( Line(points = {{-50, 14}, {-40, 14}, {-40, 14}, {-40, 14}}, color = {0, 0, 255})); connect(signalVoltage.p, inductor.p) annotation( Line(points = {{-40, 46}, {-74, 46}, {-74, 14}, {-70, 14}, {-70, 14}}, color = {0, 0, 255})); annotation( uses(Modelica(version = ""3.2.3""))); end testbench; }}} '''Used Software ''' Windows 10 OpenModelica 1.16.0 PyFMI 2.5 Spyder 3.3.6 '''FMU Creation''' Created the FMU with a .mos file with the following settings: OpenModelica.Scripting.loadFile(""testbench.mo""); getErrorString(); setCommandLineOptions(""-d=newInst""); getErrorString(); setCommandLineOptions(""-d=initialization""); getErrorString(); setCommandLineOptions(""--simCodeTarget=Cpp""); getErrorString(); setCommandLineOptions(""-d=-disableDirectionalDerivatives""); getErrorString(); OpenModelica.Scripting.translateModelFMU(testbench, version=""2.0"", fmuType = ""me""); getErrorString(); '''Python code for testing''' {{{ import pylab as P import numpy as N from pyfmi import load_fmu def run_demo(with_plots=True): model = load_fmu('testbench.fmu') Tstart = 0.0 # Tend = 0.1 dt = 0.0001 model.setup_experiment(start_time = Tstart) model.enter_initialization_mode() model.exit_initialization_mode() time = Tstart model.enter_continuous_time_mode() x = model.continuous_states model.set('resistor.R', 1000) model.set('v_DC', 5700) vref = [model.get_variable_valueref('resistor.i')] vref2 = [model.get_variable_valueref('resistor.R')] t_sol = [Tstart] sol = [model.get_real(vref)] sol2 = [model.get_real(vref2)] while time < Tend: dx = model.get_derivatives() time = time + dt model.time = time x = x + dt*dx model.continuous_states = x t_sol += [time] sol += [model.get_real(vref)] sol2 += [model.get_real(vref2)] if with_plots: P.figure(1) P.plot(t_sol,N.array(sol)[:,0]) P.title(model.get_name()) P.ylabel('Current at Resistor1 (A)') P.xlabel('Time (s)') P.figure(2) P.plot(t_sol,N.array(sol2)[:,0]) P.title(model.get_name()) P.ylabel('Resistor1 (Ohm)') P.xlabel('Time (s)') if __name__ == ""__main__"": run_demo() }}} ''' Bugs''' In the second model (with the inductor), a change of the DC voltage (model.set('v_DC', 5700)) leads to a proportional change of the current at resistor1. This works as it should. A change of the value of the resistor (model.set('resistor.R', 10000)) does not affect the current in the resistor in any way. The printing the value shows the one which was actually set (see second plotted figure), but for the calculation of the current, the default value which was selected in OpenModelica is used. In the first model (without inductor), neither a change in the DC voltage nor a change in the Resistor affect the current in the resistor, though should. Within other models, changing the value of the resistor works with the demanded result, and we had difficulties setting the voltage of the source. Is there a mistake in the way of setting the parameters, a bug in OpenModelica, in PyFMI, or what is going on here? " bode@… 6088 Remaining issues with HelmholtzMedia Third-Party Libraries defect Francesco Casella new 2020-08-18T14:28:08Z 2021-09-13T11:58:21Z "As of 25 Aug 2020, we have [https://libraries.openmodelica.org/branches/newInst/HelmholtzMedia/HelmholtzMedia.html 42 runnable models] in the library, which all go through all phases of code generation. One fails during C-code compilation, see #6087. Another five fail at runtime - [https://libraries.openmodelica.org/branches/newInst/HelmholtzMedia/files/HelmholtzMedia_HelmholtzMedia.Examples.ConvergenceTest.Ancillary_Saturation.sim HelmholtzMedia.Examples.ConvergenceTest.Ancillary_Saturation] apparently go above critical temperature - [https://libraries.openmodelica.org/branches/newInst/HelmholtzMedia/files/HelmholtzMedia_HelmholtzMedia.Examples.ConvergenceTest.setSat.sim HelmholtzMedia.Examples.ConvergenceTest.setSat] has convergence issues with {{{setSat_T}}} at time 8.5363 - [https://libraries.openmodelica.org/branches/newInst/HelmholtzMedia/files/HelmholtzMedia_HelmholtzMedia.Examples.MediaTestModels.IsopentaneTestModel.sim HelmholtzMedia.Examples.MediaTestModels.IsopentaneTestModel] fails at initialization, probably because of bad initialization values: {{{ assert | warning | The following assertion has been violated at time 0.000000 | | | | false assert | warning | Nominal variable violating min/max constraint: -725000.0 <= ambient.h_ambient <= 700000.0, has value: 1e+06 }}} - [https://libraries.openmodelica.org/branches/newInst/HelmholtzMedia/files/HelmholtzMedia_HelmholtzMedia.Examples.Validation.Derivatives_SaturationBoundary.sim HelmholtzMedia.Examples.Validation.Derivatives_SaturationBoundary] fails at initialization, possibly because of going supercritical without being able to handle that - [https://libraries.openmodelica.org/branches/newInst/HelmholtzMedia/files/HelmholtzMedia_HelmholtzMedia.Examples.Validation.idealGasLimit.sim HelmholtzMedia.Examples.Validation.idealGasLimit] runs into numerical problems at time = 480 @matthis, feel free to further investigate and comment or ask for clarifications here." Francesco Casella 6124 Special characters inide info.json Code Generation v1.16.0-dev defect Martin Sjölund new 2020-09-17T17:29:49Z 2021-09-13T11:58:21Z "When simulating a model in a path with a special character the path will not be stored correctly in the info.json. For example a file test.mo in directory `/some/Path/specialChars/söWhät` will be saved as `""file"":""/some/Path/specialChars/s\uffffffc3\uffffffb6Wh\uffffffc3\uffffffa4t/test.mo""` The full info.json file: {{{ {""format"":""Transformational debugger info"",""version"":1, ""info"":{""name"":""ChatteringEvents1"",""description"":""Exhibits chattering after t = 0.5, with generated events""}, ""variables"":{ ""x"":{""comment"":"""",""kind"":""state"",""type"":""Real"",""unit"":"""",""displayUnit"":"""",""source"":{""info"":{""file"":""/home/aheuermann1/workspace/Testitesttest/specialChars/s\uffffffc3\uffffffb6Wh\uffffffc3\uffffffa4t/test.mo"",""lineStart"":3,""lineEnd"":3,""colStart"":3,""colEnd"":30}}}, ""der(x)"":{""comment"":"""",""kind"":""derivative"",""type"":""Real"",""unit"":"""",""displayUnit"":"""",""source"":{""info"":{""file"":""/home/aheuermann1/workspace/Testitesttest/specialChars/s\uffffffc3\uffffffb6Wh\uffffffc3\uffffffa4t/test.mo"",""lineStart"":3,""lineEnd"":3,""colStart"":3,""colEnd"":30}}}, ""y"":{""comment"":"""",""kind"":""variable"",""type"":""Real"",""unit"":"""",""displayUnit"":"""",""source"":{""info"":{""file"":""/home/aheuermann1/workspace/Testitesttest/specialChars/s\uffffffc3\uffffffb6Wh\uffffffc3\uffffffa4t/test.mo"",""lineStart"":4,""lineEnd"":4,""colStart"":3,""colEnd"":9}}} }, ""equations"":[{""eqIndex"":0,""tag"":""dummy""}, {""eqIndex"":1,""section"":""initial"",""tag"":""assign"",""defines"":[""x""],""uses"":[""$START.x""],""equation"":[""$START.x""],""source"":{""info"":{""file"":"""",""lineStart"":0,""lineEnd"":0,""colStart"":0,""colEnd"":0}}}, {""eqIndex"":2,""tag"":""alias"",""equation"":[5],""section"":""initial""}, {""eqIndex"":3,""tag"":""alias"",""equation"":[6],""section"":""initial""}, {""eqIndex"":4,""tag"":""alias"",""equation"":[7],""section"":""initial""}, {""eqIndex"":5,""section"":""regular"",""tag"":""assign"",""defines"":[""z""],""uses"":[""x""],""equation"":[""if x > 0.0 then -1.0 else 1.0""],""source"":{""info"":{""file"":""/home/aheuermann1/workspace/Testitesttest/specialChars/s\uffffffc3\uffffffb6Wh\uffffffc3\uffffffa4t/test.mo"",""lineStart"":7,""lineEnd"":7,""colStart"":3,""colEnd"":30}}}, {""eqIndex"":6,""section"":""regular"",""tag"":""assign"",""defines"":[""y""],""uses"":[""z""],""equation"":[""2.0 * z""],""source"":{""info"":{""file"":""/home/aheuermann1/workspace/Testitesttest/specialChars/s\uffffffc3\uffffffb6Wh\uffffffc3\uffffffa4t/test.mo"",""lineStart"":8,""lineEnd"":8,""colStart"":3,""colEnd"":10}}}, {""eqIndex"":7,""section"":""regular"",""tag"":""assign"",""defines"":[""der(x)""],""uses"":[""y""],""equation"":[""y""],""source"":{""info"":{""file"":""/home/aheuermann1/workspace/Testitesttest/specialChars/s\uffffffc3\uffffffb6Wh\uffffffc3\uffffffa4t/test.mo"",""lineStart"":9,""lineEnd"":9,""colStart"":3,""colEnd"":13}}} ], ""functions"":[ ] } }}}" Andreas Heuermann 6159 timeline not visible anymore *unknown* defect Adrian Pop assigned 2020-10-15T08:49:11Z 2021-09-13T11:58:21Z "Hi, since a few days I can't access the timeline view. The error is ""TIMELINE_VIEW privileges are required to perform this operation. You don't have the required permissions."" I know it has nothing to do with openmodelica itself, but I can't find any information who to contact. My login from openmodelica is also not working... thanks in advance " anonymous 6161 [FMI] FMU with string parameters will crash if a memory pool collection happens FMI defect Adrian Pop accepted 2020-10-16T15:15:31Z 2021-09-13T11:58:21Z " The memory pool frees the string parameters which it shouldn't do. We need a way to alloc and save the string parameters so that we can free them properly, but only when the FMU is terminated. " Adrian Pop 6172 Issue with for loop index variables in conditional expression within algorithm Code Generation defect Mahder Alemseged Gebremedhin accepted 2020-10-31T18:59:52Z 2021-09-13T11:58:21Z "Consider the following test model {{{#!mo class matrixAdd parameter Real[3,2] m={{1,2},{2,3},{4,5}}; parameter Real[3,2] a={{2,2},{2,2},{2,2}}; Real[3,2] b; Real max; algorithm max:=0; for i in 1:3 loop for j in 1:2 loop b[i,j]:=m[i,j]+a[i,j]; if (maxlocalData[0]->realVars[6] /* max variable */, (&data->localData[0]->realVars[0] /* b[1,1] variable */)[calc_base_index_dims_subs(2, 3, 2, i, ((modelica_integer) 1))], data->simulationInfo->storedRelations[0]); ^ matrixAdd_05evt.c:51:161: note: each undeclared identifier is reported only once for each function it appears in matrixAdd_05evt.c: In function 'matrixAdd_function_updateRelations': matrixAdd_05evt.c:78:163: error: 'i' undeclared (first use in this function) tmp2 = LessZC(data->localData[0]->realVars[6] /* max variable */, (&data->localData[0]->realVars[0] /* b[1,1] variable */)[calc_base_index_dims_subs(2, 3, 2, i, ((modelica_integer) 1))], data->simulationInfo->storedRelations[0]); }}}" Francesco Casella 6178 unable -assert (simulation flag) with ompython OMPython defect arunkumar palanisamy new 2020-11-04T10:58:36Z 2021-09-13T11:58:21Z "Hello, I'm using OMPython to simulate OpenModelica models. Inside of OMPython there is an option to call the *.exe-file with some simulation flags. A default option of OpenModelica is the ""-lv=assert"" Option. On the Website https://www.openmodelica.org/doc/OpenModelicaUsersGuide/latest/simulationflags.html it says that one can unable this with the flag ""-lv=-assert"", but while simulating it is still showing the assers from the simulation in the commandline. The other standard Options (-lv=Log_Succes & -lv=stdout) i can unable with the flag ""-lv=-stdout"" ,... " lukas.koenemann@… 6181 Boolean incorrectly evaluated and asserts, implying negative time? Run-time v1.17.0-dev defect Andreas Heuermann new 2020-11-05T05:06:57Z 2021-09-13T11:58:21Z "''The following asserts time is less than zero. Did not assert in previous versions of OMC'' {{{#!mo model DebugInitialValue model BooleanPulse input Real width(start=0.5); output Boolean y; equation y = time < width; end BooleanPulse; class DayNightCycle parameter Real earth_day_period=24; Real daylight_ratio; BooleanPulse daylight(width=daylight_ratio); end DayNightCycle; parameter Real ratio_start=0; Real _ratio; DayNightCycle cycle(daylight_ratio=_ratio); //FAILS. Will work if changed to daylight_ratio=0 here. algorithm _ratio := ratio_start; if not initial() then assert(cycle.daylight.y==false,""oops"",level=AssertionLevel.warning); end if; end DebugInitialValue; }}}" craig.fletcher@… 6184 getInstallationDirectoryPath() depends on executable starting location Interactive Environment defect Adrian Pop new 2020-11-06T09:27:42Z 2021-09-13T11:58:21Z "If I start `OMEdit` from `$OPENMODELICAHOME/build/bin` then I get, {{{ getInstallationDirectoryPath() ""C:/OpenModelica/build"" }}} but if I run it from `$OPENMODELICAHOME/OMEdit/bin` then I get, {{{ getInstallationDirectoryPath() ""C:/OpenModelica/build/lib"" }}} " Adeel Asghar 6185 Freeze&Crash (occasionally) when modifying Plot Setup OMEdit v1.16.0-dev defect Adeel Asghar new 2020-11-06T10:59:31Z 2021-09-13T11:58:21Z "Sometimes, when in Plotting mode, modifying the appearance of plotted variables via the Plot Setup dialog, OMEdit freezes and then crashes. It seems to happen at random. This is not a new bug, it happened in 1.14.0 too." anonymous 6186 "Assert triggered during initialization despite ""not initial()"" if-statement" Backend v1.17.0-dev defect Andreas Heuermann assigned 2020-11-06T12:12:15Z 2021-09-13T11:58:21Z "When formulating an assert that is not allowed to be checked during initialization omc will check it any way and the assert triggers. See following example: {{{ loadString("" model missingInitial Real x; equation x = time; if not initial() then assert(not x==0, \""This assert is not allowed to trigger during initalization.\"",level=AssertionLevel.warning); end if; end missingInitial; ""); getErrorString(); setCommandLineOptions(""-d=newInst,optdaedump --removeSimpleEquations=none""); getErrorString(); simulate(missingInitial); getErrorString(); }}} {{{ assert | warning | The following assertion has been violated during initialization at time 0.000000 | | | | not x == 0.0 assert | warning | This assert is not allowed to trigger during initalization. LOG_SUCCESS | info | The initialization finished successfully without homotopy method. LOG_SUCCESS | info | The simulation finished successfully. }}}" Andreas Heuermann 6211 VDI6007.TestCaseXX models fail in Buildings Run-time defect Andreas Heuermann new 2020-11-10T10:40:32Z 2021-09-13T11:58:21Z "All the VDI6007.TestCaseXX models in Buildings fail because of the same issue, see e.g. [https://libraries.openmodelica.org/branches/newInst/Buildings_7.0.0/files/Buildings_7.0.0_Buildings.ThermalZones.ReducedOrder.Validation.VDI6007.TestCase1.sim this one]. An assertion is violated concerning the counting of certain discrepancies. This involves event handling, the root cause should be investigated." Francesco Casella 6212 First tick of shiftsample is missing OMSimulator defect Andreas Heuermann assigned 2020-11-10T12:07:46Z 2021-09-13T11:58:21Z "Hi, When shifting a clock with shiftSample (as explained in Fritzson, Principles of object-oriented modeling..... 2nd ed., page 709/710) the first tick of the shifted clock y1 (expected at 0.1sec) is missing. Below is an example model derived from Fritzson's example. I added 'Count1' and 'Count2' variables to reveal the actual sampling moment, since sampling instances are not clear from the OMedit plots. {{{ model test3 Clock u1 = Clock(3,10); Clock y1=shiftSample(u1,1,3); Real Count1(start=2); Real Count2(start=2); initial equation equation Count1 = sample(time,u1); Count2 = sample(time,y1); end test3; }}} The first update of Count2 is at 0.4 sec instead of at 0.1 sec. I use OpenModelica 1.16.0 (this does not seem to be an option in the drop-down list below). Best regards, Paul van der Hulst PS. Note that in dymola I ''do'' get the first sample at 0.01sec." p.van.der.hulst@… 6213 Lookup in wrong scope when redeclaring function field in a function New Instantiation v1.17.0-dev defect Per Östlund accepted 2020-11-10T14:42:02Z 2021-09-13T11:58:21Z "Modelica_LinearSystems2.Controller.Examples.DiscretizationSeries has some code with the same error as: {{{ record R Real x[:]; end R; function f input Integer n; output R r(redeclare Real x[n]); end f; model M Real x[:] = f(3); end M; }}}" Martin Sjölund 6224 OM cannot run some electrical load flow calculations from open-source library PowerSysPro Initialization 1.16.0 defect Karim Adbdelhak new 2020-11-13T08:14:35Z 2021-09-13T11:58:21Z "Hello All EDF is developping some open-source Modelica libraries and you already know some of them (ThemoSysPro, BuildSysPro, ...). In the electrical domain,a new library is being developped by EDF too. This library is available here: https://bitbucket.org/simulage/powersyspro/wiki/Home As you can read it in the Wiki of this page, OpenModelica is not currently able to run most of models instantiating PowerSysPro components. You can check this trying to run cases from the package Examples of the library, especially for models mixing several lines and transformers. Th problem occurs in the intialization part of the solver, something close to a Newton-Raphson algorithm. Best regards" JPhi Tavella 6225 OMSimulator hangs in the HUBCAP sandbox OMSimulator v1.17.0-dev defect Adrian Pop new 2020-11-13T09:57:25Z 2020-11-20T10:12:48Z "If I try to start the FMU simulation in the HUBCAP sandboxes (both command line and GUI), the simulation hangs. The models showing this behavior are attached. One of the models has an FMU generated with Overture 2.8.5 whereas the others FMU was generated with Overture 3.0.2. These SSP models were constructed by following the instructions from https://download.fortiss.org/public/projects/af3/help/example_co-simulation.html. When executing the OMSimulator on the command line, the following output is produced: {{{ # OMSimulator --numProcs=1 TestSSP.ssp info: Set temp directory to ""/home/adrpo33/testing/omsimulator"" info: Set working directory to ""/home/adrpo33/testing/omsimulator"" info: New model ""TestSSP"" with corresponding temp directory ""/home/adrpo33/testing/omsimulator/TestSSP-6jkx7taq"" info: Set working directory to ""/home/adrpo33/testing/omsimulator"" info: Set working directory to ""/home/adrpo33/testing/omsimulator/TestSSP-6jkx7taq"" info: Set working directory to ""/home/adrpo33/testing/omsimulator"" error: [terminate] Model ""TestSSP"" is in wrong model state info: 0 warnings info: 1 errors }}} The workaround mentioned in the ticket #6182 ({{{OMSimulator --deleteTempFiles=false TestSSP.ssp}}}) does not help here. " diewald@… 6226 OMEdit freezes when starting/initializing a SSP simulation from the GUI *unknown* 1.16.0 defect Adrian Pop new 2020-11-13T10:10:26Z 2020-11-13T10:10:26Z "When starting a SSP simulation under Linux from the GUI, OMEdit hangs. It can be worked around by starting the simulation from the command line if a switch to keep temporary files is included: {{{ OMSimulator --deleteTempFiles=false ../TestSSP.ssp }}} Note that this behavior is already present in OpenModelica versions <= 1.16. This issue is also different from https://trac.openmodelica.org/OpenModelica/ticket/6225 that is about the HUBCAP OpenModelica sandbox. If the simulation is started from the GUI in Windows, the simulation behaves as expected and OMEdit does not freeze." diewald@… 6233 Tooltip shows wrong unit OMEdit 1.16.0 defect Adeel Asghar new 2020-11-20T09:49:40Z 2021-09-13T11:58:21Z "Consider the following example of an electric circuit using a ramp voltage: {{{ model ParametricPlotToolTip Modelica.Electrical.Analog.Basic.Ground ground annotation( Placement(visible = true, transformation(origin = {-80, -50}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Electrical.Analog.Basic.Resistor resistor(R = 100) annotation( Placement(visible = true, transformation(origin = {-40, 0}, extent = {{-10, -10}, {10, 10}}, rotation = -90))); Modelica.Electrical.Analog.Sources.RampVoltage rampVoltage(V = 100, duration = 1) annotation( Placement(visible = true, transformation(origin = {-80, 0}, extent = {{-10, -10}, {10, 10}}, rotation = -90))); equation connect(rampVoltage.n, ground.p) annotation( Line(points = {{-80, -10}, {-80, -40}}, color = {0, 0, 255})); connect(rampVoltage.p, resistor.p) annotation( Line(points = {{-80, 10}, {-80, 30}, {-40, 30}, {-40, 10}}, color = {0, 0, 255})); connect(resistor.n, ground.p) annotation( Line(points = {{-40, -10}, {-40, -30}, {-80, -30}, {-80, -40}}, color = {0, 0, 255})); annotation( uses(Modelica(version = ""3.2.3""))); end ParametricPlotToolTip; }}} Run the simulation and create a parametric plot with {{{rampVoltage.v}}} on the horizontal axis and {{{resistor.i}}} on the vertical axis. When moving the mouse pointer onto the curve, a tooltip is shown indicating the actual point. However, the horizontal quantity is show in seconds (s) instead of Volt (V)." dr.christian.kral@… 6259 Free parameters mess up FMI model structure Backend v1.17.0-dev defect Karim Adbdelhak new 2020-12-01T17:29:14Z 2021-09-13T11:58:21Z "See the following example: {{{#!mo model SI1 ""Single Integrator with fixed parameter"" parameter Real p = 1 ""gain for input""; input Real u(start = -2); output Real y(start = p); equation der(y) = p * u; end SI1; }}} for which FMI 2.0 export generates the following reasonable Outputs and Derivatives structure in modelDescription.xml. InitialUnknowns appears a bit ""over-engineered"" (y alias, der(y) and y unknown; der(y) depending on u and p): {{{#!xml }}} Now see a model with slight modification (free parameter): {{{#!mo model SI2 ""Single Integrator with free parameter"" parameter Real p(fixed = false) ""gain for input""; input Real u(start = -2); output Real y(start = p); initial equation p = 1; equation der(y) = p * u; end SI2; }}} Outputs and Derivatives loose their dependencies. The now more interesting InitialUnknowns disappear completely: {{{#!xml }}} What happens to dependencies of Outputs and Derivatives?" Rüdiger Franke 6263 Fix spurious remaining issues in the master testsuite Testing Framework 1.16.0 defect Adrian Pop new 2020-12-03T10:41:22Z 2021-09-13T11:58:21Z "After @AnHeuermann merged in [https://github.com/OpenModelica/OpenModelica/pull/6978 PR 6978], one cause for random improvements and regressions in each run of the entire testsuite was fixed for good. Unfortunately, we still have some issues that are causing this behaviour in a few models involving Python and DeviceDrivers (see below). This is no big deal, but it would be nice to get rid of them, and at long last getting clean regression reports. The UDP models are reported as regressions even though the [https://libraries.openmodelica.org/branches/master/Modelica_DeviceDrivers/files/Modelica_DeviceDrivers_Modelica_DeviceDrivers.Blocks.Examples.TestSerialPackager_UDP.sim simulation log] seems to indicate success. I guess there is something fishy in the way the simulation process is terminated that triggers a non-zero exit code or something. The Python examples just [https://libraries.openmodelica.org/branches/master/Buildings_7.0.0/files/Buildings_7.0.0_Buildings.Obsolete.Utilities.IO.Python27.Functions.Examples.Exchange.sim segfault] every now and then. Could someone please try to look into these two issues and fix them for good?" Francesco Casella 6264 An assert() is not correctly handled by OM: wrong violated equation Backend 1.16.0 defect Andreas Heuermann assigned 2020-12-03T10:59:22Z 2021-09-13T11:58:21Z "I more carrefully check results from simulation of models of the new library PowerSysPro developped by EDF and available here: ​https://bitbucket.org/simulage/powersyspro/wiki/Home Important note: use the version 1.4 for OM (don't use the last version 1.5 due to discussion in ticket #6261). The issue is related to the model OneSouceOneLineOneSource (package Examples). The assert() condition is not correctly reported by OM as the log information is: The following assertion has been violated during initialization at time 0.000000 src1.I <= 50.0 Current flowing the line is exceeding the maximum admissible current for PowerSysPro.Examples.OneSouceOneLineOneSource.line The violated equation src1.I <= 50.0 is wrong and should be replaced by line.IA <= 50.0 This assert() is correctly handled by Dymola." jean-philippe.tavella@… 6265 assert() not correctly handled by OM: second case *unknown* 1.16.0 defect Francesco Casella new 2020-12-03T12:40:43Z 2021-09-13T11:58:21Z "This ticket completes previous ticket #6264. Refer to model DegradedModeForLoads in package Examples. I see two issues in the handling of assert(): 1/ The assert() not load.U < load.minU is not reported with the correct time. The time is 36.8 and should be 36.0 (exactly the same time as for assert() load.degradedMode == false) 2/An assert is missing. The assert() load.degradedMode = true should be reported a second time at approx. time = 364 No issue with Dymola." jean-philippe.tavella@… 6277 Parameter with negative sign changes display unit OMEdit v1.17.0-dev defect Adeel Asghar new 2020-12-09T17:10:33Z 2021-09-13T11:58:21Z "Consider the following (attached) example: {{{ model Degree Modelica.Electrical.QuasiStationary.SinglePhase.Basic.Ground ground annotation( Placement(visible = true, transformation(origin = {0, -26}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Electrical.QuasiStationary.SinglePhase.Sources.VoltageSource voltageSource(phi (displayUnit = ""deg"") = 0) annotation( Placement(visible = true, transformation(origin = {0, 10}, extent = {{-10, -10}, {10, 10}}, rotation = -90))); equation connect(voltageSource.pin_n, ground.pin) annotation( Line(points = {{0, 0}, {0, -16}}, color = {85, 170, 255})); annotation( uses(Modelica(version = ""3.2.3""))); end Degree; }}} For the angle {{{phi}}} the display unit {{{deg}}} is defined. I perform a double click on the voltage source model to change the parameter settings. I mark the {{{0}}} of {{{phi}}} by double clicking on it and to then overwrite it with a new negative number. As I start typing the negative sign, e.g. in {{{-240}}}, the display unit switches to {{{rad}}}." Christian Kral 6279 FMU shows parameters that should be hidden FMI v1.17.0-dev defect Lennart Ochel reopened 2020-12-12T11:12:56Z 2021-09-13T11:58:21Z "Consider model TestFMU below (annotations dropped) {{{ model TestFMU parameter Real K = 1; Modelica.Blocks.Interfaces.RealInput u; Modelica.Blocks.Interfaces.RealOutput y; Modelica.Blocks.Math.Gain gain1(k = K / 2); Modelica.Blocks.Math.Gain gain(k = 1); equation connect(gain1.u, u); connect(gain1.y, gain.u); connect(gain.y, y); end TestFMU; }}} I exported it as FMU-ME 2.0 and imported into Dymola the parameter window is as in the enclosed file screen.png. I think the parameter gain1_k shouldn't be visible in the dialog box, since it is internally computed through a binding formula." massimo ceraolo 6282 Allow mainstream use of ParModAuto ParModelica 1.16.0 defect Mahder Alemseged Gebremedhin new 2020-12-14T23:03:14Z 2022-03-28T12:16:02Z "The ParModAuto infrastructure for parallel simulation was merged into master with [https://github.com/OpenModelica/OpenModelica/pull/6825 PR 6825]. To make it available to mainstream end-users and not only to hard-core developers of OpenModelica, three final steps are required: - Make the infrastructure usable by just activating the {{{--parModAuto}}} flag, without the need of recompiling the source code - Include some documentation in the [https://openmodelica.org/doc/OpenModelicaUsersGuide/latest/index.html User's Guide] - Add some tests to the testsuite so that this infrastructure is regularly tested and does not inadvertently get broken" Francesco Casella 6292 Multiple instances of the same FMU exported from OM cannot be run in parallel FMI 1.16.0 defect Francesco Casella new 2020-12-17T13:55:47Z 2021-09-13T11:58:21Z "I try to use several instances of the same FMU (for Co-Simulation) exported from OM 1.16.0. I can run the case with our tool DNG 2021, but only with special flags on our tool to run with: - Stepping multithreaded : false - Termination multithreaded : false When these flags are true, the FMU fails as reported here in our issueTracker: https://bitbucket.org/simulage/daccosim/issues/20/a-case-where-the-loglck-file-remaisn-after I suspect the issue is on the termination part, not the stepping. Probably a problem in the thread-safe mechanism... Note: the same issue occured in the past with Dymola FMUs and DS solved it." jean-philippe.tavella@… 6312 dgesv failing in windows when computing Ax=b Run-time 1.16.0 defect Andreas Heuermann new 2020-12-24T12:35:38Z 2021-09-13T11:58:21Z "When computing numerical computation for data Reconciliation, the dgesv solver fails to compute Ax=b in windows, where as for the same problem the solution is successfully computed in linux. An example to reproduce the problem is available in the testsuite in the following location {{{ testsuite/openmodelica/dataReconciliation/TSP_FourFlows11.mos testsuite/openmodelica/dataReconciliation/TSP_FourFlows10.mos }}} use the old FrontEnd to run the tests {{{ omc -d=-newInst TSPFourFlows11.mos }}} I am attaching the numerical computation log for TSP_FourFlows11.mos ran from linux and windows, look for the heading in the log file {{{ Calculations of Matrix (F*Sx*Ft) f* = c(x,y) ============================================ }}} From the log file we can see that the calculation made for (F*Sx*Ft) and c(x,y) is the same for both in windows and linux, but when computing f*, '''dgesv''' cannot compute the solution in windows. " arunkumar palanisamy 6325 Support for ExternData New Instantiation 1.16.0 defect Per Östlund assigned 2021-01-04T12:48:14Z 2021-09-13T11:58:21Z "When trying to test/verify an example from https://github.com/modelica/ModelicaSpecification/issues/2425#issuecomment-751835905 I got the following error messaged in OMEdit (Connected to OpenModelica 1.17.0~dev-305-gb74c531): {{{ [2] 13:43:27 Translation Error [/var/lib/jenkins/ws/LINUX_BUILDS/tmp.build/openmodelica-1.17.0~dev-305-gb74c531/OMCompiler/Compiler/NFFrontEnd/NFEvalFunction.mo: 181:7-183:92]: Internal error NFEvalFunction.evaluateExternal failed on ExternData.Types.ExternXMLFile.constructor, evaluation of userdefined external functions not yet implemented }}} Which I'm not sure what it is trying to tell me. So not sure if this is an issue of OMC or the library. I've attached both my test model and the xml file once more here. " Dietmar Winkler 6326 OMEdit changes to dark mode if Fedora changes to dark mode OMEdit 1.16.2 defect Adeel Asghar new 2021-01-04T22:52:58Z 2021-09-13T11:58:21Z "When I change the Gnome theme in Fedora to dark theme, OMEdit becomes black and unusable. When I change Gnome back to a light theme, it gets OK again. [[Image()]] The same effect is not seen in Ubuntu however. I use Fedora 33 (Xorg)" pwithu@… 6327 OMEdit crashes when unloading a library OMEdit v1.17.0-dev defect Adeel Asghar new 2021-01-04T23:53:17Z 2021-09-13T11:58:21Z "I am developing a test library, that I need to unload and reload often. Occasionally, OMEdit crashes when unloading it, after having added stuff to it. I'm using the latest nightly build v1.17.0-dev-313-g0591e00b90 on Windows 10 64-bit. I sent a couple of crash reports, the last was sent on 05-01-2020 00:49" Francesco Casella 6332 Cannot run a SSP model with 2 looped FMUs OMSimulator 1.16.0 defect Lennart Ochel new 2021-01-07T14:36:11Z 2021-09-13T11:58:21Z "I try to solve a system of 2 equations / 2 unknowns, each equation being in one different FMU. The FMUs are build from Dymola (with FMI for CS 2.0). The system is named equationsPair. I can build the SSP model but the run fails at the init stage whatever the solver used (ma, mav, mav-2): [2] 15:31:04 Ecriture Erreur [solveAlgLoop] max. number of iterations (10) exceeded at time = 0.000000 [3] 15:31:04 Ecriture Erreur [initialize] Initialization of system ""equationsPair.ep"" failed Is it normal according to current implemented features?" jean-philippe.tavella@… 6333 Cannot define only once a FMU that is instantiated twice in a SSP model OMSimulator 1.16.0 defect Lennart Ochel new 2021-01-07T14:53:51Z 2021-09-13T11:58:21Z "I'm not able to instantiate only once a FMU that is to be logically used/instantiated twice in a SSP model. I don't know if the limitation is due to: - SSP specification level - OMSimulator limitation - a lack of knowledge of the subject on my side Note: the FMU has flag canBeInstantiatedOnlyOncePerProcess=false." jean-philippe.tavella@… 6334 Cannot handle medium/large size FMUs with OMSimulator OMSimulator 1.16.0 defect Lennart Ochel new 2021-01-08T09:00:34Z 2021-09-13T11:58:21Z "I try to use medium/large size FMUs in SSP models and simply to load these FMUs in the Editor (OMEdit) it is very time consuming. What kind of operations are done there? Second, after a successfull FMU loading, each time I simply click on the editor sheet or resize the FMU, again a long time is taken before giving the hand to the user. Should be reduced to zero-time consuming, shouldn't? My FMUs are exported from Dymola (with license-free for use). I can give you some if needed. In comparison, DNG(https://bitbucket.org/simulage/daccosim/wiki/Home) can load and graphically manage these FMUs almost instantaneously." jean-philippe.tavella@… 6336 Error when loading a simple Dymola FMU in an SSP model OMSimulator v1.17.0-dev defect Lennart Ochel accepted 2021-01-08T10:32:25Z 2021-09-13T11:58:21Z "I try to load a very light and simple Dymola FMU in an SSP model and I get these errors: [4] 11:19:43 Ecriture Erreur [loadSnapshot] loading snapshot failed [5] 11:21:35 Ecriture Erreur [initializeDependencyGraph_initialUnknowns] tankwin3264: erroneous dependencies detected in modelDescription.xml [6] 11:21:35 Ecriture Erreur [NewComponent] tankwin3264: Couldn't initialize dependency graph for initial unknowns. [7] 11:21:35 Ecriture Erreur [loadSnapshot] loading snapshot failed When doing this a second time, a new error comes like this: [8] 11:26:19 Ecriture Erreur [addSubModel] ""tankYPipeDym.Root.tankwin3264"" already exists in the scope Then I save the .ssp file and reopen it with an external browser. The FMU appears. There should not be dependencies troubles in Dymola FMUs. The FMU is attached to this ticket." jean-philippe.tavella@… 6339 Chemical library models fail because of too many event iterations or chattering Third-Party Libraries 1.16.0 defect Francesco Casella new 2021-01-12T19:53:47Z 2021-09-13T11:58:21Z "Some models in the Chemical library fail during initialization because of too many events, e.g. [https://libraries.openmodelica.org/branches/master/Chemical/files/Chemical_Chemical.Examples.Hemoglobin.HemoglobinTitration.sim HemoglobinTitration], while others fail because of chattering during simulation, e.g. [https://libraries.openmodelica.org/branches/master/Chemical/files/Chemical_Chemical.Examples.Hemoglobin.Joels57.sim Joels57]. @marek, do you have any clue why this could happen?" Francesco Casella 6343 Issue with simulation flags in the testing infrastructure Testing Framework 1.16.0 defect Martin Sjölund new 2021-01-18T01:13:57Z 2021-09-13T11:58:21Z "Please check [https://libraries.openmodelica.org/branches/master/PowerGrids/files/PowerGrids_PowerGrids.Examples.ENTSOE.SteadyState.sim PowerGrids.Examples.ENTSOE.SteadyState]. The simulation executable reports: {{{ Regular simulation: ./PowerGrids_PowerGrids.Examples.ENTSOE.SteadyState -abortSlowSimulation -alarm=480 -nls=kinsol -lv=LOG_INIT_HOMOTOPY -lv LOG_STATS stdout | warning | each command line option can only be used once: -lv }}} and then does not report the simulation stats. The first {{{-lv}}} flag is generated by the {{{__OpenModelica_simulationFlags}}} annotation, I guess the second is added by the CI scripts. In this case, the script should recognize that there is already a {{{-lv}}} flag and append {{{LOG_STATS}}} to it. All the example models in {{{PowerGrids}}} suffer of the same problem." Francesco Casella 6346 Enable analytic jacobians for daeMode Backend 1.16.0 defect Karim Adbdelhak assigned 2021-01-18T18:59:58Z 2022-01-24T17:37:04Z "By running this simple model {{{ model M Real x(start = 1, fixed = true),y; equation der(x) = -y; y + 0.1*sin(y) = x; annotation(__OpenModelica_commandLineOptions=""--daeMode --generateSymbolicJacobian"", __OpenModelica_simulationFlags(jacobian=""coloredSymbolical"",lv=""LOG_STATS"")); end M; }}} I understand that analytic jacobians are not generated in DAE mode, since there is no trace of their computation in the C code and in the declarative debugger. This is not very clear from the documentation of the {{{--generateSymbolicJacobian}}} [https://openmodelica.org/doc/OpenModelicaUsersGuide/latest/omchelptext.html#omcflag-generatesymbolicjacobian compiler flag documentation] , which makes no explicit reference to either {{{odeMode}}} nor {{{daeMode}}}, but is clear from the description of [https://openmodelica.org/doc/OpenModelicaUsersGuide/latest/omchelptext.html#omcflag-postoptmodules postOptModules], which states symbolicJacobian (Detects the sparse pattern ''of the ODE system'' and calculates also the symbolic Jacobian if flag '--generateSymbolicJacobian' is enabled.) In fact, [https://github.com/OpenModelica/OpenModelica/blob/c8233fa62ad0c3e01be24d6e4f97134c02204a10/OMCompiler/SimulationRuntime/c/simulation/solver/ida_solver.c#L345 this line of code] should print out an appropriate error message when I try to turn on analytic jacobians in DAE mode, as in the above message. Unfortunately, if I do it in OMEdit, the simulation output is not passed to the simulation output window, so I can't see that (why?). For the sake of high-speed power grid simulation, computing the jacobian of the DAE in daeMode would be very useful, since most of its nonzero coefficients are parameters and could be computed only once at initialization." Francesco Casella 6349 Failed to insert class Test_VSC within HVDCcomponents.Examples OMPython 1.16.0 defect arunkumar palanisamy new 2021-01-22T10:33:26Z 2021-09-13T11:58:21Z "Hello, I am having some trouble to open one simple class called ""Test_VSC"" because of a custom library and I am getting the following error: {{{ 2021-01-22 11:14:05,834 - OMPython - INFO - OMC Server is up and running at file:///C:/Users/J5046~1.ALV/AppData/Local/Temp/openmodelica.port.beb0bed9c01a4c248f8137b3d2e1b308 pid=12472 2021-01-22 11:14:06,147 - OMPython - INFO - OMC Server is up and running at file:///C:/Users/J5046~1.ALV/AppData/Local/Temp/openmodelica.port.5765d22327464c56b1d8d5829c7e24e9 pid=3676 loadFile Error: Error: Failed to insert class Test_VSC within HVDCcomponents.Examples; the available classes were: Error: Failed to load package 'HVDCcomponents.Examples.Test_VSC' (default) using MODELICAPATH C:/OpenModelica/lib/omlibrary. Error: Class 'HVDCcomponents.Examples.Test_VSC' not found in scope . }}} The code is: {{{ from OMPython import OMCSessionZMQ from OMPython import ModelicaSystem path = 'C:/OpenModelica/lib/omlibrary/HVDCcomponents/Examples' within = 'HVDCcomponents.Examples' name = 'Test_VSC' file ='""'+ path + '/' + name + '.mo'+'""' mod_file = path + '/' + name + '.mo' load_file = ""loadFile("" + file + "")"" within_name = ""'"" + within + '.' + name + ""'"" # To create the modelica session and execute action omc = OMCSessionZMQ() # To set variables, and change the model mod = ModelicaSystem(mod_file,within_name, [""C:/OpenModelica/lib/omlibrary/HVDCComponents/package.mo"",""C:/OpenModelica/lib/omlibrary/OpenIPSL/package.mo"",""Modelica""]) mod.buildModel() # Loading the model file Load = omc.sendExpression(load_file) if (not Load): raise NameError(""Coudn't load file"") }}} Before I've tried several ways to call the function ""ModelicaSystem"", being them: mod = ModelicaSystem(mod_file,within_name) mod = ModelicaSystem(file,within_name) mod = ModelicaSystem(mod_file,name) mod = ModelicaSystem(mod_file,within_name,[""HVDCComponents"",""OpenIPSL"",""Modelica""]) mod = ModelicaSystem(file,within_name,[""HVDCComponents"",""OpenIPSL"",""Modelica""]) mod = ModelicaSystem(mod_file,name,[""HVDCComponents"",""OpenIPSL"",""Modelica""]) And all of them have errors, sometimes: {{{ loadFile Error: Error: Failed to insert class Test_VSC within HVDCcomponents.Examples; }}} {{{ Error: Failed to load package HVDCcomponents (default) using MODELICAPATH C:/OpenModelica/lib/omlibrary. Error: Class HVDCcomponents.Examples.Test_VSC not found in scope . }}} The code in OpenModelica for Test_VSC is the following: {{{ within HVDCcomponents.Examples; model Test_VSC OpenIPSL.Electrical.Buses.Bus bus1(S_b = 1000, V_b = 230, displayPF = true, fn = 50) annotation( Placement(visible = true, transformation(origin = {116, 2}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); OpenIPSL.Electrical.Buses.InfiniteBus infiniteBus1(S_b = 1000, V_b = 230, fn = 50) annotation( Placement(visible = true, transformation(origin = {108, -34}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); HVDCcomponents.PQ_sensor pQ_sensor1(S_b = 1000) annotation( Placement(visible = true, transformation(origin = {84.4, 2}, extent = {{-6, -5}, {6, 5}}, rotation = 0))); Modelica.Electrical.Analog.Basic.Ground ground1 annotation( Placement(visible = true, transformation(origin = {-55, -27}, extent = {{-7, -7}, {7, 7}}, rotation = 0))); HVDCcomponents.PQ_sensor pQ_sensor2(S_b = 1000) annotation( Placement(visible = true, transformation(origin = {-231.6, 0}, extent = {{6, -5}, {-6, 5}}, rotation = 0))); OpenIPSL.Electrical.Buses.Bus bus2(S_b = 1000, V_b = 230, displayPF = true, fn = 50) annotation( Placement(visible = true, transformation(origin = {-264, 0}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); OpenIPSL.Electrical.Buses.InfiniteBus infiniteBus2(S_b = 1000, V_b = 230, fn = 50) annotation( Placement(visible = true, transformation(origin = {-272, -36}, extent = {{10, -10}, {-10, 10}}, rotation = 0))); Modelica.Blocks.Sources.Step step5(height = 10, startTime = 10) annotation( Placement(visible = true, transformation(origin = {-172, 50}, extent = {{4, -4}, {-4, 4}}, rotation = 0))); Modelica.Blocks.Sources.Step step4(height = 0, offset = 0, startTime = 2) annotation( Placement(visible = true, transformation(origin = {42, 34}, extent = {{4, -4}, {-4, 4}}, rotation = 0))); Modelica.Blocks.Sources.Step step1(height = 0, startTime = 0) annotation( Placement(visible = true, transformation(origin = {30, 66}, extent = {{4, -4}, {-4, 4}}, rotation = 0))); HVDCcomponents.VSC_station_final vSC_station_final(MVAb = 1000, P_ref = 0, Q_ref = 0, S_b = 1000, Vb = 230, Vdcb = 640, Vgd = 230) annotation( Placement(visible = true, transformation(origin = {-194, 2}, extent = {{10, -10}, {-10, 10}}, rotation = 0))); HVDCcomponents.DC_cable_PI_section dC_cable_PI_section(Vinit = 640E3, length = 100) annotation( Placement(visible = true, transformation(origin = {-90, 2}, extent = {{-15, -5}, {15, 5}}, rotation = 0))); Modelica.Blocks.Sources.Step step(height = 10, offset = 0, startTime = 5) annotation( Placement(visible = true, transformation(origin = {-152, 26}, extent = {{4, -4}, {-4, 4}}, rotation = 0))); HVDCcomponents.VSC_station_final vSC_station_final1(MVAb = 1000, P_ref = 0, Q_ref = 0, S_b = 1000, Vb = 230, Vdc_Control_Type = ""PI+filter"", Vdcb = 640, Vgd = 230) annotation( Placement(visible = true, transformation(origin = {0, 8}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Electrical.Analog.Sensors.CurrentSensor Sensor annotation( Placement(visible = true, transformation(origin = {-52, 42}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); equation connect(pQ_sensor1.n, bus1.p) annotation( Line(points = {{90, 2}, {116.4, 2}}, color = {0, 0, 255})); connect(bus1.p, infiniteBus1.p) annotation( Line(points = {{116, 2}, {132, 2}, {132, -34}, {125, -34}, {125, -34}, {123.5, -34}, {123.5, -34}, {118, -34}}, color = {0, 0, 255})); connect(bus2.p, infiniteBus2.p) annotation( Line(points = {{-264, 0}, {-290, 0}, {-290, -36}, {-282, -36}, {-282, -36}}, color = {0, 0, 255})); connect(pQ_sensor2.n, bus2.p) annotation( Line(points = {{-238, 0}, {-264, 0}, {-264, 0}, {-264, 0}}, color = {0, 0, 255})); connect(pQ_sensor2.p, vSC_station_final.p) annotation( Line(points = {{-226, 0}, {-216, 0}, {-216, 2}, {-205, 2}}, color = {0, 0, 255})); connect(dC_cable_PI_section.pin_p, vSC_station_final.pin_p) annotation( Line(points = {{-105, 5}, {-144, 5}, {-144, 7}, {-183, 7}}, color = {0, 0, 255})); connect(vSC_station_final.pin_n, dC_cable_PI_section.pin_n) annotation( Line(points = {{-183, -3}, {-104, -3}, {-104, -1}, {-105, -1}}, color = {0, 0, 255})); connect(ground1.p, dC_cable_PI_section.pin_n1) annotation( Line(points = {{-54, -20}, {-54, -1}, {-75, -1}}, color = {0, 0, 255})); connect(vSC_station_final1.p, pQ_sensor1.p) annotation( Line(points = {{12, 8}, {70, 8}, {70, 2}, {78, 2}, {78, 2}}, color = {0, 0, 255})); connect(vSC_station_final1.pin_n, dC_cable_PI_section.pin_n1) annotation( Line(points = {{-10, 2}, {-54, 2}, {-54, 0}, {-75, 0}, {-75, -1}}, color = {0, 0, 255})); connect(step5.y, vSC_station_final.Qref) annotation( Line(points = {{-176, 50}, {-198, 50}, {-198, 14}, {-198, 14}}, color = {0, 0, 127})); connect(step.y, vSC_station_final.Pref) annotation( Line(points = {{-156, 26}, {-190, 26}, {-190, 14}, {-190, 14}}, color = {0, 0, 127})); connect(vSC_station_final1.Pref, step1.y) annotation( Line(points = {{-4, 20}, {-8, 20}, {-8, 66}, {26, 66}}, color = {0, 0, 127})); connect(step4.y, vSC_station_final1.Qref) annotation( Line(points = {{38, 34}, {4, 34}, {4, 20}, {4, 20}}, color = {0, 0, 127})); connect(Sensor.p, dC_cable_PI_section.pin_p1) annotation( Line(points = {{-62, 42}, {-74, 42}, {-74, 6}, {-74, 6}}, color = {0, 0, 255})); connect(Sensor.n, vSC_station_final1.pin_p) annotation( Line(points = {{-42, 42}, {-22, 42}, {-22, 12}, {-10, 12}, {-10, 14}}, color = {0, 0, 255})); annotation( Diagram(graphics = {Line(origin = {0, 8}, points = {{0, 0}})}, coordinateSystem(extent = {{-300, -100}, {150, 100}}, initialScale = 0.1)), Icon(coordinateSystem(extent = {{-300, -100}, {150, 100}})), __OpenModelica_commandLineOptions = """", experiment( StopTime=20, Interval=0.002, Tolerance=1e-006, __OpenModelica_Algorithm=""dassl"")); end Test_VSC; }}} " jeduapf@… 6352 Function returning record with array fails Code Generation v1.17.0-dev defect Mahder Alemseged Gebremedhin accepted 2021-01-26T15:57:07Z 2021-09-13T11:58:21Z "Please consider this test model (also attached) {{{ #!mo model TestFunctionRecordArray constant Integer c = 3; record R Real v; Real x[c]; end R; function f input Real v; output R rout; algorithm rout.v := v; rout.x := {0.3, 0.4, 0.3}; end f; Real x; R r; equation x = time; r = f(x); end TestFunctionRecordArray; }}} The model fails during compilation with {{{ TestFunctionRecordArray_functions.c:33:3: error: use of undeclared identifier '_rout' _rout._x = _OMC_LIT0; ^ }}}" Francesco Casella 6360 Base model parameters disappear from GUI when edit Extended model OMEdit defect Adeel Asghar new 2021-02-01T09:45:56Z 2021-09-13T11:58:21Z "Consider to work on a model, called ""Container"" using diagram view in OMEdit. This model contains a model ""ExtendedModel"" that extends a ""BaseModel"". If I modify the extended model and save, when I go back to the container model the parameters contained in the base class are no more visible in the parameters window. They appear again only unloading and reloading again the package. Procedure: 1) load the attached test.mo package 2) open ""Container"" and check that both ""a"" and ""b"" input fields are present 3) open ""ExtendedModel"" and change the equation ""c = a+b"" into ""c = a*b"" 4) go back to ""Container"" and open the parameter window for extendedModel 5) ""a"" input field does not appear anymore About OMEdit: Connected to OpenModelica v1.18.0-dev-5-g263a0e58e8 (64-bit) Connected to OMSimulator v2.0.0.post284-gc8ec782-mingw " Simone Bosotti 6361 Compilation in path with special character failing (Windows + OMEdit) Run-time v1.17.0-dev defect Adrian Pop assigned 2021-02-01T13:49:24Z 2021-09-13T11:58:21Z "When compiling a model {{{ model helloWorld Real x(start=1); equation der(x) = 10*x; end helloWorld; }}} on Windows, saved in a path with a special character, e.g. `D:\workspace\Testitesttest\pathWithö`, the compilation from OMEdit will fail: {{{ C:/Program Files/OpenModelica1.18.0-dev-64bit/share/omc/scripts/Compile.bat helloWorld gcc mingw64 parallel 16 0 PATH = ""C:\PROGRA~1\OPENMO~2.0-D\tools\msys\mingw64\bin;C:\PROGRA~1\OPENMO~2.0-D\tools\msys\mingw64\bin\..\..\usr\bin;"" mingw32-make: Entering directory 'C:/OMDev/tools/msys/tmp/OPENMO~1/OMEdit/HELLOW~1' clang -Os -falign-functions -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.18.0-dev-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=helloWorld -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o helloWorld.o helloWorld.c clang -Os -falign-functions -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.18.0-dev-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=helloWorld -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o helloWorld_functions.o helloWorld_functions.c clang -Os -falign-functions -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.18.0-dev-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=helloWorld -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o helloWorld_records.o helloWorld_records.c clang -Os -falign-functions -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.18.0-dev-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=helloWorld -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o helloWorld_01exo.o helloWorld_01exo.c clang -Os -falign-functions -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.18.0-dev-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=helloWorld -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o helloWorld_02nls.o helloWorld_02nls.c clang -Os -falign-functions -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.18.0-dev-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=helloWorld -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o helloWorld_03lsy.o helloWorld_03lsy.c clang -Os -falign-functions -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.18.0-dev-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=helloWorld -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o helloWorld_04set.o helloWorld_04set.c clang -Os -falign-functions -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.18.0-dev-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=helloWorld -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o helloWorld_05evt.o helloWorld_05evt.c clang -Os -falign-functions -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.18.0-dev-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=helloWorld -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o helloWorld_06inz.o helloWorld_06inz.c clang -Os -falign-functions -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.18.0-dev-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=helloWorld -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o helloWorld_07dly.o helloWorld_07dly.c clang -Os -falign-functions -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.18.0-dev-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=helloWorld -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o helloWorld_08bnd.o helloWorld_08bnd.c clang -Os -falign-functions -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.18.0-dev-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=helloWorld -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o helloWorld_09alg.o helloWorld_09alg.c clang -Os -falign-functions -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.18.0-dev-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=helloWorld -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o helloWorld_10asr.o helloWorld_10asr.c clang -Os -falign-functions -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.18.0-dev-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=helloWorld -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o helloWorld_11mix.o helloWorld_11mix.c clang -Os -falign-functions -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.18.0-dev-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=helloWorld -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o helloWorld_12jac.o helloWorld_12jac.c clang -Os -falign-functions -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.18.0-dev-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=helloWorld -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o helloWorld_13opt.o helloWorld_13opt.c clang -Os -falign-functions -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.18.0-dev-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=helloWorld -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o helloWorld_14lnz.o helloWorld_14lnz.c clang -Os -falign-functions -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.18.0-dev-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=helloWorld -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o helloWorld_15syn.o helloWorld_15syn.c clang -Os -falign-functions -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.18.0-dev-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=helloWorld -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o helloWorld_16dae.o helloWorld_16dae.c clang -Os -falign-functions -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.18.0-dev-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=helloWorld -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o helloWorld_17inl.o helloWorld_17inl.c clang -I. -o helloWorld.exe helloWorld.o helloWorld_functions.o helloWorld_records.o helloWorld_01exo.o helloWorld_02nls.o helloWorld_03lsy.o helloWorld_04set.o helloWorld_05evt.o helloWorld_06inz.o helloWorld_07dly.o helloWorld_08bnd.o helloWorld_09alg.o helloWorld_10asr.o helloWorld_11mix.o helloWorld_12jac.o helloWorld_13opt.o helloWorld_14lnz.o helloWorld_15syn.o helloWorld_16dae.o helloWorld_17inl.o -I""C:/Program Files/OpenModelica1.18.0-dev-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=helloWorld -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -L""D:/workspace/Testitesttest/pathWithö"" -Os -falign-functions -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.18.0-dev-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=helloWorld -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -L""C:/Program Files/OpenModelica1.18.0-dev-64bit/lib//omc"" -L""C:/Program Files/OpenModelica1.18.0-dev-64bit/lib"" -Wl,--stack,16777216,-rpath,""C:/Program Files/OpenModelica1.18.0-dev-64bit/lib//omc"" -Wl,-rpath,""C:/Program Files/OpenModelica1.18.0-dev-64bit/lib"" -fopenmp -Wl,-Bstatic -lregex -ltre -lintl -liconv -lexpat -lomcgc -lpthread -loleaut32 -limagehlp -lhdf5 -lz -lszip -Wl,-Bdynamic -Wl,-Bstatic -lSimulationRuntimeC -Wl,-Bdynamic -Wl,-Bstatic -lomcgc -lregex -ltre -lintl -liconv -lexpat -static-libgcc -luuid -loleaut32 -lole32 -limagehlp -lws2_32 -llis -lsundials_nvecserial -lsundials_sunmatrixdense -lsundials_sunmatrixsparse -lsundials_sunlinsoldense -lsundials_sunlinsolklu -lsundials_sunlinsollapackdense -lsundials_sunlinsolspbcgs -lsundials_sunlinsolspfgmr -lsundials_sunlinsolspgmr -lsundials_sunlinsolsptfqmr -lsundials_sunnonlinsolnewton -lsundials_cvode -lsundials_cvodes -lsundials_idas -lsundials_kinsol -lumfpack -lklu -lcolamd -lbtf -lamd -lipopt -lcoinmumps -lpthread -lm -lgfortran -lquadmath -lmingw32 -lgcc_eh -lmoldname -lmingwex -luser32 -lkernel32 -ladvapi32 -lshell32 -lopenblas -lcminpack -Wl,-Bdynamic -lwsock32 -lstdc++ /usr/bin/sh: clang -I. -o helloWorld.exe helloWorld.o helloWorld_functions.o helloWorld_records.o helloWorld_01exo.o helloWorld_02nls.o helloWorld_03lsy.o helloWorld_04set.o helloWorld_05evt.o helloWorld_06inz.o helloWorld_07dly.o helloWorld_08bnd.o helloWorld_09alg.o helloWorld_10asr.o helloWorld_11mix.o helloWorld_12jac.o helloWorld_13opt.o helloWorld_14lnz.o helloWorld_15syn.o helloWorld_16dae.o helloWorld_17inl.o -I""C:/Program Files/OpenModelica1.18.0-dev-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=helloWorld -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -L""D:/workspace/Testitesttest/pathWithö"" -Os -falign-functions -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.18.0-dev-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=helloWorld -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -L""C:/Program Files/OpenModelica1.18.0-dev-64bit/lib//omc"" -L""C:/Program Files/OpenModelica1.18.0-dev-64bit/lib"" -Wl,--stack,16777216,-rpath,""C:/Program Files/OpenModelica1.18.0-dev-64bit/lib//omc"" -Wl,-rpath,""C:/Program Files/OpenModelica1.18.0-dev-64bit/lib"" -fopenmp -Wl,-Bstatic -lregex -ltre -lintl -liconv -lexpat -lomcgc -lpthread -loleaut32 -limagehlp -lhdf5 -lz -lszip -Wl,-Bdynamic -Wl,-Bstatic -lSimulationRuntimeC -Wl,-Bdynamic -Wl,-Bstatic -lomcgc -lregex -ltre -lintl -liconv -lexpat -static-libgcc -luuid -loleaut32 -lole32 -limagehlp -lws2_32 -llis -lsundials_nvecserial -lsundials_sunmatrixdense -lsundials_sunmatrixsparse -lsundials_sunlinsoldense -lsundials_sunlinsolklu -lsundials_sunlinsollapackdense -lsundials_sunlinsolspbcgs -lsundials_sunlinsolspfgmr -lsundials_sunlinsolspgmr -lsundials_sunlinsolsptfqmr -lsundials_sunnonlinsolnewton -lsundials_cvode -lsundials_cvodes -lsundials_idas -lsundials_kinsol -lumfpack -lklu -lcolamd -lbtf -lamd -lipopt -lcoinmumps -lpthread -lm -lgfortran -lquadmath -lmingw32 -lgcc_eh -lmoldname -lmingwex -luser32 -lkernel32 -ladvapi32 -lshell32 -lopenblas -lcminpack -Wl,-Bdynamic -lwsock32 -lstdc++ : No such file or directory mingw32-make: *** [helloWorld.makefile:32: omc_main_target] Error 127 mingw32-make: Leaving directory 'C:/OMDev/tools/msys/tmp/OPENMO~1/OMEdit/HELLOW~1' Compilation process failed. Exited with code 2. }}} I guess the problem is `-L""D:/workspace/Testitesttest/pathWithö""`, but running the makefile from mingw shell works fine. I can't reproduce the problem without running it from OMEdit." Andreas Heuermann 6371 Modelica_Synchronus FMUs not working FMI v1.17.0-dev defect Andreas Heuermann assigned 2021-02-09T10:51:01Z 2021-09-13T11:58:21Z "As far as I can tell it is not possible to export a Modelica model, that is using features like clocks from Modelic_Synchronus, as an FMU that can be run by a FMU Import Tool. For example when exporting `Modelica_Synchronous.Examples.Elementary.ClockSignals.SubSample` as a 2.0 FMU and simulating it with OMSimulator the simulation will issue warnings and the results are completely wrong. {{{ setCommandLineOptions(""--std=3.5""); getErrorString(); loadModel(Modelica, {""3.2.3""}); getErrorString(); loadModel(Modelica_Synchronous); getErrorString(); buildModelFMU(Modelica_Synchronous.Examples.Elementary.ClockSignals.SubSample, version=""2.0"", fmuType=""me""); getErrorString(); system(""OMSimulator Modelica_Synchronous.Examples.Elementary.ClockSignals.SubSample.fmu""); getErrorString(); }}} {{{ andreas@DESKTOP-OSJIVA0:~/workspace/Testitesttest/newTicketClocks$ omc runTests.mos true """" true """" true """" ""/home/andreas/workspace/Testitesttest/newTicketClocks/Modelica_Synchronous.Examples.Elementary.ClockSignals.SubSample.fmu"" """" info: Set temp directory to ""/home/andreas/workspace/Testitesttest/newTicketClocks"" info: Set working directory to ""/home/andreas/workspace/Testitesttest/newTicketClocks"" info: Set working directory to ""/home/andreas/workspace/Testitesttest/newTicketClocks"" info: New model ""model"" with corresponding temp directory ""/home/andreas/workspace/Testitesttest/newTicketClocks/model-ew0k961t"" error: [fmiLogger] module FMI2XML: [Line:105] Unknown element 'Clocks' in XML, skipping warning: module FMI2XML: [Line:106] Skipping nested XML element 'Clock' warning: module FMI2XML: [Line:106] Skipping nested XML element 'Inferred' error: [fmiLogger] module FMI2XML: Unknown attribute 'clockIndex=1' in XML info: model doesn't contain any continuous state info: Result file: model_res.mat (bufferSize=10) info: Parameter model.root.fmu.periodicClock.solverMethod will not be stored in the result file, because the signal type is not supported info: 2 warnings info: 2 errors 0 """" }}} The result of `model.sample1.y` should be a clocked version of a sine curve. I have added the modelDescription.xml to this ticket. Or is it just that I exported the FMU wrong and it is possible? The Cpp should be able to use clocks in FMUs, but it didn't change anything for me when adding `simCodeTarget=Cpp`." Andreas Heuermann 6372 Asserts in conditional equations are not handled correctly Run-time 1.18.0-dev defect Andreas Heuermann new 2021-02-09T15:39:13Z 2021-09-13T11:58:21Z "Please consider the following MWE {{{ model M3 Real x; equation if time > 0.5 then x = time; assert(x > 0, ""error""); else x = 0; end if; end M3; }}} At time = 0.501 the runtime fails with {{{ The following assertion has been violated at time 0.502000 if time > 0.5 then x > 0.0 else true }}} Obviously there is something wrong with the way asserts are handled, apparently they still use some ""old value"". " Francesco Casella 6378 ThermalSeparation not working Third-Party Libraries 1.16.2 defect Francesco Casella assigned 2021-02-15T19:45:21Z 2021-09-13T11:58:21Z "The commits at https://github.com/thom-marx/ThermalSeparation indicate some contributions by OpenModelica developers. However, all examples are rejected by OpenModelica with a message of the kind: [ThermalSeparation.Media.WaterBasedLiquid.BaseClasses: 25:3-32:30]: PartialMedium is partial, name lookup is not allowed in partial classes. Can this be fixed?" Rüdiger Franke 6381 Dump the settings of OMEdit in the OMEdit logs OMEdit 1.16.2 defect Adeel Asghar new 2021-02-16T19:21:59Z 2021-09-13T11:58:21Z "For debugging purposes, it can be really important to know what are the OMEdit settings, as #6307 clearly demonstrates. @adeas31, can you dump all the settings in some of the log files that are shipped with the crash reports?" Francesco Casella 6385 Overdetermined system OMEdit 1.16.2 defect Shravya Hebbur Murali assigned 2021-02-18T16:39:21Z 2021-09-13T11:58:21Z "Does anyone have a system for how they determine where the errors are in their overdetermined model? I find that the errors from the simulation do not directly lead me to the error package SplitM_1 connector Inlet flow Real Q[17] (each quantity=""volumetric flowrate"", each unit=""L/h"") ""Flowrate""; input Real c[17] (each quantity=""concentration"",each unit=""mg/L""); Real P[17] (each quantity = ""pressure"", each unit = ""Pa"") ""Potential variable""; end Inlet; connector Outlet flow Real Q[17] (each quantity=""volumetric flowrate"", each unit=""L/h"") ""Flowrate""; output Real c[17] (each quantity=""concentration"",each unit=""mg/L""); Real P[17] (each quantity = ""pressure"", each unit = ""Pa"") ""Potential variable""; end Outlet; record membrane_properties parameter Real n = 7 ""Number of capillaries per fiber""; parameter Real m = 15 ""Number of Membrane Fibers""; parameter Modelica.SIunits.Length d_cap = 0.0009 ""Capillary diameter""; parameter Modelica.SIunits.Length l_m = 1.5 ""Capillary membrane length""; end membrane_properties; record set_flow_parameters parameter Modelica.SIunits.Velocity u_cf[17] ={0.25, 0.5, 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5, 5.5, 6, 6.5, 7, 7.5, 8}; //Crossflow velocity at the membrane inlet parameter Real J_p_overall = 35; //in m^3/sm^2 Average permeate flux as the permeate leaves the membrane 35 L/hm^2 parameter Real Y = 0.45; //Water conversion factor (Q_p/Q_raw) parameter Real k_w = 10.67; //water permeability through the membrane in L/hm^2 //parameter Real P_feed = 2.75; // used to calculate potential presure terms end set_flow_parameters; record Conc_pol_parameters //output Real Re[17]; //Reynoldsnumber Real Sc[17]; //Schmidtnumber Real Sh[17]; //Sherwoodnumber Real CP[17]; //concentration polarization Real delta[17]; //d_h/Sh Real k[17]; //D_i.Sh/d_h""; //input constant Real D_i = 1.07 * 10 ^ (-9) ""Diffusion coefficient / m²/s""; end Conc_pol_parameters; record osmopressure_solute constant Real R_gasconstant = Modelica.Constants.R; parameter Real alpha = 1 ""disscociation constant between 0 and 1""; parameter Real T = 293 ""temperature /K""; //why error parameter Real v = 2 ""stoichiometric coefficient""; //c_f is the only variation from one membrane module to the next Real P_osmotic[17]; Real B; end osmopressure_solute; class calculated_flows constant Real pi = 3.141592; Real d_h ""hydraulic diameter""; extends membrane_properties; extends set_flow_parameters; output Real A_cf ""Crosssectional flow area / m²""; output Real A_act ""Active Membrane area / m²""; equation d_h = d_cap * m * n; A_cf = pi * (d_cap / 2) ^ 2 * n * m; A_act = pi * d_h * l_m; end calculated_flows; model Raw_water //Inlet In_MO; Outlet Out_F; extends calculated_flows; //Permeate Perm; parameter Real c_raw_init = 248 ""Concentration of contaminant / mg/L""; Real Q_raw_f[17] ""raw water flowrate set / L/h ""; Real c_raw[17]; //Real Q_p; Real V[17]""Volume of water in the raw water tank varying with progression of the filtration process with time""; Real V_initial = 500 * 10 ^ 3 ""Volume of water present in the tank""; initial equation for i in 1:17 loop c_raw[i] = c_raw_init; V[i] = V_initial; Q_raw_f[i] = J_p_overall * A_act / Y; end for; equation for i in 1:17 loop //initial equation //c_raw[i] = c_raw_init; //V[i] = V_initial; //equation Out_F.c[i] = c_raw[i]; Out_F.Q[i] = - Q_raw_f[i]; der(V[i]) = - Q_raw_f[i]; der(c_raw[i] * V[i]) = Out_F.Q[i] * Out_F.c[i]; //der(V) = In_MO.Q + Out_F.Q ; //der(c_raw * V) = In_MO.Q * In_MO.c ; //In_MO.P = 1; Out_F.P[i] = 1; end for; end Raw_water; model Feed Inlet In_raw, In_cyc; Outlet Out; extends calculated_flows; //feed flowrate calculated based on fixed feed velocity //Real P_head; Real Q_f[17]; Real P_f[17]; //just display Real P_rec[17]; //just display Real P_increase_f[17]; Real P_increase_rec[17]; Real P_feed[17]; equation for i in 1:17 loop Q_f[i] = u_cf[i] * A_cf * 3600 * 1000; In_raw.c[i] * In_raw.Q[i] + In_cyc.c[i] * In_cyc.Q[i] + Out.c[i] * Out.Q[i] = 0; Out.Q[i] = -abs(Q_f[i]); In_cyc.Q[i] + Out.Q[i] + In_raw.Q[i] = 0; In_raw.P[i] = P_f[i]; In_cyc.P[i] = P_rec[i]; P_increase_f[i] = P_feed[i] - P_f[i]; P_increase_rec[i] = P_feed[i] - P_rec[i]; Out.P[i] = P_feed[i]; end for; end Feed; model Membrane Inlet In; Outlet Out_P, Out_M; Real sn ""segment number""; Real R_obssn[17] ""rejection considering CP""; Real c_msn[17] ""concentration along the membrane / mg/L""; Real c_fsn[17] ""concentration of feed or bulk / mg/L""; Real tsn[17] ""thickness of boundary layer / m""; Real TMP[17] ""transmembrane pressure /bar""; Real WCF[17] ""water conversion factor""; Real k[17] ""beta, mass transfer coefficient""; //Real P_loss ""Pressure loss""; Real P_loss_HP[17] ""Pressure loss along the membrane length using Hagen-poiseuille equation""; //Real P_loss_sn ""Pressure loss in each segment""; Real e_sn[17] ""energy used in each segment unit""; //Real TMP_test; Real Q_psn[17] ""permeate leaving segment n""; Real J_psn[17] ""permeate flux through segment sn""; Real u_cfsn[17]; //Parameter assumption to test the model- //Pressure varies with velocity and a relationship must be attained experimentally, or J_p(TMP) must be calculated by another method and not Darcy's law //Intrinsic retetntion can be obtained from experimental calculations Real P_in[17]; Real P_out[17]; Real f_D[17]; parameter Real R_int = 0.9; //intrinsic retention of membrane parameter Real rho = 998.2 ""density of water kg/m^3""; parameter Real mu = 1 * 10 ^ (-3) ""dynamic viscosity / Pa.s""; extends calculated_flows; extends Conc_pol_parameters; extends osmopressure_solute; equation for i in 1:17 loop f_D[i] = 64 / Re[i] ""friction factor""; abs(In.c[i]) = c_fsn[i]; //Out_P.c = In.c * (1-R); // permeate from the membrane calculated based on assumed R value u_cfsn[i] = In.Q[i] / (A_cf * 3600 * 1000); P_in[i] = In.P[i]; Out_P.P[i] = 0; //P_loss_sn = f_D * rho * l_m/4 * u_cfsn ^ 2 / (2 * d_cap) * 10^(-5); //P_loss = f_D * rho * l_m * sn/4 * u_cfsn ^ 2 / (2 * d_cap) * 10^(-5); P_loss_HP[i] = 0.25 *l_m * sn/4 * u_cfsn [i]; //P_loss_HP[i] = In.Q[i] * (8 / (m * n)) * mu * l_m * sn / 4 * 10 ^ (-5) / ((d_cap / 2) ^ 4 * pi * 3.6 * 10 ^ 6); // convert from pa to bar - Q from l/h to m3/s, flow is considered to be equally distributed through the m capillaries in the n fibres P_out[i] = P_in[i] - P_loss_HP[i]; TMP[i] = (P_in[i] + P_out[i]) / 2 - Out_P.P[i]; Out_M.P[i] = P_out[i]; //TMP_test = (In.P + Out_M.P)/2; Q_psn[i] = k_w * TMP[i] * (A_act / 4); J_psn[i] = Q_psn[i] / (A_act / 4); Out_P.Q[i] = -abs(Q_psn[i]); In.Q[i] + Out_P.Q[i] + Out_M.Q[i] = 0; WCF[i] = abs(Out_P.Q[i] / In.Q[i]); (CP[i], Re[i], Sc[i], Sh[i], delta[i], k[i]) = Concentration_polarization(d_cap, D_i, l_m * sn / 4, c_fsn[i], u_cfsn[i], J_psn[i], R_int); (B, P_osmotic[i]) = osmotic_pressure(R_gasconstant, alpha, T, c_msn[i], v); c_msn[i] = CP[i] * c_fsn[i]; //Out_P.c = (1 - R_int) * c_fsn; //R_obssn = 1 - Out_P.c / c_msn; Out_P.c[i]=(1-R_int)*c_msn[i]; R_obssn[i]=1-(Out_P.c[i]/c_fsn[i]); tsn[i] = D_i / k[i]; Out_P.c[i] * Out_P.Q[i] + Out_M.c[i] * Out_M.Q[i] + In.c[i] * In.Q[i] = 0; e_sn[i] = P_loss_HP[i] * u_cfsn[i] * A_cf * 3600 * 1000; end for; end Membrane; model Permeate Inlet In_P1, In_P2, In_P3, In_P4; output Real Q_p[17]; output Real c_permeate[17]; extends calculated_flows; equation for i in 1:17 loop Q_p[i] = In_P1.Q[i] + In_P2.Q[i] + In_P3.Q[i] + In_P4.Q[i]; c_permeate[i] = (In_P1.c[i] * In_P1.Q[i] + In_P2.c[i] * In_P2.Q[i] + In_P3.c[i] * In_P3.Q[i] + In_P4.c[i] * In_P4.Q[i]) / Q_p[i]; end for; end Permeate; model Membrane_outlet Inlet In; Outlet Out_cyc, Out_Ret; //Out_RW //parameter Real rec = -1 ""recirculation""; equation for i in 1:17 loop Out_Ret.c[i] = In.c[i]; Out_cyc.c[i] = In.c[i]; //Out_cyc.Q = -abs(rec); Out_cyc.Q[i] + Out_Ret.Q[i] + In.Q[i] = 0; Out_cyc.P[i] = 1; Out_Ret.P[i] = 1; end for; end Membrane_outlet; model Retentate Inlet In_Ret; output Real Q_ret[17]; output Real c_ret[17]; extends calculated_flows; equation for i in 1:17 loop Q_ret[i] = In_Ret.Q[i]; c_ret[i] = In_Ret.c[i]; // In_P1.P + In_P2.P + In_P3.P + In_P4.P = 0; end for; end Retentate; class Run Real WCF_overall[17]; Real Y_overall[17]; Real R_overall[17]; Real P_loss_overall[17]; Real R_raw_overall[17]; Real TMP_overall[17]; extends calculated_flows; Raw_water RW; Feed F; Membrane M1(sn = 1); Membrane M2(sn = 2); Membrane M3(sn = 3); Membrane M4(sn = 4); Permeate Pn; Membrane_outlet MO; Retentate Ret; equation connect(RW.Out_F, F.In_raw); connect(F.Out, M1.In); connect(M1.Out_P, Pn.In_P1); connect(M2.Out_P, Pn.In_P2); connect(M3.Out_P, Pn.In_P3); connect(M4.Out_P, Pn.In_P4); //final permeate stream is made up of the 4 permeate streams connect(M1.Out_M, M2.In); connect(M2.Out_M, M3.In); connect(M3.Out_M, M4.In); connect(M4.Out_M, MO.In); connect(MO.Out_Ret, Ret.In_Ret); connect(MO.Out_cyc, F.In_cyc); for i in 1:17 loop WCF_overall[i] = abs(Pn.Q_p[i] / F.Out.Q[i]); Y_overall[i] = Pn.Q_p[i] / RW.Q_raw_f[i]; R_overall[i] = 1 - Pn.c_permeate[i] / F.Out.c[i]; R_raw_overall[i] = 1 - Pn.c_permeate[i] / RW.c_raw_init; P_loss_overall[i] = M1.P_loss_HP[i] + M2.P_loss_HP[i] + M3.P_loss_HP[i] + M4.P_loss_HP[i]; J_p_overall = (M1.Q_psn[i] + M2.Q_psn[i] + M3.Q_psn[i] + M4.Q_psn[i]) / A_act; TMP_overall[i] = (M1.P_in[i] + M4.P_out[i]) / 2; end for; end Run; function Concentration_polarization input Real d_cap, D_i, l_m, c_f, u_cf, J_p, R_int; output Real CP ""Concentration polarization / c_0/c_f"", Re ""Reynold's number"", Sc ""Schmidt number"", Sh ""Sherwood number"", delta ""thickness of boundary layer laminar flow / m"", k ""Mass transfer coefficient""; protected constant Real e = Modelica.Constants.e; Real mu = 1 * 10 ^ (-3) ""dynamic viscosity / Pa.s""; Real rho = 998.2 ""density of water kg/m^3""; algorithm Re := d_cap * u_cf * rho / mu; Sc := mu / (rho * D_i); if Re < 2300 then Sh := 1.62 * (Re * Sc * d_cap / l_m) ^ (1 / 3); else Sh := 0.04 * Re ^ (3 / 4) * Sc; end if; delta := d_cap / Sh ""thickness of boundary layer laminar flow / m""; k := D_i / delta ""Mass transfer coefficient""; CP := e ^ (J_p / 1000 / 3600 / k) / (R_int + (1 - R_int) * e ^ (J_p / 1000 / 3600 / k)) ""Concentration polarization / c_0/c_f""; end Concentration_polarization; function osmotic_pressure input Real R_gasconstant, alpha, T, c_f, v; //c_f is the only varaiation from one membrane module to the next output Real B, P_osmotic; algorithm B := 1 + alpha * (v - 1); P_osmotic := B * R_gasconstant * 10 ^ (-2) * T * c_f / (1000 * 120.3676); // Use magnesium sulphate in moles end osmotic_pressure; end SplitM_1;" anonymous 6387 Some OMEdit window controls missing with release 1.17 OMEdit v1.17.0-dev defect Adeel Asghar assigned 2021-02-19T07:44:40Z 2021-09-13T11:58:21Z "Se attached pictures done, respectively, with releases 1.16.0-dev-648 and 1.17.0-dev-141. " massimo ceraolo 6388 External Media library for thermodynamic properties Third-Party Libraries 1.16.2 defect Francesco Casella assigned 2021-02-19T07:44:50Z 2021-09-13T11:58:21Z "Hi, Anyone please tell me how to work with external media package to calculate the thermodynamic properties. As I am unable to compile and run in my windows machine." harish.kulambi@… 6389 Impossible to expand the latest release of library PowerSysPro (2.1.2) OMEdit v1.17.0-dev defect Francesco Casella new 2021-02-19T09:09:01Z 2021-09-13T11:58:21Z "I uploaded a new version of library PowerSysPro that perfectly operates with Dymola. The problem is that after opening it with OpenModelica, then I cannot expand the library in the brower, there is a tool crash, not depending I think on the version of OM. Trying to more identify the issue I limited to simply two packages the library to reproduce the issue. This reduced library is enclosed here. The problem is related to redeclarations of functions cos, sin, asin with external builtins. I see two issues in fact here: - expanding the package should be always possible, even when models are not successfully checkable. - why is not it possible to redefine functions as cos, sin, asin (possible with Dymola)?" jean-philippe.tavella@… 6397 Simulations with -lv vendor annotation fail in the testsuite Testing Framework 1.18.0-dev defect Martin Sjölund new 2021-02-27T19:24:17Z 2021-09-13T11:58:21Z "All simulations in [https://libraries.openmodelica.org/branches/master/ScalableTestGrids_noopt/ScalableTestGrids_noopt.html ScalableTestGrids] are failing with this error; {{{ Regular simulation: ./ScalableTestGrids_noopt_ScalableTestGrids.Models.Type1_N_1_M_1 -abortSlowSimulation -alarm=500 -nls=kinsol -lv=LOG_STATS -lv LOG_STATS stdout | warning | each command line option can only be used once: -lv }}} I understand one {{{-lv}}} option comes from the {{{__OpenModelica_simulationFlags(nls=""kinsol"", lv=""LOG_STATS"")}}} in the [https://github.com/PowerGrids/ScalableTestGrids/blob/054638e19aafaf7735770284908e7bc387840ce5/ScalableTestGrids/Models/Type1_N_1_M_1.mo#L54 code], while the other is probably added by Jenkins. " Francesco Casella 6398 OMPlot save to SVG does not properly escape text in Title OMPlot 1.16.2 defect Adeel Asghar new 2021-03-01T12:22:39Z 2021-09-13T11:58:21Z "How to reproduce: - OMEdit 1.16.2 - Create A plot with any signal - Add a Title, e.g. ""foo & bar "" - save to Svg The resulting svg will contain foo & bar <test> which is not a vailid svg file." openmodelica@… 6401 buildFMU with min, max values of variable FMI 1.16.2 defect Lennart Ochel new 2021-03-03T09:04:17Z 2021-09-13T11:58:21Z "I want to build an fmu with openmodelica, when i do that i run the buildModelFMU/translateModelFMU function. The problem is, that additional information of the model-variable are not included. For example: {{{ parameter Real F_min = 0; parameter Real F_max = 1; parameter Real F(min=F_min, max=F_max); }}} If I look into the model_description.xml file the min/max-values are not included for the variable F. Is it possible to do that? I want to load the fmu with the pyfmi package (from Python) and read out the bounds of every variable with the pyfmi function (get_variable_min/max). best regards, Lukas " lukas.koenemann@… 6409 Simulation is not stopped when an error happens Run-time 1.18.0-dev defect Andreas Heuermann assigned 2021-03-08T10:56:45Z 2021-09-13T11:58:21Z "My ""Network"" simulation, in the output tab, gives these errors: {{{ Error solving nonlinear system 6721 at time 40.5601 nonlinear system 6721 fails: at t=40.5601 Fatal error on line 1118, column 11: tag mismatch }}} but the process Network.exe is not stopped after this, it continues running. This is not so clear in the interface (see screenshot) because the progress bar remains stuck at 0%. OMEdit allows to start a new try of the simulation (so it does not recognize that the process is still running), but the compilation an raises an error because it can't overwrite Network.exe. {{{ C:\PROGRA~1\OPENMO~2.0-D\tools\msys\mingw64\bin\ld: cannot open output file Network.exe: Permission denied clang: error: unable to remove file: Permission denied clang: error: linker command failed with exit code 1 (use -v to see invocation) mingw32-make: *** [Network.makefile:39: omc_main_target] Error 1 mingw32-make: Leaving directory 'C:/Users/simon/AppData/Local/Temp/OPENMO~1/OMEdit/Net~1.NET' Compilation process failed. Exited with code 2. }}} OpenModelica v1.18.0-dev-132-gc048acb712 (64-bit) Windows 10 64-bit" Simone Bosotti 6410 Issues with simulation of Fluid-based models with NF Backend v1.17.0-dev defect Karim Adbdelhak assigned 2021-03-08T14:40:37Z 2021-09-13T11:58:21Z " See forum topic: https://www.openmodelica.org/forum/default-topic/3166-fluid-library-to-complicated-for-omc" Adrian Pop 6429 [MM] Add listFlatten and listFlattenReverse in C for more performance MetaModelica 1.18.0-dev defect Martin Sjölund new 2021-03-17T10:40:16Z 2021-09-13T11:58:21Z " Currently List.flatten is implmeneted as: {{{ listAppend(lst for lst in listReverse(inList)) }}} which has rather bad performance (time and memory wise). Implement this in C." Adrian Pop 6433 Start values with fixed=false not appearing in NLS Backend 1.18.0-dev defect Karim Adbdelhak assigned 2021-03-22T21:57:26Z 2021-09-13T11:58:21Z "As you can see in the model, the value of the parameter startA that is solved in the initial equation does not appear as a start value of the parameter a when looking at the log of the NLS. In this simple model the solver still converges, but for more complicated models this can cause nonconvergence. " Tin Rabuzin 6436 Segmentation fault with non-linear Newton solver Run-time 1.18.0-dev defect Andreas Heuermann new 2021-03-26T11:21:07Z 2021-09-13T11:58:21Z "When running the example from https://trac.openmodelica.org/OpenModelica/ticket/6409 with the newton solver as non-linear solver we get a segmentation fault: {{{ Limited backtrace at point of segmentation fault /lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7f0e485c23c0] /home/andreas/workspace/OpenModelica/build/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so(solveNewton+0x3e)[0x7f0e4918097e] /home/andreas/workspace/OpenModelica/build/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so(solveNLS+0xd2)[0x7f0e4915a802] /home/andreas/workspace/OpenModelica/build/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so(solve_nonlinear_system+0x40e)[0x7f0e4915ae7e] [...] Segmentation fault }}} Since the model isn't public I'll try to solve this or find an example to show the segmentation fault. The problem is that in `solveNewton` in [https://github.com/OpenModelica/OpenModelica/blob/master/OMCompiler/SimulationRuntime/c/simulation/solver/nonlinearSolverNewton.c#L190 nonlinearSolverNewton.c#L190] `solverData` is `NULL`, so `solverData->ftol` will crash. But I don't know ''why'' it is NULL. " Andreas Heuermann 6438 A lookup issue Interactive Environment v1.17.0-dev defect Adeel Asghar accepted 2021-03-26T20:22:42Z 2021-09-13T11:58:21Z "Steps to reproduce: 1) load TestPackage.mo, and open Test: we have a red box because MyModel is missing 2) load Test1.mo and duplicate its model MyModel into TestPackage. Look at model Test inside TestPackage: the red box should disappear, but it does not. 3) save, unload and re-load TestPackage again 4) open Test inside TextPackage: the red box has disappared and now myModel is displayed. So the issue is in point 2. Tested with 1.17.0-dev.beta3." massimo ceraolo 6443 Issues with profiling in OMEdit OMEdit 1.18.0-dev defect Adeel Asghar new 2021-04-21T17:14:32Z 2021-09-13T11:58:21Z "Despite the improvements applied to #5804, we are still facing problems with profiling in OMEdit. The worst problem is that, in some cases, if you turn on profiling after running some simulations on the same model, the profiling results are not loaded. Unfortunately, we were unable to reproduce this issue with a given sequence of steps. However, we believe this is due to some invalid state that the files in the working directory end up in. For sure, we can reproduce another issue: if you run a simulation with profiling on, and then turn it off, the old profiling results keep being loaded and displayed in the debugger, also across sessions, so they may actually be months or years old. This can be quite confusing. If we delete the simulation results directory in the working directory and start from clean conditions, then everything works fine. We would then suggest that all {{{*prof_.*}}} files are deleted just before running a new simulation (both when recompiling and resimulating), to avoid weird side effects from previous simulations. BTW, we did not understand why two {{{prof_}}} files are generated even in case profiling is switched off. What information do they contain? " Francesco Casella 6278 FMUs exported from OM are very heavy FMI 1.16.0 discussion Adrian Pop assigned 2020-12-10T13:00:48Z 2021-09-13T11:58:21Z "As I found a workaround for ticket #6262 I now try to test some FMUs exported from OM, especially for multi-FMU co-initialization with our co-simulator DNG (https://bitbucket.org/simulage/daccosim/wiki/Home). Positive feedback: OM FMUs seem to correctly run and being in conformance with FMI 2.0 for co-simulation. Doing a graph with 2 FMUs iterative coinit is correct and results are identical to those given from Dymola FMUs. Negative feedback: the size of OM FMUs is much more important comparing to Dymola FMUs (with a factor of 10 for the .dll file). Is there any solution to reduce that? Will be an issue with heavy graphs containing lots of FMUs... I attach for comparison an OM FMU and a Dymola FMU from the same model. " jean-philippe.tavella@… 6305 Retire support of Python 2 in OMPython OMPython 1.16.0 discussion arunkumar palanisamy new 2020-12-22T10:36:33Z 2021-09-13T11:58:21Z "Python 2 has been [https://www.python.org/doc/sunset-python-2/ retired] by the Python Software foundation in 2020. In particular, no new safety-critical upgrades are expected to be released. We should discuss how to handle this in OpenModelica, regarding OMPython." Francesco Casella 6344 How to reopen the .csv file of a SSP model run? OMSimulator v1.17.0-dev discussion Lennart Ochel accepted 2021-01-18T07:32:30Z 2021-09-13T11:58:21Z "This thread of discussion is related to SSP runs (OMSimulator). I'm not able to identify the .csv file containing all variables after the run of s SSP model. I see the results in the viewer but where is the .csv file (name, location) for post-morten visualization? Second question: is there somewhere some information related to a SSP model run (simulation time, time for FMU loading, etc.)?" jean-philippe.tavella@… 2499 Better OMEdit support for editing large string bindings for parameters or constants OMEdit trunk enhancement Adeel Asghar new 2013-12-05T09:51:47Z 2021-09-13T11:58:21Z "Sometimes string parameters or constants have a large string binding. For these the user should be able to click on a button and get a larger text editor window (that can be resized) instead of just a one line text area." Adrian Pop 3287 Allow input of common parameters and replaceable classes in a multiple component selection OMEdit trunk enhancement Adeel Asghar new 2015-04-20T10:05:07Z 2021-09-13T11:58:21Z "It is often the case that a model contains several components for which some parameter(s) must take the same value. In this case, it is very convenient to be able to select the set of components and input the value(s) of the parameter(s) in common only once. Once replaceable class support is in place (see #2079), this should also apply to replaceable classes. In particular, this feature will allow to change the medium model of all the Modelica.Fluid components of a system sharing the same medium with just one selection and a few clicks of the mouse." Francesco Casella 3847 Feature Request: Complete as you Type Class Member Drop-Down List OMEdit v1.10.0-dev-nightly enhancement Anatoly Trosinenko assigned 2016-04-14T03:57:36Z 2021-09-13T11:58:21Z "As a modeling user that cannot memorize all class structures of the Modelica Library Classes, a class member drop-down list feature like the one you find in programming environments like MS Visual Studio would be very helpful for the OMEdit modeling code view. Whenever you type a full-stop after a class name, a drop-down list would appear, helping you to auto-complete your package name, class variables, or function names as you type." stephan.fevrier@… 3921 Introduce wrapFunctionCalls and CSE also for the initial equations Backend enhancement Karim Adbdelhak assigned 2016-05-19T22:08:24Z 2021-09-13T11:58:21Z "In some cases (e.g., steady-state initialization of steam power plant models using homotopy) the initial equations could end up being evaluated a large number of times, and therefore could benefit a lot from CSE if expensive function calls can be spared. Please introduce wrapFunctionCalls also within {{{-initOpt}}}" Francesco Casella 3963 Split C source code in more files for more efficient parallel compilation Code Generation enhancement Lennart Ochel new 2016-06-15T17:43:38Z 2021-09-13T11:58:21Z "The MSL and ScalableTestSuite coverage logs https://test.openmodelica.org/libraries/ModelicaTest_trunk/BuildModelRecursive.html https://test.openmodelica.org/libraries/ScalableTestSuite_Experimental/BuildModelRecursive.html reveal that the C compile time is always a significant fraction of the overall build time, and in many cases the bottleneck of the entire process. Recently, the large header file that prevented the splitting of the C source files into much smaller chunks was removed by Martin S., but the number of C files is still the same. We should avoid very large files and split them into a larger number of smaller ones, e.g. by putting an upper bound to the number of functions contained in each .c file. I guess the effort/gain ratio of this improvement would be extremely high, even if a comparatively crude splitting strategy was undertaken. Any volunteers? Thanks! " Francesco Casella 3985 Implement debug logging features in FMUs FMI enhancement Adeel Asghar new 2016-07-01T10:41:36Z 2021-09-13T11:58:21Z "Debugging OMC-generated FMUs is currently very hard, because it is not possible to get additional logging info, e.g. about the nonlinear solver iterations. The current OMC logging interface should be linked to the FMI logging function. I understand from an e-mail discussion that it is possible to do so without any overhead when logging is turned off, by using the functions: {{{ fmi2Status fmi2SetDebugLogging(fmi2Component c, fmi2Boolean loggingOn, size_t nCategories, const fmi2String categories[]); }}}" Francesco Casella 3986 Allow setting default simflags in FMUs FMI enhancement Adeel Asghar new 2016-07-01T10:48:44Z 2021-09-13T11:58:21Z "In some cases, the successful operation of FMUs might depend on low-level runtime options, such as {{{-newtonFTol}}}, {{{-newtonXTol}}}, {{{-ls}}}, etc. It is essential that the person in charge of packaging the FMU (usually an expert) can fine-tune all these settings based on his knowledge, so as to guarantee the best possible performance of the FMU on the end-user side. I would suggest to allow setting values for these flags different from the default ones by adding an {{{input String simflags}}} to the {{{translateModelFMU}}} and {{{buildModelFMU}}} API functions. This could also serve as a makeshift way to get more logging info, while #3985 is implemented." Francesco Casella 4037 Unification of command line options among multiple runtimes Run-time enhancement Lennart Ochel accepted 2016-09-06T06:38:35Z 2021-09-13T11:58:21Z "The C runtime has a lot of command line options. The Cpp runtime has less command line options. Typically the names and the syntax are different. C options are long names that start with one dash and lower case character; Cpp options are either long names that start with two dashes or short (one character) that starts with one dash. Since OpenModelica 1.9.4 the short Cpp options were changed to upper case letters. This way they are unique, because the C runtime uses no upper case letters. This proposal is that the C runtime introduces short versions of the most important command line options as well. The short versions should be the same among all runtimes, while the long versions may be specific. The proposed short options are: || -S arg || simulation start time || || -E arg || simulation end time || || -H arg || simulation step size || || -G arg || number of intervals in equidistant grid || || -I arg || integration solver method || || -L arg || linear solver method || || -N arg || nonlinear solver method || || -C || continue if nonlinear solver does not converge || || -T arg || integration solver tolerance || || -V arg || log settings (all, events, ls, nls, states, warning, discard, error, fatal, pending -- cf. FMI 2 spec) || || -O arg || output writing (all, step, none) for all steps and events or only steps or nothing || || -P arg || simulation results output format (mat or csv) || || -A arg || abort after arg seconds || || -F arg || name of results file || || -M arg || path to Modelica Standard Library || || -R arg || path to simulation runtime libs || " Rüdiger Franke 4150 Virtual Machine problems Installation program v1.11.0 enhancement Adeel Asghar new 2016-11-24T09:22:13Z 2021-09-13T11:58:21Z "1) 64bit support: I downloaded a virtual machine from https://build.openmodelica.org/omc/builds/virtual_machines/nightly64 When started it turned out to be only 32bits. 2) LaTeX is missing, so that OMNotebook Latexcell is not supported. Packages ""texlive-latex-base"" and ""dvipng"" should be enough. 3) Keyboard localization is a bit difficult. I succeeded with running ""sudo dpkg-reconfigure keyboard-configuration"" in a terminal. Maybe that should be documented somewhere?" Henning Kiel 4485 Add units for volume flow to OMEdit OMEdit enhancement Adeel Asghar new 2017-08-03T17:47:51Z 2021-09-13T11:58:21Z Currently volume flows in OMEdit are only displayed in the SI unit m3/s, which is normally quite inconvenient. Popular engineering units for this quantity are m3/h and l/s (liters per senconds), can you add them please? Francesco Casella 4518 Optionally introduce aliases for variables with composite names in the declarative debugger OMEdit enhancement Adeel Asghar new 2017-09-10T20:18:40Z 2021-09-13T11:58:21Z "Equations shown in the declarative debugger tend to be extremely long and span multiple lines even on a large screen, because fully qualified variable names are used, such as {{{ powerPlant.steamPlant.superheater.steamSide.flowModel.fluidModel.p powerPlant.steamPlant.superheater.steamSide.flowModel.fluidModel.T }}} It's easy to envision how an equation containing more than a handful of such long names will be extremely cumbersome and, what's more important, almost impossible to read and understand for a human reader. On the other hand, in most cases large parts of those names are redundant, and actually not needed at all to identify the variables for the person doing the debugging, once he/she understands the context. In fact, when I need to analyze such an equation, I usually copy&paste it in a text editor, then remove all the redundant stuff, so I'm left, in this case, with just {{{p}}} and {{{T}}}. This obiously makes the equations much shorter and a lot more readable. It would be nice if the OMEdit debugger interface did this for me automatically. This could be done along the following lines. A button ""Show short aliases"" is introduced above the equation window. If you select an equation and click on this button, the program collects the fully qualified names of all the variables shown in this equation and removes as many prefixes as possible from them so that the shortest possible variable names are left, that are not ambiguous. Then, it replaces these shorter aliases in the equation for display purposes. For example, if you have {{{a.b.c.x}}} and {{{a.b.c.y}}}, only {{{x}}} and {{{y}}} will be displayed, while if you have {{{a.b.c.x}}} and {{{a.e.c.x}}}, {{{b.c.x}}} and {{{e.c.x}}} will be shown. These aliases will be also be shown in the Variables windows before the fully qualified name, so you have a legend to understand their meaning, e.g., {{{ p (powerPlant.steamPlant.superheater.steamSide.flowModel.fluidModel.p) T (powerPlant.steamPlant.superheater.steamSide.flowModel.fluidModel.T) }}} This simple feature would make the debugger a lot more effective on real-life, non-trivial hierarchical models than it is today. " Francesco Casella 4526 Propagate displayUnits on simple equations New Instantiation enhancement Mahder Alemseged Gebremedhin new 2017-09-22T10:14:07Z 2021-09-13T11:58:21Z "After the ban on replaceable base classes in Modelica 3.0, input & output connectors are Real and no longer have units. When building components the typical pattern is the following: {{{ model M Modelica.SIunits.Temperature T; Modelica.Blocks.Interfaces.RealOutput T_out; ... equation ... T_out = T; ... end M; }}} It would be great if in this case the unit and displayUnit information was automatically propagated from T to T_out, so that I can see the temperature in degrees Celsius when I'm looking into the connector variable. This can be trivially implemented by checking all the equations in the form: {{{ a = b; a + b = 0; }}} where one of the variables (e.g., {{{a}}}) has a non-empty unit string, while the other (e.g., {{{b}}}) has an empty unit string. In this case, {{{b}}} takes the unit and displayUnit attributes of {{{a}}}. When implementing this feature, please pay attention to efficiency, see #4362" Francesco Casella 4539 Vendor specific annotation in MSL Third-Party Libraries enhancement Martin Sjölund assigned 2017-10-01T13:46:04Z 2021-09-13T11:58:21Z "Vendor specific annotations are not allowed in the MSL (see https://github.com/modelica/Modelica/issues/2332). I am wondering if you have a workflow in order add OpenModelica specific annotations to the MSL. In the actual trunk version of the MSL there is model Modelica.Magnetic.QuasiStatic.FundamentalWave.Examples.BasicMachines.InductionMachines.IMC_YD which does not simulate with the default simulation settings in OMEdit. As explained in #4538 the Newton solver is required to work OK. Do have something like a list, where additional OpenModelica specific annotations may be added to MSL Models? " Christian Kral 4699 BaseAvlSet/Tree use O(n*log n) memory *unknown* v1.13.0-dev-nightly enhancement somebody new 2017-12-28T11:07:17Z 2021-09-13T11:58:21Z "A rebalance causes nodes to be recreated though only the pointers need to be adapted, same holds for height value. I propose to use arrays (or Mutable) to hold and update these values to have O(n) memory usage. BaseAvlTree inherits from BaseAvlSet. Special care needs to be taken for its {{{map}}} and {{{mapFold}}} function. {{{ record NODE Key key ""The key of the node.""; array height ""Height of tree, used for balancing""; array subtrees ""Left+right subtrees.""; end NODE; function left input Tree tree; output Tree = tree.subtrees[1]; end left; function right input Tree tree; output Tree = tree.subtrees[2]; end right; }}}" Henning Kiel 4774 Make Interactive Simulation (OPC UA server) work with Cpp runtime Cpp Run-time v1.13.0-dev-nightly enhancement new 2018-02-20T08:01:10Z 2021-09-13T11:58:21Z "Interactive simulation shall be introduced with OpenModelica 1.13. So far it does not work with the Cpp runtime. The only documentation I'm aware of is the [https://liu.diva-portal.org/smash/get/diva2:1118383/FULLTEXT01.pdf thesis by Christoffer Fors Johansson] about ""A prototype was developed""." Rüdiger Franke 4792 wrapFunctionCall does not work for array outputs Backend enhancement Lennart Ochel new 2018-03-05T10:30:57Z 2021-09-13T11:58:21Z "For instance the following model has still 2 function calls: {{{ loadString("" model A function f input Real x; output Real y[2]; algorithm for i in 1:2 loop y[i] := i+sin(x); end for; end f; Real x[2]; output Real y[2]; equation der(x) = 2*f(x[1])+x; y = f(x[1]); end A; ""); simulate(A); getErrorString(); }}} Large models contain often arrays, so it would be quite a good benefit to improve the module wrapFunctionCall." Willi Braun 4851 Split the 16dae.c source file into multiple files Code Generation enhancement Willi Braun new 2018-03-30T20:10:01Z 2021-09-13T11:58:21Z "When compiling large models with {{{-daeMode=new}}}, the lion's share of the compilation time on machines with multiple cores is taken by the 16dae.c file. This contains - a large number of simple functions, each computing a residual - the evaluateDAEResiduals function - the getAlgebraicDAEVarNominals function - the setAlgebraicDAEVars function - the getAlgebraicDAEVars function - the initializeDAEmodeData function I would recommend at the very least to put each of the last five functions in separate C source files. It would also be good to split the first part of the file, containing the residual functions, in multiple chunks, as already done for the 06inz.c file, see ticket:3963#comment:6. This would dramatically speed up the code generation for large models, where C compilation is currently the bottleneck." Francesco Casella 4954 Add a default style.css which OMEdits info/revisions view uses OMEdit v1.13.0-dev-nightly enhancement Adeel Asghar new 2018-05-25T08:55:45Z 2021-09-13T11:58:21Z "OMEdit currently does not offer a way to specify a global (tool) css that the display of info and revisions honour. Other tools do this currently and there is also a ticket on m:#1893 to standardise this in the spec. Until then a tool solution should be in place also for OMEdit." Dietmar Winkler 4990 Should we make IDA the default ODE mode solver? Run-time enhancement Andreas Heuermann assigned 2018-06-18T16:25:08Z 2021-09-13T11:58:21Z "The IDA solver has been implemented as an alternative to DASSL for quite some time. IDA is in fact DASSL's successor: it implements the same basic algorithm, but it is written natively in C and, contrary to DASSL, it is actively maintained as a part of the SUNDIALS suite, so it is in general expected to give better performance than the old DASSL. In principle, once we have IDA implemented I see no reason to keep DASSL as the default option. In fact, I have some test cases where DASSL fails and IDA works just fine. Unfortunately, 99% of the users will just use the default solver and, in case of simulation issues, won't probably think of solving them by simply switching to IDA. So, the question is: should we make ida the default solver for ode mode simulations, in place of dassl? I guess in order to answer this question we need to run the whole testsuite with ida as a default solver and look for regressions and improvements. Currently, we have Hudson tasks running the whole testsuite with ida and daeMode (https://libraries.openmodelica.org/branches/daemode/ and https://libraries.openmodelica.org/branches/newInst-daemode/), but I don't think we should make daeMode the default solver option. @sjoelund.se, could you set up a task to be run on demand such as https://libraries.openmodelica.org/branches/daemode/, but only with -s=ida as default simflag and no daeMode? I could then analyze the results, so we can take an informed decision. In fact, it could be that ida has few recessions, or possibly none, and a lot of improvements compared to dassl already. On the other hand, if there are issues left we could try to solve them, and/or to give suggestions to the end users when should they perfer IDA over DASSL. " Francesco Casella 5028 Add readDerivatives to readSimulationResultVars() API function Interactive Environment enhancement Martin Sjölund new 2018-07-03T12:33:23Z 2021-09-13T11:58:21Z "I am using variable filters on {{{simulate()}}} and the {{{filterSimulationResults()}}} API functions to select the reference variables for the ScalableTestSuite. The filter regexp and the options of filterSimulationResults allows me to select some representative variables and to get rid of parameters and description strings. However, I could not find a viable way to get rid of the {{{der()}}} variables, which are often noisy and generate false negatives, see e.g. [https://libraries.openmodelica.org/branches/newInst/ScalableTestSuite_noopt/files/ScalableTestSuite_noopt_ScalableTestSuite.Thermal.Advection.ScaledExperiments.SteamPipe_N_320.diff.html this report]. Could you please add one more input to {{{readSimulationResultVars}}} {{{ input Boolean readDerivatives = true; }}} that indicates whether or not derivative names should be included in the output? I guess this would be very useful in general when processing simulation output for testing." Francesco Casella 5070 Build a new class out of selected components OMEdit enhancement Adeel Asghar new 2018-08-22T08:44:22Z 2021-09-13T11:58:21Z "Select a collection of subcomponents and then build a new class out of those components. This is useful when a model gets too big (too many sub-components) and you want to easily add some additional hierarchy to the model. Using this feature is like making a ""subroutine"" of the subcomponents." Adeel Asghar 5164 OMEdit should help remove wrong modifiers OMEdit enhancement Adeel Asghar new 2018-10-10T19:25:20Z 2021-09-13T11:58:21Z "Sometimes, particularly during the development of new models, it happens that instantiated components turn out to have obsolete modifiers. When this happens, it is currently necessary to manually remove them from the textual code, which is a bit awkward. Consider for example the attached test case, where {{{expression}}} has an illegal modifier {{{z = 2.0}}}. It would be nice if, when opening the parameter window for the component, a dialog popped up proposing to remove such modifiers." Francesco Casella 5269 Make number of decimals in OMEdit plots and variable browser customizable OMEdit enhancement Adeel Asghar new 2019-01-11T11:48:08Z 2021-09-13T11:58:21Z "When visualizing results in OMEdit, both in plots and in the variables browser, six significant digits are shown. Some models have very high sensitivity to some variables or parameters (e.g., the current in a line with a very small resistance depends on very tiny voltage differences), so it would be appreciated if the number of shown decimals could be customized to show more when needed." Francesco Casella 5354 Allow to differentiate expressions w.r.t. state derivatives to compute analytic Jacobian for daeMode Backend enhancement Willi Braun new 2019-02-21T21:55:28Z 2021-09-13T11:58:21Z "Give a system F(x, x_dot, t) = 0, solvers such as IDA require to compute the Jacobians dF/dx and dF/dx_dot. The latter task cannot currently be carried out by the backend, because the backend has variables for the states, but not for the derivatives. The backend should then be enhanced to allow this." Francesco Casella 5472 Allow to re-simulate a failed simulation OMEdit v1.14.0-dev-nightly enhancement John Tinnerholm accepted 2019-05-10T16:30:51Z 2021-09-13T11:58:21Z "If a simulation fails, it is not possible to change the solver parameters and re-simulate, one has to recompile the model from scratch every time. It would be nice if one could re-simulate without re-compiling also in this case. @adeas31, would this be easy to implement?" Francesco Casella 5573 Dump the jacobian dependencies on the tearing variables Backend enhancement Karim Adbdelhak new 2019-07-08T14:40:59Z 2021-09-13T11:58:21Z "I'd like to experiment some advanced diagnostic techniques for debugging nonlinear solver failures at initialization. To do so, I need to figure out for each nonlinear implicit system of equations on which tearing variables the Jacobian depends on, directly, or indirectly through the torn equations. I understand from today's discussion in the webmeeting that this information is already available. Can you please dump it somehow, in terms of a list of variable names and/or a list of indeces in the unknown vector {{{x}}}? Thanks!" Francesco Casella 5751 Add a flag to dump the Flat Modelica to a file during model translation or checking Interactive Environment v.1.15.0-dev enhancement Adrian Pop accepted 2019-12-16T16:04:58Z 2021-09-13T11:58:21Z "At the moment one needs to call instantiateModel to get the flat Modelica output. A flag to dump the flat Modelica during the model checking or model build for simulation is desirable as the instantiation can take some time for large models so is not preferable to be repeated. Previous ticket text ----- I used to generate flat modelica outputs and dae dumps directly form OMEdit by the following compiler flags assigned as ""Additional Translation Flags"" in the Options Dialog: {{{ -m +d=evalOutputOnly --postOptModules+=dumpDAE }}} Currently there are no additional files created. Maybe I'm missing something, but at least it used work." Oliver Lenord 5760 Improve behaviour of back/forward buttons in OMEdit Documentation browser OMEdit enhancement Adeel Asghar reopened 2019-12-19T10:50:33Z 2021-09-13T11:58:21Z "The yellow back and forward buttons in the Doumentation browser are very useful to navigate the hyperlinks in the HTML documentation. However, when they are pressed, they bring into view the previous or successive window from the top of the page. In case the documentation is longer than one page, one has to scroll down and search for the line where the link was located in order to continue reading, which is extremely annoying if you do it more than once or twice. I would recommend to record the position of the viewport on the document when hyperlinks are clicked, so that one is brought back to the same exact point when the back or forward button is clicked. As a test case, you can take the {{{Modelica.UsersGuide.Overview}}} info, click on the StateGraph link, then click on the back button." Francesco Casella 5809 Allow multiple installations on the same Windows PC Installation program enhancement Adeel Asghar new 2020-01-29T12:53:36Z 2022-03-09T23:23:13Z "I have a production model (a three-phase PWM inverter) that works perfectly, i.e. without warnings or messages and with correct results, on a relatively old OM version (1.14.0-dev234). It doesn't work anymore with recent nightly builds. When asked to run this model, they issue several runtime errors and then stop simulating. Instead of creating a ticket on this issue, I would like to first by-section to help developers to understand what change spoiled the previous correct behavior. At present, to test several OM versions one should either - have many PCs and install one OMEdit per PC - un-install and re-install versions several times, - create several virtual machines, each of them containing an OM. All of these options are either very costly and/or complicated and/or time-consuming so that to discourage any attempt. In case it is possible to install several OM versions on the same PC, the procedure would be greatly simplified. Today's hard disks are so large that it is not too demanding to have dozens of versions installed. " massimo ceraolo 5859 "Make OMEdit display ""pu"" instead of ""1""?" OMEdit enhancement Adeel Asghar new 2020-02-20T17:30:37Z 2021-09-13T11:58:21Z "The unit for `Modelica.SIunits.PerUnit` is defined with ""1"" and also correctly displayed as such. Now there are reasons why the unit is not ""pu"" but at least for the tool it would be possible to '''display''' ""pu"" instead of ""1"" in parameter dialogues and plots. This would improve the user experience. Dymola does something similar when displaying ""Ω"" instead of ""Ohm"" and I will also suggest to them to maybe display ""pu"" instead." Dietmar Winkler 6010 Get OpenModelica back into FMI Cross-checker FMI enhancement Andreas Heuermann assigned 2020-06-15T12:22:45Z 2021-09-13T11:58:21Z We should get back into the FMI Cross-checker logs. We can use this ticket to keep track of required activities Francesco Casella 6015 Development of an OMScilab interface OMScilab enhancement Adrian Pop new 2020-06-17T10:23:32Z 2021-09-13T11:58:21Z "OpenModelica features the [https://openmodelica.org/doc/OpenModelicaUsersGuide/latest/ommatlab.html OMMatlab API] to interact with Matlab. This is motivated by the widespread use of Matlab in the control community. However, Matlab is not open-source, so we lack a completely open-source alternative. [https://www.scilab.org Scilab] is an open-source alternative to Matlab. It was recently acquired by ESI group, and is still released under GPL v2. The [https://fossee.in/ FOSSEE] initiative promotes the coordinated use of open source software for engineering, and already endorses both OpenModelica and Scilab. The next logical step is to develop an OMScilab API, akin to OMMatlab, to allow tighter integration between these two tools. The development can probably be jump-started by porting the existing Matlab interface, since there are similarities between the two tools. The effort will be coordinated by IIT/FOSSEE.in. We can use this ticket as an initial collecting point for project management information. I suggest that project managers get an account on this trac, and coordinate with Adrian Pop (@adrpo) for technical issues. I already created a new OMScilab component category. I tentatively target this development for the next release 1.17.0, due end of December. We can postpone that if necessary." Francesco Casella 6026 OM Plotting doesn't manage the option to split two variables OMEdit enhancement Adeel Asghar assigned 2020-06-23T12:51:07Z 2021-09-13T11:58:21Z "Currently when you add two variables to Plot:1 (for example) they're added in the same Window together This is an enhancement request to have the possibility to split then in two Windows. Please don't propose to open a new Plot because this is not the intention of this ticket. See the below attached picture of what I mean for two separate window (e.g. one for {{{revolute1.phi}}} and another for {{{revolute1.w}}} https://pasteboard.co/JepY65K.jpg" Knot 6062 Proper handling of changed global settings OMEdit v1.16.0-dev enhancement Adeel Asghar new 2020-07-22T09:59:08Z 2021-09-13T11:58:21Z "As reported in [https://trac.openmodelica.org/OpenModelica/ticket/6059] and [https://trac.openmodelica.org/OpenModelica/ticket/6061] it is unexpected that changes to the settings, e.g. compiler flags, are not carried over to the simulation unless OMEdit is restarted. The dialog box has a disclaimer saying: ""Global flags applied to the Simulation Setup dialog upon the first simulation of a model."" In other words once a model has been simulated the only way to apply changes to the settings is through the ""Simulation Setup"" dialog. None of the following helps to update the local settings: * Simulate * Re-simulate * Re-simulate Setup (at least this should work) * Unload+reload+simulate * Delete results+simulate Only a restart of OMEdit will carry over the global settings to the new simulation. As this behavior is at least partially unexpected it can cause a significant amount of frustration when trying out different compiler flags. I suggest that when a model is re-compiled, then it should also appreciate the latest global settings." Oliver Lenord 6073 [OMEdit] Add support for pre/post scripts to simulate OMEdit enhancement Adeel Asghar new 2020-07-28T13:00:11Z 2021-09-13T11:58:21Z "See: https://openmodelica.org/forum/default-topic/3060-custom-components-requiring-special-environment-variables#p10164 Basically would be nice to have scripts to execute before and after the simulate command when the simulate button is pressed. Also, open a .mat file in the plotting perspective when is opened in OMEdit via command line." Adrian Pop 6097 Store imported start values for later reuse Interactive Environment enhancement Karim Adbdelhak new 2020-08-25T15:19:27Z 2022-09-28T00:18:17Z "ticket:5824#comment:3 discusses how to import start values from previous simulations (possibly carried out with other tools) to help the initialization of models. This requires cumbersome data files, while only a minimal part of that information is actually used. @daniel.bouskela asks if it is possible to store this information for later reuse. One option could be to introduce a vendor annotation where OpenModelica stores all the start values that are actually needed to initialize the nonlinear solvers during initialization, and only them. For example, we could introduce an API function call {{{storeExternalInitValues(model, ""results.mat"");}}} that carries out the following steps: - compiles {{{model}}} - determines what are the variables for which initial guesses are required during initialization to set up the iterative solvers - loads their value from the result file - adds (or replaces, if it already exists) an annotation such as {{{ __OpenModelica_storedInitValues( M1.M2.v1 = ; M1.M2.v2 = ; ...); }}} Then we could add a simulation flag {{{-iis}}} that has the same effect as {{{-iif}}}, but gets the data from the stored values instead of getting them from the result file. @Karim, @AnHeuermann, what do you think?" Francesco Casella 6236 Solve simple linear systems in closed form if that leads to simple solution Backend 1.16.0 enhancement Karim Adbdelhak new 2020-11-20T18:22:14Z 2021-09-13T11:58:21Z "Consider the following linear system, which is obtained when building object-oriented 1D, 2D, and 3D thermal models because of pairs of conductances being series connected: {{{ Q = 2*g*(Tb - T2); Q = 2*g*(T1 - Tb); }}} with unknowns {{{Q}}} and {{{Tb}}} ({{{T1}}} and {{{T2}}} are states). This system has a simple closed-form solution: {{{ Q := g*(T1 - T2); Tb := (T1 + T2)/2; }}} that can be computed with a lot less overhead than it is needed to use a numerical linear solver such as LAPACK's {{{dgesv}}}. We could consider trying to solve 2x2 (and possibly 3x3) systems by gaussian elimination using a variant of the ASSC algorithm. If the outcome is simple assignments, we could put them in the generated code, otherwise we should discard it and continue using the numerical solution instead." Francesco Casella 6321 Add the Reload feature in OMEdit OMEdit 1.16.0 enhancement Adeel Asghar new 2021-01-02T19:17:11Z 2021-09-13T11:58:21Z "When working with OpenModelica and other tools (including a text editor) it often happens that modifications to a work-in-progress library are done outside OMEdit. In order to get them in, one currently needs to first unload the library, and the load it again, either by providing the full pathname (which is a pain) or by using the recent file list. It would be much nicer to be able to perform this action by a single operation ""Reload"", preferably placed under ""Unload"" in the context menu of the Libraries Browser" Francesco Casella 6417 OMEdit keyboard short cuts / hot keys OMEdit v1.17.0-dev enhancement Adeel Asghar new 2021-03-11T11:13:15Z 2021-09-13T11:58:21Z "To increase the usability of omedit i'd suggest keyboard shortcuts for the following commands: - Run simulation - Re-Run simulation - Simulation setup - Switch between views of a model (schema/text view) - verify model If accepted, this issue could be mentioned in #2894" openmodelica@… 6422 Performance problems with Power Electronics Run-time 1.16.5 enhancement Andreas Heuermann new 2021-03-12T08:31:59Z 2021-09-13T11:58:21Z "OM 1.16.5 on Windows 10 64bit Please consider the enclosed model: It's a bidirectioanl DC/DC converter for coupling a 13 V battery with an 48 V battery in automotive systems. As a reference, in Dymola simulation takes about 2 minutes (I know, simulation of switching power electronics can't be really performant). OM reports ""The initialization finished successfully without homotopy method."", then it seems to get stuck at 3% for a long time without any feedback. You may add that model to your test cases. " ahaumer@… 6423 Optionally list all empty connection sets New Instantiation 1.16.2 enhancement Per Östlund new 2021-03-12T12:34:16Z 2021-09-13T11:58:21Z "Sometimes people make mistakes by not connecting (or incorrectly connecting) ports, particularly in electrical circuits. This fact may not be immediately obvious from inspection of the diagram. It would be nice to get optional notification of all empty connection sets from the front end, e.g. by turing on {{{-d=listEmptyCS}}}. OMEdit could then have a flag that turns this on when Check is performed. @perost, you already gather that information, so this should be an easy task, right?" Francesco Casella 4992 Should we skip some versions of the Buildings library in Hudson testing and in the OMC installer? Testing Framework task Martin Sjölund assigned 2018-06-19T17:40:56Z 2021-09-13T11:58:21Z "@mwetter, if you check https://libraries.openmodelica.org/branches/master/ you can see there are currently 7 versions of the Buildings library, plus 2 versions of the older Annex60 library, in the OMC testsuite, each containing from 300 to 900 test models. Every day, each of these libraries is tested with the latest 7 stable releases of OMC plus the master development version (see https://libraries.openmodelica.org/branches/overview-combined.html), as well as with the latest development version and the fmi, daeMode, newInst and daeMode-newInst flags, see https://libraries.openmodelica.org/branches/ That's really a lot of testing work, which is sometimes straining our servers a bit. It is of course of the utmost importance for us to test the latest versions of the library, so we can check the progress of coverage and performance of OMC on them. I am not sure if there is some added value at also checking all the previous versions, on a daily basis, ao we need your input about this. In fact, this issue also affects the size of the OMC installer and the installation time, since all those versions are included. I don't know if old versions of these libraries are still actively used and thus have value for end-users, or rather if they now have mainly a historical value. Can you please add a comment about which versions you'd like to see in the daily reports and in the installer, so we can streamline both processes? Please note that libraries using versions of the Modelica Standard Library older than 3.2.1 (which had several portability issues) cannot really be supported seriously by OMC, unless they are upgraded to use MSL 3.2.1 (or later). I also take the opportunity of showing the recent progress with the new front end. [https://libraries.openmodelica.org/branches/history/newInst/Buildings_latest.svg Coverage of Buildings] is finally taking off, and we expect it to reach 100% in the following few months, hopefully overcoming all the outstanding issues that could not be fixed in the old front end. Thanks " Francesco Casella 5977 Schedule for 1.16.0 release *unknown* task Adrian Pop new 2020-05-25T14:05:45Z 2021-09-13T11:58:21Z "After today's discussion at the devmeeting, we agreed on this schedule: - Release 1.15.0 is cancelled, replaceable support will be available in 1.16.0 - June 1 2020 after the devmeeting: feature freeze on master - New experimental features which have not been tested thoroughly are allowed until this deadline, as long as they are disabled by default. They can be fixed and improved during the beta testing period, but they cannot be added after feature freeze - June 8 2020 branch off 1.16.0-beta.1 on the maintenance branch, unless there are major issues. The branched-off version should include replaceable support. - After 1.16.0-beta.1 is branched off, new features can be pushed on master (1.17.0-dev). Only bugfixes are allowed on the 1.16.0 maintenance branch, of course they should also be applied to the master branch - Release of 1.16.0 by end of July 2020 at the latest. There are many open blocker tickets for [https://trac.openmodelica.org/OpenModelica/query?priority=blocker&status=accepted&status=assigned&status=new&status=reopened&milestone=1.15.0&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&desc=1&order=id 1.15.0] and [https://trac.openmodelica.org/OpenModelica/query?priority=blocker&status=accepted&status=assigned&status=new&status=reopened&milestone=1.16.0&col=id&col=summary&col=milestone&col=priority&col=status&col=type&col=component&desc=1&order=priority 1.16.0]. Since we are switching to time-based release, strictly speaking there is no such thing as a blocker ticket, this is just to give top priority and attention to the fix. Some of these tickets are expected to be fixed in 1.16.0, the other ones will be rescheduled to 1.17.0" Francesco Casella 6223 Python.h not found OMPython 1.16.0 task arunkumar palanisamy assigned 2020-11-13T06:23:18Z 2021-09-13T11:58:21Z " I try this example to include a Python function in OpenModelica: https://openmodelica.org/doc/OpenModelicaUsersGuide/latest/interop_c_python.html However I get following error : make -j2 -f CallExternalPython.makefile clang -Os -fPIC -mfpmath=sse -fno-dollars-in-identifiers -I""/usr/bin/../include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=CallExternalPython -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o CallExternalPython.o CallExternalPython.c clang -Os -fPIC -mfpmath=sse -fno-dollars-in-identifiers -I""/usr/bin/../include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=CallExternalPython -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o CallExternalPython_functions.o CallExternalPython_functions.c In file included from CallExternalPython_functions.c:7: ./CallExternalPython_includes.h:5:10: fatal error: 'Python.h' file not found #include ^~~~~~~~~~ 1 error generated. : recipe for target 'CallExternalPython_functions.o' failed make: *** [CallExternalPython_functions.o] Error 1 make: *** Waiting for unfinished jobs.... Compilation process failed. Exited with code 2. I checked that gcc is installed. I have the package python3-dev, so that Python.h exists. I copied a path to Python.h in the ModelicaPath to be sure it's not a path issue. Any idea how I could solve this ?" Gerrer 6306 OpenModelica fails to build on MacOS Build Environment 1.16.0 1.16.5 defect Adrian Pop accepted 2020-12-22T22:10:20Z 2021-03-17T09:52:19Z This ticket is to document issues on MacOS and try to keep it to build with help from other people. Adam Dershowitz 5868 Avoid alias elimination of individual elements of an array Backend 1.19.0 defect Karim Adbdelhak assigned 2020-02-26T22:37:10Z 2022-01-19T11:24:27Z "Certain operations involving arrays (e.g. passing them as inputs to functions) only work if their integrity is preserved. In some cases, the {{{removeSimpleEquations}}} algorithm in the backend eliminates some elements of arrays in favour of other scalar aliases, jeopardizing the correctness of those operations. The {{{removeSimpleEquations}}} should be fixed to avoid eliminating individual components of arrays when doing alias elimination." Francesco Casella 2447 Let OM automatically load packages as specified in import statements New Instantiation trunk 1.19.0 enhancement Per Östlund reopened 2013-10-25T20:02:41Z 2021-12-09T09:36:20Z "Currently, OMEdit (and omc I guess) does not automatically load a package that is specified in a import statement. In other tools (e.g., Dymola) it's normally enough to have the package that is listed in an import statement to be either present in the same working directory or in the `MODELICAPATH`. Having to manually load those packages seems to be an unnecessary burden on the user and can be easily done by the tool. I can't really think of any reason why this would *not* be a good feature to have." Dietmar Winkler 1929 Multibody USR and SSR joints have wrong initialization values Backend trunk 2.0.0 defect Willi Braun assigned 2012-11-05T11:04:40Z 2017-10-26T23:04:45Z "ModelicaTest.MultiBody.FourbarVariants.JointUSR and ModelicaTest.MultiBody.FourbarVariants.JointSSR models simulate with wrong results, this is due to wrong initialization of some variables including derivatives of state variables, see for example j2.a in JointUSR or Body1.w_a[1] Body1.z_a[1] Body2.v_0[2] Body2.a_0[2] in joints.SSR The initial conditions and values for the states are completely specified in the models but OMC wrongly computes the initial value of some variables in the USR and SSR joints. " Bruno Scaglioni 2385 Missing variable declarations in instantiated model when using expandable connectors New Instantiation trunk 2.0.0 defect Adrian Pop reopened 2013-10-02T11:13:05Z 2019-04-11T14:57:06Z "Instantiating ExpandableArrayTest.Test below {{{ package ExpandableArrayTest expandable connector B Real x; end B; block Bsource output B bout; equation bout.x = sin(time); end Bsource; model Areceiver input B bin; Real y; equation y = 2 * bin.x; end Areceiver; model Test Areceiver a1; Bsource b1; equation connect(b1.bout,a1.bin); end Test; end ExpandableArrayTest; }}} yields the following: {{{ class ExpandableArrayTest.Test Real a1.y; equation a1.y = 2.0 * a1.bin.x; b1.bout.x = sin(time); end ExpandableArrayTest.Test; }}} where b1.bout.x and a1.bin.x are used in the equations but have no variable declaration. If one removes the '''expandable''' qualifier for B the instantiated model is ok: {{{ class ExpandableArrayTest.Test input Real a1.bin.x; Real a1.y; output Real b1.bout.x; equation a1.y = 2.0 * a1.bin.x; b1.bout.x = sin(time); a1.bin.x = b1.bout.x; end ExpandableArrayTest.Test; }}} " carlj@… 2387 Operator overloading fails for matrices New Instantiation trunk 2.0.0 defect Per Östlund assigned 2013-10-02T13:13:39Z 2019-05-10T08:06:40Z "There seems to be some issues when trying to use overloaded operators with matrices. For example this model: {{{ operator record Complex Real re; Real im; encapsulated operator 'constructor' function fromReal import Complex; input Real re; input Real im = 0; output Complex result(re = re, im = im); end fromReal; end 'constructor'; encapsulated operator '*' function multiply import Complex; input Complex c1; input Complex c2; output Complex c3; algorithm c3 := Complex(c1.re*c2.re - c1.im*c2.im, c1.re*c2.im + c1.im*c2.re); end multiply; function scalarProduct import Complex; input Complex c1[:]; input Complex c2[size(c1, 1)]; output Complex c3; algorithm c3 := Complex(0); for i in 1:size(c1, 1) loop c3 := c3 + c1[i] * c2[i]; end for; end scalarProduct; end '*'; encapsulated operator function '+' import Complex; input Complex c1; input Complex c2; output Complex c3; algorithm c3 := Complex(c1.re + c2.re, c1.im + c2.im); end '+'; end Complex; model ComplexTest Complex c1 = Complex(1.0, 0.0); Complex c2[3, 3] = {{c1, c1, c1}, {c1, c1, c1}, {c1, c1, c1}}; Complex c3[3, 1] = {{c1}, {c1}, {c1}}; Complex c4[3, 1] = c2 * c3; end ComplexTest; }}} In the binding of c4 we have c2 * c3, which is currently evaluated to a Complex[3] array instead of Complex[3, 1] as it should. This is because we don't check the restrictions on the function arguments for scalarProduct, and mistakenly use it even though the dimensions don't match. If the scalarProduct function is removed the compiler still fails with: {{{ Could not vectorize function because dimensions 3 and 1mismatch. }}}" Per Östlund 2689 mapping of zero crossings to equations does not work properly Backend trunk 2.0.0 defect Karim Adbdelhak assigned 2014-05-09T09:48:25Z 2019-04-04T23:26:33Z "The mapping from zero crossings to equations does not work as soon as a model get split up into various equation systems (partitioning). The zero crossing contains only a equation index but no information about the appropriate equation system. The issue can be reproduced using the following model: {{{#!mo model test1 Boolean a; Real b(start=0.7, fixed=true); equation der(b) = if b > 0 then -1 else 1; a = time < 0.5 or time < 0.6; end test1; }}} The debugger pinpoints {{{a = time < 0.5 or time < 0.6}}} instead of {{{der(b) = if b > 0 then -1 else 1}}}. If both equations get reordered the debugger pinpoints the correct equation." Lennart Ochel 3695 removeSimpleEquations is slow on large models Backend v1.9.4-dev-nightly 2.0.0 defect Willi Braun new 2016-02-19T16:46:18Z 2016-03-01T12:53:24Z "The default implementation of removeSimpleEquations in the back-end is slow and scales badly with the system size. A new implementation is available by selecting --removeSimpleEquations=new which performs much better. However, it is still incomplete (e.g., it doesn't handle arrays), and still has some bugs (some alias variables getting set to zero instead of the correct variables). The new implementation should be completed and made the default. Besides the usual testsuite managed by GitHub/Hudson, when testing it I would recommend to also check out the performance with the ScalableTestSuite library" Francesco Casella 3844 Unnecessary array instantiations Frontend 2.0.0 defect Adrian Pop assigned 2016-04-12T18:24:51Z 2019-04-04T21:21:01Z "Examples that use arrays often result in huge code because OpenModelica instantiates these arrays over and over again. Have for instance a look the `Modelica.Media.Examples.R134a.*` examples. Here is a simpler version: {{{#!mo package ArrayData constant Integer[:] cdata = {1, 2, 3, 4, 5, 6, 7, 8, 9}; function f input Integer[:] idata; input Integer idx; output Integer y; algorithm y := idata[idx] + cdata[idx] + cdata[idx + 1]; end f; model Test input Integer idx = 0; parameter Integer[:] pdata = cdata; Integer y = f(pdata, idx+1); end Test; end ArrayData; }}} `ArrayData.Test` is instantiated to: {{{#!mo function ArrayData.f input Integer[:] idata; input Integer idx; output Integer y; algorithm y := idata[idx] + {1, 2, 3, 4, 5, 6, 7, 8, 9}[idx] + {1, 2, 3, 4, 5, 6, 7, 8, 9}[1 + idx]; end ArrayData.f; class ArrayData.Test input Integer idx = 0; parameter Integer pdata[1] = 1; parameter Integer pdata[2] = 2; parameter Integer pdata[3] = 3; parameter Integer pdata[4] = 4; parameter Integer pdata[5] = 5; parameter Integer pdata[6] = 6; parameter Integer pdata[7] = 7; parameter Integer pdata[8] = 8; parameter Integer pdata[9] = 9; Integer y = ArrayData.f({pdata[1], pdata[2], pdata[3], pdata[4], pdata[5], pdata[6], pdata[7], pdata[8], pdata[9]}, 1 + idx); end ArrayData.Test; }}} It is bad if a temporary array is created when calling the function `f`, instead of just passing `pdata`. It is worse if the whole `cdata` array is created temporarily again and again whenever the function `f` wants to access one element of it. " Rüdiger Franke 4069 Unify init.xml files of C and Cpp runtime Run-time 2.0.0 defect Willi Braun accepted 2016-10-12T06:15:10Z 2016-10-19T16:47:51Z "The Variables Browser of OMEdit does not show entry fields for models that were translated with the Cpp runtime. It appears that the XML attribute `isValueChangeable` is missing in the init file. The question arises, why the C runtime and the Cpp runtime generate different _init.xml files." Rüdiger Franke 4442 Incorrect evaluation of inner/outer and record dependencies New Instantiation v1.11.0 2.0.0 defect Per Östlund assigned 2017-06-09T11:02:56Z 2019-05-09T16:44:11Z "The type of the replaceable parameter “medium_01” is exchanged in global “SIM” object and the medium’s record instance is copied to the component level using Modelica’s inner/outer concept. The record’s instance is then further copied using modifiers. OpenModelica does not succeed in evaluating the dependencies within the records in the correct order. This applies to array sizes, which are dependent on the exchanged type and the corresponding instance copied using inner/outer and modifiers. The top-level model to be simulated is the tester “Tester_ShellAndTubeCondenser” in the package “DynamicSolarSystem”. " j.schulz@… 4756 Clock partitioning should be skipped in systems without clock partitions Backend 2.0.0 defect Martin Sjölund accepted 2018-02-13T11:41:22Z 2018-02-16T13:07:33Z "Please check the execstat log of the [https://libraries.openmodelica.org/branches/master/ScalableTestSuite/files/ScalableTestSuite_ScalableTestSuite.Electrical.DistributionSystemDC.ScaledExperiments.DistributionSystemModelicaActiveLoads_N_80_M_80.err DistributionSystemModelicaActiveLoads_N_80_M_80] model. The {{{preOpt clockPartitioning}}} phase takes over 5 seconds and half a gigabye net memory to find out that the system has in fact no clocked partitions at all. I guess it shouldn't be hard to check from NF data that there are no instances of clocks in the model, so as to skip this phase entirely. Is there any reason not to do that?" Francesco Casella 5061 [NF] Are public parameters allowed in functions by the Modelica spec? New Instantiation 2.0.0 defect Per Östlund new 2018-08-10T16:48:14Z 2018-08-10T22:26:26Z "The NF is really strict on this: https://libraries.openmodelica.org/branches/newInst/AdvancedNoise/files/AdvancedNoise_AdvancedNoise.Examples.RailIrregularities.Comparisons.FilterAndConvolution.err {{{ [/var/lib/hudson/slave/workspace/OpenModelica_TEST_LIBS/OpenModelica/OMCompiler/build/lib/omlibrary/AdvancedNoise 1.0.0/Generators/QuickXorshift64star/package.mo:13:5-13:62:writable] Warning: Invalid public variable p, function variables that are not input/output must be protected. }}} The function looks like this: {{{#!mo redeclare function extends initialState ""Returns an initial state for the xorshift64* algorithm"" /* According to http://vigna.di.unimi.it/ftp/papers/xorshift.pdf, the xorshoft* random number generator generates statistically random numbers from a bad seed within one iteration. */ parameter Integer p = 1 ""The number of iterations to use""; protected Real r ""Random number not used outside the function""; algorithm // more here end function initialState; }}} I think we should just issue a warning and allow this." Adrian Pop 5300 Support the inverse annotation Backend 2.0.0 defect Lennart Ochel new 2019-01-25T18:30:37Z 2019-03-14T16:25:25Z "The inverse annotation, as specified in Section 12.8 of the language specification, should be implemented in the backend. This is a minimalistic test model, that should run without the need of any implicit nonlinear solver. {{{ package TestInverse function f input Real x; output Real y; algorithm y := x*abs(x); annotation(Inline = false, inverse(y=g(x))); end f; function g input Real y; output Real x; algorithm x := sqrt(abs(y))*sign(y); annotation(Inline = false); end g; model Test Real x, y; equation y = time - 5; y = f(x); annotation(experiment(StopTime = 10)); end Test; end TestInverse; }}}" Francesco Casella 5344 Duplicate of model causes incomplete code Interactive Environment v1.14.0-dev-nightly 2.0.0 defect Per Östlund assigned 2019-02-18T09:37:18Z 2019-02-18T15:26:41Z "Consider the following package: {{{ package Source import Modelica.Constants.pi; import SI = Modelica.SIunits; package Components model Component parameter SI.Radius r = 1 ""Radius""; parameter SI.Area area = r^2*pi; end Component; end Components; model Example Components.Component component; parameter SI.Length l = 1; annotation(experiment(StartTime = 0, StopTime = 1, Tolerance = 1e-6, Interval = 0.002)); end Example; end Source; }}} If I make a right click on the model {{{Example}}} and select duplicate with the following settings, {{{ Name: Example Path: (blank) }}} the duplicated example {{{ model Example Components.Component component; parameter SI.Length l = 1; annotation(experiment(StartTime = 0, StopTime = 1, Tolerance = 1e-6, Interval = 0.002)); end Example; }}} cannot be simulated for the following reasons: 1. In the duplicate model the class name is just copied and pasted, but not replaced by the fully qualified class name which is required when copying the model the outside of the package {{{Source}}}. This means that {{{ Components.Component component; }}} has to be replaced by {{{ Source.Components.Component component; }}} 2. The {{{import}}} of {{{SI}}} is missing in the duplicate. So after adding {{{ import SI = Modelica.SIunits; }}} the model is finally complete: {{{ model Example import SI = Modelica.SIunits; Source.Components.Component component; parameter SI.Length l = 1; annotation(experiment(StartTime = 0, StopTime = 1, Tolerance = 1e-6, Interval = 0.002)); end Example; }}} === Conclusions and proposal 1. When creating a duplicate of a model into a package on the ''same'' hierarchy level the actual implementation is OK 2. When creating a duplicate of a model into a package on a ''different'' hierarchy level, but still inside the package where the inherited {{{import}}} statements are located, only the class names have to be replaced by the fully qualified class names 3. When creating a duplicate of a model into a package on a ''different'' hierarchy level outside the package where the inherited {{{import}}} statements are located, then the ""missing"" {{{import}}} statements have to be inserted, in addition to replacing the class names by the fully qualified class names For a productive development of models it were extremely helpful to improve the duplicate in the proposed way. Otherwise, it is particularly for beginners extremely difficult to implement the required manual changes. But even experienced user usually suffer from a long list of adaptations to be made when duplicating a model. " Christian Kral 5351 HRSG Cloned Library Component / re-occuring pump error Third-Party Libraries 2.0.0 defect Francesco Casella assigned 2019-02-21T00:12:04Z 2019-02-21T08:02:00Z "In an attempt to model a Combined Power Cycle, I wanted to be able to model a Rankine Cycle with the use of a HRSG - 3 Level pressure and reheat heat exchanger system. I cloned the ThermoPower Library's available model by copying the base class and then the actual HRSG_3LRh.mo file. I then created the combined cycle by adding this in series with all the necessary Rankine and Brayton Cycle components. I'm unable to instantiate this model but I am curious as to whether this is due to the improper use of the HRSG_3LRh or because of how I am using the prescribedspeedpump model. I really do believe that it is the pump at hand that is preventing this model, and many many other Rankine cycles in the past from simulating due to the reoccuring error messages I continue to see, model after model. It reads: [1] 16:55:27 Translation Error [ThermoPower.Examples: 2534:70-2534:81]: Variable q_nom not found in scope ThermoPower.Examples.RankineCycle.Models.PrescribedSpeedPump. [2] 16:55:27 Translation Error [ThermoPower.Water: 5800:7-5804:36]: Class flowCharacteristic not found in scope ThermoPower.Water.Pump$prescribedSpeedPump1$feedWaterPump (looking for a function or record). Every Rankine model I create using any pump.mo file, simple or complex, yeilds an error message(s) exactly the same or very similar pertaining to the flow rate of the system and how ""It's not in the scope of the model"". The only other reason this model cannot instantiate and then simulate might be because I copied a model from the ThermoPower Library, where I've learned recently is undergoing new developments. Any sort of advice or suggestions would be helpful! I have no idea how to trouble shoot this pump error message I continue to get. " KieranF 5549 Cross compilation of FMUs for Win64 on Ubuntu is broken for some models working with files FMI v1.14.0-dev-nightly 2.0.0 defect Lennart Ochel new 2019-06-26T09:50:18Z 2019-06-29T10:02:28Z "While cross compilation from Ubuntu to Win64 generally works (supposing necessary MinGW packages are installed on Ubuntu), compiler cannot find some required .a-files for Win64 platform when model uses the `Modelica.Utilities.Streams.readLine`, for example. == How to reproduce == 1) Install MinGW and OpenModelica 1.14-dev on Ubuntu (from the respective repositories) 2) Create the following files: **Test.mo:** {{{#!modelica model Test String line; output Boolean endOfFile; equation (line, endOfFile) = Modelica.Utilities.Streams.readLine(""test.txt"", 1); end Test; }}} **Test.mos:** {{{#!modelica loadModel(Modelica); print(buildModelFMU(Test, platforms={""i686-w64-mingw32""})); print(getErrorString()); }}} 3) Compile with the following command: {{{ omc Test.mos Test.mo }}} == Expected behavior == The model is compiled correctly, path to the generated FMU is printed to the console, no errors. == Observed behavior == {{{ /tmp$ omc Test.mos Test.mo true Error: Error building simulator. Build log: checking build system type... x86_64-unknown-linux-gnu checking host system type... i686-w64-mingw32 checking target system type... i686-w64-mingw32 build_short: x86_64-linux-gnu host_short: i686-mingw32 checking for i686-w64-mingw32-gcc... i686-w64-mingw32-gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... yes checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether i686-w64-mingw32-gcc accepts -g... yes checking for i686-w64-mingw32-gcc option to accept ISO C89... none needed checking how to run the C preprocessor... i686-w64-mingw32-gcc -E checking whether make sets $(MAKE)... yes checking for cross-compilation flags... not needed; i686-w64-mingw32-gcc contains the prefix checking if -Werror works... ok checking looking for --no-undefined... yes checking looking for dollars in identifiers... CPPFLAGS: -fdollars-in-identifiers checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for an ANSI C-conforming const... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for size_t... yes checking for vprintf... yes checking for _doprnt... no checking for strdup... yes checking for strerror... yes checking LAPACK/BLAS flags... not found checking for static pthreads... OK (static) checking for cos in -lm... yes checking for filesystem access... OK checking fmi2Functions.h usability... yes checking fmi2Functions.h presence... yes checking for fmi2Functions.h... yes checking fmi2FunctionTypes.h usability... yes checking fmi2FunctionTypes.h presence... yes checking for fmi2FunctionTypes.h... yes checking fmi2TypesPlatform.h usability... yes checking fmi2TypesPlatform.h presence... yes checking for fmi2TypesPlatform.h... yes configure: creating ./config.status config.status: creating Makefile i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o Test.o Test.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o Test_functions.o Test_functions.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o Test_records.o Test_records.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o Test_01exo.o Test_01exo.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o Test_02nls.o Test_02nls.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o Test_03lsy.o Test_03lsy.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o Test_04set.o Test_04set.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o Test_05evt.o Test_05evt.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o Test_06inz.o Test_06inz.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o Test_07dly.o Test_07dly.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o Test_08bnd.o Test_08bnd.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o Test_09alg.o Test_09alg.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o Test_10asr.o Test_10asr.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o Test_11mix.o Test_11mix.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o Test_12jac.o Test_12jac.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o Test_13opt.o Test_13opt.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o Test_14lnz.o Test_14lnz.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o Test_15syn.o Test_15syn.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o Test_16dae.o Test_16dae.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o Test_17inl.o Test_17inl.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o Test_init_fmu.o Test_init_fmu.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o Test_FMU.o Test_FMU.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o util/read_matlab4.o util/read_matlab4.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o util/read_csv.o util/read_csv.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o util/libcsv.o util/libcsv.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o gc/memory_pool.o gc/memory_pool.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o gc/omc_gc.o gc/omc_gc.c In file included from Test_FMU.c:54:0: fmi-export/fmu2_model_interface.c.inc: In function ‘omc_assert_fmi_common’: fmi-export/fmu2_model_interface.c.inc:162:16: warning: passing argument 1 of ‘GC_vasprintf’ from incompatible pointer type [-Wincompatible-pointer-types] GC_vasprintf(&str, msg, args); ^ i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o util/base_array.o util/base_array.c In file included from openmodelica_func.h:52:0, from Test_FMU.c:10: util/modelica_string.h:71:5: note: expected ‘const char **’ but argument is of type ‘char **’ int GC_vasprintf(const char **strp, const char *fmt, va_list ap); ^~~~~~~~~~~~ i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o util/boolean_array.o util/boolean_array.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o util/omc_error.o util/omc_error.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o util/omc_file.o util/omc_file.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o util/division.o util/division.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o util/generic_array.o util/generic_array.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o util/index_spec.o util/index_spec.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o util/integer_array.o util/integer_array.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o util/list.o util/list.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o util/modelica_string.o util/modelica_string.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o util/real_array.o util/real_array.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o util/ringbuffer.o util/ringbuffer.c Test_FMU.c: At top level: cc1: warning: unrecognized command line option ‘-Wno-parentheses-equality’ i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o util/string_array.o util/string_array.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o util/utility.o util/utility.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o util/varinfo.o util/varinfo.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o util/ModelicaUtilities.o util/ModelicaUtilities.c util/ModelicaUtilities.c: In function ‘ModelicaError’: util/ModelicaUtilities.c:68:1: warning: ‘noreturn’ function does return } ^ util/ModelicaUtilities.c: In function ‘ModelicaVFormatError’: util/ModelicaUtilities.c:72:1: warning: ‘noreturn’ function does return } ^ util/ModelicaUtilities.c: In function ‘ModelicaFormatError’: util/ModelicaUtilities.c:79:1: warning: ‘noreturn’ function does return } ^ util/ModelicaUtilities.c: At top level: cc1: warning: unrecognized command line option ‘-Wno-parentheses-equality’ i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o util/omc_msvc.o util/omc_msvc.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o util/simulation_options.o util/simulation_options.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o util/rational.o util/rational.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o util/modelica_string_lit.o util/modelica_string_lit.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o util/omc_init.o util/omc_init.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o util/omc_mmap.o util/omc_mmap.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o math-support/pivot.o math-support/pivot.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o simulation/simulation_info_json.o simulation/simulation_info_json.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o simulation/options.o simulation/options.c simulation/simulation_info_json.c: In function ‘skipValue’: simulation/simulation_info_json.c:113:19: warning: comparison between pointer and zero character constant [-Wpointer-compare] if (str+1 == '\0') { ^~ simulation/simulation_info_json.c:113:13: note: did you mean to dereference the pointer? if (str+1 == '\0') { ^ i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o simulation/simulation_omc_assert.o simulation/simulation_omc_assert.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o simulation/omc_simulation_util.o simulation/omc_simulation_util.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o simulation/solver/delay.o simulation/solver/delay.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o simulation/solver/fmi_events.o simulation/solver/fmi_events.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o simulation/solver/omc_math.o simulation/solver/omc_math.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o simulation/solver/model_help.o simulation/solver/model_help.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o simulation/solver/stateset.o simulation/solver/stateset.c simulation/simulation_info_json.c: At top level: cc1: warning: unrecognized command line option ‘-Wno-parentheses-equality’ i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o simulation/solver/synchronous.o simulation/solver/synchronous.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o simulation/solver/initialization/initialization.o simulation/solver/initialization/initialization.c i686-w64-mingw32-gcc -Os -fno-stack-protector -Wno-parentheses-equality -Wno-unused-variable -fPIC -I/usr/include/omc/c/fmi -fdollars-in-identifiers -DCMINPACK_NO_DLL=1 -c -o meta/meta_modelica_catch.o meta/meta_modelica_catch.c mkdir -p ../binaries/win32 i686-w64-mingw32-gcc -shared -o Test.dll Test.o Test_functions.o Test_records.o Test_01exo.o Test_02nls.o Test_03lsy.o Test_04set.o Test_05evt.o Test_06inz.o Test_07dly.o Test_08bnd.o Test_09alg.o Test_10asr.o Test_11mix.o Test_12jac.o Test_13opt.o Test_14lnz.o Test_15syn.o Test_16dae.o Test_17inl.o Test_init_fmu.o Test_FMU.o ./util/read_matlab4.o ./util/read_csv.o ./util/libcsv.o gc/memory_pool.o gc/omc_gc.o ./util/base_array.o ./util/boolean_array.o ./util/omc_error.o ./util/omc_file.o ./util/division.o ./util/generic_array.o ./util/index_spec.o ./util/integer_array.o ./util/list.o ./util/modelica_string.o ./util/real_array.o ./util/ringbuffer.o ./util/string_array.o ./util/utility.o ./util/varinfo.o ./util/ModelicaUtilities.o ./util/omc_msvc.o ./util/simulation_options.o ./util/rational.o ./util/modelica_string_lit.o ./util/omc_init.o ./util/omc_mmap.o ./math-support/pivot.o ./simulation/simulation_info_json.o ./simulation/options.o ./simulation/simulation_omc_assert.o ./simulation/omc_simulation_util.o ./simulation/solver/delay.o ./simulation/solver/fmi_events.o ./simulation/solver/omc_math.o ./simulation/solver/model_help.o ./simulation/solver/stateset.o ./simulation/solver/synchronous.o ./simulation/solver/initialization/initialization.o ./meta/meta_modelica_catch.o -L""/tmp"" -Wl,-Bstatic ""-L/usr/lib/x86_64-linux-gnu/omc"" -Wl,-rpath=""/usr/lib/x86_64-linux-gnu/omc"" ""-L/usr/lib/"" -Wl,-rpath=""/usr/lib/"" ""-L/home/trosinenko/.openmodelica/binaries/Modelica"" -Wl,-rpath=""/home/trosinenko/.openmodelica/binaries/Modelica"" ""-L/usr/lib/omlibrary/Modelica 3.2.2/Resources/Library/x86_64-linux"" -Wl,-rpath=""/usr/lib/omlibrary/Modelica 3.2.2/Resources/Library/x86_64-linux"" ""-L/usr/lib/omlibrary/Modelica 3.2.2/Resources/Library/linux64"" -Wl,-rpath=""/usr/lib/omlibrary/Modelica 3.2.2/Resources/Library/linux64"" ""-L/usr/lib/omlibrary/Modelica 3.2.2/Resources/Library"" -Wl,-rpath=""/usr/lib/omlibrary/Modelica 3.2.2/Resources/Library"" -lModelicaExternalC -Wl,-Bdynamic -shared -static-libgcc -lm -Wl,-Bstatic -lpthread -Wl,-Bdynamic Test_functions.o:Test_functions.c:(.text+0x1f): undefined reference to `ModelicaInternal_readLine' collect2: error: ld returned 1 exit status Makefile:31: recipe for target 'nozip' failed make: *** [nozip] Error 1 }}}" Anatoly Trosinenko 5552 OpenModelica FMUs seem to not report exact continuous states FMI v1.14.0-dev-nightly 2.0.0 defect Lennart Ochel new 2019-06-28T08:27:59Z 2019-06-28T12:25:45Z "When compiling a simple model to a CoSimulation (cs) FMU using ""OpenModelica v1.14.0-dev-26515-g3e60c14bfc (64-bit)"", the solution to the continuous states after the next '''fmi2doStep''' seems to depend on whether or not the continuous states have been set to what '''fmi2getReal''' reports for the individual states using '''fmi2setReal'''. So, it makes a '''difference''' for the next continuous state if you '''extract''' the current continous state, save it, and then '''set''' it to what was just saved. I'm attaching a Python 3 script to demonstrate this issue using the model ""Modelica.Blocks.Examples.PID_Controller"". The script assumes the corresponding .fmu file to be in the current working directory (see line 26)." dafred4991@… 5560 Make it clearer who are the candidate states in dynamic state selection sets Backend 2.0.0 defect Karim Adbdelhak new 2019-07-02T22:52:36Z 2019-07-02T22:52:36Z "Please run the following test case {{{ model M Real xx, yy, z, w; equation z*der(xx) + w*der(yy) = 0; 2*xx^2 + yy^2 = 3; z = sin(time); w = cos(time); end M; }}} If you turn on {{{-d=stateselection}}}, you get the following output {{{ Number of states: 1 ($STATESET1.x) }}} however, it is not clear that {{{xx}}} and {{{yy}}} belong to this set. Nor it is when looking at the variables browser in OMEdit. The only place where this info is available is the log generated by {{{-d=bltdump}}}, but that is really too low-level. I guess even casual users would like to understand who are the dynamically selected states. Is there any way to improve this, e.g. by adding the candidate state sets to the {{{-d=stateselection}}} output?" Francesco Casella 5708 OM erroneously prompts saving options in annotations OMEdit 2.0.0 defect Adeel Asghar new 2019-11-23T15:30:15Z 2019-11-23T15:33:16Z "The Simulation Setup dialog in it is bottom declares it allows to ""Save experiment annotation inside model ie., experiment annotation"" Unfortunately, this is not always true. For Instance, OM cannot save the state of ""Store Variable ad Events"" (in the Output page of simulation setup) through annotations, probably because no annotation exists to do so. This is confusing and I think should be corrected for 2.0.0 release. Probably the Simulation Setup options must be rearranged in tabs in such a way that options not having annotations to store them inside models are grouped together in a tab for in which it is not proposed to the user to ""Save experiment annotation inside model ie., experiment annotation"". " massimo ceraolo 5759 Support Modelica.Utilities.Strings.* functions directly Interactive Environment 2.0.0 defect somebody new 2019-12-18T20:56:47Z 2020-01-29T08:06:16Z "Currently it doesn't work to call for example scanInteger in a script because we have {{{-d=nogen}}} activated and even so, generating a dll for this is just overkill. We already link with ModelicaExternalC so we could just support this via function evaluation and known external functions. Even if you enable {{{-d=gen}}} on Windows it complains on missing omc_assert. The only way to parse an integer now is to switch to -g=MetaModelica and do {{{stringInt}}} which is just totally annoying. " Adrian Pop 5843 Make sure daeMode works in a reliable way Run-time 2.0.0 defect Karim Adbdelhak new 2020-02-14T14:44:38Z 2020-02-21T01:48:16Z "{{{--daeMode}}} was introduced several years ago, particularly to handle models with large algebraic loops and/or models where the DAE description is sparse while the ODE one is not. The current status of {{{--daeMode}}} is that it works well in a number of cases, but still fails rather frequently. For example, compare the success ratio of simulations of MSL 3.2.3 [https://libraries.openmodelica.org/branches/newInst/Modelica_3.2.3/Modelica_3.2.3.html with odeMode] and with [https://libraries.openmodelica.org/branches/newInst-daeMode/Modelica_3.2.3/Modelica_3.2.3.html daeMode]. We should - investigate why these failures happen - fix them if possible - in case some cases cannot be reliable handled by {{{--daeMode}}} we should issue a proper error message during compilation, instead of generating a failing simulation code" Francesco Casella 2247 Policy for the treatment of Modelica nonconformances in OMC Frontend trunk 2.0.0 discussion somebody new 2013-06-17T08:43:43Z 2017-10-30T00:27:51Z "We need to define a policy to handle models which are not 100% conforming to the Modelica specification in OMC. In doing so, we have to strike a balance between conflicting goals: - promote the full standardization of the language in the Modelica Association - educate users to only use standard language features when writing code, and to progressively remove non-standard features from their existing code base - attract users of other Modelica tools by providing feasible migration paths for non-conformant code The first two goals would suggest that any non-conformance to the spec should generate an error. However, this is probably overkill, and might hamper the migration to OMC by old-time users of other tools having a consolidated code base of models. My proposal is that any non-conformance to the spec should always at least generate a warning, so that the user is aware that his/her code is not 100% Modelica compliant. I would suggest that these warnings cannot be turned off, so there is an incentive to remove the non-conformances from the code base in the medium term. We then need to decide which of these non-conformances should actually generate errors and abort the translation. IMO, this should always be the case for those situations where the semantics is unclear or inconsistent, and where we might need to ""reverse engineer Dymola"" in order to understand how to implement them. Examples: writing a = b where a is an enumeration and b an integer, putting integers in equations involving reals without the appropriate conversion functions, changing final modifiers, multiple inheritance from not exactly equal classes, missing within clause in class declarations, wrong package.order files, etc. On the contrary, other non-conformances like non-standard annotations can be safely ignored, so they should only generate an error by default. We might then add one flag (I would call it 'strict' or something, since it seems that 'pedantic' is already used with a different meaning) that instead generates an error in all these cases. This can be used for the development of libraries (e.g., the MSL), in order to get a correct automatic reporting of models which are 100% clean. However, this flag should be off by default, in order to avoid harassing end-users. Last, but not least, is the issue of models with missing initial equations. Although these models can give problems when used across different tools, they are by no means illegal. My suggestion is to always generate warnings in such cases, and introduce a special flag to generate an error in such cases, which should be turned on when checking libraries such as the MSL, and be off by default. I would avoid mixing this thing up with the 'strict' flag, because that concerns language conformance, and this would only generate confusion, as it is already the case in Dymola. " Francesco Casella 4515 Automatic inference of nominal attributes for scaling New Instantiation 2.0.0 discussion Per Östlund new 2017-09-06T17:00:26Z 2019-05-17T10:13:31Z "As discussed in #4395 and #4510, scaling of variables by nominal values can be critical for the performance of nonlinear solvers. A brute-force approach to this issue is to add nominal attributes on *all* potentially badly scaled variable declarations, either directly or by means of types with suitable default nominal attributes (e.g., Modelica.SIunits.AbsolutePressure). This is rather cumbersome, but most importantly it strongly prevents reuse of models. Assume that I need to model a large industrial hydraulic press, where forces can be in excess of 1e6 N. The models of the hydraulic part, which are developed ad-hoc, will have a proper, domain-specific selection of nominal attributes on variables such as pressures and forces. On the other hand, if I want to re-use the Modelica.Mechanics.Translation models for inertia, springs, etc., the force variables in there won't have any nominal attribute, leaving potentially dangerous holes in the problem scaling. The first solution to this problem is to derive ad-hoc models for the mechanical components by inheritance from the MSL, adding the appropriate nominal values to all the potentially badly scaled variables. Another similar approach is to make a copy of the Modelica.Mechanics.Translational library and modify it along these lines. Both options are clearly far from ideal. A better solution would be to have automatic inference of missing nominal values, so that the scaling values declared in the hydraulic part of the model get propagated to the mechanical part automatically and transparently, without any end-user or library-developer intervention. In some cases, like x = y or x + y = 0, this is trivial (see #4511). Some other cases will be less trivial but easy to manage. For example, x = k*y, where k is a known parameter, allows to infer the nominal attribute of x from that of y, or vice versa. As far as I know, this topic has never been discussed in the Modelica community. I think it definitely deserves to be addressed in a systematic way, and I also think this could lead to some interesting and non-trivial research. If anybody else is interested, please contact me and I will be glad to explore this further, also by providing relevant examples and application cases." Francesco Casella 5370 Modelica compiler should issue warnings when clocked equations appear outside of the when equations Backend 2.0.0 discussion Lennart Ochel new 2019-03-03T19:30:02Z 2019-05-17T22:41:39Z "While working with clocked equations I found that its to easy to turn continuous equations into clocked ones by mistake due to clock inference. I think it would be much easier to debug such situations if Modelica compiler would print warning for synchronous equations appearing outside of the clocked when equations, except for connect equations and equations with synchronous sample operator. {{{ #!modelica model Example Real x, y, z; equations x = sample(time, Clock(0.1)); //no warnings when Clock() y = x; end when; z = z; // print warning end Example; }}} " anonymous 2157 Automatic generation of HTML documentation from Modelica packages Frontend trunk 2.0.0 enhancement somebody new 2013-04-17T10:29:06Z 2017-10-29T22:57:07Z "The Modelica language has been designed to make the automatic generation of library documentation from the source code, by exploiting type information (attributes), comments, graphical annotations and documentation annotations. Dymola is able to generate pretty-printed HTML documentation, and this feature has been used, e.g., to generate the documentation of the Modelica Standard Library. However, Dymola is not free software. For organizations who want to rely on OMC for the entire Modelica toolchain, this feature would be extremely important, possibly with improvement over what is currently done by Dymola. An additional useful feature would be to automatically generate LaTeX and/or Open Document Format code, that can, e.g., be included as an appendix to a technical report, containing the full, hyperlinked documentation of the library itself." Francesco Casella 3869 3d-trajectories in OMEdit OMEdit 2.0.0 enhancement Adeel Asghar new 2016-04-25T11:29:40Z 2016-04-25T11:35:36Z It would be nice to have the possibility of a 3d plot parametric display to visualize/plot 3d trajectories (Example is Lorenz-Attractor). Henning Kiel 4451 Unspecific error message: The given system is mixed-determined. Backend v1.11.0 2.0.0 enhancement Lennart Ochel assigned 2017-06-20T06:45:10Z 2018-08-13T05:10:52Z """The given system is mixed-determined. [index > 3] Please checkout the option ""+maxMixedDeterminedIndex"" The documentation of the compiler flag says: ""--maxMixedDeterminedIndex Sets the maximum mixed-determined index that is handled by the initialization. Integer (default 3)."" These messages should contain a hint about what is meant by a mixed determined system and its index. Based in the brief description of the compiler flag one can guess that it's probably related to the initialization. A hint what to look at in the model when this error message is thrown would be important. In my case I'm not even sure if it's a bug in my model or a bug in OMC." Oliver Lenord 4870 Do not evaluate parameter-dependent assertions at each time step. Code Generation 2.0.0 enhancement Lennart Ochel new 2018-04-06T17:07:32Z 2018-04-06T17:07:32Z "Please consider the attached simple test case (an RC circuit fed by sinusoidal voltage source). The main Test.c file contains this function {{{ /* equation index: 15 type: ALGORITHM assert(1.0 + R.alpha * (R.T - R.T_ref) >= 1e-015, ""Temperature outside scope of model!""); */ void Test_eqFunction_15(DATA *data, threadData_t *threadData) { TRACE_PUSH const int equationIndexes[2] = {1,15}; modelica_boolean tmp1; static const MMC_DEFSTRINGLIT(tmp2,35,""Temperature outside scope of model!""); static int tmp3 = 0; { tmp1 = GreaterEq(1.0 + (data->simulationInfo->realParameter[4]) * (data->simulationInfo->realParameter[2] - data->simulationInfo->realParameter[3]),1e-015); if(!tmp1) { { FILE_INFO info = {""C:/OpenModelica1.13.0-dev-64bit/lib/omlibrary/Modelica 3.2.2/Electrical/Analog/Basic.mo"",66,5,67,45,0}; omc_assert_warning(info, ""The following assertion has been violated %sat time %f\n1.0 + R.alpha * (R.T - R.T_ref) >= 1e-015"", initial() ? ""during initialization "" : """", data->localData[0]->timeValue); omc_assert_withEquationIndexes(threadData, info, equationIndexes, MMC_STRINGDATA(MMC_REFSTRINGLIT(tmp2))); } } } TRACE_POP }}} which test the assertion at each time step. In fact, since the thermal port is disabled in this case (as in most circuits using the resistor component), the expression in the assert statement turns out to be parameter-dependent. As such, its evaluation should not end up here, but rather together with the initial equations. Furthermore, the corresponding file may be compiled without optimizations, since it will only be executed once, so the additional time spent for the optimization is never justified." Francesco Casella 4871 Avoid using DIVISION macros in the dynamic equations if the denominator is a parameter-dependent expression Code Generation 2.0.0 enhancement Lennart Ochel new 2018-04-06T17:22:23Z 2018-04-12T16:43:56Z "Please consider the attached test case, a simple RC circuit fed by a sinusoidal voltage source. The Test.c file contains the following function {{{ /* equation index: 14 type: SIMPLE_ASSIGN der(C._v) = DIVISION(-source.i, C.C) */ void Test_eqFunction_14(DATA *data, threadData_t *threadData) { TRACE_PUSH const int equationIndexes[2] = {1,14}; data->localData[0]->realVars[1] /* der(C.v) STATE_DER */ = DIVISION_SIM((-data->localData[0]->realVars[7] /* source.i variable */),data->simulationInfo->realParameter[0],""C.C"",equationIndexes); TRACE_POP } }}} This function needs to compute der(C._v) = -source.i/C.C. The denominator of this expression is a parameter-dependent expression, so it should be checked to be non-zero only once during initialization, and then computed with a plain division during simulation. With the current implementation, the check that it is non-zero is re-done times and again at each f(x,t) evaluation. The overhead of this macro in models that have lots of divisions can be substantial: a comparison with the mu-Modelica tool on a simple ODE model, using the same DASSL solver, showed that the slow-down factor can be as high as 4X." Francesco Casella 4960 Evaluate all parameters except some New Instantiation 2.0.0 enhancement Per Östlund new 2018-06-02T14:18:48Z 2018-06-03T21:40:06Z "I am trying to optimize the code generation and the runtime performance of large power grid models compiled with OMC. These models have a very large number of parameters, most of which will never need to be changed at runtime. If I set {{{-d=evaluateAllParameters}}} I can have them evaluated to literal constants in the front-end, with great benefits in terms of improved back-end optimizations, reduced back-end running time, reduced code size and improved runtime performance. However, we need in fact to be able to change just a handful of parameters at runtime, that typically describe the simulation scenario: which loads are changing, which breakers are opened, etc. Unfortunately, this is currently not possible if -d=evaluateAllParameters is set. Putting the Evaluate=true annotation on the parameters that are not going to change is impractical, and also it adds an unnecessary restriction to possible future uses of the model that require the parameters not to be evaluated, e.g. for sensitivity analysis. So, I would propose to add the flag {{{--evaluateAllParametersExcept=regexp}}} to the NF, that evaluates all the parameters in the front-end, except those matching the regexp. @perost, how long would it take to implement such a functionality?" Francesco Casella 5626 Linearize should be available from the OMEdit GUI OMEdit 2.0.0 enhancement Adeel Asghar new 2019-09-05T12:28:06Z 2019-09-10T06:28:49Z Not only from the API script. Francesco Casella 5776 Allow to include in-package dependencies when duplicating OMEdit 2.0.0 enhancement Adeel Asghar new 2020-01-09T10:48:24Z 2020-01-09T13:42:47Z "This is a companion ticket of #4536. Now that #5733 is solved, I expect that someone starts working on #4536. I would like to focus on a nasty issue that, in my opinion, has been plaguing Dymola for years, and maybe can be addressed in OM from the ground up when working on #4536. Consider Package1. Suppose we want to copy Model1 into Package2. Therefore we duplicate into Package2. If common duplication is done, i.e. Dymola's and OM's (once #4536 is solved) this would create a dependency of Package2 on Package1 which not always is welcome. It also stays hidden and annoys non-expert (but also expert) users. In fact, if one unloads Package 1 and opens Model1 in Package 2, a red-box appears in the place of subMod in Package2.Model1. What I suggest is to allow, as an option, to ""include in-package dependencies"". I this case, duplicating Model1 should automatically duplicate also SubModel1. The implementation should take care of the package structure. For instance, when duplicating Model2 into Package2, not only Model2 should be duplicated, but also SubModel2, which should be inserted into SubPackage1; the latter, if not existing, should be created. Note that this is not in contrast with #4536. According to this proposal, all dependencies on libraries (i.e. packages different from the one we are duplicating from) should be dealt with exactly as #4536 asks for. " massimo ceraolo 5779 Enable/disable root finding Backend 2.0.0 enhancement Lennart Ochel new 2020-01-10T16:59:11Z 2020-01-15T12:30:12Z "There is a simulation flag -noRootFinding: [https://openmodelica.org/doc/OpenModelicaUsersGuide/latest/simulationflags.html#simflag-norootfinding] which is according to the users guide applicable only to DASSL and IDA. I'm currently running simulations intended for real time applications using Euler and so forth. I'd like to see this simulation flag as a general setting applicable to all solvers but especially for the fixed step solvers: 1. because real time applications typically have to avoid root finding as it is not deterministic. 2. It should easy to disable this extra capability as these solvers typically do not have an advanced root finding scheme mingled with the solver iterations." Oliver Lenord 6176 Display multi-dimensional arrays under collapsible trees as 1D arrays OMEdit 2.0.0 enhancement Adeel Asghar new 2020-11-03T18:29:22Z 2020-11-03T18:29:22Z "Simulate the following model in OMEdit {{{ model Arrays Real x[10] = fill(1,10); Real y[10,10] = fill(1,10,10); Real z[10,10,3] = fill(1,10,10,3); end Arrays; }}} The array {x} appears in the Variables Browser under a collapsible tree. Unfortunately {{{y}}} and {{{z}}} don't, they flood the browser with all the expanded scalar elements. We shoud probably have hierarchical collapsible trees of elements for the ND arrays as well." Francesco Casella 6240 Extend overconstrained connector semantics to handle dynamic branches Backend 1.16.0 2.0.0 enhancement Karim Adbdelhak new 2020-11-24T14:44:09Z 2021-10-14T09:52:18Z "This is a second, improved attempt to address this issue, following #6238 The overconstrained connector semantics defined in Section [https://specification.modelica.org/master/connectors-and-connections.html#equation-operators-for-overconstrained-connection-based-equation-systems1 9.4] of Modelica 3.4 considers a fixed connection graph, that can be handled statically at compile time. One of the cited examples for overconstrained types in connectors is the phase information in AC power systems. The current semantics is able to represent synchronous systems whose topology remains unchanged during simulation. The phase reference is generated by one component of the synchronous system (normally a power generator) and distributed throughout the entire synchronous system via the overconstrained connector variable. In fact, it is possible to have multiple synchronous systems in the same Modelica model, that correspond to structurally disconnected connections sub-graphs, e.g. two national grids connected by a DC link, but in any case their topology is fixed at runtime. When modelling AC trasmission systems, is is possible that in case of severe perturbations, some key circuit breakers are switched open (i.e., their conductance brough to zero), effectively splitting a single synchronous system into multiple synchronous islands. Note that this requires no structural changes in the grid equations, only to set some admittance values to zero. When this happens, the two (or more) ensuing islands can settle into new steady states with different frequencies. Hence, if a single, whole-system-wide reference is still used, the phase angle of currents and voltages of the now disconnected island(s) will continue to rotate permanently with a frequency that is the difference between the local island frequency and the frequency of the island where the original root node was picked. This is very inconvenient, because it prevents variable step-size solvers to increase the step size, once the system settles to the new steady state. This problem could be avoided by allowing to dynamically break and reconnect the breakable branches corresponding to {{{connect()}}} statements in the connection graph of [https://specification.modelica.org/v3.4/Ch9.html#equation-operators-for-overconstrained-connection-based-equation-systems1 Section 9.4]. It would then be possible to break the synchronous connections established by transmission lines when their admittance is brough to zero, thus modelling effects of circuit breakers on the synchronous sub-system topology. As a consequence, two or more disjoint connection graphs would be formed at the time of the breaker openings, each corresponding to a new synchronous island. The new graph topology should be analyzed at this point, picking a new root node for each newly formed island in the grid. Then, instead of having a single phase reference for the entire system, which would no longer be adequate, one would now have two or more independent phase references, one for each island, which would ensure that the variables of each island reach a steady state, thus avoiding the persistent sinusoidal oscillations found in the case of a statically determined connection topology. From the point of view of the language specification, this extension only requires to add one optional Boolean input to the {{{connect()}}} statement {{{ connect(A.R, B.R, activeBranch = true); }}} where {{{activeBranch}}} tells whether a breakable branch should be added to the connection graph (possibly to be broken at a later stage to avoid loops), or not. If {{{activeBranch}}} is set to a constant value of {{{true}}} (possibly by default), the behaviour is exactly the same as in Modelica 3.4. In case instead it is set to a Boolean variable, the breakable branch will only be added to the graph when {{{activeBranch = true}}}. From an implementation point of view, this means that the graph connection analysis no longer can be performed statically at compile time, but needs to be deferred to run time. According to [https://specification.modelica.org/v3.4/Ch9.html#converting-the-connection-graph-into-trees-and-generating-connection-equations Section 9.4.2], everything except overconstrained connector variables is always handled in the same way, i.e., following [https://specification.modelica.org/v3.4/Ch9.html#generation-of-connection-equations Section 9.2], so the runtime analysis will be limited to overconstrained variables in connectors. Everthing else, including determining connection sets, building connection equations for flow variables, and handling stream connector variables, is unchanged and can still be managed statically at compile time. In general this can be quite a big deal, because Modelica cannot handle structural dynamics at runtime. However, the special case of scalar overconstrained connector variables with zero-dimensional {{{equalityConstraint()}}} function output turns out to be very easy to handle, and is enough to address the issue with the synchronous AC grids. This is demonstrated by the attached examplary case. The attached package contains components to build conceptual models of phasor-based AC power grid models. The components are overly simplified and only retain the minimal features that are needed to analyze this language semantics extension. In this case, the overconstrained variable is actually not the phase angle but rather the angular velocity of the phasor reference frame, which is sufficient to ensure that all state variables are constant when the synchronous islands are all operating in steady state. {{{System 1}}} is a basic example with two generators {{{G1}}} and {{{G2}}}, each connected to a local load, connected by an inductive transmission line {{{T}}}. The system starts in steady state with balanced loads, then at time = 1 the active power consumption of load {{{L2}}} is reduced by 20%. This starts a transient, that eventually dies out once the primary frequency controls stabilize the system at a new, higher frequency. Note that at that point, all state variables are constant, allowing implicit solvers to take large time steps. {{{System 2}}} is similar to {{{System1}}}, except that line {{{T}}} is split in the series connection of lines {{{T1a}}} and {{{T1b}}}, running in parallel, with line {{{T2}}}. This allows to demonstrate the overconstrained connector mechanism, since {{{T1a}}} and {{{T1b}}} form a loop that must be broken to avoid getting an overconstrained system of equations. The overall impedance is the same, so the power and frequency transients are the same as in {{{System1}}}. In {{{System 3}}}, line {{{T2}}} also includes a circuit breaker mechanism, that brings its susceptance {{{B}}} to zero when the {{{T2.open}}} signal becomes true. From that point onwards, there is no longer any exchange of power along the lines, so the system is effectively split into two synchronous islands, one containing {{{G1}}} and {{{L1}}}, the other one containing {{{G2}}} and {{{L2}}}. The frequencies of the two drift apart, causing the phasors and state variables of {{{G2}}} and {{{L2}}}, that still use {{{G1.port.omegaRef}}} as a reference angular velocity, to oscillate forever even when the new steady state is reached. In order to avoid this, the connection graph needs to be split when the breaker embedded in {{{T2}}} is opened. This behaviour is achieved in {{{System4}}} by using the modified {{{TransmissionLineVariableBranch}}} component, that contains two public and one protected ports {{{#!mo ACPort port_a; ACPort port_b; protected ACPort port_b_int; }}} and the following equations {{{#!mo port_a.i = Complex(0,B_act)*(port_a.v - port_b_int.v); when open then closed = false; B_act = 0; elsewhen close then closed = true; B_act = B; end when; port_a.omegaRef = port_b_int.omegaRef; Connections.branch(port_a.omegaRef, port_b_int.omegaRef); connect(port_b_int, port_b, closed); }}} where the breakable branch between the protected port {{{port_b_int}}} and the public {{{port_b}}} is only activated when {{{closed = true}}}. Handling the case of Real overdetermined connector variables with empty constraint function is relatively straighforward. During flattening, the front end should indentify all the structurally connected subgraphs (i.e., ignoring the values of {{{activeBranch}}}), then identify those of them that only contain static breakable branches (for which {{{activeBranch = true}}} by default or by means of constant-evaluated binding) and those that contain at least one dynamically breakable branch. The former should be handled as in Modelica 3.4. For the latter, all the relevant information about overconstrained types and variables, and about nodes and branches of the corresponding subgraphs, should be passed to the backend using some suitable formalism. Subgraphs that are structurally unconnected, regardless of {{{activeBranch}}} status of their breakable branches should be identified. I guess we should try to re-use the front-end code in the backend as much as possible, and even in the runtime code (e.g. for graph analysis) as long as the MetaModelica code of the frontend can be translated into C/C++ code. The generated code should then perform the following operations at initialization and each time any {{{activeBranch}}} connection attribute changes: - re-build the connection graphs of all the structurally unconnected sub-graphs to which the branches that changed their activation status belong, according to the rules set forth in [https://specification.modelica.org/master/connectors-and-connections.html#equation-operators-for-overconstrained-connection-based-equation-systems1 Section 9.4], only accounting for branches with {{{activeBranch = true}}} - in case a previously de-activated branch is re-established, check that the corresponding connection equation involving the overconstrained connector variables is actually verified within some tolerance, otherwise aborting the simulation; this would correspond to the requirement that two islands can only be reconnected if the are operating exactly at the same frequency or phase. This check could be defined by adding one more function {{{reconnectable()}}} to the overconstrained type definition, which returns a boolean indicating if the reconnection is feasible (see below). - identify disjoint sub-graphs within each structurally connected, re-built sub-graph, and select one root node for each of them, according the standard rules set forth in [https://specification.modelica.org/v3.4/Ch9.html#converting-the-connection-graph-into-trees-and-generating-connection-equations Section 9.4.2] - break all loops in those sub-graphs - set each overconstrained connector variable of each sub-graph to be equal to the value of the corresponding root node variable (this can be done trivially via pointers!) If a frequency reference is used, the {{{reconnectable}}} function could be implemented as {{{#!mo function reconnectable input ReferenceFrequency f1; input ReferenceFrequency f2; output Boolean canReconnect; protected constant Real eps = 1e-6; algorithm canReconnect := abs(f1 - f2) < eps; end reconnectable; }}} For phase references, one should account for {{{2*pi}}} ambiguity {{{#!mo function reconnectable input ReferenceAngle theta1; input ReferenceAngle theta2; output Boolean canReconnect; protected constant Real eps = 1e-6; SI.Angle delta; algorithm delta := (theta1 - theta2)- div(theta1 - thetha2, 2*pi)*2*pi; canReconnect := abs(delta) < eps; end reconnectable; }}} I suppose this feature could be implemented rather easily in OpenModelica, as a first prototype implementation of this language extension. It could be tested in an extended version of the attached package, including some more examples with a bit more nodes and edges in the connection graphs, and finally tested on an extended version of the [https://github.com/powergrids PowerGrids library], that already envisioned such a feature. If the experiments with the prototype are successful, this could form the basis of an MCP to introduce this feature into the next version of the Modelica Specification." Francesco Casella 3853 Clean up OpenModelica base libraries MetaModelica 2.0.0 task Martin Sjölund new 2016-04-16T08:54:36Z 2018-10-02T06:02:50Z "OpenModelica uses its own language and base libraries. Sometimes they appear grown arbitrarily instead of thoroughly designed. This costs a lot of time for looking up and finding out the right functions. Development time could be reduced and code quality increased if there were more common conventions. See three examples for lists, arrays and strings below. Everyone can remember basic list operations, like `map` and `fold`: {{{#!mo List.fold(List.map(outLocal, BackendVariable.varCref), BaseHashSet.add, HashSet.emptyHashSet()); }}} But OpenModelica works more efficient if people state: {{{#!mo List.applyAndFold(outLocal, BaseHashSet.add, BackendVariable.varCref, HashSet.emptyHashSet()); }}} See: [changeset:9027e889/OMCompiler]. Can't combined functions like `applyAndFold` be hidden from the public interface and used by the translator automatically? Here is an array example from SimCodeUtil.mo: {{{#!mo Dangerous.arrayUpdateNoBoundsChecking(simVars, Integer(index), simVar::Dangerous.arrayGetNoBoundsChecking(simVars, Integer(index))); }}} Everyone could immediately grasp what this does if it was formulated like: {{{#!mo simVars[index] := simVar :: simVars[index]; }}} Does it really pay off in the high-level language MetaModelica to skip the bounds check? Last but not least strings. One commonly wants to generate a string representation of an object, e.g. for debug logging. Programming languages typically offerer a common concept that applies everywhere, like `object.ToString()` or `to_string(object)`. OpenModelica sometimes uses the concept of appending `String` to the type name and starting with lower case, like `intString` or `realString`. This concept is also used in `BackendDump.mo`, e.g. for `BackendDump.equationString` or `BackendDump.timeEventString`. But there are many other functions that use a different naming that one hardly can remember, mostly in DAEDump.mo, prepending `dump` or appending `Str` instead of `String` or inventing some abbreviations, like: {{{ DAEDump.dumpOperatorString -- operatorString DAEDump.dumpExtDeclStr -- externalDeclString DAEDump.derivativeCondStr -- derivativeCondString }}} It helped a lot if a common concept was used everywhere." Rüdiger Franke 1842 Illegal redeclare should be rejected by the NF with appropriate error message New Instantiation 2.1.0 defect Per Östlund assigned 2012-09-25T11:58:37Z 2018-05-08T09:51:27Z "Model ""Nitri1"" in attached Package results in ""Stack Overflow Error"" when instantiating in OMShell. When deleting line 33 ""package Test = WasteWater.ASMx;"" omc.exe crashes. This structure is used a lot in our Library and is working in Dymola. It would be nice if it would run in OpenModelica (or at least a similar structure). " julian.wyszynski 2010 Prefix rules needs more work in new instantiation New Instantiation trunk 2.1.0 defect Per Östlund new 2013-01-07T11:11:15Z 2018-07-02T13:35:41Z Not all the rules from 4.4.2.2 are implemented in the new instantiation. It's e.g. possible to declare model constants, which shouldn't be allowed. Per Östlund 2153 Better analysis for function completion New Instantiation trunk 2.1.0 defect Per Östlund new 2013-04-14T01:16:01Z 2018-07-02T13:43:01Z "We need way better analysis to find out which functions are complete and can be called during compilation. Currently we consider non-complete: - partial functions - replaceable functions but this is rather wrong and not really correct. Unfortunately the Modelica Specification does not say anything about this, maybe we should add a ticket about it in the Modelica Trac." Adrian Pop 4901 The NF does not check if redeclared functions are legal New Instantiation 2.1.0 defect Per Östlund new 2018-04-25T09:41:54Z 2018-06-13T23:13:40Z "Please consider the attached test package. The model Test.Test_f_wrong should fail, because WrongPackage.f is not a subtype of BasePackage.f" Francesco Casella 4905 Restriction on input connection is not enforced by OMC New Instantiation 2.1.0 defect Per Östlund assigned 2018-04-27T16:41:30Z 2018-06-13T23:14:48Z "Please consider the following test package (also attached) {{{ package TestProtectedConnector model M Modelica.Blocks.Interfaces.RealInput u if use_u; parameter Boolean use_u; // protected Modelica.Blocks.Interfaces.RealInput u_internal; equation if not use_u then u_internal = 1; end if; connect(u, u_internal); end M; model P TestProtectedConnector.M m1(use_u = true); TestProtectedConnector.M m2(use_u = false); Modelica.Blocks.Sources.RealExpression source; equation connect(source.y, m1.u); end P; end TestProtectedConnector; }}} Model P is illegal, because it violates the rule stated in section 9.3 of the specification A connection set of causal variables (input / output) may at most contain variables from one inside output connector or one public outside input connector. With the old FE, a warning is issued {{{ [TestProtectedConnector: 11:5-11:27]: Connecting two signal sources while connecting u to u_internal. }}} while the new FE silently accepts this code. Other tools fail to compile the model, because it does not comply with the specification. IMO this test case should generate an error also in OMC, accepting illegal Modelica code encourages bad modelling practices and hinders tool portability. We may add one flag to optionally lift this restriction, but it shouldn't be the default behaviour." Francesco Casella 5248 Implement saveTotalModel using the new frontend Interactive Environment v1.14.0-dev-nightly 2.1.0 defect somebody new 2018-12-13T18:35:57Z 2018-12-14T07:59:40Z "The saveTotalModel API currently uses a precursor of the new frontend, which doesn't work correctly in many cases. It should be replaced with a new implementation based on the new frontend instead. One idea is to instantiate a model using only the first phase of the instantiation, and then discard any model that hasn't been expanded." Per Östlund 5390 The NF should not evaluate final record parameters unless they only depend on structural or final parameters Backend 2.1.0 defect Karim Adbdelhak assigned 2019-03-14T18:53:31Z 2021-04-30T20:31:20Z "Please consider the {{{Modelica.Mechanics.MultiBody.Examples.Elementary.HeatLosses}}} model. The {{{final}}} parameter {{{body1.R_start}}} is currently constant-evaluated, to avoid the bindings ending up in the initial equation sections, where the back-end doesn't handle them correctly. However, the {{{Body}}} model contains the following declaration: {{{ final parameter Frames.Orientation R_start= Modelica.Mechanics.MultiBody.Frames.axesRotations( sequence_start, angles_start, zeros(3)) ""Orientation object from world frame to frame_a at initial time""; }}} where {{{angles_start}}} is not {{{final}}}, nor it has an {{{Evaluate = true}}} annotation. Hence, {{{R_start}}} should not be constant evaluated, and it should be possible to get it automatically updated if {{{angles_start}}} is changed at run time, without the need to recompile the model from scratch. In fact, that's exactly what Dymola does. Notice that with the current new front-end and backend, simply moving the final binding to the initial equation section produces incorrect results, see the original bug report in #5288." Francesco Casella 5667 Arrays of records insufficiently type checked New Instantiation v1.14.0-dev-nightly 2.1.0 defect Per Östlund new 2019-10-21T08:49:43Z 2019-10-21T11:43:54Z "The following model fails without a proper error message: {{{#!mo record R Real x[:]; end R; model M parameter R r[:] = {R({1, 2, 3}), R({1, 2})}; end M; }}} Currently only the type of the record class itself is considered when type checking, but in cases such as this the type of the record instances should be used instead." Per Östlund 6163 Constrainedby clause not verified by the NF New Instantiation 2.1.0 defect Per Östlund new 2020-10-19T22:33:21Z 2020-10-19T22:33:21Z "Consider the attached test package. The {{{Component}}} model is invalid, because it calls function {{{fa}}} which is contained in the default {{{AdvancedMedium}}} package, but is not defined in the constraining class {{{BaseMedium}}}. Unfortunately, {{{Component}}} is checked successfully. This is too bad, because {{{SystemBroken}}} should be fine, according to the constraining class clause. In fact, it is broken because {{{Component}}} is not valid in the first place. The NF should eventually check that the models are valid under the constraining class clause, and report an error if they aren't." Francesco Casella 4755 Reduce memory usage when building models in OpenModelica *unknown* 2.1.0 enhancement Martin Sjölund new 2018-02-12T16:05:39Z 2018-06-11T12:52:55Z "Please check the results of [https://libraries.openmodelica.org/branches/newInst/ScalableTestSuite/files/ScalableTestSuite_ScalableTestSuite.Electrical.DistributionSystemDC.ScaledExperiments.DistributionSystemModelica_N_112_M_112.err DistributionSystemModelica_N_112_M_112]in the [https://libraries.openmodelica.org/branches/newInst/ScalableTestSuite/ScalableTestSuite.html new front end Hudson report]. The following message appears many time {{{ GC Warning: Failed to expand heap by 16777216 bytes }}} then the final message is issued {{{ GC Warning: Out of Memory! Heap size: 3240 MiB. Returning NULL! }}} If I am not mistaken this mode should have a quarter million equations, so it is large but not exceedingly so; it is the largest model so far in the testsuite. The {{{N_80_M_80}}} model, which is half as big, clears the NF in four seconds with about 1.6 GB memory allocation, which non-trivial but still pretty manageable. Can we configure the Hudson job to also support the N_112_M_112 model? All other times should be below 300 s, save the C compilation, which will however improve a lot as soon as Willi is finished with the new daeMode backend workflow." Francesco Casella 5334 Check for wrong annotations New Instantiation 2.1.0 enhancement Per Östlund new 2019-02-13T12:03:16Z 2019-02-13T12:03:16Z "Wrong annotations are silently ignored by the frontend. They should rather generate errors. Typical test case: {{{ model M Real x(start = 1, fixed = true); equation der(x) = -x; annotation(Experiment(stopTime= 5)); end M; }}} simulates for 1 second instead of 5, because {{{Experiment}}} should be {{{experiment}}} and {{{stopTime}}} should be {{{StopTime}}}. Unfortunately, the compiler does not complain at all." Francesco Casella 5545 Improve diagnostics for wrong connectors New Instantiation 2.1.0 enhancement Per Östlund new 2019-06-22T17:25:12Z 2019-06-22T17:25:12Z The attached model contains a connection between two connectors with incompatible types. It would be good to have a more detailed reporting of the cause of incompatibility, which may help in cases less trivial than this one. Francesco Casella 1055 No warning produced for blocks with non-directional variables (from MathCore) Future defect krsta assigned 2009-03-16T15:26:35Z 2016-02-05T09:58:52Z A warning should be produced for blocks that has variables that are neither inputs nor outputs. krsta 1061 Check of redeclaration of different type is not made (from MathCore) Future defect krsta assigned 2009-03-16T15:34:53Z 2016-02-05T09:58:52Z "In C2 a change to the type Integer is made, which is illegal (must be a subtype of Real). However, C2 builds and returns the value r=3. {{{ class C1 protected replaceable parameter Real r=3.14; end C1; model C2 replaceable parameter C1 x1(redeclare replaceable Integer r=3 ); end C2; }}}" krsta 1168 When there's an empty element in the Placement.iconTransformation record, the corresponding value in the Placement.transformation might be returned instead of '-'. Interactive Model Editor Interface Future defect donida new 2010-02-11T17:05:03Z 2016-02-05T09:58:52Z "When the Placement.iconTransformation record (see page 184 of the Modelica Specification 3.1) has an empty element, a '-' character is returned instead of the default value, in fact, according to the specifications: ""...If no iconTransformation is given the transformation is also used for placement in the icon layer."" the diagram transformation should be returned." donida 1232 Equation systems in when equations not handled correctly Backend Future defect Willi Braun assigned 2010-05-31T15:48:06Z 2017-11-14T22:08:53Z "Equation systems are not handled correctly when put in when equations, such as in this example model: {{{ model when_test Real x; Real y; equation when sample(0, 10) then x = y; y = x; end when; end when_test; }}} This model gives the following error messages when compiled: {{{ generate_ode_system2_nonlinear_residuals failed -SimCodegen.buildSolvedBlocks failed Error processing file: test.mo Error: Internal error generate_compute_output failed Error: Internal error Generation of simulation code failed }}}" Per Östlund 1410 Algebraic loop is generated instead of a known variable Future defect Martin Sjölund new 2011-01-27T10:36:09Z 2018-01-11T09:57:05Z "The following will be executed 3 times per time step, but can actually be decided statically: {{{Real x = sin(x)}}} Basically, if lhs and rhs have the same variables, and the rest of the input is constant, we should be able to solve this before simulation (if it also has some other parameter input, we should be able to solve it during initialization). Is it desirable to solve this in the backend (it could generate a system that is easier to simulate)? Anyway, the residual function generated will be called 3 times per time step and sin is not a terribly cheap operation." Martin Sjölund 1427 Assignment of continuous signals to discrete variables should be rejected Backend Future defect Lennart Ochel assigned 2011-02-05T10:11:37Z 2014-09-30T12:50:04Z "Both of the following work, but should not: {{{#!mo class A Integer i = integer(time); discrete Real r = time; end A; }}} Note that in a function, an assignment `i := r;` should still be allowed since in a function, all changes are discrete or continuous depending on your viewpoint. There probably will not be problems with inline functions since the variability of the call is simply the highest variability of the inputs. (3.8 Variability of Expressions ""If v is a discrete-time component then expr needs to be a discrete-time expression."")" Martin Sjölund 1441 Removing STMT_TUPLE_ASSIGN Backend Future defect Martin Sjölund new 2011-03-02T13:22:28Z 2016-02-05T09:58:52Z "Tuple assignments have a problem today: {{{ class B function fn output Integer o1 := 1; output Integer o2 := 2; annotation(__OpenModelica_Impure = true); end fn; Integer i1,i2; Real r1,r2; algorithm (i1,i2) := fn(); (r1,r2) := fn(); end B; }}} Class B would accept (r1,r2) := fn(), which works in this particular case (because in the C-code, a double can be assigned an integer at the loss of precision (>48-bit long ints; not a big issue)). The big problem here is that converting an integer array to real array or unboxing returned data is not performed. We could either remove STMT_TUPLE_ASSIGN altogether (replace it with pattern assignments - my favorite) or extend the type to include a list of types so that the code generation can perform necessary casts but this does not always work. We could also make the STMT_TUPLE_ASSIGN statement return a temporary variable plus a list of (non-tuple) assignments performed on this temp.var. For now, I'll change the implementation to only check for subtype instead of type conversions, see if the testsuite runs, and commit." Martin Sjölund 1451 Backend scaling for simple array-equation Backend Future defect Patrick Täuber assigned 2011-03-15T10:04:28Z 2017-11-06T15:27:22Z "Scales to the power of 3.5... Horrible n=50 0.231s n=100 2s n=150 9s n=200 27s n=10000 115 days {{{ class A function fn input Real t; input Integer n; output Real out[n]; algorithm out := {i*t for i in 1:n}; end fn; parameter Integer n = 4000; Real r[n]; equation r = fn(time, n); end A; }}}" Martin Sjölund 1458 Cyclic default-bindings in functions are still accepted Frontend Future defect Martin Sjölund reopened 2011-03-24T06:22:41Z 2017-11-14T22:08:53Z "The check should probably be moved to the instantiation of functions (because we fall back to generation of code). We can check for usage of unbound variables in the same place later on... {{{#!mo function f output Real y = y; end f; model A Real y = f(); end A; }}} {{{#!mo function f output Real y = y; end f; class A Real y = 5.79776549334303e-316; end A; Error: Cyclically dependent constants or parameters found in scope : {y} }}}" Martin Sjölund 1514 Backend: Integer linear systems are not handled properly Future defect Martin Sjölund new 2011-05-09T08:55:46Z 2016-02-05T09:58:52Z "The following will generate a (real) linear system of equations. But it contains an integer, which will then truncate the results. {{{ model M Real x; Integer y; equation 2*x + y = 5.0; 2*x - y = 3.0; end M; }}}" Martin Sjölund 1551 "Index reduction fails for ""simple"" model" Backend trunk Future defect Martin Sjölund new 2011-05-26T15:37:00Z 2017-10-23T21:38:04Z "{{{ model M Real y1,y2; equation y1 = sin(time^2); y2 = der(der(y1)); end M; }}}" Martin Sjölund 1552 Optimize algorithm sections whenever possible Backend Future defect Willi Braun assigned 2011-05-29T15:05:59Z 2016-02-05T09:58:52Z "This should generate an alias-equation x = y {{{#!mo model M Real x; Real y = sqrt(time); algorithm x := y; end M; }}} The only thing we really need to think about is that the causality of the algorithm outputs should never change. It does not mean we cannot optimize them (we inline functions after all)." Martin Sjölund 1562 F77 functions sometimes overwrite input arguments Future defect Per Östlund accepted 2011-06-30T01:02:50Z 2016-02-05T09:58:52Z The model Modelica.Media.Incompressible.Examples.Glycol47 gets erroneous values for the poly_rho and poly_Cp constants, because the input array B to the Lapack function dgelsx is overwritten with the unassigned output argument x. This only happens when code generation is used to generate dgelsx. Per Östlund 1575 Really bad code generation for parameter arrays set via a function call... Simulation Code Generation Future defect Adrian Pop new 2011-07-19T09:49:29Z 2017-10-23T21:48:04Z "This model: {{{ model Bad parameter Real x[10000] = fcall(constants); end Bad; }}} generates really bad code that calls fcall 10000 times and then sets the x for that index." Adrian Pop 1616 Unbound parameter warning should be output during instantiation and not elaboration Future defect Per Östlund new 2011-09-08T15:38:05Z 2016-02-05T09:58:52Z We currently print warnings about unbound parameters during elaboration, which means that a warning is generated for each use of the parameter. We should instead print a warning during the instantiation of the variable. Per Östlund 1628 Subscripting jagged arrays give errors Future defect Martin Sjölund new 2011-09-28T13:59:59Z 2016-02-05T09:58:52Z "OpenModelica thinks {{{n[2].r}}} has dimension 3. Works in Dymola: {{{ model N parameter Integer n; Real r[n]; end N; model M N[2] n(n = {3,4}); equation n[1].r = {1,2,3}; n[2].r = {4,5,6,7}; end M; }}} Also try to fix: {{{ model M N[2] n(n = {3,4}); equation n[:].r = {{1,2,3},{4,5,6}}; end M; }}} (It succeeds but should not!)" Martin Sjölund 1633 Provide error message for unknown sizes in slices Future defect Martin Sjölund new 2011-10-04T08:29:57Z 2016-02-05T09:58:52Z "{{{ model ArrayTestModel public parameter Integer dimensionOne = 2; parameter Real exampleArray[:,:] = {{0.4572,0.3556,0.2032}}; protected function ArrayExampleFunction input Integer dimensionOne; input Real valuesList[:,:]; output Real outputList[dimensionOne,:]; protected Integer listSize; Integer aux; algorithm listSize:=size(valuesList, 1); for i in 1:dimensionOne loop aux:=min(i, listSize); outputList[i]:=valuesList[aux]; // Type-checking should catch this; the runtime will be unable to handle such a construct end for; end ArrayExampleFunction; parameter Real exampleArrayList[dimensionOne,:] = ArrayExampleFunction(dimensionOne, exampleArray); end ArrayTestModel; }}}" Martin Sjölund 1640 Connectors in models are not updated Future defect jez assigned 2011-10-24T21:42:32Z 2016-02-05T09:58:52Z "1. Create an own connector, draw a circle in icon view and a rectangle in diagram view 2. Create a model - ""beta"" 3. drag this connector to your model beta 4. Create model ""gejma"" 5. add beta component to gejma 6. Modify ""beta"" - i.e. add another connector 7. in ""gejma"" the block stays the same, even after save. Only restart of OME helps - which is not simple, since you cannot use packages. You have to load all three models separately." jez 1643 FMU is not re-initialized after set continuous state Backend trunk Future defect Jens Frenkel assigned 2011-11-01T14:07:02Z 2016-02-05T09:58:52Z "After setting a state using the function \\ {{{fmiSetContinuousStates}}}  the fmu is not re-initialised. see also the spec. 

fmiStatus fmiSetContinuousStates(fmiComponent c, const fmiReal x[], size?t nx);
Set a new (continuous) state vector and re-initialize caching of variables that depend on the states. Argument nx is the length of vector x and is provided for checking purposes (variables that depend solely on constants, parameters, time, and inputs need not to be newly computed in the sequel, but the previously computed values can be reused). Note, fmiEventUpdate might change the continuous states as well. Note: fmiStatus = fmiDiscard is possible.
" Jens Frenkel 1644 Type-check when-equations Future defect Martin Sjölund new 2011-11-04T10:02:18Z 2016-02-05T09:58:52Z "Consider the following: {{{model M parameter Real r = 1.5; equation when sample(0.5,0.1) then r = time; end when; end M;}}}" Martin Sjölund 1645 renameClass API takes very long time when Modelica library is loaded Future defect Adeel Asghar assigned 2011-11-04T15:04:33Z 2016-02-05T09:58:52Z "renameClass starts refactoring the library models and takes ages to complete when loadModel(Modelica) is done. Adrian you have fixed similar kind of issue with renameComponent API and added a new renameComponentInClass API. You can do the same with this one also :)" Adeel Asghar 1646 Performance of synthetic testcase Frontend Future defect Martin Sjölund new 2011-11-07T10:41:12Z 2017-11-14T22:08:53Z "{{{ model CheckInstantiationLimit extends M(i=1); package P constant Integer limit=10; end P; model N parameter Integer i; M m(i=i+1) if i inList; input FoldFunc inFoldFunc; input ArgType1 inExtraArg1; input ArgType2 inExtraArg2; input ArgType3 inExtraArg3; input FoldType inStartValue; output FoldType outResult; partial function FoldFunc input ElementType inElement; input ArgType1 inConstantArg1; input ArgType2 inConstantArg2; input ArgType3 inConstantArg3; input FoldType inFoldArg; output FoldType outFoldArg; end FoldFunc; algorithm outResult := match(inList, inFoldFunc, inExtraArg1, inExtraArg2, inExtraArg3, inStartValue) local ElementType e; list rest; FoldType arg; case ({}, _, _, _, _, _) then inStartValue; case (e :: rest, _, _, _, _, _) equation arg = inFoldFunc(e, inExtraArg1, inExtraArg2, inExtraArg3, inStartValue); then fold3(rest, inFoldFunc, inExtraArg1, inExtraArg2, inExtraArg2, arg); end match; end fold3; }}}" Martin Sjölund 1815 Type variables cannot be (explicitly) unified even though the compiler can unify them Frontend trunk Future defect somebody new 2012-09-16T00:42:14Z 2017-11-14T22:08:53Z "Even though a type unification is obvious the compiler does not always accept a type specified by a function that's called. In the Side note in the code of #1814 this issue is shown. In the `eq` function a type variable `A` is defined and used for `element`. It has to be of the same type as `Element`, otherwise the call to `equalityFunction` will fail (and a compilation error occurs if that's attempted). `A currentElement` is rejected by the compiler since `next` returns `Element`. This causes the internal type `Element` to potentially have to propagate to any uses outside of the package where a polymorphic function exists that uses `eq`. Mainly I would like `A` to be valid here so that this propagation does not occur. Additionally, it seems more reasonable that naming it `Element` would fail since that type variable is free and there is no indication in the written code that the unification occurs, but that is less important. " adabe588@… 1817 "Exporting ""Modelica.Electrical.Machines.Examples.AIMS_Start"" to FMI generates invalid modelDescription.xml" Code Generation Future defect Willi Braun assigned 2012-09-17T12:51:35Z 2017-11-14T22:08:53Z "modelDescription.xml does not contain a valid min or starting attribute for ScalarVariable aims.airGapS.p while simulation the model the default value is set to ""2"" Exporting the example via Dymola 2013 resulsts in a correct behaivor extract from modelDescription.xml {{{ }}} The missing start/min value causes this error division by zero in partial equation: (aims.airGapS.gamma - (-Real(aims.airGapS.p)) * aims.fixed.phi0) / Real(aims.airGapS.p) because Real(aims.airGapS.p) == 0 | [line] 5463 | [file] Modelica_Electrical_Machines_Examples_AIMS_Start.c" dh 1822 Replaceable type cannot unify with itself Backend trunk Future defect somebody new 2012-09-18T14:06:53Z 2017-11-14T22:08:53Z "This code looks okay to me, but the typechecker disagrees. I'm making a recursive call which causes a type unification error. I have similar code in other places that do not have this issue. Actual Output: {{{ {true,true,true} true """" ""[test.mo:17:3-17:27:writable] Error: Type mismatch in assignment in result := Collection.find(next, it) of polymorphic := polymorphic<$.Collection.Next.Element> [test.mo:17:3-17:27:writable] Error: Type mismatch in pattern result actual type: polymorphic expected type: polymorphic<$.Collection.Next.Element> "" }}} Expected Output: {{{ {true,true,true} true """" (infinite loop) }}} Script: {{{ setCommandLineOptions({""+d=rml,noevalfunc,failtrace"",""+g=MetaModelica"",""+showAnnotations""}); loadFile(""test.mo""); getErrorString(); Test.test({1,2,3,4}); getErrorString(); }}} Code: {{{ encapsulated package Collection replaceable type State subtypeof Any; replaceable type Element subtypeof Any; partial function Next input State state; output Element current; output State nextState; end Next; function find input Next next; input State it; output Element result; algorithm result := find(next, it); end find; end Collection; encapsulated package Test protected import Collection.{find,Next}; public function firstRest input List list; output A first; output List rest; algorithm (first,rest) := match (list) case first :: rest then (first, rest); end match; end firstRest; function lfind input Next next; input List list; output A result; algorithm result := find(firstRest, list); end lfind; function test input List list; output Integer res; algorithm res := lfind(firstRest, list); end test; end Test; }}} " adabe588@… 1884 incompatible types when assigning to type 'modelica_real' from type 'modelica_string' Backend trunk Future defect somebody assigned 2012-10-15T07:56:28Z 2018-01-11T09:38:45Z "Caused by this model: {{{ model DataType_OpenModelica input String str(start = ""muh""); output Integer length; output String outString(start = ""abcdef""); algorithm length:=Modelica.Utilities.Strings.length(str); outString:=str; end DataType_OpenModelica; }}} " anonymous 1940 Multibody USR and SSR joints have wrong simulation values Backend trunk Future defect Willi Braun reopened 2012-11-16T15:31:20Z 2017-11-14T22:08:53Z "ModelicaTest.MultiBody.FourbarVariants.JointUSR and ModelicaTest.MultiBody.FourbarVariants.JointSSR models simulate with wrong results." Lennart Ochel 2045 Initialisation of external object fails Run-time trunk Future defect Lennart Ochel assigned 2013-02-05T06:06:36Z 2017-11-14T22:08:53Z "https://svn.modelica.org/projects/Modelica_EmbeddedSystems/trunk/Modelica_DeviceDrivers/ @r5977 To silence some warnings, optionally download: https://svn.modelica.org/projects/Modelica_EmbeddedSystems/trunk/Modelica_Synchronous/ @r5977 Initialisation of external object fails for Modelica_DeviceDrivers.Blocks.Examples.TestSerialPackager_UDP. I checked it by adding a print statement to the constructor function, which was never executed. The constructor should be called once (and only once), and before it is used. Note that the symbolic init could not be used because {{{ Model is structurally singular, error found sorting equations 2: $PRE.getReal.y[2] = $_start(getReal.y[2]); 4: $PRE.getReal.y[1] = $_start(getReal.y[1]); }}} Bug taken from the [https://www.openmodelica.org/index.php/forum/topic?id=825#p3142 forums]" Martin Sjölund 2080 Mechanics.MultiBody.Examples.Constraints.PrismaticJoint Backend trunk Future defect Lennart Ochel assigned 2013-02-22T12:14:59Z 2017-11-14T22:08:53Z "Modelica.Mechanics.MultiBody.Examples.Constraints.ConstrainPrismaticJoint.mos still fails. But only on 64-bit 12.04 Ubuntu with gcc 4.4. On Mint 14 (Ubuntu 12.10) and when using clang, it works fine. This could mean something changed in the compilers, but I doubt it since it's only tiny vendor patches that differ between the two: 12.04: gcc version 4.4.7 (Ubuntu/Linaro 4.4.7-1ubuntu2) 12.10: gcc version 4.4.7 (Ubuntu/Linaro 4.4.7-2ubuntu1) I had a thought it could be compiler settings that changed (I didn't use -march=native on my laptop in order to please valgrind). It could possibly be that the linear solver changed. But it didn't since it seems we use our own f2c-translated copy of LAPACK internally! (Willi, why do we use our own version of LAPACK in the simulation executables? omc.exe itself is linked with LAPACK anyway...) For 12.04 (which does produce a correct executable), I get: {{{ Error: When solving linear system ... [ 0.0 , -0.9663834860128886 , 0.0 , 1.0 ; -0.5648625214636235 , 0.0 , -0.8191520442889918 , 0.09960050292505122 ; 0.0 , -0.21486551488510405 , 1.0 , 0.0 ; 1.0 , 0.14119408087712543 , 0.0 , 0.0 ] * [ bodyOfConstraint.body.frame_a.r_0[3] ; freeMotionScalarInit.r_rel_a_1 ; bodyOfConstraint.body.frame_a.r_0[1] ; bodyOfConstraint.body.frame_a.r_0[2] ] = [ 0.0 ; 0.0 ; 0.0 ; 0.0 ] }}} (I changed the rhs to all zeroes, which is what the backend used; but I don't get why (1) it fails - all zeroes has a trivial solution provided all x are set in the matrix. (2) why we enter all zeroes on the rhs instead of evaluating the rhs!) So why did it succeed at evaluating the system on 12.04, but still fail later? Anyway, if dgesv failed for a constant zero rhs we should change linear system solver ;) Or why did it not even try evaluating the system on 12.04? Note that the system-provided LAPACK is used for both of these versions. '''Jens''', I think we should just rewrite analyzeConstantJacobian to be a little smarter. I looked at the generated _info.xml and the equations generated are indeed different for the two compilers. For test.openmodelica.org, 6 more linear system are generated than on my laptop (I guess 3+3 initialization). If you got this far, you are braver than me. I didn't go up to check that the text is coherent." Martin Sjölund 2094 Function testcase not covered by BuildModelRecursive.mos Frontend trunk Future defect somebody new 2013-02-28T07:53:32Z 2017-11-14T22:08:53Z "The following testcase is part of ModelicaTest, but we never run it: {{{ loadModel(Modelica);getErrorString(); loadModel(ModelicaTest);getErrorString(); ModelicaTest.testAllFunctions();getErrorString(); }}} It currently fails with: {{{ ""[/mnt/mech/trunk/build/lib/omlibrary/ModelicaTest 3.2.1/Math.mo:182:5-182:52:writable] Error: Wrong type or wrong number of arguments to transpose(Matrices.realSchur(A1))'. (in component ) [/mnt/mech/trunk/build/lib/omlibrary/ModelicaTest 3.2.1/package.mo:34:3-34:42:writable] Error: Class ModelicaTest.Math.Matrices2 not found in scope ModelicaTest.testAllFunctions (looking for a function or record). "" }}}" Martin Sjölund 2120 Make sure solving for a variable always solves the equation Backend trunk Future defect Patrick Täuber assigned 2013-03-12T10:52:50Z 2017-10-29T22:08:59Z "{{{ model M Real r[3]; equation r[1] = 1; r[integer(time)] = 2; r[2] = time; end M; }}} We get `r[3]` is solved by: {{{ Variables (1) ======================================== 1: r[3]:VARIABLE() .M, .Real type: Real [3] Equations (1, 1) ======================================== 1/1 (1): {1.0, time, r[3]}[integer(time, 0)] = 2.0 }}} Add an assertion `integer(time) == 3`, and use `r[3] = 2.0`." Martin Sjölund 2199 wrong figures when plotting 2 different variables. OMPlot trunk Future defect Adeel Asghar assigned 2013-05-21T17:34:19Z 2017-11-14T22:08:53Z I tried to plot other variables as the x axis other than time, but the figures do not seem correct. In my model I set the pipe length as 20m, and simulation time as 500s. If I plot pipe length vs time, the figure should give a constant of 20. Instead, the figures are as shown in the attachement mlmco 2213 How can binded blocks produce top-level inputs? Frontend trunk Future defect somebody new 2013-05-30T15:42:29Z 2017-10-29T23:56:08Z "I found some issues using blocks. OpenModelica cannot simulate the model test from the following package. {{{ package bug_2213 block anyChange ""does any entry of a boolean vector change its value?"" input Boolean vec[:]; output Boolean anychange; algorithm anychange:=false; for i in 1:size(vec, 1) loop anychange:=anychange or change(vec[i]); end for; end anyChange; model test Boolean b[3]; anyChange ac(vec=b); Integer i(start=0, fixed=true); equation b[1] = time > 0.1; b[2] = time > 0.2; b[3] = time > 0.3; when ac.anychange then i = pre(i) + 1; end when; end test; end bug_2213; }}} Already our flat code seems to be weird. Why do we get top-level inputs in the flat code? {{{ class bug_2213.test Boolean b[1]; Boolean b[2]; Boolean b[3]; Integer i(start = 0, fixed = true); input Boolean ac.vec[1]; input Boolean ac.vec[2]; input Boolean ac.vec[3]; output Boolean ac.anychange; equation ac.vec = {b[1], b[2], b[3]}; b[1] = time > 0.1; b[2] = time > 0.2; b[3] = time > 0.3; when ac.anychange then i = 1 + pre(i); end when; algorithm ac.anychange := false; for i in 1:3 loop ac.anychange := ac.anychange or change(ac.vec[i]); end for; end bug_2213.test }}}" Lennart Ochel 2260 Replace DAEDump with template-based dumper Frontend trunk Future defect somebody new 2013-06-24T09:31:29Z 2013-06-24T09:31:29Z "DAEDump has many issues related to dumping of the flattened code, and should be replaced with a template instead. Such a template has already been implemented as DAEDumpTpl, but the old DAEDump is still used by default. All of the old dumping code in DAEDump should be stripped out and replaced with calls to DAEDumpTpl as needed. DAEDumpTpl seems to have been written to mimic DAEDump as much as possible though, which means that it does some things wrong in the same way as DAEDump, so DAEDumpTpl might need some fixes. Testcases should of course be written for the new dumper too." Per Östlund 2287 algorithm assigning an array fails during transformation Backend trunk Future defect probably noone new 2013-07-18T19:34:28Z 2017-11-14T22:08:53Z "The following model fails during index reduction: {{{#!mo model Unnamed Real a[3]; algorithm a[1] := 1; end Unnamed; }}} Error message: {{{ Simulation failed for model: Unnamed Error: Model is structurally singular, error found sorting equations 1: algorithm a[1] := 1.0; ; for variables a[1](3), a[3](1), a[2](2) Error: Internal error Transformation Module PFPlusExt index Reduction Method Pantelites failed! }}} If the model gets extended with a state the translation fails due to unreferenced variables a[2] and a[3]. This is wrong because a[2] and a[3] are referenced in the algorithm (implicit). {{{#!mo model Unnamed Real a[3]; Real x; equation der(x) = 0; algorithm a[1] := 1; end Unnamed; }}} Error message: {{{ Simulation failed for model: Unnamed [:3:3-3:12:writable] Error: Variable a[2] is not referenced in any equation (possibly after symbolic manipulations). }}}" Lennart Ochel 2306 Assignments using functions with multiple outputs Command Prompt Environment trunk Future defect somebody new 2013-08-10T20:03:54Z 2017-11-14T22:08:53Z " {{{ function multRetFn output Integer a := 5; output Integer b := 10; output Integer c := 15; end multRetFn; >> (v1, v2, v3) := multRetFn() //works >> (v1, v2) := multRetFn() //doesn't work (variables not set) >> (v1, , v3) := multRetFn() //doesn't work (error) >> v1 := multRetFn() //doesn't work (variable not set) }}} Strangely enough, using the first value directly works some of the time (see ticket [https://trac.openmodelica.org/OpenModelica/ticket/2242 2242]) {{{ >> multRetFn() / 2 2.5 }}}" joafa554 2316 Remove need to use OPENMODELICAHOME Installation program trunk Future defect Adrian Pop assigned 2013-08-20T08:03:04Z 2017-11-14T22:08:53Z "We already use /proc/self in Linux and similar in OSX. By adding the same for Windows, we can remove the need to have this environment variable mess things up: http://stackoverflow.com/questions/4841546/safely-get-path-to-running-executable-in-windows-api The only open question is how to handle this in OSX as the OMEdit.app needs to be able to find the omc executable. With dynamic linking, this is sort of resolved (as OSX hard-codes the paths of .dylib, so you cannot moved things around freely anyway). And even without, the OMEdit.app can keep a hardcoded path to omc (as it does today)." Martin Sjölund 2319 no support for discrete equation systems Backend trunk Future defect probably noone new 2013-08-22T10:04:09Z 2017-11-14T22:08:53Z "Some discrete variables may be involved in equation systems. This is currently not supported. {{{#!mo model foo Real a; initial equation pre(a)^2 + a^2 = 9; equation when {sample(0.1, 0.1)} then a = time; end when; end foo; }}} Error log: {{{ Translation | Interner Fehler Transformation Module sort components failed! Translation | Interner Fehler sorting equations(strongComponents failed) Translation | Interner Fehler ./Compiler/BackEnd/BackendDAETransform.mo: function analyseStrongComponentBlock failed Translation | Interner Fehler Sorry - Support for Discrete Equation Systems is not yet implemented $PRE.a a $PRE.a ^ 2.0 + a ^ 2.0 = 9.0 a = $PRE.a }}}" Lennart Ochel 2367 Record with vectors, zeros(), size() New Instantiation trunk Future defect Adrian Pop accepted 2013-09-26T08:33:45Z 2020-02-08T20:12:06Z "{{{#!mo model emptyVector2 record R parameter Real x[:]=zeros(size(x,1)); end R; R r; end emptyVector2; }}} here omc.exe freezes. (r15030)" c.schulze@… 2370 Record input connectors wrongly interpreted by the OpenModelica compiler Frontend trunk Future defect somebody new 2013-09-27T08:46:49Z 2017-11-14T22:08:53Z "It seems that the OpenModelica compiler wrongly interprets inputs based on record data types. The three following models a,b,c are essentially the same model, but using different set ups of data types. The use of scalar types (block a) compiles properly, as well as the use of vectorized data types (block b). However, when a record data type (block c) is used the compilation fails with error regarding a mismatch between the number of unknowns (2 equations and 4 unknowns are reported). This is indeed very strange, since the instantiated model actually has the correct code (see below) that is equivalent to the manually coded block a: {{{#!mo // correct automatically generated code for block c class inputoutput.c input Real u.a; input Real u.b; output Real y.a; output Real y.b; equation y.a = u.a; y.b = u.b; end inputoutput.c; package inputoutput record sig Real a,b; end sig; // block a compiles with OpenModelica 1.9 r17338 block a input Real a,b; output Real A,B; equation A = a; B = b; end a; // block b compiles with OpenModelica 1.9 r17338 block b input Real u[2]; output Real y[2]; equation y = u; end b; // block cfails to compile with OpenModelica 1.9 r17338 block c input sig u; output sig y; equation y = u; end c; annotation(Icon(coordinateSystem(extent = {{-100,-100},{100,100}}, preserveAspectRatio = true, initialScale = 0.1, grid = {2,2})), Diagram(coordinateSystem(extent = {{-100,-100},{100,100}}, preserveAspectRatio = true, initialScale = 0.1, grid = {2,2})), uses(Modelica(version = ""3.2""))); end inputoutput; }}}" mats.l.larsson@… 2378 addComponent does not handle the double declaration check Interactive Environment trunk Future defect somebody new 2013-09-30T17:43:02Z 2017-11-14T22:08:53Z "Run the attached script and notice the change in the model. '''loadFile''' checks the double declaration, the same check should be added for '''addComponent''' and '''renameComponentInClass'''." Adeel Asghar 2420 Do not return error messages when calling checkModel (maybe there are other API that do this) Frontend trunk Future defect somebody new 2013-10-11T12:01:52Z 2017-11-14T22:08:53Z "Currently checkModel puts the error messages in the string returned. Should make checkModel return an array with succes(true)/failure(false) and the actual message. Then the user can call getErrorString() to get the error messages. {{{ checkModel -> {true|false, ""message""} getErrorString(); }}}" Adrian Pop 2428 numerical instability Run-time trunk Future defect somebody new 2013-10-18T15:26:02Z 2017-11-14T22:08:53Z "Following model behaves numerical instable: {{{ loadString("" model testCFExpr1 Real x; initial equation der(x) = 3.14159/2; equation sin(der(x)) = cos(x); end testCFExpr1; ""); simulate(testCFExpr1, stopTime=10, tolerance=1e-4); val(x,0); val(x,10); val(der(x),0); val(der(x),10); simulate(testCFExpr1, stopTime=10, tolerance=1e-5); val(x,0); val(x,10); val(der(x),0); val(der(x),10); simulate(testCFExpr1, stopTime=10, tolerance=1e-6); val(x,0); val(x,10); val(der(x),0); val(der(x),10); simulate(testCFExpr1, stopTime=10, tolerance=1e-7); val(x,0); val(x,10); val(der(x),0); val(der(x),10); simulate(testCFExpr1, stopTime=10, tolerance=1e-8); val(x,0); val(x,10); val(der(x),0); val(der(x),10); }}} results with different tolerances: {{{ tolerance = 0.0001: -0.000001326803844565571 1.5707084777514067 1.570795 0.00008784904348996832 tolerance = 0.00001: -0.000001326803844565571 1.5707236871192907 1.570795 0.00007263967560595125 tolerance = 0.000001: -0.000001326803844565571 526.3524099363941 1.570795 18.985196381642503 tolerance = 0.0000001: -0.000001326803844565571 1.570724934665874 1.570795 0.00007139212902257958 tolerance = 0.00000001: -0.000001326803844565571 183.5349266542149 1.570795 0.24824358078800488 " Willi Braun 2463 Error when removing simple equations for a simple model Backend trunk Future defect probably noone new 2013-11-05T14:56:54Z 2017-11-14T22:08:53Z "Some time ago I reported a an error (ticket #2095) that seems to be fixed but Is still get the error in the latest build. To reproduce, use the following model: {{{ model ExtractionSetSTest Real x1(uncertain=Uncertainty.refine); Real x2(uncertain=Uncertainty.refine); Real x3(uncertain=Uncertainty.refine); Real y1; Real y2; Real y3; equation x1+x2 = 0; x1-x2 = 0; y1 = x2+2*x3; x3-y1+y2=x2; y2+y3=0; y2-2*y3=3; end ExtractionSetSTest; }}} ans try to build it. You should get the error message: {{{ - BackendVariable.vararrayNth 1 has NONE!!! Error processing file: ExtractionSetSTest.mo Error: Internal error pre-optimization module removeSimpleEquations failed. Error: Internal error Transformation Module PFPlusExt index Reduction Method Pantelides failed! }}} However the model is correct." Leonardo Laguna 2466 Over-determined system Backend trunk Future defect probably noone new 2013-11-07T14:04:50Z 2017-11-14T22:08:53Z "When setting the initialization parameters for the Multibody components the system becomes over-determined. E.g. by setting the r_0 parameter for the bodyShape component. When instantiating model: {{{ ""Check of test completed successfully. Class test has 915 equation(s) and 921 variable(s). 618 of these are trivial equation(s). "" }}} and when simulating: {{{ Symbolic 14:57:07 0:0-0:0 Too many equations, over-determined system. The model has 924 equation(s) and 921 variable(s). }}} A notable thing is that the numbers of equations, when instantiating and simulating, are not the same. Furthermore, the number of variables and equations are not the same, when just using a bodyShape and a world component without connecting them together. {{{ ""Check of test1 completed successfully. Class test1 has 912 equation(s) and 921 variable(s). 615 of these are trivial equation(s). "" }}}" Nimalk 2471 Add check if variable can be changed via -override* Run-time trunk Future defect Adrian Pop accepted 2013-11-11T08:52:25Z 2017-11-14T22:08:53Z "Currently we do not check if a variable can be changed via -override* functionality in the simulation executable. We should add a check for this (see if isValueChangeable attribute in XML is set to true)." Adrian Pop 2494 Derivative annotation handling broken Code Generation trunk Future defect Willi Braun accepted 2013-11-29T13:21:21Z 2017-11-14T22:08:53Z "The following model does not compile with omc 1.9.0: {{{ #!mo within ; model pendulumDer function equation1 input Real x; input Real y; output Real r = x^2 + y^2 - 1; annotation(...); end equation1; function equation1_der1 input Real x; input Real y; input Real dx; input Real dy; output Real r = 2*(x*dx + y*dy); annotation(...); end equation1_der1; function equation1_der2 input Real x; input Real y; input Real dx; input Real dy; input Real ddx; input Real ddy; output Real r = 2*(x * ddx + dx^2 + y * ddy + dy^2); end equation1_der2; Real x(start=0.1), y(start=-0.9, fixed=true), vx, vy, F; equation equation1(x, y) = 0; der(x) = vx; der(y) = vy; der(vx) = F*x; der(vy) = F*y - 9.81; end pendulumDer; }}} output: {{{ 2 choeger@gimli ~/test % make -f pendulumDer.makefile :( gcc -falign-functions -march=native -mfpmath=sse -fPIC -I""/usr/include/omc"" -I. -L""/home/choeger/test"" -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o pendulumDer.o pendulumDer.c pendulumDer.c: In function ‘eqFunction_2’: pendulumDer.c:1228:3: error: too many arguments to function ‘omc_pendulumDer_equation1__der2’ pendulumDer_functions.c:74:37: note: declared here pendulumDer.c:1237:3: error: too many arguments to function ‘omc_pendulumDer_equation1__der2’ pendulumDer_functions.c:74:37: note: declared here make: *** [pendulumDer.o] Error 1 }}}" Christoph Höger 2500 premature optimization when generating simulation code Backend trunk Future defect Adrian Pop assigned 2013-12-05T20:32:13Z 2017-11-14T22:08:53Z "We'd like to be able to build a simulation executable and then run it multiple times, tweaking various parameter values for each run. However, some parameter overrides have no effect. Consider the simulation executable for the attached very abstract model of a vehicle, generated with {{{ omc +s +i=params.drivetrain params.mo Modelica ModelicaServices make -f params.drivetrain.makefile }}} One can run the model and observe the result: {{{ % ./params.drivetrain -output=body.s time=1,body.s=0.50000000001342925771 % }}} It's possible to override some parameters: {{{ % ./params.drivetrain -output=body.s -override=""body.m=2"" time=1,body.s=0.25000000002465611049 % }}} But not all: {{{ % ./params.drivetrain -output=body.s -override=""direction=2"" time=1,body.s=0.50000000001342925771 % }}} This is because some branches of if-equations controlled by parameter expressions are not being included in the generated C code. This appears to be an optimization, and a reasonable default optimization. However, it would be useful to be able to disable it, so that more kinds of parameters could be overridden at simulation time. Optimizations of this type should be enabled by specific optimization flags, and those flags should be added to the set of default optimizations. In addition, an attempt to override parameters the effect of which has been optimized away should be reported as an error." Bill Janssen 2502 array equations may matched inconsistent Backend trunk Future defect Willi Braun new 2013-12-06T10:49:44Z 2017-11-14T22:08:53Z "That means equation like {a,b,c} = {d,e,f+g} may matched to vars {d,f,g} what is inconsistent. I try to add a testcase later. " Willi Braun 2576 Partial Function Evaluation in Backend for Spice3 Backend trunk Future defect probably noone new 2014-02-09T13:09:19Z 2017-11-14T22:08:53Z "Volker and I had a look at the Inverter Model and found out why it cannot be simulated by omc. Let me try to explain the problem. Inside the M_NMOS component we have the equations {{{ icBD = cc.cBD * (der(B.v) - der(Dinternal)); icBS = cc.cBS * (der(B.v) - der(Sinternal)); icGB = cc.cGB * (der(G.v) - der(B.v)); icGD = cc.cGD * (der(G.v) - der(Dinternal)); icGS = cc.cGS * (der(G.v) - der(Sinternal)); }}} which is the only occurance of der(Dinternal) (and the other der() variables). Unfortunately cc.cBD (and in fact all cc.c*) evaluate to constant zero and thus the equations cannot be solved for der(Dinternal), for example. During compile time however, OpenModelica doesn't notice that cc.c* is zero and therefore cannot take any measures against it. This is because cc is solved in the equation {{{ cc = Mos.mosCalcNoBypassCode( m, m_type, c2, p, C, vp, m_bInit, {G.v, B.v, Dinternal, Sinternal}); }}} most function parameters are evaluated to be constants by the Backend, however (due to constants, final parameters and Evalute=true annotations) bltdump tells us {{{ mp.cc = Modelica.Electrical.Spice3.Internal.Mos.mosCalcNoBypassCode( Modelica.Electrical.Spice3.Internal.Mosfet.Mosfet(300.15, 0.0001, 0.0001, 0.0, 0.0, 1.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0, 1, 1, 0.0, 0.0, false), -1, Modelica.Electrical.Spice3.Internal.Mos1.Mos1Calc(0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.00002, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1, 0.0001, 0.0, 0.0, 0.00002, 600.0, 0.6, 0.0, 0.0, 0.00000000000001, 0.00000000000001, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.8, 0.4, 0.0, 0.7302833841653967, 0.7302833841653967, 0.4686291501015239, 0.3535533905932738, 0.25, 0.0, 0.0, 0.0, 0.025864709055120616, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0), Modelica.Electrical.Spice3.Internal.Mos1.Mos1ModelLineParams(0.0, 0.0, 0.8, 0.5, 0.5, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 1.0, 0.0, 1.0, 0.0, 0.5, 0.6, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 600.0, 0.0, 0.00000000000001, 0.0, 1.0, 0.0, 1.0, 0.00002, 0.0, 300.15), Modelica.Electrical.Spice3.Internal.SpiceConstants(0.00000000010359431399069999, 0.00000000003453133, 0.00000000000000000016021918, 273.15, 0.000000000000000000000013806226, 300.15, 1.4142135623730951, 2.718281828459045, 0.000000000001, 300.15, 300.15, 0.0, 0.0, 0.0001, 0.0001, 0.0000000001, 0.000000000000001, 0.0000000001, 0.001, 0.025864709055120616, 0.0000861726105451295), Modelica.Electrical.Spice3.Internal.Mos.MosModelLineVariables(0.0, 0.0, 0.6, 0.0, 0.00002), false, {mn.G.v, mp.B.v, mp.B.v, mn.Dinternal}) }}} Since, there are still time-varying parameters left, namely {mn.G.v, mp.B.v, mp.B.v, mn.Dinternal}, the function is not being evaluated. However, by looking at the code of Mos.mosCalcNoBypassCode one finds that {{{ out_cc.cBD := if (in_m_bInit) then 1e-15 else (int_c.m_capbdb + int_c.m_capbds); }}} where the following constants are known {{{ in_m_bInit = false; int_c.m_capbdb = 0; int_c.m_capbds = 0; }}} And thus out_cc.cBD is also known. If those information were available to the backend, it should be possible to simulate models from the Spice3 library. Thus, in my opinion we need a new backend module which ""partly evaluates"" functions. What I mean is, that we take a function {{{ {cc.a, cc.b} = f_original(constant, variable) }}} ""copy it"" and create a new function {{{ {cc.a} = f_new(variable) }}} which only depends on the non-constant parameters and where the constants are evaluated inside the function possibly assigning already known outputs (In this example cc.b). Volker knows well how to write such a backend module. However, it would be nice if he would get some advice on how to copy and evaluate such a function efficiently." Christian Schubert 2577 derivatives start-value Backend trunk Future defect probably noone new 2014-02-10T08:27:05Z 2017-11-14T22:08:53Z "Modelica.Media.Examples.ReferenceAir.DryAir1 says > Warning: Iteration variables with default zero start attribute in equation system w/o analytic Jacobian: input $DER.volume.medium.h:DUMMY_DER(fixed = false ) Should we add some start-value for these or ignore printing such warnings since we introduced this variable?" Martin Sjölund 2582 do more check in checkModel Backend trunk Future defect probably noone new 2014-02-13T14:44:38Z 2017-11-14T22:08:53Z "There are already some warnings for parameters with binding and fixed=false, without binding and fixed=true, and so on (some cases are still not covered, see https://trac.openmodelica.org/OpenModelica/browser/trunk/testsuite/simulation/modelica/initialization/parameters.mos?rev=19092). Unfortunately, some of them are thrown in the front end and some in the back end. It would be better to move all of them to the front end, because then they get also covered by “checkModel”. Due to some issues in the front end, this cannot be done right now. So I will move all of the warning back into the back end to keep them all together. We should think about extending the checkModel phase between front and back end and moving all these warning there." Lennart Ochel 2599 Handling of (tuple) = f(...) when solving non-linear Backend trunk Future defect probably noone new 2014-02-21T16:39:13Z 2017-11-14T22:08:53Z "Examples like following were handled wrong in SimCodeUtil: {{{ model TupleNonLinear function ftest input Real a; output Real b; output Integer c; algorithm b := 0; for i in {1} loop //prevent inlining b := b + sin(a); c := integer(a); end for; end ftest; Real a; Integer c; Real x,z; equation der(x) = sin(a + time); (x,c) = ftest(a); z = if c>=1 then 10 else 0; annotation (experiment(StopTime=2)); end TupleNonLinear; }}} We try to solve the equation (x,c) = ftest(a) non-linear for {a,c} but actually only a should be solved non-linear and c can be calculated then directly." Willi Braun 2605 Can MathML blocks be nested in the XML dump? Backend trunk Future defect probably noone new 2014-03-01T03:52:18Z 2017-11-14T22:08:53Z "Matt and I were looking at the XMLDump code this afternoon, and we think there's an error, which would be fixed by this change. What we're seeing is blocks embedded in other blocks, which seems wrong. We think the wrong function is being called to express the vector's value. " Bill Janssen 2618 Reinitial in algorithm section also continuos relations Backend trunk Future defect Karim Adbdelhak assigned 2014-03-13T17:27:32Z 2019-04-04T23:24:46Z "In the following example, we introduce a memory in algorithms, since while the continuous integration relations are fixed. But they need to re-initialized for every execution. {{{ model BreakFor //extends Icons.TestCase; Real x; algorithm x := 1; for i in 1:10 loop x := x * 2; //print(""loop= "" +& intString(i) +&"" x == "" +& realString(x) +& ""\n""); if x > 25 then break; end if; end for; //print("" x == "" +& realString(x) +& ""\n""); assert(x >= 32, ""x was not set correctly.""); annotation ( __ModelicaAssociation(TestCase(shouldPass = true, section = {""11.2.4""})), experiment(StopTime = 0.01), Documentation( info = ""Tests the functionality of 
break
inside a for-loop."")); end BreakFor; }}}" Willi Braun 2664 "Probelm with handling ""when statement"" in an FMU" FMI trunk Future defect Willi Braun reopened 2014-04-13T13:22:37Z 2020-01-13T16:56:04Z "There has been a problem with models involving ""when statements"". The modelica code of these models work fine but the problem manifests itself once the model is exported as an FMU and then re-imported for simulation. Running simulations after re-importing the FMU show that when conditions in the model never get fired at all." uzahsan@… 2670 Possible support for Modelica_LinearSystems2 Frontend trunk Future defect somebody new 2014-04-19T02:08:42Z 2017-11-14T22:08:53Z "The library: Modelica_LinearSystems2 https://github.com/modelica/Modelica_LinearSystems2 is used quite a lot for model analysis and various plots (bode, etc.) This ticket is to investigate if is possible to support it. As far as I've seen for example having a look at this file: https://github.com/modelica/Modelica_LinearSystems2/blob/release/Modelica_LinearSystems%202.3.1/Utilities/Import/linearize2.mo is that it should be possible but we would need some support for some of Dymola-specific annotations and API: - translateModel / {{{Dialog(__Dymola_translatedModel)}}} - linearization (we already support it but with some differences) - SetVariable/SetParameter (we already support these but with some differences) - simulateModel (we already support it but with some differences) - readMatrixSize/readMatrix/readStringMatrix (we already support these but with some differences) - {{{annotation (__Dymola_interactive=true)}}}: not sure what this does Besides the above things we need plotting support from Modelica code as for example used in this file: https://github.com/modelica/Modelica_LinearSystems2/blob/release/Modelica_LinearSystems%202.3.1/Utilities/Plot/diagram.mo - createPlot - plotArray - more plot functions from the library I guess these plot functions need to be combined with annotation {{{(__Dymola_interactive=true)}}} somehow to be able to display the plots. " Adrian Pop 2717 Exporting a model as XML code file not completed Code Generation Future defect Lennart Ochel new 2014-06-05T05:33:55Z 2017-11-14T22:08:53Z "It is not clear when XML code files are generated. When exporting model of Modelica.Fluid.Examples.TraceSubstances.RommCO2 as XML,the following lines are numerously generated in the XML code file. 1. 2. #error ""[CodegenXML.tpl:2147:14-2147:14] Unknown expression: Modelica.Media.IdealGases.Common.DataRecord(#SHARED_LITERAL_35(String)#, 0.01801528, -13423382.81725291, 549760.6476280135, 1000.0, #SHARED_LITERAL_37(Real[7])#, #SHARED_LITERAL_38(Real[2])#, #SHARED_LITERAL_39(Real[7])#, #SHARED_LITERAL_40(Real[2])#, 461.5233290850878)"" It is not cmopleted to export model as XML." carp 2730 "Unproper behaviour of function ""dumpXMLDAE"" for ""stateSpace"" translationLevel" Code Generation trunk Future defect somebody assigned 2014-06-16T13:16:46Z 2017-11-14T22:08:53Z "When calling function ""dumpXMLDAE"" with ""stateSpace"" translationLevel, in dumped XML file /dae/zeroCrossingList/zeroCrossingElement/involvedEquations/equationId contains id of unsorted equation." anonymous 2756 OM reports an error in the C code it creates Code Generation trunk Future defect Mahder Alemseged Gebremedhin accepted 2014-07-18T15:51:34Z 2017-11-14T22:08:53Z "If I run (using OM r20199) ""gridTest21"" of the enclosed package ""AutoCreateBug"" I get the following message: {{{ ""C:\Programmi\OpenModelica1.9.1Nightly\\MinGW\bin\mingw32-make.exe"" -f AutoCreateBug.gridTest21.makefile gcc -falign-functions -msse2 -mfpmath=sse -I""C:/Programmi/OpenModelica1.9.1Nightly//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o AutoCreateBug.gridTest21.o AutoCreateBug.gridTest21.c AutoCreateBug.gridTest21.c: In function 'AutoCreateBug_gridTest21_eqFunction_27': AutoCreateBug.gridTest21.c:458: error: expected expression before 'modelica_integer' AutoCreateBug.gridTest21.c:458: error: expected ')' before '$Pi$rB$Pv' AutoCreateBug.gridTest21.c:460: error: expected expression before 'modelica_integer' AutoCreateBug.gridTest21.c:460: error: expected ')' before '$Pi$rB$Pv' mingw32-make: *** [AutoCreateBug.gridTest21.o] Error 1 Compilation process exited with code 2 }}} It seems that OM creates for this model a C file that is invalid. " massimo ceraolo 2774 Vectors are not detected as discrete variables Backend trunk Future defect Willi Braun new 2014-08-08T10:05:25Z 2017-11-14T22:08:53Z "The test whenDiscreteForLoop currently contains code like this: {{{#!mo model testWhenLoopA1 Real x; discrete Real d[2]; Integer n = 2; equation der(x) = x+1; algorithm when sample(0,0.1) then for i in 1:n loop d[i] := d[i]+1; end for; end when; end testWhenLoopA1; }}} The discrete keyword was added by me because OpenModelica does not add it for vectors assigned in a when-statement." Martin Sjölund 2785 Check of protected variables is not made when using replaceable/redeclare (again) Frontend trunk Future defect Per Östlund accepted 2014-08-22T11:24:04Z 2014-09-01T12:14:39Z "The erroneous model `C2` in #1060 currently validates without any warning. Repeating the code for ease of reference: {{{ class C1 protected replaceable parameter Real r=3.14; end C1; model C2 replaceable parameter C1 x1(redeclare replaceable Integer r=3); end C2; }}} (It is not obvious to me that the test ''flattening/modelica/redeclare/RedeclareVisibility2.mo'' is actually testing this properly; to me it looks like a flattening test with incorrect expected result, see #2784.)" Henrik Tidefelt 2788 Enumerated types causing errors Code Generation trunk Future defect Willi Braun assigned 2014-08-23T23:45:19Z 2014-08-25T07:25:34Z "When I attempt to simulate the model Test.SimpleEngine_pass from the attached file, I get the follow error. This model works with omc r21000, but does not work with the latest nightly version of omc r21957. I see similar errors in all of my models that use enumerated types. Warning: The initial conditions are not fully specified. Use +d=initialization for more information. Error: Error building simulator. Build log: clang -fPIC -I""/usr/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o G18802.o G18802.c clang -fPIC -I""/usr/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o G18802_functions.o G18802_functions.c clang -fPIC -I""/usr/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o G18802_records.o G18802_records.c clang -fPIC -I""/usr/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o G18802_01exo.o G18802_01exo.c clang -fPIC -I""/usr/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o G18802_02nls.o G18802_02nls.c G18802_02nls.c:50:43: error: no member named 'nominal' in 'struct INTEGER_ATTRIBUTE' nlsData->nominal[i] = $P$ATTRIBUTE$PReq.nominal; ~~~~~~~~~~~~~~~~~ ^ G18802_02nls.c:70:43: error: no member named 'nominal' in 'struct INTEGER_ATTRIBUTE' nlsData->nominal[i] = $P$ATTRIBUTE$PReq.nominal; ~~~~~~~~~~~~~~~~~ ^ 2 errors generated. make: *** [G18802_02nls.o] Error 1 " klenk@… 2799 Missing enumeration type declaration in DAEXMLdump *unknown* trunk Future defect somebody new 2014-09-02T18:40:16Z 2014-10-25T22:03:46Z " I have an example where there is a enumeration type declared in a library: a/b/c/d/e.mo: type e = enumeration( f,g,h ) ... And a DAEXML dump of a model that uses the constants: a.b.c.d.e.f a.b.c.d.e.g but the XML file does not contain any information about the enumeration type declaration. So, from the XML file itself, it is not possible to infer if a.b.c.d.e.f maps to 1 or 2 or something else. " ashish.x.tiwari@… 2804 codegen error if one is using Modelica.Utilities.Streams.readLine Code Generation trunk Future defect Lennart Ochel new 2014-09-05T16:31:34Z 2014-09-15T13:28:03Z "Models that try to use the function Modelica.Utilities.Streams.readLine are failing with a code generation error. {{{ model test /* function readL input String fileName; input Integer line; output String string; algorithm string := Modelica.Utilities.Streams.readLine(fileName, line); end readL; function readF input String fileName; output String stringVector[Modelica.Utilities.Streams.countLines(fileName)]; algorithm for i in 1:size(stringVector, 1) loop stringVector[i] := readL(fileName, i); end for; Modelica.Utilities.Streams.close(fileName); end readF; */ parameter String fileName = \""./test.txt\""; parameter Integer N = Modelica.Utilities.Streams.countLines(fileName); parameter String file[N] = Modelica.Utilities.Streams.readFile(fileName); // works // parameter String file[N] = readF(fileName); end test; }}} Somehow the types of an array inside of DAE.STMT_TUPLE_ASSIGN are not generate correct. That code the is generated with the following line works, but then we get other issue. The question is which type should passed to the function contextArrayReferenceCrefAndCopy. {{{#!diff Index: Compiler/Template/CodegenC.tpl =================================================================== --- Compiler/Template/CodegenC.tpl (revision 22125) +++ Compiler/Template/CodegenC.tpl (working copy) @@ -4734,7 +4736,7 @@ match ty case T_ARRAY(__) then let &varCopyAfter = buffer """" - let var = tempDecl(""base_array_t"", &varDecls) + let var = tempDecl(expTypeArrayIf(ty), &varDecls) let lhs = writeLhsCref(e, var, context, &varCopyAfter, &varDecls, &auxFunction) let &varCopy += if lhs then '<%lhs%><%\n%>' else error(sourceInfo(), 'Got empty statement from writeLhsCref(<%printExpStr(e)%>)') let &varCopy += varCopyAfter @@ -7070,24 +7081,28 @@ case STMT_TUPLE_ASSIGN(exp=CALL(attr=CALL_ATTR(ty=T_TUPLE(tupleType=ntys)))) then let &preExp = buffer """" let &postExp = buffer """" let lhsCrefs = (List.rest(expExpLst) |> e => match e case ARRAY(array={}) case CREF(componentRef=WILD(__)) then "", NULL"" - case CREF(componentRef=cr,ty=ty) then ("", &"" + contextArrayReferenceCrefAndCopy(cr, e, ty, context, varDecls, postExp, &auxFunction)) + case CREF(componentRef=cr,ty=ty) then ("", &"" + contextArrayReferenceCrefAndCopy(cr, e, crefLastType(cr), context, varDecls, postExp, &auxFunction)) // Crazy DAE.CALL on lhs? Yup, we apparently generate those. TODO: Don't generate those crazy things! case CALL(attr=CALL_ATTR(ty=ty)) then ("", &"" + contextArrayReferenceCrefAndCopy(makeUntypedCrefIdent(""#error""), e, ty, context, varDecls, postExp, auxFunction)) else error(sourceInfo(), 'Unknown expression to assign to: <%printExpStr(e)%>')) // The tuple expressions might take fewer variables than the number of outputs. No worries. let lhsCrefs2 = lhsCrefs + List.fill("", NULL"", intMax(0,intSub(listLength(ntys),listLength(expExpLst)))) let ret = daeExpCallTuple(exp, lhsCrefs2, context, &preExp, &varDecls, &auxFunction) let &preExp += match expExpLst case ARRAY(array={})::_ case CREF(componentRef=WILD(__))::_ then '<%ret%>;<%\n%>' - case (e as CREF(componentRef=cr,ty=ty))::_ then '<%contextArrayReferenceCrefAndCopy(cr, e, ty, context, varDecls, postExp, auxFunction)%> = <%ret%>;<%\n%>' + case (e as CREF(componentRef=cr,ty=ty))::_ then '<%contextArrayReferenceCrefAndCopy(cr, e, crefLastType(cr), context, varDecls, postExp, auxFunction)%> = <%ret%>;<%\n%>' // Crazy DAE.CALL on lhs? Yup, we apparently generate those. TODO: Don't generate those crazy things! case (e as CALL(attr=CALL_ATTR(ty=ty)))::_ then '<%contextArrayReferenceCrefAndCopy(makeUntypedCrefIdent(""#error""), e, ty, context, varDecls, postExp, auxFunction)%> = <%ret%>;<%\n%>' case e::_ then error(sourceInfo(), 'Unknown expression to assign to: <%printExpStr(e)%>') ('/* tuple assignment */<%\n%>' + preExp + postExp) case STMT_TUPLE_ASSIGN(exp=MATCHEXPRESSION(__)) then let &preExp = buffer """" let &afterExp = buffer """" }}}" Willi Braun 2807 Disallow illegal prefixes in records Frontend trunk Future defect Per Östlund accepted 2014-09-08T10:26:27Z 2017-11-14T22:08:53Z The prefixes input, output, inner, outer, stream and flow are not allowed inside records, but we do not check this currently. Per Östlund 2809 Detect and optimize useless tuple construction Frontend trunk Future defect Martin Sjölund assigned 2014-09-09T05:40:42Z 2014-09-09T08:43:49Z "The following pattern occurs often in the code, and constructs a new tuple (b,c) even though this is costly and not necessary: {{{#!mo case (a,(b,c)) then (a,(b,c)); }}} It should be possible to detect this an optimize it away." Martin Sjölund 2820 initialization of discrete states Backend trunk Future defect Lennart Ochel accepted 2014-09-12T15:24:26Z 2014-09-12T15:24:32Z "The initialization problem of the following model is not handled correctly: {{{#!mo model PreMatrix Integer x[2,2] = integer(time*fill(1,2,2)); Integer y[2,2]; algorithm for i in 1:size(x,1),j in 1:size(x,2) loop y[i,j] := pre(x[i,j]); end for; end PreMatrix; }}} The initialization passes without any message, but there should be some warnings about missing fixed start attribute for discrete states: {{{ Warning: Assuming fixed start value for the following 4 variables: x[2,2]:DISCRETE(fixed = false ) .PreMatrix, .Integer type: Integer x[2,1]:DISCRETE(fixed = false ) .PreMatrix, .Integer type: Integer x[1,2]:DISCRETE(fixed = false ) .PreMatrix, .Integer type: Integer x[1,1]:DISCRETE(fixed = false ) .PreMatrix, .Integer type: Integer }}}" Lennart Ochel 2825 Override of Q-Idents Command Prompt Environment trunk Future defect somebody new 2014-09-18T06:32:49Z 2014-09-18T07:09:24Z "The simulation command line flag {{{-override}}} is quite useful. Unfortunately, it is not working for Q-Idents, because inverted commas are not passed to the simulation. Has anyone an idea how to fix it? The issue can be tried using the following example script. {{{#!mo loadString("" model foo Real x(start=1.0); Real 'y'(start=1.0); parameter Real p=1.0; equation der(x) = p; der('y') = p; end foo; ""); getErrorString(); simulate(foo, stopTime=0.0); getErrorString(); val(x, 0.0); getErrorString(); val('y', 0.0); getErrorString(); simulate(foo, stopTime=0.0, simflags=""-override=p=-2,x=0,\'y\'=0 -lv=LOG_SOLVER""); getErrorString(); val(x, 0.0); getErrorString(); val('y', 0.0); getErrorString(); }}} {{{x}}} is working as expected, whereas {{{'y'}}} is not. BTW: Whitespaces (and probably other strange valid characters) in Q-Idents will not work too." Lennart Ochel 2828 Function partial application sometimes results in type mismatch MetaModelica trunk Future defect Martin Sjölund new 2014-09-18T14:41:45Z 2014-09-18T14:41:45Z "Defining map1Fold like this causes an error: {{{#!mo function mapFold ""Takes a list, an extra argument and a function. The function will be applied to each element in the list, and the extra argument will be passed to the function and updated."" input list inList; input FuncType inFunc; input FT inArg; output list outList := {}; output FT outArg := inArg; partial function FuncType input TI inElem; input FT inArg; output TO outResult; output FT outArg; end FuncType; protected TO res; algorithm for e in inList loop (res, outArg) := inFunc(e, outArg); outList := res :: outList; end for; outList := listReverse(outList); end mapFold; public function map1Fold ""Takes a list, an extra argument, an extra constant argument, and a function. The function will be applied to each element in the list, and the extra argument will be passed to the function and updated."" input list inList; input FuncType inFunc; input ArgT1 inConstArg; input FT inArg; output list outList := {}; output FT outArg := inArg; partial function FuncType input TI inElem; input ArgT1 inConstArg; input FT inArg; output TO outResult; output FT outArg; end FuncType; algorithm (outList, outArg) := mapFold(inList, function inFunc(inConstArg = inConstArg), inArg); end map1Fold; }}} The error is: {{{ Error: Type mismatch in pattern outList expression type: list> pattern type: list> }}} I.e. it thinks the types are different when they should be the same." Per Östlund 2847 OM recognizes an algebraic loop where there is none. Backend trunk Future defect somebody new 2014-09-28T11:56:55Z 2017-11-14T22:08:53Z "During initiallization OM (R22462) reports an algebraic loop where there is actually none. In the section of the code, where the error is reported, parameters are passed down from the reactor object to the inner casing, the pipe and the outer casing. Also there should be no need for iteration. This error did not occur in R22052, although the initialization crashed with another error. {{{ simulate(MetalHydrideStorage.M, stopTime=1000, simflags="""", method=""dassl"") record SimulationResult resultFile = """", simulationOptions = ""startTime = 0.0, stopTime = 1000.0, numberOfIntervals = 500, tolerance = 1e-006, method = 'dassl', fileNamePrefix = 'MetalHydrideStorage.M', options = '', outputFormat = 'mat', variableFilter = '.*', cflags = '', simflags = ''"", messages = ""Simulation execution failed for model: MetalHydrideStorage.M "", timeFrontend = 47.74968853897553, timeBackend = 38.34561539851902, timeSimCode = 3.609517678727312, timeTemplates = 6.031960890188393, timeCompile = 21.9803886463405 end SimulationResult; Notification: It was not possible to analyze the given system symbolically, because the relevant equations are part of an algebraic loop. This is not supported yet. Warning: Assuming redundant initial conditions for the following 12 initial equations: reactor.outerCasing.s = reactor.s_oCasing reactor.pipe.crossArea = 3.141592653589793 * ((0.035 - reactor.s_oCasing) ^ 2.0 - (0.02755 + reactor.s_iCasing) ^ 2.0) reactor.pipe.crossAreas[1] = reactor.pipe.crossArea reactor.pipe.crossAreas[2] = reactor.pipe.crossArea reactor.pipe.crossAreas[3] = reactor.pipe.crossArea reactor.pipe.crossAreas[4] = reactor.pipe.crossArea reactor.pipe.crossAreas[5] = reactor.pipe.crossArea reactor.outerCasing.T[4] = reactor.outerCasing.T_start initialState.T = T0 reactor.innerCasing.area_h = 1.570796326794897 * (0.0007590025000000001 + (0.02755 + reactor.s_iCasing) ^ 2.0) * reactor.h_Casing reactor.outerCasing.area_h = 1.570796326794897 * (0.001225 + (0.035 - reactor.s_iCasing) ^ 2.0) * reactor.h_Casing reactor.outerCasing.T_start = reactor.Twall_start Warning: Iteration variables with default zero start attribute in torn nonlinear equation system: reactor.outerCasing.s:VARIABLE() = reactor.s_oCasing ""Wall thickness"".MetalHydrideStorage.M, .MetalHydrideStorage.Setup.Reactor, .MetalHydrideStorage.Setup.Wall, .Modelica.SIunits.Length type: Real reactor.outerCasing.area_h:VARIABLE() = 1.570796326794897 * (0.001225 + (0.035 - reactor.s_iCasing) ^ 2.0) * reactor.h_Casing ""Heat transfer area"".MetalHydrideStorage.M, .MetalHydrideStorage.Setup.Reactor, .MetalHydrideStorage.Setup.Wall, .Modelica.SIunits.Area type: Real reactor.innerCasing.area_h:VARIABLE() = 1.570796326794897 * (0.0007590025000000001 + (0.02755 + reactor.s_iCasing) ^ 2.0) * reactor.h_Casing ""Heat transfer area"".MetalHydrideStorage.M, .MetalHydrideStorage.Setup.Reactor, .MetalHydrideStorage.Setup.Wall, .Modelica.SIunits.Area type: Real Warning: Iteration variables with default zero start attribute in torn nonlinear equation system: reactor.pipe.crossAreas[6]:VARIABLE() = reactor.pipe.crossArea ""cross flow areas of flow segments"".MetalHydrideStorage.M, .MetalHydrideStorage.Setup.Reactor, .Modelica.Fluid.Pipes.DynamicPipe, .Modelica.SIunits.Area type: Real reactor.pipe.dimensions[1]:VARIABLE() = 4.0 * reactor.pipe.crossArea / reactor.pipe.perimeter ""hydraulic diameters of flow segments"".MetalHydrideStorage.M, .MetalHydrideStorage.Setup.Reactor, .Modelica.Fluid.Pipes.DynamicPipe, .Modelica.SIunits.Length type: Real reactor.pipe.dimensions[2]:VARIABLE() = 4.0 * reactor.pipe.crossArea / reactor.pipe.perimeter ""hydraulic diameters of flow segments"".MetalHydrideStorage.M, .MetalHydrideStorage.Setup.Reactor, .Modelica.Fluid.Pipes.DynamicPipe, .Modelica.SIunits.Length type: Real reactor.pipe.dimensions[3]:VARIABLE() = 4.0 * reactor.pipe.crossArea / reactor.pipe.perimeter ""hydraulic diameters of flow segments"".MetalHydrideStorage.M, .MetalHydrideStorage.Setup.Reactor, .Modelica.Fluid.Pipes.DynamicPipe, .Modelica.SIunits.Length type: Real reactor.pipe.dimensions[4]:VARIABLE() = 4.0 * reactor.pipe.crossArea / reactor.pipe.perimeter ""hydraulic diameters of flow segments"".MetalHydrideStorage.M, .MetalHydrideStorage.Setup.Reactor, .Modelica.Fluid.Pipes.DynamicPipe, .Modelica.SIunits.Length type: Real reactor.pipe.dimensions[5]:VARIABLE() = 4.0 * reactor.pipe.crossArea / reactor.pipe.perimeter ""hydraulic diameters of flow segments"".MetalHydrideStorage.M, .MetalHydrideStorage.Setup.Reactor, .Modelica.Fluid.Pipes.DynamicPipe, .Modelica.SIunits.Length type: Real reactor.pipe.dimensions[6]:VARIABLE() = 4.0 * reactor.pipe.crossArea / reactor.pipe.perimeter ""hydraulic diameters of flow segments"".MetalHydrideStorage.M, .MetalHydrideStorage.Setup.Reactor, .Modelica.Fluid.Pipes.DynamicPipe, .Modelica.SIunits.Length type: Real reactor.pipe.crossAreas[1]:VARIABLE() = reactor.pipe.crossArea ""cross flow areas of flow segments"".MetalHydrideStorage.M, .MetalHydrideStorage.Setup.Reactor, .Modelica.Fluid.Pipes.DynamicPipe, .Modelica.SIunits.Area type: Real reactor.pipe.crossAreas[2]:VARIABLE() = reactor.pipe.crossArea ""cross flow areas of flow segments"".MetalHydrideStorage.M, .MetalHydrideStorage.Setup.Reactor, .Modelica.Fluid.Pipes.DynamicPipe, .Modelica.SIunits.Area type: Real reactor.pipe.crossAreas[3]:VARIABLE() = reactor.pipe.crossArea ""cross flow areas of flow segments"".MetalHydrideStorage.M, .MetalHydrideStorage.Setup.Reactor, .Modelica.Fluid.Pipes.DynamicPipe, .Modelica.SIunits.Area type: Real reactor.pipe.crossAreas[5]:VARIABLE() = reactor.pipe.crossArea ""cross flow areas of flow segments"".MetalHydrideStorage.M, .MetalHydrideStorage.Setup.Reactor, .Modelica.Fluid.Pipes.DynamicPipe, .Modelica.SIunits.Area type: Real reactor.pipe.crossAreas[4]:VARIABLE() = reactor.pipe.crossArea ""cross flow areas of flow segments"".MetalHydrideStorage.M, .MetalHydrideStorage.Setup.Reactor, .Modelica.Fluid.Pipes.DynamicPipe, .Modelica.SIunits.Area type: Real }}}" e1026754@… 2849 "Wrong flattening of ""inner outer output""" Frontend trunk Future defect Adrian Pop accepted 2014-09-29T15:57:42Z 2014-09-29T16:11:32Z " In the following model (also attached) the inner variable `v` declared in model `Test` is assigned to in model `B` where it is declared as `outer output`. `B` is instantiated in `A` and `A` is instantiated in `Test`. In model `A` variable `v` is declared as `inner outer output`. {{{#!mo package Bug model B outer output Real v; equation v = time; end B; model A inner outer output Real v; Real y2; B b; equation y2 = v; end A; model Test inner Real v; Real y1; A a; equation y1 = v; end Test; end Bug; }}} The model flattens, but the generated system of equations is wrong (therefore, it doesn't simulate). The flattened Modelica is: {{{ class Bug.Test Real v; Real y1; Real a.v; Real a.y2; equation a.v = time; a.y2 = v; y1 = v; end Bug.Test; }}} Note that the equality constraint between `v` and `a.v` is lost. Adding an additional constraint, e.g., `Real a.v = v` would make the flattened code valid. Alternatively, `a.v` could be substituted by `v` everywhere. " Bernhard Thiele 2852 Use the same C-code for identical functions Code Generation trunk Future defect Martin Sjölund accepted 2014-09-30T07:53:29Z 2014-09-30T12:02:00Z "With calling of functions through components, identical functions are often generated. The C compiler will generate equivalent code for both, which is not desirable. We should figure out which functions are equivalent and replace calls to one with calls to another (or simply alias them via function pointer). {{{#!mo model N function f input Real r; output Real o := r; end f; end N; model M N n1,n2; Real r1 = n1.f(time), r2 = n2.f(time); end M; }}} A Hash from DAE.Function to Absyn.Path should be sufficient (or String->Path and manually DAEDump the function to speed up any hash conflicts)." Martin Sjölund 2863 NFSCodeDependency removes used constant Frontend trunk Future defect Per Östlund assigned 2014-10-06T10:05:43Z 2014-10-06T10:07:52Z "It seems that when you have redeclares for types of the components in some cases some of the constants from them are removed. See attached model. Constant scale in Delta disappears on saveTotalSCode. " Adrian Pop 2881 NFScodeDependency stack overflow Frontend trunk Future defect Per Östlund reopened 2014-10-10T09:32:53Z 2017-11-14T22:08:53Z "FCSys.Assemblies.Cells.Cell gives a stack overflow in the dependency analysis (so I cannot upload the total model). https://github.com/kdavies4/FCSys/archive/master.zip {{{#!mo loadModel(FCSys);getErrorString(); saveTotalModel(""total.mo"",FCSys.Assemblies.Cells.Cell);getErrorString(); }}}" Martin Sjölund 2895 Error translating new Medium package Frontend trunk Future defect Adrian Pop assigned 2014-10-16T06:33:47Z 2016-04-20T14:36:45Z "Hi, I wrote a package for a new Medium which I need to run my models. It is a mixture of table-based incompressible liquids. I have tested it on a very simple model (two incompressible liquids, two Boundary_pT each containing a different fluid, two valves, a pipe where the two liquids are mixed, and a Boundary_pT at atmospheric pressure) and I am able to run it. When I just change a few parameters or I increase the complexity of the model (for example by adding a pump) the model crashes. Now I have tried to test my Medium using Modelica.Media.Examples.Tests.Components.PartialTestModel and I got the following error message: [CodegenC.tpl:10494:39-10494:39] Error: Template error: Unknown dimensions may not be part of generated code. This is most likely an error on the part of OpenModelica. Please submit a detailed bug-report. What shall I do? Thanks in advance for your help. Regards, Andrea. " andreabr@… 2923 Expressions get simplified even if flag noSimplify is used Frontend trunk Future defect Adrian Pop new 2014-10-22T08:19:06Z 2014-10-22T10:04:21Z "I know the flag noSimplify is a very old one. This could either mean that it is very well tested or that it is long-forgotten and no one cares about it. I can see that is does something in some cases, but it does not what I expect for some simple examples. Please check out the following one: {{{#!mo model foo Real a; Real b; equation a = sin(time); b = 0.3 * a + 0.7 * a; end foo; }}} If I instantiate model foo without using the flag noSimplify, I get the expected result: {{{#!mo class foo Real a; Real b; equation a = sin(time); b = a; end foo; }}} But, if I run the same with noSimplify enabled, I still get the same result. I would expect that in that case the expressions should remain as they are written in the model." Lennart Ochel 2924 Extending a model fails Frontend trunk Future defect Adrian Pop accepted 2014-10-22T13:21:25Z 2021-12-08T14:07:00Z "I have a model (unfortunately, proprietary, so i can't put it here) that I have been working with that is now causing me some difficulties. The base model is working fine. I then extended that model, with some additions, and it is also working fine. The strange difficulty that I am running into, is that if I extend that model, I run into errors. And, the occur, even if I do nothing but this: model Model3 extends Model2; end Model3; If I check Model2, I see that it is balanced with 894 equations and 894 variables. And it runs just fine. If I check Model3 (created with nothing but extends, as above, and no actual additions or changes) it shows 1264 equations and 1571 variables (!?!?). If I try to run this model, I see a bunch of ""Model is structurally singular, error found sorting equations"", ""Internal error pre-optimization model clockPartioning failed"", ""Too many equations, over-determined system. The model has 1264 equations and 894 variables"" I don't see how extending a model, with no changes, or even just a minor addition, can cause the addi4tion of hundreds of equations and variables. " Adam Dershowitz 2929 Encapsulation does not work Frontend trunk Future defect Adrian Pop new 2014-10-24T15:13:32Z 2014-10-24T15:13:32Z "Remove ""import DAE"" from Static.mo - omc compiles fine, but should not since DAE.ICONST, etc should not be able to perform lookup on DAE." Martin Sjölund 2931 Bootstrapped compiler should check undefined variables in if branches MetaModelica trunk Future defect Adrian Pop assigned 2014-10-27T02:15:28Z 2017-11-14T22:08:53Z "For example in CevalFunction.evaluateWhileStatement (modified on line 1438): {{{#!mo case (_, _, _, _, _, st) equation (cache, Values.BOOL(boolean = b), st) = cevalExp(inCondition, inCache, inEnv, st); if b then (cache, env, loop_ctrl, st) = evaluateStatements(inStatements, cache, inEnv, st); (cache, env, loop_ctrl, st) = evaluateWhileStatement(inCondition, inStatements, cache, env, loop_ctrl, st); else loop_ctrl = NEXT(); // env = inEnv; end if; then (cache, env, loop_ctrl, st); }}} env is not defined in the else branch. This will compile code and for some models (i think it was MoistAir) will just crash. Comment out {{{env = inEnv;}}} in the else branch and run the testsuite. " Adrian Pop 2934 Flattening(?) of simple model with external function fails Backend trunk Future defect somebody new 2014-10-27T18:28:44Z 2014-10-27T20:00:31Z "In the attached tester OpenModelica seems to fail to flatten the model. Possibly some issue with structural constants/parameters in records??? Tested with rev 22812." Christian Schulze 2948 OMC on Windows does not support non-ascii directories Interactive Environment trunk Future defect somebody new 2014-11-01T01:21:53Z 2014-11-01T02:40:26Z "Just see the latest crash report: https://dev.openmodelica.org/omeditcrashreports/tmp/2014-11-01_02:03:13-omeditcommunication.log Seems the user name contains non-ascii chars and OMC chdir cannot handle it. Maybe we need iconv on that or something. OMEdit is of course affected because of this." Adrian Pop 2954 package.order encoded UTF-8 with Byte Order Mark (BOM) is not properly handled Frontend trunk Future defect somebody new 2014-11-03T12:10:14Z 2017-11-14T22:08:53Z "When we read package.order encoded in UTF-8 with BOM the first class name is mangled, if is {{{MassFlowRate}}} then the name we read is: {{{MassFlowRate}}} which will make the library un-loadable. " Adrian Pop 2967 Pantelides fails for arrays Backend trunk Future defect somebody new 2014-11-06T07:47:57Z 2017-11-14T22:08:53Z "Pantelides fails for the following models using arrays: {{{#!mo package ModelicaCompliance ""A semantics compliance suite for the Modelica language"" extends Icons.TestPackage; package Algorithms extends Icons.TestPackage; package For extends Icons.TestPackage; model BoolRange extends Icons.TestCase; Boolean[Boolean] b; algorithm for i in false:true loop b[i] := i; end for; assert(b[false] == false, ""b[false] was not set correctly.""); assert(b[true] == true, ""b[true] was not set correctly.""); annotation(__ModelicaAssociation(TestCase(shouldPass = true, section = {""11.2.2""})), experiment(StopTime = 0.01)); end BoolRange; end For; end Algorithms; package Icons model TestCase end TestCase; package TestPackage end TestPackage; end Icons; annotation(version = ""3.2""); end ModelicaCompliance; model BoolRange_total extends ModelicaCompliance.Algorithms.For.BoolRange; annotation(__ModelicaAssociation(TestCase(shouldPass = true, section = {""11.2.2""})), experiment(StopTime = 0.01)); end BoolRange_total; }}} {{{#!mo package ModelicaCompliance ""A semantics compliance suite for the Modelica language"" extends Icons.TestPackage; package Algorithms extends Icons.TestPackage; package For extends Icons.TestPackage; model EnumRange extends Icons.TestCase; type TwoEnums = enumeration(one, two); TwoEnums[TwoEnums] te; algorithm for e in TwoEnums.one:TwoEnums.two loop te[e] := e; end for; assert(te[TwoEnums.one] == TwoEnums.one, ""te[TwoEnums.one] was not set correctly.""); assert(te[TwoEnums.two] == TwoEnums.two, ""te[TwoEnums.two] was not set correctly.""); annotation(__ModelicaAssociation(TestCase(shouldPass = true, section = {""11.2.2""})), experiment(StopTime = 0.01)); end EnumRange; end For; end Algorithms; package Icons model TestCase end TestCase; package TestPackage end TestPackage; end Icons; annotation(version = ""3.2""); end ModelicaCompliance; model EnumRange_total extends ModelicaCompliance.Algorithms.For.EnumRange; annotation(__ModelicaAssociation(TestCase(shouldPass = true, section = {""11.2.2""})), experiment(StopTime = 0.01)); end EnumRange_total; }}}" Martin Sjölund 2969 differentiate delay expr Backend trunk Future defect Andreas Heuermann assigned 2014-11-07T01:08:52Z 2019-09-30T12:49:05Z "Differentiation of delay expression is not implementet, yet. All delay expression get an index in BackendDAECreate, but we don't know the next index while differentiation." Willi Braun 2997 Zero-crossings in algorithm sections Backend trunk Future defect somebody new 2014-11-24T08:59:05Z 2014-11-24T08:59:05Z "Events are not triggered for some algorithm sections. The example from r23518 illustrates the issue: {{{#!mo model ZeroCrossingAlg Real a; Integer d; algorithm a := 2*time; d := if a > 1.0 then 1 else 2; a := 0.5; end ZeroCrossingAlg; }}} " Lennart Ochel 3004 OMOptim optimization is not working OMOptim trunk Future defect Hubert Thieriot new 2014-11-26T14:08:01Z 2014-11-26T14:08:01Z "When trying to use OmOptim (0.9.20750, r23549) under Ubuntu 12.04 and 14.04, 32bit, I failed using a very simple example. I attached the sample file to this posting. The procedure for running an OMOptim optimization is described in https://openmodelica.org/svn/OpenModelica/trunk/doc/OMOptim/OMOptimUsersGuide.pdf * First, I created a new project. * Then I loaded the sample file SimpleOpt.mo as well as MSL 3.2.1 and Modelica Services. * I expected to see the available Modelica variables as described in OMOptimUsersGuide.pdf. But no variable and parameter is shown and there is no option in the context menu to load the variable list." Christian Kral 3008 Error in type inference when using function passed to function Frontend Future defect Per Östlund assigned 2014-11-28T12:52:38Z 2014-11-28T13:09:44Z "Consider the package Test: {{{ package Test partial function myFunBase input Real u; output Real y1; output Real y2; end myFunBase; function myFun extends myFunBase; algorithm y1 := u; y2 := 2 * u; end myFun; function myFun2 input myFunBase f; output Real y; protected Real x1,x2; algorithm (x1,x2) := f(2); Y := x1 + x2; end myFun2; model Test Real x(start = 1.0); Real y; equation x = -der(x); y = myFun2(myFun); end Test; end Test; }}} when validating Test.Test in OMEdit one gets: {{{ ""[:21:5-21:20:writable] Error: Type mismatch in assignment in (x1, x2) := f(#(2.0)) of (Real, Real) := (#Real, #Real) Error: Error occurred while flattening model Test.Test "" }}} Tested with ""OpenModelica 1.9.1+dev (r22423) (Bootstrapping vers""." carlj@… 3015 OMEdit Plots are not correct *unknown* trunk Future defect Adeel Asghar assigned 2014-12-04T18:22:29Z 2016-04-13T10:33:11Z "It seems that something is strange with plotting data in some cases. I am running 23640. To recreate: Run ThermoPower->Test->TestTurboJetInertia it seems to compile and simulate just fine. Then, for example, plot Inertia1->w and the vertical scale is just 523 repeated, and the plot shows multiple steps. But, this should show an exponential decay when there is a fuel reduction at 1 sec. If I do the same thing with release 1.9.1 it does show an exponential decay at 1 sec, although the vertical scale still just shows 523 repeated, so the vertical scale appears to be wrong in 1.9.1 as well." Adam Dershowitz 3024 Support for if equations inside when equations Backend trunk Future defect somebody new 2014-12-10T16:05:35Z 2014-12-10T16:05:35Z "Currently the back-end cannot fully handle if equations inside when equations. It can only handle if equations that can be transformed to if expressions. So this kind of equations do fail in the back-end {{{#!mo when wE43_direct.switchingDynamics.ReachMiddle then if abs(wE43_direct.switchingDynamics.x_d) > wE43_direct.switchingDynamics.transVel then reinit(wE43_direct.switchingDynamics.x_d,wE43_direct.switchingDynamics.coefficientOfDamping * pre(wE43_direct.switchingDynamics.x_d)); wE43_direct.switchingDynamics.targetReached = false; else wE43_direct.switchingDynamics.targetReached = true; reinit(wE43_direct.switchingDynamics.x_d,0.0); reinit(wE43_direct.switchingDynamics.x,0.0); end if; end when; }}}" Adrian Pop 3029 Add support for generating a 32bit FMU using a 64bit OMC (if possible) FMI trunk Future defect Adeel Asghar new 2014-12-13T00:11:45Z 2018-09-12T02:07:35Z "Some people are interested in generating a 32bit FMU from a 64bit OMC on Linux. This should be possible I guess if we specify some flags to the C compiler, but we would need 32 bit libraries to link in I guess." Adrian Pop 3066 ExpressionSolve cant't solve cast Backend trunk Future defect somebody reopened 2015-01-08T11:37:56Z 2015-01-09T10:39:28Z "The model Modelica.Electrical.Machines.Examples.SynchronousInductionMachines.SMEE_LoadDump fails, because we can't solve for for a cast expression. See following model: {{{ loadString("" model Test2 parameter Real a = sin(3.14)*2; parameter Real x = 10; Real y; Integer p; equation der(y) = y + p; der(y) = a*sin(time); end Test2; ""); getErrorString(); }}} - It should be possible to fix that, or vitalij? - The tearing module should generate an error in such situations." Willi Braun 3067 Memory leak in FMI 2.0 (20 MB/min) FMI trunk Future defect Adrian Pop accepted 2015-01-09T08:30:53Z 2017-11-14T22:08:53Z "Thanks to the solution of a couple of tickets during the last weeks the optimization basing on FMI is working quite well now! A remaining problem is a memory leak that can be seen in all examples to some extend. Here is an extreme case that leaks about 20 MB/min (depending on the speed of your processor). The problem can be reproduced by repeatedly running an optimization with HQP. On a machine with omc (r23977), git, gcc and tcl-dev: {{{ $ git clone https://github.com/omuses/hqp.git $ cd hqp $ ./configure $ make $ cd odc $ ./odc % while true {source drumboiler_sp.tcl} }}}" Rüdiger Franke 3068 Model fails because linear system solver fails Run-time trunk Future defect somebody new 2015-01-09T12:43:20Z 2015-01-09T12:43:20Z "MSL32 Model Modelica.Magnetic.FundamentalWave.Examples.BasicMachines.SMR_Inverter_MultiPhase produces the following error with Cellier Tearing: {{{ stdout | info | model terminate | linear system solver failed. | Simulation terminated at time 0.226 }}}" Patrick Täuber 3069 Model needs very long simulation time with Cellier Tearing Backend trunk Future defect Patrick Täuber accepted 2015-01-09T14:26:01Z 2016-05-02T10:22:53Z "The MSL32 model Modelica.Electrical.Machines.Examples.AsynchronousInductionMachines.AIMC_YD takes over 100 minutes for simulation with Cellier Tearing because of way too much steps: {{{ LOG_STATS | info | ### STATISTICS ### | | | | | timer | | | | | | 0.0322984s reading init.xml | | | | | | 0.003696s reading info.xml | | | | | | 0.000564877s pre-initialization | | | | | | 0.000243327s [ 0.0%] initialization | | | | | | 5.6153e-05s [ 0.0%] steps | | | | | | 0.0105037s [ 0.0%] creating output-file | | | | | | 0.00208371s [ 0.0%] event-handling | | | | | | 0.0116676s [ 0.0%] overhead | | | | | | 6586.88s [100.0%] simulation | | | | | | 6586.9s [100.0%] total | | | | | events | | | | | | 2 state events | | | | | | 0 time events | | | | | solver: DASSL | | | | | | 15358920 steps taken | | | | | | 30979010 calls of functionODE | | | | | | 23021038 evaluations of jacobian | | | | | | 217 error test failures | | | | | | 7673606 convergence test failures }}} With omcTearing: {{{ LOG_STATS | info | ### STATISTICS ### | | | | | timer | | | | | | 0.031817s reading init.xml | | | | | | 0.00360088s reading info.xml | | | | | | 0.000564458s pre-initialization | | | | | | 0.000215112s [ 0.0%] initialization | | | | | | 0.000122851s [ 0.0%] steps | | | | | | 0.00647291s [ 0.7%] creating output-file | | | | | | 0.00109345s [ 0.1%] event-handling | | | | | | 0.00640162s [ 0.7%] overhead | | | | | | 0.849506s [ 98.3%] simulation | | | | | | 0.864376s [100.0%] total | | | | | events | | | | | | 2 state events | | | | | | 0 time events | | | | | solver: DASSL | | | | | | 8942 steps taken | | | | | | 12840 calls of functionODE | | | | | | 595 evaluations of jacobian | | | | | | 176 error test failures | | | | | | 83 convergence test failures }}}" Patrick Täuber 3070 Noise package does not work (replaceable package + function objects) Frontend trunk Future defect Adrian Pop accepted 2015-01-11T11:20:05Z 2020-12-01T15:38:20Z "DLR is currently restructuring the Noise package that is planned to be included in MSL 3.2.2. The package shall be very flexible ((a) the uniform random number generator to be used can be selected globally, (b) the random number according to a specific distribution can be selected for every instance and (c) this instance uses the globally selected uniform random number generator. Unfortunately, OpenModelica 1.9.1 (r22929) is not able to handle it. Find attached several different variants in order to find a version that runs in OpenModelica. Neither of them runs in OpenModelica: - TestRandomFeatures.Version2 is the desired one with the desired flexibility. OpenModelica complains during flattening. - TestRandomFeatures.Version1,Version3,Version are simplified versions (not as flexible as desired), but still OpenModelica complains during flattening. - TestRandomFeatures.Version4 is a very simplified version and OpenModelica generates C-Code. However, the C-compiler reports errors (incompatible type for argument 1 of 'sub_alloc_integer_array'). Please, fix OpenModelica that at least Version5 is running. Even better, please try to generalize OpenModelica so that Version2 is running " martin.otter@… 3071 Handle argument conversion in external C structs Code Generation trunk Future defect Adrian Pop assigned 2015-01-12T13:59:58Z 2015-01-12T14:00:12Z "We need to handle record in external ""C"" according to the specification: > Each element of the Modelica record is mapped to its corresponding C representation. Which means we need to convert Integer from long to int. > The elements of the Modelica record class are declared in the same order in the C struct. Which means we need to create a function to permute the Modelica array since it is in alphabetical ordering. > Arrays cannot be mapped. Which means the C version of the struct needs to be modified to not contain arrays." Martin Sjölund 3079 Start values are not calculated properly if they depend on secondary parameters Backend trunk Future defect Lennart Ochel new 2015-01-15T19:34:19Z 2015-01-15T19:34:19Z "Start values are calculated before the secondary parameters which leads to div. by zero. The following model demonstrates the wrong behavior: {{{#!mo model A parameter Real a(fixed=false); Real x(start = 1.0,fixed=true); Real y(start = 1/b,fixed=true); parameter Real b = 5.6 / a; initial equation x*2 = a; equation der(x) = 0; der(y) = 0; end A; }}} " Lennart Ochel 3084 Under-determined linear system not solvable! *unknown* trunk Future defect Willi Braun accepted 2015-01-18T12:16:14Z 2015-03-09T13:22:33Z "I noticed that the simulation of one the following examples in Modelica_Electrical_PowerConverters.Examples.ACDC.ThyristorBridge2mPulse 1. ThyristorBridge2mPulse_R 2. ThyristorBridge2mPulse_RL 3. ThyristorBridge2mPulse_RLV 4. ThyristorBridge2mPulse_RLV_Characteristic 5. ThyristorBridge2mPulse_DC_Drive causes multiple error messages of the kind: {{{ under-determined linear system not solvable! Matrix singular! }}} The first three examples at least simulate, even though these error messages occur. Example 4 takes too long to wait for the simulation to end. Example 5 does not finish simulation at all. I have to note, however, that these examples have been working in previous versions of OpenModelica. The actual bug report refers to * Ubuntu 14.04 32 bit * OpenModelica r24056 * Library Modelica_Electrical_PowerConverters located on https://svn.modelica.org/projects/Modelica_ElectricalSystems/Modelica_Electrical_PowerConverters/branches/Modelica_Electrical_PowerConverters%203.2.1; a modified version of this library is planned to be included in MSL 3.2.2 I am not sure whether this ticket is related with #2996 or not." Christian Kral 3086 Crash of OMOptim OMOptim Future defect Hubert Thieriot new 2015-01-19T17:36:14Z 2015-01-19T17:51:56Z I use OMOptim 0.9.22747 together with OM 1.9.1. At the end of an optimization run the programm always crashs before a results tab appears. rita 3120 XML code generation can not handle record assignments in algorithm section Code Generation trunk Future defect somebody assigned 2015-01-30T13:20:09Z 2015-02-03T18:10:12Z "{{{ #!mo model Bug record BugRecord Integer x; end BugRecord; BugRecord bugRecord; initial equation bugRecord = BugRecord(0); algorithm when time > 0.5 then bugRecord := BugRecord(1); end when; end Bug; }}} You can generate C code and it works. But XML code generation is broken. '''$ omc -s --simCodeTarget=XML Bug.mo''' Error processing file: Bug.mo [CodegenXML.tpl:2148:14-2148:14:writable] Error: Template error: Unknown expression: Bug.BugRecord(1) # Error encountered! Exiting... # Please check the error message and the flags." anonymous 3133 Uncertainties and OpenTURNS support is broken Backend trunk Future defect Adrian Pop accepted 2015-02-03T14:56:41Z 2015-02-03T14:56:49Z The support for uncertainties (and implicit the connection to OpenTURNS) got broken a while back. We should bring it back as people in MODRIO project need it. Adrian Pop 3154 OMOptim and clang: incomplete type 'Variable' named in nested name specifier OMOptim trunk Future defect Hubert Thieriot new 2015-02-12T18:24:48Z 2017-11-14T22:08:53Z "openmodelica r24555: Several compilation errors with clang (version ""clang-3.5.0-6.fc21.x86_64"" on Fedora 21) in OMOptim: Example (see also the attached log file): In file included from ../Core/Dymola/ModPlusDymolaCtrl.cpp:44: In file included from ../Core/Dymola/ModPlusDymolaCtrl.h:18: In file included from ../Core/Modelica/ModPlusCtrl.h:47: In file included from ../../OMOptimBasis/MOVector.h:169: ../../OMOptimBasis/MOVector.cpp:121:12: error: incomplete type 'Variable' named in nested name specifier return ItemClass::nbFields; ^~~~~~~~~~~ ../Core/Dymola/ModPlusDymolaCtrl.cpp:121:21: note: in instantiation of member function 'MOAVector::columnCount' requested here finalVariables->clear(); ^ ../Core/ModelPlus.h:14:7: note: forward declaration of 'Variable' class Variable; ^ " Stefan Hoelldampf 3163 Cycling binding that is not cyclic detected Frontend trunk Future defect Per Östlund new 2015-02-19T13:24:45Z 2016-04-13T10:18:37Z "If M.id is renamed to M.idx, the following code works. Seems we do not find out if an identifier comes from within the function scope or not. {{{#!mo model M function f input Integer id; output Integer o = id; end f; function g = f(final id=id); Integer id; Integer y = f(id); Integer z = g(); end M; }}}" Martin Sjölund 3164 Code generation error for tuple calls with array slices Code Generation trunk Future defect Mahder Alemseged Gebremedhin accepted 2015-02-19T13:39:48Z 2015-02-20T18:58:52Z "Code generation fails with UNKNOWN_SUBSCRIPT for the following code: {{{#!mo function f input Real r; output Real y = r; output Real o[3] = {r,r,r}; end f; function g input Real r; input Integer i; output Real o[4]; algorithm o[1] := f(r); (,o[i:i+2]) := f(r); (o[1],o[i:i+2]) := f(r); end g; model M Real r[4] = g(time,1); end M; }}}" Martin Sjölund 3165 Cyclically dependent parameters due to min/max attribute Frontend trunk Future defect somebody new 2015-02-19T13:53:34Z 2015-02-20T10:23:47Z "{{{#!mo model test parameter Real a(min=0, max=b) = 2; parameter Real b(min=a) = 3; end test; }}} OpenModelica throws following error message for this model: {{{ Translation Error Cyclically dependent constants or parameters found in scope test: {b,a}. }}} Is that intended? Dymola does not complain about cyclically dependent parameters in this case." Lennart Ochel 3170 Under Mac OS X, BouncingBall FMU segfaults in fmuCheck *unknown* trunk Future defect somebody new 2015-02-20T17:22:42Z 2015-12-23T15:23:45Z "Under Mac OS X, using the OpenModelica svn head from 20-Feb-2015, a BouncingBall FMU created with OpenModelica segfaults in fmuCheck. See Ticket #3169 at https://trac.openmodelica.org/OpenModelica/ticket/3169 for setup. Note that it is necessary to unzip the fmu in a tmp directory and do: mv binaries/x86_64-apple-darwin13.4.0/ binaries/darwin64 zip -r ../BouncingBallFMI20.fmu * I created a debug version of fmuCheck by editing FMUChecker-2.0.1/build/CMakeCache.txt and changing various places where optimization was used and -g was not used to -ggdb {{{ //Flags used by the compiler during debug builds. CMAKE_CXX_FLAGS_DEBUG:STRING=-ggdb //Flags used by the compiler during release builds for minimum // size. CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-ggdb //Flags used by the compiler during release builds. CMAKE_CXX_FLAGS_RELEASE:STRING=-ggdb //Flags used by the compiler during release builds with debug info. CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-ggdb ... //Flags used by the compiler during debug builds. CMAKE_C_FLAGS_DEBUG:STRING=-ggdb //Flags used by the compiler during release builds for minimum // size. CMAKE_C_FLAGS_MINSIZEREL:STRING=-ggdb //Flags used by the compiler during release builds. CMAKE_C_FLAGS_RELEASE:STRING=-ggdb //Flags used by the compiler during release builds with debug info. CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-ggdb }}} I also changed strip to touch {{{ //Path to a program. CMAKE_STRIP:FILEPATH=touch }}} I then reran cmake .. and make, which gives me a debug version of fmuCheck.darwin64. I still can't get a complete stack trace, but at least an assertion is failing: {{{ bash-3.2$ ggdb /Users/cxh/src/fmi/FMUChecker-2.0.1/build/fmuCheck.darwin64 GNU gdb (GDB) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type ""show copying"" and ""show warranty"" for details. This GDB was configured as ""x86_64-apple-darwin13.2.0"". Type ""show configuration"" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type ""help"". Type ""apropos word"" to search for commands related to ""word""... Reading symbols from /Users/cxh/src/fmi/FMUChecker-2.0.1/build/fmuCheck.darwin64...done. (gdb) r BouncingBallFMI20.fmu Starting program: /Users/cxh/src/fmi/FMUChecker-2.0.1/build/fmuCheck.darwin64 BouncingBallFMI20.fmu [INFO][FMUCHK] FMI compliance checker Test [FMILibrary: Test] build date: Feb 19 2015 [INFO][FMUCHK] Called with following options: [INFO][FMUCHK] /Users/cxh/src/fmi/FMUChecker-2.0.1/build/fmuCheck.darwin64 BouncingBallFMI20.fmu [INFO][FMUCHK] Will process FMU BouncingBallFMI20.fmu [INFO][FMILIB] XML specifies FMI standard version 2.0 Assertion failed: (index < a->size), function jm_vector_get_itemp_char, file /Users/cxh/src/fmi/FMUChecker-\ 2.0.1/FMIL/src/Util/include/JM/jm_vector.h, line 352. Program received signal SIGABRT, Aborted. 0x00007fff8af53866 in ?? () (gdb) where #0 0x00007fff8af53866 in ?? () #1 0x00007fff8620935c in ?? () #2 0x0000000000000000 in ?? () (gdb) #0 0x00007fff8af53866 in ?? () #1 0x00007fff8620935c in ?? () #2 0x0000000000000000 in ?? () (gdb) }}}" cxh@… 3172 Reorganize the /build layout for Windows to better support +target=msvc for CPP runtime Cpp Run-time trunk Future defect Adrian Pop accepted 2015-02-23T13:49:52Z 2015-09-24T15:09:09Z "Currently runtimeCPPmsvcinstall and runtimeCPPinstall puts the build/include and build/lib files in the same place which means that we only support gcc for the CPP runtime (or whichever target is ran last). I propose to have build/include/msvc/cpp and build/lib/msvc/cpp. Maybe even have the same for the C runtime (build/include|lib/msvc/c) as currently is directly in build/include/msvc and build/lib/msvc." Adrian Pop 3176 String parameters cannot be changed at run-time Run-time trunk Future defect somebody new 2015-02-25T00:34:49Z 2015-03-03T02:38:05Z "Using -override or by editing the _init.xml file, parameters of type String ignore the start value and use whatever value was set at compilation. " jwharington@… 3177 Loading libraries with non existing names in package.order should not fail Frontend trunk Future defect somebody new 2015-02-25T07:09:45Z 2015-02-25T07:55:45Z Currently we fail if we find a name in package.order which does not exist as a directory_name/package.mo or name.mo. We should only give a warning and continue. Unfortunately a lot of libraries (especially in development) have this issue and we fail to load them because of it. Adrian Pop 3182 dimension size of function calls Frontend trunk Future defect somebody new 2015-03-02T14:44:01Z 2015-03-04T08:28:14Z "Hi, The dimension of an array-equation with (external) functions can occasionally be evaluated. See example model: {{{ package funcTest function func input Real[n] arrIn; input Integer n; output Real[n] arrOut; external ""C"" foo(arrIn,arrOut); end func; model funcDimension parameter Integer n1 = 2; Real x[n1], x1[n1]; Real y; equation for i in 1:n1 loop x1[i] = time; end for; x = func(x1,n1); der(y) = x[1]; end funcDimension; end funcTest; }}} +d=dumpSimCode tells us that {{{ 8: x=funcTest.func(x1, 2)[Real[:] ] }}} the dimension of the arrayequation is unknown but actually, this could be evaluated with the help of the function declaration to {{{n}}} i.e. {{{n1}}} and even {{{2}}} (if we evaluate parameter). " Volker Waurich 3185 Add simulation tests ran with the same flags as OMEdit uses so we check that simulation works Run-time trunk Future defect somebody new 2015-03-03T16:32:58Z 2015-03-03T16:32:58Z Sometimes simulation works without any flags but crashes if extra flags are given (such as running the simulation from OMEdit). We should add tests to check this. Adrian Pop 3191 Modelica.Fluid.Examples.HeatingSystem fails in combination with replaceHomotopy=actual Backend trunk Future defect somebody new 2015-03-06T13:14:47Z 2015-03-10T08:27:35Z "Modelica.Fluid.Examples.HeatingSystem fails if replaceHomotopy=actual is used due to a singular linear system during casualization: {{{ 1 : pump.dp_pump = pump.p_b_nominal - tank.ports[2].p 2 : pump.dp_pump = pump.medium.p - tank.ports[2].p [ 1.0 , 1.0 ; 1.0 , 1.0 ] * [ tank.ports[2].p ; pump.dp_pump ] = [ pump.p_b_nominal ; pump.medium.p ] U(2,2) = 0.0, which means system is singular for variable pump.dp_pump. }}} " Lennart Ochel 3200 New attributes values break some tests Run-time trunk Future defect somebody new 2015-03-09T13:13:09Z 2015-03-09T13:13:09Z "With r24990 the following examples are broken: {{{ testsuite/simulation/libraries/msl32/Modelica.Fluid.Examples.HeatExchanger.HeatExchangerSimulation-addDerAlias.mos testsuite/simulation/libraries/msl32/Modelica.Fluid.Examples.HeatingSystem.mos testsuite/simulation/libraries/msl32/Modelica.Fluid.Examples.PumpingSystem.mos }}} The examples fail with a non-linear solver issue at initialization." Willi Braun 3206 Invalid code generation for functions Code Generation trunk Future defect someone new 2015-03-10T08:18:25Z 2015-03-10T08:18:25Z "If msl32 example HeatingSystem get executed using +replaceHomotopy=actual the generated c code contains following error: {{{ Modelica.Fluid.Examples.HeatingSystem_functions.c: In function ‘omc_$DER$$PModelica$PFluid$PUtilities$PregFun3’: Modelica.Fluid.Examples.HeatingSystem_functions.c:445: error: lvalue required as left operand of assignment }}}" Lennart Ochel 3216 cseCall and DIVISION Backend trunk Future defect somebody new 2015-03-12T10:49:56Z 2015-03-12T10:50:08Z It seems weird to me that DIVISION is a DAE.CALL. It seems to be handled by common sub-expression elimination. Why is this just not simply a binary operation? Special code generation for the error messages can easily be expanded in the code generator. Martin Sjölund 3217 Wrong equation counting Code Generation trunk Future defect Mahder Alemseged Gebremedhin accepted 2015-03-12T13:56:06Z 2015-04-24T12:00:29Z "OM counts just 2 equations for following model, but it should be 4. {{{#!mo model TestSimpleEqu record foo Real a; Real b; end foo; function foofoo2 input foo x[2]; output foo y[2]; algorithm y[1].a := x[2].b; y[1].b := x[2].a; y[2].a := x[1].b; y[2].b := x[1].a; end foofoo2; foo g1[2]; equation //{foo(g1[1].a, g1[1].b), foo(g1[2].a, g1[2].b)} = foofoo2({foo(1.0, 2.0),foo(1.0, 2.0)}); g1 = foofoo2({foo(1.0, 2.0),foo(1.0, 2.0)}); end TestSimpleEqu; }}}" Lennart Ochel 3218 The read_write.* interface seems a bit off Run-time trunk Future defect somebody new 2015-03-12T17:51:40Z 2015-03-12T18:28:56Z "read_write.c uses malloc instead of GC_malloc. Do we really need this elaborate interface anymore? Can't we just send MetaModelica values directly now? This is afaik used only to send/receive data from external functions compiled as dlls during instantiation and probably during scripting." Adrian Pop 3224 Final parameter is not refreshed in plot windows after re-simulating example *unknown* trunk Future defect somebody new 2015-03-15T15:39:55Z 2015-03-15T15:39:55Z "Consider the following example {{{ model ParameterExample parameter Real a = 1; parameter Real b = 2; parameter Real c = a * b; final parameter Real d = a * b; end ParameterExample; }}} I simulate the example. In the PLOT tab I change parameter a from 1 to 2 an re-simulate the example by performing a right click on {{{ParameterExample}}}, selecting {{{Re-simulate}}}. Then parameter {{{c}}} gets refreshed, whereas {{{d}}} does not get refreshed. " Christian Kral 3230 Initialization handles when-clauses within algorithms wrong Backend trunk Future defect Lennart Ochel accepted 2015-03-17T13:14:23Z 2015-03-17T19:30:39Z "See the following example: {{{#!mo model Test Real r[2]; algorithm r[1] := 2; when time > 0.5 then r := zeros(2); end when; end Test; }}} Output: {{{ Notification: The given system is mixed-determined. [index > 0] Notification: The given system is mixed-determined. [index > 1] Notification: The given system is mixed-determined. [index > 2] Notification: The given system is mixed-determined. [index > 3] Error: No system for the symbolic initialization was generated. }}}" Lennart Ochel 3241 Cpp runtime naming conventions Cpp Run-time trunk Future defect Niklas Worschech assigned 2015-03-21T17:13:35Z 2017-11-14T22:08:53Z "Consider {{{#!mo package A package B model M end M; end B; package C model M end M; end C; end A; }}} translateModel(A.B.M) with +simCodeTarget=Cpp generates files that have `A.B.M` in their names. The classes inside the files just contain `M` in their name. This exhibits the risk that `A.B.M` and `A.C.M` collide if they shall be linked together, e.g. in a hierarchical FMU. Is this a bug or a feature? One might alternatively use underscores instead of dots for class names, like `A_B_M`. The Cpp FMU code generation currently messes up models with dots in their names. This ticket needs to be clarified, in order to know in which direction to proceed. " Rüdiger Franke 3242 Failure to compile generated code due to type mismatch ParModelica trunk Future defect Mahder Alemseged Gebremedhin reopened 2015-03-23T08:31:05Z 2015-09-10T15:46:36Z "When trying out the ocl* functions in ParModelica I ran into issues compiling the generated code. This might be related to bug #3214, but for ParModelica this time. To start with the test code (that should probably be extended to cover more of the ocl* functions): {{{#!mo /// oclTest.mo package oclTest constant Integer globalSizes = 10; constant Integer localSizes = 2; parkernel function Kernel parglobal output Integer groupId[globalSizes]; parglobal output Integer localId[globalSizes]; algorithm groupId[oclGetGlobalId(1)] := oclGetGroupId(1); localId[oclGetGlobalId(1)] := oclGetLocalId(1); end Kernel; function test output Integer groupId[globalSizes]; output Integer localId[globalSizes]; algorithm oclSetNumThreadsGlobalLocal1D({globalSizes}, {localSizes}); (groupId, localId) := Kernel(); end test; end oclTest; }}} Then a little script: {{{ /// oclTest.mos loadFile(""oclTest.mo""); getErrorString(); (x,y):=oclTest.test(); getErrorString(); }}} Then try to build and run the test script: {{{ $ omc -g=ParModelica oclTest.mos true """" Error processing file: oclTest.mos Error: Error building simulator. Build log: g++ -I""/home/gustaf/local/openmodelica/include/omc/c"" -fPIC -O0 -falign-functions -march=native -c -o oclTest_test.o oclTest_test.c oclTest_test.c: In function ‘integer_array omc_oclTest_test(threadData_t*, integer_array*)’: oclTest_test.c:35:46: error: cannot convert ‘base_array_t* {aka base_array_s*}’ to ‘device_integer_array* {aka dev_arr*}’ for argument ‘2’ to ‘device_integer_array omc_oclTest_Kernel(threadData_t*, device_integer_array*)’ tmp2 = omc_oclTest_Kernel(threadData, &tmp1); ^ oclTest_test.makefile:18: recipe for target 'oclTest_test' failed make: *** [oclTest_test] Error 1 # Error encountered! Exiting... # Please check the error message and the flags. Execution failed! }}} $ omc --version 1.9.3+dev (r25196) " Gustaf Thorslund 3257 hpcom and algebraic systems Backend trunk Future defect somebody new 2015-04-01T07:14:22Z 2017-11-14T22:08:53Z "Running `omc +d=hpcom +hpcomScheduler=level +n=8 ParallelPRV.mos` gives output: > There is no ODE system that can be parallelized! Which is correct; the system does not have state variables. However, the algebraic system of equations is very expensive and simple to parallelize. testsuite/simulation/modelica/parallel/ParallelPRV.mos" Martin Sjölund 3272 VehicleInterfaces.Examples.FrontWheelDriveManualVehicle generates bad results Backend trunk Future defect somebody new 2015-04-10T22:45:55Z 2015-04-10T22:45:55Z "For example variable driveline.finalDrive.phi_b is always 0. Maybe the back-end guys can have a look. Not sure this is an initialization issue or something else. If you compile OMC with: {{{ > export GITLIBRARIES=Yes }}} you will get VehicleInterfaces 1.2.2 with OpenModelica. Then you can run this script: {{{ loadModel(Modelica); getErrorString(); loadModel(VehicleInterfaces""); getErrorString(); simulate(VehicleInterfaces.Examples.FrontWheelDriveManualVehicle); getErrorString(); val(driveline.finalDrive.phi_b, 0); val(driveline.finalDrive.phi_b, 1); val(driveline.finalDrive.phi_b, 2); val(driveline.finalDrive.phi_b, 3); val(driveline.finalDrive.phi_b, 4); val(driveline.finalDrive.phi_b, 5); val(driveline.finalDrive.phi_b, 6); val(driveline.finalDrive.phi_b, 7); val(driveline.finalDrive.phi_b, 8); val(driveline.finalDrive.phi_b, 9); val(driveline.finalDrive.phi_b, 10); }}} " Adrian Pop 3276 createNonlinearResidualEquationsComplex failed for fluid-model *unknown* trunk Future defect somebody new 2015-04-13T12:54:45Z 2015-04-13T16:36:10Z "Problematic library: https://github.com/droberg/Modelica-MVEM.git The library mentioned above contains three test-models of which two simulates great (same results as in Dymola) while the third has problems with '''createNonlinearResidualEquationsComplex''' The examples that are working in openModelica 1.9.2 (And nightly r25516) are: * energyPreservationTest.mo * throttleSanityCheck.mo The example that is not working is * SIEngineTest Code to reproduce: {{{ cd(""C:/Temp/Modelica-MVEM/MVEMLib"") clear() loadModel(Modelica); loadFile(""package.mo"") instantiateModel(MVEMLib.Examples.SIEngineTest) simulate(MVEMLib.Examples.SIEngineTest, stopTime=15, method=""dassl"", tolerance=1e-005) }}} Result: {{{ ... [c:/dev/OpenModelica/Compiler/SimCode/SimCodeUtil.mo:3501:7-3501:46:writable] Error: Internt fel function createNonlinearResidualEquationsComplex failed for: ({-sIEngine.exhaustTemperatureDrop.InPut.dmXi[1], -sIEngine.exhaustTemperatureDrop.InPut.dmXi[2], -sIEngine.exhaustTemperatureDrop.InPut.dmXi[3], -sIEngine.exhaustTemperatureDrop.InPut.dmXi[4], -sIEngine.exhaustTemperatureDrop.InPut.dmXi[5], -sIEngine.exhaustTemperatureDrop.InPut.dmXi[6]}, sIEngine.adiabaticBurner.dummyOutput) = MVEMLib.Basic.Media.AdiabaticBurner.fuelAirMedium.calcBurnedFractions({sIEngine.adiabaticBurner.UnburnedInPut.dmXi[1], sIEngine.adiabaticBurner.UnburnedInPut.dmXi[2], sIEngine.forcedMassFlow.InPut.dmXi[1]}, sIEngine.exhaustManifold.gas.T) [C:/Temp/Downloads/Modelica ... }}}" Per Öberg 3288 FMU compilation (MSVC) Code Generation trunk Future defect Adrian Pop assigned 2015-04-20T18:26:43Z 2017-11-14T22:08:53Z "Using flag +target=msvc and compiling a model with string variables or parameters, the following prevent successful compilation: mymodel_fmu.c : error C2440: 'return' : cannot convert from 'modelica_string' to 'fmiString' Conversion from 'void*' to pointer to non-'void' requires an explicit cast The offending function: {{{ fmiString getString(ModelInstance* comp, const fmiValueReference vr) { switch (vr) { case $PVAR : return comp->fmuData->simulationInfo.stringParameter[0]; break; default: return """"; } } }}} mymodel_fmu.c : error C2440: '=' : cannot convert from 'fmiString' to 'modelica_string' Conversion loses qualifiers The offending function: {{{ fmiStatus setString(ModelInstance* comp, const fmiValueReference vr, fmiString value) { switch (vr) { case $PVAR : comp->fmuData->simulationInfo.stringParameter[0]=value; break; default: return fmiError; } return fmiOK; } }}} " michael.kobierski@… 3289 FMU compilation (MSVC) fails for big models FMI trunk Future defect Adrian Pop assigned 2015-04-20T18:34:43Z 2016-03-19T00:19:05Z "Using flag +target=msvc, the following is observed when creating an FMU from a model with a very long modelDescription.xml file (the contents of which are also stored in a .c file). mymodel_init.c(1) : error C2026: string too big, trailing characters truncated mymodel_info.c(1) : error C2026: string too big, trailing characters truncated The same code will compile fine with gcc, due to the compiler specific nature of limits imposed on string literals. Turns out cl has a maximum limit of 16KB." michael.kobierski@… 3293 Array of records containing array get wrong equation count. Backend trunk Future defect somebody new 2015-04-24T11:50:27Z 2015-04-24T11:50:27Z "This is a bit like #3217, but with an array in the record. Given the following model: {{{#!mo model ArrayRecordArrayTest record Field Real value[3,5,7](each start=11); end Field; function Func input Field f; output Field result; algorithm result.value := 13*f.value; end Func; function FuncArray input Field f[:]; output Field result[size(f)]; algorithm for i in 1:size(f,1) loop result[i] := Func(f[i]); end for; end FuncArray; Field x; Field a[2]; algorithm when sample(0, 0.1) then x := Func(x); a := FuncArray(a); end when; end ArrayRecordArrayTest; }}} Flattening seems to work fine, but then it fails with too few equations. {{{ Error processing file: ArrayRecordArrayTest.mo Error: Too few equations, under-determined system. The model has 107 equation(s) and 315 variable(s). Error: Internal error Transformation Module PFPlusExt index Reduction Method Pantelides failed! }}} So it seems to only count the number of variables in the record when using an array or records, but count the length of the array when only using one record." Gustaf Thorslund 3294 Precalculate less functions Frontend trunk Future defect somebody new 2015-04-26T18:54:13Z 2017-11-14T22:08:53Z "The example `Modelica.Utilities.Examples.readRealParameterModel` is all about reading model parameters at simulation time. {{{#!mo model readRealParameterModel ""Demonstrate usage of Examples.readRealParameter/.expression"" import SI = Modelica.SIunits; extends Modelica.Icons.Example; parameter String file = Modelica.Utilities.Files.loadResource(""modelica://Modelica/Resources/Data/Utilities/Examples_readRealParameters.txt"") ""File on which data is present""; parameter SI.Inertia J = readRealParameter(file, ""J"") ""Inertia""; parameter SI.Angle phi_rel0 = readRealParameter(file, ""phi_rel0"") ""Relative angle""; parameter SI.AngularVelocity w_rel0 = readRealParameter(file, ""w_rel0"") ""Relative angular velocity""; end readRealParameterModel; }}} OpenModelica evaluates everything at translation time. This can hardly be counted as a passed test. The `file` must be read at simulation time. As of today one can generally introduce some dummy inputs, whose values are not known at translation time, and pass them to a function like `readReadParameter`. Then the evaluation of the function is shifted to the simulation time -- and it works fine typically. How can the translation of OpenModelica be changed to evaluate less functions, so that models like `readRealParameterModel` work as intended, without tricks? " Rüdiger Franke 3299 Array of records containing array get compilation errors when updated Code Generation trunk Future defect Mahder Alemseged Gebremedhin accepted 2015-04-29T09:22:36Z 2015-04-29T09:53:17Z "If putting arrays into records (to get some kind of abstraction), and then putting those records into an array, the generated code will fail to build due to unknown components in array. {{{#!mo loadString("" package ArrayRecordArrayAssign record AR Integer a[2,3]; end AR; function UpdateAR input AR ar; output AR result; algorithm result.a := 10*ar.a; end UpdateAR; function Test input Integer n; output AR result; protected AR a; algorithm for i in 1:n loop a := UpdateAR(a); end for; result := a; end Test; function Test2 input Integer n; output AR[2] result; protected AR ara[2]; algorithm for i in 1:n loop ara[1] := ara[2]; ara[2] := UpdateAR(ara[2]); end for; result := ara; end Test2; end ArrayRecordArrayAssign; ""); // This works fine x := ArrayRecordArrayAssign.Test(3); // This gives compilation errors in generated code y := ArrayRecordArrayAssign.Test2(3); }}} The assignment to a record works fine, but the assignment to a record within an array will fail. {{{ Error: Error building simulator. Build log: gcc -I""/home/gustaf/src/openmodelica/build/include/omc/c"" -fPIC -O0 -falign-functions -march=native -c -o ArrayRecordArrayAssign_Test2.o ArrayRecordArrayAssign_Test2.c ArrayRecordArrayAssign_Test2.c: In function ‘omc_ArrayRecordArrayAssign_Test2’: ArrayRecordArrayAssign_Test2.c:24:31: error: ‘ArrayRecordArrayAssign_AR_array’ has no member named ‘_a’ alloc_integer_array(&_result._a, 2, 2, 3);alloc_generic_array(&_result, sizeof(ArrayRecordArrayAssign_AR), 1, (modelica_integer) 2); ^ ArrayRecordArrayAssign_Test2.c:25:28: error: ‘ArrayRecordArrayAssign_AR_array’ has no member named ‘_a’ alloc_integer_array(&_ara._a, 2, 2, 3);alloc_generic_array(&_ara, sizeof(ArrayRecordArrayAssign_AR), 1, (modelica_integer) 2); . . . }}}" Gustaf Thorslund 3307 translation fails because of (lack of) potential and flow variables where all signals are inputs or outputs Backend trunk Future defect somebody new 2015-05-04T22:00:50Z 2015-05-05T10:03:46Z "I want to export a fluid flow component (similar to Modelica.Fluid) as an FMU. The translation fails because the number of potential variables is not equal to the number of flow variables. The model has, however, only input or output signals, and no flow variable should be used in this case. I created the following test case that reproduces the error. It does not use any Fluid or Media, but rather only has input or output signals. In my view, this model is well-posed: {{{ package MIMO connector FluidProperties ""Type definition for fluid properties"" // No input or output is declared here, as the whole connector // can be all input or all output variables. Modelica.SIunits.SpecificEnthalpy h ""Specific thermodynamic enthalpy""; Real X_w ""Water vapor mass fractions per kg total air""; end FluidProperties; connector inlet input Modelica.SIunits.MassFlowRate m_flow; input Modelica.SIunits.AbsolutePressure p; input FluidProperties proFor; output FluidProperties proBac; end inlet; connector outlet output Modelica.SIunits.MassFlowRate m_flow; output Modelica.SIunits.AbsolutePressure p; input FluidProperties proBac; output FluidProperties proFor; end outlet; block MIMO ""Test model"" inlet inlet1 annotation (Placement(transformation(extent={{-110,-10},{-90,10}}), iconTransformation(extent={{-110,-10},{-90,10}}))); outlet outlet1 annotation (Placement(transformation(extent={{90,-10},{110,10}}), iconTransformation(extent={{90,-10},{110,10}}))); equation connect(inlet1, outlet1) annotation (Line(points={{-100,0},{100,0},{100,0}}, color={0,0,0})); annotation (uses(Modelica(version=""3.2.1"")), Diagram(coordinateSystem( preserveAspectRatio=false, extent={{-100,-100},{100,100}}))); end MIMO; annotation (uses(Modelica(version=""3.2.1""))); end MIMO; }}} The detailed message is: {{{ [1] 14:50:53 Translation Warning [MIMO: 12:5-17:14]: Connector .MIMO.inlet is not balanced: The number of potential variables (4) is not equal to the number of flow variables (0). [2] 14:50:53 Translation Warning [MIMO: 4:5-10:24]: Connector .MIMO.FluidProperties is not balanced: The number of potential variables (2) is not equal to the number of flow variables (0). [3] 14:50:53 Translation Warning [MIMO: 19:5-24:15]: Connector .MIMO.outlet is not balanced: The number of potential variables (4) is not equal to the number of flow variables (0). [4] 14:50:53 Symbolic Error [: 0:0-0:0]: Too few equations, under-determined system. The model has 6 equation(s) and 10 variable(s). [5] 14:50:53 Translation Error [: 0:0-0:0]: Internal error pre-optimization module clockPartitioning failed. }}} A slightly more complex model is Buildings/Fluid/FMI/Examples/FMUs/TwoPortPassThrough from {{{ git clone git@github.com:lbl-srg/modelica-buildings.git cd modelica-buildings git checkout issue313_fmi }}} " Michael Wetter 3314 Under RHEL6.5, the VanDerPol FMU created by omc r25909 segfaults when run using fmusdk2 FMI trunk Future defect new 2015-05-11T20:16:54Z 2015-09-09T10:18:58Z "Under RHEL6.5, the VanDerPol FMU created by omc r25909 segfaults when run using fmusdk2. Here's how to reproduce this: Build FMUSDK2: {{{ git clone https://github.com/cxbrooks/fmusdk2.git cd fmusdk2 make cd fmu20/bin }}} Using the OpenModelica devel tree, create VanDerPol.fmu: {{{ cxh@terra VanDerPol]$ omc --version 1.9.3+dev (r25909) [cxh@terra VanDerPol]$ cat VanDerPol.mo // Van der Pol model // From OpenModelica: build/share/doc/omc/testmodels/VanDerPol.mo model VanDerPol ""Van der Pol oscillator model"" // Was start = 1, but FMUSDK has start = 2 Real x(start = 2); // Was start = 1, but FMUSDK has start = 0 Real y(start = 0); // Was lambda = 0.3, but FMUSDK has start = 1 parameter Real lambda = 1.0; equation der(x) = y; der(y) = - x + lambda*(1 - x*x)*y; end VanDerPol; [cxh@terra VanDerPol]$ cat VanDerPol.mos loadModel(Modelica, {""3.2.1""}); getErrorString(); loadFile(""VanDerPol.mo""); getErrorString(); OpenModelica.Scripting.translateModelFMU( className=VanDerPol, version=""2.0""); getErrorString(); [cxh@terra VanDerPol]$ omc VanDerPol.mos true """" true """" ""SimCode: The model VanDerPol has been translated to FMU"" ""Warning: The initial conditions are not fully specified. Use +d=initialization for more information. "" [cxh@terra VanDerPol]$ gdb ~/src/fmi/fmusdk2/fmu20/bin/fmusim_me GNU gdb (GDB) Red Hat Enterprise Linux (7.2-75.el6) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type ""show copying"" and ""show warranty"" for details. This GDB was configured as ""x86_64-redhat-linux-gnu"". For bug reporting instructions, please see: ... Reading symbols from /home/cxh/src/fmi/fmusdk2/fmu20/bin/fmusim_me...done. (gdb) r VanDerPol.fmu Starting program: /home/cxh/src/fmi/fmusdk2/fmu20/bin/fmusim_me VanDerPol.fmu warning: File ""/usr/local/gcc-4.9.2/lib64/libstdc++.so.6.0.20-gdb.py"" auto-loading has been declined by your `auto-load safe-path' set to ""/usr/share/gdb/auto-load:/usr/lib/debug:/usr/bin/mono-gdb.py"". To enable execution of this file add add-auto-load-safe-path /usr/local/gcc-4.9.2/lib64/libstdc++.so.6.0.20-gdb.py line to your configuration file ""/home/cxh/.gdbinit"". To completely disable this security protection add set auto-load safe-path / line to your configuration file ""/home/cxh/.gdbinit"". For more information about this security protection see the ""Auto-loading safe path"" section in the GDB manual. E.g., run from the shell: info ""(gdb)Auto-loading safe path"" [Thread debugging using libthread_db enabled] cmd='unzip -o -d fmuTmpceAftN/ ""VanDerPol.fmu"" > /dev/null' Detaching after fork from child process 12875. fmiModelDescription fmiVersion=2.0 modelName=VanDerPol guid={8c4e810f-3df3-4a00-8276-176fa3c9f9e0} description=Van der Pol oscillator model ModelExchange modelIdentifier=VanDerPol dllPath = fmuTmpceAftN/binaries/linux64/VanDerPol.so FMU Simulator: run 'VanDerPol.fmu' from t=0..1 with step size h=0.1, loggingOn=0, csv separator=',' log categories={ } Program received signal SIGSEGV, Segmentation fault. 0x00007ffff65257e2 in GC_find_limit_with_bound () from /usr/local/openmodelica/lib/x86_64-linux-gnu/omc/libomcgc.so.1 Missing separate debuginfos, use: debuginfo-install atlas-3.8.4-2.el6.x86_64 blas-3.2.1-4.el6.x86_64 glibc-2.12-1.149.el6_6.7.x86_64 libxml2-2.7.6-17.el6_6.1.x86_64 zlib-1.2.3-29.el6.x86_64 (gdb) where #0 0x00007ffff65257e2 in GC_find_limit_with_bound () from /usr/local/openmodelica/lib/x86_64-linux-gnu/omc/libomcgc.so.1 #1 0x00007ffff65258e2 in GC_init_linux_data_start () from /usr/local/openmodelica/lib/x86_64-linux-gnu/omc/libomcgc.so.1 #2 0x00007ffff6524352 in GC_init () from /usr/local/openmodelica/lib/x86_64-linux-gnu/omc/libomcgc.so.1 #3 0x00007ffff651e809 in GC_generic_malloc_inner () from /usr/local/openmodelica/lib/x86_64-linux-gnu/omc/libomcgc.so.1 #4 0x00007ffff651e8ce in GC_generic_malloc () from /usr/local/openmodelica/lib/x86_64-linux-gnu/omc/libomcgc.so.1 #5 0x00007ffff7678f87 in fmi2Instantiate () from fmuTmpceAftN/binaries/linux64/VanDerPol.so #6 0x00000000004024ae in simulate (fmu=0x616a60, tEnd=1, h=0.10000000000000001, loggingOn=0, separator=44 ',', nCategories=0, categories=0x0) at model_exchange/main.c:75 #7 0x0000000000403139 in main (argc=2, argv=0x7fffffffe5a8) at model_exchange/main.c:275 (gdb) down Bottom (innermost) frame selected; you cannot go down. (gdb) up #1 0x00007ffff65258e2 in GC_init_linux_data_start () from /usr/local/openmodelica/lib/x86_64-linux-gnu/omc/libomcgc.so.1 (gdb) #2 0x00007ffff6524352 in GC_init () from /usr/local/openmodelica/lib/x86_64-linux-gnu/omc/libomcgc.so.1 (gdb) #3 0x00007ffff651e809 in GC_generic_malloc_inner () from /usr/local/openmodelica/lib/x86_64-linux-gnu/omc/libomcgc.so.1 (gdb) #4 0x00007ffff651e8ce in GC_generic_malloc () from /usr/local/openmodelica/lib/x86_64-linux-gnu/omc/libomcgc.so.1 (gdb) #5 0x00007ffff7678f87 in fmi2Instantiate () from fmuTmpceAftN/binaries/linux64/VanDerPol.so (gdb) #6 0x00000000004024ae in simulate (fmu=0x616a60, tEnd=1, h=0.10000000000000001, loggingOn=0, separator=44 ',', nCategories=0, categories=0x0) at model_exchange/main.c:75 75 c = fmu->instantiate(instanceName, fmi2ModelExchange, guid, fmuResourceLocation, (gdb) q A debugging session is active. Inferior 1 [process 12872] will be killed. Quit anyway? (y or n) y [cxh@terra VanDerPol]$ }}}" cxh@… 3321 cppruntime does not return proper exit codes Cpp Run-time trunk Future defect Niklas Worschech assigned 2015-05-18T19:55:29Z 2017-11-14T22:08:53Z "cppruntime returns exit code=0 (success) even when the numerical solver fails: {{{ OpenModelicaModelTesting.SimulationRuntime.Cpp OpenModelicaModelTesting.Kind.VerifiedSimulation Modelica.Mechanics.MultiBody.Examples.Elementary.RollingWheelSetDriving {""wheelSet.x"",""wheelSet.y"",""wheelSet.phi"",""wheelSet.theta1"",""wheelSet.theta2"",""wheelSet.der_theta1"",""wheelSet.der_theta2""} Simulation options: startTime = 0.0, stopTime = 3.0, numberOfIntervals = 500, tolerance = 1e-06, method = 'dassl', fileNamePrefix = 'Modelica.Mechanics.MultiBody.Examples.Elementary.RollingWheelSetDriving', options = '', outputFormat = 'mat', variableFilter = '.*', cflags = '', simflags = '' Result file: Modelica.Mechanics.MultiBody.Examples.Elementary.RollingWheelSetDriving_res.mat Messages: [CVODES WARNING] ... [CVODES ERROR] CVode At t = 0.506727 and h = 1e-24, the error test failed repeatedly or with |h| = hmin. SUNDIALS_ERROR: CVode() failed with flag = -3 Warning: Resultfile and Reference have different end time points! Reffile[502]=3.000000 File[85]=0.504000 }}}" Martin Sjölund 3348 ParModelica: Unable to allocate parlocal array ParModelica trunk Future defect Mahder Alemseged Gebremedhin new 2015-06-08T20:55:46Z 2015-06-08T20:55:46Z "{{{#!mo setCommandLineOptions(""-v=1 +g=ParModelica +d=noevalfunc""); loadString("" package ParLocalArray constant Integer arrayCnt = 2; parkernel function f parglobal input Real A[arrayCnt]; parglobal output Real B[arrayCnt]; protected parlocal Real Tmp[arrayCnt]; algorithm for i in oclGetGlobalId(1):oclGetGlobalSize(1):arrayCnt loop Tmp[i] := A[i]*7; B[i] := Tmp[i]+A[i]; end for; end f; function test input Real d; output Real result[arrayCnt]; protected parglobal Real pResult[arrayCnt]; Real tmp[arrayCnt]; parglobal Real pTmp[arrayCnt]; algorithm for i loop tmp[i] := i; end for; pTmp := tmp; pResult := f(pTmp); result := pResult; end test; end ParLocalArray; ""); x:=ParLocalArray.test(4); }}} {{{ Error building program: CL_BUILD_PROGRAM_FAILURE Build failed: Errors detected in compilation of OpenCL code: CL_PROGRAM_BUILD_LOG: :33:3: error: use of undeclared identifier 'device_local_real_array' device_local_real_array _Tmp; ^ :39:3: warning: implicit declaration of function 'alloc_device_local_real_array' is invalid in C99 alloc_device_local_real_array(&_Tmp, 1, (modelica_integer) 2); ^ :39:34: error: use of undeclared identifier '_Tmp' alloc_device_local_real_array(&_Tmp, 1, (modelica_integer) 2); ^ :52:9: error: use of undeclared identifier '_Tmp' (*real_array_element_addr_c99_1(&_Tmp, 1, /* modelica_integer */ (modelica_integer)_i)) = (7.0 * (*real_array_element_addr_c99_1(&_A, 1, /* modelica_integer */ (modelica_integer)_i))); ^ :52:40: note: instantiated from: (*real_array_element_addr_c99_1(&_Tmp, 1, /* modelica_integer */ (modelica_integer)_i)) = (7.0 * (*real_array_element_addr_c99_1(&_A, 1, /* modelica_integer */ (modelica_integer)_i))); ^ :54:98: error: use of undeclared identifier '_Tmp' (*real_array_element_addr_c99_1(&_B, 1, /* modelica_integer */ (modelica_integer)_i)) = ((*real_array_element_addr_c99_1(&_Tmp, 1, /* modelica_integer */ (modelica_integer)_i)) + (*real_array_element_addr_c99_1(&_A, 1, /* modelica_integer */ (modelica_integer)_i))); ^ :54:129: note: instantiated from: (*real_array_element_addr_c99_1(&_B, 1, /* modelica_integer */ (modelica_integer)_i)) = ((*real_array_element_addr_c99_1(&_Tmp, 1, /* modelica_integer */ (modelica_integer)_i)) + (*real_array_element_addr_c99_1(&_A, 1, /* modelica_integer */ (modelica_integer)_i))); }}} Tested using my ParModelicaFixes branch on github containing fixes from Mahder, so it may or may not be related to those fixes." Gustaf Thorslund 3349 ParModelica: Unassigned parglobal output array from parkernel may SegFault ParModelica trunk Future defect Mahder Alemseged Gebremedhin new 2015-06-08T21:06:48Z 2015-06-08T21:06:48Z "If a temporary array (maybe even bigger than available for parlocal) is needed inside a kernel function, it can only be provided using an output variable that's only used internally. If this array is not assigned to an array outside, it may give segmentation fault. Here's a test case: {{{#!mo setCommandLineOptions(""-v=1 +g=ParModelica +d=noevalfunc""); loadString("" package ParTmp constant Integer arrayCnt = 2; parkernel function f parglobal input Real A[arrayCnt]; parglobal output Real B[arrayCnt]; parglobal output Real Tmp[arrayCnt]; algorithm for i in oclGetGlobalId(1):oclGetGlobalSize(1):arrayCnt loop Tmp[i] := A[i]*7; B[i] := Tmp[i]+A[i]; end for; end f; function test input Real d; output Real result[arrayCnt]; protected parglobal Real pResult[arrayCnt]; Real tmp[arrayCnt]; parglobal Real pTmp[arrayCnt]; algorithm for i loop tmp[i] := i; end for; pTmp := tmp; pResult := f(pTmp); result := pResult; end test; end ParTmp; ""); x:=ParTmp.test(4); }}} {{{ Limited backtrace at point of segmentation fault /usr/lib/libpthread.so.0(+0xf870)[0x7f56beb44870] ./ParTmp_test.so(omc_ParTmp_f+0xc2)[0x7f56b22d5862] ./ParTmp_test.so(omc_ParTmp_test+0x22d)[0x7f56b22d54fd] ./ParTmp_test.so(in_ParTmp_test+0x105)[0x7f56b22d5685] /home/gusth/src/OpenModelica/build/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(+0xdfd604)[0x7f56bcdce604] /home/gusth/src/OpenModelica/build/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(DynLoad_executeFunction+0x3d)[0x7f56bcdce7dd] /home/gusth/src/OpenModelica/build/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(omc_CevalScript_cevalCallFunctionEvaluateOrGenerate+0x4f2)[0x7f56bc84f3e2] /home/gusth/src/OpenModelica/build/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(omc_CevalScript_cevalCallFunction+0x47d)[0x7f56bc850c9d] /home/gusth/src/OpenModelica/build/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(omc_BackendInterface_cevalCallFunction+0x5f)[0x7f56bcd8962f] /home/gusth/src/OpenModelica/build/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(omc_Ceval_cevalWork2+0x4ed4)[0x7f56bcd78a04] /home/gusth/src/OpenModelica/build/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(omc_Ceval_cevalWork1+0xc6)[0x7f56bcd7a436] /home/gusth/src/OpenModelica/build/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(omc_Ceval_ceval+0x64)[0x7f56bcd60bd4] /home/gusth/src/OpenModelica/build/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(omc_Ceval_cevalIfConstant+0x271)[0x7f56bcd736f1] /home/gusth/src/OpenModelica/build/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(omc_Static_elabCallArgs3+0x6b3)[0x7f56bcb95b63] /home/gusth/src/OpenModelica/build/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(omc_Static_elabCallArgs2+0xc4d)[0x7f56bcb97fbd] Segmentation fault (core dumped) }}} Tested using my ParModelicaFixes branch on github containing fixes from Mahder, so it may or may not be related to those fixes." Gustaf Thorslund 3350 ParModelica: parkernel and scalar output doesn't work ParModelica trunk Future defect Mahder Alemseged Gebremedhin new 2015-06-08T21:12:49Z 2015-06-08T21:12:49Z "{{{#!mo setCommandLineOptions(""-v=1 +g=ParModelica +d=noevalfunc""); loadString("" package ParScalarOutput constant Integer arrayCnt = 2; parkernel function f parglobal input Real A[arrayCnt]; output Real B; parglobal output Real C; algorithm if oclGetGlobalId(1) == 1 and oclGetGlobalId(2) == 1 and oclGetGlobalId(3) == 1 then B := A[arrayCnt]; C := A[1]; end if; end f; function test input Real d; output Real a; output Real b; protected parglobal Real pResult[arrayCnt]; Real tmp[arrayCnt]; parglobal Real pTmp[arrayCnt]; parglobal Real pB; algorithm for i loop tmp[i] := i; end for; pTmp := tmp; (a,pB) := f(pTmp); b := pB; end test; end ParScalarOutput; ""); (x,y):=ParScalarOutput.test(4); x; y; }}} {{{ - Select your device: 2 :Using flags -I""/home/gusth/src/OpenModelica/build/include/omc/c/"" OpenCL initialization : 5836.392000 ms Kernel Execution : 0.035000 ms Kernel calls: 1, time 0.000035 s, avg 0.035000 ms 6.95326731319017e-310 0.0 }}} Tested using my ParModelicaFixes branch on github containing fixes from Mahder, so it may or may not be related to those fixes. Workaround is to use a parglobal array as output, assign it to a parglobal array, copy to an ordinary array, and finally read the value." Gustaf Thorslund 3370 Add tail recursion optimization for return statements Frontend trunk Future defect somebody new 2015-06-24T08:51:33Z 2015-06-24T08:51:43Z "The following is currently not recognize by the tail recursion optimization: {{{#!mo function f /// ... algorithm if cond then out := f(...); // tail recursive call return; end if; end f; }}}" Martin Sjölund 3383 Issues with Modelica_Noise Beta 1 Backend Backend trunk Future defect Per Östlund assigned 2015-07-17T12:27:35Z 2017-11-14T22:08:53Z "Please get https://github.com/DLR-SR/Noise/tree/MSL (https://github.com/DLR-SR/Noise/archive/MSL.zip) and load package Modelica Modelica_Noise Beta 1. With OpenModelica 1.9.3NightlyBuild from today, the following problems occur: The following models give an error when translating the generated C-Code: simulate(Modelica_Noise.Blocks.Examples.NoiseExamples.GenericNoise) simulate(Modelica_Noise.Blocks.Examples.NoiseExamples.AutomaticSeed) simulate(Modelica_Noise.Blocks.Examples.NoiseExamples.Distributions) simulate(Modelica_Noise.Blocks.Examples.NoiseExamples.UniformNoiseProperties) simulate(Modelica_Noise.Blocks.Examples.NoiseExamples.ImpureGenerator) simulate(Modelica_Noise.Blocks.Examples.NoiseExamples.ActuatorWithNoise) All errors seem to be the same source due to Modelica_Noise.Blocks.Noise.GlobalSeed {{{ function random = Modelica_Noise.Math.Random.Utilities.impureRandom(final id=id_impure) protected parameter Integer id_impure = ...; }}} the ""id_impure variable is claimed to be not defined when defining function random " anonymous 3384 Issues with Modelica_Noise Beta 1 Frontend Frontend trunk Future defect somebody new 2015-07-17T12:32:01Z 2015-08-03T15:01:39Z "Please get ​https://github.com/DLR-SR/Noise/tree/MSL (​https://github.com/DLR-SR/Noise/archive/MSL.zip) and load package Modelica Modelica_Noise Beta 1. With OpenModelica 1.9.3NightlyBuild from today, the following problems occur: Translating {{{ simulate(Modelica_Noise.Blocks.Examples.NoiseExamples.NormalNoiseProperties) simulate(Modelica_Noise.Blocks.Examples.NoiseExamples.WeibullNoiseProperties) }}} gives the following error (unfortunately in German) Variable mu konnte nicht im Geltungsbereich von Modelica_Noise.Blocks.Noise.GenericNoise$noise gefunden werden. The issue seems to be {{{ Blocks.Examples.NoiseExamples.NormalNoiseProperties: model NormalNiseProperties extends UniformNoiseProperties(pMean = mu, var = sigma^2, noise(redeclare function distribution = Modelica_Noise.Math.Distributions.Normal.quantile(mu=mu,sigma=sigma))); parameter Real mu = 3; parameter Real sigma = 1; }}} so propagation of parameters to function calls" martin.otter@… 3390 Issues with unparsing the type of variable in model_init.xml Code Generation trunk Future defect Lennart Ochel new 2015-07-24T18:14:00Z 2015-07-24T18:14:00Z " Reported here: https://openmodelica.org/forum/default-topic/1664-buildmodel-fails-with-template-error-from-codegenutil-tpl We get an error in the CodegenUtil.tpl:207 when building the attached model. I made it to generate a text instead of failing and we get something like this in the XML file: {{{#!xml /* ScalarVariableType: Real[2] */ }}} The variable seems to be an array of two: {{{/* ScalarVariableType: Real[2] */}}} Weirdly enough these variables doesn't seem to be used in the C code, so is maybe just a matter of filtering them out?" Adrian Pop 3397 Sorting of algebraic loops can affect solvability Backend trunk Future defect somebody new 2015-08-04T07:55:37Z 2015-08-04T07:55:37Z "In some cases it is possible to affect the solvability by reorder the variables of an algebraic loop. In the following examples [https://test.openmodelica.org/libraries/PlanarMechanics/files/PlanarMechanics.Examples.KinematicLoop_DynamicStateSelection.err] the reordering of the linear algebraic loops has changed with the commit [https://trac.openmodelica.org/OpenModelica/changeset/25096] and now there is a numerical singularity, while the solving process. So here we have here an instance of an effect that we experienced already sometimes, in order to solve such an issue we need a reordering strategy of algebraic loops in the Backend. Any ideas?" Willi Braun 3406 Problem with initial values / parameters in FMU generation from Simulink FMI trunk Future defect Adeel Asghar new 2015-08-13T07:24:45Z 2015-12-04T17:43:19Z "Dear Sir/Madam, when generating FMUs with the Simulink coder target (2.1.1 patch 15.07.22, see rtwsfcnfmi_ver2.1.1_patch_150722.zip), we face the following problem which can be reproduced by the attached file (const_integrator.zip). We have a very simple Simulink model : a contant value that is integrated. The Constant value and the initial value of the integrator are the parameters of the model. Importing the FMU in Simulink: Initial value of integrator does not have an influence on the result, treated as zero. Importing the FMU in Simulink in OMEdit: Neither of the both parameters (constant value to be integrated, initial value of the integrator) has an influence. Do we make something wrong or where is the bug to be located? Thank you for your support and regards, Antoine Vandamme" antoine.vandamme@… 3411 Compiler does not detect unassigned variable in some cases with if equations MetaModelica trunk Future defect Martin Sjölund new 2015-08-17T13:25:43Z 2015-08-17T13:34:40Z "The compiler does not detect that b3 is not assigned and because of that the behavior is undefined and random. See also [changeset:92eaf4/OMCompiler] {{{ #!mo protected function inlineWhenEq ""inlines function calls in when equations"" input BackendDAE.WhenEquation inWhenEquation; input Inline.Functiontuple fns; input DAE.ElementSource inSource; output BackendDAE.WhenEquation outWhenEquation; output DAE.ElementSource outSource; output Boolean inlined; algorithm (outWhenEquation,outSource,inlined) := matchcontinue(inWhenEquation) local DAE.ComponentRef cref; DAE.Exp e,e_1,cond; BackendDAE.WhenEquation weq,weq_1; DAE.ElementSource source; Boolean b1,b2,b3; list assrtLst; BackendDAE.WhenEquation we, elsewe; Option oelsewe; list whenStmtLst; case BackendDAE.WHEN_STMTS(condition=cond, whenStmtLst=whenStmtLst, elsewhenPart = oelsewe) equation (cond, source, b1,_) = Inline.inlineExp(cond, fns, inSource); (whenStmtLst, b2) = inlineWhenOps(whenStmtLst, fns); if isSome(oelsewe) then SOME(elsewe) = oelsewe; (elsewe, source, b3) = inlineWhenEq(elsewe, fns, source); oelsewe = SOME(elsewe); else oelsewe = NONE(); // the compiler does not detect that b3 is not assigned // b3 = false; end if; then (BackendDAE.WHEN_STMTS(cond, whenStmtLst, oelsewe), source, b1 or b2 or b3); end matchcontinue; end inlineWhenEq; }}}" Adrian Pop 3418 Bad performance of Spice3BenchmarkFourBitBinaryAdder dominating MSL 3.2.1 tests Backend trunk Future defect somebody new 2015-08-24T13:45:25Z 2018-02-09T13:14:34Z "The one model `Modelica.Electrical.Spice3.Examples.Spice3BenchmarkFourBitBinaryAdder` dominates the time needed for testing MSL3.2.1 without producing good results. The C runtime takes 6m40s to simulate that model. Afterwards the verification of 46/47 signals fails. Looking at the results, it appears possible that the C runtime doesn't appropriately adapt to the extreme short `experiment(StopTime=1e-006, Interval=1e-009)`. The C++ code generation takes 4m3s in the Templates phase (opposed to 20s for C code generation). C++ generates code for 171 algebraic loops (two code files for each of them). Many of the loops have a dimension of 1. See: {{{ $ grep _dimAEq OMCpp*FourBit*Algloop*.cpp }}} Many of those are linear (checked Algloop 825, 920, 938, ...). Shouldn't linear algebraic loops of dimension 1 be treated more efficiently?" Adrian Pop 3419 Function signatures for type safe function partial application Code Generation trunk Future defect Lennart Ochel new 2015-08-24T17:53:20Z 2015-08-28T18:18:57Z "OpenModelica boxes arguments of functions that are passed as input to other functions. The actual types of the arguments appear to be only known during the boxing/unboxing operations. This hinders the generation of type safe code. The actual function signatures should be accessible from `PARTEVALFUNCTION` and `FUNCTION_PTR` (see SimCodeTV.mo). See the following example: {{{#!mo partial function part input Real u; output Real y; end part; function func input Real u; input Real v; output Real y; algorithm y := u + v; end func; function feval input part f; input Real u; output Real y; algorithm y := f(u); end feval; model m input Real u = 0; // prevent presolving Real y = feval(function func(v = 2), u + 1); end m; }}} When generating code for `function feval`, the signature of the input `part` should be accessible from the `FUNCTION_PTR` argument. When generating code for `model m`, the signatures of the used function `func` and of the expected `part` should be accessible from `PARTEVALFUNC`. So far only the types of the additional arguments of `func` (v in the example) can be derived from the `expList` contained in `PARTEVALFUNC`. " Rüdiger Franke 3439 Make 3rdParty includes more homogeneous Build Environment trunk Future defect Adrian Pop accepted 2015-09-02T10:51:22Z 2015-09-02T18:39:05Z "We don't seem to have a clear picture on where to install 3rdParty includes. We seem to push them into one of these places: - build/include/omc/c - build/include/omc/cpp sometimes in their own directory sometimes not. We should come up with a clear structure on where to put these includes especially of those libraries that are used by both C and CPP runtimes. For example for ticket #3426 we need sundials but is not clear where to put the includes. If ones looks into the OpenModelica windows installation we seem to have sundials includes twice inside: - build/include/omc/cpp - build/include/omc/cpp/includes " Adrian Pop 3454 Wrong results after the latest back end changes FMI Future defect Lennart Ochel new 2015-09-11T13:39:07Z 2017-11-14T22:08:53Z "There are wrong results for the following two fmu tests after the latest back end changes (#3452): {{{ openmodelica/cppruntime/fmu/modelExchange/1.0/CoupledClutches_FMU1_CPP.mos openmodelica/cppruntime/fmu/modelExchange/2.0/CoupledClutches_FMU2_CPP.mos }}}" Lennart Ochel 3464 Failing variable lookup during array creation Cpp Run-time Future defect Marcus Walther new 2015-09-16T19:26:32Z 2017-11-14T22:08:53Z "Some models from MSL trunk initialize arrays with expressions like `TransformationMatrix`: {{{#!mo function ToSpacePhasor input Real x[:]; ... protected parameter Integer m=size(x, 1); parameter Modelica.SIunits.Angle phi[m]=MultiPhase.Functions.symmetricOrientation(m); parameter Real TransformationMatrix[2, m]=2/m*{+cos(+phi),+sin(+phi)} for k in 1:m}; ... end ToSpacePhasor; }}} The Cpp runtime generates separate createArray functions that don't see the used variables. See e.g. `Modelica.Electrical.Machines.Examples.Transformers.TransformerTestbench`, https://test.openmodelica.org/libraries/MSL_trunk_cpp/BuildModelRecursive.html Shouldn't these functions be removed and the array be created in situ?" Rüdiger Franke 3474 OpenModelica 1.9.3 Installer for Windows 7 - Path Setup Fails Installation program Future defect Adeel Asghar new 2015-09-23T15:27:18Z 2015-10-03T09:28:41Z "When installing OM 1.9.3 with the provided installer, OM is only set-up correctly for the admin user. Other users with non-admin rights are not able to execute e.g. OMEdit (""path"" missing errors). Also, the links in the start menu are missing for non-admin users. I assume that the installer does not setup OM for all users, just for the admin. This behavior has changed since 1.9.2. Sorry, if this is duplicate bug report." hztirf@… 3478 Performance issue for Chemical.Examples.AcidBase.AlbuminTitration Backend Future defect Lennart Ochel accepted 2015-09-26T08:51:47Z 2015-10-13T08:31:32Z https://test.openmodelica.org/libraries/Chemical_Experimental/BuildModelRecursive.html says that Chemical.Examples.AcidBase.AlbuminTitration takes 5400 seconds for the backend, which is incredibly much. The C-code also does not compile due to going beyond the pre-defined 256 level bracket nesting depth. Martin Sjölund 3485 Parameter records are not displayed and cannot be modified in OMEdit GUI Frontend Future defect somebody new 2015-09-29T15:49:40Z 2017-11-14T22:08:53Z "If a model uses parameter records, these records are displayed in the OMEdit GUI as regular parameter entry fields. I attached a sample model of a DC machine to describe the issue using an example. However, the following behavior occurs when double clicking on the DC machine model: * Switch to ""Losses"" and enter ""brushParameters(V=1)"" in the field brushParameters. Click OK * The following code is then inserted {{{...dcpm(...,brushParameters = brushParameters(V = 1))}}}: this is syntactically incorrect Modelica code * When re-opening the DC machine parameter GUI the brushParameters do no appear * Remove {{{,brushParameters = brushParameters(V = 1)}}} from the code * Add syntactically correct in the code {{{...dcpm(...,brushParameters(V = 1))}}} * The model checks fine but again, the no brushParameters appear in the GUI To summarize my investigations, the GUI seems not to be able to handle and display records properly. " Christian Kral 3494 Start values not taken from modelDescription.xml FMI 1.0 Future defect Willi Braun assigned 2015-10-05T06:45:25Z 2020-02-06T15:47:28Z "The start values that are written in the modelDescription.xml are not passed to the FMU before initialization. How to reproduce: - take the bouncing-ball model from testsuite/openmodelica/fmi/ModelExchange/1.0 and export it to FMU 1.0 (either with C or C++ Runtime) - the initial height of the ball is ""1.0"" - change the start-value in the modelDescription.xml to ""2.0"" and repack the FMU - if you now simulate it again, the height still starts at ""1.0"" If I understand the FMI Standard correctly, than the start-values should be taken from the modelDescription.xml and passed to the FMU before the initial system is solved. I know that we are using the FMI-Library to import these stuff and it seems that the library is not passing the start-values if we just call ""fmi1_import_instantiate_model"" and ""fmi1_import_initialize"". " Marcus Walther 3495 Issue with array indices in generated code Code Generation Future defect Mahder Alemseged Gebremedhin accepted 2015-10-07T08:34:37Z 2017-11-14T22:08:53Z "I get the following output by the simulation of a Petri net model: {{{ C:/Users/TKLEIN~1/AppData/Local/Temp/OpenModelica/OMEdit/PNlib2.Examples.TestWkeit.exe -port=51187 -logFormat=xml -override=startTime=0,stopTime=5,stepSize=0.01,tolerance=1e-6,solver=dassl,outputFormat=mat,variableFilter=.* -r=PNlib2.Examples.TestWkeit_res.mat -dasslJacobian=coloredNumerical -w -lv=LOG_STATS scalar s->index[0][0] == 2456744 incorrect, a->dim_size[0] == 2 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Simulation process failed. Exited with code 255. }}}" timo.lask@… 3498 Wrong generation of base partitions Backend Future defect Lennart Ochel reopened 2015-10-07T19:17:33Z 2017-11-14T22:08:53Z "The code generated for the following model does not compile due to the attempt to access the not existing previous(dt). {{{#!mo model SID ""Single Integrator Discrete-time"" parameter Real dt = 0.1 ""sample time"" annotation(Evaluate=true); parameter Real p = 1 ""gain for input""; parameter Real y_start = 0 ""start value for state""; Real xd(start = y_start); input Real u(start = -2); output Real y; equation when Clock(dt) then xd = previous(xd) + p * u * dt; end when; y = hold(previous(xd)); end SID; }}} The sample rate dt should be constant. Instead `omc -s -d=dumpSynchronous SID.mo` gives {{{ Base clocks (1) ======================================== 1: Clock(previous(dt))[1] }}}" Rüdiger Franke 3499 Quasi static fundamental wave machines are not simulating *unknown* Future defect Willi Braun assigned 2015-10-07T20:06:40Z 2016-04-23T13:00:59Z "It is planned for MSL 3.2.2 to include further packages. One of these packages is the {{{Modelica.Magnetic.QuasiStatic.FundamentalWave}}} library. In order to test this library with MSL 3.2.1 I attached the package {{{Modelica_AddOn}}}, which includes all the new packages of MSL 3.2.2. Please test the examples of {{{Modelica_AddOn.Magnetic.QuasiStatic.FundamentalWave.Examples}}}. None of these examples works the actual nightly build version of OpenModelica. I tested the examples with * Ubuntu 14.04 32 bit * OpenModelica 1.9.4~dev-155-ga69 When simulating the models I receive the following error messages: {{{ Matrix singular! under-determined linear system not solvable! }}} I wonder whether this issue is related with #3084." Christian Kral 3511 BackendDAEUtil.tryToSolveOrDerive don't use functionTree Backend Future defect Lennart Ochel assigned 2015-10-14T14:29:01Z 2015-10-16T17:50:40Z "{{{Differentiate.differentiateExpSolve,ExpressionSolve.solve2}}} in tryToSolveOrDerive need for correct handling of functions the functionTree. Example: {{{#!modelica model testTearing function f input Real t; output Real y; algorithm y := 2 * t; end f; Real a annotation(tearingSelect = always); Real b; Real _a annotation(tearingSelect = always); Real _b; equation a = b + f(b); b = sin(a) + 3 * f(b); _a = _b + 2 * _b; _b = sin(_a) + 3 * 2 * _b; end testTearing; }}} It should be possible to find same tearing for {{{a,b}}} loke for {{{_a,_b}}} " Vitalij Ruge 3526 Code generation fails for array in records Code Generation Future defect Lennart Ochel new 2015-10-22T12:17:11Z 2017-11-14T22:08:53Z "Template CodegenUtil.ScalarVariableType failed fort he following model: {{{#!mo model test record R Real r[3]; end R; function f input Real x; output R y; algorithm y.r[1] := 1.0+x; y.r[2] := 2.0+x; y.r[3] := 3.0+x; end f; R x; R y; equation x = y; y = f(time); end test; }}} Maybe this is also related to the module {{{removeSimpleEquations}}}, since the model works fine if it get disabled using {{{--removeSimpleEquations=none}}}." Lennart Ochel 3540 Improve support for exporting FMI for co-simulation FMI Future defect Adrian Pop accepted 2015-11-04T04:59:15Z 2017-11-14T22:08:53Z FMI for co-simulation support is missing. Adrian Pop 3586 FMI import crashes FMI Future defect Lennart Ochel assigned 2015-12-08T08:37:57Z 2019-12-29T20:07:08Z "When I export a MSL exmample to FMI 2.0 for model exchange with Dymola 2016 FD01 an import the fmu with omc the simulation crashes with this error: ""Modelica_Blocks_Examples_PID_0Controller_me_FMU.mo"" """" true """" record SimulationResult resultFile = """", simulationOptions = ""startTime = 0.0, stopTime = 4.0, numberOfIntervals = 500, tolerance = 0.0001, method = 'dassl', fileNamePrefix = 'Modelica_Blocks_Examples_PID_0Controller_me_FMU', options = '', outputFormat = 'mat', variableFilter = '.*', cflags = '', simflags = ''"", messages = ""Simulation execution failed for model: Modelica_Blocks_Examples_PID_0Controller_me_FMU module = Modelica_Blocks_Examples_PID_0Controller, log level = WARNING: [][FMU status:Warning] fmiGetContinuousStates: fmiEnterInitializationMode must be called before calling fmiGetContinuousStates module = Modelica_Blocks_Examples_PID_0Controller, log level = WARNING: [][FMU status:Warning] fmiGetContinuousStates: fmiEnterInitializationMode must be called before calling fmiGetContinuousStates module = Modelica_Blocks_Examples_PID_0Controller, log level = WARNING: [][FMU status:Warning] fmiGetReal: Not allowed before call of fmiEnterInitializationMode module = Modelica_Blocks_Examples_PID_0Controller, log level = WARNING: [][FMU status:Warning] fmiGetEventIndicators: fmiExitInitializationMode must be called before calling fmiGetEventIndicators module = Modelica_Blocks_Examples_PID_0Controller, log level = WARNING: [][FMU status:Warning] model cannot be initialized in current state(2) module = Modelica_Blocks_Examples_PID_0Controller, log level = WARNING: [][FMU status:Warning] fmiExitModelInitializationMode: may only called in initialization mode module = Modelica_Blocks_Examples_PID_0Controller, log level = WARNING: [][FMU status:Warning] model cannot be initialized in current state(2) module = Modelica_Blocks_Examples_PID_0Controller, log level = WARNING: [][FMU status:Warning] fmiExitModelInitializationMode: may only called in initialization mode module = Modelica_Blocks_Examples_PID_0Controller, log level = WARNING: [][FMU status:Warning] model cannot be initialized in current state(2) module = Modelica_Blocks_Examples_PID_0Controller, log level = WARNING: [][FMU status:Warning] fmiExitModelInitializationMode: may only called in initialization mode module = Modelica_Blocks_Examples_PID_0Controller, log level = WARNING: [][FMU status:Warning] model cannot be initialized in current state(2) module = Modelica_Blocks_Examples_PID_0Controller, log level = WARNING: [][FMU status:Warning] fmiExitModelInitializationMode: may only called in initialization mode module = Modelica_Blocks_Examples_PID_0Controller, log level = WARNING: [][FMU status:Warning] model cannot be initialized in current state(2) module = Modelica_Blocks_Examples_PID_0Controller, log level = WARNING: [][FMU status:Warning] fmiExitModelInitializationMode: may only called in initialization mode module = Modelica_Blocks_Examples_PID_0Controller, log level = WARNING: [][FMU status:Warning] model cannot be initialized in current state(2) module = Modelica_Blocks_Examples_PID_0Controller, log level = WARNING: [][FMU status:Warning] fmiExitModelInitializationMode: may only called in initialization mode module = Modelica_Blocks_Examples_PID_0Controller, log level = WARNING: [][FMU status:Warning] model cannot be initialized in current state(2) module = Modelica_Blocks_Examples_PID_0Controller, log level = WARNING: [][FMU status:Warning] fmiExitModelInitializationMode: may only called in initialization mode assert | debug | Solving non-linear system 160 failed at time=0. | | | | For more information please use -lv LOG_NLS. assert | info | simulation terminated by an assertion at initialization "", timeFrontend = 0.04856964748633506, timeBackend = 0.04349024258596179, timeSimCode = 0.0181141241133943, timeTemplates = 0.1261298758561969, timeCompile = 2.619043872252758 end SimulationResult; ""Warning: The initial conditions are not fully specified. Use +d=initialization for more information. Warning: There are iteration variables with default zero start attribute. Use +d=initialization for more information. "" " Niklas Worschech 3598 C++ keywords as a Modelica variable inside of a function Cpp Run-time Future defect Niklas Worschech assigned 2015-12-15T09:11:10Z 2015-12-15T14:06:37Z "It seems that there are some issues similar to #3596 in the Cpp runtime as well. Please checkout following model: {{{#!mo model M function f input Real switch; output Real out = switch; end f; Real r = f(time); end M; }}}" Lennart Ochel 3626 Parameter records are not displayed correctly in OMEdit OMEdit Future defect Adeel Asghar accepted 2016-01-07T18:05:48Z 2016-10-13T12:55:29Z "Please consider the attached example of a DC Machine model, which modifies two parameter records: {{{ ...brushParameters(V = 0.617), frictionParameters(PRef = 0.7162, power_w = 2, wRef = 723.4)... }}} Make a double click on the DC machine model and chose the Losses tab: In the brushParameters field only the number 0.617 appears but it is not clear whether this is ""V"" or ""ILinear"" The frictionParameters filed again shows only one value (723.4) but it is not clear to which element of the record the value belongs to. " Christian Kral 3638 Parameters based on externally read parameters are not calculated correctly Run-time Future defect Willi Braun assigned 2016-01-21T19:22:56Z 2017-11-14T22:08:53Z "Please consider the following example: {{{ model ReadingParameters parameter String inputFile = Modelica.Utilities.Files.loadResource(""modelica://ReadingParameters/input.dat"") ""Input data file""; parameter Modelica.SIunits.Voltage V1 = KeyWordIO.readRealParameter(inputFile, ""V1""); parameter Modelica.SIunits.Voltage V2 = KeyWordIO.readRealParameter(inputFile, ""V2""); final parameter Real n12 = V1 / V2; end ReadingParameters; }}} This example relies on the same library to read parameters from external files, as included in #3625. Please run the attached example. It reads the data file ""input.dat"" from which the values V1 = 1000 and V2 = 100 are obtained. In this case the ratio n12 = V1/V2 is calculated correctly: n12 = 10 Now, in the data file change the second lint to V2 = 1000, make a right click on the result file in the Variable Browser and ""re-simulate"" (not re-compile). Then, the new parameters are read correctly, i.e., V1 = 1000 and V2 = 1000. However, the original parameter n12 = 10 remains unchanged, even though n12 should be equal to 1." Christian Kral 3668 Memory allocation of the back-end and code generation grows quadratically with the system size Backend v1.9.4-dev-nightly Future defect Willi Braun assigned 2016-02-05T18:30:26Z 2016-02-12T18:20:53Z "Consider the attached test package: it has one large algebraic system of equations driven by a scalar differential equation. I have used these settings, which include some that are essential for the efficient handling of the large algebraic system: {{{ setCommandLineOptions(""--preOptModules-=clockPartitioning --postOptModules-=detectJacobianSparsePattern --postOptModules+=wrapFunctionCalls --disableLinearTearing --removeSimpleEquations=new --indexReductionMethod=uode --tearingMethod=omcTearing -d=dumpSimCode,gcProfiling,execstat,nogen,initialization,backenddaeinfo,discreteinfo,stateselection""); simulate(LargeAlgebraic.M_2000, method = ""rungekutta"", stopTime = 1, numberOfIntervals = 10, simflags = ""-lv LOG_STATS,LOG_LS -ls=klu""); }}} Under Windows, the size of memory allocated by the back-end and code generation phases grows approximately as O(N^2^), N being the size of the algebraic system: || N || Memory (MB) || ||2000 || 260 || ||4000 || 1000 || ||6000 || 2000 || Note that the number of non-zero elements in the incidence matrix of the system grows as O(N), as there are 3 non-zero elements in each row. This is not sustainable for systems that have more than a few thousands unknowns. " Francesco Casella 3676 Do some sanity checks on the Windows PATH when building omc Build Environment v1.9.4-dev-nightly Future defect Adrian Pop accepted 2016-02-10T17:29:35Z 2016-02-10T17:29:42Z Sometimes if the user changes their Windows PATH the build will get to some programs it shouldn't and the build process has issues. Make sure we do some checks on the PATH in the Makefile.omdev.mingw. Adrian Pop 3696 Add an OMC API to get and set the redeclare modifiers in extends and components Interactive Environment v1.9.4-dev-nightly Future defect Adrian Pop accepted 2016-02-19T17:46:56Z 2016-02-19T17:50:58Z "Currently we don't support the redeclare modifiers in the query/set API. We need to implement an API for that." Adrian Pop 3700 ModelicaCompliance.Functions.External.CMapping2 fails on test server Run-time v1.9.4-dev-nightly Future defect somebody new 2016-02-20T03:30:35Z 2016-02-20T03:42:00Z "and generates weird non-XML characters: {{{ p was not set correctly, H▒▒d▒% <> E.two. }}} " Adrian Pop 3706 OMEdit does not render some icons Interactive Environment v1.9.4-dev-nightly Future defect Adrian Pop assigned 2016-02-22T13:30:11Z 2017-11-14T22:08:53Z "OMEdit does not render all icons. Has this to do with recent optimizations? Load e.g. Modelica_Synchronous (see github.com/Modelica) Then open Modelica_Synchronous.Examples.RealSignals.Sample1 The icon of assignClock is not shown (see attached screenshot)." Rüdiger Franke 3711 Cpp runtime test recordTupleReturnTest fails if wrapFunctionCalls is enabled Cpp Run-time v1.9.4-dev-nightly Future defect somebody new 2016-02-23T09:40:12Z 2016-02-23T21:02:18Z "I don't really know why the cpp runtime test recordTupleReturnTest fails if post-optimization module wrapFunctionCalls is enabled (just pass {{{--postOptModules+=wrapFunctionCalls}}}). Can someone have a look? BTW: The test fails for c runtime anyway." Lennart Ochel 3712 Print a plot in an OMNotebook OMNotebook v1.11.0 Future defect arunkumar palanisamy reopened 2016-02-23T11:53:21Z 2017-11-14T22:08:53Z Try printing the attached notebook file. Everything is printed nicely except for the plot. Adeel Asghar 3721 Re: FMI 1.0 co-simulation API skeleton. FMI 1.0 v1.9.4-dev-nightly Future defect Adeel Asghar new 2016-02-24T16:34:33Z 2020-02-06T15:50:34Z "https://trac.openmodelica.org/OpenModelica/changeset/e87391212dc31770541528ea6c64dcc6489fb04e/OMCompiler There is a mistake with the structures which is apparent in FMUs created using the C runtime and FMI1 for model exchange. The structure fmiCallbackFunctions and fmiStatus are currently as below. {{{ typedef struct { fmiCallbackLogger logger; fmiCallbackAllocateMemory allocateMemory; fmiCallbackFreeMemory freeMemory; fmiStepFinished stepFinished; } fmiCallbackFunctions; typedef enum {fmiOK, fmiWarning, fmiDiscard, fmiError, fmiFatal, fmiPending} fmiStatus; }}} the fmiStepFinished ONLY exists in the standard for fmi1 co-simulation, yet this same structure is used even for FMUs created for model exchange. An application which supports FMI1 for model exchange will only have the first three callbacks, and this creates a problem when fmiCallbackFunctions is then passed (by value) to fmiInstantiateModel. {{{ DllExport fmiComponent fmiInstantiateModel(fmiString instanceName, fmiString GUID, fmiCallbackFunctions functions, fmiBoolean loggingOn); }}} A caller will observe that all logs will be created, because what likely happens is that their provided value of loggingOn gets used as a (maybe partially complete) function pointer for step finished, and the value of loggingOn is then some garbage. These structure are however defined in FMI1 for co-simulation. tl;dr There must be a mechanism to select the right callback structure depending on whether model-exchange or co-simulation is selected for fmi1 because they are not compatible. As an aside, I know the CPP runtime is configured correctly for this, but it is not currently an option." michael.kobierski@… 3725 loadString merge=true create duplicate elements Interactive Environment v1.9.4-dev-nightly Future defect Adrian Pop accepted 2016-02-25T00:57:09Z 2016-03-17T05:49:55Z Run the attached script. Adeel Asghar 3729 Models of trunk/Modelica that do not simulate in OpenModelica (and are not present in MSL 3.2.1 failed simulations) Run-time v1.9.4-dev-nightly Future defect somebody new 2016-02-28T08:56:17Z 2017-11-14T22:08:53Z "When comparing the simulation results of MSL 3.2.1 with trunk: https://test.openmodelica.org/hudson/job/MSL_3.2.1_Simulation/894/#showFailuresLink, Build #894 (Feb 28, 2016 8:17:37 AM) with https://test.openmodelica.org/hudson/job/MSL_trunk_Simulation/860/#showFailuresLink, Build #860 (Feb 28, 2016 8:22:08 AM) then the following models are either not present in MSL 3.2.1 or simulate in MSL 3.2.1 but not in trunk: {{{ Modelica.Electrical.Analog.Examples.OpAmps.SignalGenerator - Fails with DASSL (nonlinear equation solver fails) - Simulates with Radau5 Modelica.Electrical.Analog.Examples.OpAmps.Multivibrator - Fails with DASSL and Radau5 (nonlinear equation solver fails) - Simulates with trapezoid Modelica.Electrical.Machines.Examples.SynchronousInductionMachines.SMPM_Braking - Fails with DASSL, Radau5, Trapezoid (nonlinear equation solver fails) - Simulates in Dymola, but with a WARNING: You have many state events. It might be due to chattering. Changing Vknee in the diodes from 0 to 0.8 (= more realistic diode model) removes the chattering warning in Dymola (and about 5 times less state events). Modelica.Magnetic.FundamentalWave.Examples.BasicMachines.AIMC_DOL_MultiPhase - Fails with DASSL, Radau5, Trapezoid (nonlinear equation solver fails) Modelica.Magnetic.FundamentalWave.Examples.BasicMachines.SMPM_Inverter_MultiPhase - Fails with DASSL, Radau5, Trapezoid (nonlinear equation solver fails) Modelica.Magnetic.FundamentalWave.Examples.BasicMachines.SMR_Inverter_MultiPhase - Fails with DASSL, Radau5, Trapezoid (linear equation solver fails) Modelica.Fluid.Examples.IncompressibleFluidNetwork - Compilation took too long, so I stopped. - Unclear, because the last change of this model was in 2013, and then this model should fail with MSL 3.2.1 and with trunk, but it fails only in trunk " martin.otter@… 3731 OMEdit creates unnecessary empty Icon and Diagram annotation Interactive Environment v1.9.4-dev-nightly Future defect Adrian Pop assigned 2016-02-29T15:52:58Z 2017-11-14T22:08:53Z "When creating a new class with OMEdit will always add the line ` annotation(Icon, Diagram);` even to classes where this doesn't make sense. It's simply just adds noise to the code which is especially annoying when having your code under version control." Dietmar Winkler 3740 Simulation errors for Modelica trunk Run-time v1.9.4-dev-nightly Future defect somebody new 2016-03-02T17:00:46Z 2017-11-14T22:08:53Z "The following 9 models from MSL trunk compile in OpenModelica 1.9.4-dev.beta2-120 (2016-03-02 03:29), but fail during simulation: Modelica.Electrical.Analog.Examples.OpAmps.SignalGenerator Nonlinear solver failed Modelica.Electrical.Analog.Examples.OpAmps.Multivibrator Nonlinear solver failed Modelica.Electrical.Spice3.Examples.Spice3BenchmarkFourBitBinaryAdder Simulation successful, but fatal error in GC: Too many heap sections; OMEdit crashes Modelica.Magnetic.FundamentalWave.Examples.BasicMachines.AIMC_DOL_MultiPhase Underdetermined linear system Modelica.Magnetic.FundamentalWave.Examples.BasicMachines.SMPM_Inverter_MultiPhase Underdetermined linear system Modelica.Magnetic.FundamentalWave.Examples.BasicMachines.SMR_Inverter_MultiPhase Underdetermined linear system Modelica.Magnetic.QuasiStatic.FundamentalWave.Examples.BasicMachines.InductionMachines.IMC_DOL Underdetermined linear system Modelica.Magnetic.QuasiStatic.FundamentalWave.Examples.BasicMachines.SynchronousMachines.SMEE_Generator Nonlinear solver failed Modelica.Fluid.Examples.IncompressibleFluidNetwork Simulation failure was reported in the nightly check. After 10 minutes of compilation, I got impatient and stop it. " martin.otter@… 3790 Simulation and FMU build using C runtime and MSVC is broken Run-time Future defect Adrian Pop accepted 2016-03-23T00:52:53Z 2017-11-14T22:08:53Z "It seems we have a broken MSVC C runtime. See also: https://www.openmodelica.org/forum/default-topic/1894-fmi-co-simulation-1-0" Adrian Pop 3800 Verification of nightly tests lacking absolute tolerance Testing Framework Future defect Adrian Pop new 2016-03-26T22:54:03Z 2017-11-14T22:08:53Z "There are some examples that fail to verify due to numerical noise. See e.g.: https://test.openmodelica.org/libraries/MSL_trunk/files/Modelica.Electrical.Analog.Examples.CharacteristicThyristors.diff.Ground1.p.i.html The plot reports a relative tolerance of 0.003. An absolute tolerance is missing if e.g. reference 0 vs. actual 4e-7 lets the validation fail." Rüdiger Franke 3810 New runtime flag -overrideSettings Run-time Future defect Lennart Ochel accepted 2016-03-31T19:32:15Z 2016-04-06T08:59:32Z "The two flags {{{–override}}} and {{{-overrideFile}}} are currently used to override settings and parameters/start values. This lead to conflicts if a variable/parameter has the same name as a setting option. Hence, these flags should only be used to override parameters/start values and a new flag, e.g. {{{–overrideSettings}}}, should be introduced to handle setting overrides. This would break some existing OpenModelica scripts. How should we deal with backwards compatibility? " Lennart Ochel 3821 FMU generation - dependend dlls FMI Future defect Adrian Pop accepted 2016-04-06T08:34:41Z 2017-11-14T22:08:53Z Currently we put all the dependent dlls in the binary folder but the FMI standard says that it should be only one dlls which has no dependencies. It should be possible to generate this via source code FMUs. Adrian Pop 3823 Store less information in ElementSource Frontend Future defect Adrian Pop accepted 2016-04-07T05:04:22Z 2017-11-14T22:08:53Z "We store too much information in ElementSource for components and equations and it takes up a lot of memory. We should be able to disable parts of that depending on a flag. Partial work has been already done here: https://github.com/OpenModelica/OMCompiler/pull/657 " Adrian Pop 3832 Wrong min/max attributes for derivatives in equation systems Backend Future defect Lennart Ochel new 2016-04-08T15:06:07Z 2017-11-14T22:08:53Z "Nonlinear solvers can exploit the min/max attributes of variables. The backend introduces additional variables for derivatives. It is good if these variables for der(x) keep nominal attribute of x. They must not keep min and max attributes though. See e.g.: {{{ setCommandLineOptions(""+simCodeTarget=Cpp""); loadModel(Modelica); simulate(Modelica.Fluid.Examples.DrumBoiler.DrumBoiler); }}} The file `OMCppModelica.Fluid.Examples.DrumBoiler.DrumBoilerAlgloop138.cpp:16f` contains {name, nominal, min, max}: {{{ _vars[0] = {""der(evaporator.V_l)"", 1.0, -1e60, 1e60}; _vars[1] = {""der(evaporator.p)"", 1000000.0, 611.657, 100000000.0}; }}} The backend should not provide the min and max attributes of `evaporator.p` for `der(evaporator.p)` because the derivative of the pressure can be negative. " Rüdiger Franke 3840 Incorrect message about cyclic parameters Frontend Future defect somebody new 2016-04-12T05:47:30Z 2017-10-18T14:42:53Z "Simulating {{{TestPackage.Example}}} gives the error {{{ Cyclically dependent constants or parameters found in scope `TestPackage.TestModel` }}} Here is a test model that illustrates the construct we use: {{{ package TestPackage model Example TestModel t(set_a = true, a = 2); end Example; model TestModel parameter Boolean set_a = true ""Set to true to set parameter a""; parameter Real a = b annotation(Dialog(enable=set_a)); parameter Real b = a annotation(Dialog(enable=not set_a)); end TestModel; end TestPackage; }}} I agree that `TestPackage.TestModel` has a cyclic dependency, but when used in `TestPackage.Example`, this dependency is removed by setting `a=2`, hence there is no need to issue the error. A use case for such a construct is `Annex60.Fluid.Chillers.Examples.Carnot_TEva` in which the user can specify a Carnot effectiveness from which the Carnot efficiency is computed, or vice versa, depending on a parameter such as `set_a`. This is used in 15 out of the 20 regression tests of Annex 60 that fail. Can this test be delayed in OpenModelica until the parameters are assigned?" Michael Wetter 3849 Wrong constant evaluation of final parameter arrays in the back-end Backend Future defect Adrian Pop accepted 2016-04-14T15:56:36Z 2017-11-14T22:08:53Z "I have a non-public wind power model that sends an array of zeros to a function instead the of the correct array. The model works with +d=evalparam which forces the evaluation in the front-end. I'm opening this bug so we don't forget about it." Adrian Pop 3876 Connecting pin to wire resuts in crash Frontend v1.9.4-v1.9.x Future defect somebody new 2016-04-29T10:14:02Z 2016-04-29T10:14:02Z "Connecting a pin to a wire results in a crash. The ""wire properties"" are shown but after confirming these, the program breaks down. OS: Windows 10 x64" tobias@… 3886 Identically unit information for states and state derivatives Backend Future defect Lennart Ochel accepted 2016-05-02T20:40:08Z 2016-05-03T06:39:41Z It is really weird that states and their derivatives have the same unit information in OMEdit/OMPlot. Because time is always in seconds, it should be rather easy to determine state derivative unit information by dividing the state unit information by seconds. Lennart Ochel 3899 Make FMU Compile without configure script FMI Future defect Adeel Asghar new 2016-05-10T10:57:47Z 2018-01-09T12:32:42Z "If we assume that the user of the FMU has nothing installed on his system and wants the most bare-bone FMU we could possibly compile, it should be possible to compile the FMU is a standard way: and XML tags have a tag with a list of that we could use to specify all files necessary to compile the FMU (note: this requires OM finding out which these files are at OMC compile-time or reading some structure later). It would be nice if the C-code also worked without setting gcc include directives like `-I include/fmi2`. One problem is of course how to deal with external build projects like ModelicaExternalC. We should still support the configure script though since it takes care of a lot of extras for us." Martin Sjölund 3911 Internal compiler error: Segmentation fault Code Generation Future defect Adrian Pop accepted 2016-05-16T19:18:22Z 2016-05-24T18:11:34Z "Below is the text I saw when the compiling failed. This is a fairly large model (took 5 minutes to translate, 3 more to get to this failure point). I cannot provide the model. WebModel_06inz.c: In function 'WebModel_eqFunction_93667': WebModel_06inz.c:1299806:1: internal compiler error: Segmentation fault } ^ libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. See for instructions. : recipe for target 'WebModel_06inz.o' failed \tools\msys\mingw64\bin\mingw32-make: *** [WebModel_06inz.o] Error 1 Compilation process failed. Exited with code 2." palmer.ap@… 3917 stategraph2 expamples not working Frontend v1.10.0-dev-nightly Future defect Adrian Pop assigned 2016-05-18T16:57:27Z 2016-05-20T16:18:42Z "Application examples are failing in translation phase. Tried ControlledTanks example. Gives the following error related to uniqueRootIndices: [21] 22:21:34 Translation Error [Modelica_StateGraph2: 14992:7-14999:4]: Type mismatch for positional argument 1 in Connections.uniqueRootIndices(roots={local_entry[1].node, local_entry[2].node}). The argument has type: record Modelica_StateGraph2.Internal.Interfaces.Node Boolean suspend; Boolean resume; end Modelica_StateGraph2.Internal.Interfaces.Node;[2] expected type: OpenModelica.Code.VariableName[:] [22] 22:21:34 Translation Error Error occurred while flattening model Modelica_StateGraph2.Examples.Applications.ControlledTanks.ControlledTanks2" rahul.dutta.bits@… 3919 For HPCOM models both the memory_pool GC and the Boehm GC are used Run-time Future defect somebody new 2016-05-19T08:38:06Z 2016-05-19T08:38:06Z "We are using {{{mmc_init_nogc}}} which should use the memory_pool for the HPCOM models but then we're using Boehm GC anyway for things in the runtime system. It should be one or the other but not both of them at the same time. This has issues on OSes which need GC_init called on the main thread such as OSX. " Adrian Pop 3932 Dump DAE directly to stdout Frontend Future defect Martin Sjölund accepted 2016-05-26T14:08:21Z 2018-02-13T06:36:33Z We are able to dump Susan directly to file, so we should also be able to print flat Modelica directly to stdout and avoid using a ton of memory. Martin Sjölund 3934 Support the vendor annotations in translateModel and simulation runtime Interactive Environment Future defect somebody new 2016-05-27T09:54:26Z 2017-11-14T22:08:53Z "We should add support for vendor annotations in translateModel: Flag {{{fX}}} has the form {{{-name}}} or {{{-name=value}}}. Annotation in the model: {{{ __OpenModelica_simulationFlags=(f1 f2 f3 f4) }}} Flags in translateModel {{{ // override f2 from __OpenModelica_simulationFlags translateModel(M, simflags=""f2 f5 f6""); }}} Flags on command line: {{{ # override f3 from __OpenModelica_simulationFlags # override f6 from translateModel ./M -f3 f6 f7 }}} The flags from {{{translateModel}}} should override {{{__OpenModelica_simulationFlags}}} and should be put in the {{{M_init.xml}}} file each flag in its own element under {{{}}}. Example {{{M_init.xml}}} file: {{{#!xml f1 f2 f3 f4 f5 f6 }}} The simulation runtime (M.exe) will read the simulation flags from {{{M_init.xml}}} and apply them before applying the flags given on the command line. See also ticket: #3488 " Adrian Pop 3943 Implement support for daeMode in the C++ runtime Cpp Run-time Future defect Niklas Worschech assigned 2016-05-31T06:05:00Z 2017-11-14T22:08:53Z We have DAE mode for the C runtime implemented by wbraun but we don't yet have support for it in the C++ runtime. This should be added. Adrian Pop 3945 OMC doesn't build with hdf5 1.10 Build Environment v1.10.0-dev-nightly Future defect Martin Sjölund new 2016-05-31T14:17:25Z 2016-06-07T16:40:44Z "ModelicaExternalC is incompatible with the newest release of the hdf5 library, which I have already reported here: [modelica:#2001]. This also causes the build of OMC to fail, since it depends on ModelicaExternalC. Until this is fixed upstream, are there any workarounds for this issue? I tried calling configure with --enable-hdf5=no, but it's not propagated to the ModelicaExternalC configure, and directly calling the ModelicaExternalC configure seems to mess up various paths." Per Östlund 3947 Fix test using SID which is defined in the windows header Cpp Run-time Future defect somebody new 2016-06-02T21:39:23Z 2016-06-02T21:39:23Z "Test: https://github.com/OpenModelica/OpenModelica-testsuite/blob/master/openmodelica/cppruntime/fmu/modelExchange/2.0/testModelDescription.mos uses name SID which is defined in the windows header already which gives errors: https://test.openmodelica.org/hudson/job/OM_Win/lastCompletedBuild/testReport/openmodelica_cppruntime_fmu_modelExchange_2/0/testModelDescription_mos/ I wonder if is possible to avoid name clashes with the common headers." Adrian Pop 3953 simulate(..) returns record instead of string Interactive Environment Future defect somebody new 2016-06-07T14:19:28Z 2016-06-08T09:14:26Z "According the its signature the MOS scripting function `simulate(..)` should return a String. However, (?sometimes?) a record is returned. Consider following MOS script: {{{ #!modelica loadModel(Modelica); res := simulate(Modelica.Blocks.Examples.PID_Controller); print(""A""); print(res); // No error, but this line will be blank? print(""B""); if true then res := simulate(Modelica.Blocks.Examples.PID_Controller); print(res); // Throws an error that a record is passed, but a String is expected else print(""Just to have an else""); end if; }}} The first print doesn't work (but throws no error), the second print fails with a type error (expected String, but got a record). How is the return value of `simulate(..)` supposed to work?" Bernhard Thiele 3957 Simulation errors with hierarchical state machines in Modelica 3.3 Backend v1.10.0-dev-nightly Future defect Bernhard Thiele assigned 2016-06-09T12:32:51Z 2017-11-14T22:08:53Z "Hello all, I am currently doing my Master's thesis and I am building a simple hierarchical state machines with parallel states (see code below) but I have problems when trying to simulate. I get these two errors: Translation Error [c:/dev/OpenModelica/OMCompiler/Compiler/SimCode/SimCodeUtil.mo: 4490:9-4490:145]: Internal error function createSingleWhenEqnCode failed. When equations currently only supported on form v = ... Translation Error [c:/dev/OpenModelica/OMCompiler/Compiler/SimCode/SimCodeUtil.mo: 479:5-479:146]: Internal error function createSimCode failed [Transformation from optimised DAE to simulation code structure failed] Does anyone know where is the problem? Any help will be appreciated. Thanks for your time and help. " tpv9292@… 3965 Support giving alarm time at the command line for rtest and runtests.pl Testing Framework Future defect Adrian Pop accepted 2016-06-17T10:25:38Z 2016-06-17T10:25:51Z "Currently we impose a hardcoded 900 seconds alarm time for tests. To be able to use the same testing framework for big tests this limit should be configurable." Adrian Pop 3976 Setting the locale via scripting does not work Interactive Environment Future defect Adrian Pop accepted 2016-06-24T02:46:23Z 2016-09-21T11:32:23Z "Running test.mos: {{{ setCommandLineOptions(""+locale=en_US""); getErrorString(); loadModel(Modelica); getErrorString(); getInheritedClasses(Modelica.Mechanics.MultiBody.Visualizers.Advanced.Shape); getErrorString(); }}} on a computer with a Swedish locale gives: {{{ IDA-LIU050+adrpo@ida-liu050 MINGW32 ~/dev/OpenModelica/build/bin $ ./omc.exe test.mos true """" true """" {ModelicaServices.Animation.Shape,Modelica.Utilities.Internal.PartialModelicaServices.Animation.PartialShape} ""[c:/bin/cygwin/home/adrpo/dev/OpenModelica/build/lib/omlibrary/Modelica 3.2.2/Mechanics/MultiBody/Visualizers.mo:1979:8-1980:83:writable] Error: PartialModelicaServices ▒r partiell, namnuppslagning ▒r inte till▒tet i partiella klasser. "" }}} Running {{{omc +locale=en_US}}} gives me messages in English. " Adrian Pop 3989 Noise system library examples fail Frontend Future defect somebody new 2016-07-06T14:08:47Z 2016-07-07T14:58:52Z "The noise system library examples such as ""UniformNoise"" all fail with the attached message displayed in the compilation tab. Samples are run on a Windows 7 64bit machine, using standard Windows intaller (OMEdit v1.9.5-dev-20-g6cc344e connected to OpenModelica v1.9.6). I am not very familiar with OpenModelica, but can give additional info if required. " h.j.van.weers@… 3996 Massive slowdown when using generate_icon.py Backend v1.11.0 Future defect Lennart Ochel new 2016-07-13T15:18:00Z 2016-07-13T15:18:00Z "There is some regression bug regarding the API that the [https://github.com/OpenModelica/OMCompiler/blob/master/Examples/generate_icons.py generate_icons.py] script uses that slows down the icon generation by literally an order of magnitude. Hence rendering it almost useless for use in the documentation generation script for larger libraries such as the MSL (currently busy for 3 hours and going). Someone should take a look at this script again to determine if the issues is due to the script itself, its API calls or something entirely else that has changed in OMC." Dietmar Winkler 3997 Missing replacement of identifiers when inlining functions Backend Future defect Adrian Pop assigned 2016-07-15T05:46:47Z 2018-12-12T09:45:48Z "OpenModelica generated unnecessarily large and non-linear equation systems for the PowerSystems library so far. The reason was missing `annotation(Inline=true)` for small one-liner functions. Commit https://github.com/modelica/PowerSystems/commit/61ba3296af8b2ebdcb86adff0c222291a6a820d7 introduces these annotations. In some models the compilation fails due to missing identifier `xx` now. This comes from inlining `PhaseSystems.ThreePhase_dq0.jj`. See an example: {{{#!mo model InlineMatrixFunction function jj ""Vectorized version of j"" input Real[:,:] xx ""array of voltage or current vectors""; output Real[size(xx,1),size(xx,2)] yy ""array of rotated vectors""; algorithm yy := cat(1, {-xx[2,:], xx[1,:]}, zeros(size(xx,1)-2, size(xx,2))); annotation(Inline=true); end jj; Real[3, 1] v = {{1}, {2}, {3}}; Real[3, 1] jv = jj(v); end InlineMatrixFunction; }}} See e.g.: PowerSystems.Examples.Spot.AC3ph.Line PowerSystems.Examples.Spot.TransmissionAC3ph.FaultTline PowerSystems.Examples.Spot.TransmissionAC3ph.Tline Unfortunately the nightly tests don't report `backenddaeinfo`. Shouldn't the nightly tests use the same options for MSL and for other libraries, like PowerSystems? " Rüdiger Franke 3998 OMC does not search in the correct places for libs under Linux Backend v1.11.0 Future defect Martin Sjölund accepted 2016-07-15T07:27:09Z 2017-11-14T22:08:53Z "When working on [https://github.com/modelica/Modelica_DeviceDrivers/issues/114 Modelica_DeviceDrivers gh#114] I tried to run (on OpenModelica 1.11.0~dev-42-g1a73b84 under Ubuntu 16.04 64bit): {{{#!mo model Try4 parameter String mem_name = ""COM4""; import Modelica_DeviceDrivers.Communication.SharedMemory; import Modelica_DeviceDrivers.Communication.SharedMemory_; import Modelica_DeviceDrivers.Packaging.SerialPackager; import Modelica_DeviceDrivers.Packaging.SerialPackager_; protected SharedMemory sm = SharedMemory(mem_name, 16 * 1024); SerialPackager pkg = SerialPackager(); equation SharedMemory_.read(sm, pkg); annotation(uses(Modelica_DeviceDrivers(version=""1.4.4""))); end Try4; }}} which compiles fine and even seems to execute but I got a translation warning: {{{ [4] 09:08:37 Translation Warning [Modelica_DeviceDrivers.Communication.SharedMemory: 17:3-25:17]: Could not find library pthread in either of: /usr/lib/x86_64-linux-gnu/omc/libpthread.a /usr/lib/x86_64-linux-gnu/omc/libpthread.so /usr/lib//libpthread.a /usr/lib//libpthread.so ... }}} the lib actually resides in: {{{ $ locate libpthread.a /usr/lib/x86_64-linux-gnu/libpthread.a /usr/lib32/libpthread.a /usr/libx32/libpthread.a }}} Same goes for `librt`. So OMC should first search `/usr/lib/x86_64-linux-gnu/` then `/usr/lib/x86_64-linux-gnu/omc/` " Dietmar Winkler 4021 Incorrect array indexing in for-loop in algorithm section *unknown* v1.11.0 Future defect somebody new 2016-08-10T05:34:30Z 2016-08-10T05:34:30Z "I get an incorrect result when using array indexing inside the algorithm section and also inside a 'when sample()' section (see .mo file attached). If I comment out the loop at line 45 and replace it with the hand indexed lines starting at line 48 I get the correct result (see attached data-wrong.txt and data-correct.txt). Also, if I replace the 'j' inside the loop with a number I will get a correct (although unusable) result. I'm using: OpenModelica-v1.11.0-dev-54-g4ec62d0-64bit.exe and running from OMEdit. Running on Windows 10." dma@… 4025 Incorrect XML File Export for Shipping Model Backend v1.11.0 Future defect Lennart Ochel new 2016-08-12T19:57:15Z 2016-08-12T19:57:15Z "During export of shipping example FluidHeatFlow_SimpleCooling/Modelica.Thermal.FluidHeatFlow.Examples.SimpleCooling.xml The xml file contains a bug at line 4166: I'm not sure how you can subtract an equation from an equation. FeatureNotFoundException in JModelicaModelDescription Model Editor" tomas.tourikis@… 4057 Cyclic parameter bindings with more than two elements lead to stack overflow in the Frontend Frontend Future defect somebody new 2016-09-28T14:33:36Z 2016-09-28T14:33:36Z "The following model leads to a stack overflow in Inst.updateComponentInEnv: {{{#!mo model parameterBug1 parameter Boolean b1 = true; parameter Integer p1 = p2; parameter Integer p2 = if b1 then p3 else 0; // p2 = p3 parameter Integer p3 = if b1 then 0 else p1; // p3 = 0 equation end parameterBug1; }}} The following works fine: {{{#!mo model parameterBug1 parameter Boolean b1 = true; parameter Integer p1 = if b1 then p2 else 0; // p1 = p2 parameter Integer p2 = if b1 then 0 else p1; // p2 = 0 equation end parameterBug1; }}}" Patrick Täuber 4058 Inconsistent handling of structural parameters Frontend Future defect somebody new 2016-09-28T14:40:23Z 2016-09-28T14:40:23Z "In the following model b1 is detected as a structural parameter and b2 not: {{{#!mo model parameterBug2 parameter Boolean b1 = true; parameter Boolean b2 = true; parameter Integer p1 = if b1 then p2 else 0; parameter Integer p2 = if b2 then 0 else p1; equation end parameterBug2; }}} -d=printStructuralParameters: {{{ ""Notification: The following structural parameters were evaluated in the front-end: b1 }}} Switching the order in the following way leads to b2 detected as structural and not b1: {{{#!mo model parameterBug2 parameter Boolean b2 = true; parameter Boolean b1 = true; parameter Integer p1 = if b1 then p2 else 0; parameter Integer p2 = if b2 then 0 else p1; equation end parameterBug2; }}} -d=printStructuralParameters: {{{ ""Notification: The following structural parameters were evaluated in the front-end: b2 }}}" Patrick Täuber 4068 Failed to configure openmodelica-devel Installation program v1.11.0 Future defect Adeel Asghar new 2016-10-11T09:33:03Z 2016-10-11T17:53:06Z "I am trying to install openmodelica using macports and keep getting this error message . I am using Mac OS X 10.11.6 and have updated XCode. {{{ Error: Failed to configure openmodelica-devel, consult /opt/local/var/macports/build/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/work/openmodelica_1.11.0~dev-192-g1d441b1/config.log Error: org.macports.configure for port openmodelica-devel returned: configure failure: command execution failed Please see the log file for port openmodelica-devel for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/main.log To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets Error: Processing of port openmodelica-devel failed }}}" Makumazan 4076 Really bad performance with big tables *unknown* Future defect somebody new 2016-10-17T15:09:34Z 2017-10-12T22:51:29Z "Flattening and compilation of models including big tables takes a lot of time and a lot of memory. The attached model takes ~4h to compile. Most of the time is spent in functions that test if an expression is constant or in simplifications. " Adrian Pop 4098 inconsistent code for array equation Frontend Future defect somebody new 2016-10-26T16:02:12Z 2016-10-28T11:51:03Z "the following example include the same formulatin but generate different flatt model {{{#!modelica model foo function f input Real x; output Real[2] y; output Real[2] z; algorithm y[1] := 2*x; y[2] := 3*x; z[1] := y[1]*y[2]; z[2] := 3*x; end f; Real [2] y1; Real [2] y2; equation (,y1) = f(time); y2 = f(time).z; end foo; }}} // y2: 2 x single equation // y1: complex equation It's would be greate if we can standardize this. " Vitalij Ruge 4113 $ is invalid in C identifiers Code Generation Future defect Lennart Ochel new 2016-10-28T09:08:03Z 2018-04-13T13:02:09Z "The current C-code still uses dollars in identifiers in order to generate code despite being invalid in C. avr-gcc does not like it, and `-fdollars-in-identifiers` can be used to pass the pre-processor. But the linker cannot handle dollars as symbol names, so we should try to remove the remaining uses of dollar-signs if possible (avr-gcc might be able to compile code anyway since I think we mostly use `$` in preprocessor names, but if they appear in functions we need to fix those)." Martin Sjölund 4121 Recursive type definitions generate no errors MetaModelica Future defect Martin Sjölund new 2016-11-01T06:44:42Z 2016-11-01T06:44:42Z "Having a file containing: {{{#!mo uniontype Resources record R Integer i; end R; end Resources; type Resources = list; // reference itself }}} will generate no error messages, will just fail directly! " Adrian Pop 4122 Simulation fails in OpenModelica, Works in JModelica Backend v1.11.0 Future defect Willi Braun assigned 2016-11-01T20:49:32Z 2016-11-03T08:36:19Z "The attached file produces incorrect (null) results when simulated with OpenModelica but produces a correct result in JModelica. I'm using the OpenModelica-v1.11.0-dev-201-gf2641d7-64bit.exe nightly build (it failed on earlier releases as well). I have attached the Modelica source file, the errors generated during simulation, and a graph of the result produced by JModelica." dma@… 4127 Losing Loop with ArrayEquations?? Backend Future defect somebody new 2016-11-03T23:10:40Z 2016-11-08T09:41:06Z "{{{ loadString("" model foo function f input Real[2] x; output Real[2] y; algorithm y[1] := 2*x[1]^2 + 1; y[2] := 3*x[2]^2 + 2; end f; Real[ 2] y; equation y = f(y); //Loop !? end foo; ""); getErrorString(); simulate(foo); getErrorString(); val(y[1], {0, 0.5, 1}); }}} return wrong results. The loop for `y = f(y)` is missing. " Vitalij Ruge 4133 plot() in OMNotebook does not respect displayUnit OMPlot v1.11.0 Future defect Adeel Asghar new 2016-11-10T14:22:07Z 2016-11-10T14:22:41Z "When I use the plot() function in OMNotebook, which afaict uses OMPlot in the background, any defined displayUnits for plotted variables are not considered, instead it plots the variables in base units. It would be great if OMNotebook would also honor those, in case one already went to the effort to scale variables into a similar range for clear plotting (e.g. pressures with bar vs Pa). The same plot, manually created from within the OMEdit plotting tab, honors displayUnits as expected." Christoph 4149 Cannot instantiate equation in Joystick model Frontend Future defect somebody new 2016-11-22T08:49:52Z 2016-11-22T14:47:46Z "Hi, If you try to simulate Modelica_DeviceDrivers 1.4.4./Blocks/Examples/TestInputJoystick.mo you will get the error message: {{{ Failed to instantiate equation: (AxesRaw, buttons, pOV) = Modelica_DeviceDrivers.InputDevices.GameController_.getData(joystick); }}} Whats the problem in here? Thanks" Volker Waurich 4163 Load/save a DynamicWebbook OMNotebook Future defect Adeel Asghar new 2016-12-02T07:24:17Z 2016-12-02T07:24:17Z The new [http://omwebbook.openmodelica.org/static/DynamicWebbook/index.html DynamicWebbook] really is nice and I want to point it to my non-Modelica friends from engineering. Is there any possibility to locally create an DynamicWebbook and save/load it some kind of permanently to share the link with custom content? On Firefox, the current save button simply prints the site which is not the behaviour I would have expected. anonymous 4180 Make diff algorithm move annotation section to the end OMEdit Future defect Adeel Asghar new 2016-12-13T15:42:55Z 2019-05-17T16:07:26Z Class annotations should be moved to the end of the class, even if this modifies the file... Martin Sjölund 4195 "How to disambiguate ""1/min"" from ""rpm"" vs ""1/60s""?" Frontend Future defect somebody new 2016-12-25T23:04:30Z 2016-12-25T23:22:02Z "Currently we have: {{{ convertUnits(""1/min"", ""rad/s"") -> (true,60.0,0.0) // wrong, just coverts min to seconds convertUnits(""rpm"", ""rad/s"") -> (true,9.549296585513719,0.0) // correct }}} The question is how do we know when is {{{revolutions / minute}}} vs {{{1 / minute}}} as they have exactly the same representation {{{""1/min""}}}?" Adrian Pop 4213 LinearSolver should scale equation system Cpp Run-time Future defect somebody new 2017-01-12T09:42:25Z 2017-01-12T10:10:27Z "The commit [https://github.com/OpenModelica/OMCompiler/commit/cab8786aaf392317662695b24fac2708be3592e7 Separate nonlinear and linear solver] removed the linear solver part from Newton. Unfortunately it also removed the scaling with `fNominal`. Don't know if the optional KLU scales internally. The default DGESV does not seem to do it. Shouldn't a scaling be applied, at least with DGESV? " Rüdiger Franke 4229 Augmented bouncing ball model falls through if exported and imported as FMU FMI Future defect Adeel Asghar new 2017-01-24T12:46:06Z 2017-01-24T17:37:16Z "The following bouncing ball model {{{#!modelica model BouncingBall parameter Real e=0.7 ""coefficient of restitution""; parameter Real g=9.81 ""gravity acceleration""; Real h(start=1) ""height of ball""; Real v ""velocity of ball""; Boolean flying(start=true) ""true, if ball is flying""; equation der(h) = v; der(v) = if flying then -g else 0; flying = not (h <= 0 and v <= 0); when h <= 0.0 then reinit(v, -e*pre(v)); end when; end BouncingBall; }}} avoids the well-known ""fall-through"" effect by the additional logic around the `flying` flag. However if one exports and imports the model by the following MOS script, the ball will fall through. {{{ bb_file_path :=realpath(""BouncingBall.mo""); loadFile(bb_file_path); translateModelFMU(BouncingBall); bb_fmu_file_path := realpath(""BouncingBall.fmu""); imported_fmu_mo_file := importFMU(""BouncingBall.fmu""); loadFile(imported_fmu_mo_file); simulate(BouncingBall_me_FMU, stopTime=3.0,outputFormat=""csv""); }}} [[Image(bouncingballplot.png)]]" Bernhard Thiele 4244 "Redeclared models ""loose"" their connectors" OMEdit Future defect Adeel Asghar new 2017-01-30T21:52:59Z 2017-01-30T22:00:59Z "Please consider the model attached to this ticket. Each of the second connector of {{{ComponentA}}} and {{{ComponentB}}} is created through extends of a single connector class {{{BaseConnectorA}}} and {{{BaseConnectorB}}}, respectively, and adding an additional connector. In the example model {{{ExampleAB}}} a base class is used. {{{componentA}}} and {{{componentB}} are redeclared from the base class model by {{{ComponentA}}} and {{{ComponentB}}}, respectively. In the example modelel {{{ExampleAB}}} the two extended connectors do not appear. When checking the model OpenModelica complains: {{{ Scripting Error Unable to find component componentA.port_b while parsing connection {componentA.port_b,componentB.port_a, """"}. }}} However, the model simulates without problems. Nevertheless this kind of configurations seems to be problematic, as a more complex variant of this applications refuses to compile in OpenModelica... However, the two ""missing"" connectors are shown in the result variable browser. " Christian Kral 4268 Detect case issues in files of Modelica libraries Parser Future defect Martin Sjölund new 2017-02-13T18:23:02Z 2017-02-13T18:23:02Z "Currently we give a vague message if the file case of the package inside the file, the package.order file and the file itself have different cases. We should maybe do a quick check and give a better error message on this." Adrian Pop 4298 OMOptim build on linux amd64 failed due to gcc 6.0 bug 70129 OMOptim v1.12.0 Future defect Adrian Pop new 2017-03-06T02:48:50Z 2018-09-20T01:57:41Z "Compile of OMOptim of latest git pull failed in several files due to problem with: #include_next Failure text aligns with gcc bug 70129. Google search ""workaround for gcc bug 70129"" shows that several other packages have been forced to deal with this issue. Ubuntu Linux amd64 gcc --version gcc (Ubuntu 6.2.0-7ubuntu11) 6.2.0 20161018 Sprinkling #include in: OMOptim/OMOptim/Core/Dymola/Dymola.cpp OMOptim/OMOptim/Core/Dymola/ModPlusDymolaCtrl.cpp OMOptim/OMOptim/Core/FileData/CSV.cpp OMOptim/OMOptim/Core/FileData/LoadOMOptim.h OMOptim/OMOptim/Core/OptObjective.cpp OMOptim/OMOptim/Core/ParetoDominance.cpp OMOptim/OMOptim/Core/Project.cpp OMOptim/OMOptim/GUI/MainWindow.cpp makes the compiler problem go away but can't be a viable long-term solution. " smunns@… 4307 "OMEdit: Icon and Diagram: Silent give up on expression: ""visible = useHeatPort""" OMEdit Future defect Adeel Asghar new 2017-03-13T16:53:36Z 2017-03-13T17:04:15Z "Dear developers, after 1h of investigation I found out, that the expression {{{visible = useHeatPort}}} will result that the Icon or the Diagram will NOT be displayed. It seems that also other users had that problem: [https://www.openmodelica.org/forum/default-topic/1132-icon-does-not-show-in-omedit] Ticket #2081 is about the underlaying feature. My suggestion is to simply ignore that token, show the Icon/Diagram and print out a warning (until #2081 is fixed)." Jan Kokert 4317 Allow $ in component references and type names in mos scripts Parser Future defect Martin Sjölund new 2017-03-15T12:13:04Z 2017-03-15T12:43:14Z "Currently we don't allow the $ char in mos scripts but some of the code we generate for example for parameter sensitivity use the $ sign: https://openmodelica.org/doc/OpenModelicaUsersGuide/latest/parametersensitivity.html The problem is that one cannot use val($x, 0) and any other functions that have a variable name containing $ as input. " Adrian Pop 4328 OMEdit: bug when partial cutting folded annotations and UNDO OMEdit Future defect Adeel Asghar new 2017-03-16T09:33:52Z 2017-03-16T09:33:52Z "I observed a strange bug in OMEdit: 1.) Consider the following line of code (the annotation is folded) {{{Modelica.Electrical.Analog.Basic.Ground ground1 annotation( ...)}}} 2.) Now select this line (without the newline) by placing the cursor under {{{Mod...}}} and (1) press [Shift]+[End] key or (2) press [Shift] key and click on {{{...)}}}. 3.) Then cut the line using [control]+[x] or via the context menu 4.) Undo the last step by using [control]+[z] Result: The code folding icon (little plus) has vanished. It is '''not possible to get it back ''' - you have to '''unload the library''' or restart OMEdit. " Jan Kokert 4352 Choosing record results in setComponentModifierValue error message Interactive Environment Future defect somebody new 2017-03-21T14:20:23Z 2017-04-06T06:58:47Z "Sorry, if this issue was already reported - I searched for it but I couldn't find anything. I observed an error message when I set graphically a record for a parameter. Here an example: 1.) Load the {{{PhotoVolataics}}} system library 2.) Create a new empty model 3.) Insert a solar cell from the library (Components/SimpleCell) 4.) Open the Parameters Dialog of the cell 5.) Choose a solar cell record by typing e.g. {{{PhotoVoltaics.Records.SHARP_NU_S5_E3E()}}} 6.) Click [OK] 7.) Open the Parameters Dialog of the cell a second time 8.) Change nothing, just click [OK] The result is the following error message: {{{ [12] 14:51:10 Scripting Error Unable to set the component modifier value using command setComponentModifierValue(test, cell.moduleData, $Code(=PhotoVolataics.Records.SHARP_NU_S5_E3E())) }}} It seems that the {{{= }}} is not correctly removed. " Jan Kokert 4374 Wrong analysis of linearity due to missing jacobian Backend Future defect Willi Braun new 2017-03-28T12:29:04Z 2017-03-28T12:29:04Z "The Model `Modelica.Electrical.PowerConverters.Examples.ACDC.RectifierBridge2mPulse.ThyristorBridge2mPulse_RLV_Characteristic` from the MSL contains one system which is considered as nonlinear although it is obviously linear: {{{#!mo 1/1 (1): rectifier.thyristor_n.idealThyristor[3].off = rectifier.thyristor_n.idealThyristor[3].s < 0.0 or pre(rectifier.thyristor_n.idealThyristor[3].off) and not rectifier.pre_n[3].y [dynamic] 2/2 (1): rectifier.thyristor_n.i[3] = rectifier.thyristor_n.idealThyristor[3].s * (if rectifier.thyristor_n.idealThyristor[3].off then 1e-05 else 1.0) [dynamic] 3/3 (1): rectifier.thyristor_p.i[3] + (-rectifier.thyristor_n.i[3]) - rectifier.iAC[3] = 0.0 [dynamic] 4/4 (1): multiStarResistance.resistor.i[1] + rectifier.iAC[2] + rectifier.iAC[3] + rectifier.iAC[1] = 0.0 [dynamic] 5/5 (1): rectifier.thyristor_p.i[2] + (-rectifier.thyristor_n.i[2]) - rectifier.iAC[2] = 0.0 [dynamic] 6/6 (1): rectifier.thyristor_n.i[2] = rectifier.thyristor_n.idealThyristor[2].s * (if rectifier.thyristor_n.idealThyristor[2].off then 1e-05 else 1.0) [dynamic] 7/7 (1): rectifier.thyristor_n.idealThyristor[2].off = rectifier.thyristor_n.idealThyristor[2].s < 0.0 or pre(rectifier.thyristor_n.idealThyristor[2].off) and not rectifier.pre_n[2].y [dynamic] 8/8 (1): rectifier.thyristor_n.idealThyristor[2].v = rectifier.thyristor_n.idealThyristor[2].s * (if rectifier.thyristor_n.idealThyristor[2].off then 1.0 else 1e-05) [dynamic] 9/9 (1): rectifier.thyristor_n.idealThyristor[2].v = currentSensor.n.v - rectifier.vAC[2] [dynamic] 10/10 (1): rectifier.thyristor_n.idealThyristor[3].v = currentSensor.n.v - rectifier.vAC[3] [dynamic] 11/11 (1): rectifier.thyristor_n.idealThyristor[3].v = rectifier.thyristor_n.idealThyristor[3].s * (if rectifier.thyristor_n.idealThyristor[3].off then 1.0 else 1e-05) [dynamic] 12/12 (1): rectifier.thyristor_n.idealThyristor[1].v = currentSensor.n.v - rectifier.vAC[1] [dynamic] 13/13 (1): rectifier.thyristor_p.idealThyristor[1].v = rectifier.vAC[1] - rectifier.dc_p.v [dynamic] 14/14 (1): rectifier.thyristor_p.idealThyristor[1].v = rectifier.thyristor_p.idealThyristor[1].s * (if rectifier.thyristor_p.idealThyristor[1].off then 1.0 else 1e-05) [dynamic] 15/15 (1): rectifier.thyristor_p.idealThyristor[1].off = rectifier.thyristor_p.idealThyristor[1].s < 0.0 or pre(rectifier.thyristor_p.idealThyristor[1].off) and not rectifier.pre_p[1].y [dynamic] 16/16 (1): rectifier.thyristor_p.i[1] = rectifier.thyristor_p.idealThyristor[1].s * (if rectifier.thyristor_p.idealThyristor[1].off then 1e-05 else 1.0) [dynamic] 17/17 (1): rectifier.thyristor_p.i[1] + rectifier.thyristor_p.i[2] + rectifier.thyristor_p.i[3] - inductor.i = 0.0 [dynamic] 18/18 (1): rectifier.thyristor_p.i[2] = rectifier.thyristor_p.idealThyristor[2].s * (if rectifier.thyristor_p.idealThyristor[2].off then 1e-05 else 1.0) [dynamic] 19/19 (1): rectifier.thyristor_p.idealThyristor[2].off = rectifier.thyristor_p.idealThyristor[2].s < 0.0 or pre(rectifier.thyristor_p.idealThyristor[2].off) and not rectifier.pre_p[2].y [dynamic] 20/20 (1): rectifier.thyristor_p.idealThyristor[2].v = rectifier.thyristor_p.idealThyristor[2].s * (if rectifier.thyristor_p.idealThyristor[2].off then 1.0 else 1e-05) [dynamic] 21/21 (1): rectifier.thyristor_p.idealThyristor[2].v = rectifier.vAC[2] - rectifier.dc_p.v [dynamic] 22/22 (1): rectifier.thyristor_p.idealThyristor[3].v = rectifier.vAC[3] - rectifier.dc_p.v [dynamic] 23/23 (1): rectifier.thyristor_p.idealThyristor[3].v = rectifier.thyristor_p.idealThyristor[3].s * (if rectifier.thyristor_p.idealThyristor[3].off then 1.0 else 1e-05) [dynamic] 24/24 (1): rectifier.thyristor_p.idealThyristor[3].off = rectifier.thyristor_p.idealThyristor[3].s < 0.0 or pre(rectifier.thyristor_p.idealThyristor[3].off) and not rectifier.pre_p[3].y [dynamic] 25/25 (1): rectifier.thyristor_p.i[3] = rectifier.thyristor_p.idealThyristor[3].s * (if rectifier.thyristor_p.idealThyristor[3].off then 1e-05 else 1.0) [dynamic] 26/26 (1): rectifier.thyristor_p.i[1] + (-rectifier.thyristor_n.i[1]) - rectifier.iAC[1] = 0.0 [dynamic] 27/27 (1): sineVoltage.sineVoltage[1].v = rectifier.vAC[1] - multiStarResistance.resistor.v[1] [dynamic] 28/28 (1): sineVoltage.sineVoltage[2].v = rectifier.vAC[2] - multiStarResistance.resistor.v[1] [dynamic] 29/29 (1): sineVoltage.sineVoltage[3].v = rectifier.vAC[3] - multiStarResistance.resistor.v[1] [dynamic] 30/30 (1): multiStarResistance.resistor.v[1] = 1000000.0 * multiStarResistance.resistor.i[1] [dynamic] 31/31 (1): inductor.i + (-rectifier.thyristor_n.i[1]) - rectifier.thyristor_n.i[3] - rectifier.thyristor_n.i[2] = 0.0 [dynamic] 32/32 (1): rectifier.thyristor_n.i[1] = rectifier.thyristor_n.idealThyristor[1].s * (if rectifier.thyristor_n.idealThyristor[1].off then 1e-05 else 1.0) [dynamic] 33/33 (1): rectifier.thyristor_n.idealThyristor[1].off = rectifier.thyristor_n.idealThyristor[1].s < 0.0 or pre(rectifier.thyristor_n.idealThyristor[1].off) and not rectifier.pre_n[1].y [dynamic] 34/34 (1): rectifier.thyristor_n.idealThyristor[1].v = rectifier.thyristor_n.idealThyristor[1].s * (if rectifier.thyristor_n.idealThyristor[1].off then 1.0 else 1e-05) [dynamic] }}} The linearity is assessed on the basis of the analytical jacobian, which is missing here and therefore leads to a nonlinear ""result"". Since the system does not contain any function call it may has something to do with the pre-operator and is related to [https://trac.openmodelica.org/OpenModelica/ticket/4373 4373]." Patrick Täuber 4411 Odd error-message for over-determined system Backend Future defect Lennart Ochel new 2017-05-03T20:03:20Z 2018-01-08T06:43:09Z "Seems like a bug in verison 1.12.0 of 3 May 2017 {{{#!mo model SpinArtistry import Modelica.SIunits; import Modelica.Mechanics.MultiBody.Frames.Orientation; import Modelica.Mechanics.MultiBody.Frames.axisRotation; import Modelica.Mechanics.MultiBody.Visualizers; import Modelica.Mechanics.MultiBody.Frames; import Modelica.Mechanics.MultiBody.Types.Color; // Running ""simulate"" on this model will result in a // Translation Error ""The given system is mixed-determined. // [index > 3]"" // If you comment/uncomment the following lines to change // the following declaration from a parameter to a constant, // it will succeed. parameter SIunits.AngularVelocity der_angle = 10.0; //constant SIunits.AngularVelocity der_angle = 10.0; //parameter Frames.Orientation Rtilt = Frames.axisRotation(3, -0.7, 0); constant Frames.Orientation Rtilt = Frames.axisRotation(3, -0.7, 0); SIunits.Angle angle; Frames.Orientation R; initial equation angle = 0.0; R = Frames.absoluteRotation(Frames.Orientation(T=identity(3),w={0,der_angle,0}), Rtilt); equation der_angle = der(angle); R = Frames.absoluteRotation(Frames.axisRotation(2, angle, der_angle), Rtilt); end SpinArtistry; }}}" Vestal 4415 package.order file is cleared after duplicate OMEdit v1.11.0 Future defect Oliver Lenord accepted 2017-05-09T12:49:30Z 2017-11-14T22:22:54Z When using the duplicate class command in a package structure various package.order files are modfied and all content removed. Oliver Lenord 4416 Incorrect results are obtained if the residual is overly sensitive to the tear variables. *unknown* v1.11.0 Future defect somebody new 2017-05-12T10:02:04Z 2017-05-16T08:49:56Z "Incorrect results are obtained if the residual is overly sensitive to the tear variables. An example triggering this behavior is available at: https://github.com/baharev/failure-modes-of-tearing/blob/master/tearing_enabled/example_1.mo An in-depth discussion why this is happening is given in Section 3.1 of https://github.com/baharev/failure-modes-of-tearing/blob/master/failure_modes_of_tearing.pdf Note that OpenModelica must fail on this example; that is just unavoidable. The issue here is that OpenModelica does not recognize that it has failed, and incorrectly claims that everything went OK, even though many variables have completely rubbish values. You cannot fix this in the traditional setup. Probably the best thing to do is to substitute the solution vector back into the original system, and check whether the original system is satisfied too. If not, stop and report failure, and tell the user to turn off tearing, and use sparse linear algebra instead. I am available for discussion in person at the 12th International Modelica Conference 2017; I will stay at the Clarion Congress Hotel. " Ali Baharev 4418 Incorrect results are obtained if the residual is insensitive to the tear variables *unknown* v1.11.0 Future defect somebody new 2017-05-12T10:11:44Z 2017-05-16T08:51:34Z "Similar to ticket:4416 but the underlying causes are different, and the tool also shows slightly different behavior. Incorrect results are obtained if the residual is insensitive to the tear variables. An example triggering this behavior is available at: https://github.com/baharev/failure-modes-of-tearing/blob/master/tearing_enabled/example_2.mo An in-depth discussion why this is happening is given in Section 3.2 of https://github.com/baharev/failure-modes-of-tearing/blob/master/failure_modes_of_tearing.pdf Note that OpenModelica must fail on this example; that is just unavoidable. The issue here is that OpenModelica does not recognize that it has failed, and incorrectly claims in the end that everything went OK, even though many variables have rubbish values. It did emit some obscure warnings during the intermediate computations. The warnings hardly tell anything to non-experts. You cannot fix this in the traditional setup. As with ticket 4416, probably the best thing to do is to substitute the solution vector back into the original system, and check whether the original system is satisfied too. If not, stop and report failure, and tell the user to turn off tearing, and use sparse linear algebra instead. I am available for discussion in person at the 12th International Modelica Conference 2017; I will stay at the Clarion Congress Hotel. " Ali Baharev 4420 OpenModelica hangs for minutes on examples that are otherwise solvable in milliseconds Backend v1.11.0 Future defect Patrick Täuber assigned 2017-05-12T10:41:31Z 2017-10-31T10:47:44Z "Example 3: https://github.com/baharev/failure-modes-of-tearing/blob/master/tearing_enabled/example_3.mo of https://github.com/baharev/failure-modes-of-tearing/blob/master/failure_modes_of_tearing.pdf was designed to test the effects of fill-in. The parameter N of the model can be changed. The latest release of Dymola hangs for more than 6 minutes (with N=500) when tearing is enabled, but the situation is slightly better if I disable tearing. OpenModelica on the other hand hangs for reasons that seem to have nothing to do with tearing. I suspect that OpenModelica falls into a so-called O(n^2^) trap, but I failed to track down the exact causes. If you fix this issue, make sure you understand Section 3.3 of the paper too, and test what happens in OpenModelica. In my opinion, applying tearing by default, and without any caution, is the wrong default. A better default would be to check whether tearing eliminated ""sufficiently many"" variables (say, at least 2/3 of all variables AND at least 10 variables, so I propose checking it in both absolute and relative terms). If tearing did not eliminate ""sufficiently many"" variables, disable tearing, and use sparse linear algebra instead, especially if the original problem is sparse. Here, the ""sufficiently many"" is somewhat arbitrary, and one would have to test it on a reasonable benchmark suite; the above 2/3 and 10 were arbitrary. In any case, eliminating just a single variable, and turning an otherwise sparse problem into a completely full problem is not acceptable (and that is precisely what Dymola does). I am available for discussion in person at the 12th International Modelica Conference 2017; I will stay at the Clarion Congress Hotel. " Ali Baharev 4429 Builtin function cardinality is not implemented in Ceval.cevalBuiltinHandler Backend Future defect Adrian Pop new 2017-05-31T10:27:51Z 2017-06-29T06:51:41Z " This leads to problems, e.g. if the binding of a structural parameter contains cardinality. To reproduce such a case please use the ThermoSysPro model `ThermoSysPro.Examples.SimpleExamples.TestCentrifugalPump5.mo`. In the current version of the library there is a workaround, so please remove `annotation(Evaluate=true)` for {{{#!mo parameter Boolean dyn_mech_equation=((cardinality(M) <> 0) and dynamic_mech_equation); }}} in `ThermoSysPro.WaterSteam.Machines.CentrifugalPump.mo`. Since the structural parameter `centrifugalPump.dyn_mech_equation` cannot be evaluated in the frontend due to cardinality function, no branch for the conditional initial equation can be chosen: {{{#!mo Initial Equations (4, 3) ======================================== 1/1 (0): if centrifugalPump.dyn_mech_equation then der(centrifugalPump.w) = 0.0 end if [unknown] ... }}} Thus, during initialization this equation is not considered and removed in ""Simple Equations"". In consequence `$DER.centrifugalPump.w` is solved in another equation which inevitably leads to a division by zero and the model fails. " Patrick Täuber 4430 MDD clocked SerialPackager models fail to translate Backend Future defect Lennart Ochel new 2017-05-31T14:51:08Z 2017-05-31T15:16:39Z "The Modelica Device Drivers examples using clocked SerialPackager blocks fail. I have committed two failing test cases into the testsuite (https://github.com/OpenModelica/OpenModelica-testsuite/pull/644/commits). For example, model `Modelica_DeviceDrivers.ClockedBlocks.Examples.TestSerialPackager` fails with the error message ""Symbolic Error. Too many equations, over-determined system. The model has 100 equation(s) and 99 variable(s)."" Dymola's diagnosis says: ""The DAE has 110 scalar unknowns and 110 scalar equations"" and the model simulates. " Bernhard Thiele 4432 unbalanced if-eqns are not detected *unknown* v1.12.0 Future defect somebody new 2017-06-01T18:05:39Z 2017-10-31T10:09:38Z "Following model is accepted even it is not really balanced. Also the result is really odd. {{{ model ifeqns Real x(start=-1); Real y1,y2; equation der(x) = sin(time); if x > 0 then y1 = x; y2 = 2*y1*x; elseif x > 0.75 then y2 = 2.0; else y2 = 2*x; y1 = 3*x; end if; end ifeqns; }}}" anonymous 4448 ExternData library is not working in OpenModelica Code Generation v1.12.0 Future defect Adrian Pop accepted 2017-06-16T09:14:53Z 2017-11-07T10:12:46Z "The ExternData library works in Dymola and SimulationX, unfortunately, it is currently not working in OpenModelica. The library developed mentioned this in the documentation and suggest a quick fix (https://github.com/tbeu/ExternData). However, the fix does not work in OpenModelica. (please check this discussion board https://github.com/tbeu/ExternData/issues/9#issuecomment-308656184). By using a stand-alone function as suggested by the library developer- package Test extends Modelica.Icons.Package; function __OpenModelica_getReal ""Get scalar Real value from XML file"" extends Modelica.Icons.Function; input String fileName="""" ""File where external data is stored""; input String varName ""Key""; output Real y ""Real value""; protected ExternData.Types.ExternXMLFile xml = ExternData.Types.ExternXMLFile(fileName) ""External XML file object""; algorithm y := ExternData.Functions.XML.getReal(xml=xml, varName=varName); annotation(Inline=false); end __OpenModelica_getReal; model XMLTest ""XML file read test"" extends Modelica.Icons.Example; parameter String fileName = Modelica.Utilities.Files.loadResource(""modelica://ExternData/Resources/Examples/test.xml""); Real test = __OpenModelica_getReal(fileName, ""set1.gain.k""); annotation(experiment(StopTime=1)); end XMLTest; annotation(uses(ExternData(version=""2.2.0""), Modelica(version=""3.2.2""))); end Test; XML test compiles without any error but when I try to run it gives following errors. [1] 10:44:56 Translation Notification [ExternData: 512:7-520:18]: Created directory C:\Users\mrn04\AppData\Local\Temp\/omc_compile_ED_XMLFile_422688 [2] 10:44:56 Translation Notification [ExternData: 512:7-520:18]: cp -a ""C:/OpenModelica1.12.0-dev-64bit/lib/omlibrary/ExternData 2.2.0/Resources""/* ""C:\Users\mrn04\AppData\Local\Temp\/omc_compile_ED_XMLFile_422688"" [3] 10:44:56 Translation Notification [ExternData: 512:7-520:18]: Changed directory to C:/Users/mrn04/AppData/Local/Temp/omc_compile_ED_XMLFile_422688/BuildProjects/autotools [4] 10:44:56 Scripting Error Error opening file: log: No such file or directory. [5] 10:44:56 Translation Error [C:/dev/OpenModelica64bit/OMCompiler/Compiler/SimCode/SimCodeFunctionUtil.mo: 742:9-742:129]: Internal error function elaborateFunction failed for function: function ExternData.Functions.XML.getReal""Inline never"" ""Get scalar Real value from XML file"" input String varName ""Key""; output Real y ""Real value""; input ExternalObject ExternData.Types.ExternXMLFile xml ""External XML file object""; external ""C"" y = ED_getDoubleFromXML(xml, varName); end ExternData.Functions.XML.getReal; [6] 10:44:56 Translation Error [C:/dev/OpenModelica64bit/OMCompiler/Compiler/SimCode/SimCodeUtil.mo: 603:5-603:83]: Internal error Creation of Modelica functions failed. Any kind of help on this issue will be very helpful. Thanks." musa_me4@… 4464 Import FMU Model Description fails for any model not named modelDescription.xml FMI Future defect Alachew Mengist assigned 2017-07-07T12:14:08Z 2017-07-07T12:32:46Z "In OMEdit open `FMI->Import FMU Model Description` and in the upcoming file selector choose the attached file ´modelDescriptionXXX.xml`. The message window will display something like {{{ [8] 14:04:44 Scripting Error module = Cannot open file '/tmp/OpenModelica_bernhard/OMEdit/modelDescription.xml' for parsing, log level = FATAL: FMIXML [9] 14:04:44 Scripting Error The FMU version is unknown. Unknown/Unsupported FMU version. [10] 14:04:44 Scripting Notification adding: modelDescriptionXXX.xml (deflated 49%) }}} Now, rename the file to `modelDescription.xml` and import it again. This time it works. Hence, it seems that importing FMU Model Description fails for any file not named `modelDescription.xml`." Bernhard Thiele 4470 Bad performance of tearing for large scale models Backend Future defect Patrick Täuber new 2017-07-13T12:13:35Z 2017-07-20T12:43:11Z "The execution time for the postOptModule `tearingSystem` is quite bad for large scale models, e.g. from ScalableTestsuite. The situation has been improved a lot by [https://github.com/OpenModelica/OMCompiler/commit/767bebdf198ccf7a8d54afab11440d158ac182d6 removing the loop check] from differentiation. The current times for tearing for the `BreakerNetwork_N_XX` models can be seen here: [https://trac.openmodelica.org/OpenModelica/ticket/3816#comment:11 #3816] The performance should be improved further. I will soon add some more times to compare." Patrick Täuber 4473 MetaModelica: unable to pass tuple types correctly MetaModelica Future defect Martin Sjölund new 2017-07-18T08:43:01Z 2017-07-18T08:43:01Z "I tried to simplify some code and replaced e.g. the following code in {{{ResolveLoops.mo}}}: {{{ protected function getEqPairs ... //old working code: //eqs := List.map(List.flatten(List.map1(vars,Array.getIndexFirst,meT)),Util.tuple31); //new code failing to compile: eqs := List.map(List.map1Flat(vars,Array.getIndexFirst,meT),Util.tuple31); }}} {{{ Error: Type mismatch in assignment in eqs := List.map(List.map1Flat(vars, Array.getIndexFirst, meT), Util.tuple31) of list<#Integer> := list> Error: Type mismatch in pattern eqs expression type: list> pattern type: list<#Integer> }}} " Henning Kiel 4480 Initial conditions are not considered properly when applying Re-simulate OMEdit Future defect Adeel Asghar new 2017-07-29T16:01:17Z 2017-10-05T11:32:03Z "Consider the following example {{{ model ReSimulate Real x; initial equation x=0; equation der(x)=1; end ReSimulate; }}} After the simulation of this example, an input field for the initial condition of the variable {{{x}}} appears in the Plotting tab. When I enter 1 and re-simulate, the result does not change. So obviously, the changed initial condition is not taken into account. If instead the model {{{ model ReSimulate Real x(start=0); equation der(x)=1; end ReSimulate; }}} is used, the change of the initial condition works just fine. " Christian Kral 4497 Overriding a parameter that sets a parameter in a record has no effect *unknown* Future defect somebody new 2017-08-10T01:14:20Z 2017-08-11T09:49:38Z "Consider the following: {{{ record MyRecord Real y; end MyRecord; function InitRecord input Real x; output MyRecord s(y = x); end InitRecord; model test parameter Real t = 1; parameter MyRecord r = InitRecord (t); algorithm print(""t=""+String(t)+"" ""); print(""r.y=""+String(r.y)+""\n""); assert(t== r.y, ""Correct assignment from structure""); end test; }}} When running this with default values of 't', this works as expected. However, when overriding 't' on the command line or via _init.xml, the record's parameter is not updated. In this example program, running the program has an assertion failure: {{{ ./test -override t=2 t=2 r.y=1 assert | warning | The following assertion has been violated during initialization at time 0.000000 | | | | t == r.y assert | error | Correct assignment from structure assert | info | simulation terminated by an assertion at initialization }}} More information: similar test program which assigns an element of an array works correctly, as does assigning a simple scalar parameter. " jwharington@… 4500 Reinit of variables Backend v1.12.0 Future defect Jal Panchal new 2017-08-16T04:36:50Z 2017-08-16T05:35:15Z "I faced a problem while using reinit in my code and I have extracted the essential parts into the code below {{{ model erraticWhenCondition Modelica.Blocks.Sources.Sine sine1(amplitude = 1, freqHz = 0.5) annotation( Placement(visible = true, transformation(origin = {-58, 8}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Real x (start = 1); Real y,z,a,b; equation when sine1.y < 0.8 then reinit(x, 1); end when; when sine1.y > -0.8 then reinit(x ,-1); end when; x = 1; y = x; z = x*1; a = x*(-1); b = x*2; end erraticWhenCondition; }}} What I observed was, x is switching between -1 and 1 correctly, so is y and z. But a and b get constant values of -1 and 2. So either such an equation should raise an error or the calculation must be done rightly for a and b." jal.panchal@… 4501 Rotational display unit not converted correctly Interactive Environment Future defect Adrian Pop assigned 2017-08-16T08:50:46Z 2017-08-16T12:38:38Z "Consider the following model: {{{ model Test Modelica.Mechanics.Rotational.Sources.QuadraticSpeedDependentTorque load( tau_nominal=-100, TorqueDirection=false, w_nominal(displayUnit=""1/min"") = 104.71975511966) annotation(Placement(visible = true, transformation(origin = {-2, 2}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); end Test; }}} In this model the nominal angular velocity is equal to 104.71975511966 rad/s = 1000 1/min. Make a double click on the component {{{load}}} in the Diagram view. Have a look at the attached image: it shows the wrong conversion to 6283.19 1/min. When switching back to rad/s the angular speed is displayed correctly. This issue applies to {{{ OMEdit 1.12.0~dev-329-gf8a7774 Connected to OpenModelica 1.12.0~dev-957-gd3d2a74 Linux Mint 18.2 64bit }}}" Christian Kral 4506 Generating FMU C library with MSVC compiler is broken (RUNTIMEDIR not interpreted) *unknown* Future defect somebody new 2017-09-01T16:13:42Z 2017-09-01T16:13:42Z "Using OpenModelica from git. I have tried to generate a FMU package with C language and MSVC compiler options, both through command line OMCompiler and OMEdit. Both return similar messages: {{{ [2] 13:05:05 Translation Error Error building simulator. Build log: Microsoft (R) Program Maintenance Utility Version 14.00.23506.0 Copyright (C) Microsoft Corporation. All rights reserved. test_FMU.makefile(5) : fatal error U1052: file '$(RUNTIMEDIR)/Makefile.objs' not found Stop. RESULT: 2 }}} It looks like RUNTIMEDIR variable from the makefile is not being unwrapped correctly. " anonymous 4519 Solving equations with a division by zero Backend Future defect assigned 2017-09-11T11:12:55Z 2017-10-04T20:39:59Z "I attached two examples which are current not simulating in OpenModelica. I know these examples should work as they are simulating in Dymola and they have been working in a previous version two years ago (when I developed similar models). Please load the system library ElectroMechanicalDrives to investigate the following two examples. === TestElectroMechanicalDrives When compiling this example the following error message is generated: {{{ stdout | unknown |

DASKR--  AT T (=R1) AND STEPSIZE H (=R2) THE                                    
      In above,  R1 =   0.0000000000000E+00   R2 =   1.6518123698891E-13
DASKR--  NONLINEAR SOLVER FAILED TO CONVERGE                                    
DASKR--  REPEATEDLY OR WITH ABS(H)=HMIN                                         
stdout | error |

Simulation process failed. Exited with code 248.

stdout | info |

The initialization finished successfully without homotopy method.

stdout | warning |

The corrector could not converge.

stdout | warning |

can't continue. time = 0.000000

stdout | info |

model terminate | Integrator failed. | Simulation terminated at time 0

}}} When I remove the inertia, the model simulates OK. This I do not understand... === TestElectroMechanicalDrives2 When compiling this example the following error message is generated: {{{ stdout | error |

Simulation process failed. Exited with code 1.

stdout | info |

The initialization finished successfully without homotopy method.

assert | debug |

division by zero at time 0, (a=0) / (b=0), where divisor b expression is: inertia.w

assert | debug |

division by zero at time 0, (a=0) / (b=0), where divisor b expression is: inertia.w

assert | debug |

division by zero at time 0, (a=0) / (b=0), where divisor b expression is: inertia.w

}}} This issue seems to be related with speed. If I change the offset of the ramp to 1E-3 the example works fine. === Summary The problem seems to be caused by {{{ElectroMechanicalDrives.Components.Rotational.ConstantEfficiency}}}. However, this example should be working and has been working some time ago. As a workaround I wonder if there exists an alternative formulation of the efficiency equations to work with OpenModelica. " anonymous 4524 Simple KeyWordIO example does not work in OM Frontend v1.13.0-dev-nightly Future defect Adrian Pop reopened 2017-09-19T10:40:04Z 2017-10-06T20:04:05Z "Hi, Today I wanted to test the KeyWordIO library with a simple example for my dissertation: {{{ #!modelica model test import KeyWordIO.*; parameter String outputFileName = Modelica.Utilities.Files.loadResource(""modelica://test/myoutput.txt""); Real M[2,2] = [1,2;3,4]; algorithm when initial() then KeyWordIO.writeRealCSV(outputFileName, ""\t"", M); end when; annotation ( uses(KeyWordIO(version = ""0.7.0""))); end test; }}} Unfortunately, the process crashes in the latest nightly build (v1.13.0-dev-27) and also in a version before (v1.12.0-dev-580): {{{ stdout | error |

Process crashed stdout | error |

Process crashed
Simulation process failed. Exited with code -1073741819. }}} Furthermore, it is interesting that it crashed two times... On the compilation tab it says: {{{ test_functions.c: In function 'omc_KeyWordIO_writeRealCSV': test_functions.c:48:10: warning: assignment makes pointer from integer without a cast [-Wint-conversion] tmp5 = tmp6; ^ }}} Maybe these tickets are related: ticket:3638 ticket:4313 I would highly appreciate if this simple example could work. Many thanks in advance!" Jan Kokert 4533 FMIL cannot delete Cpp FMUs binaries FMI Future defect Lennart Ochel assigned 2017-09-27T11:47:46Z 2017-10-06T07:18:01Z "I have no clue why, but the FMILibrary cannot remove the binaries for Cpp FMUs after freeing all resources. The strange thing is, that is works totally fine using the c runtime. I get the following error message using OMFMISimulator for any FMU using Cpp runtime: {{{ rm: cannot remove ‘temp_O3Lzyk/binaries/linux64/me_A_cpp.so’: Input/output error error: module JMPRT: Error removing temp_O3Lzyk (Invalid argument) }}} " Lennart Ochel 4535 Structural singularity related to electric ground placement Backend v1.12.0 Future defect Lennart Ochel new 2017-09-28T16:23:34Z 2017-10-25T08:42:14Z "I've been trying to model three phase inverters (AC-DC converters, similar to the MSL example Modelica.Electrical.PowerConverters.Examples.DCAC.MultiPhaseTwoLevel.MultiPhaseTwoLevel_RL, but using discrete MSL Electrical.Analog and Electrical.Ideal components). I've been hit by Symbolic Warning that some equation sub-system is '''structurally or numerically singular''', and indeed the simulation fails at time 0.0 (unable to solve linear system). I've created a minimal example to reproduce the issue (cf. QuickRInverterSingle.mo file). It has the topology of a single phase inverter, but using resistors instead of switches (to remove any source of error coming from non linear elements). The key aspect is that the AC side is made of '''two inductors with the ground connected between the two'''. This may looks weird, but this mimics the typical three-phase case when the ground is connected to the neutral point. This means that some state variables (inductor currents) are algebraically coupled. Simulation of this model fails, unless the ground is placed somewhere else. Maybe I'm missing something, but I believe that the system should have a solution no matter the placement of the ground. I'm using OpenModelica 1.12.0~dev.alpha1 on Debian stretch." Pierre Haessig 4544 Nested match-statements with tuple outputs causes template error MetaModelica v1.13.0-dev-nightly Future defect Martin Sjölund new 2017-10-05T14:56:52Z 2017-10-05T14:56:52Z "MetaModelica code like this: {{{#!mo (b, s) := match s case ""test"" then match s case ""test"" then (true, ""test""); end match; end match; }}} gives the error: {{{ [CodegenCFunctions.tpl:3547:14-3547:14:writable] Error: Template error: expTypeShort: (Boolean, String). }}}" Per Östlund 4549 Zero size string array Run-time Future defect Willi Braun assigned 2017-10-06T19:44:21Z 2018-04-09T11:55:39Z "When investigating #4524, I stumbled into a problem with zero size string variables of functions. Please consider the following example: {{{ package TestString function zeroSize input Real matrix[:, :] ""Matrix""; input String[:,:] header = fill("""", 0, size(matrix, 2)) ""String matrix""; algorithm Modelica.Utilities.Streams.print(""Size of matrix: "" + String(size(matrix, 1)) + "" x "" + String(size(matrix, 2))); Modelica.Utilities.Streams.print(""Size of header: "" + String(size(header, 1)) + "" x "" + String(size(header, 2))); if size(matrix,2)<>size(header,2) then Modelica.Utilities.Streams.error(""zeroSize: number of columns of matrix (""+String(size(matrix,2))+"") and header (""+String(size(header,2))+"") do not match""); end if; end zeroSize; model TestZeroSize parameter Real M[2,2] = [1,2;3,4]; algorithm when initial() then // zeroSize({{1,2},{3,4}}); zeroSize(M); end when; end TestZeroSize; end TestString; }}} In this example the function {{{zeroSize}}} has the two input variables, {{{matrix}}} and {{{header}}}. Variable {{{header}}} is assigned with a default input: a string zero rows and two columns. The function here just serves as dummy function, logging the dimensions of the two arrays {{{matrix}}} and {{{header}}} and cause an error, in case their number of rows were different. In the test model {{{TestString}}} the function {{{zeroSize}}} is tested. When simulating the modell, the following error is triggered: {{{ stdout | error |

Simulation process failed. Exited with code 255.

stdout | info |

Size of matrix: 2 x 2
stdout | info |

Size of header: 0 x 0
assert | debug |

zeroSize: number of columns of matrix (2) and header (0) do not match

assert | info |

simulation terminated by an assertion at initialization

}}} So apparently the number of columns is not determined correctly in the function call. Now change the test model to: {{{ zeroSize({{1,2},{3,4}}); // zeroSize(M); }}} an re-run the simulation test model: everything works fine with no complaints..." Christian Kral 4559 OmOptim is not starting in Linux OMOptim Future defect Adrian Pop new 2017-10-12T11:59:49Z 2017-10-12T22:15:42Z "When I try to start OMOptim I get the following error message in {{{ OMEdit 1.13.0~dev-7-g5ab8668 Connected to OpenModelica 1.13.0~dev-99-g28a2c18 Linux Mint 18.2 }}} {{{ > OMOptim *** Error in `OMOptim': realloc(): invalid pointer: 0x0000000000908d20 *** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7fd7680437e5] /lib/x86_64-linux-gnu/libc.so.6(realloc+0x348)[0x7fd768050a08] /usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN9QListData7reallocEi+0x1f)[0x7fd76702b9cf] /usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN9QListData6appendEi+0x81)[0x7fd76702baa1] /usr/lib/x86_64-linux-gnu/libQt5Core.so.5(+0x1d6d78)[0x7fd7670f7d78] /usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_Z21qRegisterResourceDataiPKhS0_S0_+0x2e6)[0x7fd7670f3b16] /usr/lib/x86_64-linux-gnu/libQt5Core.so.5(+0x7bcc3)[0x7fd766f9ccc3] /lib64/ld-linux-x86-64.so.2(+0x106ba)[0x7fd76ab826ba] /lib64/ld-linux-x86-64.so.2(+0x107cb)[0x7fd76ab827cb] /lib64/ld-linux-x86-64.so.2(+0xc6a)[0x7fd76ab72c6a] ======= Memory map: ======== 00400000-006f0000 r-xp 00000000 08:03 2248746 /usr/bin/OMOptim 008ef000-00906000 r--p 002ef000 08:03 2248746 /usr/bin/OMOptim 00906000-00909000 rw-p 00306000 08:03 2248746 /usr/bin/OMOptim 00909000-00940000 rw-p 00000000 00:00 0 00aee000-00b20000 rw-p 00000000 00:00 0 [heap] 7fd758000000-7fd758021000 rw-p 00000000 00:00 0 7fd758021000-7fd75c000000 ---p 00000000 00:00 0 7fd75f721000-7fd75f726000 r-xp 00000000 08:03 2237322 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 7fd75f726000-7fd75f925000 ---p 00005000 08:03 2237322 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 7fd75f925000-7fd75f926000 r--p 00004000 08:03 2237322 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 7fd75f926000-7fd75f927000 rw-p 00005000 08:03 2237322 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 7fd75f927000-7fd7611dd000 r-xp 00000000 08:03 2231404 /usr/lib/x86_64-linux-gnu/libicudata.so.55.1 7fd7611dd000-7fd7613dc000 ---p 018b6000 08:03 2231404 /usr/lib/x86_64-linux-gnu/libicudata.so.55.1 7fd7613dc000-7fd7613dd000 r--p 018b5000 08:03 2231404 /usr/lib/x86_64-linux-gnu/libicudata.so.55.1 7fd7613dd000-7fd7613de000 rw-p 018b6000 08:03 2231404 /usr/lib/x86_64-linux-gnu/libicudata.so.55.1 7fd7613de000-7fd7613ee000 r-xp 00000000 08:03 2229440 /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0 7fd7613ee000-7fd7615ed000 ---p 00010000 08:03 2229440 /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0 7fd7615ed000-7fd7615ee000 r--p 0000f000 08:03 2229440 /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0 7fd7615ee000-7fd7615ef000 rw-p 00010000 08:03 2229440 /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0 7fd7615ef000-7fd7615f4000 r-xp 00000000 08:03 2237360 /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1.0.0 7fd7615f4000-7fd7617f3000 ---p 00005000 08:03 2237360 /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1.0.0 7fd7617f3000-7fd7617f4000 r--p 00004000 08:03 2237360 /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1.0.0 7fd7617f4000-7fd7617f5000 rw-p 00005000 08:03 2237360 /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1.0.0 7fd7617f5000-7fd7617f9000 r-xp 00000000 08:03 2238699 /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0.0.0 7fd7617f9000-7fd7619f8000 ---p 00004000 08:03 2238699 /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0.0.0 7fd7619f8000-7fd7619f9000 r--p 00003000 08:03 2238699 /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0.0.0 7fd7619f9000-7fd7619fa000 rw-p 00004000 08:03 2238699 /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0.0.0 7fd7619fa000-7fd761a11000 r-xp 00000000 08:03 2238703 /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0.0.0 7fd761a11000-7fd761c10000 ---p 00017000 08:03 2238703 /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0.0.0 7fd761c10000-7fd761c12000 r--p 00016000 08:03 2238703 /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0.0.0 7fd761c12000-7fd761c13000 rw-p 00018000 08:03 2238703 /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0.0.0 7fd761c13000-7fd761c14000 r-xp 00000000 08:03 2237305 /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1.0.0 7fd761c14000-7fd761e13000 ---p 00001000 08:03 2237305 /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1.0.0 7fd761e13000-7fd761e14000 r--p 00000000 08:03 2237305 /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1.0.0 7fd761e14000-7fd761e15000 rw-p 00001000 08:03 2237305 /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1.0.0 7fd761e15000-7fd761e1a000 r-xp 00000000 08:03 2237326 /usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0 7fd761e1a000-7fd762019000 ---p 00005000 08:03 2237326 /usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0 7fd762019000-7fd76201a000 r--p 00004000 08:03 2237326 /usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0 7fd76201a000-7fd76201b000 rw-p 00005000 08:03 2237326 /usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0 7fd76201b000-7fd76201d000 r-xp 00000000 08:03 2237320 /usr/lib/x86_64-linux-gnu/libXdamage.so.1.1.0 7fd76201d000-7fd76221c000 ---p 00002000 08:03 2237320 /usr/lib/x86_64-linux-gnu/libXdamage.so.1.1.0 7fd76221c000-7fd76221d000 r--p 00001000 08:03 2237320 /usr/lib/x86_64-linux-gnu/libXdamage.so.1.1.0 7fd76221d000-7fd76221e000 rw-p 00002000 08:03 2237320 /usr/lib/x86_64-linux-gnu/libXdamage.so.1.1.0 7fd76221e000-7fd762248000 r-xp 00000000 08:03 2231019 /usr/lib/x86_64-linux-gnu/libglapi.so.0.0.0 7fd762248000-7fd762447000 ---p 0002a000 08:03 2231019 /usr/lib/x86_64-linux-gnu/libglapi.so.0.0.0 7fd762447000-7fd76244b000 r--p 00029000 08:03 2231019 /usr/lib/x86_64-linux-gnu/libglapi.so.0.0.0 7fd76244b000-7fd76244c000 rw-p 0002d000 08:03 2231019 /usr/lib/x86_64-linux-gnu/libglapi.so.0.0.0 7fd76244c000-7fd76244d000 rw-p 00000000 00:00 0 7fd76244d000-7fd76244e000 r-xp 00000000 08:03 2238749 /usr/lib/x86_64-linux-gnu/libxshmfence.so.1.0.0 7fd76244e000-7fd76264e000 ---p 00001000 08:03 2238749 /usr/lib/x86_64-linux-gnu/libxshmfence.so.1.0.0 7fd76264e000-7fd76264f000 r--p 00001000 08:03 2238749 /usr/lib/x86_64-linux-gnu/libxshmfence.so.1.0.0 7fd76264f000-7fd762650000 rw-p 00002000 08:03 2238749 /usr/lib/x86_64-linux-gnu/libxshmfence.so.1.0.0 7fd762650000-7fd762655000 r-xp 00000000 08:03 2238723 /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1.0.0 7fd762655000-7fd762855000 ---p 00005000 08:03 2238723 /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1.0.0 7fd762855000-7fd762856000 r--p 00005000 08:03 2238723 /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1.0.0 7fd762856000-7fd762857000 rw-p 00006000 08:03 2238723 /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1.0.0 7fd762857000-7fd762859000 r-xp 00000000 08:03 2238711 /usr/lib/x86_64-linux-gnu/libxcb-present.so.0.0.0 7fd762859000-7fd762a58000 ---p 00002000 08:03 2238711 /usr/lib/x86_64-linux-gnu/libxcb-present.so.0.0.0 7fd762a58000-7fd762a59000 r--p 00001000 08:03 2238711 /usr/lib/x86_64-linux-gnu/libxcb-present.so.0.0.0 7fd762a59000-7fd762a5a000 rw-p 00002000 08:03 2238711 /usr/lib/x86_64-linux-gnu/libxcb-present.so.0.0.0 7fd762a5a000-7fd762a5c000 r-xp 00000000 08:03 2238701 /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0.0.0 7fd762a5c000-7fd762c5b000 ---p 00002000 08:03 2238701 /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0.0.0 7fd762c5b000-7fd762c5c000 r--p 00001000 08:03 2238701 /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0.0.0 7fd762c5c000-7fd762c5d000 rw-p 00002000 08:03 2238701 /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0.0.0 7fd762c5d000-7fd762c81000 r-xp 00000000 08:03 2229273 /usr/lib/x86_64-linux-gnu/libgraphite2.so.3.0.1 7fd762c81000-7fd762e80000 ---p 00024000 08:03 2229273 /usr/lib/x86_64-linux-gnu/libgraphite2.so.3.0.1 7fd762e80000-7fd762e82000 r--p 00023000 08:03 2229273 /usr/lib/x86_64-linux-gnu/libgraphite2.so.3.0.1 7fd762e82000-7fd762e83000 rw-p 00025000 08:03 2229273 /usr/lib/x86_64-linux-gnu/libgraphite2.so.3.0.1 7fd762e83000-7fd762ea4000 r-xp 00000000 08:03 2238731 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 7fd762ea4000-7fd7630a3000 ---p 00021000 08:03 2238731 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 7fd7630a3000-7fd7630a4000 r--p 00020000 08:03 2238731 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 7fd7630a4000-7fd7630a5000 rw-p 00021000 08:03 2238731 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 7fd7630a5000-7fd7630a9000 r-xp 00000000 08:03 3281426 /lib/x86_64-linux-gnu/libuuid.so.1.3.0 7fd7630a9000-7fd7632a8000 ---p 00004000 08:03 3281426 /lib/x86_64-linux-gnu/libuuid.so.1.3.0 7fd7632a8000-7fd7632a9000 r--p 00003000 08:03 3281426 /lib/x86_64-linux-gnu/libuuid.so.1.3.0 7fd7632a9000-7fd7632aa000 rw-p 00004000 08:03 3281426 /lib/x86_64-linux-gnu/libuuid.so.1.3.0 7fd7632aa000-7fd7632b1000 r-xp 00000000 08:03 2237695 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4 7fd7632b1000-7fd7634b0000 ---p 00007000 08:03 2237695 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4 7fd7634b0000-7fd7634b1000 r--p 00006000 08:03 2237695 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4 7fd7634b1000-7fd7634b2000 rw-p 00007000 08:03 2237695 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4 7fd7634b2000-7fd763520000 r-xp 00000000 08:03 3281656 /lib/x86_64-linux-gnu/libpcre.so.3.13.2 7fd763520000-7fd763720000 ---p 0006e000 08:03 3281656 /lib/x86_64-linux-gnu/libpcre.so.3.13.2 7fd763720000-7fd763721000 r--p 0006e000 08:03 3281656 /lib/x86_64-linux-gnu/libpcre.so.3.13.2 7fd763721000-7fd763722000 rw-p 0006f000 08:03 3281656 /lib/x86_64-linux-gnu/libpcre.so.3.13.2 7fd763722000-7fd763724000 r-xp 00000000 08:03 2237311 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 7fd763724000-7fd763924000 ---p 00002000 08:03 2237311 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 7fd763924000-7fd763925000 r--p 00002000 08:03 2237311 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 7fd763925000-7fd763926000 rw-p 00003000 08:03 2237311 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 7fd763926000-7fd763988000 r-xp 00000000 08:03 2237348 /usr/lib/x86_64-linux-gnu/libXt.so.6.0.0 7fd763988000-7fd763b88000 ---p 00062000 08:03 2237348 /usr/lib/x86_64-linux-gnu/libXt.so.6.0.0 7fd763b88000-7fd763b89000 r--p 00062000 08:03 2237348 /usr/lib/x86_64-linux-gnu/libXt.so.6.0.0 7fd763b89000-7fd763b8e000 rw-p 00063000 08:03 2237348 /usr/lib/x86_64-linux-gnu/libXt.so.6.0.0 7fd763b8e000-7fd763b8f000 rw-p 00000000 00:00 0 7fd763b8f000-7fd763bb5000 r-xp 00000000 08:03 3294958 /lib/x86_64-linux-gnu/libexpat.so.1.6.0 7fd763bb5000-7fd763db5000 ---p 00026000 08:03 3294958 /lib/x86_64-linux-gnu/libexpat.so.1.6.0 7fd763db5000-7fd763db7000 r--p 00026000 08:03 3294958 /lib/x86_64-linux-gnu/libexpat.so.1.6.0 7fd763db7000-7fd763db8000 rw-p 00028000 08:03 3294958 /lib/x86_64-linux-gnu/libexpat.so.1.6.0 7fd763db8000-7fd763e1c000 r-xp 00000000 08:03 2238324 /usr/lib/x86_64-linux-gnu/libpcre16.so.3.13.2 7fd763e1c000-7fd76401c000 ---p 00064000 08:03 2238324 /usr/lib/x86_64-linux-gnu/libpcre16.so.3.13.2 7fd76401c000-7fd76401d000 r--p 00064000 08:03 2238324 /usr/lib/x86_64-linux-gnu/libpcre16.so.3.13.2 7fd76401d000-7fd76401e000 rw-p 00065000 08:03 2238324 /usr/lib/x86_64-linux-gnu/libpcre16.so.3.13.2 7fd76401e000-7fd76419d000 r-xp 00000000 08:03 2232460 /usr/lib/x86_64-linux-gnu/libicuuc.so.55.1 7fd76419d000-7fd76439d000 ---p 0017f000 08:03 2232460 /usr/lib/x86_64-linux-gnu/libicuuc.so.55.1 7fd76439d000-7fd7643ad000 r--p 0017f000 08:03 2232460 /usr/lib/x86_64-linux-gnu/libicuuc.so.55.1 7fd7643ad000-7fd7643ae000 rw-p 0018f000 08:03 2232460 /usr/lib/x86_64-linux-gnu/libicuuc.so.55.1 7fd7643ae000-7fd7643b2000 rw-p 00000000 00:00 0 7fd7643b2000-7fd764604000 r-xp 00000000 08:03 2230925 /usr/lib/x86_64-linux-gnu/libicui18n.so.55.1 7fd764604000-7fd764804000 ---p 00252000 08:03 2230925 /usr/lib/x86_64-linux-gnu/libicui18n.so.55.1 7fd764804000-7fd764813000 r--p 00252000 08:03 2230925 /usr/lib/x86_64-linux-gnu/libicui18n.so.55.1 7fd764813000-7fd764814000 rw-p 00261000 08:03 2230925 /usr/lib/x86_64-linux-gnu/libicui18n.so.55.1 7fd764814000-7fd764882000 r-xp 00000000 08:03 2622539 /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0 7fd764882000-7fd764a81000 ---p 0006e000 08:03 2622539 /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0 7fd764a81000-7fd764a84000 r--p 0006d000 08:03 2622539 /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0 7fd764a84000-7fd764a85000 rw-p 00070000 08:03 2622539 /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0 7fd764a85000-7fd764a86000 rw-p 00000000 00:00 0 7fd764a86000-7fd764ae2000 r-xp 00000000 08:03 2234695 /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0.10000.1 7fd764ae2000-7fd764ce2000 ---p 0005c000 08:03 2234695 /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0.10000.1 7fd764ce2000-7fd764ce3000 r--p 0005c000 08:03 2234695 /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0.10000.1 7fd764ce3000-7fd764ce4000 rw-p 0005d000 08:03 2234695 /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0.10000.1 7fd764ce4000-7fd764ceb000 r-xp 00000000 08:03 3307682 /lib/x86_64-linux-gnu/librt-2.23.so 7fd764ceb000-7fd764eea000 ---p 00007000 08:03 3307682 /lib/x86_64-linux-gnu/librt-2.23.so 7fd764eea000-7fd764eeb000 r--p 00006000 08:03 3307682 /lib/x86_64-linux-gnu/librt-2.23.so 7fd764eeb000-7fd764eec000 rw-p 00007000 08:03 3307682 /lib/x86_64-linux-gnu/librt-2.23.so 7fd764eec000-7fd764eef000 r-xp 00000000 08:03 3307685 /lib/x86_64-linux-gnu/libdl-2.23.so 7fd764eef000-7fd7650ee000 ---p 00003000 08:03 3307685 /lib/x86_64-linux-gnu/libdl-2.23.so 7fd7650ee000-7fd7650ef000 r--p 00002000 08:03 3307685 /lib/x86_64-linux-gnu/libdl-2.23.so 7fd7650ef000-7fd7650f0000 rw-p 00003000 08:03 3307685 /lib/x86_64-linux-gnu/libdl-2.23.so 7fd7650f0000-7fd765225000 r-xp 00000000 08:03 2237307 /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0 7fd765225000-7fd765425000 ---p 00135000 08:03 2237307 /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0 7fd765425000-7fd765426000 r--p 00135000 08:03 2237307 /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0 7fd765426000-7fd76542a000 rw-p 00136000 08:03 2237307 /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0 7fd76542a000-7fd76543b000 r-xp 00000000 08:03 2237324 /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0 7fd76543b000-7fd76563a000 ---p 00011000 08:03 2237324 /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0 7fd76563a000-7fd76563b000 r--p 00010000 08:03 2237324 /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0 7fd76563b000-7fd76563c000 rw-p 00011000 08:03 2237324 /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0 7fd76563c000-7fd765645000 r-xp 00000000 08:03 2237344 /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 7fd765645000-7fd765844000 ---p 00009000 08:03 2237344 /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 7fd765844000-7fd765845000 r--p 00008000 08:03 2237344 /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 7fd765845000-7fd765846000 rw-p 00009000 08:03 2237344 /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 7fd765846000-7fd765855000 r-xp 00000000 08:03 2237332 /usr/lib/x86_64-linux-gnu/libXi.so.6.1.0 7fd765855000-7fd765a54000 ---p 0000f000 08:03 2237332 /usr/lib/x86_64-linux-gnu/libXi.so.6.1.0 7fd765a54000-7fd765a55000 r--p 0000e000 08:03 2237332 /usr/lib/x86_64-linux-gnu/libXi.so.6.1.0 7fd765a55000-7fd765a56000 rw-p 0000f000 08:03 2237332 /usr/lib/x86_64-linux-gnu/libXi.so.6.1.0 7fd765a56000-7fd765a6c000 r-xp 00000000 08:03 2237169 /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0 7fd765a6c000-7fd765c6b000 ---p 00016000 08:03 2237169 /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0 7fd765c6b000-7fd765c6c000 r--p 00015000 08:03 2237169 /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0 7fd765c6c000-7fd765c6d000 rw-p 00016000 08:03 2237169 /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0 7fd765c6d000-7fd765c70000 rw-p 00000000 00:00 0 7fd765c70000-7fd765c77000 r-xp 00000000 08:03 2237303 /usr/lib/x86_64-linux-gnu/libSM.so.6.0.1 7fd765c77000-7fd765e76000 ---p 00007000 08:03 2237303 /usr/lib/x86_64-linux-gnu/libSM.so.6.0.1 7fd765e76000-7fd765e77000 r--p 00006000 08:03 2237303 /usr/lib/x86_64-linux-gnu/libSM.so.6.0.1 7fd765e77000-7fd765e78000 rw-p 00007000 08:03 2237303 /usr/lib/x86_64-linux-gnu/libSM.so.6.0.1 7fd765e78000-7fd765eca000 r-xp 00000000 08:03 2235295 /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2 7fd765eca000-7fd7660c9000 ---p 00052000 08:03 2235295 /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2 7fd7660c9000-7fd7660ca000 r--p 00051000 08:03 2235295 /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2 7fd7660ca000-7fd7660cb000 rw-p 00052000 08:03 2235295 /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2 7fd7660cb000-7fd76616f000 r-xp 00000000 08:03 2254278 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.12.1 7fd76616f000-7fd76636e000 ---p 000a4000 08:03 2254278 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.12.1 7fd76636e000-7fd766374000 r--p 000a3000 08:03 2254278 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.12.1 7fd766374000-7fd766375000 rw-p 000a9000 08:03 2254278 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.12.1 7fd766375000-7fd76638e000 r-xp 00000000 08:03 3294972 /lib/x86_64-linux-gnu/libz.so.1.2.8 7fd76638e000-7fd76658d000 ---p 00019000 08:03 3294972 /lib/x86_64-linux-gnu/libz.so.1.2.8 7fd76658d000-7fd76658e000 r--p 00018000 08:03 3294972 /lib/x86_64-linux-gnu/libz.so.1.2.8 7fd76658e000-7fd76658f000 rw-p 00019000 08:03 3294972 /lib/x86_64-linux-gnu/libz.so.1.2.8 7fd76658f000-7fd7665b3000 r-xp 00000000 08:03 3281668 /lib/x86_64-linux-gnu/libpng12.so.0.54.0 7fd7665b3000-7fd7667b2000 ---p 00024000 08:03 3281668 /lib/x86_64-linux-gnu/libpng12.so.0.54.0 7fd7667b2000-7fd7667b3000 r--p 00023000 08:03 3281668 /lib/x86_64-linux-gnu/libpng12.so.0.54.0 7fd7667b3000-7fd7667b4000 rw-p 00024000 08:03 3281668 /lib/x86_64-linux-gnu/libpng12.so.0.54.0 7fd7667b4000-7fd7668c3000 r-xp 00000000 08:03 3288352 /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.2 7fd7668c3000-7fd766ac2000 ---p 0010f000 08:03 3288352 /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.2 7fd766ac2000-7fd766ac3000 r--p 0010e000 08:03 3288352 /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.2 7fd766ac3000-7fd766ac4000 rw-p 0010f000 08:03 3288352 /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.2 7fd766ac4000-7fd766ac5000 rw-p 00000000 00:00 0 7fd766ac5000-7fd766adc000 r-xp 00000000 08:03 2237420 /usr/lib/x86_64-linux-gnu/libaudio.so.2.4 7fd766adc000-7fd766cdc000 ---p 00017000 08:03 2237420 /usr/lib/x86_64-linux-gnu/libaudio.so.2.4 7fd766cdc000-7fd766cdd000 r--p 00017000 08:03 2237420 /usr/lib/x86_64-linux-gnu/libaudio.so.2.4 7fd766cdd000-7fd766cde000 rw-p 00018000 08:03 2237420 /usr/lib/x86_64-linux-gnu/libaudio.so.2.4 7fd766cde000-7fd766d1b000 r-xp 00000000 08:03 2231153 /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.9.0 7fd766d1b000-7fd766f1a000 ---p 0003d000 08:03 2231153 /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.9.0 7fd766f1a000-7fd766f1c000 r--p 0003c000 08:03 2231153 /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.9.0 7fd766f1c000-7fd766f21000 rw-p 0003e000 08:03 2231153 /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.9.0 7fd766f21000-7fd7673e6000 r-xp 00000000 08:03 2229052 /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1 7fd7673e6000-7fd7673f2000 r--p 004c4000 08:03 2229052 /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1 7fd7673f2000-7fd7673f3000 rw-p 004d0000 08:03 2229052 /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1 7fd7673f3000-7fd7673f7000 rw-p 00000000 00:00 0 7fd7673f7000-7fd76791e000 r-xp 00000000 08:03 2233879 /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.5.1 7fd76791e000-7fd76791f000 ---p 00527000 08:03 2233879 /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.5.1 7fd76791f000-7fd767934000 r--p 00527000 08:03 2233879 /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.5.1 7fd767934000-7fd76793a000 rw-p 0053c000 08:03 2233879 /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.5.1 7fd76793a000-7fd76793f000 rw-p 00000000 00:00 0 7fd76793f000-7fd767f98000 r-xp 00000000 08:03 2233884 /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.5.1 7fd767f98000-7fd767fc6000 r--p 00658000 08:03 2233884 /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.5.1 7fd767fc6000-7fd767fcb000 rw-p 00686000 08:03 2233884 /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.5.1 7fd767fcb000-7fd767fcc000 rw-p 00000000 00:00 0 7fd767fcc000-7fd76818c000 r-xp 00000000 08:03 3307696 /lib/x86_64-linux-gnu/libc-2.23.so 7fd76818c000-7fd76838c000 ---p 001c0000 08:03 3307696 /lib/x86_64-linux-gnu/libc-2.23.so 7fd76838c000-7fd768390000 r--p 001c0000 08:03 3307696 /lib/x86_64-linux-gnu/libc-2.23.so 7fd768390000-7fd768392000 rw-p 001c4000 08:03 3307696 /lib/x86_64-linux-gnu/libc-2.23.so 7fd768392000-7fd768396000 rw-p 00000000 00:00 0 7fd768396000-7fd7683ac000 r-xp 00000000 08:03 3281565 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fd7683ac000-7fd7685ab000 ---p 00016000 08:03 3281565 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fd7685ab000-7fd7685ac000 rw-p 00015000 08:03 3281565 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fd7685ac000-7fd7686b4000 r-xp 00000000 08:03 3307691 /lib/x86_64-linux-gnu/libm-2.23.so 7fd7686b4000-7fd7688b3000 ---p 00108000 08:03 3307691 /lib/x86_64-linux-gnu/libm-2.23.so 7fd7688b3000-7fd7688b4000 r--p 00107000 08:03 3307691 /lib/x86_64-linux-gnu/libm-2.23.so 7fd7688b4000-7fd7688b5000 rw-p 00108000 08:03 3307691 /lib/x86_64-linux-gnu/libm-2.23.so 7fd7688b5000-7fd768a27000 r-xp 00000000 08:03 2230338 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21 7fd768a27000-7fd768c27000 ---p 00172000 08:03 2230338 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21 7fd768c27000-7fd768c31000 r--p 00172000 08:03 2230338 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21 7fd768c31000-7fd768c33000 rw-p 0017c000 08:03 2230338 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21 7fd768c33000-7fd768c37000 rw-p 00000000 00:00 0 7fd768c37000-7fd768c4f000 r-xp 00000000 08:03 3307679 /lib/x86_64-linux-gnu/libpthread-2.23.so 7fd768c4f000-7fd768e4e000 ---p 00018000 08:03 3307679 /lib/x86_64-linux-gnu/libpthread-2.23.so 7fd768e4e000-7fd768e4f000 r--p 00017000 08:03 3307679 /lib/x86_64-linux-gnu/libpthread-2.23.so 7fd768e4f000-7fd768e50000 rw-p 00018000 08:03 3307679 /lib/x86_64-linux-gnu/libpthread-2.23.so 7fd768e50000-7fd768e54000 rw-p 00000000 00:00 0 7fd768e54000-7fd76913b000 r-xp 00000000 08:03 2237251 /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.7Aborted }}}" Christian Kral 4560 BackendDAE.adjacencyRowEnhanced fails with array function Backend Future defect Lennart Ochel new 2017-10-12T14:17:27Z 2017-10-12T14:17:27Z "{{{ loadString("" package ticket4545 model Test_vector Real x[2](each start = 0, each fixed = true); discrete Real u[2](each start = 0, each fixed = true); Real y[2]; Real d; function f input Real x[2]; input Real y1; input Real y2; output Real outA[2]; output Real out; algorithm for i in 1:2 loop outA[i] := 3*x[i] - y1*y2; end for; out := sum(outA); end f; equation for i in 1:2 loop der(x[i]) = u[i]+y[i]; y[i] = 0.5*x[i]; end for; algorithm (u, d) := f(x, y[1], y[2]); when sample(0,1) then for i in 1:2 loop u[i] := u[i] - y[i]; end for; end when; end Test_vector; end ticket4545; ""); getErrorString(); simulate(ticket4545.Test_vector); getErrorString(); }}} ErrorString: {{{ ""Notification: It was not possible to check the given initialization system for consistency symbolically, because the relevant equations are part of an algebraic loop. This is not supported yet. Error: Internal error BackendDAE.adjacencyRowEnhanced failed for eqn: algorithm (u, d) := ticket4545.Test_vector.f({x[1], x[2]}, y[1], y[2]); $whenCondition1 := false; Error: Internal error BackendDAEUtil.getAdjacencyMatrixEnhancedScalar failed }}} " Willi Braun 4587 Running Hudson PR with testsuite hash and force lastest generates invalid OpenModelica glue project Build Environment Future defect Martin Sjölund new 2017-10-24T15:36:56Z 2017-10-25T12:35:26Z "Whenever libraries change we might get issues with the testsuite. I update the testsuite then I run the Hudson PR job with testsuite hash, force latest and PUSH and that somehow updates also the OMCompiler to the hash that is ONLY present on asap.openmodelica.org repository! I guess we should check if the local hash is also present in the github repo." Adrian Pop 4591 partitionIndependentBlocksEq stack overflow Backend Future defect Lennart Ochel new 2017-10-26T08:35:57Z 2017-10-26T08:35:57Z "partitionIndependentBlocksEq / partitionIndependentBlocksReq can get stack overflows if there is a huge number of independent blocks, for example with N=25600 in ScalableTestSuite.Thermal.Advection.ScaledExperiments.SimpleAdvection_N_25600 with clang debugging flags enabled. One idea would be to have additional work arrays where we can put elements to visit... The problem is to do this without allocating a lot of data." Martin Sjölund 4631 FMU clash with IPython and PyFMI (JSON involved) FMI v1.12.0 Future defect Lennart Ochel new 2017-11-16T08:35:13Z 2018-09-13T15:11:51Z "Trying to load an FMU compiled by omc (OpenModelica's compiler) with PyFMI provoke a nasty crash under IPython. Running import pyfmi pyfmi.load_fmu(""path/to/fmu"") makes IPython crash with message JSON object expected ',' or '}', got: ""lineEnd"":67,""colSta Aborted (core dumped) I tried both IPython 5.4 and 4.2, for Python 2.7.13 (Anaconda 64-bit) on Ubuntu 16.04. An example FMU for reproducing the bug can be found here: https://trac.fmi-standard.org/browser/branches/public/Test_FMUs/FMI_2.0/... This seems to be specific to OpenModelica as a JModelica compiled FMU (https://trac.fmi-standard.org/browser/branches/public/Test_FMUs/FMI_2.0/...) does not trigger the error. Both FMUs pass the FMU compliance check. Do you have any idea about the problem's root and how to solve it? I already experienced segfaults with older version of OpenModelica, as mentionned here: http://www.jmodelica.org/27816. They were however rare enough to be only a nuisance, not a show stopper." anonymous 4698 OMPython + 'Failed to build model: BouncingBall' *unknown* Future defect somebody new 2017-12-25T20:40:06Z 2018-01-02T14:07:24Z "Trying to use OMPython to simulate Modelica Models. I tried the example in the help and it failed. Below are the sequence of commands. Not sure what is wrong. Please help. Thanks In [2]: from OMPython import OMCSessionZMQ ...: omc = OMCSessionZMQ() 2017-12-25 15:33:30,137 - OMPython - INFO - OMC Server is up and running at file:///C:/Users/msoli/AppData/Local/Temp/openmodelica.port.dbdec2bfec4f4db88c5a79f56907c637 In [3]: omc.sendExpression(""getVersion()"") Out[3]: 'v1.12.0 (64-bit)' In [4]: omc.sendExpression(""cd()"") Out[4]: 'C:/Program Files (x86)/Microsoft Visual Studio/Shared/Anaconda3_64' In [5]: omc.sendExpression(""loadModel(Modelica)"") Out[5]: True In [6]: omc.sendExpression(""loadFile(getInstallationDirectoryPath() + \""/share/doc/omc/testmodels/BouncingBall.mo\"")"") Out[6]: True In [7]: omc.sendExpression(""instantiateModel(BouncingBall)"") Out[7]: 'class BouncingBall\n parameter Real e = 0.7 ""coefficient of restitution"";\n parameter Real g = 9.810000000000001 ""gravity acceleration"";\n Real h(start = 1.0) ""height of ball"";\n Real v ""velocity of ball"";\n Boolean flying(start = true) ""true, if ball is flying"";\n Boolean impact;\n Real v_new;\n Integer foo;\nequation\n impact = h <= 0.0;\n foo = if impact then 1 else 2;\n der(v) = if flying then -g else 0.0;\n der(h) = v;\n when {h <= 0.0 and v <= 0.0, impact} then\n v_new = if edge(impact) then (-e) * pre(v) else 0.0;\n flying = v_new > 0.0;\n reinit(v, v_new);\n end when;\nend BouncingBall;\n' In [8]: omc.sendExpression(""simulate(BouncingBall, stopTime=3.0)"") Out[8]: {'messages': 'Failed to build model: BouncingBall', 'resultFile': '', 'simulationOptions': ""startTime = 0.0, stopTime = 3.0, numberOfIntervals = 500, tolerance = 1e-006, method = 'dassl', fileNamePrefix = 'BouncingBall', options = '', outputFormat = 'mat', variableFilter = '.*', cflags = '', simflags = ''"", 'timeBackend': 0.0, 'timeCompile': 0.0, 'timeFrontend': 0.0, 'timeSimCode': 0.0, 'timeSimulation': 0.0, 'timeTemplates': 0.0, 'timeTotal': 0.0}" msoliman.w@… 4700 statealias elimination breaks models Backend Future defect Volker Waurich new 2018-01-05T06:34:53Z 2018-01-11T08:42:55Z "The removing of state-alias in {{{https://github.com/OpenModelica/OMCompiler/commit/f37e0292c}}} breaks some models: {{{https://libraries.openmodelica.org/branches/history/master/2017-12-13%2009:34:42..2017-12-13%2017:25:42.html}}}" Volker Waurich 4707 Wrong symbols naming in FMU import library FMI v1.13.0-dev-nightly Future defect Lennart Ochel new 2018-01-11T15:40:46Z 2018-01-12T14:25:42Z "The ''binaries/win64/.lib'' import library is broken. The symbols in the import library (.lib) do not match those in the shared library (.dll). In the .dll: fmi2Instantiate In the .lib: _fmiInstantiate Recompiling from FMU sources with adding '--output-def=.def' as I suggested [https://trac.openmodelica.org/OpenModelica/ticket/4706] to the compiler flags solves the problem." dariomangoni@… 4723 Drawing inherited icons OMEdit v1.13.0-dev-nightly Future defect Adeel Asghar new 2018-01-26T19:10:35Z 2018-02-01T10:09:50Z "It seems that OpenModelica has a different interpretation of the specs than Dymola regarding the drawing inherited icons. I can't really say who is right or wrong or if the spec simply needs clarification. I leave that for you to decide. I've attached a [attachment:test.mo test model] and here is the result from Dymola: [[Image(dymola.png)]] vs OpenModelica: [[Image(openmodelica.png)]] " Dietmar Winkler 4738 Add support for MSVC 64bit FMI Future defect Adrian Pop accepted 2018-02-01T14:53:13Z 2018-02-01T14:53:25Z "Currently for MSVC we only compile using the 32bit compiler. We should do that only for 32bit OM and for the 64bit OM we should compile using the 64bit CL compiler." Adrian Pop 4740 """if noEvent()"" won't protect sqrt from being called" Backend Future defect Lennart Ochel new 2018-02-01T16:17:15Z 2018-02-01T16:17:15Z "{{{#!modelica model behaelter parameter Real A = 5; parameter Real V0 = 0; parameter Real g = 9.81; parameter Real k = 0.1; Real h, fout, fin, v, V; initial equation V=V0; equation der(V) = -fout+fin; if noEvent(V >= 0)then A*h = V; v = sqrt(2*g*h); fout = k*v; else fout = 0; h = 0; v = 0; end if; end behaelter; }}} {{{#!modelica model wasserkette behaelter b1(V0 = 1); equation if noEvent(time < 10)then b1.fin = 0.25; else b1.fin = 0; end if; end wasserkette; }}} When I {{{simulate(wasserkette,stopTime=20)}}} I get the following output: {{{ record SimulationResult resultFile = ""wasserkette_res.mat"", messages = ""assert | debug | division leads to inf or nan at time 0, (a=6.93672) / (b=0), where divisor b is: sqrt(b1.g * b1.h) LOG_SUCCESS | info | The initialization finished successfully without homotopy method. assert | warning | The following assertion has been violated at time 10.560000 assert | debug | Model error: Argument of sqrt(b1.g * b1.h) was -0.186758 should be >= 0 assert | warning | The following assertion has been violated at time 10.560000 assert | debug | Model error: Argument of sqrt(b1.g * b1.h) was -0.154058 should be >= 0 assert | debug | division leads to inf or nan at time 21.9614, (a=0) / (b=0), where divisor b is: sqrt(b1.g * b1.h) assert | debug | division leads to inf or nan at time 20.1835, (a=0) / (b=0), where divisor b is: sqrt(b1.g * b1.h) LOG_SUCCESS | info | The simulation finished successfully. "" end SimulationResult; ""Warning: Iteration variables with default zero start attribute in equation system w/o analytic Jacobian: b1.v:VARIABLE() type: Real b1.h:VARIABLE() type: Real b1.fout:VARIABLE() type: Real "" }}} Moving either {{{A*H=V}}} or {{{fout=k*v}}} out of the if expression (and removing the corresponding equation from else branch) leads to successfull simulation." Henning Kiel 4767 Number of intervals is influencing whether simulation run is successful Run-time v1.13.0-dev-nightly Future defect Willi Braun assigned 2018-02-15T19:05:07Z 2018-03-02T12:26:37Z "Please consider the attached example of a controlled DC machine that I am using in my classes. One of my students ran into a problem when simulating this model. === Simulation setting 1 (as attached) {{{ experiment(StartTime = 0, StopTime = 1.5, Tolerance = 1e-06, Interval = 0.00075) }}} The simulation fails with the error message: {{{ LOG_SUCCESS | info |

The initialization finished successfully without homotopy method.

assert | debug |

Simulation terminated due to too many, i.e. 20, event iterations.
This could either indicate an inconsistent system or an undersized limit of event iterations.
The limit of event iterations can be specified using the runtime flag '–mei=<value>'.

stdout | error |

Simulation process failed. Exited with code 255.

}}} I follow the suggestion and set {{{-mei=1000}}}: This results in: {{{ stdout | error |

Simulation process failed. Exited with code 255.

}}} === Simulation setting 2 {{{ experiment(StartTime = 0, StopTime = 1.5, Tolerance = 1e-06, Interval = 7.5e-05) }}} The simulation runs fine with some warnings, however. {{{ LOG_SUCCESS | info |

The initialization finished successfully without homotopy method.

LOG_NLS_V | warning |

Warning: maximal number of iteration reached but no root found

}}} Simulations results are displayed correctly and the simulation looks OK. === Conclusions I already experienced a couple times, that the actual number of intervals heavily influences the success of a simulation run. This makes it very difficult in a teaching situation to identify the problem and find a proper solution. The attached model now represents a reproducible case of the described issue. This issue occurred at version 1.12.0 (on Windows machine). I double checked the issue right now at version {{{ OMEdit 1.13.0~dev-101-ga45068d Connected to OpenModelica 1.13.0~dev-632-g450ec7c }}} on a Linux 64bit machine. " Christian Kral 4801 Possible display unit are handled differently for variables and outputs (and inputs) OMEdit v1.13.0-dev-nightly Future defect Adeel Asghar new 2018-03-14T18:52:42Z 2018-03-14T18:53:19Z "Please consider the following example, which is triggered by investigations related with https://github.com/modelica/Modelica/issues/2488: {{{#!mo package TestAngle block AngleBlock parameter Modelica.SIunits.Angle phi = 0.1 ""Angle""; extends Modelica.Blocks.Interfaces.SO(y(unit=""rad"")); equation y=phi; end AngleBlock; model TestAngleBlock AngleBlock angleBlock annotation (Placement(transformation(extent={{-10,-10},{10,10}}))); end TestAngleBlock; annotation (uses(Modelica(version=""3.2.2""))); end TestAngle; }}} When simulating the example TestAngleBlock two variables can be plotted: * {{{angleBlock.phi}}}: when plotted, displayUnit = ""deg"" but can be switched to ""rad"" as well * {{{angleBlock.}}}: the only available displayUnit is ""rad"" So when both variables are plotted, only one can be displayed in ""deg"". I think both variables should have the option to be shown in ""deg""." Christian Kral 4881 removeEqualFunctionCalls and wrapFunctionCalls Backend Future defect Lennart Ochel new 2018-04-11T20:24:32Z 2018-04-11T20:24:32Z "For `removeEqualFunctionCalls` we can find the line {{{#!modelica skip this module if cse module is activated }}} which use `Flags.CSE_CALL`. But enable `wrapFunctionCalls` is not equal `Flags.CSE_CALL`. see the dump: https://github.com/OpenModelica/OpenModelica-testsuite/blob/master/openmodelica/debugDumps/lateInline.mos both moduls are enabled. " Vitalij Ruge 4888 ModelicaExternalC libraries for Visual Studio are missing Run-time Future defect Lennart Ochel new 2018-04-18T08:28:55Z 2018-04-18T08:28:55Z "For this model: {{{#!mo model TablesTest Modelica.Blocks.Tables.CombiTable2D combiTable2D(table=[2,4; 4,6]); Modelica.Blocks.Sources.Sine sine; Modelica.Blocks.Sources.Sine sine1; equation connect(sine.y, combiTable2D.u1); connect(sine1.y, combiTable2D.u2); end TablesTest; }}} the simulation with the C++ runtime and Visual Studio is not working because the ModelicaStandardTables library could not be found. With commit 90621756a8e8f3978a17347146a6fc3b044f3e71 the C++ runtime uses the ModelicaExternalC libraries from the OpenModelica main build. Since the ModelicaExternalC libraries are build staticly with gcc, they can not be linked with Visual Studio libraries" Niklas Worschech 4890 strange power Backend Future defect somebody new 2018-04-18T15:00:42Z 2018-04-25T06:35:50Z "the following simple model create for simple power operation {{{#!modelica model pow_test Real x = time^(1/3); end pow_test; }}} about 60 lines C-Code: {{{#!C /* equation index: 2 type: SIMPLE_ASSIGN x = time ^ 0.3333333333333333 */ void pow_test_eqFunction_2(DATA *data, threadData_t *threadData) { TRACE_PUSH const int equationIndexes[2] = {1,2}; modelica_real tmp0; modelica_real tmp1; modelica_real tmp2; modelica_real tmp3; modelica_real tmp4; modelica_real tmp5; modelica_real tmp6; tmp0 = data->localData[0]->timeValue; tmp1 = 0.3333333333333333; if(tmp0 < 0.0 && tmp1 != 0.0) { tmp3 = modf(tmp1, &tmp4); if(tmp3 > 0.5) { tmp3 -= 1.0; tmp4 += 1.0; } else if(tmp3 < -0.5) { tmp3 += 1.0; tmp4 -= 1.0; } if(fabs(tmp3) < 1e-10) tmp2 = pow(tmp0, tmp4); else { tmp6 = modf(1.0/tmp1, &tmp5); if(tmp6 > 0.5) { tmp6 -= 1.0; tmp5 += 1.0; } else if(tmp6 < -0.5) { tmp6 += 1.0; tmp5 -= 1.0; } if(fabs(tmp6) < 1e-10 && ((unsigned long)tmp5 & 1)) { tmp2 = -pow(-tmp0, tmp3)*pow(tmp0, tmp4); } else { throwStreamPrint(threadData, ""%s:%d: Invalid root: (%g)^(%g)"", __FILE__, __LINE__, tmp0, tmp1); } } } else { tmp2 = pow(tmp0, tmp1); } if(isnan(tmp2) || isinf(tmp2)) { throwStreamPrint(threadData, ""%s:%d: Invalid root: (%g)^(%g)"", __FILE__, __LINE__, tmp0, tmp1); } data->localData[0]->realVars[0] /* x variable */ = tmp2; TRACE_POP } }}} Line: https://github.com/OpenModelica/OMCompiler/blob/master/Compiler/Template/CodegenCFunctions.tpl#L4938 related commits: https://github.com/OpenModelica/OMCompiler/commit/63d57dd2ca84c3e72641edba77fde0494bc56b73 https://github.com/OpenModelica/OMCompiler/commit/cb732fc280ac2d8940713d8a104c18952a0634da" Vitalij Ruge 4892 Execution statistics show wrong solver Backend v1.13.0-dev-nightly Future defect Willi Braun assigned 2018-04-19T11:26:58Z 2018-04-19T17:12:08Z "After running the model the ### STATISTICS ### block always shows ""euler"" as solver, despite dassl beeing selected and used." Hauke Hirsch 4893 ligc segfault at fmiInstantiateModel Code Generation v1.13.0-dev-nightly Future defect Lennart Ochel new 2018-04-19T14:24:00Z 2018-04-25T06:26:18Z "Hi, I'm using fmi version 1 with the C simulation runtime, and for a specific FMU there is a SIGSEGV thrown when instantiating the model. Here's the GDB stacktrace {{{ (gdb) bt #0 0xabfc366d in GC_find_limit_with_bound (p=0x81a0604 """", up=0, bound=0x0) at os_dep.c:966 #1 0xabfc373f in GC_find_limit (p=0x81a0604 """", up=0) at os_dep.c:978 #2 0xabfc37c0 in GC_init_linux_data_start () at os_dep.c:463 #3 0xabfc1799 in GC_init () at misc.c:1159 #4 0xabfbb76c in GC_generic_malloc_inner (lb=0, k=2) at malloc.c:125 #5 0xabfbb809 in GC_generic_malloc (lb=0, k=2) at malloc.c:196 #6 0xabfbbb69 in GC_generic_malloc_uncollectable (lb=, k=2) at malloc.c:319 #7 0xabfbbc05 in GC_malloc_uncollectable (lb=0) at malloc.c:351 #8 0xaf881d19 in initializeDataStruc (data=0x83bf078, threadData=0x83bf410) at simulation/solver/model_help.c:903 #9 0xac4de7ec in GENSAL_fmiInstantiateModel (instanceName=, GUID=, functions=..., loggingOn=76 'L') at include/fmi1/fmu1_model_interface.c:189 (gdb) frame 0 #0 0xabfc366d in GC_find_limit_with_bound (p=0x81a0604 """", up=0, bound=0x0) at os_dep.c:966 966 GC_noop1((word)(*result)); (gdb) print result $5 = (volatile ptr_t) 0x8047f00
(gdb) frame 8 #8 0xaf881d19 in initializeDataStruc (data=0x83bf078, threadData=0x83bf410) at simulation/solver/model_help.c:903 903 tmpSimData.stringVars = (modelica_string*) omc_alloc_interface.malloc_uncollectable(data->modelData->nVariablesString * sizeof(modelica_string)); (gdb) info locals tmpSimData = {timeValue = 0, realVars = 0x83bf500, integerVars = 0x83bef30, booleanVars = 0x83b99a0 """", stringVars = 0x0, inlineVars = 0x0} i = (gdb) print data->modelData->nVariablesString $6 = 0 }}} Link the the function https://github.com/ivmai/bdwgc/blob/master/os_dep.c#L982 This model has only one string parameter, yet data->modelData->nVariablesString is 0. I cannot test the c++ runtime because i'm using Centos 6.9 32 bits and cannot compile it due to boost errors. Is this a known problem? Thanks " simon.zeni@… 4895 listArrayLiteral in uniontype constant gives compilation errors MetaModelica v1.13.0-dev-nightly Future defect Martin Sjölund new 2018-04-20T11:25:32Z 2018-04-20T11:25:32Z "Using listArrayLiteral causes incorrect code to be generated in cases such as this: {{{#!mo package P uniontype UT1 record R1 Integer n; end R1; end UT1; uniontype UT2 record R2 array ut1; end R2; end UT2; constant UT2 ut2 = UT2.R2( listArrayLiteral({}) ); end P; function f input P.UT2 ut2; output array ut1 = ut2.ut1; end f; function test algorithm f(P.ut2); end test; }}} This gives the compilation error: {{{ :31:21: error: use of undeclared identifier '_P' omc_f(threadData, _P._ut2); }}}" Per Östlund 4908 [NF] Issues with inner/outer with redeclare New Instantiation Future defect Per Östlund new 2018-04-29T14:17:25Z 2018-04-29T14:18:59Z " Attached model has an: {{{#!mo inner SimCenter simCenter( contributeToCycleSummary = true, redeclare TILMedia.VLEFluidTypes.TILMedia_InterpolatedWater fluid1, showExpertSummary = true); }}} where {{{fluid1}}} is modifying: {{{(nc_propertyCalculation = 1)}}} which is then send to an outer: {{{outer SimCenter simCenter}}} from which is used in an array inside {{{Turbine_HP1}}}: {{{Turbine_HP1.medium.nc_propertyCalculation}}}. What i get is: {{{ [C:/home/adrpo33/dev/OMTesting/ClaRa/SteamCycle_01_total.mo:1382:7-1382:145:writable] Error: Could not evaluate structural parameter (or constant): Turbine_HP1.medium.nc_propertyCalculation which gives dimensions of array: vleFluidNames. Array dimensions must be known at compile time. }}} " Adrian Pop 4972 Annotations in extended clause have no effect OMEdit v1.13.0-dev-nightly Future defect Adeel Asghar new 2018-06-03T00:43:06Z 2018-06-03T00:43:06Z "The annotations primitivesVisible=false in extended class that supposed to suppress the parent class icon don't work. " anonymous 4989 Build error using homebrew's Qt 5.11 on macOS *unknown* Future defect Adeel Asghar assigned 2018-06-17T19:44:48Z 2018-12-22T09:23:25Z "When building GUIs exectuables such as `OMPlotGUI` and `OMEditGUI` on macOS using the latest Qt 5.11, I get the following error: {{{ clang++ -c -I/usr/local/opt/gettext/include -std=c++11 -O2 -std=gnu++11 x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -mmacosx-version-min=10.11 -w -fPIC -DQT_NO_DEBUG -DQT_SVG_LIB -DQT_PRINTSUPPORT_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I. -I../../../build/include/omplot/qwt -I../../../build/include/omc/c -I. -I/usr/local/Cellar/qt/5.11.0/lib/QtSvg.framework/Headers -I/usr/local/Cellar/qt/5.11.0/lib/QtPrintSupport.framework/Headers -I/usr/local/Cellar/qt/5.11.0/lib/QtWidgets.framework/Headers -I/usr/local/Cellar/qt/5.11.0/lib/QtGui.framework/Headers -I/usr/local/Cellar/qt/5.11.0/lib/QtCore.framework/Headers -I../generatedfiles/moc -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/OpenGL.framework/Headers -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/AGL.framework/Headers -I/usr/local/Cellar/qt/5.11.0/mkspecs/macx-clang -F/usr/local/Cellar/qt/5.11.0/lib -o Plot.o Plot.cpp clang: error: no such file or directory: 'x86_64' }}} Apparently this is due to a `qmake.sh` that is stripping away the `-arch` flag from the makefile. A fix is proposed in https://github.com/OpenModelica/OpenModelica-common/pull/2 . " Silvio Traversaro 4998 table.getNextTimeEvent Backend v1.12.0 Future defect Lennart Ochel new 2018-06-22T14:08:44Z 2018-06-25T09:00:32Z "Hi, I've got issue when I mix two different blocks that are reading ASCII - table. It's working when i consider them alone, with other non-reader blocks that behave the same (but whithout extranal input, just constant settings), but when I use them both, I've got this issue : [118] 16:03:38 Traduction Erreur Internal error BackendDAE.adjacencyRowEnhanced failed for eqn: when {$whenCondition1, initial()} then z2.C11.table.nextTimeEventScaled := Modelica.Blocks.Sources.CombiTimeTable$z2$C11$table.getNextTimeEvent(z2.C11.table.tableID, z2.C11.table.timeScaled, z2.C11.table.tableOnFileRead); end when; [119] 16:03:38 Traduction Erreur Internal error BackendDAEUtil.getAdjacencyMatrixEnhancedScalar failed [120] 16:03:38 Traduction Erreur Internal error - IndexReduction.dynamicStateSelectionWork failed! Thanks for your help, Regards," clement.tobac@… 5000 Use Model_init.xml in the resources folder of FMU instead of compiling Model_init_fmu.c FMI Future defect Lennart Ochel new 2018-06-25T11:47:34Z 2018-06-25T13:15:14Z Compiling the huge function inside Model_init_fmu.c takes forever, we should try to load the data from the resources folder of FMU. Adrian Pop 5022 Disabled HPCOM test Run-time Future defect Marcus Walther new 2018-07-02T07:38:12Z 2018-07-02T07:38:12Z I will disable Modelica.Thermal.HeatTransfer.Examples.Motor_mcp_omp.mos because while the non-HPCOM version takes 8 seconds, the HPCOM version on our servers sometimes takes much longer and when running under docker it reaches the 25-minute timeout. Martin Sjölund 5064 Inline doesn't work properly Backend Future defect Lennart Ochel new 2018-08-12T13:37:53Z 2018-08-29T21:10:46Z " The NF can flatten attached model: AdvancedNoise.Examples.VaryingDistribution but the inline doesn't work properly, the nBuffer is not inlined or evaluated when inlined and ends up as an undefined in the code generation. {{{#!mo function AdvancedNoise.Sources.TimeBasedNoise.interpolation.interpolate ""Inline before index reduction"" ""Constant interpolation in a buffer of random values"" input Real[:] buffer ""Buffer of random numbers""; input Real offset ""Offset from buffer start (0..size(buffer)-1""; input Real samplePeriod = 1.0 ""The sample period of the noise buffer""; output Real y ""Interpolated value at position offset""; protected Integer nBuffer = size(buffer, 1) ""Size of the buffer""; algorithm y := buffer[if nBuffer == 1 then 1 else integer(offset) + 1]; end AdvancedNoise.Sources.TimeBasedNoise.interpolation.interpolate; }}} " Adrian Pop 5067 Mac openmodelica-devel fails to build Build Environment Future defect Martin Sjölund new 2018-08-21T13:32:59Z 2018-08-21T13:32:59Z "I can't upgrade openmodelica-devel from @1.13.0~dev-1284-g876da2a_0 (which builds, but will only run with the modification in https://trac.openmodelica.org/OpenModelica/ticket/5060 ) to 1.13.0~dev-1297-g6c67337_0 I'll attach the full log file, but the end of the log file shows a link error: {{{ :info:build /usr/bin/clang++ -c -pipe -Os -stdlib=libc++ -std=c++11 -Wno-unused-variable -Wno-unused-function -Wno-unused-parameter -DWITHOUT_OSG -g -mmacosx-version-min=10.13 -Wall -W -DQT_NO_DEBUG -DQT_WEBKIT_LIB -DQT_SVG_LIB -DQT_XMLPATTERNS_LIB -DQT_XML_LIB -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/opt/local/libexec/qt4/share/mkspecs/macx-g++ -I. -I../generatedfiles/moc -I/opt/local/libexec/qt4/Library/Frameworks/QtCore.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtNetwork.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtGui.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtOpenGL.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtXml.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtXmlPatterns.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtSvg.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtWebKit.framework/Versions/4/Headers -I../../../build/include/omc/scripting-API -I../../../build/include/omplot -I../../../build/include/omplot/qwt -I../../../build/include/x86_64-darwin17.7.0/omc/antlr3 -I../../../build/include/omc/c -I../../qjson-0.8.1/build/include -I../../../build/include -I../../qjson/build/include -I../../../build/include/omc/scripting-API -I../../../build/include/omc/c/util -I../../../build/include/omc/fmil -I/opt/local/libexec/qt4/Library/Frameworks/QtWebKit.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtSvg.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtXmlPatterns.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtXml.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtOpenGL.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtGui.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtNetwork.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtCore.framework/Versions/4/Headers -I/opt/local/libexec/qt4/include -I/System/Library/Frameworks/OpenGL.framework/Versions/A/Headers -I/System/Library/Frameworks/AGL.framework/Headers -F/opt/local/libexec/qt4/Library/Frameworks -F/opt/local/libexec/qt4/lib -o moc_FMUProperties.o ../generatedfiles/moc/moc_FMUProperties.cpp :info:build /usr/bin/clang++ -c -pipe -Os -stdlib=libc++ -std=c++11 -Wno-unused-variable -Wno-unused-function -Wno-unused-parameter -DWITHOUT_OSG -g -mmacosx-version-min=10.13 -Wall -W -DQT_NO_DEBUG -DQT_WEBKIT_LIB -DQT_SVG_LIB -DQT_XMLPATTERNS_LIB -DQT_XML_LIB -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/opt/local/libexec/qt4/share/mkspecs/macx-g++ -I. -I../generatedfiles/moc -I/opt/local/libexec/qt4/Library/Frameworks/QtCore.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtNetwork.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtGui.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtOpenGL.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtXml.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtXmlPatterns.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtSvg.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtWebKit.framework/Versions/4/Headers -I../../../build/include/omc/scripting-API -I../../../build/include/omplot -I../../../build/include/omplot/qwt -I../../../build/include/x86_64-darwin17.7.0/omc/antlr3 -I../../../build/include/omc/c -I../../qjson-0.8.1/build/include -I../../../build/include -I../../qjson/build/include -I../../../build/include/omc/scripting-API -I../../../build/include/omc/c/util -I../../../build/include/omc/fmil -I/opt/local/libexec/qt4/Library/Frameworks/QtWebKit.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtSvg.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtXmlPatterns.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtXml.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtOpenGL.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtGui.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtNetwork.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtCore.framework/Versions/4/Headers -I/opt/local/libexec/qt4/include -I/System/Library/Frameworks/OpenGL.framework/Versions/A/Headers -I/System/Library/Frameworks/AGL.framework/Headers -F/opt/local/libexec/qt4/Library/Frameworks -F/opt/local/libexec/qt4/lib -o moc_OMSSimulationDialog.o ../generatedfiles/moc/moc_OMSSimulationDialog.cpp :info:build /usr/bin/clang++ -c -pipe -Os -stdlib=libc++ -std=c++11 -Wno-unused-variable -Wno-unused-function -Wno-unused-parameter -DWITHOUT_OSG -g -mmacosx-version-min=10.13 -Wall -W -DQT_NO_DEBUG -DQT_WEBKIT_LIB -DQT_SVG_LIB -DQT_XMLPATTERNS_LIB -DQT_XML_LIB -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/opt/local/libexec/qt4/share/mkspecs/macx-g++ -I. -I../generatedfiles/moc -I/opt/local/libexec/qt4/Library/Frameworks/QtCore.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtNetwork.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtGui.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtOpenGL.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtXml.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtXmlPatterns.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtSvg.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtWebKit.framework/Versions/4/Headers -I../../../build/include/omc/scripting-API -I../../../build/include/omplot -I../../../build/include/omplot/qwt -I../../../build/include/x86_64-darwin17.7.0/omc/antlr3 -I../../../build/include/omc/c -I../../qjson-0.8.1/build/include -I../../../build/include -I../../qjson/build/include -I../../../build/include/omc/scripting-API -I../../../build/include/omc/c/util -I../../../build/include/omc/fmil -I/opt/local/libexec/qt4/Library/Frameworks/QtWebKit.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtSvg.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtXmlPatterns.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtXml.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtOpenGL.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtGui.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtNetwork.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtCore.framework/Versions/4/Headers -I/opt/local/libexec/qt4/include -I/System/Library/Frameworks/OpenGL.framework/Versions/A/Headers -I/System/Library/Frameworks/AGL.framework/Headers -F/opt/local/libexec/qt4/Library/Frameworks -F/opt/local/libexec/qt4/lib -o moc_OMSSimulationOutputWidget.o ../generatedfiles/moc/moc_OMSSimulationOutputWidget.cpp :info:build /usr/bin/clang++ -c -pipe -Os -stdlib=libc++ -std=c++11 -Wno-unused-variable -Wno-unused-function -Wno-unused-parameter -DWITHOUT_OSG -g -mmacosx-version-min=10.13 -Wall -W -DQT_NO_DEBUG -DQT_WEBKIT_LIB -DQT_SVG_LIB -DQT_XMLPATTERNS_LIB -DQT_XML_LIB -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/opt/local/libexec/qt4/share/mkspecs/macx-g++ -I. -I../generatedfiles/moc -I/opt/local/libexec/qt4/Library/Frameworks/QtCore.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtNetwork.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtGui.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtOpenGL.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtXml.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtXmlPatterns.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtSvg.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtWebKit.framework/Versions/4/Headers -I../../../build/include/omc/scripting-API -I../../../build/include/omplot -I../../../build/include/omplot/qwt -I../../../build/include/x86_64-darwin17.7.0/omc/antlr3 -I../../../build/include/omc/c -I../../qjson-0.8.1/build/include -I../../../build/include -I../../qjson/build/include -I../../../build/include/omc/scripting-API -I../../../build/include/omc/c/util -I../../../build/include/omc/fmil -I/opt/local/libexec/qt4/Library/Frameworks/QtWebKit.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtSvg.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtXmlPatterns.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtXml.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtOpenGL.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtGui.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtNetwork.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtCore.framework/Versions/4/Headers -I/opt/local/libexec/qt4/include -I/System/Library/Frameworks/OpenGL.framework/Versions/A/Headers -I/System/Library/Frameworks/AGL.framework/Headers -F/opt/local/libexec/qt4/Library/Frameworks -F/opt/local/libexec/qt4/lib -o qrc_resource_omedit.o ../generatedfiles/rcc/qrc_resource_omedit.cpp :info:build /usr/bin/clang++ -headerpad_max_install_names -L/opt/local/lib -Wl,-headerpad_max_install_names -rdynamic -mmacosx-version-min=10.13 -o ../bin/OMEdit.app/Contents/MacOS/OMEdit main.o Helper.o Utilities.o StringHandler.o MainWindow.o OpenModelicaScriptingAPIQt.o OMCProxy.o MessagesWidget.o ItemDelegate.o LibraryTreeWidget.o Commands.o CoOrdinateSystem.o ModelWidgetContainer.o ModelicaClassDialog.o FunctionArgumentDialog.o SearchWidget.o OptionsDialog.o BaseEditor.o ModelicaEditor.o TransformationsEditor.o TextEditor.o CEditor.o CompositeModelEditor.o MetaModelicaEditor.o HTMLEditor.o PlotWindowContainer.o Component.o ShapeAnnotation.o CornerItem.o LineAnnotation.o PolygonAnnotation.o RectangleAnnotation.o EllipseAnnotation.o TextAnnotation.o BitmapAnnotation.o ComponentProperties.o Transformation.o DocumentationWidget.o SimulationDialog.o SimulationOutputWidget.o SimulationProcessThread.o SimulationOutputHandler.o OpcUaClient.o FetchInterfaceDataDialog.o FetchInterfaceDataThread.o TLMCoSimulationDialog.o TLMCoSimulationOutputWidget.o TLMCoSimulationThread.o ImportFMUDialog.o ImportFMUModelDescriptionDialog.o VariablesWidget.o NotificationsDialog.o ShapePropertiesDialog.o OMDumpXML.o diff_match_patch.o TransformationsWidget.o CommandFactory.o GDBAdapter.o StackFramesWidget.o LocalsWidget.o ModelicaValue.o BreakpointMarker.o BreakpointsWidget.o BreakpointDialog.o DebuggerConfigurationsDialog.o AttachToProcessDialog.o ProcessListModel.o backtrace.o GDBBacktrace.o CrashReportDialog.o GitCommands.o CommitChangesDialog.o RevertCommitsDialog.o CleanDialog.o OMEditApplication.o TraceabilityGraphViewWidget.o TraceabilityInformationURI.o OMSProxy.o FMUProperties.o OMSSimulationDialog.o OMSSimulationOutputWidget.o moc_Helper.o moc_Utilities.o moc_StringHandler.o moc_MainWindow.o moc_OpenModelicaScriptingAPIQt.o moc_OMCProxy.o moc_MessagesWidget.o moc_ItemDelegate.o moc_LibraryTreeWidget.o moc_ModelWidgetContainer.o moc_ModelicaClassDialog.o moc_SearchWidget.o moc_OptionsDialog.o moc_BaseEditor.o moc_ModelicaEditor.o moc_TransformationsEditor.o moc_TextEditor.o moc_CEditor.o moc_CompositeModelEditor.o moc_MetaModelicaEditor.o moc_HTMLEditor.o moc_PlotWindowContainer.o moc_Component.o moc_ShapeAnnotation.o moc_CornerItem.o moc_LineAnnotation.o moc_PolygonAnnotation.o moc_RectangleAnnotation.o moc_EllipseAnnotation.o moc_TextAnnotation.o moc_BitmapAnnotation.o moc_ComponentProperties.o moc_DocumentationWidget.o moc_SimulationDialog.o moc_SimulationOutputWidget.o moc_SimulationProcessThread.o moc_SimulationOutputHandler.o moc_OpcUaClient.o moc_FetchInterfaceDataDialog.o moc_FetchInterfaceDataThread.o moc_TLMCoSimulationDialog.o moc_TLMCoSimulationOutputWidget.o moc_TLMCoSimulationThread.o moc_ImportFMUDialog.o moc_ImportFMUModelDescriptionDialog.o moc_VariablesWidget.o moc_NotificationsDialog.o moc_ShapePropertiesDialog.o moc_TransformationsWidget.o moc_GDBAdapter.o moc_StackFramesWidget.o moc_LocalsWidget.o moc_ModelicaValue.o moc_BreakpointMarker.o moc_BreakpointsWidget.o moc_BreakpointDialog.o moc_DebuggerConfigurationsDialog.o moc_AttachToProcessDialog.o moc_ProcessListModel.o moc_GDBBacktrace.o moc_CrashReportDialog.o moc_GitCommands.o moc_CommitChangesDialog.o moc_RevertCommitsDialog.o moc_CleanDialog.o moc_TraceabilityGraphViewWidget.o moc_TraceabilityInformationURI.o moc_OMSProxy.o moc_FMUProperties.o moc_OMSSimulationDialog.o moc_OMSSimulationOutputWidget.o qrc_resource_omedit.o -F/opt/local/libexec/qt4/Library/Frameworks -F/opt/local/libexec/qt4/lib -L /opt/local/var/macports/build/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/work/openmodelica_1.13.0~dev-1297-g6c67337/build/lib/x86_64-darwin17.7.0/omc -lOMPlot -lomqwt -lfmilib_shared -L../OMEditGUI/Debugger/Parser -lGDBMIParser -lomantlr3 -Wl,-rpath,@loader_path/../../../../lib/x86_64-darwin17.7.0/omc,-rpath,@loader_path/../../../../lib/,-rpath,/opt/local/lib/x86_64-darwin17.7.0/omc,-rpath,/opt/local/lib/ -lOpenModelicaCompiler -lOpenModelicaRuntimeC -lomcgc -L/opt/local/var/macports/build/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/work/openmodelica_1.13.0~dev-1297-g6c67337/build/lib/x86_64-darwin17.7.0/omc -lomopcua -L/opt/local/var/macports/build/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/work/openmodelica_1.13.0~dev-1297-g6c67337/build/lib -lOMSimulatorLib -lomtlmsimulator -lqjson -F/opt/local/libexec/qt4/Library/Frameworks -F/opt/local/libexec/qt4/lib -L/opt/local/libexec/qt4/lib -framework QtWebKit -framework QtSvg -F/opt/local/Library/Frameworks -framework QtGui -framework QtCore -framework QtXmlPatterns -framework QtNetwork -framework QtXml -framework QtOpenGL -framework OpenGL -framework AGL :info:build Undefined symbols for architecture x86_64: :info:build ""_oms2_getSubModelPath"", referenced from: :info:build OMSProxy::getSubModelPath(QString, QString*) in OMSProxy.o :info:build ld: symbol(s) not found for architecture x86_64 :info:build clang: error: linker command failed with exit code 1 (use -v to see invocation) :info:build make[3]: *** [../bin/OMEdit.app/Contents/MacOS/OMEdit] Error 1 :info:build make[3]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/work/openmodelica_1.13.0~dev-1297-g6c67337/OMEdit/OMEdit/OMEditGUI' :info:build make[2]: *** [OMEdit] Error 2 :info:build make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/work/openmodelica_1.13.0~dev-1297-g6c67337/OMEdit/OMEdit/OMEditGUI' :info:build make[1]: *** [omedit] Error 2 :info:build make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/work/openmodelica_1.13.0~dev-1297-g6c67337/OMEdit' :info:build make: *** [omedit] Error 2 :info:build make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/work/openmodelica_1.13.0~dev-1297-g6c67337' :info:build Command failed: cd ""/opt/local/var/macports/build/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/work/openmodelica_1.13.0~dev-1297-g6c67337"" && /usr/bin/make -j8 -w :info:build Exit code: 2 :error:build Failed to build openmodelica-devel: command execution failed :debug:build Error code: CHILDSTATUS 84264 2 :debug:build Backtrace: command execution failed :debug:build while executing :debug:build ""system {*}$notty {*}$nice $fullcmdstring"" :debug:build invoked from within :debug:build ""command_exec build"" :debug:build (procedure ""portbuild::build_main"" line 8) :debug:build invoked from within :debug:build ""$procedure $targetname"" :error:build See /opt/local/var/macports/logs/_opt_local_var_macports_sources_build.openmodelica.org_macports_lang_openmodelica-devel/openmodelica-devel/main.log for details. }}} " Adam Dershowitz 5082 internal compiler error: Segmentation fault Code Generation v1.13.0-dev-nightly Future defect Lennart Ochel new 2018-08-24T19:20:46Z 2018-08-29T21:22:28Z "I was trying to compile in gcc when I received the following message: S730_02nls.c: In function 'S730_eqFunction_32331': S730_02nls.c: 54238: 1: internal compiler error: Segmentation fault } ^ libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make: *** [S730_02nls.o] Error 1 Can anyone help me solve this problem? My version of OMEdit is v1.13.0-dev-196-g9199a1a6 (64-bit) and mingw / gcc is up to date." anonymous 5113 [FMI] Fix issues with input/output String/Boolean in FMUs FMI Future defect Lennart Ochel new 2018-09-10T17:42:28Z 2018-09-10T18:26:17Z " Continue the work in: https://github.com/OpenModelica/OMCompiler/pull/2625 and add support for setting String/Boolean inputs. " Adrian Pop 5121 Use template files for Makefiles for C and FMU build that users can change Build Environment Future defect Martin Sjölund new 2018-09-12T13:52:34Z 2018-09-13T14:49:51Z "Would be nice to have some template Makefiles for building C and FMU which we can populate with values. We could store them in {{{/share/omc/scripts}}}. This way the users can edit these templates to their liking making much easier and flexible to do what they want." Adrian Pop 5124 Very simple model is detected as over-determined Backend Future defect Lennart Ochel new 2018-09-13T20:31:32Z 2018-09-13T20:31:32Z "The following example model fails (28 equations and 26 variables): {{{ model Test model tp extends Modelica.Electrical.Analog.Interfaces.TwoPort; equation connect(n1, n2); connect(p1, p2); end tp; Modelica.Electrical.Analog.Sources.ConstantVoltage v; Modelica.Electrical.Analog.Basic.Ground g1; Modelica.Electrical.Analog.Sources.ConstantCurrent c(I = 0); Test.tp pt; equation connect(g1.p, v.n); connect(pt.p1, v.p); connect(pt.n1, v.n); connect(pt.p2, c.p); connect(pt.n2, c.n); end Test; }}} When removing the TwoPort in the middle, it works. {{{ model Test Modelica.Electrical.Analog.Sources.ConstantVoltage v; Modelica.Electrical.Analog.Basic.Ground g1; Modelica.Electrical.Analog.Sources.ConstantCurrent c(I = 0); equation connect(g1.p, v.n); connect(v.p, c.p); connect(v.n, c.n); end Test; }}} When manually inlining the TwoPort, I get: {{{ model Test model tp Modelica.SIunits.Voltage v1; Modelica.SIunits.Voltage v2; Modelica.SIunits.Current i1; Modelica.SIunits.Current i2; Modelica.Electrical.Analog.Interfaces.PositivePin p1; Modelica.Electrical.Analog.Interfaces.NegativePin n1; Modelica.Electrical.Analog.Interfaces.PositivePin p2; Modelica.Electrical.Analog.Interfaces.NegativePin n2; equation v1 = p1.v - n1.v; v2 = p2.v - n2.v; 0 = p1.i + n1.i; 0 = p2.i + n2.i; i1 = p1.i; i2 = p2.i; connect(n1, n2); connect(p1, p2); end tp; Modelica.Electrical.Analog.Sources.ConstantVoltage v; Modelica.Electrical.Analog.Basic.Ground g1; Modelica.Electrical.Analog.Sources.ConstantCurrent c(I = 0); Test.tp pt; equation connect(g1.p, v.n); connect(pt.p1, v.p); connect(pt.n1, v.n); connect(pt.p2, c.p); connect(pt.n2, c.n); end Test; }}} This has the same result as with the non-inlined version. When I remove the 0=p1.i+n1.i and 0=p2.i+n2.i equations, it works. Example: {{{ model Test model tp Modelica.SIunits.Voltage v1; Modelica.SIunits.Voltage v2; Modelica.SIunits.Current i1; Modelica.SIunits.Current i2; Modelica.Electrical.Analog.Interfaces.PositivePin p1; Modelica.Electrical.Analog.Interfaces.NegativePin n1; Modelica.Electrical.Analog.Interfaces.PositivePin p2; Modelica.Electrical.Analog.Interfaces.NegativePin n2; equation v1 = p1.v - n1.v; v2 = p2.v - n2.v; i1 = p1.i; i2 = p2.i; connect(n1, n2); connect(p1, p2); end tp; Modelica.Electrical.Analog.Sources.ConstantVoltage v; Modelica.Electrical.Analog.Basic.Ground g1; Modelica.Electrical.Analog.Sources.ConstantCurrent c(I = 0); Test.tp pt; equation connect(g1.p, v.n); connect(pt.p1, v.p); connect(pt.n1, v.n); connect(pt.p2, c.p); connect(pt.n2, c.n); annotation( uses(Modelica(version = ""3.2.2"")) ); end Test; }}} These two equations are practically redundant and should be eliminated/ not be counted." tknodt@… 5142 Plot shows different value than the calculated value through simulation *unknown* v1.12.0 Future defect somebody new 2018-09-26T20:38:14Z 2018-09-27T07:48:09Z "I am running the adiabatic.mo example in here: http://book.xogeny.com/components/components/heat_transfer/ Once the simulation completes, the temperature at node.T is 288.15 K according to the Variables Browser. However, when you click the checkbox to plot it, the plot shows 363.15 K. " sebasr96@… 5149 Discrete integer input causes internal error when generating code (but validated without any errors) Backend v1.13.0-dev-nightly Future defect Lennart Ochel new 2018-10-02T15:17:17Z 2018-10-02T15:18:38Z "== How to reproduce == Either compile the following model to FMU or simulate: {{{ #!modelica model TestInt discrete input Integer inInt; end TestInt; }}} == What is expected == Compiled without error or with some meaningful error. == What really happens == {{{ [/build/openmodelica-FcUrBU/openmodelica-1.13.0~dev-1491-g87333c1/OMCompiler/Compiler/BackEnd/BackendDAECreate.mo:1121:9-1121:82:writable] Error: Internal error function lowerKnownVarkind failed Error: Internal error BackendDAECreate.lowerKnownVar failed for discrete input Integer inInt; Error: Internal error BackendDAECreate.lowerVar failed for discrete input Integer inInt; }}}" anatoly.trosinenko@… 5150 The utility sample() freezes the output after a amount of simulation time. OMSimulator v1.12.0 Future defect jordeam@… new 2018-10-03T17:58:11Z 2019-05-17T23:02:54Z "I am using OpenModelica for control in electrical drives classes. I used a tiny sample period of 100e-6s. After a time of simulation, sample() stops working and the simulation gives wrong answers. I tested all available numerical algorithms without success. I also used fixed step simulation with less than 1us of step and also failed. I use a ZOH in the feedback, one fo each loop, because OpenModelica is not able to solve numerically the system without those, but after a certain time, provided ZOH in the library as well as a locally defined ZOH fails because of sample(), that freezes its output. Using provided ZeroOrderHold breaks the simulation before desired ending time. [[Image(s1.png)]] Using the defined in module, does not break the simulation, but sample() stops working at 0.249. [[Image(s2.png)]] The source code is attached. " jordeam@… 5196 Memory leak with inline arrays in when clauses FMI v1.13.0-dev-nightly Future defect Lennart Ochel new 2018-11-01T11:55:01Z 2019-03-29T09:03:31Z "It seems there is a memory leak reproducible with a simple array defined inline in a while clause. I cannot say for sure, since it goes through the memory pool logic, but both valgrinding the FMUChecker with this FMU and looking at the generated source code suggest that the memory for this array is allocated but never freed. == How to reproduce == * Take these files: **TestAllTrue.mo**: {{{#!modelica model TestAllTrue input Boolean x, y, z; output Boolean res; equation when Modelica.Math.BooleanVectors.allTrue({x, y, z}) then res = true; end when; end TestAllTrue; }}} **TestAllTrue.mos**: {{{#!modelica print(buildModelFMU(TestAllTrue, ""1.0"", ""me"")); print(getErrorString()); }}} * Compile it with `omc TestAllTrue.mos Modelica TestAllTrue.mo` * Run under Valgrind with {{{#!shell mkdir -p /tmp/fmu # So valgrind can show symbols from .so-file from FMU valgrind --leak-check=full --show-leak-kinds=all ~/tmp/FMUChecker-2.0.3/build/fmuCheck.linux64 -z /tmp/fmu -h 0.01 -s 10000 -o /dev/null TestAllTrue.fmu }}} Among other, it will print {{{ ==32160== 29,360,128 bytes in 3 blocks are still reachable in loss record 24 of 24 ==32160== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==32160== by 0x6C645EE: pool_malloc (in /tmp/fmu/binaries/linux64/TestAllTrue.so) ==32160== by 0x6C58383: array_alloc_scalar_boolean_array (in /tmp/fmu/binaries/linux64/TestAllTrue.so) ==32160== by 0x6C55301: TestAllTrue_eqFunction_4 (in /tmp/fmu/binaries/linux64/TestAllTrue.so) ==32160== by 0x6C55869: TestAllTrue_functionAlgebraics (in /tmp/fmu/binaries/linux64/TestAllTrue.so) ==32160== by 0x6C54FDC: TestAllTrue_fmiCompletedIntegratorStep (in /tmp/fmu/binaries/linux64/TestAllTrue.so) ==32160== by 0x40C689: fmi1_me_simulate (in /home/trosinenko/tmp/FMUChecker-2.0.3/build/fmuCheck.linux64) ==32160== by 0x40B99C: fmi1_check (in /home/trosinenko/tmp/FMUChecker-2.0.3/build/fmuCheck.linux64) ==32160== by 0x408934: main (in /home/trosinenko/tmp/FMUChecker-2.0.3/build/fmuCheck.linux64) }}} //this suggests where the leak is// * Running the same command without Valgrind but with `/usr/bin/time` (not built-in `time` from `bash`) shows that {{{ with -s 10000 option -> 20536maxresident k with -s 1000000 option -> 1567340maxresident k }}} //this suggests that leak really exists :)// == Analysis == Unpack the generated FMU and look at **TestAllTrue.c**: {{{#!c /* equation index: 4 type: SIMPLE_ASSIGN $whenCondition1 = Modelica.Math.BooleanVectors.allTrue({x, y, z}) */ void TestAllTrue_eqFunction_4(DATA *data, threadData_t *threadData) { TRACE_PUSH const int equationIndexes[2] = {1,4}; boolean_array tmp0; array_alloc_scalar_boolean_array(&tmp0, 3, (modelica_boolean)data->localData[0]->booleanVars[2] /* x variable */, (modelica_boolean)data->localData[0]->booleanVars[3] /* y variable */, (modelica_boolean)data->localData[0]->booleanVars[4] /* z variable */); data->localData[0]->booleanVars[0] /* $whenCondition1 DISCRETE */ = omc_Modelica_Math_BooleanVectors_allTrue(threadData, tmp0); TRACE_POP } }}} Looks like `array_alloc_scalar_boolean_array` was called but corresponding `..._free_...` was not. This was tested with FMU ME 1.0 and FMUChecker 2.0.3" anatoly.trosinenko@… 5197 Derivatives in IDA cpp target Cpp Run-time v1.13.0-dev-nightly Future defect somebody new 2018-11-01T13:26:25Z 2018-11-02T19:00:19Z "Models containing the der() pseudofunction result in an initialization error during simulation when using IDA solver and cpp target. C target and DASSL work fine for same simulation." Solipsism 5214 URI expansion misinterprets control characters Code Generation v1.13.0-dev-nightly Future defect Lennart Ochel new 2018-11-12T09:01:14Z 2018-11-12T09:01:14Z "I have a resource loaded with `loadResources` with the following syntax: {{{ Modelica.Utilities.Files.loadResource(""modelica://MyLibraryName/Resources/myfile.txt"") }}} Suppose that my library is stored in '''C:\folder1\videoterminal\MyLibraryName''' Once it gets expanded, the '''_init.xml''' file contains the following string `C:\folder1{\v}ideoterminal\MyLibraryName\Resources\myfile.txt` where {\v} is the control character `\v`. The normal path contains a `\v` in `\videoterminal` that is wrongly considered as a control character!" dariomangoni@… 5237 FreeBSD fails to build Build Environment Future defect Martin Sjölund assigned 2018-12-11T17:53:09Z 2019-01-29T08:35:11Z "Invalid operands to binary expression ('__bind' and 'int') {{{ c++ -DCMAKE_Fortran_COMPILER=gfortran7 -DPF_INET=AF_INET -DFLT_MAX=INFINITY -fPIC -O2 -pipe -fno-omit-frame-pointer -fPIC -DLIBICONV_PLUG -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -fno-stack-protector -O2 -pipe -fno-omit-frame-pointer -fPIC -DLIBICONV_PLUG -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -fno-omit-frame-pointer -DLIBICONV_PLUG -isystem /usr/local/include -c src/netstream-socket.cpp -o obj/netstream-socket.o src/netstream-socket.cpp:260:69: error: invalid operands to binary expression ('__bind' and 'int') if ( bind(server_socket_, (struct sockaddr*)&self, sizeof(self)) != 0 ) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~ }}} 1.14.0-dev FreeBSD 11.2 amd64 clang-60 " yuri@… 5257 OMEdit works only if started as superuser *unknown* Future defect trlo new 2018-12-22T15:28:13Z 2019-01-07T08:58:18Z "OMEdit 1.13.0 connected to OpenModelica 1.13.0 built for Ubuntu 16.04.5 LTS. The running OS is Linux Mint 18.3 on x86_64. OMEdit crashes after each ""Re-Simulation"". Only execution as superuser/root with ""sudo OMEdit"" works fine. Thanks a lot trlo" trlo 5331 "illogical ""incompatible components"" error in library model replica" Frontend Future defect somebody new 2019-02-11T23:07:10Z 2019-02-12T17:37:59Z "I am trying to model and replicate the ""Open Brayton Power Cycle"" from the OpenModelica Library and have come across an error message that makes little sense. The error message is the result of incompatibility between sourceMassflow.mo and CombustionChamber.mo, all taken from the modelica library and connected in the same fashion as the library Brayton example has been done. This error has occurred after completely replicating the ""Brayton Power Cycle - Open"" from the modelica library. This is the error I am receiving. This message almost proves that the two components are compatible with one another however I cannot figure out the reason why they are ""not working"" together. Code:// [11] 14:18:40 Translation Error [BraytonCycle_First: 49:3-50:84]: Incompatible components in connect statement: connect(sourceMassFlow1.flange, combustionChamber1.inf) - sourceMassFlow1.flange has components {C_outflow, Xi_outflow, h_outflow, m_flow, p} - combustionChamber1.inf has components {C_outflow, Xi_outflow, h_outflow, m_flow, p} I copied all of the library's component parameters into my model and expected this to solve the issue. Nothing I have done fixes this issue, where it seems that these models would be compatible due to the error message above. Any help or advice would be greatly appreciated." NRELintern 5341 OMEdit claiming flowrate variable is not constant Initialization Future defect Lennart Ochel new 2019-02-15T19:59:51Z 2019-02-19T18:22:30Z "I've been trying to model a Rankine Power Cycle on Modelica for a while now and keep running into a error that always stems from the use of a water pump imported from the ThermoPower Library. I receive the error: [2] 12:46:39 Translation Error Variable Pump.q_single0 in package ThermoPower.Water.Pump is not constant But it makes no sense because I directly input a value for the flow rate q_single on the ""component parameters"" interface before instantiating. I've tried to allow the program to calculate this parameter on its own via the embedded equation within the cell which pulls values from other assigned parameters. Also, since this value needs to be ""constant"" I made sure that all of the other parameters being used in this equation are staying constant, which they are. No luck. I've also tried using dummy values for this flow rate in hopes that an assigned numerical value will over ride the error of constant. No luck. Finally, I've tried going into the Text View of the model and located the Pump associated with this error. Once there, I've tried editing the code ... ThermoPower.Water.Pump Pump( Np0 = 1, V = 10, dp0 = 0, hstart = 1e5, n0 = 150, n_const = 150, q_single(fixed = true, start = 10), w0 = 50, w_single(fixed = false), wstart = 50) where I would switch fixed = true. This did not work as well. I feel like I have tried all options at my disposal as a 1 month user of OpenModelica but none of these solutions satisfies what the program actually wants. I am also curious as to why this code error is always associated with pump models. Please let me know what you think of the situation, I'm open to all ideas! I've attached the .mo file below for anyone curious. Thanks! " KieranF 5349 Internal error Transformation Module PFPlusExt index Reduction Method Pantelides failed! OMSimulator Future defect Lennart Ochel new 2019-02-19T23:48:34Z 2019-02-19T23:48:34Z "I have never seen this type of error before while using OpenModelica and have run out of solutions on how to trouble shoot this error. I made this HRSG Rankine cycle model imitating a couple of different types of examples available on the Modelica Library. The model can instantiate however when it comes times to simulate my model, this and (6) other errors appear. " KieranF 5368 Nightly Build 1.14.0 giving odd Syntax Warnings and Effecting Old Simulation Results *unknown* v1.14.0-dev-nightly Future defect somebody new 2019-03-01T16:06:15Z 2019-03-01T16:06:15Z "In an attempt to use the ThermoPower Library correctly I recently downloaded the nightly build to update the current version of OMEdit I have been using. Ever since I downloaded this version, I receive Syntax Warnings I have never seen before but am almost positive they have to do with the installation of the new OMEdit version. They read as follows: {{{ [1] 16:47:59 Scripting Warning Requested package Modelica of version 3.2.2, but this package was already loaded with version 3.2.3. You might experience problems if these versions are incompatible. [2] 16:47:59 Symbolic Warning The model contains alias variables with conflicting start and/or nominal values. It is recommended to resolve the conflicts, because otherwise the system could be hard to solve. To print the conflicting alias sets and the chosen candidates please use -d=aliasConflicts. }}} I normally would not have paid attention to these notifications, however, I tried opening a once working simulation of the Brayton Power Cycle I had on file and it now fails to work. This model I built is identical to the one located in ThermoPower.Examples.Brayton.OpenLoopSimulator. Exactly identical. It was once an extremely reliable model of mine and always would simulate. Now, after the installation of the nightly build, I am receiving errors as follows: {{{ C:/Users/kfung/AppData/Local/Temp/1/OpenModelica/OMEdit/BraytonPowerCycle_Plant/BraytonPowerCycle_Plant.exe -port=59573 -logFormat=xmltcp -override=startTime=0,stopTime=1,stepSize=0.002,tolerance=1e-6,solver=dassl,outputFormat=mat,variableFilter=.* -r=C:/Users/kfung/AppData/Local/Temp/1/OpenModelica/OMEdit/BraytonPowerCycle_Plant/BraytonPowerCycle_Plant_res.mat -w -lv=LOG_STATS -inputPath=C:/Users/kfung/AppData/Local/Temp/1/OpenModelica/OMEdit/BraytonPowerCycle_Plant -outputPath=C:/Users/kfung/AppData/Local/Temp/1/OpenModelica/OMEdit/BraytonPowerCycle_Plant The initialization problem is inconsistent due to the following equation: 0 != 121002 = ThermoPower.Gas.SourcePressure$braytonPowerCycle1$SourcePressure.Medium.h_TX(braytonPowerCycle1.SourcePressure.T, {braytonPowerCycle1.SourcePressure.Xnom[1], braytonPowerCycle1.SourcePressure.Xnom[2], braytonPowerCycle1.SourcePressure.Xnom[3], braytonPowerCycle1.SourcePressure.Xnom[4]}, true, Modelica.Media.Interfaces.Choices.ReferenceEnthalpy.ZeroAt25C, 0.0) - braytonPowerCycle1.Compressor.gas_in.h The following assertion has been violated during initialization at time 0.000000
braytonPowerCycle1.Compressor.gas_in.T >= 200.0 and braytonPowerCycle1.Compressor.gas_in.T <= 6000.0
Temperature T (=125.721 K = 200 K) is not in the allowed range
200 K <= T <= 6000 K
required from medium model ""Air"". simulation terminated by an assertion at initialization Simulation process failed. Exited with code -1. }}} These errors produced and given to me through the simulation compiler are very misleading and incorrect! What it is saying about the starting source pressure value is incorrect. What it is saying about the initial temperature of gas entering the compressor is also incorrect! I just cannot seem to move past these weird nuances with OpenModelica and the software is making less and less sense to me. If you have any advice or suggestions on how to trouble shoot this problem please let me know. I really don't understand why it is not simulating under these circumstance, especially because it's been copied by a working library Brayton model. " KieranF 5371 Heat Exchanger Model works & simulates but doesn't actually transfer energy to raise outlet temperature OMSimulator v1.13.0 Future defect Lennart Ochel new 2019-03-04T17:03:29Z 2019-03-04T17:03:29Z "In order to properly model a Rankine Power Cycle correctly I have started to disassemble the system into its respected components in an attempt to learn more about each component model and how they work individually. The model built was completed using the ThermoPower library. I built a simple Heat Exchanger model with FlueGas as the working fluid to heat up water. The FlueGas is coming in at a rate of 400 [kg/s] at a temperature of 700 [K] / 426.85 [C]. Within the simulation I am able to see that the FlueGas temperature drops from 426.85 [C] down to 26.85 [C], however looking at the water results, it does not increase in temperature at all. The inlet and outlet temperature values are at a constant 25 [C]. To make matters more confusing I incorporated ""Gas Temperature Sensors"", located ThermoPower.Gas.SensT, in between the inlet and outlet of both fluids in order to also observe how temperature changes with the use of a heat exchanger. This resulted in some very confusing results. The gas temperature at the outlet is observed to increase linearly which does not make sense as a working fluid. However the outlet temperature of the water does increase linearly which is about the only sanity check that does make sense in an instance of (1) [sec]. Although the time instance is yet another point of confusion for myself, for it was set to 30 [sec] but only simulated until 1 [sec]. Please feel free to leave a comment if you have any advice or insight you can provide me, its much appreciated. Thanks!" KieranF 5376 How can I simulate my models better and more specifically? OMSimulator v1.13.0 Future defect Lennart Ochel new 2019-03-05T17:00:37Z 2019-04-19T10:43:28Z "I started modeling subsystems of the Rankine Power Cycle in an attempt to verify each component works individually as well as how each component works with others. The model I have been working on has been a simple Heat Exchanger model. It only involves the HX, and (2) MassSourceFlow for the water and gas and (2) SinkSourceflow for the water and gas respectively. Finally, temperature sensors (SensT) were given to the inlet and outlets of each fluid for the Heat Exchanger for a total of (4) temperature sensors. This model was created using the ThermoPower Library where all of the components are from and located within this library. The model is able to be checked, it instantiates and it simulates consistently as well. The issue I am having is that the simulation does not describe the physics or desired results an ideal Heat Exchanger that one would expect. What's happening for me in my simulation is that the 700 [K] FlueGas is going through the Heat Exchanger and at the outlet is reading 372 [K]. These are the readings of sensT1 and sensT2 components for the inlet and outlet temperatures of the working fluid (FlueGas). These initial results are great and all at first inspection but looking into it more, its obvious that something is off and something is not working the way it should. Allow me to go into greater detail: The outlet sensT2 reads 372 [K]. But clicking on the tab in the simulation window shows the plot of temperature vs. time. In the plot, the temperature starts at 300 [K] and linearly increases over the interval of 30 [sec] to the temperature of 372 [K] by the time t=20 [s]. Here, at the outlet of the working fluid (FlueGas), it is increasing in temperature instead of transferring the heat to the other fluid, water, as a heat exchanger should. Looking at the water inlet and outlet sensT sensors show good results. The inlet reads 298 [K] and the outlet reads 372 [K]. It can be observed that the outlet starts increasing in temperature over the interval 0 5379 Cannot execute in path containing @ FMI Future defect Lennart Ochel new 2019-03-11T09:21:08Z 2019-03-11T09:21:08Z "Steps to reproduce the behavior: * Install OMSimulator in a path containing @ (for example a btrfs subvolume). * Run a test {{{ [martin@mega tlm]$ ../../install/linux/bin/OMSimulator tlm1d.lua assert | debug | Failed to open file /mnt/data/%40Mech/martin/dev/OMSimulator/testsuite/tlm/tlm1d-lua/model-0io41wrt/temp/mass/resources/tlm_massSpring_info.json for reading: No such file or directory getBestJumpBuffer got mmc_jumper=(nil), globalJumpBuffer=(nil) Aborted }}} --- see https://github.com/OpenModelica/OMSimulator/issues/627" Lennart Ochel 5386 Wrong copyright notice installed Documentation v1.14.0-dev-nightly Future defect Martin Sjölund new 2019-03-12T21:28:18Z 2019-07-27T17:47:36Z "When looking into the files of the installed Modelica Standard Library I found something strange: There are outdated copyright notices included in the file structures {{{/usr/share/doc/omlib-.../}}} The copyright notices do belong to previous version of the respective libraries. Please have a look at the attached files. * MSL 3.2.3 shows **Modelica License 2** but should be **3-BSD** by now * KeywordIO 0.9.0 shows **Modelica License 1** but should be **3-BSD** by now I suppose this shall be corrected." Christian Kral 5391 How do I fix the error, “Model is structurally singular, error found sorting equations” *unknown* v1.13.2 Future defect somebody new 2019-03-14T19:51:51Z 2019-04-17T18:52:57Z "This is one of the most common errors I receive when working with OpenModelica Software. I already understand how this error is usually triggered; when system parameters are conflicting and disagree with one another. I only recieve this error upon simulation. Leading up to that point, my model is able to be checked and instantiated. I've already tried omitting system parameters that I've deemed not an necessity to my system however nothing seems to fix the error. This was an attempt to get rid of system parameters that might be conflicting with one another. My system is already very simple to begin with. Currently, I'm working on a sub-assembly verification process in order to correctly build a working Rankine Power model. The sub assembly focuses on a (1) of (2) heat exchangers that would be used in a dual HX system incorporating a reheat process in between the High Pressure and Low Pressure turbines. This sub assembly is trying to describe water coming from a pump at a condensed liquid state where it will travel through a heat exchanger ""super heater"" where it will change the state from a compressed liquid to a superheated vapor. This vapor will then be fed into the High Pressure turbine and return into a Pressure Sink. I've already completed a hand calculated thermodynamic analysis of my system and know outlet temperatures and enthalpies. However, these outlet parameters are some of which I chose to remove for I felt I would let the system solve for them instead of telling it what it should calculate. Removing these values to solve the error did not work as well. If you have any thoughts, advice or considerations please let me know! Below I've posted the code to what I have been working on. Thanks again!" KieranF 5396 how to select a large number of output variables in a mos script *unknown* Future defect somebody new 2019-03-19T13:36:25Z 2019-03-21T14:07:21Z "I'm using a mos script to simulate OM model. So far I use the command ""variableFilter"" to select the outputs that I want to check after simulation. However, the number of output variables that I want to keep becomes larger and larger. I wonder if there's a way to call a file containing all the variable names from the mos script, instead of giving an exhaustive list of variables to ""variableFilter""? Thanks a lot! " yulu.dong@… 5402 sample(...) operator does not work in Cpp FMU runtime Code Generation v1.14.0-dev-nightly Future defect Lennart Ochel new 2019-03-25T12:42:06Z 2019-04-15T18:53:57Z "When using `sample` operator in a model, an FMU is compiled successfully, but it does not ""tick"". == How to reproduce == Compile this model: **TestSample.mo:** {{{#!modelica model TestSample output Integer counter; initial algorithm counter := 0; algorithm when sample(0, 0.25) then counter := counter + 1; end when; end TestSample; }}} ... with the following script: **tester.mos:** {{{#!modelica print(buildModelFMU(TestSample)); print(getErrorString()); }}} ... in C and Cpp modes. {{{ $ omc --simCodeTarget=C tester.mos TestSample.mo /tmp/TestSample.fmu $ ~/soft/FMUChecker-2.0.4/build/fmuCheck.linux64 -n 10 TestSample.fmu [INFO][FMUCHK] FMI compliance checker Test [FMILibrary: Test] build date: Sep 1 2018 [INFO][FMUCHK] Called with following options: [INFO][FMUCHK] /home/trosinenko/soft/FMUChecker-2.0.4/build/fmuCheck.linux64 -n 10 TestSample.fmu [INFO][FMUCHK] Will process FMU TestSample.fmu [INFO][FMILIB] XML specifies FMI standard version 2.0 [INFO][FMUCHK] Model name: TestSample [INFO][FMUCHK] Model GUID: {376610ce-4dff-45b4-9f45-3324c6b1c663} [INFO][FMUCHK] Model version: [INFO][FMUCHK] FMU kind: ModelExchange [INFO][FMUCHK] The FMU contains: 0 constants 0 parameters 3 discrete variables 0 continuous variables 0 inputs 1 outputs 2 local variables 0 independent variables 0 calculated parameters 0 real variables 2 integer variables 0 enumeration variables 1 boolean variables 0 string variables [INFO][FMUCHK] Printing output file header ""time"",""counter"" [INFO][FMUCHK] Model identifier for ModelExchange: TestSample [INFO][FMILIB] Loading 'linux64' binary with 'default' platform types [INFO][FMUCHK] Version returned from ME FMU: '2.0' [INFO][FMUCHK] Initialized FMU for simulation starting at time 0 0.0000000000000000E+00,1 1.0000000000000001E-01,1 2.0000000000000001E-01,1 3.4999999999999998E-01,2 4.4999999999999996E-01,2 5.0000000000000000E-01,3 5.9999999999999998E-01,3 6.9999999999999996E-01,3 8.4999999999999998E-01,4 9.4999999999999996E-01,4 1.0000000000000000E+00,5 [INFO][FMUCHK] Simulation finished successfully at time 1 FMU check summary: FMU reported: 0 warning(s) and error(s) Checker reported: 0 Warning(s) 0 Error(s) $ omc --simCodeTarget=Cpp tester.mos TestSample.mo /tmp/TestSample.fmu $ ~/soft/FMUChecker-2.0.4/build/fmuCheck.linux64 -n 10 TestSample.fmu [INFO][FMUCHK] FMI compliance checker Test [FMILibrary: Test] build date: Sep 1 2018 [INFO][FMUCHK] Called with following options: [INFO][FMUCHK] /home/trosinenko/soft/FMUChecker-2.0.4/build/fmuCheck.linux64 -n 10 TestSample.fmu [INFO][FMUCHK] Will process FMU TestSample.fmu [INFO][FMILIB] XML specifies FMI standard version 2.0 [INFO][FMUCHK] Model name: TestSample [INFO][FMUCHK] Model GUID: {9b7ffb92-39d7-42ca-abff-65d03f7643cc} [INFO][FMUCHK] Model version: [INFO][FMUCHK] FMU kind: ModelExchange [INFO][FMUCHK] The FMU contains: 0 constants 0 parameters 3 discrete variables 0 continuous variables 0 inputs 1 outputs 2 local variables 0 independent variables 0 calculated parameters 0 real variables 2 integer variables 0 enumeration variables 1 boolean variables 0 string variables [INFO][FMUCHK] Printing output file header ""time"",""counter"" [INFO][FMUCHK] Model identifier for ModelExchange: TestSample [INFO][FMILIB] Loading 'linux64' binary with 'default' platform types [INFO][FMUCHK] Version returned from ME FMU: '2.0' [INFO][FMUCHK] Initialized FMU for simulation starting at time 0 0.0000000000000000E+00,0 1.0000000000000001E-01,0 2.0000000000000001E-01,0 3.4999999999999998E-01,0 4.4999999999999996E-01,0 5.0000000000000000E-01,0 5.9999999999999998E-01,0 6.9999999999999996E-01,0 8.4999999999999998E-01,0 9.4999999999999996E-01,0 1.0000000000000000E+00,0 [INFO][FMUCHK] Simulation finished successfully at time 1 FMU check summary: FMU reported: 0 warning(s) and error(s) Checker reported: 0 Warning(s) 0 Error(s) }}} == What is expected == Both tick every 1/4 second. == What really happens == The Cpp FMU compiles successfully but does not work as expected. Maybe I should have used something like `counter := pre(counter) + 1;` but this does not work, too. For me, this looks quite serious, since when compiler refuses to compile model (even with an internal error), it is clear that something gone wrong. But in this case nothing suspicious happens nor when compiling nor in run-time." Anatoly Trosinenko 5414 Unsolvable Error pertaining to variable not found within model OMSimulator v1.13.2 Future defect Lennart Ochel new 2019-03-29T17:49:15Z 2019-04-01T16:06:06Z "I'm currently working on building a heat recovery steam generator and have just started building from the ThermoPower Library and connect an evaporator to the economizer. When trying to simulate an error occurs within the OMEdit Simulator: division by zero at time 0, (a=-458389.9207317767) / (b=0), where divisor b expression is: 8.75988806777792 * Economizer.metalTube.Am * Economizer.metalTube.rhomcm * /*Real*/(Economizer.metalTube.Nt) I'm not the best at debugging my models but I have an idea and I have some confusion trouble shooting this. My initial confusion was to verify which variable resulted in b=0. However, upon inspection I noticed how the variable Economizer.metalTube.Nt, Economizer.metalTube.Am did not exist within my the economizer class. I knew it had to be rooted into my class through extensions and partial classes and tried to define these ""missing"" variables in the text view of my economizer model, but this simply resulted in an error saying: [1] 11:46:14 Translation Error [ThermoPower_HRSG_Econ_Evap: 68:3-92:112]: Variable Economizer: In modifier (Nt = 3), class or component Nt not found in . How exactly do I trouble shoot this error if I cannot define or locate the needed variables that are causing b=0? Please let me know what you think about this. Your time and energy is greatly appreciated. " KieranF 5424 How do I access/locate the code fragment transformations while my model is being flattened? Frontend v1.13.2 Future defect somebody new 2019-04-05T20:04:55Z 2019-04-05T20:04:55Z "In an effort to learn and improve my almost non-existent debugging skills, a book I've been reading suggests that I look into the code transformations that occur to my model when it is being flattened. I've known for a while now, that OpenModelica compiles the modelica model from it's EOO language into C. What I recently learned about how the compiler will replace, reject or alter the original input code and change it to the extent that a user with little computer science background (me) will not be able to recognize the errors produced and how to trouble shoot them (me times 100). I haven't had the best luck with trouble shooting and solving the errors developed from my models and hope that this route will give me a new perspective on debugging. The book I am referencing is called, ""Tools and Methods for Analysis, Debugging, and Performance Improvements of Equation-Based Models"" written by Martin Sjolund " KieranF 5433 FMU GetString returns \x3 FMI v1.14.0-dev-nightly Future defect Lennart Ochel new 2019-04-12T13:03:32Z 2019-04-12T14:09:13Z "I know, it's a **very** unclear bug report, but because of this I had to roll back to previous version. Version (stable) v1.13.2 works just fine. Version v1.14.0-dev-169-g050a82062 worked just fine. Version v1.14.0-dev-225-g199705757 is broken. FMU GetString returns **in some cases** an '\x3' character. I tried to understand the pattern: it happens especially when I have to read a 'shapeType' String that is of the type 'modelica://MyLibrary/something.stl' but not in ALL the models. (some of the models with external shapeType worked even with the 'broken' version). And I can't share my code because it's under NDA. Yes, blame me :-( Maybe you can check in the Git log if something happened during this period... " dariomangoni@… 5440 visualization crash OMEdit Future defect Volker Waurich new 2019-04-18T05:31:39Z 2019-05-09T09:30:15Z "The visualization crashes for the following model {{{ model visShapeSTL parameter String wheelShapeFile = Modelica.Utilities.Files.fullPathName(""file:///wheel.stl""); Modelica.Mechanics.MultiBody.Parts.Fixed fixed annotation( Placement(visible = true, transformation(origin = {-30, 0}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); inner Modelica.Mechanics.MultiBody.World world annotation( Placement(visible = true, transformation(origin = {-90, 90}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Mechanics.MultiBody.Visualizers.Advanced.Shape vis( shapeType=wheelShapeFile, r_shape={0,0,0}, lengthDirection={1,0,0}, widthDirection={0,1,0}, length=1.0, width=1.0, height=1.0, color={0,128,255}, extra=0.0, specularCoefficient=world.defaultSpecularCoefficient, r=world.frame_b.r_0, R=world.frame_b.R) if world.enableAnimation; annotation( Placement(visible = true, transformation(origin = {12, 2}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); equation annotation( uses(Modelica(version = ""3.2.3""))); end visShapeSTL; }}}" Volker Waurich 5498 High Memory Usage When Opening a Model *unknown* v1.14.0-dev-nightly Future defect somebody new 2019-05-20T12:10:49Z 2019-05-23T08:24:58Z I have a model with ca. 15.600 equations(~7400 equations are trivial). When opening the model, i've noticed the memory usage jumps to 12GB and stays at that level even though i've closed the model. How can i test for a memory leak? or is it a memory leak problem in the first palce? unfortunately, i can't share the model. Arinomo 5499 setParameters of ModelicaSystem has no effect on simulation OMPython Future defect Alachew Mengist new 2019-05-20T12:24:47Z 2020-03-12T21:28:48Z "Hi, I'm trying to run the PowerWorld example from the PowerSystems library via OMPython. No errors occur and the simulation itself works. The solutions are correct compared to the ones of OMEdit. However I run into problems when manipulating the parameters: {{{ from OMPython import ModelicaSystem mod = ModelicaSystem('/home/XXX/PowerSystems/package.mo', ""PowerSystems.Examples.PowerWorld.PowerWorld"", [""Modelica""]) mod.setParameters(**{'windFarm.cut_out': 1.0}) mod.simulate() print(mod.getParameters().get('windFarm.cut_out'))#prints out 1.0 frequ_sols = mod.getSolutions('frequency.y') print(frequ_sols)#solutions are for windFarm.cut_out=0.0 :( }}} windFarm.cut_out has the default value 0.0. I set windFarm.cut_out to 1.0. No error occurs. I start the simulation. The solutions (checked with the help of frequ_sols) are incorrect. The solutions are still the solutions of the default value. I don't see any mistake on my side or hint in the doc that could help me. " anonymous 5532 Support use of interactive variables in the OMC API Interactive Environment Future defect somebody new 2019-06-13T20:41:02Z 2019-06-13T20:41:02Z " See: https://stackoverflow.com/questions/56568988/openmodelica-script-issue-about-setparametervalue/ " Adrian Pop 5551 Cannot open the OMEdit internal Modelica documentation *unknown* Future defect somebody new 2019-06-27T12:53:26Z 2019-06-27T13:17:44Z "I just build openmodelica-git module in Archlinux straight from AUR. The program seems to work so far but when I want to open the `ModelicaReference > ModelicaGrammar` page from the internal documentation, OMEdit raises an exception. The UI halts, some small images of bugs appear at various places all over the UI and I get a core dump. This happens all the time so it is reproducable. I generated a backtrace and will try to attach it to the ticket." github@… 5553 [MetaModelica] Warn if a function gets to big and has too many cases MetaModelica Future defect Martin Sjölund new 2019-06-28T09:29:19Z 2019-06-28T09:29:19Z "I think we should have a warning if a function gets too big (like the API handling ones) because this generates bad code with some compilers (for example clang 3.8.0-2ubuntu4 on Ubuntu 16.04). See: #5548 and PR: https://github.com/OpenModelica/OpenModelica/pull/288" Adrian Pop 5556 Undefined behavior in OpenModelicaScriptingAPIQt.cpp Susan (Templates) v1.14.0-dev-nightly Future defect Adrian Pop new 2019-06-29T14:27:32Z 2019-06-29T14:27:32Z "According to [https://test.openmodelica.org/scan-build/latest/2019-06-28-122907-428-1/ Clang Static Analyzer reports], the `OpenModelicaScriptingAPIQt.cpp` file contains lots of exception handling triggering Undefined Behavior such as [https://test.openmodelica.org/scan-build/latest/2019-06-28-122907-428-1/report-57a8da.html#EndPath this one]. On the first glance, it looks like harmless rethrowing, but OMEdit [https://github.com/OpenModelica/OpenModelica/blob/4dc44f91c3bb6d10b5571cbf1217b922479ff0d3/OMEdit/OMEdit/OMEditGUI/OMC/OMCProxy.cpp#L249 contains the code] that handles this `throwException` signal with `showException` slot. This suggests that it is not a noreturn function, so the execution flows to the line {{{#!cpp responseLog.append(result ? ""true"" : ""false""); }}} This, again, looks harmless (just slightly misleading random `true` or `false` in log), but precisely this pattern was observed as [https://stackoverflow.com/questions/54120862/does-the-c-standard-allow-for-an-uninitialized-bool-to-crash-a-program crasing the program] instead of just showing garbage: the compiler spotted, that {{{#!cpp strlen(flag ? ""true"" : ""false"") == 1 - flag }}} I have tried to rewrite this file but have not succeeded: looks like one bootstrapping iteration was not enough in my case... Though, there are examples of commits successfully changing this template. This shows some non-triviality of contributing to this file." Anatoly Trosinenko 5559 Issues with large parameter arrays Backend Future defect Lennart Ochel new 2019-07-02T10:27:17Z 2019-07-03T10:45:51Z "See forum post: https://www.openmodelica.org/forum/default-topic/2734-ram-problem-with-very-large-arrays-used-as-parameters-in-a-model I have observed this myself as well for the old front-end. With -d=newInst is much better for the front-end but the back-end uses a lot of memory and time to generate the code. {{{#!mo model test public parameter Integer Nmax = 100; protected parameter Real x[Nmax](each fixed=false) ""abscissa""; parameter Real y[Nmax](each fixed=false) ""y=f(x)""; // any variable for my calculation initial algorithm x := linspace(0.0,14.5,Nmax); // In this example f (x) = -1 and there would be no need for an array, // obviously I fill y with a more complicated algorithm, not a simple formula... y := fill(-1.0,Nmax); equation // any equation for my calculation end test; }}} " Adrian Pop 5572 Delay operator in a for loop of an algorithm section Backend Future defect Lennart Ochel new 2019-07-08T14:02:30Z 2019-07-10T21:36:44Z "The following simple model using a delay operator in a for-loop inside an algorithm section is not handled by OpenModelica. {{{#!mo model test3 Real x=sin(377*time); Real z; parameter Real tau[:]={0.01,0.02}; equation algorithm for k in 1: 2 loop z:=delay(x,tau[k]); end for; end test3; }}} original post: https://stackoverflow.com/questions/56916012/error-due-to-delay-operator-in-algorithm-section" adrien.guironnet@… 5576 Solve array equation in backend for array of records Backend Future defect Karim Adbdelhak new 2019-07-10T11:36:43Z 2019-07-10T11:37:27Z "We get an error for arrays of records in the SimCode-phase. When simulating {{{ record simplRec Real a; end simplRec; function func input Real a; output simplRec out[3]; algorithm out[1].a := a; out[2].a := a*a; out[3].a := a*a*a; end func; model testArraysOfRecors simplRec A[3]; equation A = func(1); end testArraysOfRecors; }}} See the error log: {{{ Error processing file: bugArrayRecord.mo [D:/workspace/OpenModelica/OMCompiler/Compiler/SimCode/SimCodeUtil.mo:6462:7-6462:48:writable] Error: Internal error solving array equation: 1 : A = func(1.0) for variable: A[1].a. [D:/workspace/OpenModelica/OMCompiler/Compiler/SimCode/SimCodeUtil.mo:1478:5-1478:77:writable] Error: Internal error createEquationsForSystems failed [D:/workspace/OpenModelica/OMCompiler/Compiler/SimCode/SimCodeUtil.mo:746:5-746:146:writable] Error: Internal error function createSimCode failed [Transformation from optimised DAE to simulation code structure failed] # Error encountered! Exiting... # Please check the error message and the flags. Execution failed! }}} " Andreas Heuermann 5579 New Frontend does not check for circular dependencies in parameter bindings New Instantiation Future defect Per Östlund new 2019-07-11T15:30:30Z 2019-07-12T13:12:31Z "Consider following model: {{{ model circularBinding parameter Boolean b1 = true; parameter Real f = if b1 then g else 2.0; parameter Real g = if b1 then 2.0 else f; end circularBindung; }}} The old frontend detected the (seemingly) possible circular dependency in the bindings of {{{f}}} and {{{g}}} and marked the condition {{{b1}}} with {{{final=true}}}. The new frontend does not do that and therefore it fails in the backend. The minimal thing that is needed is that {{{{b1}}} has to get {{{final= true}}}, that is what the old frontend does and {{{evaluateParameters}}} in combination with {{{simplifyIfEquations}}} takes care of it. But those models are mostly useless right now and it would be great to get rid of them or at least thin them out (i guess some form of simplification for if equations has to stay). Optimally the frontend would take care of it, detect and resolve the structural parameters. Also related: The old frontend evaluated protected parameters whereas the new frontend does not. As far as i know they can't be changed after compilation anyways, so what is the correct way to handle it?" Karim Adbdelhak 5673 Error regarding alias variables and variability FMI Future defect Lennart Ochel new 2019-10-24T12:46:05Z 2019-10-24T12:46:05Z "The VDM checker detected errors regarding variability of alias variables of OpenModelica exorted FMUs, see https://github.com/modelica/fmi-cross-check/issues/76 Perhaps this is old stuff as in the FMI Cross-Check Repo https://github.com/modelica/fmi-cross-check/tree/master/fmus/2.0 I find only FMUs for OM 1.11. for arm-linux gnuabi, which is not the most commonly used platform :-) It would be great if OpenModelica would actively participate in the FMI cross-check with up-to-date versions, as to my experience this drastically improves the quality of FMI implementations of tools." cbertsch 5744 Problems to simulate MSL models with OM nightly Installation program v1.16.0-dev Future defect Martin Sjölund assigned 2019-12-10T19:35:57Z 2020-07-12T16:31:03Z "Im am using the following version of OM nightly und Linux Mint 19.2: {{{ Connected to OpenModelica 1.16.0~dev-72-gc3a557c Connected to OMSimulator unknown-linux }}} However, I have a lot of difficulties to run OM simulations currently, but I cannot say whether this is the installation on my machine (which I guess is the case) or the actual OpenModelica version. After I noticed some problems a week ago, I re-installed everything (through Synaptic) but that did not change anything. Please let me step-by-step explain what I notice: 1) Start of OMEdit I get the following messages: {{{ [1] 20:18:35 Scripting Notification Skipped loading package Complex (3.2.3,default) using MODELICAPATH /usr/bin/../lib/omlibrary:/home/christian/.openmodelica/libraries/ (uses-annotation may be wrong). [2] 20:18:35 Scripting Notification Skipped loading package ModelicaServices (3.2.3,default) using MODELICAPATH /usr/bin/../lib/omlibrary:/home/christian/.openmodelica/libraries/ (uses-annotation may be wrong). [3] 20:18:35 Scripting Error Failed to load package ModelicaReference (3.2.3) using MODELICAPATH /usr/bin/../lib/omlibrary:/home/christian/.openmodelica/libraries/. }}} I go to the indicated directory {{{omlibrary}}} and see all the installed libraries: {{{ christian@Yogix:/> christian@Yogix:/> cd /usr/bin/../lib/omlibrary christian@Yogix:omlibrary> ls 'Buildings 5.1.0' OpenBLDC 'ElectroMechanicalDrives 2.2.0' 'PhotoVoltaics 1.5.0' 'EMOTH 1.4.0' 'PhotoVoltaics_TGM 1.5.0' GNU_ScientificLibrary 'PlanarMechanics 1.4.1' 'HanserModelica 1.1.0' PlanarMechanicsTest 'KeyWordIO 0.9.0' 'PowerFlow 0.3' 'Modelica 3.1' PraxisSimulationstechnik 'Modelica 3.2.1' 'PVSystems 0.6.3' 'Modelica 3.2.2' 'SiemensPower 2.2' 'Modelica 3.2.3' 'Spot 0.706.1' 'ModelicaTest 3.2.1' 'SpotExamples 0.706.1' 'ModelicaTest 3.2.2' 'SystemDynamics 2.1' 'ModelicaTest 3.2.3' 'VehicleInterfaces 1.2.4' 'ModelicaTest trunk' 'WindPowerPlants 1.3.0' 'Modelica trunk' 'XogenyTest 1.1' }}} 2) I try a simple Model {{{ model Test Real x(start = 1); equation der(x) = -x; end Test; }}} This model simulates OK with no complaints. 3) I simulate {{{Modelica.Blocks.Examples.Filter}}} When I try to simulate this model I get asked to switch back the old frontend and then the following error messages occur in the **Messages Browser**: {{{ [1] 20:25:59 Scripting Notification Skipped loading package Complex (3.2.3,default) using MODELICAPATH /usr/bin/../lib/omlibrary:/home/christian/.openmodelica/libraries/ (uses-annotation may be wrong). [2] 20:25:59 Scripting Notification Skipped loading package ModelicaServices (3.2.3,default) using MODELICAPATH /usr/bin/../lib/omlibrary:/home/christian/.openmodelica/libraries/ (uses-annotation may be wrong). [3] 20:25:59 Translation Error [Modelica.Constants: 25:3-26:101]: Variable ModelicaServices.Machine.Integer_inf not found in scope Constants. [4] 20:25:59 Translation Error [Modelica.Blocks.Continuous: 2271:9-2271:37]: Import Modelica.Constants.pi not found in scope . [5] 20:25:59 Translation Error [Modelica.Blocks.Continuous: 2293:11-2293:73]: Variable pi not found in scope Butterworth. [6] 20:26:08 Scripting Notification Skipped loading package Complex (3.2.3,default) using MODELICAPATH /usr/bin/../lib/omlibrary:/home/christian/.openmodelica/libraries/ (uses-annotation may be wrong). [7] 20:26:08 Scripting Notification Skipped loading package ModelicaServices (3.2.3,default) using MODELICAPATH /usr/bin/../lib/omlibrary:/home/christian/.openmodelica/libraries/ (uses-annotation may be wrong). [8] 20:26:08 Translation Error [Modelica.Blocks.Continuous: 2410:9-2411:40]: Variable .Modelica.Constants.pi not found in scope Modelica.Blocks.Continuous.Internal.Filter.coefficients.lowPass. [9] 20:26:08 Translation Error [Modelica.Constants: 19:3-20:47]: Variable ModelicaServices.Machine.eps not found in scope Modelica.Constants. [10] 20:26:08 Translation Error [Modelica.Blocks.Continuous: 2446:9-2447:40]: Variable .Modelica.Constants.pi not found in scope Modelica.Blocks.Continuous.Internal.Filter.coefficients.highPass. [11] 20:26:08 Translation Error Error occurred while flattening model Modelica.Blocks.Examples.Filter }}} So this model does neither compile nor simulate. --- So it seems there is a problem with loading and/or treating the Modelica Standard Library correctly. * Could anyone on a Linux machine please confirm / not confirm my findings? * Any ideas what could have gone wrong? * Could that have been caused by installing some other software?" Christian Kral 5745 Problem installing OM on macOS Catalina with Macports *unknown* Future defect somebody new 2019-12-11T00:22:35Z 2019-12-11T07:41:01Z """sh-3.2# port install gcc44 # With the addition of llvm/clang as the default compiler in XCode, many ports now fail to build unless you force GCC to be used. Newer MacOS versions may require more recent gfortran compilers available ---> Fetching distfiles for gcc44 Error: building gcc44 is not supported with Xcode 9 or greater Error: Failed to fetch gcc44: unsupported platform Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc44/gcc44/main.log for details. Error: Follow https://guide.macports.org/#project.tickets to report a bug. Error: Processing of port gcc44 failed” " Ariel Liebman 5774 [CG] Records with one component have code generation issues Code Generation Future defect Lennart Ochel new 2020-01-08T17:58:13Z 2020-01-13T12:07:13Z "Reported here: https://openmodelica.org/forum/default-topic/2864-passing-record-in-external-c-function It seems that the compiler does some sort of bad optimization for records with one component." Adrian Pop 5793 Comments in enumerations are not shown in OMEdit in case of type imports *unknown* Future defect somebody new 2020-01-20T08:50:28Z 2020-01-20T08:50:28Z " Please check the attached test package. If you open {{{System}}} with OMEdit, double-click on {{{m}}}, and select a new value for parameter {{{p}}}, the enumeration values are shown, instead of their explanatory comments. I guess the API ignores the import statmentes, which are often use for convenience, in order to avoid very long paths in the source code. This should be preferably fixed for 2.0.0 " Francesco Casella 5808 OMedit focus jumps from one block to another on a right click.... *unknown* Future defect somebody new 2020-01-29T02:16:56Z 2020-01-29T02:16:56Z "To reproduce I select a block by left clicking it in the diagram view. then right click over the same block to to change parameters or attributes... a menu appears but it does the focus shifted to a different block. In the attached file when I try to edit the parameters of sine0 I get the parameters of samplermd and when I try to edit filtermd I get filter6" mdonolo@… 5812 Start values lost in big power plant initialization Backend Future defect Karim Adbdelhak new 2020-01-30T12:38:25Z 2020-01-30T16:53:42Z "When trying to simulate {{{FlexiCaL.Plants.Test.TestPlantDeltaOffDesign}}} with {{{-d=evaluateAllParameters}}}, I get a solver failure at the first iteration of the big nonlinear system of equations for lambda = 0. This is most likely due to wrong start values, since the model is successfully initialized by Dymola. Some analysis reveals that the two most probable causes are - loss of start values for {{{fixed = false}}} parameters - loss of start values for some enthalpy variables. The former issue is addressed in see ticket:5807#comment:9. The latter issue is reported here. For example, the flattened model contains {{{ Real Plant.Carbonator.SH.htilde[10]( quantity = ""SpecificEnergy"", unit = ""J/kg"", min = -10000000000.0, max = 10000000000.0, start = 3331000.0, nominal = 500000.0, stateSelect = StateSelect.prefer) ""Enthalpy state variables""; }}} but then the nonlinear solver diagnostic message reports {{{ proper start-values for some of the following iteration variables might help ... [306] Real Plant.CalcinerSection.a_SH2_1.fluidFlow.htilde[4](start=100000, nominal=500000) ... }}} with the start value of 100000 being the default start value for the type used to define {{{htilde}}}." Francesco Casella 5822 PowerSystems sensor model segfaults during matching Backend v1.16.0-dev Future defect Lennart Ochel new 2020-02-03T12:05:38Z 2020-02-03T13:12:50Z The `PowerSystems.Examples.AC1ph_DC.Elementary.Sensor` model segfaults in `match_pf_fair` (`runtime/matching.c:356`), called from `IndexReduction.selectStates`, seemingly because it tries to read past the end of the `col_ids` array. I don't know if this is because of an issue with the algorithm itself or with the data it's given though. Per Östlund 5826 [OMEdit] Automatically expand the filtered library tree OMEdit Future defect Adeel Asghar new 2020-02-04T09:30:22Z 2020-02-04T09:30:22Z Currently when we filter the library tree you need to manually expand the tree to get to the filtered item. The tree should be expanded automatically. Adrian Pop 5833 No responds using Interact widget in IJulia with OMJulia OMJulia v.1.15.0-dev Future defect Adrian Pop new 2020-02-06T12:48:44Z 2020-02-06T18:52:20Z "Using the following code in IJulia {{{ @manipulate for d = 0:0.1:2 setParameters(mod,[""c=1"",""m=1"",""d=""*string(d)]) simulate(mod) t, x = getSolutions(mod,[""time"",""x""]) PyPlot.plot(t,x) end }}} displays a slider widget and a plot of the curve. But moving the slider does not update plot. Removing the '@manipulate' creates as expected a char of curves. Am I missing something or is this a bug?" Oliver Lenord 5890 buildModel() fails with 'ModelicaSystem' object has no attribute 'buildModel' OMPython v1.16.0-dev Future defect Alachew Mengist reopened 2020-03-12T23:21:25Z 2020-04-06T23:34:18Z "Hi I like to use a Modelica block, set its parameters and simulate it while assigning its inputs from a csv file. Running the commands below, which are from https://www.openmodelica.org/doc/OpenModelicaUsersGuide/latest/ompython.html#enhanced-ompython-features, gives the shown error. {{{ >>> from OMPython import OMCSessionZMQ >>> omc = OMCSessionZMQ() 2020-03-12 15:58:29,708 - OMPython - INFO - OMC Server is up and running at file:////tmp/openmodelica.mwetter.port.b2a371262e6c4fb182a2e58d04ac0dee pid=49441 >>> model_path=omc.sendExpression(""getInstallationDirectoryPath()"") + ""/share/doc/omc/testmodels/"" >>> from OMPython import ModelicaSystem >>> mod=ModelicaSystem(model_path + ""BouncingBall.mo"",""BouncingBall"") 2020-03-12 15:59:14,981 - OMPython - INFO - OMC Server is up and running at file:////tmp/openmodelica.mwetter.port.f6bfd8fa2b0044b5a13ab273c9613b4c pid=49446 >>> mod.buildModel() Traceback (most recent call last): File """", line 1, in AttributeError: 'ModelicaSystem' object has no attribute 'buildModel' }}} Is such a functionality still supported? If not, is there a way to realize this in omc? I tried {{{ import shutil import os from OMPython import OMCSessionZMQ model=""Buildings.Controls.OBC.ASHRAE.G36_PR1.AHUs.SingleZone.VAV.SetPoints.Supply"" parameters=""(yHeaMax=0.7, yMin=0.3, TSupSetMax=303.15, TSupSetMin=289.15)"" omc = OMCSessionZMQ() omc.sendExpression(""loadModel(Buildings)"") omc.sendExpression(""simulate({}, startTime=0, stopTime=3600, simflags=\""-csvInput reference_input.csv\"", outputFormat=\""csv\"")"".format(model)) }}} with {{{reference_input.csv}}} {{{ time, uHea, uCoo, TZonSet, TZon, TOut, uFan 0, 1, 1, 293.15, 293.15, 283.15, 0 3600, 1, 1, 293.15, 293.15, 283.15, 0 }}} but {{{uHea}}} is always zero. Adding a terminating comma as proposed in https://openmodelica.org/forum/default-topic/2627-csvinput-usage-and-input-file-format#p8935 won't help. Moreover, I have not found a documentation for how to set parameters in the block {{{Supply}}}, hence the attempt with {{{ModelicaSystem}}} which appears to provide this functionality" Michael Wetter 5894 segfault after 1020 simulations in Python 3 (but not Python 2) FMI v1.16.0-dev Future defect Lennart Ochel new 2020-03-24T10:47:37Z 2020-03-24T10:47:37Z "I export a very simple model (3 equations) as FMU in order to simulate it with Python 2000 times. It worked using Python 2, but not anymore using Python 3. ipbd indicates error happens at fmu2instantiate, but the simulation library FMPy only forwards the memory management calls to the native functions of the OS." gerrer@… 5898 loadCompletePackageFromMp fails when directory-structured library has models that differs only in letter case Interactive Environment Future defect Adrian Pop assigned 2020-03-25T11:25:42Z 2020-04-01T09:11:37Z "Strange situation, not sure if it is specifications-compliant: OpenModelica cannot load a library in Directory Hierarchy structure whose models have names that differ only for letter case. I passed from OneFile to Directory structure with a well-known Modelica editor... My package was like this: - MyPackage |- model1 |- Model1 at the beginning, ''model1'' and ''Model1'' were both in a single '''MyPackage.mo''' file. Good. Once I split in single files (i.e. Directory structure), this famous Modelica editor gave me a subfolder named '''MyPackage''' whose '''package.order''' file have TWO lines, namely ''model1'' and ''Model1'', however in the folder I have just ONE file, named '''model1.mo'''. Of couse, I couldn't have a '''Model1.mo''' in the same folder, so in the same '''model1.mo''' file both ''model1'' and ''Model1'' models have to be fit! However, this throws the error: {{{ [1] 12:19:22 Translation Error [C:/dev/OM64bit/OMCompiler/Compiler/FrontEnd/ClassLoader.mo: 299:9-299:128]: Internal error loadCompletePackageFromMp failed for unknown reason: mp=C:/workspace/_modelica_temp/ pack=DirectoryFailure [2] 12:19:22 Scripting Error Failed to load package DirectoryFailure () using MODELICAPATH C:/workspace/_modelica_temp/.}}} HOWEVER, strange as it seems, if you put the original one-file library '''MyPackage.mo''' in the same containing folder in which there is also the folder '''MyPackage''' everything works back, even if you ask to load the '''MyPackage/package.mo'''!!!! Plase read carefully this few lines above because it's tryuly incredible. " dariomangoni@… 5899 MacOS 15.3 install problem using macports Installation program v1.14.1 Future defect Martin Sjölund assigned 2020-03-26T20:19:10Z 2020-04-01T15:20:24Z Having trouble installing OpenModelica on MacBook Pro with MacOS 15.3. Have done uneventful install on several other Mac with earlier versions of MacOS. Robert.L.Gardner@… 5931 Use the same place for client settings and libraries in Windows Interactive Environment Future defect somebody new 2020-04-30T18:28:59Z 2020-05-07T18:48:15Z "Currently - the package manager uses: {{{%APPDATA%/.openmodelica/library}}} - OMEdit uses {{{%APPDATA%/openmodelica/}}} I think OMEdit should also use {{{%APPDATA%/.openmodelica/}}} for the settings and also all the clients should use the same place." Adrian Pop 5957 Failed to sole linear system of equations at time 0, system is singular Initialization Future defect Karim Adbdelhak assigned 2020-05-14T11:07:02Z 2020-05-14T11:56:07Z "I am working on modelling photovoltaic power plants electrical grids. When adding inductors to the model, it fails to solve. The model without the inductances is solid and works properly. I have already tried diferent types of solvers, but no results. I get the error: Failed to solve linear system of equations (no. 517) 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." lluc@… 6076 The enclosed code translates, Test2 can be instantiated, but compilation fails. Test runs Code Generation v1.16.0-dev Future defect Per Östlund assigned 2020-07-29T17:20:55Z 2020-07-31T10:24:19Z "Dear all, trying to encapsulate an external object class (TSModelHandle) within an interface class (TSModelC, allowing, for example, to derive its icon from the graphic classes) I get a compilation error building Test2 (Test runs correctly). Despite my environment is complex and you will not be able to reproduce the problem yourself (the external object is an interface layer to Python3 code), I think that the compiler complains could be indicative enough for somebody of you to see immediately if my attempt is fundamentally flawed. If not, there could be a problem in the code generation. This happen with version 1.14.1 and 1.16.0-dev.03. IF you need me to do some testing I will be happy to do it. Sincerely, Anton {{{ within SHCControls; package TSModel extends Modelica.Icons.TypesPackage; class TSModelHandle extends ExternalObject; function constructor ""Gets an handle to a TSModel object loaded from file."" extends Modelica.Icons.Function; input String fileName; input String modelName; output TSModelHandle tsmh; external ""C"" tsmh = initTSModel(fileName, modelName) annotation( Library = ""TSModel-Interface"", LibraryDirectory = ""file:///C:/Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release""); end constructor; //C:\\Development\\shc-controls\\SHCLib\\C-Cpp\\Cpp-ModelicaInterface\\Build\\Release function destructor ""Release storage of the TSModel object."" extends Modelica.Icons.Function; input TSModelHandle tsmh; external ""C"" finalTSModel(tsmh) annotation( Library = ""TSModel-Interface"", LibraryDirectory = ""file:///C:/Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release""); end destructor; // external ""C"" finalTSModel(tsmh) annotation(Library=""TSModel-Interface""); // If not specified looks in the default dir Library/win64 end TSModelHandle; function tsmEval ""Evaluate model at point u"" extends Modelica.Icons.Function; input TSModelHandle tsmh; input Real u[:]; output Real y[ysize]; input Integer ysize; external ""C"" tsmEval(tsmh, u, size(u, 1), y, size(y, 1)) annotation( Library = ""TSModel-Interface"", LibraryDirectory = ""file:///Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release""); end tsmEval; function invTsmEval ""Evaluate inverse model at point y"" extends Modelica.Icons.Function; input TSModelHandle tsmh; input Real u0[:]; input Real y[:]; output Real u[size(u0, 1)]; external ""C"" tsmEvalInv(tsmh, u0, size(u0, 1), y, size(y, 1), u, size(u, 1)) annotation( Library = ""TSModel-Interface"", LibraryDirectory = ""file:///Development/shc-controls/SHCLib/C-Cpp/Cpp-ModelicaInterface/Build/Release""); end invTsmEval; model Test ""Test of the TSModel package"" import Modelica.Blocks.Sources.{Step,Constant}; import Modelica.Blocks.Routing.{Multiplex2}; TSModelHandle tsmh = TSModelHandle(fileName = ""C:\\Development\\shc-controls\\SHCLib\\Python\\tests\\cannonau2x2.mat"", modelName = ""Cannonau""); // call initTSModel Real u0[2] = {0.4, 75e3}; Real u[2]; Real y[2]; Real uTilde[2]; Step T1R(height = 5, offset = 273.15 + 50, startTime = 10) annotation( Placement(visible = true, transformation(origin = {-70, 70}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Step M1R(height = 0.03, offset = 0.3, startTime = 20) annotation( Placement(visible = true, transformation(origin = {-70, 30}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Step U(height = 0.05, offset = 0.5, startTime = 15) annotation( Placement(visible = true, transformation(origin = {-70, -30}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Step DP(height = 1000, offset = 50000, startTime = 15) annotation( Placement(visible = true, transformation(origin = {-70, -70}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Multiplex2 muxR annotation( Placement(visible = true, transformation(origin = {-30, 50}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Multiplex2 muxU annotation( Placement(visible = true, transformation(origin = {-30, -50}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); equation u = muxU.y; y = tsmEval(tsmh, u, size(y, 1)); uTilde = invTsmEval(tsmh, u0, muxR.y); connect(U.y, muxU.u1[1]) annotation( Line(points = {{-58, -30}, {-50, -30}, {-50, -44}, {-42, -44}, {-42, -44}}, color = {0, 0, 127})); connect(DP.y, muxU.u2[1]) annotation( Line(points = {{-58, -70}, {-50, -70}, {-50, -56}, {-42, -56}, {-42, -56}}, color = {0, 0, 127})); connect(M1R.y, muxR.u2[1]) annotation( Line(points = {{-59, 30}, {-50, 30}, {-50, 44}, {-42, 44}}, color = {0, 0, 127})); connect(T1R.y, muxR.u1[1]) annotation( Line(points = {{-59, 70}, {-50, 70}, {-50, 56}, {-42, 56}}, color = {0, 0, 127})); annotation( experiment(StartTime = 0, StopTime = 50, Tolerance = 1e-06, Interval = 0.1)); end Test; class TSModelC parameter String fileName = ""C:\\Development\\shc-controls\\SHCLib\\Python\\tests\\cannonau2x2.mat""; parameter String modelName = ""Cannonau""; parameter TSModelHandle tsmh = TSModelHandle(fileName, modelName); function eval ""Evaluate model at point u"" extends Modelica.Icons.Function; input Real u[:]; output Real y[ysize]; input Integer ysize; algorithm y := tsmEval(tsmh, u, size(y, 1)); end eval; function evalInv ""Evaluate inverse model at point y with initial guess u0"" extends Modelica.Icons.Function; input Real u0[:]; input Real y[:]; output Real u[size(u0, 1)]; algorithm y := invTsmEval(tsmh, u0, y); end evalInv; annotation( Icon(graphics = {Rectangle(fillColor = {255, 255, 255}, fillPattern = FillPattern.Solid, extent = {{-100, 100}, {100, -100}}), Text(origin = {0, -130}, lineColor = {0, 0, 255}, fillColor = {0, 0, 255}, extent = {{-100, -20}, {100, 20}}, textString = ""%name""), Text(origin = {0, -40}, extent = {{-100, -20}, {100, 20}}, textString = ""Ext Obj""), Text(origin = {0, 40}, extent = {{-100, -20}, {100, 20}}, textString = ""TSModel"")}, coordinateSystem(initialScale = 0.1))); end TSModelC; model Test2 ""Test of the TSModelC class"" SHCControls.TSModel.TSModelC tsm(fileName = ""C:\\Development\\shc-controls\\SHCLib\\Python\\tests\\cannonau2x2.mat"", modelName = ""Cannonau"") annotation( Placement(visible = true, transformation(origin = {0, 0}, extent = {{-20, -20}, {20, 20}}, rotation = 0))); Real u[2] = {0.4, 75e3}; Real y[2]; Real uTilde[2]; equation y = tsm.eval(u, size(y, 1)); uTilde = tsm.evalInv({0.5, 75e3}, y); end Test2; end TSModel; }}} Compilation errors: {{{ C:/Program Files/OpenModelica1.16.0-dev.03-64bit/share/omc/scripts/Compile.bat SHCControls.TSModel.Test2 gcc mingw64 parallel 6 0 PATH = ""C:\PROGRA~1\OPENMO~1.03-\tools\msys\mingw64\bin;C:\PROGRA~1\OPENMO~1.03-\tools\msys\mingw64\bin\..\..\usr\bin;"" mingw32-make: Entering directory 'C:/Users/ASOPPE~1/AppData/Local/Temp/OPENMO~1/OMEdit/SHCCON~2.TES' gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.16.0-dev.03-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=SHCControls_TSModel_Test2 -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o SHCControls.TSModel.Test2.o SHCControls.TSModel.Test2.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.16.0-dev.03-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=SHCControls_TSModel_Test2 -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o SHCControls.TSModel.Test2_functions.o SHCControls.TSModel.Test2_functions.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.16.0-dev.03-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=SHCControls_TSModel_Test2 -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o SHCControls.TSModel.Test2_records.o SHCControls.TSModel.Test2_records.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.16.0-dev.03-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=SHCControls_TSModel_Test2 -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o SHCControls.TSModel.Test2_01exo.o SHCControls.TSModel.Test2_01exo.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.16.0-dev.03-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=SHCControls_TSModel_Test2 -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o SHCControls.TSModel.Test2_02nls.o SHCControls.TSModel.Test2_02nls.c gcc -Os -falign-functions -fno-ipa-pure-const -mstackrealign -msse2 -mfpmath=sse -I""C:/Program Files/OpenModelica1.16.0-dev.03-64bit/include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=SHCControls_TSModel_Test2 -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=0 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0 -c -o SHCControls.TSModel.Test2_03lsy.o SHCControls.TSModel.Test2_03lsy.c SHCControls.TSModel.Test2_functions.c: In function 'omc_SHCControls_TSModel_Test2_tsm_eval': SHCControls.TSModel.Test2_functions.c:99:68: error: '_tsm' undeclared (first use in this function) copy_real_array_data(omc_SHCControls_TSModel_tsmEval(threadData, _tsm._tsmh, _u, tmp1), &_y); ^ SHCControls.TSModel.Test2_functions.c:99:68: note: each undeclared identifier is reported only once for each function it appears in SHCControls.TSModel.Test2_functions.c: In function 'omc_SHCControls_TSModel_Test2_tsm_evalInv': SHCControls.TSModel.Test2_functions.c:122:71: error: '_tsm' undeclared (first use in this function) copy_real_array_data(omc_SHCControls_TSModel_invTsmEval(threadData, _tsm._tsmh, _u0, _y), &_y); ^ : recipe for target 'SHCControls.TSModel.Test2_functions.o' failed mingw32-make: *** [SHCControls.TSModel.Test2_functions.o] Error 1 mingw32-make: *** Waiting for unfinished jobs.... mingw32-make: Leaving directory 'C:/Users/ASOPPE~1/AppData/Local/Temp/OPENMO~1/OMEdit/SHCCON~2.TES' Compilation process failed. Exited with code 2. }}} " Anton.Soppelsa@eurac.edu 6090 model implementation (matlab vs OM) Code Generation Future defect Mahder Alemseged Gebremedhin new 2020-08-19T07:42:51Z 2020-08-21T18:25:38Z "Hello, I implemented an lithium sulfur battery model. First i used matlab ""ode15s"". I got a solution, but i wanted to extend the model. That's why I now try to implement the model in OpenModelica. If implement the model in OpenModelica I get some errors. It's exactly the running version of matlab, but it's not working in OpenModelica. Does anyone no, why I cannot simulate the model in OpenModelica? Thank you " lukas.koenemann@… 6115 Wrong code generation for *and* Code Generation Future defect Mahder Alemseged Gebremedhin new 2020-09-10T08:29:40Z 2020-09-12T21:13:40Z " The condition in the when: {{{#!mo when (index > 0) and (time >= Array[index]) ... end when }}} is translated to: {{{#!c tmp1 = Greater(data->localData[0]->integerVars[1] /* index DISCRETE */,((modelica_integer) 0)); tmp2 = GreaterEq(data->localData[0]->timeValue, (&data->localData[0]->realVars[1] /* Array[1] variable */)[calc_base_index_dims_subs(1, 10, data->localData[0]->integerVars[1] /* index DISCRETE */)]); data->localData[0]->booleanVars[1] /* $whenCondition1 DISCRETE */ = (tmp1 && tmp2); }}} which will generate an error: {{{ assert | error | Dimension 1 has bounds 1..10, got array subscript 0 assert | info | simulation terminated by an assertion at initialization }}} The first condition should be checked before the second one!" Adrian Pop 6120 can not resume simulation after pausing interactive simulation (OPC-UA fails on making run=false) in all new versions OPC v1.16.0-dev Future defect Martin Sjölund new 2020-09-17T07:41:39Z 2020-09-17T10:45:07Z "I have been trying to run OM interactive simulation session. Till OM release v1.12.0 I could pause and resume OPC-UA server by toggling the value of ""run"" variable in OPC server built by OM. But in all later versions, this feature is not functioning well. In all new versions (release/stable/nightly) I can start the simulation by providing run=true but, later with the intention of pausing the simulation if I provide run=false then OPC link disconnects and simulation fails and thus can not be resumed again and have to restart the simulation. " ritesh.sharma@… 6122 FMU/FMI not working neither for local machine nor for cross compilation FMI v1.16.0-dev Future defect Lennart Ochel new 2020-09-17T07:50:46Z 2020-09-29T03:56:42Z "Explaining the scenarios with building and compiling FMI models: CASE 1: OUTPUT If OMSimulator is used with an FMU created on ARM processor specifying platform as ""arm-linux-gnueabihf"": (why do we need this when it is not cross-platform compilation?) OMSimulator works but the output is incorrect when plotted CASE 2: OUTPUT If OMSimulator is used with an FMU created on ARM processor but without specifying platform: (with the assumption that it will create FMU for the native machine) execution fails with the following message >>>error: module FMILIB: Could not change to the DLL directory /tmp/temp_ZaD1mT/binaries/arm-linux-gnueabihf/ error: module FMILIB: The FMU contains no binary for this platform. error: Could not create the DLL loading mechanism (C-API). Error: The FMU contains no binary for this platform. info: Result file: model_res.mat info: Simulation finished. info: Removed model from scope: model CASE 3: OUTPUT If OMShell-terminal is used for importing FMU and then simulating:(irrespective of specifying platform) importFMU() works fine and generates a .mo file but simulation fails with following message >>> simulate(RLC_me_FMU, stopTime=30.0) record SimulationResult resultFile = """", messages = ""Simulation execution failed for model: RLC_me_FMU module = FMILIB, log level = FATAL: Could not change to the DLL directory /home/pi/Desktop/NPCIL/OMS/binaries/linux32/ module = FMILIB, log level = FATAL: The FMU contains no binary for this platform. assert | debug | Loading of FMU dynamic link library failed with status : UNEXPECTED assert | info | simulation terminated by an assertion at initialization Limited backtrace at point of segmentation fault Segmentation fault "" end SimulationResult; CASE 4: Output when Cross-compiling on a different machine for ARM: Same output as CASE 2 and CASE 3 " ritesh.sharma@… 6214 Simulate OpenModelica models on linux Server/Cluster OMPython Future defect arunkumar palanisamy new 2020-11-10T15:29:20Z 2020-11-10T19:47:38Z "Hello, I'm using OpenModelica to simulate/optimize an decentralized energysystem. I'm using python (OMPYthon) to automatically call the simulation multiple times with different parameters. Now I want to run the optimization on a cluster system from my university. On the cluster I dont have sudo right, so i cant install openmodelica on the cluster. Does there exist an workaround to call a simulation from within a cluster system (like a docker-file)?" lukas.koenemann@… 1625 OMEdit: change the View with incorrect code Future discussion Willi Braun new 2011-09-26T23:54:37Z 2016-02-05T09:58:52Z "let the user change the view from textual to diagram also with incorrect modelica. I would like an additional option for the user to let the modelica file like it is and not just fix it or die." Willi Braun 1899 Discusssion on how to make the generated code smaller Backend trunk Future discussion somebody new 2012-10-19T11:13:30Z 2017-11-14T22:08:53Z " This ticket sets up a discussion on how we can make the generated code smaller so that compilation times go down. As pointed out by VTT: http://www.simantics.org/~luukkainen/OM_PerformanceReport.pdf the C files for the simulation are quite large and that requires quite some time to compile. For example [https://trac.openmodelica.org/OpenModelica/browser/trunk/testsuite/simulation/libraries/3rdParty/VTT/FreeBody18.mo FreeBody18.mos] generates ~10MB of C code. and 15MB of .xml file. One way to fix this we should move *ALL* the static data in the Model_init.xml file to make the C file smaller. But this might not be enough as we already moved quite some data to the .xml file. Could we get rid of the defines completely? Any other ideas? Feel free to comment here. " Adrian Pop 2061 combine plots from different result-files Interactive Environment trunk Future discussion somebody new 2013-02-07T19:15:22Z 2017-11-14T22:08:53Z Is it possible to combine different plots from different result-files in one OMPlot-windows? Lennart Ochel 2584 How to handle bad used StateSelect.never attribute? Backend trunk Future discussion probably noone new 2014-02-15T13:14:52Z 2022-03-09T23:32:51Z "Should the following model fail or not? {{{#!mo model Unnamed Real y(fixed=true, stateSelect=StateSelect.never); equation der(y) = time; end Unnamed; }}} This is what the specification says: {{{ type StateSelect = enumeration( never ""Do not use as state at all."", avoid ""Use as state, if it cannot be avoided (but only if variable appears differentiated and no other potential state with Attribute default, prefer, or always can be selected)."", default ""Use as state if appropriate, but only if variable appears differentiated."", prefer ""Prefer it as state over those having the default value (also variables can be selected, which do not appear differentiated). "", always ""Do use it as a state."" ); }}} Currently, the variable y gets selected as state anyway. That is not what I would expect for StateSelect.never." Lennart Ochel 2591 backend debug-dump within OMEdit Interactive Environment trunk Future discussion somebody new 2014-02-18T19:39:42Z 2017-11-14T22:08:53Z "Most of the dumps (in particular backend debug-dump) are not displayed within OMEdit. Therefore a solution is needed. A possible solution is to rewrite all the dumps, so that they get covered by getErrorString(). Are there more suggestions?" Lennart Ochel 2884 Performance tracing for compiler and simulation stages *unknown* trunk Future discussion somebody new 2014-10-13T13:59:39Z 2014-10-14T05:38:47Z "I think it is necessary to trace the performance of both, the OpenModelica compiler, as well as the generated simulations. Therefore a new Hudson job could be added that runs a (small) set of models for each revision and measures the elapsed time for the different compiler and simulation stages: * Compiler: Front end, back end (in total and for each optimization module), SimCode, … * Simulation: Non-linear solvers, linear solvers, event iteration, … Therefore, it is probably necessary to run this on an independent machine. Of course it would be also interesting to test different OS and hardware configurations… But that would be too much. I think for the beginning it is good enough to have at least one setup for the measurements. The set of models should contain a couple of the biggest models from some libraries, as well as a couple of scalable models (that are probably some kind of artificial) to see if everything scales as expected and to detect bottlenecks and bad commits. The results of such a performance tracing should be provided as a text summary and as intuitive graphs. With these results it would be possible to detect and fix much more efficiently a lot of performance issues. Also it would help to provide always an efficient OpenModelica build." Lennart Ochel 2941 Replace all Package.RECORD with Package.UnionType.RECORD? *unknown* trunk Future discussion somebody new 2014-10-30T01:33:59Z 2014-10-30T06:21:47Z "Should we replace all the uniontype records paths to include the uniontype? Then the MDT lookup will start working on those and we would not need the extra imports (or how is done currently). Any comments on this? " Adrian Pop 2973 relations vs. zero crossings Backend trunk Future discussion somebody new 2014-11-10T08:26:31Z 2017-02-09T16:13:24Z "I investigated a bit how zero crossings get collected. I think there are a couple of problems. First of all, zero crossings and relations still seem to be swapped. The following simple example shows that: {{{#!mo model test8 Boolean b = sin(time) < 0.0 and cos(time) > 0.1; annotation(experiment(StartTime = 0, StopTime = 10)); end test8; }}} {{{ Zero Crossings (1) ======================================== sin(time) < 0.0 and cos(time) > 0.1 in equations [1] and when conditions [] Relations (2) ======================================== sin(time) < 0.0 with index = 0 in equations [1] and when conditions [] cos(time) > 0.1 with index = 1 in equations [1] and when conditions [] }}} A zero crossing is a continuous function whose '''zero crossing''' is of interest. Whereas relations are logical expressions that may depend on zero crossings. Because the runtime systems depend on this data structures, this should get fixed before one does further improvements of the event systems. " Lennart Ochel 3044 warn if one tries to override secondary parameters Run-time trunk Future discussion somebody new 2014-12-18T19:55:27Z 2014-12-18T19:55:27Z "I think the simulation should display a warning at least if one tries to override secondary parameters. Please, checkout the following example: {{{#!mo loadString("" model Test Real y; parameter Real p = 1; parameter Real q = p; equation y = q + time; end Test; ""); getErrorString(); simulate(Test, simflags=""-lv=LOG_SOTI""); getErrorString(); val(q, 0.0); getErrorString(); val(y, 0.0); getErrorString(); simulate(Test, simflags=""-lv=LOG_SOTI -override=q=2""); getErrorString(); val(q, 0.0); getErrorString(); val(y, 0.0); getErrorString(); }}} {{{q}}} will be {{{1}}} (actually {{{p}}}) for both cases. Any comments?" Lennart Ochel 4272 Simulation Process Failed Run-time v1.9.4-v1.9.x Future discussion Lennart Ochel accepted 2017-02-14T20:45:36Z 2017-02-14T21:11:59Z "Hello, When simulating a model that passed the ""Check Model"" I received a ""Simulation Process Failed. Exited with code 255."" error. The model consists of a couple of continuous blocks (pulse train & filter) and then a sampler and digital filter using the Modelica_Synchronous library. So, I'm wondering if anyone has any idea what might have caused this? " rbackhus@… 4384 Memory management of pre values Run-time Future discussion Lennart Ochel new 2017-04-07T08:18:46Z 2017-04-19T16:37:03Z "In the c runtime, do we really need a separate copy of pre values or could we just use the ring buffer for this instead? That would reduce the amount of redundant data and avoid coping pre values after each simulation step. Any comments?" Lennart Ochel 4721 Complex variables do not show documentation string in Variables Browser OMEdit Future discussion Adeel Asghar new 2018-01-24T15:04:28Z 2018-01-30T16:10:15Z "Consider the following example: {{{ model Test Modelica.SIunits.ComplexCurrent I = Complex(1,2) ""Complex current""; end Test; }}} After simulating this model, the documentation string of the current is NOT shown in the Description column of the Variables Browser (see attachment). Two more comments on this: 1. I tried the same thing in Dymola and the documentation string {{{""Complex current""}}} is not shown either. I am thus not sure whether this an implementation issue of OpenModelica (and Dymola) or a language issue, that the documentation string is not shown. 2. The real and imaginary parts are also missing the documentation string, but this is a design issue of the MSL, see https://github.com/modelica/Modelica/issues/2443 Comments are highly appreciated." Christian Kral 5154 Strange license of FMI run-time FMI Future discussion Lennart Ochel new 2018-10-06T07:45:55Z 2018-10-06T07:45:55Z "In the license header of FMI run-time (see here [https://github.com/OpenModelica/OMCompiler/blob/master/SimulationRuntime/c/fmi/FMI1Common.c] for example) there is quite strange text. Is it by design or just copy-pasted from the main license headers? {{{ * THIS PROGRAM IS PROVIDED UNDER THE TERMS OF THE BSD NEW LICENSE OR THE * GPL VERSION 3 LICENSE OR THE OSMC PUBLIC LICENSE (OSMC-PL) VERSION 1.2. * ANY USE, REPRODUCTION OR DISTRIBUTION OF THIS PROGRAM CONSTITUTES * RECIPIENT'S ACCEPTANCE OF THE OSMC PUBLIC LICENSE OR THE GPL VERSION 3, * ACCORDING TO RECIPIENTS CHOICE. }}} Note that the first 2 lines mention 3 license options, while the next 3 lines mention only two of them." anatoly.trosinenko@… 5195 Division by zero during the initialization via file (.mat), of the system of equations. Initialization v1.13.0-dev-nightly Future discussion Lennart Ochel assigned 2018-10-29T10:44:24Z 2019-04-01T11:35:37Z "Hello, i'm Andrea Baratta and i'm a university student, involved in the use of OMEdit. Getting directly to the point, i'm writing to you to report what i'm experiencing during the initialization via file (.mat), of the system of equation, describing the behaviour of a given fluid model. In particular, the target is to initialize a given model, with the Results file (.mat), of the same model calibrated on diffrent parameters' values. To let the solver access the variables inside the file, i empirically found that the Results file must be created setting also the option ""Protected Variable"" in ""Simulation SetUp --> Output"". What's strange, is that in this case, when i try to load the initialization file in ""Simulation SetUp --> Simulation Flag"" the process fails, due to a division by zero ($cse6 - implicated variable). Since the same procedure, performed on Dymola software, works perfectly, my question is: is somehow a OMEdit bug, or i'm making stupid mistakes in the initialization procedures? I'm so sorry for the trivial question (maybe), but being a beginner with OMEdit, i'm still not so confident. Attached you can find PROVA_INIT_FILE_2, that is the model that i would like to initialize exploiting the results file of PROVA_INIT_FILE_1. Many thanks in advance and thank you for your job. Andrea" andrea.baratta.fontanellato@… 5267 Additional variables added in FMUs exported from OM FMI Future discussion Lennart Ochel new 2019-01-09T09:29:28Z 2019-01-09T11:15:49Z "Hello, I remark some additional variables are automatically added by the tool when FMUs are exported from OMEdit. For example in the enclosed model the FMU exposes a ""new"" variable named _D_outputStateAlias_myOutput which is very similar to the ""normal"" variable myOutput. What is the purpose of these added variables? Can they be removed in the future if not useful? Best" J-Ph Tavella 5363 Is it currently possible to create/model systems off of the ThermoPower Library in OpenModelica? Build Environment Future discussion Adrian Pop assigned 2019-02-27T16:30:57Z 2019-03-01T16:41:19Z "For a month now I've been trying to model Power Cycles, specifically the Brayton and Rankine Power Cycles, in an attempt to then model a Combined Power Cycle. The Brayton Cycle example on the ThermoPower Library does in fact run and simulate. This has enabled me to correctly model my own model which also runs and simulates. But when it comes to the Rankine Power Cycle, the Library model always fails to run/simulate. I have also built MANY iterations of my own Rankine Power Cycle despite the Library model from working. All of my models also fail to run/simulate. I have tried complex models and also very very simple models. All of my iterations fail. Also something worthy of noting, a lot of errors and translation errors occur with variables pertaining to pump.mo which are seemingly impossible to troubleshoot. Working off of the ThermoPower Library since January has been a challenge. It seems most library examples/components have bugs in them preventing most examples from simulating. I've also been in contact with a builder of the ThermoPower library who has been telling me that the library is currently undergoing rebuilds. So after experiencing/learning all of these factors, is it in fact possible to model systems off of the ThermoPower Library, or is it just my inability to model a system correctly?" KieranF 5374 How do I solve Modelica errors of variables, where the variables are parameters of extensions that your model is using? *unknown* v1.13.0 Future discussion somebody new 2019-03-04T22:35:50Z 2019-03-04T22:35:50Z "I've been trying to build a Rankine Power Cycle on OpenModelica for quite some time now and have been running into a reoccurring issue that I'm just not sure how to troubleshoot. My Issue: I'm able to get the majority of all of my Rankine Power Cycle model iterations to at least get a checked model as well as a successful instantiation. At this point I deem my model ready to try and simulate. The types of errors that usually break my simulation are variables that are located within extended models that my model is using. For example: Currently I am checking and verifying sub assemblies of the Rankine Power Cycle to be able to properly verify which components work and which do not under x,y,z circumstances. My heat exchanger model is checked and is able to instantiate but upon simulation I get error codes that read: {{{ [22] 14:34:06 Symbolic Error [ThermoPower.Gas: 1053:5-1053:66]: Model is structurally singular, error found sorting equations 125: 0.0 = 0.0; for variables HX.gasFlow.vbar[5](140), HX.gasFlow.drbdX1[2,4](125) }}} What the issue here for me is that the error above, or all errors of these types, are hyperlinked to either partial models or packages that my own model extends. So the variables above ""vbar"" or ""drbdX1"" are no where within my HeatExchanger Model that I built, but the components inside of my own model somehow extend to these variables that are inevitably causing the error. Things I've tried: I've tried adding values to the extended hyperlinked models/packages in order to fix the error. This does not do anything. I've tried copy and pasting said lines of code into my own model in order to declare whatever package/function that has already been declared within the extension. This does not work as usually produces an error for incorrect declaration. The hyperlinked error does little to not help on how exactly I should fix the model, or where or which model I should fix it on. If you have any insight or recommendations on how to fix such an issue, please feel free to comment below! Thank you for your time and reading this far into my plea for help :) I've attached the model I'm working on just in case. " KieranF 5494 RemoveSimpleEquations module should remove simple equations with parametric coefficients Backend Future discussion Lennart Ochel new 2019-05-19T15:12:13Z 2019-05-21T13:10:21Z "RemoveSimpleEquations module cannot remove equations like '''a = k * b''' where '''a''' and '''b''' are some component references and '''k''' is a parameter expression. Because of that in the example below compiler cannot deduce that the value of z is zero. {{{ #!modelica model TestFactorSimpleRemoval Real x = time; Real y = 2 * time; Real z; equation z = 2 * x - y; end TestFactorSimpleRemoval; }}} Currently this model produce following equation system {{{ #!modelica ######################################## dumpindxdae ######################################## unspecified partition ======================================== Variables (3) ======================================== 1: z:VARIABLE() TestFactorSimpleRemoval type: Real 2: y:VARIABLE() TestFactorSimpleRemoval type: Real 3: x:VARIABLE() TestFactorSimpleRemoval type: Real Equations (3, 3) ======================================== 1/1 (1): z = 2.0 * x - y [dynamic |0|0|0|0|] 2/2 (1): x = time [binding |0|0|0|0|] 3/3 (1): y = 2.0 * time [binding |0|0|0|0|] Matching ======================================== 3 variables and equations var 1 is solved in eqn 1 var 2 is solved in eqn 3 var 3 is solved in eqn 2 StrongComponents ======================================== {3:2} {2:3} {1:1} BackendDAEType: simulation }}} Module RemoveSimpleEquations already handles negative sign and work with parametric coefficients could be done in the same manner." Maksimov Doe 5624 if else ODE and Algebraic Equation Backend v1.13.2 Future discussion Lennart Ochel new 2019-09-02T13:13:09Z 2019-09-13T11:16:33Z "Hello, everyone! I am facing a problem with a model I`m developing in OpenModelica and I created I simpler example to show the issue: model teste Real x; equation if time<1000 then der(x) = 10; else x = -5; end if; end teste; So what happens is that when ""time = 1000"" the simulation stops, I imagine it`s a discontinuity issue. Does anybody know how to solve this problem? Thank you!" Matheus Campanini Mughrabi 5713 Compile openmodelica with icc and icpc *unknown* v1.13.2 Future discussion Adrian Pop assigned 2019-11-25T13:01:59Z 2019-11-25T18:37:16Z "I would like to compile openmodelica with intel suite compilers icc and icpc but when I run ./configure CC=path/to/icc CXX=path/to/icpc I get the following warning message : {{{ configure: WARNING: lpsolve/lp_lib.h: present but cannot be compiled configure: WARNING: lpsolve/lp_lib.h: check for missing prerequisite headers configure: WARNING: lpsolve/lp_lib.h: see the Autoconf documentation configure: WARNING: lpsolve/lp_lib.h: section ""Present but cannot be compiled"" configure: WARNING: lpsolve/lp_lib.h: proceeding with the compiler results checking for lpsolve/lp_lib.h... no failed to find lpsolve55 hearders or library; will compiler them ourselves }}} I don't know if it's much of a big deal as the configuration carries on. But later on when I launch the compilation it aborts and returns : {{{ /usr/include/c++/7/bits/move.h(48): error: identifier ""__builtin_adressof"" is undefinded }}} I am using Ubuntu 18.04, my icc version is 15.0.4 and my gcc version is 7.4.0. Is there a way to compile OpenModelica with intel compiler ? " paul.mordant@… 5934 auxiliary state in der-call Backend Future discussion Lennart Ochel new 2020-05-03T16:16:52Z 2020-05-06T07:23:27Z "Currently arguments of the der-call like in {{{der(sin(x)*y) = 1}}} are differentiated symbolically until single variables are reached, yielding something like {{{ cos(x)*der(x)*y + sin(x)*der(y) = 1 }}} In cases like {{{der(y^x)}}} this may even result in pretty ugly residual equations. Instead we could introduce an auxiliary variable {{{$aux = sin(x)*y}}}, s.t. {{{der($aux) = 1}}}. I believe Karim has some convincing arguments towards this approach. I'll try to recap them from what I understand: a. If {{{x}}} and {{{y}}} appear only algebraically elsewhere, introducing an auxiliary results in fewer states, thus a lower index. b. Otherwise ({{{der(x)}}} and {{{der(y)}}} exist elsewhere) the system may need index reduction anyways, because the states {{{x}}} and {{{y}}} are connected somehow. The alias might allow index reduction to pick a better choice. I personally think differentiating the interior of {{{der(...)}}} is a cool feature. But there may be practical reasons against it. I have no idea how academic this issue is. Opinions?" Philip Hannebohm 5947 Backend cannot solve for variable indexed array elements Backend Future discussion Karim Adbdelhak new 2020-05-10T17:59:49Z 2020-05-11T16:16:46Z "Indexing an array with non constant expressions is allowed due to modelica specification. Our current backend is only able to have these variable indices as part of the right hand side and can never solve for these variables. This is a basic matching problem and can not be done, since we cannot evaluate during compilation what values the index can take. This is a problem that was identified in ticket #4120 Consider the following model: {{{ model testArr Boolean x(start = false); Integer y[2]; Real z[2]; equation when sample(0.0, 0.1) then x = not pre(x); end when; y[1] = if x then 1 else 2; y[2] = if x then 2 else 1; z[y[1]] = sin(time); z[y[2]] = cos(time); end testArr; }}} The indexing of `z` is not constant and therefore our current backend cannot solve for these variables (in this example it could be done, but there can be an example where it depends on a state). Equation 4 and 5 have to be solved for either z[1] or z[2] and if correctly processed it would work, but it fails. Dymola is able to solve this and i suppose they re-formulate them to be residuals. There is a way i could implement this in the backend (i need to adapt the adjacency matrix) but that would also allow a lot of stuff that is not valid to pass. We would only be able to recognize that during runtime and that could be a headache. Q: Is this relevant for real models? Q: Should we only care for special cases? Q: Should we care for invalid models failing with bad or unrelated error messages?" Karim Adbdelhak 1709 BigInt package Frontend Future enhancement Martin Sjölund new 2012-03-05T12:00:40Z 2012-08-30T10:24:16Z "MSL contains constants >31-bit, and we could support them using either an arbitrary-size data-structure or simply 128-bit or something. This would reduce the need for some ad-hoc Integer to Real conversions that we perform today: {{{ model M Integer i = 100000000000 * 100000000000; end M; }}} Gives after type-checking: {{{ class M Integer i = 1e+22; end M; }}}" Martin Sjölund 2174 Allow for modifiers in translateModel() and simulate() API functions Frontend trunk Future enhancement Adrian Pop assigned 2013-05-06T14:53:37Z 2020-06-16T10:15:45Z "It is often the case that one wants to run batches of simulations where some parameters are changed, in order to explore the configuration space. For this purpose, it would be nice if one could write modifiers directly in the simulate() and translateModel() functions, e.g.: simulate(MySystem(component2(T = 10))) This feature is provided by Dymola and it is indeed very useful in such cases." Francesco Casella 2335 Look into pattern-matching efficiency Code Generation trunk Future enhancement Martin Sjölund new 2013-09-01T13:10:15Z 2017-11-14T22:08:53Z "Currently, matchcontinue generates code like: {{{#!c CevalScript_createSimulationResultFailure_rettype tmp161; if (8 != MMC_STRLEN(tmpMeta[3+2]) || strcmp(""simulate"", MMC_STRINGDATA(tmpMeta[3+2])) != 0) MMC_THROW(); if (listEmpty(tmpMeta[3+3])) MMC_THROW(); tmpMeta[503] = MMC_CAR(tmpMeta[3+3]); tmpMeta[504] = MMC_CDR(tmpMeta[3+3]); if (mmc__uniontype__metarecord__typedef__equal(tmpMeta[503],12,1) == 0) MMC_THROW(); }}} It should be possible to make this call `continue` instead of MMC_THROW()" Martin Sjölund 2394 include the diagram view in OMNotebook OMNotebook trunk Future enhancement Adeel Asghar new 2013-10-04T10:21:05Z 2017-11-14T22:08:53Z I would like to include the diagram view of a model in OMNotebook. That would be very helpful to prepare and maintain sheets. I guess currently this is only possible using self-generated images. But that is not a good way to keep a notebook consistent. Lennart Ochel 2421 OMEdit gdb debugging - desired features OMEdit trunk Future enhancement Adeel Asghar new 2013-10-13T13:25:52Z 2017-10-12T18:26:34Z " I would really like to extend the GDB debugger features in OMEdit compared to MDT. I've been playing a lot with the MDT debugging and while is quite good, it can be way better which would support way more effective debugging. Per and Martin, add more to this list if you want. Adeel, I can make it a ticket out of this if you want -> done :) 1. have a user console to send written commands to gdb (for advanced users like Martin and me). You can use {{{-interpreter-exec console ""command""}}} http://www.sourceware.org/gdb/onlinedocs/gdb.html#g_t_002dinterpreter_002dexec 2. have an user option in OMEdit debugging settings to not remove frames that are for .c/.cpp files. Note that some of these files are quite large (100Mb+) and should not be fully opened in OMEdit just display 100 lines above and below the breakpoint line. 3. when your program cycles and you suspend it sometimes it switches threads so you get a different stack that you want. have a way to switch the threads or display all threads instead of just the one executing .mo code. 4. have a way to search the (tree-like) local variables for strings, record names, record component names if possible with regular expressions. 5. have a way to break only if a local variable contains certain record name or string. sometimes a function is executed a lot of times but you're only interested if the input/local variable path (Absyn.Path) contains certain string. currently you have to suffer through stopping *a lot* of times until you reach the point you're interested in. 6. have a toggle button that enables timings for step in, step over run commands. if you send command: {{{-enable-timings [yes | no]}}} then when you do step over or run gdb measures time until the next break event and report it then in this way: {{{time={wallclock=""0.05185"",user=""0.00800"",system=""0.00000""}}}}. the execution time until the next breakpoint is hit can then be displayed somewhere. " Adrian Pop 2473 FMU Export Option 32bit/64bit version Backend trunk Future enhancement probably noone new 2013-11-11T15:18:10Z 2018-08-09T13:03:33Z "Currently we just generate a FMU with that bit version that compiler is mode of. But we should allow uses to choose. " Willi Braun 2492 Add dumpDAEXML option to OMEdit 'XML' menu Backend trunk Future enhancement probably noone new 2013-11-28T15:51:03Z 2017-11-14T22:08:53Z Please add an option to export a DAE dump to an XML file in the OMEdit 'XML' menu. James Carow 2549 Add gnuplot support to save plots in more formats Interactive Environment trunk Future enhancement somebody new 2014-01-28T08:32:47Z 2017-11-14T22:08:53Z "Add gnuplot support to save plots in more formats. Something like: {{{#!mo function gnuplot input VariableNames vars; input String inputFile := """" ""last generated simulation results""; input String outputFile := ""output.csv""; input String inputSeparator := "",""; input String term := ""pdf""; // The usual plot arguments as well... output Boolean; end gnuplot; }}} Limitations: gnuplot only supports .csv; not .mat or .plt. More recent versions have better support for headers in the csv-file, but not good enough to conform to the full csv format. You need to know the index of each variable for it to work. Rationale: We use gnuplot to produce nice-looking plots for papers anyway. Why not integrate it into omc even if it requires output in csv format? Gnuplot supports many output formats too (svg, pdf, eps, wmf)." Martin Sjölund 2647 Expression.simplify is way too slow Backend trunk Future enhancement probably noone new 2014-04-02T10:12:09Z 2017-11-14T22:08:53Z "For the following models the compile time increases heavy, if one increase the size. {{{ model BaseModelEquations parameter Integer n=100; // see Backend time for 100, 200, 400 input Real[n] u1; input Real[n] u2; output Real[n] y1; output Real y2; equation y1=array(if u1[i] > 0 then u1[i] else u2[i] for i in 1:n); y2=sum(y1); end BaseModelEquations; }}} {{{ For n=100 : timeBackend = 0.266189871 For n=200 : timeBackend = 1.490894306 For n=400 : timeBackend = 10.56719995 For n=800 : timeBackend = 82.89054140 }}} All the time is lost by trying to simplify expressions. Also we try to do it 3 time, once by creating the BackendDAE structure, once directly after that and once at the end of the Backend process. We should do it only once and perhaps we should improve Expression.simplify further anyway." Willi Braun 2653 val does not work for csv files Interactive Environment trunk Future enhancement Martin Sjölund new 2014-04-07T09:52:33Z 2017-11-14T22:08:53Z "{{{ loadString("" model a Real b = time; end a; ""); getErrorString(); simulate(a, outputFormat=""csv""); val(b, 0); simulate(a, outputFormat=""mat""); val(b, 0); }}} result {{{ true """" record SimulationResult resultFile = ""a_res.csv"", simulationOptions = ""startTime = 0.0, stopTime = 1.0, numberOfIntervals = 500, tolerance = 1e-06, method = 'dassl', fileNamePrefix = 'a', options = '', outputFormat = 'csv', variableFilter = '.*', measureTime = false, cflags = '', simflags = ''"", messages = """", end SimulationResult; NaN record SimulationResult resultFile = ""a_res.mat"", simulationOptions = ""startTime = 0.0, stopTime = 1.0, numberOfIntervals = 500, tolerance = 1e-06, method = 'dassl', fileNamePrefix = 'a', options = '', outputFormat = 'mat', variableFilter = '.*', measureTime = false, cflags = '', simflags = ''"", messages = """", end SimulationResult; 0.0 }}}" Lennart Ochel 2874 Implement threaded for-loops in MetaModelica MetaModelica trunk Future enhancement Martin Sjölund new 2014-10-07T14:58:48Z 2016-02-05T09:58:52Z "We currently have threaded reductions, it would be nice to have the equivalent for-loops also (syntax is only a suggestion): {{{#!mo for threaded e1 in list1, e2 in list2 loop // Iterates simultaneously over list1 and list2. end for; }}}" Per Östlund 2876 Write parameters in the csv file (or maybe in another file with only parameters) Run-time trunk Future enhancement somebody new 2014-10-07T22:36:00Z 2014-10-08T06:08:52Z "Currently is not possible to write parameters to anything but the .mat files. People want to have the parameters also in .cvs format. http://stackoverflow.com/questions/26244098/constants-in-csv-format/ If we add them then that particular column in the .csv will be the same value over and over. Maybe is a good idea to add them in another file _parameters.csv and only once." Adrian Pop 2880 allow save plot to file from script *unknown* trunk Future enhancement somebody new 2014-10-09T11:33:01Z 2017-11-14T22:08:53Z "Dear Colleagues, I tried to find out any command or option which can allow me to save plot with simulation results into a file. I know that it is possible to save png file from omplot but seems that there is no way to do it from omc script. Could you please enhance omc or omplot to allow it? For example option may be smth like (i am ok with any): plot(x, savetofile = fname, format=""png"") I appologyze if there is a way to save such a plot and i just missed it in doc. If yes could you please give me a hint how i can do it? thanks Alexander " Alexander 2897 continue statement for for- and while-statements MetaModelica trunk Future enhancement Martin Sjölund reopened 2014-10-16T10:33:24Z 2020-12-02T15:00:25Z Modelica/MetaModelica is currently lacking a continue statement for breaking out of the current iteration of a for- or while-loop, which can be somewhat annoying. Considering that C (and pretty much any language with for-loops) already has this builtin it should be fairly trivial to implement. I suggested adding it to Modelica [https://trac.modelica.org/Modelica/ticket/1587#ticket here], but we could implement it in MetaModelica without waiting for that. Per Östlund 2972 OMEdit-omc integration for performance OMEdit trunk Future enhancement Adeel Asghar new 2014-11-09T10:59:16Z 2014-11-16T09:35:45Z "OMEdit has a considerable overhead calling the omc API. With the bootstrapped compiler, we could use omc as a library rather than as a server. This bring some performance gains. We could gain even better performance by doing some Qt batch operations directly. Consider a package like: {{{#!mo package OMEditStuff package QVariantMap class QVariantMap extends ExternalObject; end QVariantMap; function addString input String key; input String value; end addString; function addMap ... end addMap; end QVariantMap; function getAllClassInformation input QVariantMap map; // Pointer from the OMEdit Qt program ... output QVariantMap outMap; ... algorithm Absyn.traverseClass(program, addClassInformationToMap, map); end getAllClassInformation; function addClassInformationToMap input Absyn.Path fullPath; input Absyn.Class cl; input QVariantMap map; algorithm QVariantMap.addString(fullPath, getClassInformationStr(cl)); end addClassInformationToMap; end OMEditStuff; }}} OMEditStuff (or a set of packages) could be compiled as a separate object. Nothing in OpenModelica uses them, so OMEdit could simply link in both libOpenModelicaCompiler.so and libOpenModelicaCompilerOMEditStuff.so, calling functions in OMEditStuff, which in turn calls other functions directly. This way we could insert things directly into the data structures that OMEdit uses. I am certain it would be a lot faster than the current approach." Martin Sjölund 3117 Evaluate functions of parameters/constants only once (required by data-based interpolation functions) Backend trunk Future enhancement somebody new 2015-01-29T22:43:28Z 2017-11-10T11:42:15Z "Consider {{{ThermoPower.Test.GasComponents.TestFanMech}}}. The simulation in OMC takes 22 seconds, in Dymola 0.002 seconds, with a ratio of 10.000 (!!). The fan model uses the following function: {{{ function flowChar = Functions.FanCharacteristics.quadraticFlowBlades ( bladePos_nom={0.30,0.35,0.40,0.45,0.50,0.55,0.60,0.65,0.70,0.75,0.80, 0.85}, q_nom=[0, 0, 100, 300, 470, 620, 760, 900, 1000, 1100, 1300, 1500; 70, 125, 310, 470, 640, 820, 1000, 1200, 1400, 1570, 1700, 1900; 100, 200, 370, 530, 700, 900, 1100, 1300, 1500, 1750, 2000, 2300], H_nom=[3100, 3800, 3700, 3850, 4200, 4350, 4700, 4900, 5300, 5600, 5850, 6200; 2000, 3000, 3000, 3000, 3000, 3200, 3200, 3300, 3600, 4200, 5000, 5500; 1000, 2000, 2000, 2000, 2000, 1750, 1750, 2000, 2350, 2500, 2850, 3200]); }}} to represent its characteristic curve. The {{{quadraticFlowBlades}}} function has the following body: {{{ function quadraticFlowBlades ""Quadratic flow characteristic, movable blades"" extends baseFlow; input Real bladePos_nom[:]; input SI.VolumeFlowRate q_nom[3, :] ""Volume flow rate for three operating points at N_pos blade positionings""; input SI.Height H_nom[3, :] ""Specific work for three operating points at N_pos blade positionings""; input Real slope_s( unit=""(J/kg)/(m3/s)"", max=0) = 0 ""Slope of flow characteristic at stalling conditions (must be negative)""; algorithm H := Utilities.quadraticFlowBlades( q_flow, bladePos, bladePos_nom, Utilities.quadraticFlowBladesCoeff( bladePos_nom, q_nom, H_nom), slope_s); end quadraticFlowBlades; }}} The last input to {{{Utilities.quadraticFlowBlades}}} is a function that computes the interpolation coefficients based on the nominal data, which requires nontrivial computations. In our case, these nominal data turn out to be constants, so this function should be only called once at initialization, then subsituted by its constant output. If not, the entire set of interpolation coefficients is recomputed each time the interpolation function is called, which is horribly inefficient. This mechanism is actually required to satisfactorily handle all kinds of data-based interpolation functions." Francesco Casella 3139 equations do not switch based on param value in if statement Frontend trunk Future enhancement Adrian Pop assigned 2015-02-06T20:15:55Z 2017-11-14T22:08:53Z "Hello, i have a simple model as follows: {{{ model test parameter Real b=0; Real y; equation if b == 0 then y = 1000; else y = b; end if; end test; }}} before simulation, first i instantiate the mode and i see that in the flattened model, only the equation regarding to b==0 is considered. i assume that the code generator also considers only this equation because after compilation and running the simulation, changing the value of b in plot window, does not affect the results. I tried to remove the default value of b and i saw that this time the complete if statements appears in the flattened code after instantiation and therefore compiled after pushing simulation button. I think the code generator should compile the if statements completely, no matter if the parameter in the if statement has a default value of not, because when you have a model which its dynamics changes regarding to the value of the parameters, and you want to generate an FMU from that, the FMU should also consists all equations for different values of the parameter. Thanks, Arvin " arvin84@… 3227 Make possible to change the csv file delimiter char and quote char (for input file and output file) Run-time trunk Future enhancement Adrian Pop accepted 2015-03-16T13:38:11Z 2017-11-14T22:08:53Z "Currently there seems to be 4 separate implementations for the csv files: 1. input file externalInput.csv uses space as a delimiter 2. input file for optimization uses space as a delimiter 3. writing output results to the csv file is done using delimiter "","" 4. reading results from the results file uses comma as delimiter (libcsv.c) All these 4 different implementations should be based on libcsv.c which is the most configurable and one should be able to set the csv delimiter char and the quote char from command line. " Adeel Asghar 3304 Allow assumptions for unassigned parameters argument when checking partial models. Frontend trunk Future enhancement somebody new 2015-05-01T23:20:49Z 2015-05-04T08:58:49Z When building and debugging models it's quite handy to also be able to check partial models that have parameters without any binding equation. Dymola normally assigns either 0 or the `min` value if present. This is quite handy it would be nice to have. Dietmar Winkler 3356 Improve Susan buffers Code Generation trunk Future enhancement Martin Sjölund accepted 2015-06-16T05:27:38Z 2016-04-14T08:04:50Z "Susan has performance issues with large strings sometimes. I think adding a new language element and changing a few buffers could be a possible solution: {{{ let &buf = buffer """" to let &buffer = fileBuffer ""someFile"" """" }}}" Martin Sjölund 3435 Provide encryption/decryption for user libraries Interactive Environment trunk Future enhancement somebody new 2015-09-01T16:37:37Z 2017-10-09T09:05:23Z "This is a ticket for discussion and implementation of encryption/decryption for OpenModelica. See below some of the discussion from the OSMC board. RF: The encryption of user models is a functionality is of increasing interest. LM: Our goal is to mix encrypted libraries with MSL in usage. PF: Leo G expressed interest in encryption of their commercial libraries, to ship together with OpenModelica. AP, PF: AP will open an enhancement ticket for encryption (done, this one). Even better to bring this up within the Modelica Association so that it can be done in a more standardized way. See: https://trac.modelica.org/Modelica/ticket/1282 PF: We can also have obfuscation to hide it even more. RF: Even a simple annotation not to show the equation view would be valuable. Proposal: Investigate encryption as a future enhancement. " Adrian Pop 3523 Add valFirst and valLast to retrieve the first and last value of a variable at given time Interactive Environment Future enhancement Adrian Pop accepted 2015-10-21T21:57:14Z 2015-10-22T12:39:42Z "When we have events we have several values in the result file. We need an API like val but which returns the first value or the last value. " Adrian Pop 3578 Build OMC from branches in Hudson Build Environment Future enhancement sjolund.se new 2015-12-02T14:49:39Z 2015-12-02T17:22:35Z "During the last OSMC board meeting, it was decided to make it possible for people to build OMC on Hudson from specific development branches, in order to make early testing of new features possible for end users. Ideally, this should be possible for Linux, Windows, and Mac to enlarge as much as possible the user base. From what I understand, it is just necessary to copy the existing Hudson jobs that make the nightly builds, add an input for the branch, and use it instead of master. Piece of cake?" Francesco Casella 3652 Unable to modify parameters inside components. OMEdit Future enhancement Adeel Asghar accepted 2016-01-28T10:11:13Z 2016-01-28T13:45:03Z As of `1.9.4~dev-695-g5815c70` OMEdit is not capable of changing parameters further down the hierarchy of a model. It only allows you to use ''view class'' in order to open a class in its original location. Which means changing a parameter there will change it in the original location (if it is not write protected). But you can not add any modifiers to any of the components of the sub-layer. This is quite cumbersome. Dietmar Winkler 3660 Linearisation menu OMEdit Future enhancement Adeel Asghar new 2016-02-02T12:53:53Z 2016-02-02T12:53:53Z It would be nice to have option of linearising the selected system directly from the menu in OMEdit instead of using OMShell. In the attachment you can find the screenshots of how this could be done in Dymola and the Modelica script that I used with OMShell. trabuzin@… 3678 Efficient flattening (and code generation) for large-scale network models *unknown* Future enhancement Per Östlund new 2016-02-10T23:09:22Z 2018-09-18T12:43:15Z "I have tried to summarize in a representative model the features of large-scale power system models that are currently stressing the compiler performance in terms of code generation time. Please have a look at the attached test package. The basic model {{{ResistorSource}}} is a resistor with a voltage controlled-source in series, whose voltage is determined by a sub-model of type {{{FirstOrder}}}, containing a first order linear system. The forcing signal of the first order system is by default bound to zero, but it can be changed with a binding equations when instantiating the ResistorSource model. Many basic models are instantiated and connected together; some have a modifier on the binding equation, some don't. {{{SystemSmall}}} shows a simple example, while {{{GenerateSystemLarge}}} automatically generates the Modelica source code for systems of arbitrary size. With the default parameters, the large system has 40000 equations, and the front-end takes 43 seconds to flatten it on my pc. If you want to go up to the scale we need, you can multiply the size by a factor 10-20, though, to use Per's words, life's too short to study that case with the current compiler :) We need to show that there are strategies that can be implemented in OMC in order to shorten this processing time drastically. Regarding the front-end, I understand from Adrian that it would be possible to use some caching strategy, to avoid re-doing all the lookup times and again for each instance. Basically, the first time the compiler encounters this declaration {{{ TestCaching.ResistorSource rs_1(R = 1, u = sin(time)); }}} it will do all the lookup and flattening for the ResistorSource class with a time-varying binding equation on u, and a constant binding equation on R. This structure could be labelled as a specific type. Then, the next time the compiler encounters another declaration with exactly the same type (except for numerical values of parameters!), it could avoid re-doing the flattening and instantiation again, and just use the cached results. Would it be possible to come up with a prototype in the front-end that can use this strategy to process the {{{SystemLarge}}} model? It would then be very interesting to compare its performance with the currently available one, and understand if this kind of strategy pays off. A second further stage could involve the back-end. Assuming we use a native DAE solver (IDA/Kinsol), then we could somehow avoid to actually flatten all the individual instances in the front end, and instead pass to the back-end the collected types and just pointers to the various instances. Code to compute the DAE residuals could be generated only once for each type, and then just be called many times, one for each instance. This could save a tremendous amount of time and space which is currently spent generating the same code N times, and then compiling it to executable form. Note that if we use a DAE integrator and a-priori knowledge about the system, we could skip most of the current back-end stages: matching and sorting, index reduction, etc. I understand this second step is a lot more far-fetched, but would it be possible to come up with a prototype that could run on this demo example, to gauge the performance improvements?" Francesco Casella 3814 Optimizsation of record modifications MetaModelica Future enhancement Martin Sjölund new 2016-04-03T10:01:54Z 2016-07-06T08:52:13Z "Consider the following example code: {{{ record exampleLst Integer n; list elems; // more elements to follow... end record; function appList input list li; input output exampleLst lst; algorithm lst.n := lst.n + listLength(li); lst.elems := listAppend(li, lst.elems); end with; end appList; }}} Currently the compiler will create a new record for each of the two assignment lines (via {{{mmc_mk_box()}}}), though the intermediate object is never really referenced or used. Now, the compiler could try to figure out this and only do one {{{mmc_mk_box()}}} incorporating both changes. This would immediately reduce overall memory usage. A second approach would be to extend MetaModelica language with a {{{with do … end with;}}} construct like the following: {{{ function appList input list li; input output exampleLst lst; algorithm with lst do .n := .n + listLength(li); .elems := listAppend(.elems, li); end with; end appList; }}} Here, the assignment ({{{mmc_mk_box()}}}) is only done at the {{{end with;}}} line, and the component contents stored in temporary variables. I do not bother if one or both ways are implemented, but I would definitely love to see at least one of them :-) The second approach could also be extended to e.g. also allow for-loops etc. {{{ function appList input list> lists; input output exampleLst lst; algorithm for li in lists loop with lst do .n := .n + listLength(li); .elems := listAppend(.elems, li); end with; end for; end appList; }}}" Henning Kiel 3848 Feature Request: Visualization of Simulation Results in Model View Frontend v1.10.0-dev-nightly Future enhancement somebody new 2016-04-14T04:03:28Z 2016-04-14T04:03:28Z "The OpenModelica Plotting module is a very convenient tool for analyzing specific variables' individual behaviour. For understanding overall system behaviour and relationships however, a modeling engineer would also like being able to display a multitude of instantaneous variable values concurrently on the Diagram View of a model, being able to navigate through the simulation results with a Time control element. The attached photoshopped screen shows how such a visualization could look like. It shows monitoring elements for certain variables on the model diagram, and a slider control to browse through the simulation time to see how the monitored variable values change as a function of time. The variable monitors could for instance be added by the modeler as a new annotation element, or alternatively instantiated as components from a new Sensor class and placed on the desired Diagram locations. With such an interactive model view, a user could display instantaneous temperatures, pressures and signal values at different locations of his diagram, much like on the SCADA HMI screens in a power plant control room. By play-back of the simulation results over time, he could for instance see how a medium temperature change travels from component to component through the modeled system. " stephan.fevrier@… 3920 smiplify swap args MetaModelica Future enhancement Martin Sjölund new 2016-05-19T13:59:05Z 2016-05-19T14:02:19Z "In some cases we have something like {{{ case(e1 as X(), e2 as Y() ) guard ... equation ... then f(e1,e2) case(e2 as Y(), e1 as X()) guard ... equation ... then f(e1,e2) }}} it would nice to have {{{ case(e1 as X(), e2 as Y()) /*key-word?*/ case(e2 as Y(), e1 as X()) guard ... equation ... then f(e1,e2) }}}" Vitalij Ruge 3931 Do not generate stupid equations Initialization Future enhancement Lennart Ochel new 2016-05-26T13:29:43Z 2018-02-13T06:14:14Z "Simple initialization equations can be handled by the init.xml-file instead of requiring GCC to link things and executing code at run-time. Take a simple model like: {{{#!mo model M Real r(fixed=false, start=0); initial equation r = 1; equation der(r) = 1; end M; }}} Yields {{{#!c /* equation index: 2 type: SIMPLE_ASSIGN r = 1.0 */ void M_eqFunction_2(DATA *data, threadData_t *threadData) { TRACE_PUSH const int equationIndexes[2] = {1,2}; data->localData[0]->realVars[0] /* r STATE(1) */ = 1.0; TRACE_POP } }}} Even using fixed=true, we get a function generated: {{{#!c /* equation index: 2 type: SIMPLE_ASSIGN r = $_start(r) */ void M_eqFunction_2(DATA *data, threadData_t *threadData) { TRACE_PUSH const int equationIndexes[2] = {1,2}; data->localData[0]->realVars[0] /* r STATE(1) */ = data->modelData->realVarsData[0].attribute /* r */.start; TRACE_POP } }}} These should both be avoided, keeping the start-value from the XML-file if nothing is given." Martin Sjölund 3950 Cross compilation of FMUs under Windows Build Environment Future enhancement Martin Sjölund new 2016-06-06T05:04:05Z 2018-08-09T13:01:22Z "Recently a 64bit Windows version of OpenModelica was introduced. A separate 32bit version is still needed for the export of 32bit FMUs. This should be covered with cross compilation instead. Cross compilation already works under Linux, including an extended `CevalScriptBackend.buildModelFMU(className = ""MyModel"", platforms = {""i686-w64-mingw32""})` where `platforms` is a list of ""static"", ""dynamic"" and target triplets, like 32 bit windows in the example. Moreover the OMEdit configuration of FMI export was extended for cross compilation (Tools -> Options -> FMI). The C runtime implements cross compilation of minimal FMUs including source code; the Cpp runtime implements export of full FMUs using pre-compiled runtime libs for the respective target platform. If cross compilation shall work like under Linux then we need: - compilers with the name i686-w64-mingw32-gcc and i686-w64-mingw32-g++ (OMEdit and the FMU makefiles would expect it) - static versions of libgcc and libstdc++ (and possibly libwinpthread) along with these compilers - call the Cpp FMU makefile with a triplet argument TARGET_TRIPLET=i686-w64-mingw32 (this happens automatically if checked in OMEdit, calling CevalScriptBackend.buildModelFMU with platforms argument) - an additional version of the Cpp runtime *_static libs generated with this compiler and placed in the directory ""$(OMHOME)/lib/$(TARGET_TRIPLET)/omc/cpp"" The concept of the target triplet might be extended to msvc. Then msvc libs would not be placed in subdirectories of the gcc libs anymore, like $(OMHOME)/lib/omc/cpp/msvc but besides the gcc libs using another TARGET_TRIPLET, like $(OMHOME)/lib/$(TARGET_TRIPLET_FOR_MSVC)/omc/cpp " Rüdiger Franke 3961 Expand parameter sensitivities to other result formats Run-time v1.10.0-dev-nightly Future enhancement somebody new 2016-06-14T10:21:13Z 2017-11-14T22:08:53Z Currently parameter sensitivities are only support mat by the mat files result format, this should be expand to other result formats like csv and plt. Willi Braun 3964 MetaModelica support in OMEdit OMEdit Future enhancement Adeel Asghar accepted 2016-06-16T17:00:22Z 2017-03-08T12:58:54Z "We now have some basic support for MetaModelica in OMEdit but there are still several things missing. Following are the list of features, 1. ~~Code folding.~~ 1. Auto complete. 1. ~~Single & multi-line commenting.~~ 1. ~~Pressing enter should open the selected file in ModelWidget.~~ 1. ~~Shift-Home should not select trailing spaces.~~ 1. ~~Show only name in ctrl-tab window.~~ 1. Find in files. 1. Function Outline. 1. Toggle comment selection for C/C++ Editor. 1. Code folding for C/C++ Editor." Adeel Asghar 4108 Better inspection of results in OMEdit OMEdit Future enhancement Adeel Asghar new 2016-10-27T05:32:01Z 2020-06-24T17:34:49Z "OMEdit's plot window currently shows a tool tip with the coordinates besides the mouse pointer. It is hard to place the mouse exactly on the curve of a result, in order to see the actual value. The problem can be solved by adding a vertical ruler (vertical line) to the plot window. On mouse click this ruler is drawn at the x-position of the mouse. The Variables Browser should then update all values to the selected time point. Moreover, the Variables Browser should have a slider, enabling the selection of time for variable values. The slider should be ""wired"" with the ruler. The slider of the Variables Browser should also be wired with the slider offered by the animation window -- or possibly replace it. " Rüdiger Franke 4223 Recursive BuildModel Test: Cross reference to previous run Testing Framework Future enhancement Martin Sjölund new 2017-01-20T08:40:46Z 2017-01-20T08:45:10Z It would be quite nice if the recursive buildmodel test (e.g. https://test.openmodelica.org/libraries/Annex60/BuildModelRecursive.html) would provide at least some navigation to the previous test run. Lennart Ochel 4301 Feature to break the simulation when the steady state has been reached Backend Future enhancement Lennart Ochel accepted 2017-03-08T14:33:46Z 2017-10-12T07:30:48Z "Proposed here: http://stackoverflow.com/questions/42673420/global-measure-to-test-when-steady-state-of-system-is-reached The first point sounds like a good to have feature and doesn't seem that hard to implement, basically a terminate when all the ders are 0 (within an epsilon) for a number of steps. For the second point we would need a global operator (that returns true when all ders are within an epsilon interval) that one can use in equations to enable / disable parts of the system." Adrian Pop 4353 OMEdit: Convenient selection of records for parameters OMEdit Future enhancement Adeel Asghar new 2017-03-21T14:33:03Z 2021-03-28T14:17:32Z "It seems to be good practice in Modelica to organize multiple parameters in records and just chose one out of many records to fully setup a component. Since two weeks or so, there is in OMEdit right of the parameter input box a button with {{{[...]}}}. I assumed that with that button I can select one of the records like in Dymola. But instead, I can select where I like to '''save''' the model file. This is weird!" Jan Kokert 4371 Import unit information OMPlot Future enhancement Adeel Asghar new 2017-03-26T16:05:18Z 2017-11-19T18:44:55Z "It would be nice to have unit information available if a result file is imported to OMEdit or displayed using OMPlot. There are various possible solutions to this: * Include unit information into the mat files * Also import a _init.xml file if available to provide the unit information for the given result file * ..." Lennart Ochel 4406 OMEdit: Option to automatically close Simulation Completed Window Run-time Future enhancement Willi Braun assigned 2017-04-28T09:24:25Z 2017-05-04T09:21:29Z "When I tune parameters and re-simulate very often, the Simulation-Completed-Window is totally annoying, even if we can close that now with the [ESC] key (see sceenshot). Is it possible to add an option, that this window closes automatically if there were no errors? Warnings like {{{""LOG_NLS_V | warning |

Warning: maximal number of iteration reached but no root found

""}}} are ok for me. I really don't need to see them again and again and again and again... (https://youtu.be/9VDvgL58h_Y)" Jan Kokert 4465 Improve FMI option dialog *unknown* Future enhancement somebody new 2017-07-07T13:25:36Z 2017-07-07T13:25:36Z "Currently the option dialog displayed in OMEdit for FMI platforms shows: [[Image(dialog.png)]] I find it difficult to understand what to choose. Somebody who knows FMI would possibly go for ""Dynamic"", because the standard way of using an FMU is as DLL or shared library. But this is not meant here. It is about the dependencies of the generated DLL to other DLLs. The standard user should normally use ""static"" since this implies that everything is linked into the dynamic library which is generated. Therefore, I think this dialog should be improved to make it more clear for a user what is meant and give an indication that ""static"" is the default choice for a typical user. " Bernhard Thiele 4548 Implement support for enumerations in Susan Susan (Templates) v1.13.0-dev-nightly Future enhancement Adrian Pop new 2017-10-06T18:07:47Z 2017-10-06T18:07:47Z Susan doesn't have any support for enumerations it seems, i.e. it's not possible to declare enumerations in a type view or do anything with them in a template. This restricts the use of enumerations quite a bit since we can't use them in structures we already dump using templates (e.g. SCode or DAE), or use templates to dump structures we already use enumerations in (e.g. new frontend). Per Östlund 4566 Deleting intermediate files from CLI Command Prompt Environment Future enhancement somebody new 2017-10-16T08:50:39Z 2017-10-16T08:50:39Z "It seems that `translateModelFMU` removes most of the intermediate files at the end, but not all of them. I think it should either keep all of them or none of them - preferable customizable on a flag. The same should apply to the other commands, like `buildModel` and `simulate`. See also #2909 and #3788." Lennart Ochel 4586 enhancement: show class diagram in OMEdit OMEdit Future enhancement Adeel Asghar new 2017-10-24T14:42:01Z 2020-08-03T11:36:20Z "Basically a duplicate of this SO question: https://stackoverflow.com/questions/20607206/modelica-class-diagrams When reading code with many levels of inheritance, it would be very helpful to see a class diagram, so that it is immediately clear what parameters, variables etc were added where. Is such a functionality available already? Maybe using some script? It would be nice to be able to just see such a diagram with a single click from OMEdit." Matthis Thorade 4589 Investigate using AvlSetInt for Adjacency Matrix Backend Future enhancement Lennart Ochel new 2017-10-25T15:56:40Z 2017-10-25T15:56:40Z Currently, our adjacency matrixes use a `list>` structure, but the order of these integers does not matter. If we start using `list`, we could do operations like join and intersect without expensive operations. We would also not need to use `List.unique`. For the `comSubExp` module, the use of a single line of an intersection call used more than 50% of the total used memory of the entire translation process. Martin Sjölund 4609 Refresh button OMPlot Future enhancement Adeel Asghar new 2017-11-03T13:32:33Z 2017-11-03T16:29:07Z "A reload button would improve the usage of OMPlot (and probably OMEdit as well) in certain cases: * Plotting simulation results while the simulation is still running * Updating the plot view (and keeping all settings, e.g. scaling and selected set of variables) after recreating the result file (e.g. with different parameters) * ... " Lennart Ochel 4616 Array versus vector signals plotting behavior OMPlot v1.12.0 Future enhancement Adeel Asghar new 2017-11-06T12:14:44Z 2017-11-06T16:14:19Z "I've discovered the neat new feature ""array plot""in the 1.12 branch (*). I didn't experience bugs so far, but got slightly frustrated when working with vectors signals. I call ""vector signals"" the kind of arrays, often of small dimension, where it makes no sense to make an array plot, only time domain plots. For example i_abc={ia, ib, ic}, the concatenation of three currents in a three phased electrical systems. Behavior in 1.12: when a regular (time domain) plot tab is active, I expect that clicking on an array i_abc would plot all elements (ia, ib, ic). As of 1.12, it opens instead a new array plot windows. I find this confusing. Also, compared to 1.11, there is now one more click required to plot (ia, ib, ic), because one needs to expand the i_abc tree. I propose instead that when clicking on an array ''when the active plot is a regular plot'', it simply selects/unselects all the array components to make a time domain plot. One may argue that this diminishes the discoverability of the new ""array plot"" feature. One possible solution would be to add a Information popup when clicking on an array (with a text like ''""Do you know that you can use an array plot instead""'' .... with ""Don't show this message again"" checkbox). (*) as a side note, I haven't seen this new feature advertised in the 1.12 release notes (https://openmodelica.org/newss/186-october-31-2017-openmodelica-1-12-0-released)" Pierre Haessig 4637 Sort of the input and output variables in the model description Backend Future enhancement Willi Braun new 2017-11-20T12:02:58Z 2017-11-20T12:02:58Z "Currently the Real input and output variables are not sorted together, instead they are arbitrary in the whole Real variable list. For example the ModelStructure of the DrumBoiler model looks currently: {{{ }}} Here the inputs are {{{133 161}}} and the output {{{131 132 147 162 163}}}. It would be more efficient for some application if they would sorted simply together. e.g. inputs:{{{7 8}}} and outputs:{{{9 10 11 12 13}}}." Willi Braun 4678 Allow passing external objects as parameters to a class *unknown* v1.13.0-dev-nightly Future enhancement somebody new 2017-12-15T11:50:44Z 2017-12-15T15:05:22Z "There are cases there passing external objects as parameters to a class is very handy. An example is in the Modelica_DeviceDrivers library where an external object holding the handle to a Comedi-device is used as a parameter for ADC and DAC device blocks. The MLS 3.4 doesn't allow this construction, but it is supported by some other tools and I think the MLS 3.4 is overly restrictive in this respect. OpenModelica seems to almost support it. The two examples below show the principle. 1. `Test_EO` creates an external object named `eo` and uses it directly. This (standard conform) model '''works'''. 2. `Test_BlockWithEOParameter` is almost the same except that the logic is outsourced in a block which is instantiated and the block receives the external object as an argument. This (non standard conform) model '''doesn't work'''. OpenModelica translates example 2. to C code without error, but during C code compilation one gets the error: {{{ EOsAsParameter.Test_BlockWithEOParameter.c:90:48: error: use of undeclared identifier '$PblockEO$Peo' omc_EOsAsParameter_doSthWithEO(threadData, $PblockEO$Peo) }}} `blockEO.eo` is just an alias for `eo`. It seems that not much is missing to have it working and I think it would be a fine enhancement if one could actually make it work. {{{#!modelica package EOsAsParameter ""Using external objects as parameter"" model Test_EO EO eo=EO(""handlepath""); equation when sample(0,0.2) then doSthWithEO(eo); end when; end Test_EO; model Test_BlockWithEOParameter EO eo=EO(""handlepath""); BlockWithEOParameter blockEO(eo=eo); end Test_BlockWithEOParameter; block BlockWithEOParameter ""Block with ExternalObject as parameter"" parameter EO eo; equation when sample(0,0.2) then doSthWithEO(eo); end when; end BlockWithEOParameter; class EO ""External object"" extends ExternalObject; function constructor ""Open device"" input String devicename = ""/dev/comedi0"" ""Device name""; output EO eo ""Handle to external object""; external ""C"" eo = my_eo_create(devicename) annotation (Include="" void* my_eo_create(const char* devicename) { int dummy = 0; return (void*)&dummy; } ""); end constructor; function destructor ""Close device"" input EO eo ""Handle to external object""; external ""C"" my_eo_free(eo) annotation (Include=""void my_eo_free(void* eo) {}""); end destructor; end EO; function doSthWithEO input EO eo; external ""C"" doSthWithEO(eo) annotation (Include="" #include void doSthWithEO(void* eo) { ModelicaFormatMessage(\""Called doSthWithEO\\n\""); } ""); end doSthWithEO; end EOsAsParameter; }}}" Bernhard Thiele 4746 Trace back where a given component is defined (or modified) in a class Frontend Future enhancement Adrian Pop new 2018-02-05T15:11:13Z 2018-02-05T15:20:30Z "Inheritance is widely used to build Modelica models a) to factor out common behaviour and b) to customize models via replaceable classes and models. Consider this simple example. {{{ model A Real x ""Amount of stuff XXX""; Real y ""Amount of stuff YYY""; ... end A; model B extends A(y(start = 10)); Real z ""Amount of stuff ZZZ""; end B; model C extends B; Real w; equation x + y = 10; y + z = 15; x/z = w; w = 3; end C; }}} Suppose I am inspecting model C, and I want to understand its equations. Unfortunately, the definitions of variables {{{x, y, z}}}, and of their start attribute (which could be critical for convergence) is not found in class C. What I need to do as of today is to manually traverse the inheritance chain to discover the definition of {{{z}}} in {{{B}}}, of {{{x,y}}} in {{{A}}}, and the redeclaration of the start attribute of {{{y}}} in {{{B}}}. The compiler knows about all this stuff, so it would be really nice if it could spare me the waste of time of the manual search and give me this information. For example, if I right click on {{{y}}} in model C, it will tell me that the variable is defined in model {{{A}}} and the start attribute modified in class {{{B}}}, and possibly open extra tabs in OMEdit where those definitions are highlighted. BTW, this feature would be immensely useful to allow people to really understand models from complex libraries like {{{Modelica.Media}}} and {{{Modelica.Fluid}}}. Would this be doable without too much effort?" Francesco Casella 4777 Support modification of description string Backend Future enhancement Lennart Ochel new 2018-02-25T21:01:40Z 2018-02-25T21:01:40Z "Triggered by https://github.com/modelica/Modelica/pull/2471 I would like to initiate the support of modified description strings in OpenModelica. In particular the real and complex blocks of the MSL inherit from standardized interface blocks. However, it is now difficult to intuitively understand each block without the support of modified description strings, which I would like to implement. " Christian Kral 4797 Is there a way to define a LaTex formatted text to dfine a symob for a variable in OM? OMEdit v1.13.0-dev-nightly Future enhancement Adeel Asghar new 2018-03-10T05:39:16Z 2018-03-16T07:38:02Z "Hello, I am postprocessing my simulation results from the OM _res.mat outout files using DyMat in Python, where I use matplotlib package to generate graphs of the imported results. I am wondering if there is a way or place in OM (e.g. somewhere within the annotation feature etc) where I can define a symbol for a variable using LaTex formatted text (e.g. adding subscript, superscript, greek letters etc) along with the name, unit and description of the variable. If there is a way to do so inside the .mo file, and assuming that the symbols list will be written somewhere in the _res.mat or _init.xml files, then all the symbols can be nicely handled by matplotlib which does support LaTex. I think that is a nice feature that could be added to OM in the near future, if it already does not exist. Cheers, Ali Shirazi" ali.shirazi@… 4877 Optionally prune all the equations in a model that are not needed to compute the outputs Backend Future enhancement Willi Braun new 2018-04-10T12:25:36Z 2018-04-10T12:25:36Z "In 2011, together with PhD student Vincenzo Manzoni, I proposed a method to prune the dependency graph of the equations in a Modelica model to only keep those equations that are strictly necessary to compute the top-level outputs of a model, see paper [https://www.modelica.org/events/modelica2011/Proceedings/pages/papers/32_poster_ID_130_a_fv.pdf Minimal Equation Sets for Output Computation in Object-Oriented Models]. This could be very useful in a number of cases: - to speed up the computation of models in FMUs, by eliminating the computation of equations that may be included in the model for monitoring purposes, but that are not required to compute the output - to get simplified models very cheap, e.g., if you build a planar MultiBody system models, only put the motion on the plane as output, and evaluate the parameters, it could automatically remove all the equations for decoupled out-of-plane dynamics without the need of explicitly using different models for that purpose. This is particularly useful for systems that have ''some'' planar parts, and some full 3D motion mixed up. - to automatically remove the computation of unneded thermodynamical properties in thermofluid models with equation-based fluid models Unfortunately, as far as I understand, nobody has ever tried to implement this in a Modelica tool - at the time, we only tried it out manually on toy models. For me, it would be particularly interesting to see how much this method can help in real-life cases. In fact, it could turn out that in some cases of industrial relevance, you can get a significant speed-up, at practically zero cost for the modeller, as it would only be necessary to declare the top-level interesting outputs. From what I understand of the development in [https://github.com/OpenModelica/OMCompiler/pull/2349#issuecomment-380069675 PR #2349], implementing this additional feature should be rather straightforward, because all the required data structures and graph-analysis algorithms are already there. In a nutshell, it is only necessary to build the dependency graph from the outputs, adding the implicit dependency between each state variable and its corresponding derivative to the explicit dependencies in equations. Are you interested in this development?" Francesco Casella 5123 Support installations of multiple releases in Windows Installation program Future enhancement Adeel Asghar new 2018-09-13T17:18:31Z 2018-09-13T17:18:31Z It should be possible to install stable and nightly in parallel. Also, until cross-compiling to 32bit is supported, installing 32 and 64 bit in parallel. tknodt@… 5166 Feature request: same increment of horizontal and vertical axis OMEdit Future enhancement Adeel Asghar new 2018-10-11T15:25:53Z 2018-10-17T05:52:32Z "For electrical and mechanical engineers it were very advantageous to be able to create parametric plots which have the same horizontal and vertical axis increment. I will show two examples in short: '''1) Modelica.Electrical.QuasiStationary.SinglePhase.Examples.SeriesResonance''': In order the plot the frequency response locus of the current of the circuit the following parametric plot shall be investigated: * `currentSensor.i.re` (horizontal axis) * `currentSensor.i.im` (vertical axis) The plot shall be a circle but it appears as ellipse, since the horizontal and the vertical axis do NOT have the same increment. '''2) Modelica.Mechanics.MultiBody.Examples.Elementary.DoublePendulum''': The trajectory of frame_b of the first rod can be investigated creating a parametric plot of: * `boxBody1.frame_b.r_0[1]` (horizontal axis) * `boxBody1.frame_b.r_0[2]` (vertical axis) The trajectory shall the arc of a circle but it appears as the arc of an ellipse due to the same reason as of example 1. So in addition to auto setup it were very good to have a checkbox for the option ""Same increment of horizontal and vertical axis"". " Christian Kral 5309 Descriptions of the meaning of Complex variable are lost in the simulation result file Run-time Future enhancement Karim Adbdelhak assigned 2019-01-31T15:24:18Z 2019-04-01T11:22:11Z "Consider this simple test case {{{ model M Complex z ""Meaning of variable z""; equation z = Complex(time); end M; }}} When you open the Variables Browser, the explanation of what z means, i.e. the content of the comment ""Meaning of the variable z"" is lost. You only see the comment of the two fields of record z, ""Imaginary part of complex number"", and ""Real part of complex number"", which are useful but a bit too generic. This is due to the fact that currently only the comments of the scalar variables in the result are stored in the result file. We should find a solution (possibly backwards compatible with the existing de-facto standard set by Dymola) where we can add this information. In fact, this would also be useful in this other case {{{ model M2 M3 m ""Description of what m actually is""; end M2; model M3 Real x ""Meaning of variable x""; end M3; }}} If you simulate M2, the only description of component {{{m}}} that you see is its name, and the description of its variable x. This may be enough if the name {{{m}}} is chosen to be meaningful (as suggested by the helper windows of OMEdit when you drag-and-drop, BTW), but it would be nice to also be able to see the full comment string, in case the model developer wanted to be clearer. Currently, the full description of {{{m}}} is only visible if you hover the cursor on the component icon in the diagram view (assuming it has one), but not in the variable browser window." Francesco Casella 5365 find declared but unused variables and parameters *unknown* Future enhancement somebody new 2019-03-01T07:17:53Z 2019-03-01T15:08:31Z I sometimes have parameters and/or variables declared, but they are not used anymore due to rewriting the equations (or after some intermediate debugging). Tools like PyCharm (an IDE for Python) can detect such unused variables and warn about them. Would that also be possible with OpenModelica? Anton Neem 5921 Support for loading mol files in OMPython OMPython v1.16.0-dev Future enhancement Alachew Mengist new 2020-04-22T08:42:04Z 2020-04-22T08:42:04Z "It looks like it is currently not possible to load libraries distributed as in `mol` format. Even if the `mol` file is just a package and not encrypted. " Dietmar Winkler 6024 OM won't compile on cutting edge linux due to internal dependencies. Suggest to optionally configure for available system packages instead of sub-repos. Build Environment v1.16.0-dev Future enhancement Martin Sjölund new 2020-06-21T15:26:50Z 2020-06-22T06:35:23Z "Compiling from git source on current (cutting edge) Manjaro fails due to mumps and qwt build errors. qwt fails because of a similar issue to this one: [https://github.com/RPCS3/rpcs3/pull/7832]. Fix that makes the same build work presented here: [https://github.com/OpenModelica/OpenModelica/pull/983] Generally, compiling from source on Linux would benefit greatly from the possibility to use system packages for Ipopt, mumps, qwt, sundials etc. more easily. Additionally, explicitly using an internal qwt as omqwt forcilbly seems heavy-handed, especially since many systems provide a good qwt separately. Propose to update configure/autoconf with options to use system packages." ppenguin 6130 Support for FMI for Co-Simulation (2.0 Standard) FMI Future enhancement Lennart Ochel new 2020-09-21T11:09:24Z 2020-09-21T19:02:36Z "Hi there, I was wondering, when support for FMI Import/Export for Co-Simulation (according to 2.0 Standard) is planned to be implemented? Can you give me an estimate? Thanks!" nicolai.schoch@… 6335 Cannot manage lots of FMU inputs/outputs in a SSP model with OmSimulator OMSimulator v1.17.0-dev Future enhancement Lennart Ochel new 2021-01-08T09:15:52Z 2021-01-09T17:19:51Z "At EDF we have some co-simulation graphs with FMUs having hundreds of inputs/outputs. These graphs can be managed with our tool DNG (https://bitbucket.org/simulage/daccosim/wiki/Home). It appears more difficult with OMSimulator as: - each input/output is graphically distinguished on the left side (for inputs) or the right side (for outputs). - each FMU-to-FMU connection only carries one variable (FMU.output --> FMU.input). I suggest as a solution to allow transmission of several variables per connection. " jean-philippe.tavella@… 2883 Restructuring SimCode phase Backend trunk Future task Lennart Ochel new 2014-10-13T09:07:38Z 2014-10-13T09:20:28Z SimCode should be clearly separated from the back end. Afterwards, the SimCode phase should get restructured and split up into various files to improve compilation, maintenance and further development. Lennart Ochel 3751 Update MetaModelica Documentation MetaModelica v1.9.4-dev-nightly Future task Martin Sjölund new 2016-03-07T09:23:53Z 2016-03-07T09:23:53Z "There are a number of new MetaModelica features that have (possibly) not been fully documented in the design: * `input output` function variables: #3709 * Parametrized uniontypes #3573 * Closures (from Modelica) * isPresent (from Modelica 2.x) * Loops and list reductions (?) * Matching on enumerations (?) #3006 * Matching on constants #3005 * Destructive and dangerous operations: `listSetRest` (like lisp `setcdr`), `listReverseInPlace`, `stringGetNoBoundsChecking`, `arrayCreateNoInit`, `arrayUpdateNoBoundsChecking`, `arrayGetNoBoundsChecking` * Add the `continue` statement in loops #2897 * Implement try/catch: #2887 * Implement try/catch for stackoverflow (special annotation on try/catch): #2090 * Implement threaded iterators: #2816 (not multi-threading, but threading iterators together) * Support `myRecord.x := exp`, etc in some cases" Martin Sjölund 5874 Function body dependencies FE or BE? Frontend Future task Per Östlund assigned 2020-03-03T12:54:55Z 2020-03-06T13:06:26Z "Consider following function and its derivative: {{{ function f input x; input dx; output y; algorithm y := x; annotation ( derivative = df, Inline=false); end f; }}} {{{ function df input x; input dx; output y; algorithm y := dx; end df; }}} The function call has following structure in the Frontend: {{{ record CALL Absyn.Path path; list expLst; CallAttributes attr; end CALL; }}} And the `expLst` contains all inputs such that they will be used for any dependency analysis needed. As we see both functions have inputs they do not actually depend on so that leads to different problems, such as thae one mentioned in #5770. In the Backend we would need to get the actual function body from the function tree and traverse it, i would like to have them collected once and always available. Can that information be provided by the Frontend when the function tree is built? EDIT: This also occurs for FMI models where the interface functions can have dummy inputs." Karim Adbdelhak 5937 Parallel simulation ParModelica Future task Mahder Alemseged Gebremedhin new 2020-05-04T15:06:24Z 2020-05-06T13:00:16Z "I am trying to use hpcom to simulate in parallel my model, but I don't get the parallel and serial costs as output, after running the simulation. The ParModelica extension is already enabled, or there is another way to parallelize the model?" llucfigueras1@… 3936 problems with OMOptim OMOptim v1.9.4-v1.9.x NeedsInput defect new 2016-05-27T16:15:01Z 2017-12-21T07:23:35Z "I am trying to use OMOptim, and I can't compile any files, even the example you provide in the online tutorial. I always get an error of the kind: [C:/Research/Dx/Tank-Model/reactor.mo:1:0-1:12:writable] Error: Parser error: Unexpected token near: optimization (IDENT) The moment that I replace (in your example) optimization BatchReactor(... with model BatchReactor(... then the file will load, but won't work with OMOptim. Any ideas about what I am doing wrong?" g.provan@… 4804 IDEAS.Buildings.Examples.Structure crashes OMEdit 32 bit on Windows 10 *unknown* NeedsInput defect somebody new 2018-03-15T09:58:45Z 2018-05-08T09:13:22Z The model IDEAS.Buildings.Examples.Structure takes long to open, very long to compile and OMEdit 32bit crashes on Windows 10 (64bit, German), but it is not possible to send a crash report, so possibly related to #4688. anonymous 6260 "Error ""Following variable is discrete, but does not appear on the LHS of a when-statement""" Frontend 1.16.0 NeedsInput defect Per Östlund reopened 2020-12-01T17:31:52Z 2021-02-18T17:54:40Z "I get the error ""Following variable is discrete, but does not appear on the LHS of a when-statement"" for a discrete variable connected to another discrete variable that is in a when statement. Is that normal? Example: connect(tapChanger.tap, transformer.tap); // error with new front end (transformer.tap is not in the LHS of a when-statement, but tapChanger.tap is, so I would have expected the error to disappear when writing the connect statement. when time >0 then transformer.tap.value = tapChanger.tap.value; // no error end when;" marianne.saugier@… 6284 When condition with dae mode Run-time 1.16.0 NeedsInput defect Andreas Heuermann new 2020-12-16T07:47:14Z 2020-12-16T20:13:46Z "Such an example works fine with ida but not anymore when adding the dae mode (the variable U stays constant equals to 1): Real U(start = 1); equation when time >1 then U = 0.8; end when; We are working on an electrical test system and we need the dae mode so that we can simulate within acceptable time, but we also need to simulate the tapChanger behavior, which is impossible in dae mode because the tap stays constant. This problem can also be observed with PowerGrids/Electrical/Tests test case ""TestTransformerWithTapChangerInterval"": when adding the dae mode, the tap doesn't move anymore. " marianne.saugier@… 6291 failed to value of parameter Interactive Environment v1.17.0-dev NeedsInput defect Adrian Pop new 2020-12-17T10:11:55Z 2020-12-23T09:33:58Z "short example: {{{ model test parameter Real a = 5; parameter Real b = if a > 10 then 3 else 2; end model; }}} I'm trying to modify my model with the method ""setComponentModifierValue(test, b, $Code(=0))"" but I get the error ""failed to set value of b"". I think the problem is, that in my model the parameter_name is dependent of another parameter. Is there a possibility to change the parameter without reformulating the model? Thanks, Lukas " lukas.koenemann@… 6337 OMPython openning files associates with non default OM libraries OMPython 1.16.2 NeedsInput defect arunkumar palanisamy reopened 2021-01-08T10:56:45Z 2021-01-13T12:57:40Z "Hello, I am trying to open one file VSC_Test.mo that I developed using three default Modelica libraries (Modelica 3.2.3,Complex 3.2.3,ModelicaServices 3.2.3) and 2 other libraries (OpenIPSL,HVDCcomponents). However when I try to create the model mod using the function ModelicaSystem(), several errors pop up. If I load the model only using the name of the file and its path : ---- {{{ from OMPython import OMCSessionZMQ from OMPython import ModelicaSystem path = 'C:/Users/j.alves/Desktop/Stage/Python_CODES/Modele_HVDC_simplifie' # path = 'C:/OpenModelica/lib/omlibrary/HVDCcomponents/Examples' within = 'HVDCcomponents.Examples' name = 'Test_VSC' file ='""'+ path + '/' + name + '.mo'+'""' mod_file = path + '/' + name + '.mo' load_file = ""loadFile("" + file + "")"" within_name = within + '.' + name # To create the modelica session and execute action omc = OMCSessionZMQ() # To set variables, and change the model mod = ModelicaSystem(mod_file) mod.buildModel() # Loading the model file Load = omc.sendExpression(load_file) if (not Load): raise NameError(""Coudn't load file"") 2021-01-08 10:58:55,995 - OMPython - INFO - OMC Server is up and running at file:///C:/Users/J5046~1.ALV/AppData/Local/Temp/openmodelica.port.01c776f1a0d049748d371c59fde5c76e pid=2436 2021-01-08 10:58:56,323 - OMPython - INFO - OMC Server is up and running at file:///C:/Users/J5046~1.ALV/AppData/Local/Temp/openmodelica.port.c90c19bd229547c4abbc8c7f7570a383 pid=3316 Notification: Automatically loaded package Modelica 3.2.3 due to uses annotation. Notification: Automatically loaded package Complex 3.2.3 due to uses annotation. Notification: Automatically loaded package ModelicaServices 3.2.3 due to uses annotation. Notification: Skipped loading package OpenIPSL (1.5.0) using MODELICAPATH C:/OpenModelica/lib/omlibrary (uses-annotation may be wrong). Notification: Skipped loading package HVDCcomponents (1.0) using MODELICAPATH C:/OpenModelica/lib/omlibrary (uses-annotation may be wrong). --------------------------------------------------------------------------- TypeError Traceback (most recent call last) in 9 10 # To set variables, and change the model ---> 11 mod = ModelicaSystem(mod_file) 12 mod.buildModel() 13 c:\python38\lib\site-packages\OMPython\__init__.py in __init__(self, fileName, modelName, lmodel, useCorba, commandLineOptions) 718 if (self.fileName_): # execution from different path 719 os.chdir(self.currDir) --> 720 self.__loadingModel() 721 else: 722 print(""Error: File does not exist!!!"") c:\python38\lib\site-packages\OMPython\__init__.py in __loadingModel(self) 758 if loadmodelError: 759 print(loadmodelError) --> 760 self.buildModel() 761 762 def buildModel(self): c:\python38\lib\site-packages\OMPython\__init__.py in buildModel(self) 764 buildModelResult = self.requestApi(""buildModel"", self.modelName) 765 buildModelError = self.requestApi(""getErrorString"") --> 766 if ('' in buildModelResult): 767 print(buildModelError) 768 return TypeError: argument of type 'NoneType' is not iterable }}} ---- [[Image(1.png)]] If instead of using only the name I put ""within"" in ""mod = ModelicaSystem(mod_file,within_name)"" since there is a commented within in the VSC_Test file (Image 1) I get: {{{ Notification: Automatically loaded package Modelica 3.2.3 due to uses annotation. Notification: Automatically loaded package Complex 3.2.3 due to uses annotation. Notification: Automatically loaded package ModelicaServices 3.2.3 due to uses annotation. Notification: Skipped loading package OpenIPSL (1.5.0) using MODELICAPATH C:/OpenModelica/lib/omlibrary (uses-annotation may be wrong). Notification: Skipped loading package HVDCcomponents (1.0) using MODELICAPATH C:/OpenModelica/lib/omlibrary (uses-annotation may be wrong). [C:/OpenModelica/lib/omlibrary/HVDCcomponents/Examples/Test_VSC.mo:3:1-81:13:writable] Error: Expected the package to have within HVDCcomponents.Examples; but got within ;. Error: Failed to load package HVDCcomponents (default) using MODELICAPATH C:/OpenModelica/lib/omlibrary. Notification: Automatically loaded package OpenIPSL 1.5.0 due to uses annotation. Warning: Requested package Modelica of version 3.2.2, but this package was already loaded with version 3.2.3. You might experience problems if these versions are incompatible. Warning: Requested package Complex of version 3.2.2, but this package was already loaded with version 3.2.3. You might experience problems if these versions are incompatible. [C:/OpenModelica/lib/omlibrary/HVDCcomponents/Examples/Test_VSC.mo:3:1-81:13:writable] Error: Expected the package to have within HVDCcomponents.Examples; but got within ;. Notification: Skipped loading package HVDCcomponents (1.0,default) using MODELICAPATH C:/OpenModelica/lib/omlibrary (uses-annotation may be wrong). Error: Class HVDCcomponents.Examples.Test_VSC not found in scope . [C:/OpenModelica/lib/omlibrary/HVDCcomponents/Examples/Test_VSC.mo:3:1-81:13:writable] Error: Expected the package to have within HVDCcomponents.Examples; but got within ;. Error: Failed to load package HVDCcomponents (default) using MODELICAPATH C:/OpenModelica/lib/omlibrary. [C:/OpenModelica/lib/omlibrary/HVDCcomponents/Examples/Test_VSC.mo:3:1-81:13:writable] Error: Expected the package to have within HVDCcomponents.Examples; but got within ;. Notification: Skipped loading package HVDCcomponents (1.0,default) using MODELICAPATH C:/OpenModelica/lib/omlibrary (uses-annotation may be wrong). Warning: Requested package Modelica of version 3.2.2, but this package was already loaded with version 3.2.3. You might experience problems if these versions are incompatible. Warning: Requested package Complex of version 3.2.2, but this package was already loaded with version 3.2.3. You might experience problems if these versions are incompatible. Error: Class HVDCcomponents.Examples.Test_VSC not found in scope . }}} Also, the paths were those libraries are is the same as the path of all default libraries in MODELICAPATH (added to environmental variables Image 2) [[Image(2.png)]] ---- The libraries are located as in Image 3 [[Image(3.png)]] ---- Basically I want to open the VSC_Test.mo file and run simulations to get the results in real time with python to then change the inputs and run more simulations and so on... I will update the inputs of the system based on the result outputs. Moreover, using only the library Modelica I can run all the simulations I want using the ""mod"", but with these other 2 libraries I always get one kind of error. Please help me with this issue..." jeduapf@… 6365 check type of submodel OMPython 1.16.2 NeedsInput defect arunkumar palanisamy new 2021-02-03T13:07:58Z 2021-02-03T13:07:58Z "Hey, I'm using openmodelica/OMPython to simulate models. After simulation (call *.exe-File) i get the results as a mat-File. Is it possible to read out the type of sub-model/component that is included inside the main-model. For example: package test model submodel parameter Real a = 2; end submodel; model mainmodel parameter Real b = 4; submodel S(a=4); end mainmodel; end test; Is there any possibility to check what kind os model ""S"" is (with omc after initialization)? For example like: loadmodel(test.mainmodel); --> true type(S); --> ""submodel""" lukas.koenemann@… 6368 FMU export contains none unique value references to variables FMI 1.16.2 NeedsInput defect Lennart Ochel new 2021-02-06T19:46:19Z 2021-02-06T19:46:19Z "I'm trying to convert an ideal battery model with external input to an FMU. The resulting XML file contained non-unique value references to variables. Both the .mo file and the FMU file are attached. Could you please help me to fix this issue? Thank you, Buddi " buddih09@… 6369 FMU export contains none unique value references to variables FMI 1.16.2 NeedsInput defect Lennart Ochel new 2021-02-06T19:47:24Z 2021-02-06T19:47:24Z "I'm trying to convert an ideal battery model with external input to an FMU. The resulting XML file contained non-unique value references to variables. Both the .mo file and the XML file are attached. Could you please help me to fix this issue? Thank you, Buddi " buddih09@… 6382 External Interfacing of Models OMEdit 1.16.2 NeedsInput defect Adeel Asghar new 2021-02-17T13:08:01Z 2021-02-17T15:27:24Z " Please find the package attached. The aim is to perform addition of two numbers using an adder model. In order to have an external model to contain all the inputs and outputs of the system a ""Interface"" block is created. However the system accounts for two additional variables since maybe the ""input"" keywords are accounted in the variables section. To the contrary of above if the Interface is done within the main model itself the system does not count the "" input"" variables. [[Image(https://drive.google.com/drive/folders/1Bc82t-yHF7GjjmZS0_N9p2_5hbHgWQQD?usp=sharing)]] Please let me know more about this or any better means to handle the same " harish.kulambi@… 6408 Wrong start values for NLS with homotopy *unknown* 1.18.0-dev NeedsInput defect Andreas Heuermann assigned 2021-03-08T06:37:34Z 2021-03-20T19:21:39Z "Hi, I have noticed that with some of my power system models the nonlinear solver gets wrong start values for the iteration variables. I think the culprit is the inclusion of homotopy in the model. I attached a package with two network models in the examples package. In one of them, there is no homotopy and in the other I included homotopy just to demonstrate the issue (even though it is not needed). Homotopy is introduced in line 280 of CompositeLoadWithDummyHomotopy. The parameter of interest that becomes an iteration variable for the nonlinear solver is w_0. The start value of this parameter is assigned through another parameter omega_0 which is explicitly defined to be 1. I also attached the two screenshot which show the difference in the start values of w_0. In the case with homotopy, the start value of w_0 is zero, while without homotopy it is correctly set to 1. I tried this out on OM 1.17-beta3 and the nightly build from yesterday." trabuzin@… 6425 E: Unable to correct problems, you have held broken packages. *unknown* 1.16.5 NeedsInput defect somebody new 2021-03-14T17:51:29Z 2021-03-15T07:13:03Z "Hi. I tryed to install the Openmodelica in Ubuntu 20.04 - focal with the site instructions (https://www.openmodelica.org/download/download-linux). The result was: $sudo apt-get install openmodelica Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: openmodelica : Depends: omedit (< 20000) but it is not going to be installed E: Unable to correct problems, you have held broken packages. Can someone help me? Thanks. " fabiopinheirocardoso@… 6430 Error -1073741819 at solving initiation (after complete compilation) *unknown* 1.18.0-dev NeedsInput defect somebody new 2021-03-18T10:59:14Z 2021-03-31T16:23:58Z "Hi, We encounter a stranger error called -1073741819 on Windows x64. It appears in the ""Output"" tab in the Simulation windows. The full message is (in red) : ""Process crashed Process crashed Simulation process failed. Exited with code -1073741819. "" The model working on several computers makes a crash on one computer. Different OpenModelica version were tested on this machine and error is the same. " hubertblervaque@… 6276 Error in simulation: Simulation process failed. Exited with code 3. *unknown* 1.16.0 NeedsInput discussion somebody new 2020-12-09T02:51:48Z 2021-02-12T13:29:13Z "Platform OS: Windows10 OM: OpenModelica v1.16.1 (64-bit) OMSimulator v2.1.0-dev-230-g10c82c8-mingw ---- Error Code: src->ndims != dst->ndims, 1 != 0 Simulation process failed. Exited with code 3. ---- I have been working on simulation studies in power plant sector. I was able to successfully simulate the model using OMShell until Monday (12/07) but suddenly from 12/08, it is showing the above error in OMEdit. I Checked the .mo files from backup, it also shows same error message. I am not a strong program decoder. The compilation process shows below error ''STEAMPOWER.application.TURBINE_PLANT6B.c: In function 'STEAMPOWER_application_TURBINE_PLANT6B_eqFunction_4851': STEAMPOWER.application.TURBINE_PLANT6B.c:13533:182: warning: passing argument 2 of 'copy_real_array_data' from incompatible pointer type [-Wincompatible-pointer-types] copy_real_array_data(div_alloc_real_array(sub_alloc_real_array(mul_alloc_real_array(tmp661, tmp662), tmp663), sub_alloc_real_array(tmp674, mul_alloc_real_array(tmp676, tmp677))), &data->localData[0]->realVars[1244] /* BOILER.ploss[4] variable */); ^ In file included from C:/Program Files/OpenModelica1.16.1-64bit/include/omc/c/openmodelica_func.h:50:0, from STEAMPOWER.application.TURBINE_PLANT6B_model.h:6, from STEAMPOWER.application.TURBINE_PLANT6B.c:7: C:/Program Files/OpenModelica1.16.1-64bit/include/omc/c/util/real_array.h:89:13: note: expected 'real_array_t * {aka struct base_array_s *}' but argument is of type 'modelica_real * {aka double *}' extern void copy_real_array_data(const real_array_t source, real_array_t* dest);'' Kindly let us know the best way to avoid/rectify this error. Thank you " Manivannan Duraisamy 6355 Can I get more information on the variable steppers oms-mav et oms-mav-2? OMSimulator v1.17.0-dev NeedsInput discussion Lennart Ochel new 2021-01-27T10:30:11Z 2021-01-27T10:51:41Z "Can I get more information on the variable steppers oms-mav et oms-mav-2? What is the difference between them? Which continuous variables are used for increasing or decreasing the next step size? What are the criteria for next step evaluation knowing that parameters are given by user (minimum and maximum step size, first step size)?" jean-philippe.tavella@… 6251 Better support for search-index optimization in generated HTML help Documentation 1.16.0 NeedsInput enhancement Martin Sjölund new 2020-11-27T19:59:37Z 2020-11-27T19:59:37Z "In order to better support the search indexing of the generated Modelica HTML files, it would be very useful that the autogenerated table of the package contents has a separate h2 class, such that it can be distinguised from the the desired description or revisions. Here's some example what I mean {{{

Information

This is the desired description ...

Contents

Revisions

}}} All three h2 headings cannot be distinguished." modelica@… 6426 Solver export to fmu FMI 1.18.0-dev NeedsInput task Lennart Ochel new 2021-03-15T13:06:04Z 2021-03-15T13:06:04Z "Hello, I want to export my model as a co-simulation FMU with OpenModelica. It would be necessary to use the dassl solver within the FMU. Is that possible? best regards, Lukas" lukas.koenemann@… 1935 getNthInheritedClass is wrong for some models ... Interactive Environment trunk defect Adrian Pop assigned 2012-11-12T16:27:28Z 2021-09-13T11:58:21Z "Hi, Error report from Zsolt Lattmann: {{{ //model MassWithStopAndFriction //""Sliding mass with hard stop and Stribeck friction"" // extends PartialFrictionWithStop; // ... // extends Modelica.Thermal.HeatTransfer.Interfaces.PartialElementaryConditionalHeatPortWithoutT; // ... // encapsulated partial model PartialFrictionWithStop // ""Base model of Coulomb friction elements with stop"" // ... // end PartialFrictionWithStop; // ... //end MassWithStopAndFriction; loadModel(Modelica, {""3.2""}); getInheritanceCount(Modelica.Mechanics.Translational.Components.MassWithStopAndFriction); getNthInheritedClass(Modelica.Mechanics.Translational.Components.MassWithStopAndFriction,1); getNthInheritedClass(Modelica.Mechanics.Translational.Components.MassWithStopAndFriction,2); // ------------ ============ Outprint when exectuted ============ ---------------- // C:\OpenModelica1.9.0\bin>omc MassWithStopAndFriction.mos // true // 2 // Modelica.Thermal.HeatTransfer.Interfaces.PartialElementaryConditionalHeatPortWithoutT // Modelica.Thermal.HeatTransfer.Interfaces.PartialElementaryConditionalHeatPortWithoutT }}} The answer for the first should be PartialFrictionWithStop and for the second Modelica.Thermal.HeatTransfer.Interfaces.PartialElementaryConditionalHeatPortWithoutT. I believe it might be some issues with encapsulated classes and lookup." Adrian Pop 1939 Duplicate class detection not working when loading MSL New Instantiation trunk defect Per Östlund reopened 2012-11-15T15:05:18Z 2021-09-13T11:58:21Z "Loading a file such as {{{ package Modelica end Modelica; }}} and loading the MSL at the same time works fine, but it should complain about duplicate classes." Per Östlund 2380 Better error messages for API calls Interactive Environment trunk defect somebody new 2013-10-01T09:31:27Z 2021-09-13T11:58:21Z "If an API call is used with invalid arguments: {{{ loadFile(invalid); getErrorString(); }}} then you get this error message: {{{ Error: Class loadFile not found in scope (looking for a function or record). }}} The error message should instead say something about invalid arguments or something, saying that the API call could not be found is very confusing for users." Per Östlund 4006 SimCode scales as O(N^2) in models with many when clauses and events Backend defect Willi Braun assigned 2016-07-17T00:25:43Z 2021-09-13T11:58:21Z "Consider these two models from the ScalableTestSuite {{{ model ManyEvents ""Model with many events in when clauses"" parameter Integer N; Real x[N](each start = 0, each fixed = true); Boolean e[N](each start = false, each fixed = true); equation for i in 1:N loop der(x[i]) = 1/i; when x[i] > 1 then e[i] = true; end when; end for; end ManyEvents; model ManyEventsManyConditions ""Model with many events in when clauses and a when clause with many triggering conditions"" parameter Integer N; Real x[N](each start = 0, each fixed = true); Boolean e[N](each start = false, each fixed = true); Integer v(start = 0, fixed = true); equation for i in 1:N loop der(x[i]) = 1/i; when x[i] > 1 then e[i] = true; end when; end for; when e then v = pre(v) + 1; end when; end ManyEventsManyConditions; }}} It is apparent that the second one has one additional scalar equation, whose when clause is triggered by a vector {{{e}}} with {{{N}}} components. This is the performance of SimCode: create system equations on my pc for the first model ||=N=||=Time [s]=|| ||1000|| 4.3|| ||2000|| 18.0|| ||4000|| 87.6|| which scales as O(N^2.5^). For the second model, instead, I get: ||=N=||=Time [s]=|| ||1000|| 0.02|| ||2000|| 0.05|| ||4000|| 0.14|| which seems quite weird, as a model with one additional equation takes two order of magnitudes less time. This actually happens at the expense of the time spent by {{{encapsulateWhenConditions}}}, see #4005. Is there a way to avoid the blow up with N of the combined SimCode and encapsulateWhenConditions execution time?" Francesco Casella 4109 invalid xml file with logFormat is xml Run-time defect Willi Braun accepted 2016-10-27T09:23:10Z 2021-09-13T11:58:21Z In the xml logFormat of the c runtime is the root element missing, what may leads to parsing error while usage. Willi Braun 4194 Severe bug in unit conversion OMEdit v1.11.0 defect Adrian Pop accepted 2016-12-25T19:19:12Z 2021-09-13T11:58:21Z "Please consider the following simple example: {{{ model Test Modelica.SIunits.AngularAcceleration a=10*exp(-10*time); Modelica.SIunits.AngularVelocity w(displayUnit=""1/min"", start=0, fixed=true); Modelica.SIunits.Angle phi(displayUnit=""deg"", start=0, fixed=true); equation der(w)=a; der(phi)=w; end Test; }}} The results are '''horribly''' wrong! If I remove the ""displayUnit"", the absolete value of the results is correct, but the sign of phi is the opposite of the obvious solution! I'd prefer OpenModelica for my lectures, but how should I use that for teaching? I'm '''really''' upset." ahaumer@… 4483 Error due to bogus dynamic state selection Backend defect Lennart Ochel new 2017-08-02T10:29:29Z 2021-09-13T11:58:21Z "Please consider the attached test case. During compilation, OMC generates the following error Error: Internal error It is not possible to select continues states because Number of equations 203 greater than number of States 197 to select from The model compiles and runs correctly in Dymola. It has two potential state variables with {{{stateSelect.prefer}}} attribute; one is eliminated by the dummy derivatives method, and the only remaining one, which can definitely be selected statically is {{{pipeToCoolingTower.htilde[1]}}}. - Why is this error generated? - What does ""Number of equations greater than number of states to select from"" mean? Which set of equations is the message referring to? Please improve the clarity of the error message. Also note that the correct spelling of ""continues"" is ""continuous"" - More specifically, why trying (and failing) dynamic state selection among 197 potential states, for a model that has a very obvious static state selection? " Francesco Casella 4484 Model becomes singular if equations are written inside if-else Backend v1.11.0 defect Lennart Ochel new 2017-08-02T11:02:00Z 2021-09-13T11:58:21Z "Please see the attached file. In Column1 model if I write reboiler.feed.-- equations for some variables inside if-else, the model becomes singular. If I write these equations in algorithm outside if-else statement, model works fine. I am having eight variables in same if-else statement but only four of them behaves like this. Thank you in advance. " pravinkumar.dalve@… 4584 ZeroCrossings.equals costs memory Backend v1.13.0-dev-nightly defect Lennart Ochel new 2017-10-21T22:29:03Z 2021-09-13T11:58:21Z "Calling the function ZeroCrossings.equals costs some memory though it should only compare two zero crossings. I looked at the code, but could not find out where." Henning Kiel 4789 "Strange message when doing ""Save as...""" *unknown* defect somebody new 2018-03-02T17:38:27Z 2021-09-13T11:58:21Z "- load Test.mo in OMEdit - choose ""Save as..."" using Test1 as a name The following huge message is issued. The only hint on what the problem could be is the initial part of the message: {{{ [C:/dev/OpenModelica64bit/OMCompiler/Compiler/Script/CevalScriptBackend.mo: 1179:13-1179:204]: Internal error After merging the strings, the semantics changed for some reason (will simply return s2): }}} is. Strangely enough, the saved Test1 looks ok! Full message: {{{ [1] 18:34:03 Translation Error [C:/dev/OpenModelica64bit/OMCompiler/Compiler/Script/CevalScriptBackend.mo: 1179:13-1179:204]: Internal error After merging the strings, the semantics changed for some reason (will simply return s2): s1: package Test ""Package containing basic EV models"" model EVbasic ""Simulates a very basic Electric Vehicle"" import Modelica; DragForce dragF(Cx = 0.65, rho = 1.226, S = 6.0, fc = 0.013, m = mass.m) annotation( Placement(visible = true, transformation(origin = {104, -28}, extent = {{-10, -10}, {10, 10}}, rotation = 90))); Modelica.Mechanics.Rotational.Components.IdealGear gear(ratio = 6) annotation( Placement(visible = true, transformation(origin = {-26, 22}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Mechanics.Rotational.Sources.Torque torque annotation( Placement(visible = true, transformation(extent = {{-92, 12}, {-72, 32}}, rotation = 0))); PropDriver driver(k = 1000, yMax = 100000.0, CycleFileName = ""Sort1.txt"") annotation( Placement(visible = true, transformation(extent = {{-130, 12}, {-110, 32}}, rotation = 0))); Modelica.Mechanics.Translational.Sensors.PowerSensor mP2 annotation( Placement(visible = true, transformation(origin = {104, 12}, extent = {{-10, -10}, {10, 10}}, rotation = -90))); Modelica.Mechanics.Translational.Sensors.PowerSensor mP1 annotation( Placement(visible = true, transformation(origin = {28, 22}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Mechanics.Translational.Components.Mass mass(m = 16000) annotation( Placement(visible = true, transformation(extent = {{46, 12}, {66, 32}}, rotation = 0))); Modelica.Mechanics.Translational.Sensors.SpeedSensor velSens annotation( Placement(visible = true, transformation(origin = {78, -8}, extent = {{-10, -10}, {10, 10}}, rotation = 270))); Modelica.Mechanics.Rotational.Components.IdealRollingWheel wheel(radius = 0.5715) annotation( Placement(visible = true, transformation(extent = {{-8, 12}, {12, 32}}, rotation = 0))); Modelica.Mechanics.Rotational.Sensors.SpeedSensor motSpeed annotation( Placement(transformation(extent = {{-10, -10}, {10, 10}}, rotation = -90, origin = {-40, 0}))); Modelica.Mechanics.Rotational.Components.Inertia inertia(J = 5) annotation( Placement(transformation(extent = {{-64, 12}, {-44, 32}}))); equation connect(torque.tau, driver.tauRef) annotation( Line(points = {{-94, 22}, {-109, 22}}, color = {0, 0, 127})); connect(driver.V, velSens.v) annotation( Line(points = {{-120, 10.8}, {-120, -34}, {78, -34}, {78, -19}}, color = {0, 0, 127})); connect(mP1.flange_a, wheel.flangeT) annotation( Line(points = {{18, 22}, {12, 22}}, color = {0, 127, 0})); connect(gear.flange_b, wheel.flangeR) annotation( Line(points = {{-16, 22}, {-16, 22}, {-8, 22}})); connect(velSens.flange, mP2.flange_a) annotation( Line(points = {{78, 2}, {78, 22}, {104, 22}}, color = {0, 127, 0})); connect(mass.flange_a, mP1.flange_b) annotation( Line(points = {{46, 22}, {38, 22}}, color = {0, 127, 0})); connect(mP2.flange_a, mass.flange_b) annotation( Line(points = {{104, 22}, {66, 22}}, color = {0, 127, 0})); connect(dragF.flange, mP2.flange_b) annotation( Line(points = {{104, -18}, {104, 2}}, color = {0, 127, 0})); connect(motSpeed.flange, gear.flange_a) annotation( Line(points = {{-40, 10}, {-40, 22}, {-36, 22}}, color = {0, 0, 0})); connect(inertia.flange_a, torque.flange) annotation( Line(points = {{-64, 22}, {-68, 22}, {-72, 22}}, color = {0, 0, 0})); connect(inertia.flange_b, gear.flange_a) annotation( Line(points = {{-44, 22}, {-36, 22}}, color = {0, 0, 0})); annotation( experimentSetupOutput(derivatives = false), Documentation(info = ""

Modello Semplice di veicolo elettrico usato per l'esercitazione di SEB a.a. 2015-16.

OM 23136 OK

""), Commands, Icon(coordinateSystem(extent = {{-120, -60}, {120, 60}}, preserveAspectRatio = false, initialScale = 0.1, grid = {2, 2})), experiment(StartTime = 0, StopTime = 200, Tolerance = 0.0001, Interval = 0.1), Diagram(coordinateSystem(extent = {{-140, -40}, {120, 60}}, preserveAspectRatio = false, initialScale = 0.1, grid = {2, 2}))); end EVbasic; model PropDriver ""Simple Proportional controller driver"" parameter String CycleFileName = ""MyCycleName.txt"" ""Drive Cycle Name ex: \""sort1.txt\""""; parameter Real k(unit = ""N.m/(m/s)"") ""Controller gain""; parameter Real yMax(unit = ""N.m"") = 1000000.0 ""Max output value (absolute)""; parameter Modelica.Blocks.Types.Extrapolation extrapolation = Modelica.Blocks.Types.Extrapolation.HoldLastPoint; Modelica.Blocks.Interfaces.RealInput V annotation( Placement(transformation(extent = {{-14, -14}, {14, 14}}, rotation = 90, origin = {0, -114}), iconTransformation(extent = {{-12, -12}, {12, 12}}, rotation = 90, origin = {0, -112}))); Modelica.Blocks.Interfaces.RealOutput tauRef(unit = ""N.m"") annotation( Placement(transformation(extent = {{100, -10}, {120, 10}}), iconTransformation(extent = {{100, -10}, {120, 10}}))); Modelica.Blocks.Sources.CombiTimeTable driveCyc(columns = {2}, extrapolation = extrapolation, fileName = CycleFileName, tableName = ""Cycle"", tableOnFile = true) annotation( Placement(transformation(extent = {{-86, -10}, {-66, 10}}))); // fileName=Modelica.Utilities.Files.loadResource(""modelica://EVPkg1718eng/""+CycleFileName)) annotation ( Modelica.Blocks.Math.UnitConversions.From_kmh from_kmh annotation( Placement(transformation(extent = {{-48, -10}, {-28, 10}}))); Modelica.Blocks.Math.Feedback feedback annotation( Placement(transformation(extent = {{-10, -10}, {10, 10}}))); Modelica.Blocks.Math.Gain gain(k = k) annotation( Placement(transformation(extent = {{32, -10}, {52, 10}}))); Modelica.Blocks.Nonlinear.Limiter limiter(uMax = yMax) annotation( Placement(transformation(extent = {{70, -10}, {90, 10}}))); equation connect(from_kmh.u, driveCyc.y[1]) annotation( Line(points = {{-50, 0}, {-65, 0}}, color = {0, 0, 127}, smooth = Smooth.None)); connect(from_kmh.y, feedback.u1) annotation( Line(points = {{-27, 0}, {-8, 0}}, color = {0, 0, 127}, smooth = Smooth.None)); connect(feedback.u2, V) annotation( Line(points = {{0, -8}, {0, -114}, {1.77636e-015, -114}}, color = {0, 0, 127}, smooth = Smooth.None)); connect(feedback.y, gain.u) annotation( Line(points = {{9, 0}, {30, 0}}, color = {0, 0, 127}, smooth = Smooth.None)); connect(gain.y, limiter.u) annotation( Line(points = {{53, 0}, {68, 0}}, color = {0, 0, 127}, smooth = Smooth.None)); connect(tauRef, limiter.y) annotation( Line(points = {{110, 0}, {91, 0}}, color = {0, 0, 127}, smooth = Smooth.None)); annotation( Diagram(coordinateSystem(preserveAspectRatio = false, extent = {{-100, -100}, {100, 100}}), graphics), Documentation(info = ""

Modello semplice di pilota.

Esso contiene al suo interno il ciclo di riferimento, che insegue attraverso un regolatore solo proporzionale.

""), Icon(coordinateSystem(extent = {{-100, -100}, {100, 100}}, preserveAspectRatio = false, initialScale = 0.1, grid = {2, 2}), graphics = {Rectangle(fillColor = {255, 255, 255}, fillPattern = FillPattern.Solid, extent = {{-100, 100}, {100, -100}}), Ellipse(fillColor = {255, 213, 170}, fillPattern = FillPattern.Solid, extent = {{-23, 26}, {-12, 0}}, endAngle = 360), Text(origin = {0, 1.81063}, lineColor = {0, 0, 255}, extent = {{-104, 142.189}, {98, 104}}, textString = ""%name""), Polygon(fillColor = {215, 215, 215}, pattern = LinePattern.None, fillPattern = FillPattern.Solid, points = {{-22, -56}, {-42, -84}, {-16, -84}, {16, -84}, {-22, -56}}), Polygon(fillColor = {135, 135, 135}, pattern = LinePattern.None, fillPattern = FillPattern.Solid, points = {{-32, 44}, {-62, -48}, {-30, -48}, {-30, -48}, {-32, 44}}, smooth = Smooth.Bezier), Polygon(fillColor = {135, 135, 135}, pattern = LinePattern.None, fillPattern = FillPattern.Solid, points = {{-68, -32}, {-14, -86}, {10, -46}, {0, -46}, {-68, -32}}, smooth = Smooth.Bezier), Polygon(fillColor = {175, 175, 175}, fillPattern = FillPattern.Solid, points = {{-22, 14}, {-30, 10}, {-40, -44}, {2, -42}, {2, -30}, {0, 6}, {-22, 14}}, smooth = Smooth.Bezier), Ellipse(fillColor = {255, 213, 170}, fillPattern = FillPattern.Solid, extent = {{-30, 48}, {-3, 14}}, endAngle = 360), Polygon(pattern = LinePattern.None, fillPattern = FillPattern.Solid, points = {{-38, 38}, {-16, 54}, {-2, 40}, {4, 40}, {6, 40}, {-38, 38}}, smooth = Smooth.Bezier), Polygon(fillColor = {95, 95, 95}, fillPattern = FillPattern.Solid, points = {{30, -40}, {-32, -24}, {-36, -40}, {-24, -54}, {30, -40}}, smooth = Smooth.Bezier), Polygon(fillPattern = FillPattern.Solid, points = {{42, -66}, {36, -80}, {48, -74}, {52, -68}, {50, -64}, {42, -66}}, smooth = Smooth.Bezier), Line(points = {{48, -10}, {26, 4}, {26, 4}}, thickness = 0.5), Line(points = {{20, -6}, {34, 14}, {34, 14}}, thickness = 0.5), Polygon(fillColor = {255, 213, 170}, fillPattern = FillPattern.Solid, points = {{28, 8}, {32, 12}, {28, 6}, {34, 10}, {30, 6}, {34, 8}, {30, 4}, {26, 6}, {34, 4}, {26, 4}, {26, 6}, {28, 8}, {28, 8}, {26, 6}, {26, 6}, {26, 6}, {28, 12}, {28, 10}, {28, 8}}, smooth = Smooth.Bezier), Polygon(fillColor = {175, 175, 175}, fillPattern = FillPattern.Solid, points = {{-18, 4}, {28, 10}, {26, 2}, {-16, -12}, {-20, -12}, {-24, -2}, {-18, 4}}, smooth = Smooth.Bezier), Polygon(fillColor = {215, 215, 215}, fillPattern = FillPattern.Solid, points = {{72, -2}, {48, -2}, {36, -22}, {58, -82}, {72, -82}, {72, -2}}), Polygon(fillColor = {95, 95, 95}, fillPattern = FillPattern.Solid, points = {{49, -90}, {17, -36}, {7, -40}, {-1, -46}, {49, -90}}, smooth = Smooth.Bezier), Line(points = {{-7, 35}, {-3, 33}}), Line(points = {{-9, 22}, {-5, 22}}), Line(points = {{-7, 35}, {-3, 35}}), Text(extent = {{-82, 98}, {94, 58}}, lineColor = {238, 46, 47}, textString = ""%CycleFileName"")})); end PropDriver; model DragForce ""Vehicle rolling and aerodinamical drag force"" import Modelica.Constants.g_n; extends Modelica.Mechanics.Translational.Interfaces.PartialElementaryOneFlangeAndSupport2; extends Modelica.Mechanics.Translational.Interfaces.PartialFriction; Modelica.SIunits.Force f ""Total drag force""; Modelica.SIunits.Velocity v ""vehicle velocity""; Modelica.SIunits.Acceleration a ""Absolute acceleration of flange""; Real Sign; parameter Modelica.SIunits.Mass m ""vehicle mass""; parameter Modelica.SIunits.Density rho(start = 1.226) ""air density""; parameter Modelica.SIunits.Area S ""vehicle cross area""; parameter Real fc(start = 0.01) ""rolling friction coefficient""; parameter Real Cx ""aerodinamic drag coefficient""; final parameter Real A = fc * m * g_n; final parameter Real B = 1 / 2 * rho * S * Cx; final parameter Real mu[:, 2] = [0, 1]; Real debug = f - B * v ^ 2 * Sign; // Constant auxiliary variable equation // s = flange.s; v = der(s); a = der(v); // Le seguenti definizioni seguono l'ordine e le richieste del modello ""PartialFriction"" di // Modelica.Mechanics.Translational.Interfaces"" v_relfric = v; a_relfric = a; f0 = A ""Friction force for v_relfric=0 and forward sliding""; f0_max = A ""Maximum friction force for v_relfric=0 and locked""; free = false ""true when there is not wheel-road contact (never!)""; // Ora il calcolo di f, e la sua attribuzione alla flangia: flange.f - f = 0; // friction force if v > 0 then Sign = 1; else Sign = -1; end if; f - B * v ^ 2 * Sign = if locked then sa * unitForce else f0 * (if startForward then Modelica.Math.Vectors.interpolate(mu[:, 1], mu[:, 2], v) else if startBackward then -Modelica.Math.Vectors.interpolate(mu[:, 1], mu[:, 2], -v) else if pre(mode) == Forward then Modelica.Math.Vectors.interpolate(mu[:, 1], mu[:, 2], v) else -Modelica.Math.Vectors.interpolate(mu[:, 1], mu[:, 2], -v)); annotation( Documentation(info = ""

This component modesl the total (rolling and aerodynamic vehicle drag resistance:

F=fc*m*g+(1/2)*rho*Cx*S*v^2

It models reliably the stuck phase. Based on Modelica-Intrerfaces.PartialFriction model

""), Icon(coordinateSystem(preserveAspectRatio = true, extent = {{-100, -100}, {100, 100}}), graphics = {Polygon(points = {{-98, 10}, {22, 10}, {22, 41}, {92, 0}, {22, -41}, {22, -10}, {-98, -10}, {-98, 10}}, lineColor = {0, 127, 0}, fillColor = {215, 215, 215}, fillPattern = FillPattern.Solid), Line(points = {{-42, -50}, {87, -50}}, color = {0, 0, 0}), Polygon(points = {{-72, -50}, {-41, -40}, {-41, -60}, {-72, -50}}, lineColor = {0, 0, 0}, fillColor = {128, 128, 128}, fillPattern = FillPattern.Solid), Line(points = {{-90, -90}, {-70, -88}, {-50, -82}, {-30, -72}, {-10, -58}, {10, -40}, {30, -18}, {50, 8}, {70, 38}, {90, 72}, {110, 110}}, color = {0, 0, 255}, thickness = 0.5), Text(extent = {{-82, 90}, {80, 50}}, lineColor = {0, 0, 255}, textString = ""%name"")}), Diagram(coordinateSystem(preserveAspectRatio = true, extent = {{-100, -100}, {100, 100}}), graphics)); end DragForce; annotation( uses(Modelica(version = ""3.2.2""))); end Test; s2: package Test1 ""Package containing basic EV models"" model EVbasic ""Simulates a very basic Electric Vehicle"" import Modelica; DragForce dragF(Cx = 0.65, rho = 1.226, S = 6.0, fc = 0.013, m = mass.m) annotation( Placement(visible = true, transformation(origin = {104, -28}, extent = {{-10, -10}, {10, 10}}, rotation = 90))); Modelica.Mechanics.Rotational.Components.IdealGear gear(ratio = 6) annotation( Placement(visible = true, transformation(origin = {-26, 22}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Mechanics.Rotational.Sources.Torque torque annotation( Placement(visible = true, transformation(extent = {{-92, 12}, {-72, 32}}, rotation = 0))); PropDriver driver(k = 1000, yMax = 100000.0, CycleFileName = ""Sort1.txt"") annotation( Placement(visible = true, transformation(extent = {{-130, 12}, {-110, 32}}, rotation = 0))); Modelica.Mechanics.Translational.Sensors.PowerSensor mP2 annotation( Placement(visible = true, transformation(origin = {104, 12}, extent = {{-10, -10}, {10, 10}}, rotation = -90))); Modelica.Mechanics.Translational.Sensors.PowerSensor mP1 annotation( Placement(visible = true, transformation(origin = {28, 22}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Mechanics.Translational.Components.Mass mass(m = 16000) annotation( Placement(visible = true, transformation(extent = {{46, 12}, {66, 32}}, rotation = 0))); Modelica.Mechanics.Translational.Sensors.SpeedSensor velSens annotation( Placement(visible = true, transformation(origin = {78, -8}, extent = {{-10, -10}, {10, 10}}, rotation = 270))); Modelica.Mechanics.Rotational.Components.IdealRollingWheel wheel(radius = 0.5715) annotation( Placement(visible = true, transformation(extent = {{-8, 12}, {12, 32}}, rotation = 0))); Modelica.Mechanics.Rotational.Sensors.SpeedSensor motSpeed annotation( Placement(transformation(extent = {{-10, -10}, {10, 10}}, rotation = -90, origin = {-40, 0}))); Modelica.Mechanics.Rotational.Components.Inertia inertia(J = 5) annotation( Placement(transformation(extent = {{-64, 12}, {-44, 32}}))); equation connect(torque.tau, driver.tauRef) annotation( Line(points = {{-94, 22}, {-109, 22}}, color = {0, 0, 127})); connect(driver.V, velSens.v) annotation( Line(points = {{-120, 10.8}, {-120, -34}, {78, -34}, {78, -19}}, color = {0, 0, 127})); connect(mP1.flange_a, wheel.flangeT) annotation( Line(points = {{18, 22}, {12, 22}}, color = {0, 127, 0})); connect(gear.flange_b, wheel.flangeR) annotation( Line(points = {{-16, 22}, {-16, 22}, {-8, 22}})); connect(velSens.flange, mP2.flange_a) annotation( Line(points = {{78, 2}, {78, 22}, {104, 22}}, color = {0, 127, 0})); connect(mass.flange_a, mP1.flange_b) annotation( Line(points = {{46, 22}, {38, 22}}, color = {0, 127, 0})); connect(mP2.flange_a, mass.flange_b) annotation( Line(points = {{104, 22}, {66, 22}}, color = {0, 127, 0})); connect(dragF.flange, mP2.flange_b) annotation( Line(points = {{104, -18}, {104, 2}}, color = {0, 127, 0})); connect(motSpeed.flange, gear.flange_a) annotation( Line(points = {{-40, 10}, {-40, 22}, {-36, 22}}, color = {0, 0, 0})); connect(inertia.flange_a, torque.flange) annotation( Line(points = {{-64, 22}, {-68, 22}, {-72, 22}}, color = {0, 0, 0})); connect(inertia.flange_b, gear.flange_a) annotation( Line(points = {{-44, 22}, {-36, 22}}, color = {0, 0, 0})); annotation( experimentSetupOutput(derivatives = false), Documentation(info = ""

Modello Semplice di veicolo elettrico usato per l'esercitazione di SEB a.a. 2015-16.

OM 23136 OK

""), Commands, Icon(coordinateSystem(extent = {{-120, -60}, {120, 60}}, preserveAspectRatio = false, initialScale = 0.1, grid = {2, 2})), experiment(StartTime = 0, StopTime = 200, Tolerance = 0.0001, Interval = 0.1), Diagram(coordinateSystem(extent = {{-140, -40}, {120, 60}}, preserveAspectRatio = false, initialScale = 0.1, grid = {2, 2}))); end EVbasic; model PropDriver ""Simple Proportional controller driver"" parameter String CycleFileName = ""MyCycleName.txt"" ""Drive Cycle Name ex: \""sort1.txt\""""; parameter Real k(unit = ""N.m/(m/s)"") ""Controller gain""; parameter Real yMax(unit = ""N.m"") = 1000000.0 ""Max output value (absolute)""; parameter Modelica.Blocks.Types.Extrapolation extrapolation = Modelica.Blocks.Types.Extrapolation.HoldLastPoint; Modelica.Blocks.Interfaces.RealInput V annotation( Placement(transformation(extent = {{-14, -14}, {14, 14}}, rotation = 90, origin = {0, -114}), iconTransformation(extent = {{-12, -12}, {12, 12}}, rotation = 90, origin = {0, -112}))); Modelica.Blocks.Interfaces.RealOutput tauRef(unit = ""N.m"") annotation( Placement(transformation(extent = {{100, -10}, {120, 10}}), iconTransformation(extent = {{100, -10}, {120, 10}}))); Modelica.Blocks.Sources.CombiTimeTable driveCyc(columns = {2}, extrapolation = extrapolation, fileName = CycleFileName, tableName = ""Cycle"", tableOnFile = true) annotation( Placement(transformation(extent = {{-86, -10}, {-66, 10}}))); // fileName=Modelica.Utilities.Files.loadResource(""modelica://EVPkg1718eng/""+CycleFileName)) annotation ( Modelica.Blocks.Math.UnitConversions.From_kmh from_kmh annotation( Placement(transformation(extent = {{-48, -10}, {-28, 10}}))); Modelica.Blocks.Math.Feedback feedback annotation( Placement(transformation(extent = {{-10, -10}, {10, 10}}))); Modelica.Blocks.Math.Gain gain(k = k) annotation( Placement(transformation(extent = {{32, -10}, {52, 10}}))); Modelica.Blocks.Nonlinear.Limiter limiter(uMax = yMax) annotation( Placement(transformation(extent = {{70, -10}, {90, 10}}))); equation connect(from_kmh.u, driveCyc.y[1]) annotation( Line(points = {{-50, 0}, {-65, 0}}, color = {0, 0, 127}, smooth = Smooth.None)); connect(from_kmh.y, feedback.u1) annotation( Line(points = {{-27, 0}, {-8, 0}}, color = {0, 0, 127}, smooth = Smooth.None)); connect(feedback.u2, V) annotation( Line(points = {{0, -8}, {0, -114}, {1.77636e-015, -114}}, color = {0, 0, 127}, smooth = Smooth.None)); connect(feedback.y, gain.u) annotation( Line(points = {{9, 0}, {30, 0}}, color = {0, 0, 127}, smooth = Smooth.None)); connect(gain.y, limiter.u) annotation( Line(points = {{53, 0}, {68, 0}}, color = {0, 0, 127}, smooth = Smooth.None)); connect(tauRef, limiter.y) annotation( Line(points = {{110, 0}, {91, 0}}, color = {0, 0, 127}, smooth = Smooth.None)); annotation( Diagram(coordinateSystem(preserveAspectRatio = false, extent = {{-100, -100}, {100, 100}}), graphics), Documentation(info = ""

Modello semplice di pilota.

Esso contiene al suo interno il ciclo di riferimento, che insegue attraverso un regolatore solo proporzionale.

""), Icon(coordinateSystem(extent = {{-100, -100}, {100, 100}}, preserveAspectRatio = false, initialScale = 0.1, grid = {2, 2}), graphics = {Rectangle(fillColor = {255, 255, 255}, fillPattern = FillPattern.Solid, extent = {{-100, 100}, {100, -100}}), Ellipse(fillColor = {255, 213, 170}, fillPattern = FillPattern.Solid, extent = {{-23, 26}, {-12, 0}}, endAngle = 360), Text(origin = {0, 1.81063}, lineColor = {0, 0, 255}, extent = {{-104, 142.189}, {98, 104}}, textString = ""%name""), Polygon(fillColor = {215, 215, 215}, pattern = LinePattern.None, fillPattern = FillPattern.Solid, points = {{-22, -56}, {-42, -84}, {-16, -84}, {16, -84}, {-22, -56}}), Polygon(fillColor = {135, 135, 135}, pattern = LinePattern.None, fillPattern = FillPattern.Solid, points = {{-32, 44}, {-62, -48}, {-30, -48}, {-30, -48}, {-32, 44}}, smooth = Smooth.Bezier), Polygon(fillColor = {135, 135, 135}, pattern = LinePattern.None, fillPattern = FillPattern.Solid, points = {{-68, -32}, {-14, -86}, {10, -46}, {0, -46}, {-68, -32}}, smooth = Smooth.Bezier), Polygon(fillColor = {175, 175, 175}, fillPattern = FillPattern.Solid, points = {{-22, 14}, {-30, 10}, {-40, -44}, {2, -42}, {2, -30}, {0, 6}, {-22, 14}}, smooth = Smooth.Bezier), Ellipse(fillColor = {255, 213, 170}, fillPattern = FillPattern.Solid, extent = {{-30, 48}, {-3, 14}}, endAngle = 360), Polygon(pattern = LinePattern.None, fillPattern = FillPattern.Solid, points = {{-38, 38}, {-16, 54}, {-2, 40}, {4, 40}, {6, 40}, {-38, 38}}, smooth = Smooth.Bezier), Polygon(fillColor = {95, 95, 95}, fillPattern = FillPattern.Solid, points = {{30, -40}, {-32, -24}, {-36, -40}, {-24, -54}, {30, -40}}, smooth = Smooth.Bezier), Polygon(fillPattern = FillPattern.Solid, points = {{42, -66}, {36, -80}, {48, -74}, {52, -68}, {50, -64}, {42, -66}}, smooth = Smooth.Bezier), Line(points = {{48, -10}, {26, 4}, {26, 4}}, thickness = 0.5), Line(points = {{20, -6}, {34, 14}, {34, 14}}, thickness = 0.5), Polygon(fillColor = {255, 213, 170}, fillPattern = FillPattern.Solid, points = {{28, 8}, {32, 12}, {28, 6}, {34, 10}, {30, 6}, {34, 8}, {30, 4}, {26, 6}, {34, 4}, {26, 4}, {26, 6}, {28, 8}, {28, 8}, {26, 6}, {26, 6}, {26, 6}, {28, 12}, {28, 10}, {28, 8}}, smooth = Smooth.Bezier), Polygon(fillColor = {175, 175, 175}, fillPattern = FillPattern.Solid, points = {{-18, 4}, {28, 10}, {26, 2}, {-16, -12}, {-20, -12}, {-24, -2}, {-18, 4}}, smooth = Smooth.Bezier), Polygon(fillColor = {215, 215, 215}, fillPattern = FillPattern.Solid, points = {{72, -2}, {48, -2}, {36, -22}, {58, -82}, {72, -82}, {72, -2}}), Polygon(fillColor = {95, 95, 95}, fillPattern = FillPattern.Solid, points = {{49, -90}, {17, -36}, {7, -40}, {-1, -46}, {49, -90}}, smooth = Smooth.Bezier), Line(points = {{-7, 35}, {-3, 33}}), Line(points = {{-9, 22}, {-5, 22}}), Line(points = {{-7, 35}, {-3, 35}}), Text(extent = {{-82, 98}, {94, 58}}, lineColor = {238, 46, 47}, textString = ""%CycleFileName"")})); end PropDriver; model DragForce ""Vehicle rolling and aerodinamical drag force"" import Modelica.Constants.g_n; extends Modelica.Mechanics.Translational.Interfaces.PartialElementaryOneFlangeAndSupport2; extends Modelica.Mechanics.Translational.Interfaces.PartialFriction; Modelica.SIunits.Force f ""Total drag force""; Modelica.SIunits.Velocity v ""vehicle velocity""; Modelica.SIunits.Acceleration a ""Absolute acceleration of flange""; Real Sign; parameter Modelica.SIunits.Mass m ""vehicle mass""; parameter Modelica.SIunits.Density rho(start = 1.226) ""air density""; parameter Modelica.SIunits.Area S ""vehicle cross area""; parameter Real fc(start = 0.01) ""rolling friction coefficient""; parameter Real Cx ""aerodinamic drag coefficient""; final parameter Real A = fc * m * g_n; final parameter Real B = 1 / 2 * rho * S * Cx; final parameter Real mu[:, 2] = [0, 1]; Real debug = f - B * v ^ 2 * Sign; // Constant auxiliary variable equation // s = flange.s; v = der(s); a = der(v); // Le seguenti definizioni seguono l'ordine e le richieste del modello ""PartialFriction"" di // Modelica.Mechanics.Translational.Interfaces"" v_relfric = v; a_relfric = a; f0 = A ""Friction force for v_relfric=0 and forward sliding""; f0_max = A ""Maximum friction force for v_relfric=0 and locked""; free = false ""true when there is not wheel-road contact (never!)""; // Ora il calcolo di f, e la sua attribuzione alla flangia: flange.f - f = 0; // friction force if v > 0 then Sign = 1; else Sign = -1; end if; f - B * v ^ 2 * Sign = if locked then sa * unitForce else f0 * (if startForward then Modelica.Math.Vectors.interpolate(mu[:, 1], mu[:, 2], v) else if startBackward then -Modelica.Math.Vectors.interpolate(mu[:, 1], mu[:, 2], -v) else if pre(mode) == Forward then Modelica.Math.Vectors.interpolate(mu[:, 1], mu[:, 2], v) else -Modelica.Math.Vectors.interpolate(mu[:, 1], mu[:, 2], -v)); annotation( Documentation(info = ""

This component modesl the total (rolling and aerodynamic vehicle drag resistance:

F=fc*m*g+(1/2)*rho*Cx*S*v^2

It models reliably the stuck phase. Based on Modelica-Intrerfaces.PartialFriction model

""), Icon(coordinateSystem(preserveAspectRatio = true, extent = {{-100, -100}, {100, 100}}), graphics = {Polygon(points = {{-98, 10}, {22, 10}, {22, 41}, {92, 0}, {22, -41}, {22, -10}, {-98, -10}, {-98, 10}}, lineColor = {0, 127, 0}, fillColor = {215, 215, 215}, fillPattern = FillPattern.Solid), Line(points = {{-42, -50}, {87, -50}}, color = {0, 0, 0}), Polygon(points = {{-72, -50}, {-41, -40}, {-41, -60}, {-72, -50}}, lineColor = {0, 0, 0}, fillColor = {128, 128, 128}, fillPattern = FillPattern.Solid), Line(points = {{-90, -90}, {-70, -88}, {-50, -82}, {-30, -72}, {-10, -58}, {10, -40}, {30, -18}, {50, 8}, {70, 38}, {90, 72}, {110, 110}}, color = {0, 0, 255}, thickness = 0.5), Text(extent = {{-82, 90}, {80, 50}}, lineColor = {0, 0, 255}, textString = ""%name"")}), Diagram(coordinateSystem(preserveAspectRatio = true, extent = {{-100, -100}, {100, 100}}), graphics)); end DragForce; annotation( uses(Modelica(version = ""3.2.2""))); end Test1; s3: package Test1 ""Package containing basic EV models"" model EVbasic ""Simulates a very basic Electric Vehicle"" import Modelica; DragForce dragF(Cx = 0.65, rho = 1.226, S = 6.0, fc = 0.013, m = mass.m) annotation( Placement(visible = true, transformation(origin = {104, -28}, extent = {{-10, -10}, {10, 10}}, rotation = 90))); Modelica.Mechanics.Rotational.Components.IdealGear gear(ratio = 6) annotation( Placement(visible = true, transformation(origin = {-26, 22}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Mechanics.Rotational.Sources.Torque torque annotation( Placement(visible = true, transformation(extent = {{-92, 12}, {-72, 32}}, rotation = 0))); PropDriver driver(k = 1000, yMax = 100000.0, CycleFileName = ""Sort1.txt"") annotation( Placement(visible = true, transformation(extent = {{-130, 12}, {-110, 32}}, rotation = 0))); Modelica.Mechanics.Translational.Sensors.PowerSensor mP2 annotation( Placement(visible = true, transformation(origin = {104, 12}, extent = {{-10, -10}, {10, 10}}, rotation = -90))); Modelica.Mechanics.Translational.Sensors.PowerSensor mP1 annotation( Placement(visible = true, transformation(origin = {28, 22}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Mechanics.Translational.Components.Mass mass(m = 16000) annotation( Placement(visible = true, transformation(extent = {{46, 12}, {66, 32}}, rotation = 0))); Modelica.Mechanics.Translational.Sensors.SpeedSensor velSens annotation( Placement(visible = true, transformation(origin = {78, -8}, extent = {{-10, -10}, {10, 10}}, rotation = 270))); Modelica.Mechanics.Rotational.Components.IdealRollingWheel wheel(radius = 0.5715) annotation( Placement(visible = true, transformation(extent = {{-8, 12}, {12, 32}}, rotation = 0))); Modelica.Mechanics.Rotational.Sensors.SpeedSensor motSpeed annotation( Placement(transformation(extent = {{-10, -10}, {10, 10}}, rotation = -90, origin = {-40, 0}))); Modelica.Mechanics.Rotational.Components.Inertia inertia(J = 5) annotation( Placement(transformation(extent = {{-64, 12}, {-44, 32}}))); equation connect(torque.tau, driver.tauRef) annotation( Line(points = {{-94, 22}, {-109, 22}}, color = {0, 0, 127})); connect(driver.V, velSens.v) annotation( Line(points = {{-120, 10.8}, {-120, -34}, {78, -34}, {78, -19}}, color = {0, 0, 127})); connect(mP1.flange_a, wheel.flangeT) annotation( Line(points = {{18, 22}, {12, 22}}, color = {0, 127, 0})); connect(gear.flange_b, wheel.flangeR) annotation( Line(points = {{-16, 22}, {-16, 22}, {-8, 22}})); connect(velSens.flange, mP2.flange_a) annotation( Line(points = {{78, 2}, {78, 22}, {104, 22}}, color = {0, 127, 0})); connect(mass.flange_a, mP1.flange_b) annotation( Line(points = {{46, 22}, {38, 22}}, color = {0, 127, 0})); connect(mP2.flange_a, mass.flange_b) annotation( Line(points = {{104, 22}, {66, 22}}, color = {0, 127, 0})); connect(dragF.flange, mP2.flange_b) annotation( Line(points = {{104, -18}, {104, 2}}, color = {0, 127, 0})); connect(motSpeed.flange, gear.flange_a) annotation( Line(points = {{-40, 10}, {-40, 22}, {-36, 22}}, color = {0, 0, 0})); connect(inertia.flange_a, torque.flange) annotation( Line(points = {{-64, 22}, {-68, 22}, {-72, 22}}, color = {0, 0, 0})); connect(inertia.flange_b, gear.flange_a) annotation( Line(points = {{-44, 22}, {-36, 22}}, color = {0, 0, 0})); annotation( experimentSetupOutput(derivatives = false), Documentation(info = ""

Modello Semplice di veicolo elettrico usato per l'esercitazione di SEB a.a. 2015-16.

OM 23136 OK

""), Commands, Icon(coordinateSystem(extent = {{-120, -60}, {120, 60}}, preserveAspectRatio = false, initialScale = 0.1, grid = {2, 2})), experiment(StartTime = 0, StopTime = 200, Tolerance = 0.0001, Interval = 0.1), Diagram(coordinateSystem(extent = {{-140, -40}, {120, 60}}, preserveAspectRatio = false, initialScale = 0.1, grid = {2, 2}))); end EVbasic; model PropDriver ""Simple Proportional controller driver"" parameter String CycleFileName = ""MyCycleName.txt"" ""Drive Cycle Name ex: \""sort1.txt\""""; parameter Real k(unit = ""N.m/(m/s)"") ""Controller gain""; parameter Real yMax(unit = ""N.m"") = 1000000.0 ""Max output value (absolute)""; parameter Modelica.Blocks.Types.Extrapolation extrapolation = Modelica.Blocks.Types.Extrapolation.HoldLastPoint; Modelica.Blocks.Interfaces.RealInput V annotation( Placement(transformation(extent = {{-14, -14}, {14, 14}}, rotation = 90, origin = {0, -114}), iconTransformation(extent = {{-12, -12}, {12, 12}}, rotation = 90, origin = {0, -112}))); Modelica.Blocks.Interfaces.RealOutput tauRef(unit = ""N.m"") annotation( Placement(transformation(extent = {{100, -10}, {120, 10}}), iconTransformation(extent = {{100, -10}, {120, 10}}))); Modelica.Blocks.Sources.CombiTimeTable driveCyc(columns = {2}, extrapolation = extrapolation, fileName = CycleFileName, tableName = ""Cycle"", tableOnFile = true) annotation( Placement(transformation(extent = {{-86, -10}, {-66, 10}}))); // fileName=Modelica.Utilities.Files.loadResource(""modelica://EVPkg1718eng/""+CycleFileName)) annotation ( Modelica.Blocks.Math.UnitConversions.From_kmh from_kmh annotation( Placement(transformation(extent = {{-48, -10}, {-28, 10}}))); Modelica.Blocks.Math.Feedback feedback annotation( Placement(transformation(extent = {{-10, -10}, {10, 10}}))); Modelica.Blocks.Math.Gain gain(k = k) annotation( Placement(transformation(extent = {{32, -10}, {52, 10}}))); Modelica.Blocks.Nonlinear.Limiter limiter(uMax = yMax) annotation( Placement(transformation(extent = {{70, -10}, {90, 10}}))); equation connect(from_kmh.u, driveCyc.y[1]) annotation( Line(points = {{-50, 0}, {-65, 0}}, color = {0, 0, 127}, smooth = Smooth.None)); connect(from_kmh.y, feedback.u1) annotation( Line(points = {{-27, 0}, {-8, 0}}, color = {0, 0, 127}, smooth = Smooth.None)); connect(feedback.u2, V) annotation( Line(points = {{0, -8}, {0, -114}, {1.77636e-015, -114}}, color = {0, 0, 127}, smooth = Smooth.None)); connect(feedback.y, gain.u) annotation( Line(points = {{9, 0}, {30, 0}}, color = {0, 0, 127}, smooth = Smooth.None)); connect(gain.y, limiter.u) annotation( Line(points = {{53, 0}, {68, 0}}, color = {0, 0, 127}, smooth = Smooth.None)); connect(tauRef, limiter.y) annotation( Line(points = {{110, 0}, {91, 0}}, color = {0, 0, 127}, smooth = Smooth.None)); annotation( Diagram(coordinateSystem(preserveAspectRatio = false, extent = {{-100, -100}, {100, 100}}), graphics), Documentation(info = ""

Modello semplice di pilota.

Esso contiene al suo interno il ciclo di riferimento, che insegue attraverso un regolatore solo proporzionale.

""), Icon(coordinateSystem(extent = {{-100, -100}, {100, 100}}, preserveAspectRatio = false, initialScale = 0.1, grid = {2, 2}), graphics = {Rectangle(fillColor = {255, 255, 255}, fillPattern = FillPattern.Solid, extent = {{-100, 100}, {100, -100}}), Ellipse(fillColor = {255, 213, 170}, fillPattern = FillPattern.Solid, extent = {{-23, 26}, {-12, 0}}, endAngle = 360), Text(origin = {0, 1.81063}, lineColor = {0, 0, 255}, extent = {{-104, 142.189}, {98, 104}}, textString = ""%name""), Polygon(fillColor = {215, 215, 215}, pattern = LinePattern.None, fillPattern = FillPattern.Solid, points = {{-22, -56}, {-42, -84}, {-16, -84}, {16, -84}, {-22, -56}}), Polygon(fillColor = {135, 135, 135}, pattern = LinePattern.None, fillPattern = FillPattern.Solid, points = {{-32, 44}, {-62, -48}, {-30, -48}, {-30, -48}, {-32, 44}}, smooth = Smooth.Bezier), Polygon(fillColor = {135, 135, 135}, pattern = LinePattern.None, fillPattern = FillPattern.Solid, points = {{-68, -32}, {-14, -86}, {10, -46}, {0, -46}, {-68, -32}}, smooth = Smooth.Bezier), Polygon(fillColor = {175, 175, 175}, fillPattern = FillPattern.Solid, points = {{-22, 14}, {-30, 10}, {-40, -44}, {2, -42}, {2, -30}, {0, 6}, {-22, 14}}, smooth = Smooth.Bezier), Ellipse(fillColor = {255, 213, 170}, fillPattern = FillPattern.Solid, extent = {{-30, 48}, {-3, 14}}, endAngle = 360), Polygon(pattern = LinePattern.None, fillPattern = FillPattern.Solid, points = {{-38, 38}, {-16, 54}, {-2, 40}, {4, 40}, {6, 40}, {-38, 38}}, smooth = Smooth.Bezier), Polygon(fillColor = {95, 95, 95}, fillPattern = FillPattern.Solid, points = {{30, -40}, {-32, -24}, {-36, -40}, {-24, -54}, {30, -40}}, smooth = Smooth.Bezier), Polygon(fillPattern = FillPattern.Solid, points = {{42, -66}, {36, -80}, {48, -74}, {52, -68}, {50, -64}, {42, -66}}, smooth = Smooth.Bezier), Line(points = {{48, -10}, {26, 4}, {26, 4}}, thickness = 0.5), Line(points = {{20, -6}, {34, 14}, {34, 14}}, thickness = 0.5), Polygon(fillColor = {255, 213, 170}, fillPattern = FillPattern.Solid, points = {{28, 8}, {32, 12}, {28, 6}, {34, 10}, {30, 6}, {34, 8}, {30, 4}, {26, 6}, {34, 4}, {26, 4}, {26, 6}, {28, 8}, {28, 8}, {26, 6}, {26, 6}, {26, 6}, {28, 12}, {28, 10}, {28, 8}}, smooth = Smooth.Bezier), Polygon(fillColor = {175, 175, 175}, fillPattern = FillPattern.Solid, points = {{-18, 4}, {28, 10}, {26, 2}, {-16, -12}, {-20, -12}, {-24, -2}, {-18, 4}}, smooth = Smooth.Bezier), Polygon(fillColor = {215, 215, 215}, fillPattern = FillPattern.Solid, points = {{72, -2}, {48, -2}, {36, -22}, {58, -82}, {72, -82}, {72, -2}}), Polygon(fillColor = {95, 95, 95}, fillPattern = FillPattern.Solid, points = {{49, -90}, {17, -36}, {7, -40}, {-1, -46}, {49, -90}}, smooth = Smooth.Bezier), Line(points = {{-7, 35}, {-3, 33}}), Line(points = {{-9, 22}, {-5, 22}}), Line(points = {{-7, 35}, {-3, 35}}), Text(extent = {{-82, 98}, {94, 58}}, lineColor = {238, 46, 47}, textString = ""%CycleFileName"")})); end PropDriver; model DragForce ""Vehicle rolling and aerodinamical drag force"" import Modelica.Constants.g_n; extends Modelica.Mechanics.Translational.Interfaces.PartialElementaryOneFlangeAndSupport2; extends Modelica.Mechanics.Translational.Interfaces.PartialFriction; Modelica.SIunits.Force f ""Total drag force""; Modelica.SIunits.Velocity v ""vehicle velocity""; Modelica.SIunits.Acceleration a ""Absolute acceleration of flange""; Real Sign; parameter Modelica.SIunits.Mass m ""vehicle mass""; parameter Modelica.SIunits.Density rho(start = 1.226) ""air density""; parameter Modelica.SIunits.Area S ""vehicle cross area""; parameter Real fc(start = 0.01) ""rolling friction coefficient""; parameter Real Cx ""aerodinamic drag coefficient""; final parameter Real A = fc * m * g_n; final parameter Real B = 1 / 2 * rho * S * Cx; final parameter Real mu[:, 2] = [0, 1]; Real debug = f - B * v ^ 2 * Sign; // Constant auxiliary variable equation // s = flange.s; v = der(s); a = der(v); // Le seguenti definizioni seguono l'ordine e le richieste del modello ""PartialFriction"" di // Modelica.Mechanics.Translational.Interfaces"" v_relfric = v; a_relfric = a; f0 = A ""Friction force for v_relfric=0 and forward sliding""; f0_max = A ""Maximum friction force for v_relfric=0 and locked""; free = false ""true when there is not wheel-road contact (never!)""; // Ora il calcolo di f, e la sua attribuzione alla flangia: flange.f - f = 0; // friction force if v > 0 then Sign = 1; else Sign = -1; end if; f - B * v ^ 2 * Sign = if locked then sa * unitForce else f0 * (if startForward then Modelica.Math.Vectors.interpolate(mu[:, 1], mu[:, 2], v) else if startBackward then -Modelica.Math.Vectors.interpolate(mu[:, 1], mu[:, 2], -v) else if pre(mode) == Forward then Modelica.Math.Vectors.interpolate(mu[:, 1], mu[:, 2], v) else -Modelica.Math.Vectors.interpolate(mu[:, 1], mu[:, 2], -v)); annotation( Documentation(info = ""

This component modesl the total (rolling and aerodynamic vehicle drag resistance:

F=fc*m*g+(1/2)*rho*Cx*S*v^2

It models reliably the stuck phase. Based on Modelica-Intrerfaces.PartialFriction model

""), Icon(coordinateSystem(preserveAspectRatio = true, extent = {{-100, -100}, {100, 100}}), graphics = {Polygon(points = {{-98, 10}, {22, 10}, {22, 41}, {92, 0}, {22, -41}, {22, -10}, {-98, -10}, {-98, 10}}, lineColor = {0, 127, 0}, fillColor = {215, 215, 215}, fillPattern = FillPattern.Solid), Line(points = {{-42, -50}, {87, -50}}, color = {0, 0, 0}), Polygon(points = {{-72, -50}, {-41, -40}, {-41, -60}, {-72, -50}}, lineColor = {0, 0, 0}, fillColor = {128, 128, 128}, fillPattern = FillPattern.Solid), Line(points = {{-90, -90}, {-70, -88}, {-50, -82}, {-30, -72}, {-10, -58}, {10, -40}, {30, -18}, {50, 8}, {70, 38}, {90, 72}, {110, 110}}, color = {0, 0, 255}, thickness = 0.5), Text(extent = {{-82, 90}, {80, 50}}, lineColor = {0, 0, 255}, textString = ""%name"")}), Diagram(coordinateSystem(preserveAspectRatio = true, extent = {{-100, -100}, {100, 100}}), graphics)); end DragForce; annotation( uses(Modelica(version = ""3.2.2""))); end Test1; s4: package Test1 ""Package containing basic EV models"" model EVbasic ""Simulates a very basic Electric Vehicle"" import Modelica; DragForce dragF(Cx = 0.65, rho = 1.226, S = 6.0, fc = 0.013, m = mass.m) annotation( Placement(visible = true, transformation(origin = {104, -28}, extent = {{-10, -10}, {10, 10}}, rotation = 90))); Modelica.Mechanics.Rotational.Components.IdealGear gear(ratio = 6) annotation( Placement(visible = true, transformation(origin = {-26, 22}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Mechanics.Rotational.Sources.Torque torque annotation( Placement(visible = true, transformation(extent = {{-92, 12}, {-72, 32}}, rotation = 0))); PropDriver driver(k = 1000, yMax = 100000.0, CycleFileName = ""Sort1.txt"") annotation( Placement(visible = true, transformation(extent = {{-130, 12}, {-110, 32}}, rotation = 0))); Modelica.Mechanics.Translational.Sensors.PowerSensor mP2 annotation( Placement(visible = true, transformation(origin = {104, 12}, extent = {{-10, -10}, {10, 10}}, rotation = -90))); Modelica.Mechanics.Translational.Sensors.PowerSensor mP1 annotation( Placement(visible = true, transformation(origin = {28, 22}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Mechanics.Translational.Components.Mass mass(m = 16000) annotation( Placement(visible = true, transformation(extent = {{46, 12}, {66, 32}}, rotation = 0))); Modelica.Mechanics.Translational.Sensors.SpeedSensor velSens annotation( Placement(visible = true, transformation(origin = {78, -8}, extent = {{-10, -10}, {10, 10}}, rotation = 270))); Modelica.Mechanics.Rotational.Components.IdealRollingWheel wheel(radius = 0.5715) annotation( Placement(visible = true, transformation(extent = {{-8, 12}, {12, 32}}, rotation = 0))); Modelica.Mechanics.Rotational.Sensors.SpeedSensor motSpeed annotation( Placement(transformation(extent = {{-10, -10}, {10, 10}}, rotation = -90, origin = {-40, 0}))); Modelica.Mechanics.Rotational.Components.Inertia inertia(J = 5) annotation( Placement(transformation(extent = {{-64, 12}, {-44, 32}}))); equation connect(torque.tau, driver.tauRef) annotation( Line(points = {{-94, 22}, {-109, 22}}, color = {0, 0, 127})); connect(driver.V, velSens.v) annotation( Line(points = {{-120, 10.8}, {-120, -34}, {78, -34}, {78, -19}}, color = {0, 0, 127})); connect(mP1.flange_a, wheel.flangeT) annotation( Line(points = {{18, 22}, {12, 22}}, color = {0, 127, 0})); connect(gear.flange_b, wheel.flangeR) annotation( Line(points = {{-16, 22}, {-16, 22}, {-8, 22}})); connect(velSens.flange, mP2.flange_a) annotation( Line(points = {{78, 2}, {78, 22}, {104, 22}}, color = {0, 127, 0})); connect(mass.flange_a, mP1.flange_b) annotation( Line(points = {{46, 22}, {38, 22}}, color = {0, 127, 0})); connect(mP2.flange_a, mass.flange_b) annotation( Line(points = {{104, 22}, {66, 22}}, color = {0, 127, 0})); connect(dragF.flange, mP2.flange_b) annotation( Line(points = {{104, -18}, {104, 2}}, color = {0, 127, 0})); connect(motSpeed.flange, gear.flange_a) annotation( Line(points = {{-40, 10}, {-40, 22}, {-36, 22}}, color = {0, 0, 0})); connect(inertia.flange_a, torque.flange) annotation( Line(points = {{-64, 22}, {-68, 22}, {-72, 22}}, color = {0, 0, 0})); connect(inertia.flange_b, gear.flange_a) annotation( Line(points = {{-44, 22}, {-36, 22}}, color = {0, 0, 0})); annotation( experimentSetupOutput(derivatives = false), Documentation(info = ""

Modello Semplice di veicolo elettrico usato per l'esercitazione di SEB a.a. 2015-16.

OM 23136 OK

""), Commands, Icon(coordinateSystem(extent = {{-120, -60}, {120, 60}}, preserveAspectRatio = false, initialScale = 0.1, grid = {2, 2})), experiment(StartTime = 0, StopTime = 200, Tolerance = 0.0001, Interval = 0.1), Diagram(coordinateSystem(extent = {{-140, -40}, {120, 60}}, preserveAspectRatio = false, initialScale = 0.1, grid = {2, 2}))); end EVbasic; model PropDriver ""Simple Proportional controller driver"" parameter String CycleFileName = ""MyCycleName.txt"" ""Drive Cycle Name ex: \""sort1.txt\""""; parameter Real k(unit = ""N.m/(m/s)"") ""Controller gain""; parameter Real yMax(unit = ""N.m"") = 1000000.0 ""Max output value (absolute)""; parameter Modelica.Blocks.Types.Extrapolation extrapolation = Modelica.Blocks.Types.Extrapolation.HoldLastPoint; Modelica.Blocks.Interfaces.RealInput V annotation( Placement(transformation(extent = {{-14, -14}, {14, 14}}, rotation = 90, origin = {0, -114}), iconTransformation(extent = {{-12, -12}, {12, 12}}, rotation = 90, origin = {0, -112}))); Modelica.Blocks.Interfaces.RealOutput tauRef(unit = ""N.m"") annotation( Placement(transformation(extent = {{100, -10}, {120, 10}}), iconTransformation(extent = {{100, -10}, {120, 10}}))); Modelica.Blocks.Sources.CombiTimeTable driveCyc(columns = {2}, extrapolation = extrapolation, fileName = CycleFileName, tableName = ""Cycle"", tableOnFile = true) annotation( Placement(transformation(extent = {{-86, -10}, {-66, 10}}))); // fileName=Modelica.Utilities.Files.loadResource(""modelica://EVPkg1718eng/""+CycleFileName)) annotation ( Modelica.Blocks.Math.UnitConversions.From_kmh from_kmh annotation( Placement(transformation(extent = {{-48, -10}, {-28, 10}}))); Modelica.Blocks.Math.Feedback feedback annotation( Placement(transformation(extent = {{-10, -10}, {10, 10}}))); Modelica.Blocks.Math.Gain gain(k = k) annotation( Placement(transformation(extent = {{32, -10}, {52, 10}}))); Modelica.Blocks.Nonlinear.Limiter limiter(uMax = yMax) annotation( Placement(transformation(extent = {{70, -10}, {90, 10}}))); equation connect(from_kmh.u, driveCyc.y[1]) annotation( Line(points = {{-50, 0}, {-65, 0}}, color = {0, 0, 127}, smooth = Smooth.None)); connect(from_kmh.y, feedback.u1) annotation( Line(points = {{-27, 0}, {-8, 0}}, color = {0, 0, 127}, smooth = Smooth.None)); connect(feedback.u2, V) annotation( Line(points = {{0, -8}, {0, -114}, {1.77636e-015, -114}}, color = {0, 0, 127}, smooth = Smooth.None)); connect(feedback.y, gain.u) annotation( Line(points = {{9, 0}, {30, 0}}, color = {0, 0, 127}, smooth = Smooth.None)); connect(gain.y, limiter.u) annotation( Line(points = {{53, 0}, {68, 0}}, color = {0, 0, 127}, smooth = Smooth.None)); connect(tauRef, limiter.y) annotation( Line(points = {{110, 0}, {91, 0}}, color = {0, 0, 127}, smooth = Smooth.None)); annotation( Diagram(coordinateSystem(preserveAspectRatio = false, extent = {{-100, -100}, {100, 100}}), graphics), Documentation(info = ""

Modello semplice di pilota.

Esso contiene al suo interno il ciclo di riferimento, che insegue attraverso un regolatore solo proporzionale.

""), Icon(coordinateSystem(extent = {{-100, -100}, {100, 100}}, preserveAspectRatio = false, initialScale = 0.1, grid = {2, 2}), graphics = {Rectangle(fillColor = {255, 255, 255}, fillPattern = FillPattern.Solid, extent = {{-100, 100}, {100, -100}}), Ellipse(fillColor = {255, 213, 170}, fillPattern = FillPattern.Solid, extent = {{-23, 26}, {-12, 0}}, endAngle = 360), Text(origin = {0, 1.81063}, lineColor = {0, 0, 255}, extent = {{-104, 142.189}, {98, 104}}, textString = ""%name""), Polygon(fillColor = {215, 215, 215}, pattern = LinePattern.None, fillPattern = FillPattern.Solid, points = {{-22, -56}, {-42, -84}, {-16, -84}, {16, -84}, {-22, -56}}), Polygon(fillColor = {135, 135, 135}, pattern = LinePattern.None, fillPattern = FillPattern.Solid, points = {{-32, 44}, {-62, -48}, {-30, -48}, {-30, -48}, {-32, 44}}, smooth = Smooth.Bezier), Polygon(fillColor = {135, 135, 135}, pattern = LinePattern.None, fillPattern = FillPattern.Solid, points = {{-68, -32}, {-14, -86}, {10, -46}, {0, -46}, {-68, -32}}, smooth = Smooth.Bezier), Polygon(fillColor = {175, 175, 175}, fillPattern = FillPattern.Solid, points = {{-22, 14}, {-30, 10}, {-40, -44}, {2, -42}, {2, -30}, {0, 6}, {-22, 14}}, smooth = Smooth.Bezier), Ellipse(fillColor = {255, 213, 170}, fillPattern = FillPattern.Solid, extent = {{-30, 48}, {-3, 14}}, endAngle = 360), Polygon(pattern = LinePattern.None, fillPattern = FillPattern.Solid, points = {{-38, 38}, {-16, 54}, {-2, 40}, {4, 40}, {6, 40}, {-38, 38}}, smooth = Smooth.Bezier), Polygon(fillColor = {95, 95, 95}, fillPattern = FillPattern.Solid, points = {{30, -40}, {-32, -24}, {-36, -40}, {-24, -54}, {30, -40}}, smooth = Smooth.Bezier), Polygon(fillPattern = FillPattern.Solid, points = {{42, -66}, {36, -80}, {48, -74}, {52, -68}, {50, -64}, {42, -66}}, smooth = Smooth.Bezier), Line(points = {{48, -10}, {26, 4}, {26, 4}}, thickness = 0.5), Line(points = {{20, -6}, {34, 14}, {34, 14}}, thickness = 0.5), Polygon(fillColor = {255, 213, 170}, fillPattern = FillPattern.Solid, points = {{28, 8}, {32, 12}, {28, 6}, {34, 10}, {30, 6}, {34, 8}, {30, 4}, {26, 6}, {34, 4}, {26, 4}, {26, 6}, {28, 8}, {28, 8}, {26, 6}, {26, 6}, {26, 6}, {28, 12}, {28, 10}, {28, 8}}, smooth = Smooth.Bezier), Polygon(fillColor = {175, 175, 175}, fillPattern = FillPattern.Solid, points = {{-18, 4}, {28, 10}, {26, 2}, {-16, -12}, {-20, -12}, {-24, -2}, {-18, 4}}, smooth = Smooth.Bezier), Polygon(fillColor = {215, 215, 215}, fillPattern = FillPattern.Solid, points = {{72, -2}, {48, -2}, {36, -22}, {58, -82}, {72, -82}, {72, -2}}), Polygon(fillColor = {95, 95, 95}, fillPattern = FillPattern.Solid, points = {{49, -90}, {17, -36}, {7, -40}, {-1, -46}, {49, -90}}, smooth = Smooth.Bezier), Line(points = {{-7, 35}, {-3, 33}}), Line(points = {{-9, 22}, {-5, 22}}), Line(points = {{-7, 35}, {-3, 35}}), Text(extent = {{-82, 98}, {94, 58}}, lineColor = {238, 46, 47}, textString = ""%CycleFileName"")})); end PropDriver; model DragForce ""Vehicle rolling and aerodinamical drag force"" import Modelica.Constants.g_n; extends Modelica.Mechanics.Translational.Interfaces.PartialElementaryOneFlangeAndSupport2; extends Modelica.Mechanics.Translational.Interfaces.PartialFriction; Modelica.SIunits.Force f ""Total drag force""; Modelica.SIunits.Velocity v ""vehicle velocity""; Modelica.SIunits.Acceleration a ""Absolute acceleration of flange""; Real Sign; parameter Modelica.SIunits.Mass m ""vehicle mass""; parameter Modelica.SIunits.Density rho(start = 1.226) ""air density""; parameter Modelica.SIunits.Area S ""vehicle cross area""; parameter Real fc(start = 0.01) ""rolling friction coefficient""; parameter Real Cx ""aerodinamic drag coefficient""; final parameter Real A = fc * m * g_n; final parameter Real B = 1 / 2 * rho * S * Cx; final parameter Real mu[:, 2] = [0, 1]; Real debug = f - B * v ^ 2 * Sign; // Constant auxiliary variable equation // s = flange.s; v = der(s); a = der(v); // Le seguenti definizioni seguono l'ordine e le richieste del modello ""PartialFriction"" di // Modelica.Mechanics.Translational.Interfaces"" v_relfric = v; a_relfric = a; f0 = A ""Friction force for v_relfric=0 and forward sliding""; f0_max = A ""Maximum friction force for v_relfric=0 and locked""; free = false ""true when there is not wheel-road contact (never!)""; // Ora il calcolo di f, e la sua attribuzione alla flangia: flange.f - f = 0; // friction force if v > 0 then Sign = 1; else Sign = -1; end if; f - B * v ^ 2 * Sign = if locked then sa * unitForce else f0 * (if startForward then Modelica.Math.Vectors.interpolate(mu[:, 1], mu[:, 2], v) else if startBackward then -Modelica.Math.Vectors.interpolate(mu[:, 1], mu[:, 2], -v) else if pre(mode) == Forward then Modelica.Math.Vectors.interpolate(mu[:, 1], mu[:, 2], v) else -Modelica.Math.Vectors.interpolate(mu[:, 1], mu[:, 2], -v)); annotation( Documentation(info = ""

This component modesl the total (rolling and aerodynamic vehicle drag resistance:

F=fc*m*g+(1/2)*rho*Cx*S*v^2

It models reliably the stuck phase. Based on Modelica-Intrerfaces.PartialFriction model

""), Icon(coordinateSystem(preserveAspectRatio = true, extent = {{-100, -100}, {100, 100}}), graphics = {Polygon(points = {{-98, 10}, {22, 10}, {22, 41}, {92, 0}, {22, -41}, {22, -10}, {-98, -10}, {-98, 10}}, lineColor = {0, 127, 0}, fillColor = {215, 215, 215}, fillPattern = FillPattern.Solid), Line(points = {{-42, -50}, {87, -50}}, color = {0, 0, 0}), Polygon(points = {{-72, -50}, {-41, -40}, {-41, -60}, {-72, -50}}, lineColor = {0, 0, 0}, fillColor = {128, 128, 128}, fillPattern = FillPattern.Solid), Line(points = {{-90, -90}, {-70, -88}, {-50, -82}, {-30, -72}, {-10, -58}, {10, -40}, {30, -18}, {50, 8}, {70, 38}, {90, 72}, {110, 110}}, color = {0, 0, 255}, thickness = 0.5), Text(extent = {{-82, 90}, {80, 50}}, lineColor = {0, 0, 255}, textString = ""%name"")}), Diagram(coordinateSystem(preserveAspectRatio = true, extent = {{-100, -100}, {100, 100}}), graphics)); end DragForce; annotation( uses(Modelica(version = ""3.2.2""))); end Test1; s5: package Test1 ""Package containing basic EV models"" model EVbasic ""Simulates a very basic Electric Vehicle"" import Modelica; DragForce dragF(Cx = 0.65, rho = 1.226, S = 6.0, fc = 0.013, m = mass.m) annotation( Placement(visible = true, transformation(origin = {104, -28}, extent = {{-10, -10}, {10, 10}}, rotation = 90))); Modelica.Mechanics.Rotational.Components.IdealGear gear(ratio = 6) annotation( Placement(visible = true, transformation(origin = {-26, 22}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Mechanics.Rotational.Sources.Torque torque annotation( Placement(visible = true, transformation(extent = {{-92, 12}, {-72, 32}}, rotation = 0))); PropDriver driver(k = 1000, yMax = 100000.0, CycleFileName = ""Sort1.txt"") annotation( Placement(visible = true, transformation(extent = {{-130, 12}, {-110, 32}}, rotation = 0))); Modelica.Mechanics.Translational.Sensors.PowerSensor mP2 annotation( Placement(visible = true, transformation(origin = {104, 12}, extent = {{-10, -10}, {10, 10}}, rotation = -90))); Modelica.Mechanics.Translational.Sensors.PowerSensor mP1 annotation( Placement(visible = true, transformation(origin = {28, 22}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); Modelica.Mechanics.Translational.Components.Mass mass(m = 16000) annotation( Placement(visible = true, transformation(extent = {{46, 12}, {66, 32}}, rotation = 0))); Modelica.Mechanics.Translational.Sensors.SpeedSensor velSens annotation( Placement(visible = true, transformation(origin = {78, -8}, extent = {{-10, -10}, {10, 10}}, rotation = 270))); Modelica.Mechanics.Rotational.Components.IdealRollingWheel wheel(radius = 0.5715) annotation( Placement(visible = true, transformation(extent = {{-8, 12}, {12, 32}}, rotation = 0))); Modelica.Mechanics.Rotational.Sensors.SpeedSensor motSpeed annotation( Placement(transformation(extent = {{-10, -10}, {10, 10}}, rotation = -90, origin = {-40, 0}))); Modelica.Mechanics.Rotational.Components.Inertia inertia(J = 5) annotation( Placement(transformation(extent = {{-64, 12}, {-44, 32}}))); equation connect(torque.tau, driver.tauRef) annotation( Line(points = {{-94, 22}, {-109, 22}}, color = {0, 0, 127})); connect(driver.V, velSens.v) annotation( Line(points = {{-120, 10.8}, {-120, -34}, {78, -34}, {78, -19}}, color = {0, 0, 127})); connect(mP1.flange_a, wheel.flangeT) annotation( Line(points = {{18, 22}, {12, 22}}, color = {0, 127, 0})); connect(gear.flange_b, wheel.flangeR) annotation( Line(points = {{-16, 22}, {-16, 22}, {-8, 22}})); connect(velSens.flange, mP2.flange_a) annotation( Line(points = {{78, 2}, {78, 22}, {104, 22}}, color = {0, 127, 0})); connect(mass.flange_a, mP1.flange_b) annotation( Line(points = {{46, 22}, {38, 22}}, color = {0, 127, 0})); connect(mP2.flange_a, mass.flange_b) annotation( Line(points = {{104, 22}, {66, 22}}, color = {0, 127, 0})); connect(dragF.flange, mP2.flange_b) annotation( Line(points = {{104, -18}, {104, 2}}, color = {0, 127, 0})); connect(motSpeed.flange, gear.flange_a) annotation( Line(points = {{-40, 10}, {-40, 22}, {-36, 22}}, color = {0, 0, 0})); connect(inertia.flange_a, torque.flange) annotation( Line(points = {{-64, 22}, {-68, 22}, {-72, 22}}, color = {0, 0, 0})); connect(inertia.flange_b, gear.flange_a) annotation( Line(points = {{-44, 22}, {-36, 22}}, color = {0, 0, 0})); annotation( experimentSetupOutput(derivatives = false), Documentation(info = ""

Modello Semplice di veicolo elettrico usato per l'esercitazione di SEB a.a. 2015-16.

OM 23136 OK

""), Commands, Icon(coordinateSystem(extent = {{-120, -60}, {120, 60}}, preserveAspectRatio = false, initialScale = 0.1, grid = {2, 2})), experiment(StartTime = 0, StopTime = 200, Tolerance = 0.0001, Interval = 0.1), Diagram(coordinateSystem(extent = {{-140, -40}, {120, 60}}, preserveAspectRatio = false, initialScale = 0.1, grid = {2, 2}))); end EVbasic; model PropDriver ""Simple Proportional controller driver"" parameter String CycleFileName = ""MyCycleName.txt"" ""Drive Cycle Name ex: \""sort1.txt\""""; parameter Real k(unit = ""N.m/(m/s)"") ""Controller gain""; parameter Real yMax(unit = ""N.m"") = 1000000.0 ""Max output value (absolute)""; parameter Modelica.Blocks.Types.Extrapolation extrapolation = Modelica.Blocks.Types.Extrapolation.HoldLastPoint; Modelica.Blocks.Interfaces.RealInput V annotation( Placement(transformation(extent = {{-14, -14}, {14, 14}}, rotation = 90, origin = {0, -114}), iconTransformation(extent = {{-12, -12}, {12, 12}}, rotation = 90, origin = {0, -112}))); Modelica.Blocks.Interfaces.RealOutput tauRef(unit = ""N.m"") annotation( Placement(transformation(extent = {{100, -10}, {120, 10}}), iconTransformation(extent = {{100, -10}, {120, 10}}))); Modelica.Blocks.Sources.CombiTimeTable driveCyc(columns = {2}, extrapolation = extrapolation, fileName = CycleFileName, tableName = ""Cycle"", tableOnFile = true) annotation( Placement(transformation(extent = {{-86, -10}, {-66, 10}}))); // fileName=Modelica.Utilities.Files.loadResource(""modelica://EVPkg1718eng/""+CycleFileName)) annotation ( Modelica.Blocks.Math.UnitConversions.From_kmh from_kmh annotation( Placement(transformation(extent = {{-48, -10}, {-28, 10}}))); Modelica.Blocks.Math.Feedback feedback annotation( Placement(transformation(extent = {{-10, -10}, {10, 10}}))); Modelica.Blocks.Math.Gain gain(k = k) annotation( Placement(transformation(extent = {{32, -10}, {52, 10}}))); Modelica.Blocks.Nonlinear.Limiter limiter(uMax = yMax) annotation( Placement(transformation(extent = {{70, -10}, {90, 10}}))); equation connect(from_kmh.u, driveCyc.y[1]) annotation( Line(points = {{-50, 0}, {-65, 0}}, color = {0, 0, 127}, smooth = Smooth.None)); connect(from_kmh.y, feedback.u1) annotation( Line(points = {{-27, 0}, {-8, 0}}, color = {0, 0, 127}, smooth = Smooth.None)); connect(feedback.u2, V) annotation( Line(points = {{0, -8}, {0, -114}, {1.77636e-015, -114}}, color = {0, 0, 127}, smooth = Smooth.None)); connect(feedback.y, gain.u) annotation( Line(points = {{9, 0}, {30, 0}}, color = {0, 0, 127}, smooth = Smooth.None)); connect(gain.y, limiter.u) annotation( Line(points = {{53, 0}, {68, 0}}, color = {0, 0, 127}, smooth = Smooth.None)); connect(tauRef, limiter.y) annotation( Line(points = {{110, 0}, {91, 0}}, color = {0, 0, 127}, smooth = Smooth.None)); annotation( Diagram(coordinateSystem(preserveAspectRatio = false, extent = {{-100, -100}, {100, 100}}), graphics), Documentation(info = ""

Modello semplice di pilota.

Esso contiene al suo interno il ciclo di riferimento, che insegue attraverso un regolatore solo proporzionale.

""), Icon(coordinateSystem(extent = {{-100, -100}, {100, 100}}, preserveAspectRatio = false, initialScale = 0.1, grid = {2, 2}), graphics = {Rectangle(fillColor = {255, 255, 255}, fillPattern = FillPattern.Solid, extent = {{-100, 100}, {100, -100}}), Ellipse(fillColor = {255, 213, 170}, fillPattern = FillPattern.Solid, extent = {{-23, 26}, {-12, 0}}, endAngle = 360), Text(origin = {0, 1.81063}, lineColor = {0, 0, 255}, extent = {{-104, 142.189}, {98, 104}}, textString = ""%name""), Polygon(fillColor = {215, 215, 215}, pattern = LinePattern.None, fillPattern = FillPattern.Solid, points = {{-22, -56}, {-42, -84}, {-16, -84}, {16, -84}, {-22, -56}}), Polygon(fillColor = {135, 135, 135}, pattern = LinePattern.None, fillPattern = FillPattern.Solid, points = {{-32, 44}, {-62, -48}, {-30, -48}, {-30, -48}, {-32, 44}}, smooth = Smooth.Bezier), Polygon(fillColor = {135, 135, 135}, pattern = LinePattern.None, fillPattern = FillPattern.Solid, points = {{-68, -32}, {-14, -86}, {10, -46}, {0, -46}, {-68, -32}}, smooth = Smooth.Bezier), Polygon(fillColor = {175, 175, 175}, fillPattern = FillPattern.Solid, points = {{-22, 14}, {-30, 10}, {-40, -44}, {2, -42}, {2, -30}, {0, 6}, {-22, 14}}, smooth = Smooth.Bezier), Ellipse(fillColor = {255, 213, 170}, fillPattern = FillPattern.Solid, extent = {{-30, 48}, {-3, 14}}, endAngle = 360), Polygon(pattern = LinePattern.None, fillPattern = FillPattern.Solid, points = {{-38, 38}, {-16, 54}, {-2, 40}, {4, 40}, {6, 40}, {-38, 38}}, smooth = Smooth.Bezier), Polygon(fillColor = {95, 95, 95}, fillPattern = FillPattern.Solid, points = {{30, -40}, {-32, -24}, {-36, -40}, {-24, -54}, {30, -40}}, smooth = Smooth.Bezier), Polygon(fillPattern = FillPattern.Solid, points = {{42, -66}, {36, -80}, {48, -74}, {52, -68}, {50, -64}, {42, -66}}, smooth = Smooth.Bezier), Line(points = {{48, -10}, {26, 4}, {26, 4}}, thickness = 0.5), Line(points = {{20, -6}, {34, 14}, {34, 14}}, thickness = 0.5), Polygon(fillColor = {255, 213, 170}, fillPattern = FillPattern.Solid, points = {{28, 8}, {32, 12}, {28, 6}, {34, 10}, {30, 6}, {34, 8}, {30, 4}, {26, 6}, {34, 4}, {26, 4}, {26, 6}, {28, 8}, {28, 8}, {26, 6}, {26, 6}, {26, 6}, {28, 12}, {28, 10}, {28, 8}}, smooth = Smooth.Bezier), Polygon(fillColor = {175, 175, 175}, fillPattern = FillPattern.Solid, points = {{-18, 4}, {28, 10}, {26, 2}, {-16, -12}, {-20, -12}, {-24, -2}, {-18, 4}}, smooth = Smooth.Bezier), Polygon(fillColor = {215, 215, 215}, fillPattern = FillPattern.Solid, points = {{72, -2}, {48, -2}, {36, -22}, {58, -82}, {72, -82}, {72, -2}}), Polygon(fillColor = {95, 95, 95}, fillPattern = FillPattern.Solid, points = {{49, -90}, {17, -36}, {7, -40}, {-1, -46}, {49, -90}}, smooth = Smooth.Bezier), Line(points = {{-7, 35}, {-3, 33}}), Line(points = {{-9, 22}, {-5, 22}}), Line(points = {{-7, 35}, {-3, 35}}), Text(extent = {{-82, 98}, {94, 58}}, lineColor = {238, 46, 47}, textString = ""%CycleFileName"")})); end PropDriver; model DragForce ""Vehicle rolling and aerodinamical drag force"" import Modelica.Constants.g_n; extends Modelica.Mechanics.Translational.Interfaces.PartialElementaryOneFlangeAndSupport2; extends Modelica.Mechanics.Translational.Interfaces.PartialFriction; Modelica.SIunits.Force f ""Total drag force""; Modelica.SIunits.Velocity v ""vehicle velocity""; Modelica.SIunits.Acceleration a ""Absolute acceleration of flange""; Real Sign; parameter Modelica.SIunits.Mass m ""vehicle mass""; parameter Modelica.SIunits.Density rho(start = 1.226) ""air density""; parameter Modelica.SIunits.Area S ""vehicle cross area""; parameter Real fc(start = 0.01) ""rolling friction coefficient""; parameter Real Cx ""aerodinamic drag coefficient""; final parameter Real A = fc * m * g_n; final parameter Real B = 1 / 2 * rho * S * Cx; final parameter Real mu[:, 2] = [0, 1]; Real debug = f - B * v ^ 2 * Sign; // Constant auxiliary variable equation // s = flange.s; v = der(s); a = der(v); // Le seguenti definizioni seguono l'ordine e le richieste del modello ""PartialFriction"" di // Modelica.Mechanics.Translational.Interfaces"" v_relfric = v; a_relfric = a; f0 = A ""Friction force for v_relfric=0 and forward sliding""; f0_max = A ""Maximum friction force for v_relfric=0 and locked""; free = false ""true when there is not wheel-road contact (never!)""; // Ora il calcolo di f, e la sua attribuzione alla flangia: flange.f - f = 0; // friction force if v > 0 then Sign = 1; else Sign = -1; end if; f - B * v ^ 2 * Sign = if locked then sa * unitForce else f0 * (if startForward then Modelica.Math.Vectors.interpolate(mu[:, 1], mu[:, 2], v) else if startBackward then -Modelica.Math.Vectors.interpolate(mu[:, 1], mu[:, 2], -v) else if pre(mode) == Forward then Modelica.Math.Vectors.interpolate(mu[:, 1], mu[:, 2], v) else -Modelica.Math.Vectors.interpolate(mu[:, 1], mu[:, 2], -v)); annotation( Documentation(info = ""

This component modesl the total (rolling and aerodynamic vehicle drag resistance:

F=fc*m*g+(1/2)*rho*Cx*S*v^2

It models reliably the stuck phase. Based on Modelica-Intrerfaces.PartialFriction model

""), Icon(coordinateSystem(preserveAspectRatio = true, extent = {{-100, -100}, {100, 100}}), graphics = {Polygon(points = {{-98, 10}, {22, 10}, {22, 41}, {92, 0}, {22, -41}, {22, -10}, {-98, -10}, {-98, 10}}, lineColor = {0, 127, 0}, fillColor = {215, 215, 215}, fillPattern = FillPattern.Solid), Line(points = {{-42, -50}, {87, -50}}, color = {0, 0, 0}), Polygon(points = {{-72, -50}, {-41, -40}, {-41, -60}, {-72, -50}}, lineColor = {0, 0, 0}, fillColor = {128, 128, 128}, fillPattern = FillPattern.Solid), Line(points = {{-90, -90}, {-70, -88}, {-50, -82}, {-30, -72}, {-10, -58}, {10, -40}, {30, -18}, {50, 8}, {70, 38}, {90, 72}, {110, 110}}, color = {0, 0, 255}, thickness = 0.5), Text(extent = {{-82, 90}, {80, 50}}, lineColor = {0, 0, 255}, textString = ""%name"")}), Diagram(coordinateSystem(preserveAspectRatio = true, extent = {{-100, -100}, {100, 100}}), graphics)); end DragForce; annotation( uses(Modelica(version = ""3.2.2""))); end Test1; }}} " massimo ceraolo 5105 Unable to set fixed=true through modifier field OMEdit v1.13.0-dev-nightly defect Adeel Asghar new 2018-09-02T09:03:33Z 2024-04-17T02:45:37Z "Consider the enclosed RL3.mo model. Using current OMEdit, it runs and correctly warns about initialization. With {{{-d=initialization}}} we get: {{{ [1] 10:51:27 Translation Warning Assuming fixed start value for the following 3 variables: inductor1.inductor[1].i:VARIABLE(start = 0.0 unit = ""A"" ) ""Current flowing from pin p to pin n"" type: Real [3] inductor1.inductor[2].i:VARIABLE(start = 0.0 unit = ""A"" ) ""Current flowing from pin p to pin n"" type: Real [3] inductor1.inductor[3].i:VARIABLE(start = 0.0 unit = ""A"" ) ""Current flowing from pin p to pin n"" type: Real [3] }}} The warning issue is solved writing in code {{{i(each fixed=true)}}} in inductor1 definition: {{{ Modelica.Electrical.MultiPhase.Basic.Inductor inductor1(L = fill(0.01, 3), i(each fixed=true)); }}} This modification should be possible also through the Parameters|Modifiers tab of inductor1, but it results to be impossible. When when try, the following error message is issued: {{{ [2] 10:56:14 Scripting Error The Modifier i(each fixed=true) format is invalid. The correct format is phi(start=1) }}} " massimo ceraolo 5230 getErrorString raises pyparsing.ParseException after calling buildModel in the python interface OMPython v1.13.0-dev-nightly defect Alachew Mengist new 2018-12-06T15:27:25Z 2021-09-13T11:58:21Z "Hello, to retrieve information about the translation process, we need to call `getErrorString()` after calling `buildModel()`. In the OMSHell this works just fine by executing `buildModel(Modelica.Blocks.Examples.PID_Controller);getErrorString()` Using the python interface (v1.13.0-dev-1098-ge7d386dfb (64-bit)), the following minimal working example leads to `pyparsing.ParseException: Expected end of text (at char 123), (line:2, col:1)`: {{{ import sys sys.path.insert(0, r'C:\OpenModelica1.13.0-dev-64bit\share\omc\scripts\PythonInterface') sys.path.insert(0, r'C:\OpenModelica1.13.0-dev-64bit\lib\python') import omniORB import OMPython interface = OMPython.OMCSession() print(interface.sendExpression(""buildModel(Modelica.Blocks.Examples.PID_Controller);getErrorString()"")) }}} If I instead send the command `print(interface.sendExpression(""buildModel(Modelica.Blocks.Examples.PID_Controller);getErrorString()""))` (added a semicolon after `getErrorString()`, I get `pyparsing.ParseException: Expected {quoted string, starting with "" ending with "" | Combine:({[""-""] {""0"" | W:(1234...,0123...)} [{""."" W:(0123...)}] [{W:(eE) W:(0123...,0123...)}]}) | Forward: ... | Group:({Suppress:(""{"") [Forward: ... [, Forward: ...]...] Suppress:(""}"")}) | Group:({Suppress:(""("") [Forward: ... [, Forward: ...]...] Suppress:("")"")}) | {Suppress:(""SOME"") Suppress:(""("") Forward: ... Suppress:("")"")} | ""true"" | ""false"" | {""NONE"" Suppress:(""("") Suppress:("")"")} | Combine:(Forward: ...)} (at char 0), (line:1, col:1)` instead. Is this reproducible? Any tips or workarounds are welcome, thank you!" robert.mueller@… 5292 Can't run OpenModelica install-executable on Windows via explorer Installation program v1.14.0-dev-nightly defect Adeel Asghar new 2019-01-23T10:28:06Z 2021-09-13T11:58:21Z "I can't run the install executable for OpenModelica (downloaded from https://build.openmodelica.org/omc/builds/windows/nightly-builds/64bit/OpenModelica-v1.14.0-dev-62-g8a20ce05c-64bit.exe) with a double-click in Windows Explorer. Also right-clicking and ""Run as Administrator"" does not work. In both cases Windows indicates that something is working (with that round spinning symbol next to the cursor) but nothing happens. No process is visible in the Task-Manager. Workaround: Running via Cmd on Windows does start the Setup Wizard. I am using Windows 10 Enterprise with full admin rights. The problem is probalby connected to ticket #4829 and my PC is set up to ignore ""unsafe"" executables completly." Andreas Heuermann 5311 Bad behavior of FMUs exported from OM when stopTimeDefined is set to fmi2True FMI v1.13.0 defect Lennart Ochel new 2019-02-01T15:55:41Z 2021-09-13T11:58:21Z "Dear All, I try to use FMUs exported from OM as FMU for co-simulation (FMI 2.0). My Master code is DACCOSIM NG (https://bitbucket.org/simulage/daccosim) and this code usually invoke the primitive fmi2SteupExperiment() with the parameter stopTimeDefined set to fmi2True. In this case, when getting the values of the variables along time, I only get constant values. This bug can be avoided by not defining the ""stopTime"" but we would prefer the bug to be corrected in OM exporter. Best." jean-philippe.tavella@… 5330 csvInput does not handle Integer inputs and needs an extra comma at line end Run-time v1.14.0-dev-nightly defect Lennart Ochel new 2019-02-11T17:56:20Z 2021-09-13T11:58:21Z "the csvInput simulation flag has two big problems: - the last column needs an extra comma at the end of the line, otherwise it gets disregarded; - Integer inputs are not working at all even if the LOG_SIMULATION seems to to say that they are actually set. Moreover, if Integer inputs are mixed with Real inputs, also other inputs get corrupted." dariomangoni@… 5382 Simcode scales badly for models with large-sized arrays and events Backend v1.14.0-dev-nightly defect Karim Adbdelhak assigned 2019-03-12T12:39:09Z 2021-09-13T11:58:21Z "The attached model leaks around 10GB of RAM when run in OMEdit. The RAM does not decrease even when the model is unloaded. A second run leaks an additional 2GB. Note: a machine with at least 32GB is required to simulate the model. It is possible to reduce the value of nx in the model to make it occupy less RAM but the leak is evident for large nx." federico.terraneo@… 5428 Undo makes the cursor move to the end of the editor and unwraps all annotations OMEdit v1.14.0-dev-nightly defect Adeel Asghar new 2019-04-09T14:46:35Z 2021-09-13T11:58:21Z "UNDO generates these two undesired behaviours: - the cursor moves to the bottom of the editor - all the annotations are unwrapped In this way, the user cannot see what the UNDO action actually did (thus is hard to check if furthers UNDOs are required). Not blocking, but quite annoying." dariomangoni@… 5451 OpenModelica.Scripting.system behaving different on Windows and Linux Interactive Environment v1.14.0-dev-nightly defect somebody new 2019-05-02T13:43:32Z 2021-09-13T11:58:21Z "The Modelica scripting function `system` surpresses output on Windows but not on Linux. E.g calling the following mos-Script {{{ system(""echo \""Text output only on Linux visible\""""); }}} only outputs the text on Linux. I need it for testing OMSI FMUs with OMSimulator and check the error and warnings from OMSimulator. The test output should be equal on both OS." Andreas Heuermann 5505 Avoid file lists to be shown along with error messages *unknown* v1.14.0-dev-nightly defect somebody new 2019-05-24T22:41:13Z 2021-09-13T11:58:21Z "The attached model TwoLegs is wrong because the nv pin of powerSensor is unconnected. OM issues an error message whose first line is: {{{ An independent subset of the model has imbalanced number of equations (127) and variables (128). }}} which is ok. Then the full list of variables comes, which is already very long here, which can be much longer on larger models (reported below). I think this list of variables is at least useless. Indeed is also harmful since hides the important part of the error message. I think this list should not be displayed. Full error message: {{{ [1] 00:32:07 Symbolic Error An independent subset of the model has imbalanced number of equations (127) and variables (128). variables: meanP.x meanP.y meanP.u powerSensor.product.y powerSensor.product.u2 powerSensor.product.u1 powerSensor.currentSensor.i powerSensor.currentSensor.n.i powerSensor.currentSensor.n.v powerSensor.currentSensor.p.i powerSensor.currentSensor.p.v powerSensor.voltageSensor.v powerSensor.voltageSensor.n.v powerSensor.voltageSensor.p.i powerSensor.voltageSensor.p.v powerSensor.power powerSensor.nv.v powerSensor.pv.i powerSensor.pv.v powerSensor.nc.i powerSensor.nc.v powerSensor.pc.i powerSensor.pc.v nor2.y nor2.u dD1.s dD1.off dD1.LossPower dD1.n.i dD1.n.v dD1.p.i dD1.p.v dD1.i dD1.v dSW1.fire dSW1.s dSW1.off dSW1.LossPower dSW1.n.i dSW1.n.v dSW1.p.i dSW1.p.v dSW1.i dSW1.v uSW1.fire uSW1.s uSW1.off uSW1.LossPower uSW1.n.i uSW1.n.v uSW1.p.i uSW1.p.v uSW1.i uSW1.v uD1.s uD1.off uD1.LossPower uD1.n.i uD1.n.v uD1.p.i uD1.p.v uD1.i uD1.v Load.R_actual Load.T_heatPort Load.LossPower Load.n.i Load.n.v Load.p.i Load.p.v Load.i Load.v inductor.n.i inductor.n.v inductor.p.i inductor.p.v inductor.i inductor.v dD.s dD.off dD.LossPower dD.n.i dD.n.v dD.p.i dD.p.v dD.i dD.v dSW.fire dSW.s dSW.off dSW.LossPower dSW.n.i dSW.n.v dSW.p.i dSW.p.v dSW.i dSW.v uSW.fire uSW.s uSW.off uSW.LossPower uSW.n.i uSW.n.v uSW.p.i uSW.p.v uSW.i uSW.v uD.s uD.off uD.LossPower uD.n.i uD.n.v uD.p.i uD.p.v uD.i uD.v nor1.y nor1.u booleanPulse.pulseStart booleanPulse.y V1.n.i V1.n.v V1.p.i V1.p.v V1.i V1.v ground.p.i ground.p.v equations: 1 : ground.p.v = 0.0 2 : V1.v = V1.V 3 : V1.v = V1.p.v - V1.n.v 4 : 0.0 = V1.p.i + V1.n.i 5 : V1.i = V1.p.i 6 : booleanPulse.y = time >= booleanPulse.pulseStart and time < booleanPulse.pulseStart + booleanPulse.Twidth 7 : nor1.y = not nor1.u 8 : uD.off = uD.s < 0.0 9 : uD.v = uD.s * (if uD.off then 1.0 else uD.Ron) + uD.Vknee 10 : uD.i = uD.s * (if uD.off then uD.Goff else 1.0) + uD.Goff * uD.Vknee 11 : uD.LossPower = uD.v * uD.i 12 : uD.v = uD.p.v - uD.n.v 13 : 0.0 = uD.p.i + uD.n.i 14 : uD.i = uD.p.i 15 : uSW.off = uSW.s < 0.0 or not uSW.fire 16 : uSW.v = uSW.s * (if uSW.off then 1.0 else uSW.Ron) + uSW.Vknee 17 : uSW.i = uSW.s * (if uSW.off then uSW.Goff else 1.0) + uSW.Goff * uSW.Vknee 18 : uSW.LossPower = uSW.v * uSW.i 19 : uSW.v = uSW.p.v - uSW.n.v 20 : 0.0 = uSW.p.i + uSW.n.i 21 : uSW.i = uSW.p.i 22 : dSW.off = dSW.s < 0.0 or not dSW.fire 23 : dSW.v = dSW.s * (if dSW.off then 1.0 else dSW.Ron) + dSW.Vknee 24 : dSW.i = dSW.s * (if dSW.off then dSW.Goff else 1.0) + dSW.Goff * dSW.Vknee 25 : dSW.LossPower = dSW.v * dSW.i 26 : dSW.v = dSW.p.v - dSW.n.v 27 : 0.0 = dSW.p.i + dSW.n.i 28 : dSW.i = dSW.p.i 29 : dD.off = dD.s < 0.0 30 : dD.v = dD.s * (if dD.off then 1.0 else dD.Ron) + dD.Vknee 31 : dD.i = dD.s * (if dD.off then dD.Goff else 1.0) + dD.Goff * dD.Vknee 32 : dD.LossPower = dD.v * dD.i 33 : dD.v = dD.p.v - dD.n.v 34 : 0.0 = dD.p.i + dD.n.i 35 : dD.i = dD.p.i 36 : inductor.L * der(inductor.i) = inductor.v 37 : inductor.v = inductor.p.v - inductor.n.v 38 : 0.0 = inductor.p.i + inductor.n.i 39 : inductor.i = inductor.p.i 40 : Load.R_actual = Load.R * (1.0 + Load.alpha * (Load.T_heatPort - Load.T_ref)) 41 : Load.v = Load.R_actual * Load.i 42 : Load.LossPower = Load.v * Load.i 43 : Load.v = Load.p.v - Load.n.v 44 : 0.0 = Load.p.i + Load.n.i 45 : Load.i = Load.p.i 46 : Load.T_heatPort = Load.T 47 : uD1.off = uD1.s < 0.0 48 : uD1.v = uD1.s * (if uD1.off then 1.0 else uD1.Ron) + uD1.Vknee 49 : uD1.i = uD1.s * (if uD1.off then uD1.Goff else 1.0) + uD1.Goff * uD1.Vknee 50 : uD1.LossPower = uD1.v * uD1.i 51 : uD1.v = uD1.p.v - uD1.n.v 52 : 0.0 = uD1.p.i + uD1.n.i 53 : uD1.i = uD1.p.i 54 : uSW1.off = uSW1.s < 0.0 or not uSW1.fire 55 : uSW1.v = uSW1.s * (if uSW1.off then 1.0 else uSW1.Ron) + uSW1.Vknee 56 : uSW1.i = uSW1.s * (if uSW1.off then uSW1.Goff else 1.0) + uSW1.Goff * uSW1.Vknee 57 : uSW1.LossPower = uSW1.v * uSW1.i 58 : uSW1.v = uSW1.p.v - uSW1.n.v 59 : 0.0 = uSW1.p.i + uSW1.n.i 60 : uSW1.i = uSW1.p.i 61 : dSW1.off = dSW1.s < 0.0 or not dSW1.fire 62 : dSW1.v = dSW1.s * (if dSW1.off then 1.0 else dSW1.Ron) + dSW1.Vknee 63 : dSW1.i = dSW1.s * (if dSW1.off then dSW1.Goff else 1.0) + dSW1.Goff * dSW1.Vknee 64 : dSW1.LossPower = dSW1.v * dSW1.i 65 : dSW1.v = dSW1.p.v - dSW1.n.v 66 : 0.0 = dSW1.p.i + dSW1.n.i 67 : dSW1.i = dSW1.p.i 68 : dD1.off = dD1.s < 0.0 69 : dD1.v = dD1.s * (if dD1.off then 1.0 else dD1.Ron) + dD1.Vknee 70 : dD1.i = dD1.s * (if dD1.off then dD1.Goff else 1.0) + dD1.Goff * dD1.Vknee 71 : dD1.LossPower = dD1.v * dD1.i 72 : dD1.v = dD1.p.v - dD1.n.v 73 : 0.0 = dD1.p.i + dD1.n.i 74 : dD1.i = dD1.p.i 75 : nor2.y = not nor2.u 76 : powerSensor.voltageSensor.p.i = 0.0 77 : powerSensor.voltageSensor.v = powerSensor.voltageSensor.p.v - powerSensor.voltageSensor.n.v 78 : powerSensor.currentSensor.p.v = powerSensor.currentSensor.n.v 79 : powerSensor.currentSensor.p.i = powerSensor.currentSensor.i 80 : powerSensor.currentSensor.n.i = -powerSensor.currentSensor.i 81 : powerSensor.product.y = powerSensor.product.u1 * powerSensor.product.u2 82 : der(meanP.x) = meanP.u 83 : ground.p.i + Load.n.i + uD1.p.i + uSW1.n.i + dSW1.p.i + dD1.n.i = 0.0 84 : V1.p.i + uD.n.i + uSW.p.i + uD1.n.i + uSW1.p.i = 0.0 85 : V1.n.i + dSW.n.i + dD.p.i + dSW1.n.i + dD1.p.i = 0.0 86 : uD.p.i + uSW.n.i + dSW.p.i + dD.n.i + powerSensor.pc.i = 0.0 87 : inductor.p.i + powerSensor.nc.i + powerSensor.pv.i = 0.0 88 : inductor.n.i + Load.p.i = 0.0 89 : powerSensor.voltageSensor.p.i - powerSensor.pv.i = 0.0 90 : powerSensor.currentSensor.p.i - powerSensor.pc.i = 0.0 91 : powerSensor.currentSensor.n.i - powerSensor.nc.i = 0.0 92 : powerSensor.pv.v = powerSensor.voltageSensor.p.v 93 : powerSensor.nv.v = powerSensor.voltageSensor.n.v 94 : powerSensor.currentSensor.p.v = powerSensor.pc.v 95 : powerSensor.currentSensor.n.v = powerSensor.nc.v 96 : powerSensor.currentSensor.i = powerSensor.product.u2 97 : powerSensor.product.u1 = powerSensor.voltageSensor.v 98 : powerSensor.power = powerSensor.product.y 99 : booleanPulse.y = dSW1.fire 100 : booleanPulse.y = nor1.u 101 : booleanPulse.y = nor2.u 102 : booleanPulse.y = uSW.fire 103 : nor2.y = uSW1.fire 104 : Load.p.v = inductor.n.v 105 : V1.p.v = uD.n.v 106 : V1.p.v = uD1.n.v 107 : V1.p.v = uSW.p.v 108 : V1.p.v = uSW1.p.v 109 : dD.n.v = dSW.p.v 110 : dD.n.v = powerSensor.pc.v 111 : dD.n.v = uD.p.v 112 : dD.n.v = uSW.n.v 113 : V1.n.v = dD.p.v 114 : V1.n.v = dD1.p.v 115 : V1.n.v = dSW.n.v 116 : V1.n.v = dSW1.n.v 117 : Load.n.v = dD1.n.v 118 : Load.n.v = dSW1.p.v 119 : Load.n.v = ground.p.v 120 : Load.n.v = uD1.p.v 121 : Load.n.v = uSW1.n.v 122 : dSW.fire = nor1.y 123 : inductor.p.v = powerSensor.nc.v 124 : inductor.p.v = powerSensor.pv.v 125 : meanP.u = powerSensor.power 126 : when sample(2, meanP.t0 + 1.0 / meanP.f, 1.0 / meanP.f) then meanP.y := meanP.f * pre(meanP.x); end when; 127 : when sample(1, booleanPulse.startTime, booleanPulse.period) then booleanPulse.pulseStart := time; end when; [2] 00:32:07 Translation Error pre-optimization module clockPartitioning (simulation) failed. [1] 00:34:43 Symbolic Error An independent subset of the model has imbalanced number of equations (127) and variables (128). variables: meanP.x meanP.y meanP.u powerSensor.product.y powerSensor.product.u2 powerSensor.product.u1 powerSensor.currentSensor.i powerSensor.currentSensor.n.i powerSensor.currentSensor.n.v powerSensor.currentSensor.p.i powerSensor.currentSensor.p.v powerSensor.voltageSensor.v powerSensor.voltageSensor.n.v powerSensor.voltageSensor.p.i powerSensor.voltageSensor.p.v powerSensor.power powerSensor.nv.v powerSensor.pv.i powerSensor.pv.v powerSensor.nc.i powerSensor.nc.v powerSensor.pc.i powerSensor.pc.v nor2.y nor2.u dD1.s dD1.off dD1.LossPower dD1.n.i dD1.n.v dD1.p.i dD1.p.v dD1.i dD1.v dSW1.fire dSW1.s dSW1.off dSW1.LossPower dSW1.n.i dSW1.n.v dSW1.p.i dSW1.p.v dSW1.i dSW1.v uSW1.fire uSW1.s uSW1.off uSW1.LossPower uSW1.n.i uSW1.n.v uSW1.p.i uSW1.p.v uSW1.i uSW1.v uD1.s uD1.off uD1.LossPower uD1.n.i uD1.n.v uD1.p.i uD1.p.v uD1.i uD1.v Load.R_actual Load.T_heatPort Load.LossPower Load.n.i Load.n.v Load.p.i Load.p.v Load.i Load.v inductor.n.i inductor.n.v inductor.p.i inductor.p.v inductor.i inductor.v dD.s dD.off dD.LossPower dD.n.i dD.n.v dD.p.i dD.p.v dD.i dD.v dSW.fire dSW.s dSW.off dSW.LossPower dSW.n.i dSW.n.v dSW.p.i dSW.p.v dSW.i dSW.v uSW.fire uSW.s uSW.off uSW.LossPower uSW.n.i uSW.n.v uSW.p.i uSW.p.v uSW.i uSW.v uD.s uD.off uD.LossPower uD.n.i uD.n.v uD.p.i uD.p.v uD.i uD.v nor1.y nor1.u booleanPulse.pulseStart booleanPulse.y V1.n.i V1.n.v V1.p.i V1.p.v V1.i V1.v ground.p.i ground.p.v equations: 1 : ground.p.v = 0.0 2 : V1.v = V1.V 3 : V1.v = V1.p.v - V1.n.v 4 : 0.0 = V1.p.i + V1.n.i 5 : V1.i = V1.p.i 6 : booleanPulse.y = time >= booleanPulse.pulseStart and time < booleanPulse.pulseStart + booleanPulse.Twidth 7 : nor1.y = not nor1.u 8 : uD.off = uD.s < 0.0 9 : uD.v = uD.s * (if uD.off then 1.0 else uD.Ron) + uD.Vknee 10 : uD.i = uD.s * (if uD.off then uD.Goff else 1.0) + uD.Goff * uD.Vknee 11 : uD.LossPower = uD.v * uD.i 12 : uD.v = uD.p.v - uD.n.v 13 : 0.0 = uD.p.i + uD.n.i 14 : uD.i = uD.p.i 15 : uSW.off = uSW.s < 0.0 or not uSW.fire 16 : uSW.v = uSW.s * (if uSW.off then 1.0 else uSW.Ron) + uSW.Vknee 17 : uSW.i = uSW.s * (if uSW.off then uSW.Goff else 1.0) + uSW.Goff * uSW.Vknee 18 : uSW.LossPower = uSW.v * uSW.i 19 : uSW.v = uSW.p.v - uSW.n.v 20 : 0.0 = uSW.p.i + uSW.n.i 21 : uSW.i = uSW.p.i 22 : dSW.off = dSW.s < 0.0 or not dSW.fire 23 : dSW.v = dSW.s * (if dSW.off then 1.0 else dSW.Ron) + dSW.Vknee 24 : dSW.i = dSW.s * (if dSW.off then dSW.Goff else 1.0) + dSW.Goff * dSW.Vknee 25 : dSW.LossPower = dSW.v * dSW.i 26 : dSW.v = dSW.p.v - dSW.n.v 27 : 0.0 = dSW.p.i + dSW.n.i 28 : dSW.i = dSW.p.i 29 : dD.off = dD.s < 0.0 30 : dD.v = dD.s * (if dD.off then 1.0 else dD.Ron) + dD.Vknee 31 : dD.i = dD.s * (if dD.off then dD.Goff else 1.0) + dD.Goff * dD.Vknee 32 : dD.LossPower = dD.v * dD.i 33 : dD.v = dD.p.v - dD.n.v 34 : 0.0 = dD.p.i + dD.n.i 35 : dD.i = dD.p.i 36 : inductor.L * der(inductor.i) = inductor.v 37 : inductor.v = inductor.p.v - inductor.n.v 38 : 0.0 = inductor.p.i + inductor.n.i 39 : inductor.i = inductor.p.i 40 : Load.R_actual = Load.R * (1.0 + Load.alpha * (Load.T_heatPort - Load.T_ref)) 41 : Load.v = Load.R_actual * Load.i 42 : Load.LossPower = Load.v * Load.i 43 : Load.v = Load.p.v - Load.n.v 44 : 0.0 = Load.p.i + Load.n.i 45 : Load.i = Load.p.i 46 : Load.T_heatPort = Load.T 47 : uD1.off = uD1.s < 0.0 48 : uD1.v = uD1.s * (if uD1.off then 1.0 else uD1.Ron) + uD1.Vknee 49 : uD1.i = uD1.s * (if uD1.off then uD1.Goff else 1.0) + uD1.Goff * uD1.Vknee 50 : uD1.LossPower = uD1.v * uD1.i 51 : uD1.v = uD1.p.v - uD1.n.v 52 : 0.0 = uD1.p.i + uD1.n.i 53 : uD1.i = uD1.p.i 54 : uSW1.off = uSW1.s < 0.0 or not uSW1.fire 55 : uSW1.v = uSW1.s * (if uSW1.off then 1.0 else uSW1.Ron) + uSW1.Vknee 56 : uSW1.i = uSW1.s * (if uSW1.off then uSW1.Goff else 1.0) + uSW1.Goff * uSW1.Vknee 57 : uSW1.LossPower = uSW1.v * uSW1.i 58 : uSW1.v = uSW1.p.v - uSW1.n.v 59 : 0.0 = uSW1.p.i + uSW1.n.i 60 : uSW1.i = uSW1.p.i 61 : dSW1.off = dSW1.s < 0.0 or not dSW1.fire 62 : dSW1.v = dSW1.s * (if dSW1.off then 1.0 else dSW1.Ron) + dSW1.Vknee 63 : dSW1.i = dSW1.s * (if dSW1.off then dSW1.Goff else 1.0) + dSW1.Goff * dSW1.Vknee 64 : dSW1.LossPower = dSW1.v * dSW1.i 65 : dSW1.v = dSW1.p.v - dSW1.n.v 66 : 0.0 = dSW1.p.i + dSW1.n.i 67 : dSW1.i = dSW1.p.i 68 : dD1.off = dD1.s < 0.0 69 : dD1.v = dD1.s * (if dD1.off then 1.0 else dD1.Ron) + dD1.Vknee 70 : dD1.i = dD1.s * (if dD1.off then dD1.Goff else 1.0) + dD1.Goff * dD1.Vknee 71 : dD1.LossPower = dD1.v * dD1.i 72 : dD1.v = dD1.p.v - dD1.n.v 73 : 0.0 = dD1.p.i + dD1.n.i 74 : dD1.i = dD1.p.i 75 : nor2.y = not nor2.u 76 : powerSensor.voltageSensor.p.i = 0.0 77 : powerSensor.voltageSensor.v = powerSensor.voltageSensor.p.v - powerSensor.voltageSensor.n.v 78 : powerSensor.currentSensor.p.v = powerSensor.currentSensor.n.v 79 : powerSensor.currentSensor.p.i = powerSensor.currentSensor.i 80 : powerSensor.currentSensor.n.i = -powerSensor.currentSensor.i 81 : powerSensor.product.y = powerSensor.product.u1 * powerSensor.product.u2 82 : der(meanP.x) = meanP.u 83 : ground.p.i + Load.n.i + uD1.p.i + uSW1.n.i + dSW1.p.i + dD1.n.i = 0.0 84 : V1.p.i + uD.n.i + uSW.p.i + uD1.n.i + uSW1.p.i = 0.0 85 : V1.n.i + dSW.n.i + dD.p.i + dSW1.n.i + dD1.p.i = 0.0 86 : uD.p.i + uSW.n.i + dSW.p.i + dD.n.i + powerSensor.pc.i = 0.0 87 : inductor.p.i + powerSensor.nc.i + powerSensor.pv.i = 0.0 88 : inductor.n.i + Load.p.i = 0.0 89 : powerSensor.voltageSensor.p.i - powerSensor.pv.i = 0.0 90 : powerSensor.currentSensor.p.i - powerSensor.pc.i = 0.0 91 : powerSensor.currentSensor.n.i - powerSensor.nc.i = 0.0 92 : powerSensor.pv.v = powerSensor.voltageSensor.p.v 93 : powerSensor.nv.v = powerSensor.voltageSensor.n.v 94 : powerSensor.currentSensor.p.v = powerSensor.pc.v 95 : powerSensor.currentSensor.n.v = powerSensor.nc.v 96 : powerSensor.currentSensor.i = powerSensor.product.u2 97 : powerSensor.product.u1 = powerSensor.voltageSensor.v 98 : powerSensor.power = powerSensor.product.y 99 : booleanPulse.y = dSW1.fire 100 : booleanPulse.y = nor1.u 101 : booleanPulse.y = nor2.u 102 : booleanPulse.y = uSW.fire 103 : nor2.y = uSW1.fire 104 : Load.p.v = inductor.n.v 105 : V1.p.v = uD.n.v 106 : V1.p.v = uD1.n.v 107 : V1.p.v = uSW.p.v 108 : V1.p.v = uSW1.p.v 109 : dD.n.v = dSW.p.v 110 : dD.n.v = powerSensor.pc.v 111 : dD.n.v = uD.p.v 112 : dD.n.v = uSW.n.v 113 : V1.n.v = dD.p.v 114 : V1.n.v = dD1.p.v 115 : V1.n.v = dSW.n.v 116 : V1.n.v = dSW1.n.v 117 : Load.n.v = dD1.n.v 118 : Load.n.v = dSW1.p.v 119 : Load.n.v = ground.p.v 120 : Load.n.v = uD1.p.v 121 : Load.n.v = uSW1.n.v 122 : dSW.fire = nor1.y 123 : inductor.p.v = powerSensor.nc.v 124 : inductor.p.v = powerSensor.pv.v 125 : meanP.u = powerSensor.power 126 : when sample(2, meanP.t0 + 1.0 / meanP.f, 1.0 / meanP.f) then meanP.y := meanP.f * pre(meanP.x); end when; 127 : when sample(1, booleanPulse.startTime, booleanPulse.period) then booleanPulse.pulseStart := time; end when; [2] 00:34:43 Translation Error pre-optimization module clockPartitioning (simulation) failed. }}} " massimo ceraolo 5852 getCommandLineOptions fails with newInst New Instantiation v1.16.0-dev defect Per Östlund new 2020-02-18T09:32:18Z 2021-09-13T11:58:21Z "call to `getCommandLineOptions` fails when omc is called with `-d=newInst` debug option {{{ C:\runtest_oldInst.bat -d=initialization C:\runtest_newInst.bat Error processing file: runtest.mos # Error encountered! Exiting... # Please check the error message and the flags. Execution failed! }}} To replicate, either: - launch `runtest.mos` with omc `-d=newInst` - use the provided `runtest_newInst.bat` and `runtest_oldInst.bat` Using OpenModelica v1.16.0-dev-189-gf9a0b4816 on Win10" dariomangoni@… 5872 Arrow aspect ratio OMEdit defect Adeel Asghar new 2020-03-02T16:00:16Z 2021-09-13T11:58:21Z "The aspect ratio of arrows should be 2/3: (total width)/(total length). The Modelica Specification in this is not very clear, but will probably be enhanced: see https://github.com/modelica/ModelicaSpecification/issues/2515 In the enclosed arrows.pdf I show that OM has an erroneous aspect ratio. There I showed PowerGrids.Electrical.Buses.BusFault using OM and Dymola. Wolfram System Modeler uses the same aspect ratio as Dymola, but in a better way (it is shown in the above-mentioned ticket 2515): I propose to take this display as a reference." massimo ceraolo 5883 Elements which have been inserted can't be deleted anymore OMSimulator v.1.15.0-dev defect Lennart Ochel new 2020-03-09T11:45:14Z 2021-09-13T11:58:21Z "When I create a new .ssp project and insert elements (e.g. connectors), I can't remove them using del afterwards. Same problem with any other component. I accidently created an Input named (Output1) -> changing Input to Output is not possible afterwards. Then i tried to delete this connector which was not possible." nico.dahringer@… 5922 Alias variables do not display in Transformational Debugger Debugger v.1.15.0-dev defect Martin Sjölund assigned 2020-04-22T09:20:26Z 2021-09-13T11:58:21Z "Dear OM developpers, I'm creating an new issue for something that already mentioned as a comment by @casella (https://trac.openmodelica.org/OpenModelica/ticket/4712#comment:2): Alias variables and equation do not display in the Transformational Debugger. A related issue is that many model variables are absent in the Variables Brower of the debugger (the variables that got aliased I guess). This makes equation debugging harder. Best, Pierre" pierre.haessig@… 5939 variableFilter sometimes includes aliases of selected variables *unknown* v1.16.0-dev defect somebody new 2020-05-06T14:23:41Z 2021-09-13T11:58:21Z "The simulation option variableFilter sometimes includes variables that do not match the regular expression but that are aliases of a variable that does. Unfortunately my MWE is still 300 lines of Modelica code, since I found it quite hard to pinpoint why some variables show this behavior and some variables don't. Attached you will find one file where the variable filter works as expected (VariableFilterWorking.mo) and one where it includes four additional variables (VariableFilterBroken.mo). In both cases the outputFormat is ""csv"" and the variableFilter used is the following: {{{ (n|an_nh)_(vc_v|naca_(i|E[1-4]|k_[1-4][1-4])) }}} For VariableFilterBroken you find the additional variables an_nh_naca_F1_3n_i, an_nh_naca_F1_3n_o, n_naca_F1_3n_i and n_naca_F1_3n_o, which are equal to one of the variables selected by the filter (e.g. through ""Real n_naca_k_34 = n_naca_F1_3n_o;"") but do not match the regex. Other variable aliases (e.g. n_naca_F_c_i with ""Real n_naca_k_12 = n_naca_F_c_i;""), however, are not selected. I cannot find any pattern here, but I suspect it has something to do with variable naming and ordering since this is the only thing that changed between the working and the broken version. I suspect that this is related to [https://trac.openmodelica.org/OpenModelica/ticket/3533 #3533] and the fact that this happens for some but not all variables and is related to aliasing could explain why this issue could not be reproduced. This behavior was both tested with OMEdit and by directly calling the OMC through the scripting API. Version numbers are the following (from ""About OMEdit"" window): Connected to OMCompiler v1.16.0-dev.252+gebc5dd384 Connected to OMSimulator v2.1.0-dev-155-gf11a7e4-linux" christopher.schoelzel@… 6055 Bug when passing Boolean arrays as external function arguments Run-time v1.16.0-dev defect Andreas Heuermann new 2020-07-09T14:34:32Z 2021-09-13T11:58:21Z "In the model below a Boolean array is passed to an external function. The returned Boolean array should be identical. This works as expected when using the Cpp run-time, but fails for the default C run-time. {{{#!modelica model ExternalArrayBug ""Shows an OMC C run-time bug when passing Boolean arrays"" output Boolean u[4](each start=false,each fixed=true); output Boolean y[4](each start=false,each fixed=true); protected function booleanIdentity extends Modelica.Icons.Function; input Boolean u[:]; output Boolean y[size(u,1)]; external ""C"" boolean_identity(u, size(u,1), y, size(y,1)) annotation(Include = "" #include \""ModelicaUtilities.h\"" void boolean_identity(const int *u, size_t u_n, int *y, size_t y_n) { for (int i=0; i the ModelSwitcher toolbar is visible again. Tested with dev-648" massimo ceraolo 6177 Graphic Modelling does not respect tab / indentation settings OMEdit v1.16.0-dev defect Adeel Asghar new 2020-11-04T08:52:27Z 2021-09-13T11:58:21Z "After changing Tabs and Indentation in Text Editor of OMEdit to ""Tabs only"" and Tab&Indent Size to 3, the text produced when modelling via diagram view still uses 2 spaces instead of tabs. " anonymous 6191 Autocompletion information box sometimes gets stuck OMEdit v1.16.0-dev defect Adeel Asghar new 2020-11-08T22:29:56Z 2021-09-13T11:58:21Z "With 1.16 i encountered a new problem with OMEdit Text editor, that sometimes the autocompletion information box stays visible and frozen in place. It is always displayed on top of everything (including other windows), so it can be obstrusive when it happens. It happened a couple of times before, but i have not recognized a pattern yet. E.g. i typed import SI=Modelica.SIunits; in a new model. While typing ""Modelica.S"" the selection list of available classes opened like expected. Normally the information box would appear next to it, but in this case the box displayed on top of the list and above the line i was writing in. It also froze in place, not changing (hiding what i was typing). The info box kept frozen when changing classes, and also when moving OMEdit Window to another monitor. To get rid of the box i tried closing the original class and changing view to other classes (see screenshot) https://abload.de/img/ticketkck4o.jpg , moved window around , minimized etc. It eventually went away, i think that was when i opened the original class i was typing it again. " anonymous 6309 Font size of text in info box too small when dispayed in modern screens OMEdit v1.17.0-dev defect Adeel Asghar new 2020-12-23T13:04:56Z 2021-09-13T11:58:21Z "Modern screens often use scaling factors for fonts, to avoid too small font sizes in mm at equal DPIs. 150% or more is common nowadays. It seems to me that the text in the info blocks of OpenModelica does not take into account these scaling factors. In Qt this happens when size is chosen in pixels instead of points." massimo ceraolo 6317 "Autocompletion breaks after annotation(Dialog(tab = ""Anything""))" OMEdit 1.16.1 defect Adeel Asghar new 2020-12-31T01:14:34Z 2021-09-13T11:58:21Z "The autocompletion does not work after using the following annotation: annotation(Dialog(tab = ""Anything"")) Here there is an example: -------------------------------------------- model Test // <--- Until here auto-completion works! parameter Real K = 5 ""This is a parameter"" annotation(Dialog(tab = ""Anything"")); // <--- It does not work here. equation // <--- It does not work here. end Test; // <--- Here it works again. -------------------------------------------- " franco.ferrucci@… 6345 "displayUnit of inverse time ""d-1"", ""h-1"", ''min-1"" not working" OMEdit 1.16.2 defect Martin Sjölund reopened 2021-01-18T10:02:04Z 2021-09-13T11:58:21Z "Dear OM devs, With OM 1.16.2, I can't get variables representing a rate in per second (""s-1"") to display as per day, per hour or per minute (i.e. `unit=""s-1""` and `displayUnit=""d-1""` or ""h-1"", ""min-1""). See example model attached. I've checked that the `displayUnit=""d""` for a time works. For a rate, `displayUnit=""ks-1""` (per 1000 seconds) also works fine, i.e. displays the value multiplied by 1000. So the problem does not concerns the conversion of all units with a -1 exponent. I've found the implementation of the ""day"" unit was discussed in issue #2250 (https://trac.openmodelica.org/OpenModelica/ticket/2250#comment:27) and is visible in the code at https://github.com/OpenModelica/OpenModelica/blob/master/OMCompiler/Compiler/runtime/unitparser.cpp#L1152. About the application: I gave students a modeling project about [https://www.lewuathe.com/covid-19-dynamics-with-sir-model.html/ SIR epidemy models]. Quite fashionable these days! I think infection rates are often given per day. Best, Pierre" pierre.haessig@… 6354 Result file from OMSimulator contains all lines in double OMSimulator 1.16.0 defect Lennart Ochel accepted 2021-01-27T10:02:44Z 2021-09-13T11:58:21Z "Result file from OMSimulator contains all lines in double. As an example I attach a .csv from a run of a SSP model and each line are doubled. For optimization purpose, a single line should be anough, should'nt it?" jean-philippe.tavella@… 6356 After a SSP model run, the model is taggued as modified and should not OMSimulator v1.17.0-dev defect Lennart Ochel accepted 2021-01-27T16:12:28Z 2021-09-13T11:58:21Z "I run a SSP model, and after the successful execution, the model is taggued as modified in the browser. This is not undertandable as nothing has been changed in the ssp file due to the run. Refer to the enclosed video." jean-philippe.tavella@… 5598 redeclaration of input as output with NF New Instantiation v1.14.0-dev-nightly discussion Per Östlund assigned 2019-07-19T11:42:21Z 2021-09-13T11:58:21Z "Hello, The following error message occurred during testing with the new frontend: {{{ [ReplaceableInput.test: 7:35-7:58]: Invalid redeclaration 'output A', original element is declared 'input'. }}} However, I couldn't find anything in ModelicaSpec33 Section 7.3 (Redeclaration) about whether such a redeclaration is invalid. Is this a feature which is not yet implemented or should not be supported in the new frontend? With the old frontend the model ran without problems. See attached minimal example. " Sven Bätzing 6143 Drop support for FMI 1.0 FMI 1.0 discussion Lennart Ochel new 2020-09-29T13:10:21Z 2021-09-13T11:58:21Z "We don't support FMI 1.0 (export) well. Are we even testing FMI 1.0? And there are hardly any people using FMI 1.0 export. OMSimulator won't import FMI 1.0 either and we already stopped developing the OpenModelica Modelica import of FMUs. So should we remove source code that is used only for FMI 1.0. That could simplify the FMI runtime, the code generation and our build system and remove dead code. What are your comments on this topic? Are you in favor or cleaning up the source code or keep what ever functionality we have for someone who want's to use it?" Andreas Heuermann 2777 Omedit and small plots issues OMEdit trunk enhancement Adeel Asghar new 2014-08-11T15:35:17Z 2021-09-13T11:58:21Z "Often the user might want to look at several plots simultaneously. Then he wants them to be tiny. Typically, to ease clear small plots, plotting programs reduce the number of numerical labels when pots are small. Unfortunately OMEdit does not do this: the number of numerical label is fixed. Therefore when small plots are made labels on the horizontal axis overlap. Labels on the vertical axis do no overlap because a is imposed on the vertical plot size (it cannot be smaller than a rather large limit). What I suggest is to add a simple algorithm that adapts the number of numerical labels to the actual plot size. So that plots can be smaller than they are now, while still being well readable. In enclose a file containing an example, created with r20199. The top picture is reasonable. The center picture is too crowded of numerical labels; the bottom one is the worst one." anonymous 2983 Show simulation results while running the simulation OMEdit trunk enhancement Adeel Asghar reopened 2014-11-14T07:13:13Z 2021-09-13T11:58:21Z "It would be great to be able to display the current results of a simulation in OMEdit while it is running. This is especially useful when testing slow models where it is not clear whether they work correctly. An additional feature would be to be able to stop the simulation without loosing the results. Being able to pause/resume a simulation would be also a nice feature." A.Taeschner@… 4322 OMEdit: Improve commenting of folded lines - but how? OMEdit enhancement Adeel Asghar accepted 2017-03-15T20:38:44Z 2021-09-13T11:58:21Z "Commenting out folded lines in a hurry will result in syntax errors, as only the first line is commented out. It would be convenient if all lines are commented automatically. One possibility is to add a {{{//}}} at the beginning of every other line. Another possibility is to replace the just typed {{{//}}} into a {{{/*}}} and to add a {{{*/}}} at the end of the folded part. Removing the comments should follow the same automatic behavior. What do you think? Or is it only me, who noticed that? - This is a discussion ticket!" Jan Kokert 4956 Color and width of connecting lines OMEdit enhancement Adeel Asghar new 2018-05-28T05:57:23Z 2021-09-13T11:58:21Z "When drawing connecting lines OMEdit correctly uses as color the lineColor of the connector the line starts from. When we connect two expandable connectors to each other this implies the connecting lines to be black, which is not optimal. To improve the final result, I propose that when we start a connecting line from an expandable connector we use, as line color, the color of the pixel the drawing line is started from. I think Dymola uses this technique. I enclose two pictures showing both results. ----- Furthermore, OMEdit uses ticker lines when connecting two expandable connectors. This is useful and nice, since it recalls that that is a channel for signal, possibly carrying many signals simultaneously. Thick lines are used also when connecting model arrays. When connecting an expandable connector to a scalar model, however, thin lines should be used. Currently OMEdit uses a thick line if the drawing starts from the expandable connector, a thin one if the reverse is true. I understand that when a connecting action is initiated from an expandable connector the line should be initially be drawn as think (OMEdit does not know the connection target). But when the connection is finalised, if the other-side connector is a regular (non array, non-expandable) connector, the final thickness should be converted into thin." massimo ceraolo 5266 FMU export improvment FMI v1.13.0-dev-nightly enhancement Lennart Ochel new 2019-01-09T09:15:53Z 2021-09-13T11:58:21Z "Dear All, My company EDF would like to use FMUs exported from OM in our open-source Master of co-simulation (FYI this tool is called DACCOSIM: https://bitbucket.org/simulage/daccosim). For that, flags canGetAndSetFMUstate and canInterpolateInputs are required with value true (false at the time being). Best." J-Ph Tavella 5585 Parameter record editor OMEdit v1.13.2 enhancement Adeel Asghar new 2019-07-13T05:46:46Z 2021-09-13T11:58:21Z "Dear OM-developers, using models with a large number of parameters is a tedious and error prone job - if you want to simulate a device with different parameters and you forget to change a single parameter, the whole simulaton is wrong. As a cure, I use parameter records: The user can prepare parameter records for different versions of the device and propagate them to the device with a single action. Unfortunately, trying to edit the parameter record in the parameter menu of the component is nearly impossible without some sort of parameter record editor. It would be nice to press a button in the parameter menu near the parameter record and the parameter menu of the parameter record is shown. I'm sure this enhancement would not only improve usage for teaching but also for industrial applications. Best regards, Toni" ahaumer@… 5773 Correctly show resistance unit of measure OMEdit enhancement Adeel Asghar new 2020-01-08T10:15:00Z 2021-09-13T11:58:21Z "Recently OMEdit has added unit of measure to shown component parameters. For instance, inductances carry H, capacitances F, etc. Resistances carry ""Ohm"". I see no programming difficulty in using the correct value (uppercase greek omega). I understand that it would enhance the visual quality of diagrams minimally but in case, as I expect, the programming effort is minimal as well, it is worthwhile." massimo ceraolo 5958 Filter and export partial result files from OMEdit OMEdit enhancement Adeel Asghar accepted 2020-05-15T09:25:18Z 2021-09-13T11:58:21Z It would be handy to make [https://www.openmodelica.org/doc/OpenModelicaUsersGuide/latest/scripting_api.html#filtersimulationresults filterSimulationResults] available from OMEdit to export and filter partial result files. Lennart Ochel 6170 "Reintroducing documentation ""link"" in class context menu" OMEdit v1.16.0-dev enhancement Adeel Asghar new 2020-10-29T09:55:58Z 2020-11-20T19:02:48Z "In OMEdit of older OpenModelica versions (1.13 and older iirc), if you opened the context menu of a class in the library or in the schematic view, it provided the option to view the documentation for that class directly. This feature is lacking in 1.14 and newer. Please consider reintroducing it, or an equally convenient alternative. To view the documentation of a class right now, one has to open the class explicitly first, and then check the documentation. This is very inconvenient. For learning it is a big hindrance - be it learning modelica standard libraries, or third party libraries/models. Furthermore, due to opening the class it is now in the ""open class"" tab bar -> so after reading the documentation of some classes they have to be all closed manually again. " anonymous 6187 Plots to Clipboard OMEdit enhancement Adeel Asghar new 2020-11-06T18:06:04Z 2021-09-13T11:58:21Z "I love the possibility that e have in OM to export diagrams, as images, to the clipboard simply through right-clicking. I would love as well, being able to do the same with plots. Can this be implemented? ''I know that I can save and plots into SVG or PNG and then import them in other apps. But right-clicking would be much faster!" massimo ceraolo 6392 Possibility to pin recent files OMEdit 1.16.2 enhancement Adeel Asghar new 2021-02-21T15:23:53Z 2021-09-13T11:58:21Z "After ticket #5961 has been successfully been fixed, the new situation opens interesting new scenarios. I would like the possibility of adding some way to ""pin"" and ""unpin"" some of the recent files. Pinned files should always stay on top of the list and its quality of being pinned be displayed somehow (e.g. they could be written bold or a pin icon may be added near the name). Any recent files will be put on the list immediately after the pinned ones. Does anyone feel the need for this feature or agree with this idea? Is it difficult to implement? " massimo ceraolo 5867 Implement fixed time step implicit Euler in FMI/CS FMI 1.16.0 defect Andreas Heuermann reopened 2020-02-25T14:20:16Z 2021-03-26T23:09:50Z "Currently, FMI/CS only provides explicit Euler. This is good for real-time co-simulation of non-stiff models, but it doesn't work if the model is stiff, because it then requires very small time steps. It is planned to add CVODE to FMI/CS; however, this only provides variable step-size solvers with error control. These are fine from the point of view of precision, but they will tend to require many internal steps for each main step of the FMI, because the step changes of the output will trigger fast transients which are totally irrelevant for the output at the end of the step, but that the CVODE solvers will nevertheless try to simulate with great accuracy. A simple but effective solution could be to have fixed time step implicit Euler also implemented. This will solve most stability problems, since implicit Euler is L-stable. I would therefore recommend that this solution is also implemented for FMI/CS, in addition to CVODE. I would also recommend to include a parameter to set the maximum number of iterations of the implicit Euler algorithm. This could allow to implement almost-real-time algorithms with a fixed number (possibly only one) iteration, which will lose some accuracy during fast and large transients, but on the other hand ensure a bounded computation time for a single step." Francesco Casella 3074 Insufficient information about assertion violations Backend trunk 2.0.0 defect Willi Braun accepted 2015-01-13T09:52:07Z 2017-08-31T20:51:00Z "Apologies, the first issue of this ticket was wrong due to a typo in the code. I have modified it to reflect the actual status with the corrected code. Please consider the attached test package, which demonstrates how OMC does not provide essential information to the user when handling asserts. Simulate TestWarningConstant. You get the following warning message: Warning: Variable x is probably too big Unfortunately, the message doesn't tell you an essential piece of information, i.e., ''where'' in the model M has this error been triggered. Is it m1, m2 or m3? It also doesn't tell ''when'' the warning has been triggered One option is to enhance the error message like this: The following assertion has been violated at initialization: m3.x < 5 Warning: Variable x is probably too big Simulate TestWarningVariable. You get the same message as before Warning: Variable x is probably too big you should get something like: The following assertion has been violated at time = 0.8333 m3.x < 5 Warning: Variable x is probably too big Simulate TestWarningRecurring. You still get Warning: Variable x is probably too big According to the non-normative text of the Modelica Specification, Section 8.3.7, you should get something like The following assertion has been violated at time = 0.1577 m3.x < 5 Warning: Variable x is probably too big The following assertion is no longer violated at time = 0.3465 m3.x < 5 Warning: Variable x is probably too big Simulate TestErrorConstant. Here you should see: The following assertion has been violated at initialization: m2.x < 10 Error: Variable x is too big Simulate TestErrorVariable. The information here is quite confusing. What you should get here is The following assertion has been violated at time = 0.25 m2.x < 5 Warning: Variable x is probably too big The following assertion has been violated at time = 0.5 m2.x < 10 Error: Variable x is too big Incidentally, I think the ""Process crashed"" final message in the last case is inappropriate. It seem to hint to the fact that some uncontrolled error has taken place, such as a memory access violation in some external function, which is definitely not the case here. Evertything here is under control and we have reported the reason for the simulation to stop. I would suggest to use ""Process aborted"", which seems more appropriate." Francesco Casella 3221 Equation count of models containing expandable connectors New Instantiation trunk 2.0.0 defect Mahder Alemseged Gebremedhin assigned 2015-03-15T11:08:11Z 2017-10-12T12:29:40Z "Consider the following code {{{ package ExpandableConn model IntegInput Modelica.Blocks.Interfaces.RealInput u; Modelica.Blocks.Continuous.Integrator integrator; equation connect(integrator.u, u); end IntegInput; model IntegConn Modelica.Blocks.Continuous.Integrator integrator; Modelica.Icons.SignalBus conn; equation connect(integrator.u, conn.signal); end IntegConn; end ExpandableConn; }}} For me both models in the package should be balanced (=have the same number of equations and variables). Indeed Dymola reports 2 equations and variables in both cases. OM, instead, in the case of IntegConn reports three variables ad two equations. Then this model is inserted in to a larger one, the count gests balanced again. However i think the OM behaviour is worse. In fact one of the most beautiful characteristics of Modelica is that, when balanced models are connected to each other, the whole model stays balanced; when a large model is unbalanced, usually one expects to find where the unbalance comes from by looking at individual submodels: this OM counting technique makes this process more difficult. I must add that I've not checked what Modelica Specifications say about how to count model variables when expandable connectors are present." anonymous 5448 OMEdit fails to open model, previously Totally Saved Documentation v1.14.0-dev-nightly 2.0.0 defect Adeel Asghar reopened 2019-04-30T00:19:10Z 2019-07-12T13:16:27Z "Open model with dependencies on some libraries, Save Total, Open the saved file -> error: Unable to load the file/library. ""Only single non-structured entity is allowed to be stored in the file."" This kinda breaks the idea of Save Total, isnt it?" filip.jezek@… 5891 getEnvironmentVariable does not return any output Scripts v1.16.0-dev 2.0.0 defect somebody reopened 2020-03-13T10:43:20Z 2020-05-07T12:20:19Z "Trying in `(str, b) := Modelica.Utilities.System.getEnvironmentVariable(""Path"", false);` but it returns no output at all, not even with `getErrorString()`. I also tried running on OMSheel and also from command prompt the attached MOS script: {{{ loadModel(Modelica); (str, b) := Modelica.Utilities.System.getEnvironmentVariable(""Path""); getErrorString(); }}} that returned. {{{ C:\workspace\_modelica_temp>omc getEnv.mos true Error processing file: getEnv.mos # Error encountered! Exiting... # Please check the error message and the flags. Execution failed! }}} On Dymola2020, same command returns the expected values. Am I missing something?" dariomangoni@… 5986 Can't open wsl path from OMEdit under Windows OMEdit v1.16.0-dev 2.0.0 defect Adeel Asghar new 2020-05-28T10:53:43Z 2020-06-17T10:21:49Z "Under newer Windows 10 builds the Windows Subsystem for Linux (WSL) is included into the Windows Explorer. Similar to every file on your local drive you can navigate to your files inside a WSL distribution. When I try to open any file with OMEdit that is inside the WSL directory OMEdit is looking at the wrong location. For example when I have a file `test.mo` in my home directory of a Ubuntu 18.04 WSL I can access it from inside the WSL at `/home/myUserName/test.mo`and from the Windows Explorer at `\\wsl$\Ubuntu-18.04\home\myUserName/test.mo`. In OMEdit I can navigate to the file with the Explorer but then I get following error: {{{ Error has occured while loading the file/library /Ubuntu-18.04/home/myUserName/test.mo. Unable to load the file/library. The file /Ubuntu-18.04/home/myUserName/test.mo not found. }}} `\\wsl$` is available already for WSL1 since Windows 10 1903." Andreas Heuermann 6114 Unit checking scales with O(2^N) in case of large expressions involving +-*/ operators New Instantiation v1.16.0-dev 2.0.0 defect Per Östlund assigned 2020-09-08T16:48:11Z 2020-09-16T10:12:03Z "Open this model with OMEdit and press ""Check Model"": {{{ model EndlessCheck input Real u1, u2, u3, u4, u5, u6, u7, u8, u9, u10; input Real u11, u12, u13, u14, u15, u16, u17, u18, u19, u20; input Real u21, u22, u23, u24, u25, u26, u27, u28, u29, u30; input Real u31, u32, u33, u34, u35, u36, u37, u38, u39, u40; output Real y = u1 + u2 + u3 + u4 + u5 + u6 + u7 + u8 + u9 + u10 + u11 + u12 + u13 + u14 + u15 + u16 + u17 + u18 + u19 + u20 + u21 + u22 + u23 + u24 + u25 + u26 + u27 + u28 + u29 + u30 + u31 + u32 + u33 + u34 + u35 + u36 + u37 + u38 + u39 + u40; end EndlessCheck; }}}" Rüdiger Franke 6411 Improve zero crossing functions by using continuous expressions Run-time 1.16.1 2.0.0 defect Andreas Heuermann new 2021-03-08T18:31:59Z 2021-03-11T12:02:04Z "Zero crossing functions are currently implemented with discontinuous outputs. Conceptually speaking, {{{x > 2}}} is mapped into {{{ zcf = noEvent(if x > 2 then 1 else -1); }}} Solvers try to find the event time using iterative algorithms. IDA uses a modified secant method. With this implementation, it reduces to the bisection method, which halves the error at each iteration, or equivalently gains 3 decimal digits every 10 iterations. If we had a continuous zcf like {{{ zcf = x - 2 }}} the secant algorithm would converge in a single step. The question of course is how to handle more complicated conditions such as {{{ if x > 2 and y < 3 and isActive then ... }}} where {{{x}}} and {{{y}}} are Real variables and {{{isActive}}} is a boolean variables. A trivial discontinuous implementation is {{{ zcf = noEvent(if x > 2 and y < 3 and isActive) then 1 else -1) }}} but it won't be very efficient. A better one could be to consider {{{ zcf1 = x - 2; zcf2 = y - 3; }}} separately, or possibly to consider their product {{{ zcf = (x - 2)*(y - 3) }}} which will change the sign whenever one of the two conditions switches from false to true or vice-versa. " Francesco Casella 3661 Add a resimulate() function to the API *unknown* 2.0.0 enhancement somebody new 2016-02-02T16:35:12Z 2017-10-09T23:59:29Z "It would be really nice to have something like {{{ recompile=false }}} for simulate-appy. For example: {{{ simulate(A, simflags=""xxxx""); system(./A -yyyy); }}} is possible but, system() has other syntax under linux and windows. More native would be {{{ simulate(A, -simflags=""xxxx""); simulate(A, -simflags=""yyyy"",recompile=""false""); }}}" Vitalij Ruge 4389 Improve warnings and diagnostics for missing start attributes in nonlinear systems Run-time 2.0.0 enhancement somebody new 2017-04-08T11:05:00Z 2017-11-13T18:04:01Z "When the {{{-d=initialization}}} flag is turned on, OMC warns for all the iteration variables of nonlinear systems whose start attribute has not been modified and has thus the default value of zero. The rationale is that in case of trouble with the solver convergence, one should provide good enough start attributes for all those variables. In fact, this is not necessarily the case. Consider the following simple test case: {{{ loadString("" model Test Real x; Real y; Real z; Real w; equation x + 2*y - 3*z = 1; x - 3*y + 4*w = 10; 10*x - 3*y + 5*z = 0; (z-10)*(z+4) + y + w = 10; end Test; "");getErrorString(); setCommandLineOptions(""--maxSizeNonlinearTearing=0, -d=initialization"");getErrorString(); simulate(Test);getErrorString(); }}} where tearing has been disabled for simplicity. The system has one strong component containing all the four equations; however, the first three are in fact linear, only the fourth is non-linear. The Jacobian of the system is || 1|| -2|| 3|| 0|| || 1|| -3|| 0|| 4|| || 10|| -3|| 5|| 0|| || 0|| 1|| 2*z-6|| 1|| Now, solving the system with Newton-like methods actually means to recursively approximate the system with its linearized version around the current solution estimate. If the system is linear, the algorithm will converge to the solution no matter what the initial guess is, in one iteration for a pure Newton method, and in a few iteration for quasi-Newton methods. In this case it is obvious that the only start value which is relevant to achieve convergence is the value of {{{z}}}, which affect the linearized version of the system (i.e., its Jacobian). Providing a good initial guess of {{{z}}} means that the fourth equation is well approximated in the neighbourhood of the solution, while all the other ones are already linear, so they are already exact no matter what the start values are. A more interesting real-life application is large-scale electrical circuits, with only a few nonlinear components. For example, consider one large RLC circuit with one diode, whose equation is {{{I = I_0*(exp(-V/V_T)-1)}}}. It is apparent from the above discussion that it is only necessary to provide a good initial guess for the voltage V across the diode, while the initial guesses for all the other currents and voltages in the circuit, which do not affect the Jacobian, are basically useless. Summing up, instead of reporting the full list of iteration variables which do not have a start attribute, it would be much better to report only those ones which show up explicitly in the Jacobian. It could also be useful to report the list of initial guesses of all (and only) variables that show up in the Jacobian, so that in case of convergence problems one can focus on those values that are really relevant. In case tearing is used, the concept generalizes to selecting only those iteration variables which directly or indirectly influence the Jacobian - this would require some basic dependency analysis." Francesco Casella 4565 Model building statistics in Omedit OMEdit 2.0.0 enhancement Adeel Asghar reopened 2017-10-14T09:57:15Z 2017-12-05T16:23:36Z "OpenModelicaUsersGuide.pdf in section 1.2.5 shows simulation of a DC motor and displays interesting timing statistics: {{{ timeFrontend = 0.244445734, timeBackend = 0.011048542, timeSimCode = 0.042049415, timeTemplates = 0.027458789, timeCompile = 0.394855691, timeSimulation = 0.014914653, timeTotal = 0.7349152410000001 }}} When models are compiled and run from OMEdit only statistics related to the final running of the model are available. Is it possible to find a way to convey also these timings in the OMEdit output? Very often (as in the DC motor example) more time is spent in preparing the final executable than in the execution itself." anonymous 4633 [MetaModelica] skip cases for partial matches MetaModelica v1.13.0-dev-nightly 2.0.0 enhancement Martin Sjölund new 2017-11-17T10:03:31Z 2017-11-17T10:19:30Z "There are many match expressions with multiple arguments in OMCompiler. Take {{{ExpressionSimplify.simplifyBinary2()}}} as an example: the second argument is the operator of a binary expression. There are many cases with DAE.ADD, DAE.SUB, DAE.MUL, DAE.DIV, etc. cluttered in the cases. If this first expression matches, the match-iterator could be advanced to the next case that matches this part as well." Henning Kiel 5442 Sorting classes OMEdit v1.14.0-dev-nightly 2.0.0 enhancement Adeel Asghar new 2019-04-18T21:18:58Z 2019-04-18T21:18:58Z "It would be useful to have the possibility to sort alphabetically classes. This would be especially true with Modelica.SIunits, since these are many, they are not alphabetically ordered, and ordering them would ease searching a unit significantly" massimo ceraolo 5635 Multi(---) connection issue OMEdit 2.0.0 enhancement Adeel Asghar assigned 2019-09-12T21:42:55Z 2019-10-15T10:24:26Z "In OpenModelica, 1. it allows to make the connection between two vectorized connectors even when the parameter that is used for specifying the connector size has not been declared. For example in below case, I can still make the connection even when the nZon has not been declared. {{{ #!modelica Buildings.Controls.OBC.CDL.Continuous.Sources.Constant con1[nZon](k = 1) annotation(Placement(visible = true, transformation(extent = {{-60, -60}, {-40, -40}}, rotation = 0))); Buildings.Controls.OBC.CDL.Continuous.MultiMax multiMax1(nin=nZon) annotation(Placement(visible = true, transformation(extent = {{-12, -60}, {8, -40}}, rotation = 0))); equation connect(con1.y, multiMax1.u) annotation(Line(points = {{-38, -50}, {-14, -50}, {-14, -50}, {-14, -50}}, color = {0, 0, 127}, thickness = 0.5)); }}} 2. it allows to make the connection between two vectorized connectors which have different size. The auto-generated connection statement does not specify the element-to-element connection between the two connector. For example in below case, output connector vector of con1 has size 2 and input connector vector of multiMax1 has size 3, the connection is still allowed. {{{ #!modelica Buildings.Controls.OBC.CDL.Continuous.Sources.Constant con1[2](k = 1) annotation(Placement(visible = true, transformation(extent = {{-60, -60}, {-40, -40}}, rotation = 0))); Buildings.Controls.OBC.CDL.Continuous.MultiMax multiMax1(nin=3) annotation(Placement(visible = true, transformation(extent = {{-12, -60}, {8, -40}}, rotation = 0))); equation connect(con1.y, multiMax1.u) annotation(Line(points = {{-38, -50}, {-14, -50}, {-14, -50}, {-14, -50}}, color = {0, 0, 127}, thickness = 0.5)); }}} " jianjunhu@… 1080 Constraining type on redeclarations (from MathCore) New Instantiation trunk 2.1.0 defect krsta new 2009-03-16T16:06:28Z 2018-07-02T14:41:02Z Check that the constraining type on redeclarations is not violated. krsta 2276 detecting size mismatch for output arguments in functions New Instantiation trunk 2.1.0 defect somebody reopened 2013-07-04T18:09:10Z 2018-07-02T13:43:50Z "Following model runs into an segmentation fault, since we set the unknown size to 99. {{{ model test1 function f1 input Real u; output Real y[:]; algorithm for i in 1:5 loop y[i] := i+u; end for; end f1; Real z[5]; equation z = f1(time); end test1; }}} But it should end up with an flatting error like the constant case. {{{ model test1 function f1 output Real y[:]; // unknown size algorithm for i in 1:5 loop y[i] := i; end for; end f1; Real z[5]; equation z = f1(); end test1; }}} {{{ [:50:3-50:11:writable] Error: Array equation has unknown size in {z[1], z[2], z[3], z[4], z[5]}={1.0, 2.0, 3.0, 4.0, 5.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0}. [:50:3-50:11:writable] Error: Type mismatch in equation {z[1], z[2], z[3], z[4], z[5]}={1.0, 2.0, 3.0, 4.0, 5.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0} of type Real[5]=Real[:]. Error: Error occurred while flattening model test1 }}} " Willi Braun 4843 NF doesn't evaluate size expression of function input parameters New Instantiation v1.13.0-dev-nightly 2.1.0 defect Per Östlund new 2018-03-27T08:52:14Z 2018-12-11T21:55:26Z "The new frontend only types function parameters when typing the function itself, without taking input arguments into account. When typing a function call it should reevaluate the types of the parameters based in the input arguments, so that it catches error like this (where the function should only take a square matrix): {{{#!mo function f input Real x[:, size(x, 1)]; end f; model M algorithm f({{1, 2, 3}, {3, 4, 5}}); end M; }}}" Per Östlund 5178 Incorrect Warning - not balanced connector New Instantiation 2.1.0 defect Per Östlund reopened 2018-10-18T06:07:11Z 2018-12-11T21:56:40Z "In the following code all variables inside AA should have prefix input, and since that there should be no message about ""unbalanced connector AA"", but this message apeears when instantiating AA. {{{ class test connector A Real x; end A; connector AA = input A; end test; }}} " igor.timofeyev@… 1081 Restrictions on redeclarations (from MathCore) Future defect krsta new 2009-03-16T16:07:40Z 2016-02-05T09:58:52Z Implement the restrictions on redeclarations. (subtype, etc.) krsta 1211 Nested der-expressions generates invalid simulation code Backend trunk Future defect somebody assigned 2010-04-28T11:41:03Z 2017-10-19T12:28:15Z "Nested der-expressions seems to cause Exp.solve to fail, which causes generation of simulation code that doesn't compile. Example model: {{{ class MyRealEquation Real x(start=0); equation 100 - 20*der(x) + der(x)*der(x) = 40*der(der(x)); end MyRealEquation; }}}" Per Östlund 1677 Missing check of 7.1.3 Restrictions on the Kind of Base Class Future defect Martin Sjölund new 2012-01-10T13:52:29Z 2016-02-05T09:58:52Z "The following is illegal: {{{model M end M; function f extends M; end f; model N algorithm f(); end N;}}} See also https://trac.modelica.org/Modelica/ticket/679" Martin Sjölund 2205 Documentation generator needs to handle and sections correctly Build Environment trunk Future defect Martin Sjölund new 2013-05-24T23:21:30Z 2017-11-14T22:08:53Z "I noticed a small problem with the documentation generation script `GenerateDoc.mos`: If a model contains already a ` ... ` and/or ` ... ` section in the info layer then the resulting HTML will contain two of them. It seems that two head sections are not such a big problem but tidy does not like to have content after the `` tag. Now the one file that is almost always going to cause this problem is the `ModelicaLicense2` class because the template has exactly this structure. Funnily enough in `Modelica.UsersGuide.ModelicaLicense2` the `` tags have been removed which means no warnings in from tidy. Solution could look like something like this: * look for ` ... ` and if more than one then merge the content into one. At the same time only keep one `` (otherwise there will be a warning again) * look for `<body>`, keep first instance and discard all following. * look for `</body>`, keep only the ''last'' instance" Dietmar Winkler 2433 For loop indexes used in relations in algorithms are undefined for zero crossings Backend trunk Future defect Willi Braun new 2013-10-22T16:07:40Z 2017-11-14T22:08:53Z " {{{ algorithm for s in 1:N loop for z in 1:N loop Lm[z,s]:= if (z>=s) then L[(s-1)*N+z-div((s-1)*s,2)] else Lm[s,z]; end for; end for; }}} See also here: https://openmodelica.org/index.php/forum/topic?id=1021 You get that $Ps is undefined in the C code." Adrian Pop 2443 Bootstrapped compiler wish list MetaModelica trunk Future defect Martin Sjölund new 2013-10-25T12:22:52Z 2017-11-14T22:08:53Z "Here is a list of what me and Per talked about: 1. Include the uniontype path to the uniontype record, i.e. Abyn.Path.IDENT 2. Make it possible to use Absyn.Path.IDENT.name instead of matching for it. Make also possible to use Absyn.Path.IDENT.name = x; This will make writing of set/get functions much easier. 3. Support anonymous records from uniontypes in crefs or paths, i.e. DAE.Equation._.info = newInfo; This will bind the component named info form any record inside DAE.Equation to newInfo; 4. Support opaque types and type methods. I.e. {{{ package P type X protected type Name; function fGet(Name) => something; function fSet(Name) => something; end X; end P; }}} Add more here if you want to." Adrian Pop 2456 Change the garbage collector Code Generation trunk Future defect Martin Sjölund accepted 2013-10-31T15:45:41Z 2013-10-31T15:45:56Z "We need to change our data structures slightly in order to achieve a better performance and perhaps remove the need for boxptr-functions (marshalling, box/unbox). (16:22:18) Martin Sjölund: I think in general the way we tag pointers is wrong (16:22:32) Martin Sjölund: we should tag integers instead (16:22:33) Adrian Pop: yes, probably tagging pointers is confusing the hell out of GC (16:22:49) Adrian Pop: we could probably not tag anything anymore (16:23:03) Martin Sjölund: maybe (16:23:11) Adrian Pop: as that is needed only for the previous RML gc (16:23:19) Adrian Pop: and have 32 bit integers (16:23:49) Martin Sjölund: !!! (16:23:55) Martin Sjölund: that would be great actually (16:24:19) Martin Sjölund: would probably be a good performance boost, too (16:24:23) Adrian Pop: the only problem i think it might be with debugging (16:24:40) Martin Sjölund: only problem is knowing what is integer and what is not (16:25:15) Martin Sjölund: or we box integers too (16:28:56) Martin Sjölund: I mean... allocating data could be as simple as: void*[2] = {header,double_word}; // 64-bit void*[3] = {header,double_word1,double_word2}; // 32-bit void*[2] = {header,word}; // 32-bit, 64-bit char*[2] = {headerbyte1,headerbyte2,headerbyte3,headerbyte4,char1,...,charn}; // 32-bit, 64-bit (16:30:28) Martin Sjölund: since GC is simplified, we need less bits for book-keeping too (16:31:22) Martin Sjölund: could just be a bitset for int|double|enum|string|list|option|record = 3 bits to tag what data it is (16:31:32) Adrian Pop: true (16:32:21) Martin Sjölund: runtime could be quite simple with that (16:32:47) Martin Sjölund: oh, I forgot array as type (of course) (16:33:14) Martin Sjölund: but still 3 bits... and arrays could have 3 bits to say what is stored in it (same 8 types) (16:33:51) Martin Sjölund: and same for lists (16:34:09) Martin Sjölund: lists of unboxed data could be cool (16:35:06) Martin Sjölund: and I guess 28-bit arrays still fine length (16:37:03) Martin Sjölund: and uniontypes with only atomic members (many of them) could be allocated atomic too... (16:37:10) Martin Sjölund: so many things that can be done... (16:37:20) Adrian Pop: :) (16:37:35) Martin Sjölund: do you think we should move in this direction? (16:38:09) Martin Sjölund: before we rely too much on the eclipse debugger :D (16:38:26) Adrian Pop: i think we should not do that yet (16:38:38) Adrian Pop: wait until we move to the bootstrapped compiler (16:38:46) Adrian Pop: and then we can do changes" Martin Sjölund 2498 simulation fails with measureTime=true Run-time trunk Future defect Martin Sjölund new 2013-12-03T13:25:05Z 2017-11-14T22:08:53Z "Hi, While running the msl 3.2 with measureTime=true some models are failing when simulated. Its always because an assert was called, like in Modelica.Blocks.Examples.Filter : {{{assert | assert | Referenced 'CriticalDamping.cr' that was not declared as <variable>}}} Here the variable CriticalDamping.cr is actually an array and possibly occurs just as CriticalDamping[i] in the variables and therefore cannot be found. This assert comes from SimulationRuntime/c/simulation/simulation_info_xml.c line 72. The if where the measureTime flag is checked is in startNonInteractiveSimulation i.e. in simulation_runtime.cpp line 519. " Volker Waurich 2609 "BackendDAE modules ""removedUnusedFunction"" hides other bugs." Backend trunk Future defect probably noone new 2014-03-04T15:32:56Z 2017-11-14T22:08:53Z "The module postOptModule ""removedUnusedFunction"" should be neutral in terms of functionality to our testsuite, but it isn't. Following results when it's deactivated: {{{ Failed tests: ./openmodelica/cppruntime/libraries/msl32/Modelica.Electrical.QuasiStationary.SinglePhase.Examples.ParallelResonance.mos ./openmodelica/cppruntime/libraries/msl32/Modelica.Mechanics.MultiBody.Examples.Elementary.DoublePendulum.mos ./openmodelica/cppruntime/libraries/msl32/Modelica.Mechanics.MultiBody.Examples.Elementary.RollingWheelSetDriving.mos ./openmodelica/debugDumps/optdaedump.mos // doesn't matter ./simulation/libraries/msl31/media/Modelica.Media.Examples.Tests.MediaTestModels.Air.DryAirNasa.mos ./simulation/libraries/msl31/media/Modelica.Media.Examples.Tests.MediaTestModels.Air.MoistAir.mos ./simulation/libraries/msl31/media/Modelica.Media.Examples.Tests.MediaTestModels.IdealGases.Air.mos ./simulation/libraries/msl31/media/Modelica.Media.Examples.Tests.MediaTestModels.IdealGases.Nitrogen.mos ./simulation/libraries/msl31/media/Modelica.Media.Examples.Tests.MediaTestModels.IdealGases.SimpleNaturalGas.mos ./simulation/libraries/msl31/media/Modelica.Media.Examples.Tests.MediaTestModels.IdealGases.SimpleNaturalGasFixedComposition.mos ./simulation/libraries/msl31/media/Modelica.Media.Examples.Tests.MediaTestModels.Water.IdealSteam.mos ./simulation/libraries/msl31/media/Modelica.Media.Examples.Tests.MediaTestModels.Water.WaterIF97OnePhase_ph.mos ./simulation/libraries/msl31/media/Modelica.Media.Examples.Tests.MediaTestModels.Water.WaterIF97_pT.mos ./simulation/libraries/msl31/media/Modelica.Media.Examples.Tests.MediaTestModels.Water.WaterIF97_ph.mos ./simulation/libraries/msl32/Modelica.Fluid.Examples.AST_BatchPlant.Test.TankWithEmptyingPipe1.mos ./simulation/libraries/msl32/Modelica.Fluid.Examples.AST_BatchPlant.Test.TankWithEmptyingPipe2.mos ./simulation/libraries/msl32/Modelica.Fluid.Examples.AST_BatchPlant.Test.TanksWithEmptyingPipe1.mos ./simulation/libraries/msl32/Modelica.Fluid.Examples.AST_BatchPlant.Test.TanksWithEmptyingPipe2.mos ./simulation/libraries/msl32/Modelica.Fluid.Examples.AST_BatchPlant.Test.TwoTanks.mos ./simulation/libraries/msl32/Modelica.Fluid.Examples.BranchingDynamicPipes.mos ./simulation/libraries/msl32/Modelica.Fluid.Examples.TraceSubstances.RoomCO2.mos ./simulation/libraries/msl32/Modelica.Fluid.Examples.TraceSubstances.RoomCO2WithControls.mos ./simulation/modelica/algorithms_functions/ForIterator2.mos ./simulation/modelica/hpcom/Modelica.Fluid.Examples.BranchingDynamicPipes.mos // duplicated 24 of 2508 failed }}} So actually this are only 22 failing test, but as far as I see this are only 4 different issues. So will create separated tickets for them. For: {{{ ./simulation/libraries/msl31/media/Modelica.Media.Examples.Tests.MediaTestModels.Air.DryAirNasa.mos ./simulation/libraries/msl31/media/Modelica.Media.Examples.Tests.MediaTestModels.Air.MoistAir.mos ./simulation/libraries/msl31/media/Modelica.Media.Examples.Tests.MediaTestModels.IdealGases.Air.mos ./simulation/libraries/msl31/media/Modelica.Media.Examples.Tests.MediaTestModels.IdealGases.Nitrogen.mos ./simulation/libraries/msl31/media/Modelica.Media.Examples.Tests.MediaTestModels.IdealGases.SimpleNaturalGas.mos ./simulation/libraries/msl31/media/Modelica.Media.Examples.Tests.MediaTestModels.IdealGases.SimpleNaturalGasFixedComposition.mos ./simulation/libraries/msl31/media/Modelica.Media.Examples.Tests.MediaTestModels.Water.IdealSteam.mos ./simulation/libraries/msl31/media/Modelica.Media.Examples.Tests.MediaTestModels.Water.WaterIF97OnePhase_ph.mos ./simulation/libraries/msl31/media/Modelica.Media.Examples.Tests.MediaTestModels.Water.WaterIF97_pT.mos ./simulation/libraries/msl31/media }}} the issue is: State by [comment:1 sjoelund.se]: > They are not missing functions: they are partial functions that should never have been added... {{{ Modelica.Media.Examples.Tests.MediaTestModels.Air.MoistAir_functions.c: In function ‘omc_Modelica_Media_Interfaces_PartialMedium_specificEnthalpy__pTX’: Modelica.Media.Examples.Tests.MediaTestModels.Air.MoistAir_functions.c:4883: error: ‘Modelica_Media_Interfaces_PartialMedium_setState__pTX_rettype’ undeclared (first use in this function) Modelica.Media.Examples.Tests.MediaTestModels.Air.MoistAir_functions.c:4883: error: expected ‘;’ before ‘tmp2’ Modelica.Media.Examples.Tests.MediaTestModels.Air.MoistAir_functions.c:4884: error: ‘Modelica_Media_Interfaces_PartialMedium_specificEnthalpy_rettype’ undeclared (first use in this function) Modelica.Media.Examples.Tests.MediaTestModels.Air.MoistAir_functions.c:4884: error: expected ‘;’ before ‘tmp3’ Modelica.Media.Examples.Tests.MediaTestModels.Air.MoistAir_functions.c:4889: error: ‘tmp2’ undeclared (first use in this function) Modelica.Media.Examples.Tests.MediaTestModels.Air.MoistAir_functions.c:4890: error: ‘tmp3’ undeclared (first use in this function) Modelica.Media.Examples.Tests.MediaTestModels.Air.MoistAir_functions.c: In function ‘omc_Modelica_Media_Interfaces_PartialMixtureMedium_specificEnthalpy__pTX’: Modelica.Media.Examples.Tests.MediaTestModels.Air.MoistAir_functions.c:4908: error: ‘Modelica_Media_Interfaces_PartialMixtureMedium_setState__pTX_rettype’ undeclared (first use in this function) Modelica.Media.Examples.Tests.MediaTestModels.Air.MoistAir_functions.c:4908: error: expected ‘;’ before ‘tmp2’ Modelica.Media.Examples.Tests.MediaTestModels.Air.MoistAir_functions.c:4909: error: ‘Modelica_Media_Interfaces_PartialMixtureMedium_specificEnthalpy_rettype’ undeclared (first use in this function) Modelica.Media.Examples.Tests.MediaTestModels.Air.MoistAir_functions.c:4909: error: expected ‘;’ before ‘tmp3’ Modelica.Media.Examples.Tests.MediaTestModels.Air.MoistAir_functions.c:4914: error: ‘tmp2’ undeclared (first use in this function) Modelica.Media.Examples.Tests.MediaTestModels.Air.MoistAir_functions.c:4915: error: ‘tmp3’ undeclared (first use in this function) }}} For: {{{ ./simulation/libraries/msl32/Modelica.Fluid.Examples.BranchingDynamicPipes.mos ./simulation/libraries/msl32/Modelica.Fluid.Examples.TraceSubstances.RoomCO2.mos ./simulation/libraries/msl32/Modelica.Fluid.Examples.TraceSubstances.RoomCO2WithControls.mos }}} it seems that something in instantiation of function with constants is going wrong, since ""_TinK"", ""_poly_Cp"" and ""_poly_rho"" are constants in package. {{{ Modelica.Fluid.Examples.BranchingDynamicPipes_functions.c: In function 'omc_Modelica_Media_Incompressible_TableBased_h__T__der': Modelica.Fluid.Examples.BranchingDynamicPipes_functions.c:8790: error: '_TinK' undeclared (first use in this function) Modelica.Fluid.Examples.BranchingDynamicPipes_functions.c:8790: error: (Each undeclared identifier is reported only once Modelica.Fluid.Examples.BranchingDynamicPipes_functions.c:8790: error: for each function it appears in.) Modelica.Fluid.Examples.BranchingDynamicPipes_functions.c:8800: error: '_poly_Cp' undeclared (first use in this function) Modelica.Fluid.Examples.BranchingDynamicPipes_functions.c: In function 'omc_Modelica_Media_Incompressible_TableBased_h__T': Modelica.Fluid.Examples.BranchingDynamicPipes_functions.c:8829: error: '_TinK' undeclared (first use in this function) Modelica.Fluid.Examples.BranchingDynamicPipes_functions.c:8849: error: '_poly_Cp' undeclared (first use in this function) Modelica.Fluid.Examples.BranchingDynamicPipes_functions.c: In function 'omc_Modelica_Media_Incompressible_TableBased_h__pT': Modelica.Fluid.Examples.BranchingDynamicPipes_functions.c:8892: error: '_TinK' undeclared (first use in this function) Modelica.Fluid.Examples.BranchingDynamicPipes_functions.c:8912: error: '_poly_Cp' undeclared (first use in this function) Modelica.Fluid.Examples.BranchingDynamicPipes_functions.c:8926: error: '_poly_rho' undeclared (first use in this function) }}} For ./simulation/modelica/algorithms_functions/ForIterator2.mos we have some code generation issues with arrays. But I have no idea what kind of issue the cppruntime tests have. Does anybody something about that issue? I hope it was not the propose of this module to fix this issue;) " Willi Braun 2651 Definitions in SimulationRuntime/c/openmodelica.h and SimulationRuntime/c/simulation/solver/libf2c/f2c.h do not match for 64-bit systems Run-time trunk Future defect somebody new 2014-04-04T14:30:16Z 2017-11-14T22:08:53Z "In SimulationRuntime/c/openmodelica.h (line 91) the following definitions can be found {{{ #if defined(__alpha__) || defined(__sparc64__) || defined(__x86_64__) || defined(__ia64__) typedef int fortran_integer; typedef unsigned int fortran_uinteger; #else typedef long int fortran_integer; typedef unsigned long int fortran_uinteger; #endif }}} whereas in SimulationRuntime/c/simulation/solver/libf2c/f2c.h (line 10) the following is defined. {{{ typedef long int integer; typedef unsigned long int uinteger; }}} When arguments of the type fortran_integer* are passed to functions expecting integer* (as for instance in the dasrt solver) this leads to problems on 64-bit systems, causing for instance the dasrt solver to abort. Using a newer version of f2c.h fixed the issue for me, but since I'm not sure what other parts depend on the f2c.h header file, I don't want to patch this file right now. " Michael Kloeppel 2700 Not balanced connectors should generate an error Frontend trunk Future defect somebody new 2014-05-20T09:13:20Z 2017-11-14T22:08:53Z "Create the model: {{{ connector notValid // illegal connector Real r1; Real r2; flow Real r3; end notValid; }}} Validate the model '''Expected Result:''' An error, this is an example of illegal modelica from the modelica spec. '''Received Results:''' Warning: Connector .notValid is not balanced: The number of potential variables (2) is not equal to the number of flow variables (1)." Karin Gustafsson 2805 Array of Records Frontend trunk Future defect somebody new 2014-09-06T12:27:18Z 2014-09-06T19:06:28Z "There some issues with Arrays of Records, which has variable Array size. {{{ package MyRecord record arrayRecord Real[:] v; end arrayRecord; model test1 ""work"" arrayRecord r[2] = {arrayRecord({1}), arrayRecord({1, 2})}; end test1; model test2 ""don't work"" arrayRecord r1 = arrayRecord({1}); arrayRecord r2 = arrayRecord({1, 2}); arrayRecord r[2] = {r1, r2}; end test2; model test3 ""don't work"" function f input arrayRecord in_r; output arrayRecord out_r = in_r; end f; arrayRecord r1 = arrayRecord({1}); arrayRecord r2 = arrayRecord({1, 2}); arrayRecord r[2] = {f(r1), f(r2)}; end test3; model test4 ""work"" function f input arrayRecord in_r; output arrayRecord out_r = in_r; end f; constant arrayRecord r1 = arrayRecord({1}); constant arrayRecord r2 = arrayRecord({1, 2}); arrayRecord r[2] = {f(r1), f(r2)}; end test4; end MyRecord; }}} " Vitalij Ruge 2979 Underscores in function pointer names causes invalid generated code Code Generation trunk Future defect Lennart Ochel new 2014-11-11T17:57:51Z 2014-11-12T07:19:55Z "This model fails to compile, because in the generated code a variable called _func_ptr is declared and assigned, but _func!__ptr is instead used when trying to call the function. {{{#!mo function f output Real x := 3; end f; function test output Real x; protected partial function FuncType output Real x; end FuncType; FuncType func_ptr := f; algorithm x := func_ptr(); end test; }}}" Per Östlund 2986 Trying to use a partial function gives linker error instead of compilation error MetaModelica trunk Future defect somebody new 2014-11-17T15:17:16Z 2020-12-01T15:01:18Z "Trying to run this: {{{#!mo function f input FuncType inFunc; input Real x; output Real y := FuncType(x); // This is wrong, should be inFunc(x) partial function FuncType input Real x; output Real y; end FuncType; end f; function f2 input Real x; output Real y := 2 * x; end f2; function test output Real x := f(f2, 3.0); end test; }}} gives the error {{{ ""Error: OMC unable to load `./test.so': ./test.so: undefined symbol: omc_f_FuncType. }}} It would be better if it gave an error for trying to use a partial function instead." Per Östlund 3007 OmOptim OMOptim trunk Future defect karinasouzapk@… new 2014-11-27T14:32:55Z 2014-11-27T14:32:55Z "Hi I work with OpenModelica and now I need to optimize some parameters. I want to use OmOptim but I'm in trouble. My variables are not read in this software. In the screen this message appears: Modelica Error: impossible to get class components ... I need to know the version that was used in the manual (Open Modelica and OmOptim (the correct update)). I tried many versions of this software, but I still fails. Can I use OmOptim for optimization? The OmOptim is working well? Thank you so much." karinasouzapk@… 3017 Generate warning for unbound constants Frontend trunk Future defect somebody new 2014-12-05T15:01:51Z 2014-12-05T15:01:51Z "It would be nice if a warning were created for constants without binding, e.g. for x in the model below: {{{ model Model1 constant Real x; Real y(start = 1.0); equation y = x*der(y); end Model1; }}} " carlj@… 3020 Custom annotation cannot be read and proposed code changes to interactive.mo Interactive Environment 1.8.0 Future defect Adrian Pop assigned 2014-12-08T14:35:31Z 2016-10-11T08:51:56Z "The functions to read the component annotations try to parse the content of said annotation and fail if the format is different than the one expected. Example OMShell commands demonstrating the problem follows. The first commands creates the problematic annotation. The second tries to read it. {{{ loadString(""model Test parameter Real v = 0 annotation(__MyTag(name = \""<String>\"")); end Test;""); getComponentAnnotations(Test); -> {{__MyTag(error)}} }}} The proposed modifications to “interactive.mo” allow to get the raw (unparsed) annotation circumventing the current annotation interpretation code. Note: the modifications to interactive.mo were made to version 10683 of OpenModelica but the added code could probably be used almost unmodified in the current versions. The reference interactive.mo version 10683 and the modified version are both provided to enable a diff between the two. Here’s a resume of the changes to interactive.mo version 10683 1) The following functions were added to interactive.mo: ------------------------------------ getComponentAnnotationsAsStr getComponentAnnotationsFromEltsAsStr getComponentitemsAnnotationsAsStr getComponentitemsAnnotationsFromItemsAsStr getNthComponentAnnotationAsStr getComponentAnnotationAsStr 2) New case items to handle calls to getComponentAnnotationsAsStr and getNthComponentAnnotationAsStr were added to function evaluateGraphicalApi_dispatch(): {{{ // CSA Addons: Dec 14, 2011. C.Adourian case (istmts, st as SYMBOLTABLE(ast = p)) equation matchApiFunction(istmts, ""getComponentAnnotationsAsStr""); {Absyn.CREF(componentRef = cr)} = getApiFunctionArgs(istmts); ErrorExt.setCheckpoint(""getComponentAnnotationsAsStr""); Config.setEvaluateParametersInAnnotations(true); resstr = getComponentAnnotationsAsStr(cr, p); Config.setEvaluateParametersInAnnotations(false); ErrorExt.rollBack(""getComponentAnnotationsAsStr""); then (resstr,st); // CSA Addons: Dec 14, 2011. C.Adourian case (istmts, st as SYMBOLTABLE(ast = p)) equation matchApiFunction(istmts, ""getNthComponentAnnotationAsStr""); {Absyn.CREF(componentRef = cr),Absyn.INTEGER(value = n)} = getApiFunctionArgs(istmts); ErrorExt.setCheckpoint(""getNthComponentAnnotationAsStr""); Config.setEvaluateParametersInAnnotations(true); resstr = getNthComponentAnnotationAsStr(cr, p, n); Config.setEvaluateParametersInAnnotations(false); ErrorExt.rollBack(""getNthComponentAnnotationAsStr""); then (resstr,st); }}}" anonymous 3045 Erroneous Nominal min and max for swArc component Backend trunk Future defect somebody assigned 2014-12-19T16:55:03Z 2016-04-03T19:46:11Z "The enclosed component ""sparkGeneration"", when run with r23772 creates the error message shown below. It seems there is an error in the translation of component Modelica.Electrical.Analog.Ideal.CloserWithArc. {{{ ERROR MESSAGE ""C:\OpenModelica\\MinGW\bin\mingw32-make.exe"" -j4 -f sparkGeneration.makefile gcc -falign-functions -msse2 -mfpmath=sse -I""C:/OpenModelica//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o sparkGeneration.o sparkGeneration.c gcc -falign-functions -msse2 -mfpmath=sse -I""C:/OpenModelica//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o sparkGeneration_functions.o sparkGeneration_functions.c gcc -falign-functions -msse2 -mfpmath=sse -I""C:/OpenModelica//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o sparkGeneration_records.o sparkGeneration_records.c gcc -falign-functions -msse2 -mfpmath=sse -I""C:/OpenModelica//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o sparkGeneration_01exo.o sparkGeneration_01exo.c gcc -falign-functions -msse2 -mfpmath=sse -I""C:/OpenModelica//include/omc/c"" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o sparkGeneration_02nls.o sparkGeneration_02nls.c sparkGeneration.c: In function 'sparkGeneration_eqFunction_48': sparkGeneration.c:154: error: 'BOOLEAN_ATTRIBUTE' has no member named 'min' sparkGeneration.c:154: error: 'BOOLEAN_ATTRIBUTE' has no member named 'max' mingw32-make: *** [sparkGeneration.o] Error 1 mingw32-make: *** Waiting for unfinished jobs.... sparkGeneration_02nls.c: In function 'initializeStaticNLSData23': sparkGeneration_02nls.c:77: error: 'BOOLEAN_ATTRIBUTE' has no member named 'nominal' sparkGeneration_02nls.c:78: error: 'BOOLEAN_ATTRIBUTE' has no member named 'min' sparkGeneration_02nls.c:79: error: 'BOOLEAN_ATTRIBUTE' has no member named 'max' sparkGeneration_02nls.c: In function 'initializeStaticNLSData48': sparkGeneration_02nls.c:178: error: 'BOOLEAN_ATTRIBUTE' has no member named 'nominal' sparkGeneration_02nls.c:179: error: 'BOOLEAN_ATTRIBUTE' has no member named 'min' sparkGeneration_02nls.c:180: error: 'BOOLEAN_ATTRIBUTE' has no member named 'max' mingw32-make: *** [sparkGeneration_02nls.o] Error 1 Compilation process exited with code 2 }}}" anonymous 3112 Interactive execution of functions fail in for loops sometimes Interactive Environment trunk Future defect somebody new 2015-01-29T12:27:22Z 2015-01-29T12:27:22Z "It seems there's something that goes wrong if a function that calls another function is called inside a for loop in a mos-script and CevalFunction fails on it. Running the attached script causes the function to be executed once, and the next call then fails with an error message: {{{ [SimCode/SimCodeUtil.mo:8699:9-8699:50:writable] Error: Internal error function getCalledFunctionsInFunction2: Class f1 not found in global scope. }}} The issue only seem to occur inside a for loop, calling the function multiple times works fine without the loop. Calling the function multiple times inside the for-loop still causes it to fail after the first call though." Per Östlund 3197 Better optimization support in OMEdit OMEdit trunk Future defect Adeel Asghar new 2015-03-09T09:12:15Z 2021-11-07T06:54:31Z There's currently no support for doing an optimization in OMEdit, except for calling the optimize API manually from the command line. This needs to be made more user friendly so that normal users can do optimizations in OMEdit, either by adding a button in the toolbar or some other way. Per Östlund 3229 Make the start value of NLS iteration variable changeable in OMEdit Backend trunk Future defect somebody new 2015-03-16T15:32:51Z 2015-03-16T15:32:51Z Currently all algebraic variable are marked as not changeable in the sense, that the start value is not changeable. This should changed for NLS iteration variables of the initialization system. Willi Braun 3252 Abnormal memory consumption during compilation of models with inlined functions and symbolic differentiation Backend trunk Future defect Volker Waurich assigned 2015-03-30T22:11:22Z 2017-11-16T12:23:33Z "Please consider the SmoothSat model in the attached Save Total file. The inline smoothSat function {{{ function smoothSat ""Smooth saturation function"" input Real x; input Real xmin ""Lower bound of range where y = x""; input Real xmax ""Upper bound of range where y = x""; input Real dxmin ""Width of lower smoothing range""; input Real dxmax=dxmin ""Width of upper smoothing range""; output Real y; algorithm y := if x < xmin + dxmin then xmin + dxmin - dxmin*(xmin + dxmin - x)/(dxmin^4 + (xmin + dxmin - x)^4)^0.25 else if x > xmax - dxmax then xmax - dxmax + dxmax*(x - xmax + dxmax)/(dxmax^4 + (x - xmax + dxmax)^4)^0.25 else x; annotation (smoothOrder=4, InLine=true); end smoothSat; }}} gets differentiated 5 times in the test model SmoothSat. The Cryogenics_Test_SmoothSat.c file defines about 10000 temporary expressions. Most of them are repeated a lot of times: for example, (1.0 + (0.1 - time)) is repeated 5021 times, (time + -1.7) is repeated 4520 times. When compiling the C code under MinGW with the default settings, cc1.exe allocates over 3 GB of memory (!). Removing the 5th differentiation brings down memory allocation to 300 MB. Differentiating an expression 5 times is probably a bit extreme (the idea was to check that the first 4 derivatives are continuous, and only the 5th is discontinuous), however there is something going badly wrong with common subexpressions in the differentiated functions, and I guess this is worth having a look at. " Francesco Casella 3297 building PythonInterface fails Build Environment trunk Future defect somebody new 2015-04-28T17:01:30Z 2015-04-28T17:03:36Z "On a 64-bit Linux system with python2.7 installed: {{{ # uname -orvip && python -V 3.18.11-gentoo #1 SMP Mon Apr 20 11:28:44 CEST 2015 Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz GenuineIntel GNU/Linux Python 2.7.9 }}} when configured with --enable-python-interface, compilation fails building PythonInterface: {{{ $ make # create directories mkdir -p ..//build/lib/python/omniORB mkdir -p ..//build/share/omc/scripts/PythonInterface/OMPython/OMParser omniidl -bpython -Wbglobal=_OMCIDL -Wbpackage=OMPythonIDL ..//Compiler/runtime/omc_communication.idl ! which python2.6 || python2.6 setup.py install --no-compile `test -d /etc/apt && echo --install-layout=deb` --prefix=..//build which: no python2.6 in (/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.4:/usr/lib64/subversion/bin:/usr/games/bin:/usr/share/omniORB/bin/scripts) ! which python2.7 || python2.7 setup.py install --no-compile `test -d /etc/apt && echo --install-layout=deb` --prefix=..//build /usr/bin/python2.7 running install Checking .pth file support in ..//build/lib64/python2.7/site-packages/ /usr/bin/python2.7 -E -c pass TEST FAILED: ..//build/lib64/python2.7/site-packages/ does NOT support .pth files error: bad install directory or PYTHONPATH You are attempting to install a package to a directory that is not on PYTHONPATH and which Python does not read "".pth"" files from. The installation directory you specified (via --install-dir, --prefix, or the distutils default setting) was: ..//build/lib64/python2.7/site-packages/ and your PYTHONPATH environment variable currently contains: './/build/lib64/python2.7/site-packages/' Here are some of your options for correcting the problem: * You can choose a different installation directory, i.e., one that is on PYTHONPATH or supports .pth files * You can add the installation directory to the PYTHONPATH environment variable. (It must then also be on PYTHONPATH whenever you run Python and want to use the package(s) you are installing.) * You can set up the installation directory to support "".pth"" files by using one of the approaches described here: https://pythonhosted.org/setuptools/easy_install.html#custom-installation-locations Please make the appropriate changes for your system and try again. Makefile:6: recipe for target 'install' failed make: *** [install] Error 1 }}} Although this example shows what happens when running 'make' from the PythonInterface directory, the result is the same when building everything, and does not depend on whether the user is privileged or unprivileged. In this case, the PYTHONPATH variable was set artificially in an attempt to resolve the problem, it is normally empty. The directory {{{ ..//build/lib64/python2.7/site-packages/ }}} exists but is empty. The build should also work in a jail which wouldn't contain any files (this is for source-based package managers such as Gentoo portage), so the test for .pth files might be problematic." Stephen Bosch <posting@…> 3547 Initial event is not propagated as expected Initialization Future defect Lennart Ochel new 2015-11-09T14:07:55Z 2015-11-09T18:26:01Z "Simulation of the model below results into the end values `v2=1` as expected, but `v1=0` (as opposed to the expected: `v1=1`). {{{ #!modelica model InitialEvent Boolean iev(start=false,fixed=true); Integer v1(start=0,fixed=true), v2(start=0,fixed=true); equation iev = initial(); when {iev} then v1 = pre(v1) + 1; end when; when {initial()} then v2 = pre(v1) + 1; end when; end InitialEvent; }}}" Bernhard Thiele 3556 pseudo loops with function *unknown* Future defect somebody new 2015-11-12T11:15:04Z 2015-11-12T11:17:26Z "In the following example {{{#!modelica model A function f2 input Real dx1; input Real dx2; input Real x1; input Real x2; output Real y1; output Real y2; protected Real[2] c = {dx1 + dx2, x1 + x2}; algorithm y1 := c[1] + c[2]; y2 := c[2]; end f2; Real x,z,y; Real dx = (x-y)/exp(z), dz(start=1) = der(z), dy(start=1.5) = der(y); equation (x, z) = f2(dx, dy, x, y); dz = x - z; end A; }}} we have loops of the size 2. By replace {{{#!modelica Real[2] c = {dx1 + dx2, x1 + x2}; }}} with {{{#!modelica Real c1 = dx1 + dx2, c2 = x1 + x2; }}} we get {{{#!modelica model A2 function f2 input Real dx1; input Real dx2; input Real x1; input Real x2; output Real y1; output Real y2; protected Real c1 = dx1 + dx2, c2 = x1 + x2; algorithm y1 := c1 + c2; y2 := c2; end f2; Real x,z,y; Real dx = (x-y)/exp(z), dz(start=1) = der(z), dy(start=1.5) = der(y); equation (x, z) = f2(dx, dy, x, y); dz = x - z; end A2; }}} without loops. " Vitalij Ruge 3563 Functional input arguments ignore default arguments Frontend Future defect somebody new 2015-11-18T12:16:20Z 2015-11-18T12:16:20Z "The following model doesn't work, because the type checking ignores the default argument on f2.y. {{{#!mo function f1 input Real x; input PF pf; output Real y = pf(x); partial function PF input Real x; output Real y; end PF; end f1; function f2 input Real x; input Real y = 2.0; output Real z = x + y; end f2; model test Real x = f1(3.0, f2); // Error: (Real, Real) => Real != Real => Real end test; }}} This is annoying when writing MetaModelica code and using e.g. List.fold with a function that has default arguments." Per Östlund 3639 MinGW linker finds pre-built MSVC library Third-Party Libraries Future defect Adrian Pop assigned 2016-01-21T22:20:52Z 2016-02-12T15:29:14Z "If an external Modelica library comes with a pre-built MSVC-win32 library (e.g., in the Resources\Library\win32 directory) then the MinGW linker of OM on Windows tries to link such library and fails. See https://github.com/tbeu/ExternData/issues/9#issuecomment-173542620 for a reported issue and https://trac.modelica.org/Modelica/ticket/1316 for an unfinished discussion on Modelica. How can a library developer prevent such a linker problem? I did not yet test if the linking is successful if the appropriate MinGW libraries are provided next to (or instead) the MSVC libraries. " tc@… 3764 OMCSession.sendExpression uses up all available memory when pyplot is imported OMPython v1.9.4-v1.9.x Future defect Martin Sjölund assigned 2016-03-14T15:30:00Z 2016-03-15T12:54:11Z "I wanted to create a testing script for my modelica models using OMPython when I discovered something very strange: The code example below behaves different depending on whether the pyplot module is imported or not. If the module is imported, the parser call in OMCSession.sendExpression will use up all available memory (at least up to 8 GB). If the module is not imported or if OMCSession.execute is used instead of OMCSession.sendExpression, the memory consumption stays below 100 MB. {{{ #!python # OS: Windows 7 # OMPython version: 2.0.7 # OpenModelica version: 1.9.4 # python version: 2.7.11 # output of 'pip freeze': # cycler==0.10.0 # matplotlib==1.5.1 # numpy==1.10.4 # OMPython==2.0.7 # pyparsing==2.1.0 # python-dateutil==2.5.0 # pytz==2015.7 # six==1.10.0 import OMPython # comment out the following line and the code below will work for both 'execute' and 'sendExpression' import matplotlib.pyplot as plt s = OMPython.OMCSession() print s.sendExpression(""loadModel(Modelica)"") print s.sendExpression(""simulate(Modelica.Electrical.Machines.Examples.DCMachines.DCPM_Start,stopTime=100,numberOfIntervals=100000)"") # execute: normal behavior data = s.execute(""readSimulationResult(currentSimulationResult,{time, ground.p.v, ground.p.i})"") # sendExpression: consumes all available RAM # data = s.sendExpression(""readSimulationResult(currentSimulationResult,{time, ground.p.v, ground.p.i})"") del s }}}" christopher.schoelzel@… 3811 Metarecord usage in bindings not detected MetaModelica v1.10.0-dev-nightly Future defect Martin Sjölund new 2016-03-31T19:59:00Z 2016-03-31T19:59:00Z "The following script generated bad C-code: {{{#!mo setCommandLineOptions(""-g=MetaModelica -d=noevalfunc""); loadString("" uniontype UT record R Real x; end R; end UT; function newR input Real x; output UT ut = R(x); end newR; ""); newR(1.0); getErrorString(); }}} The error from the C compiler is: {{{ newR.c:25:32: error: use of undeclared identifier 'UT_R__desc' tmpMeta[0] = mmc_mk_box2(3, &UT_R__desc, mmc_mk_real(_x)); }}} It seems like using the record constructor for R in this way is not detected as a use of R, so no metarecord stuff is generated for it. This situation can arise since it's now possible to assign to a record field directly, so it's quite easy to end up with a function like newR and no other uses of the record constructor. A simple workaround is to just add an algorithm section and do an assignment instead." Per Östlund 3836 Tuple assignment to singleton type field MetaModelica v1.10.0-dev-nightly Future defect Martin Sjölund new 2016-04-11T09:36:18Z 2016-04-11T09:36:18Z "Currently it's not possible to assign to a field of a singleton type with a function returning a tuple: {{{#!mo uniontype UT record R Integer x; end R; end UT; function f input output UT ut; algorithm // Doesn't work: (ut.x, ...) := tuple_f(...); // Workaround: (tmp_x, ...) := tuple_f(...); ut.x := tmp_x; end f; }}}" Per Östlund 3890 Code generation for function pointers treat underscores wrong Code Generation v1.10.0-dev-nightly Future defect Lennart Ochel new 2016-05-03T10:54:50Z 2016-05-03T10:54:50Z "The following script fails because the generated code doesn't compile (`use of undeclared identifier '_pf__with__underscores'`). Removing the underscores from the function pointer works. {{{#!mo loadString("" partial function pf output Real y; end pf; function f output Real y = 1.0; end f; function test input Integer n; output Real x; protected pf pf_with_underscores = f; algorithm x := pf_with_underscores(); end test; ""); test(1); getErrorString(); ""); test(1); getErrorString(); }}}" Per Östlund 3926 Parameter calculation with numerical Jacobian leads to wrong results Backend Future defect Willi Braun accepted 2016-05-25T13:06:53Z 2017-11-14T22:08:53Z "The non-fixed parameters of the following model are calculated to 0 if calculateStrongComponentJacobians is skipped for initialization, which is obviously wrong: {{{#!mo model foo final parameter Real p1 = 1; final parameter Real p2 = 2; final parameter Real p3 = 3; final parameter Real p4 = 4; parameter Real q1 (fixed=false); parameter Real q2 (fixed=false); initial equation -p1 = 3 * (p3 * q1 + p4 * q2); -p2 = 3 * (q1 * p4 - p3 * q2); end foo; }}} A testing script is attached." Patrick Täuber 3954 Potential bugs from static code analysis Code Generation v1.10.0-dev-nightly Future defect Lennart Ochel new 2016-06-08T12:18:45Z 2016-06-23T15:57:59Z "I'm referencing from run ""Tue Jun 7 21:05:18 2016"" with 3483 warnings (approx. commit bb33335a639ba7a14c88f997355f1d41bfe37589) I wonder if 3rdParty code should be checked, because we cannot do anything about it, right? [ ] 1. virtually all files (this is not a bug, but superfluous code, slowing down C compiler) Common problem with match expressions ""Value stored to 'tmp4' is never read"" (because of failure handling?) creates hundreds of warnings and makes this static analysis difficult to read [x] 2. Absyn.mo 3584 value stored to l2 is never read -> getCrefFromExp() stop expression is lost [ ] 3. BackendDAEOptimize.mo 1763 value stored to compInfos is never read -> info from called function is lost, function returns defaults only [x] 4. BackendDAEOptimize.mo 879 value stored to lsteqns is never read -> BackendEquation.equationList(eqns) called twice [ ] 5. BackendDAEOptimize.mo 4350 value stored in expLst is never read -> list obtained from right side is directly overwritten by empty list [ ] 6. BackendDAEDump.mo 888 value stored in expLst is never read -> string with equationKindString is not used [ ] 7. BackendEquation.mo 1066,1055,1042 use of uninitialized variable b [ ] 8. BackendInline.mo 792 output variable outEquationArray not initialized [ ] 9. BackendVariable.mo 2891,2882,2898 value stored in res is never read -> call to replaceVarWithWholeDimSubs() seems useless [ ] 10. BaseHashTable.mo 213 value stored in n is never read -> valueArrayLength() explicitly read but not used [ ] 11. CevalFunction.mo 2672 value stored in deps is never read -> is this wanted? [ ] 12. CevalFunction.mo 2310,1976,2280 value stored in cache is never read -> should following functions start with inCache or cache from previous call? [ ] 13. Differentiate.mo 3052 lowerVarsElementVars() called with too few return elements [ ] 14. EvaluateFunctions.mo 3383 returned list from List.filterOnTrue(varLst, BackendVariable.isStateorStateDerVar); is not used (and called function may not fail) -> superfluous? [ ] 15. EvaluateFunctions.mo 1370 value of cref1 is overwriten 7 lines below [ ] 16. Matching.mo 3867 value stored to unmatched is never read. Maybe typo in next line that should use unmatched instead of unmatchedRows (otherwise this listAppend() is superfluous) [ ] 17. RemoveSimpleEquations.mo 3766 variable varlst is overwritten, maybe that should be iAcc = ??? And the recursion should use varlst (rest of list) and iAcc as parameters. [ ] 18. ResolveLoops.mo 2456-2460 arrays e, u, v, vv and w are created but not used [ ] 19. ResolveLoops.mo 1792+1793 arrays ass1 and ass2 are created, but not used [ ] 20. ResolveLoops.mo 1564,1580 startNode/endNode is calculated twice with different rule More to come (checked Compiler/boot/build/*.c alphabetically up to and including ResolveLoops.c, skipped HpcOM* and FFrontEnd) Items marked with [x] are already fixed." Henning Kiel 4014 Unexpected behavior of Start Time Interactive Environment v1.11.0 Future defect Willi Braun assigned 2016-07-31T13:07:14Z 2016-09-02T11:41:56Z "I have a simple RC circuit model and I want to simulate (output) only the results for times greater than a certain time (=10s), like in LTSpice. So I put 10 in the Start Time field. But what actually happens now is that the whole simulation has a time offset of 10s and initializes at 10s. Sure, the time from 0s..10s needs to be simulated internally, but I don't want so see it (see next ticket). Is the expected behavior wrong or is there a bug in OM? Thank you for revising!" Jan Kokert 4020 """JSON object expected ',' or '}'"" error on FMU load" FMI Future defect Adeel Asghar new 2016-08-05T11:20:47Z 2020-05-14T08:56:11Z "I try to load FMU generated by OpenModelica using JavaFMI library on Ubuntu 16.04 64 bit. When loading with locale set to {{{ru_RU.UTF-8}}} I get the following error: {{{ JSON object expected ',' or '}', got: ""lineEnd"":2,""colStar }}} When I specify {{{LANG=C}}} it works well. HOW TO REPRODUCE: 1) Compile the following model using OpenModelica 1.9.6: {{{#!modelica model Trivial Real x; equation x = time; end Trivial; }}} 2) Load it using the following Java code (uses JavaFMI 2.16.10 library) with {{{LANG=ru_RU.UTF-8}}}: {{{#!java import org.javafmi.wrapper.generic.Simulation; public class Test { public static void main(String args[]) { Simulation sim = new Simulation(""/tmp/Trivial.fmu""); sim.init(0.0, 1.0); sim.terminate(); } } }}} 3) Repeat step 2 with {{{LANG=C}}} EXPECTED BEHAVIOR: Nothing is printed to terminal, program finishes correctly on both steps 2 and 3. REAL BEHAVIOR: On step 2, error message {{{JSON object expected ',' or '}', got: ""lineEnd"":2,""colStar}}} is printed to terminal and program terminates with SIGABRT. On step 3 it works as expected. DEBUGGING: It seems that the problem is with the function {{{skipValue()}}} from file {{{simulation_info_json.c}}} that can be found inside an FMU in {{{include/simulation}}} directory. It has the following code: {{{ char *endptr = NULL; strtod(str,&endptr); if (str == endptr) { fprintf(stderr, ""Not a number, got %.20s\n"", str); abort(); } return endptr; }}} When using Russian locale, decimal delimiter is not point but comma, so when {{{strtod}}} is used to skip an integer in the middle of JSON object, it skips field delimiter too, that confuses {{{skipObjectRest()}}}." anatoly.trosinenko@… 4117 partial differential create complex ArrayEquation? *unknown* Future defect somebody new 2016-10-29T18:47:29Z 2016-10-29T18:47:29Z "The following example {{{#!modelica model foo function f input Real[2] x; output Real[2] y; output Real[2] z; algorithm y[1] := 2*x[1]^2 + 1; y[2] := 3*x[2]^3 + 2; z[1] := -y[1]/2+1/2+7; z[2] := -y[2]/3+2/3-7; end f; Real[ 2] y(each start = -1); Real z1, z2; equation (, y) = f(y); der(y[1]) = -z1*y[2] +1; der(y[2]) = -z2*y[1] + z1*y[2] +3; end foo; }}} failed with {{{#!bash ""[/home/vruge/OM/OMCompiler/Compiler/SimCode/SimCodeUtil.mo:5880:7-5880:48:writable] Error: Internal error for Eqn: 1 : $DER$$Pfoo$Pf({y[1], y[2]}, {1.0, 0.0})[2] * $DER.y[1] + $DER$$Pfoo$Pf({y[1], y[2]}, {0.0, 1.0})[2] * $DER.y[2] = $DER.y[2] array equations currently only supported on form v = functioncall(...) [/home/vruge/OM/OMCompiler/Compiler/SimCode/SimCodeUtil.mo:552:5-552:146:writable] Error: Internal error function createSimCode failed [Transformation from optimised DAE to simulation code structure failed] "" }}}" Vitalij Ruge 4146 Summary of omc scaling issues *unknown* Future defect Francesco Casella assigned 2016-11-18T17:58:52Z 2019-07-18T11:10:10Z "This ticket collects all the known issues with omc scaling poorly with the model size: - #1451 Backend scaling for simple array-equation - #3695 removeSimpleEquations is slow on large models - #3781 Fix scaling of detectJacobianSparsePattern - #3816 Matching and sorting scales as O(N^3^) in models with large numbers of discrete variables - #3905 findZeroCrossings scales as O(N^2^) - #4005 EncapsulateWhenConditions scales as O(N^3^) in models where a when clause is triggered by a large vector of conditions - #4006 SimCode scales as O(N^2^) in models with many when clauses and events - #4388 collectInitialBindings scales as O(N^2^) - #4398 comSubExp scales as O(N^2^) - #4460 resolveLoops scales as O(N^3^) - #4552 EvaluateParameters scales as O(N^2^) with large parameter arrays - #4590 SimCode execution times scale as O(N^4^) with large parameter arrays - #5107 SymbolicJacobian.generateSparsePattern scales as O(N^2) - #5108 Models with large arrays of parameters cause the runtime to segfault - #5382 Model with large arrays and events causes simCode to scale badly " Francesco Casella 4227 OMEdit displays enumerations as integers when debugging OMEdit v1.12.0 Future defect Adeel Asghar new 2017-01-23T11:41:48Z 2017-01-23T11:41:48Z "When using OMEdit to debug the compiler it will show enumeration literals as integers instead of the actual literals. For example, try debugging this model: {{{#!mo model M connector C Real e; flow Real f; end C; C c1, c2; equation connect(c1, c2); end M; }}} Set a breakpoint in {{{Config.languageStandardAtMost}}}, on the second statement (Util/Config.mo:435). When the debugger reaches this breakpoint it will display the std variable as {{{7}}}, instead of {{{LanguageStandard.latest}}}. It will also display the type of std as {{{Integer}}} instead of {{{LanguageStandard}}}." Per Östlund 4260 Build to JS impossible Build Environment v1.9.4-v1.9.x Future defect Martin Sjölund new 2017-02-09T18:14:42Z 2017-02-09T18:14:42Z "I wanted to build .mo to JavaScript. I used this repo to help me with emscripten https://github.com/tshort/openmodelica-javascript After succesfull generation of JS file thanks to MODEL.makefile js.mem file was created and following error was stored there. The JS files are not possible to simulate in following environment: https://github.com/tshort/mdpad/tree/gh-pages/ _prof.realdata wb Time measurements output file %s could not be opened: %s _prof.intdata %s event at time=%.12g time state Disabled time measurements because the output file could not be generated: %s Execution failed! call external Object Constructors call external Object Constructors finished check for discrete changes at time=%.12g C1.v < (-Nr.Ve) C1.v > Nr.Ve 1.0 + G.alpha * (G.T - G.T_ref) C1.C C2.C L.L updating min-values updating max-values updating nominal-values updating start-values during initialization The following assertion has been violated %sat time %f Ro.T_ref >= 0.0 The following assertion has been violated %sat time %f Ro.T >= 0.0 The following assertion has been violated %sat time %f G.T_ref >= 0.0 The following assertion has been violated %sat time %f G.T >= 0.0 The following assertion has been violated %sat time %f C1.C >= 0.0 The following assertion has been violated %sat time %f C2.C >= 0.0 The following assertion has been violated %sat time %f Nr.Ga >= -1.0 The following assertion has been violated %sat time %f Nr.Gb >= -1.0 C:/OpenModelica1.9.7/lib/omlibrary/Modelica 3.2.1/Electrical/Analog/Examples/Utilities/NonlinearResistor.mo C:/OpenModelica1.9.7/lib/omlibrary/Modelica 3.2.1/Electrical/Analog/Basic.mo C:/OpenModelica1.9.7/lib/omlibrary/Modelica 3.2.1/Electrical/Analog/Interfaces.mo model linear_Modelica_Electrical_Analog_Examples_ChuaCircuit parameter Integer n = 3; // states parameter Integer k = 0; // top-level inputs parameter Integer l = 0; // top-level outputs parameter Real x0[3] = {%s}; parameter Real u0[0] = {%s}; parameter Real A[3,3] = [%s]; parameter Real B[3,0] = zeros(3,0);%s parameter Real C[0,3] = zeros(0,3);%s parameter Real D[0,0] = zeros(0,0);%s Real x[3](start=x0); input Real u[0]; output Real y[0]; Real x_PC1Pv = x[1]; Real x_PC2Pv = x[2]; Real x_PLPi = x[3]; equation der(x) = A * x + B * u; y = C * x + D * u; end linear_Modelica_Electrical_Analog_Examples_ChuaCircuit; Internal Error: unknown base partition %ld Internal Error: unknown sub partition %ld T!"" K  'hnopqb ($ %#ƒ‚}&*+<=>?CGJMXYZ[\]^_`acdefgijklrstyz{| Illegal byte sequence Domain error Result not representable Not a tty Permission denied Operation not permitted No such file or directory No such process File exists Value too large for data type No space left on device Out of memory Resource busy Interrupted system call Resource temporarily unavailable Invalid seek Cross-device link Read-only file system Directory not empty Connection reset by peer Operation timed out Connection refused Host is down Host is unreachable Address in use Broken pipe I/O error No such device or address Block device required No such device Not a directory Is a directory Text file busy Exec format error Invalid argument Argument list too long Symbolic link loop Filename too long Too many open files in system No file descriptors available Bad file descriptor No child process Bad address File too large Too many links No locks available Resource deadlock would occur State not recoverable Previous owner died Operation canceled Function not implemented No message of desired type Identifier removed Device not a stream No data available Device timeout Out of streams resources Link has been severed Protocol error Bad message File descriptor in bad state Not a socket Destination address required Message too large Protocol wrong type for socket Protocol not available Protocol not supported Socket type not supported Not supported Protocol family not supported Address family not supported by protocol Address not available Network is down Network unreachable Connection reset by network Connection aborted No buffer space available Socket is connected Socket not connected Cannot send after socket shutdown Operation already in progress Operation in progress Stale file handle Remote I/O error Quota exceeded No medium found Wrong medium type No error information rwa" fuzesedu@… 4294 OMEdit: Icon Editor - Bring to Front/forward and Send to Back/Backward OMEdit v1.11.0 Future defect Adeel Asghar accepted 2017-03-02T18:57:31Z 2017-04-12T17:10:56Z "Issue 1: I just wondered why all z-order alignment options (Bring to Front/forward and Send to Back/Backward) are disabled. Is the feature still in development? In [changeset:1f6c73/OMEdit] support for this feature was added. Issue 2: I think in Modelica there is no dedicated z-order property. Instead, the order of the annotations is deciding. So I realized when deleting a component which is in the back and then doing an ""UNDO"", the order is not restored, so the deleted component comes to the front. I know that the IconEditor is not the most critical component, but it would be really nice, if this works properly. As we now have this wonderful UNDO-feature which makes OMEdit totally usable! " Jan Kokert 4300 MetaModelica type checking fail with function pointers MetaModelica v1.12.0 Future defect Martin Sjölund new 2017-03-07T13:27:50Z 2017-03-08T08:20:44Z "This script fails without any error message: {{{#!mo setCommandLineOptions(""-g=MetaModelica""); loadString("" uniontype U record R String path; end R; function name input U u; output String name = u.path; end name; end U; function typeCheckFail protected U u = U.R(\""test\""); algorithm print(u.name); // Oops, should've been u.path. end typeCheckFail; ""); getErrorString(); typeCheckFail(); getErrorString(); }}} In other words, calling a function expecting e.g. a string with a function pointer just silently fails. Using --showErrorMessages shows nothing, but replacing the argument with e.g. an integer does produce the expected error." Per Östlund 4344 OMEdit: keep UNDO stack after text view changes OMEdit Future defect Adeel Asghar accepted 2017-03-19T14:38:49Z 2017-03-24T13:47:41Z "Even if it seems to be a more time-consuming task, I recommend merging the UNDO stack of the Text View with the stack of the Diagram View as discussed in #4334#comment:13. It is just a strange behavior that you must go the to correct view to undo things. People how use OMEdit assume that the content in Text View and Diagram View is a different representation of the SAME thing and expect a coherent behavior especially for undo/redo." Jan Kokert 4346 OMEdit: inconsistant handling of protected objects Run-time Future defect Willi Braun assigned 2017-03-19T15:23:51Z 2017-03-24T14:01:35Z "Please consider the attached example. Both the ground symbol and the Real value are {{{protected}}}. After simulation, only the Real value is hidden in the Variables Browser. I think it is not perfectly written clear in the Modelica specification that objects (so no primitive datatypes) are still shown. But hiding them would result in a very consistent behavior and will satisfy user needs as in: [https://openmodelica.org/forum/default-topic/1029-hide-variables-to-plot-in-omedit]" Jan Kokert 4351 OMEdit: Keep abbreviated library paths from import when moving components OMEdit Future defect Adeel Asghar new 2017-03-20T14:52:09Z 2017-03-24T07:11:13Z "Bug: Abbreviated library paths defined by import will be reset after moving components in the Diagram View. Code example: {{{ model importTest import EL = Modelica.Electrical; EL.Analog.Basic.Resistor resistor annotation( Placement(visible = true, transformation(origin = {0, 0}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); end importTest; }}} 1.) Open the provided code example 2.) Go to Diagram View and move the resistor somewhere 3.) Go back to the TextView Result: The abbreviated statement {{{EL.Analog.Basic.Resistor}}} was replaced by the full {{{Modelica.Electrical.Analog.Basic.Resistor}}} An undo will set the component back to its original position, but the abbreviated library path is not restored." Jan Kokert 4356 netCDF reader works on Linux, not on Windows *unknown* v1.12.0 Future defect Adrian Pop accepted 2017-03-22T08:40:36Z 2019-03-31T19:37:12Z "More or less a copy of this issue: https://github.com/tbeu/netCDF-DataReader/issues/6 Not sure whether this has to be fixed on OM side or in the library, one of the two issues can be closed. The netCDF library comes with three examples, all three work on Linux, but fail on Windows. Tested with Windows 10 64 bit, OM 1.11 32 bit release and OM 1.12 64 bit nightly. For the Simple example the error is: {{{ [3] 10:30:07 Fehler Failed to write to file (not open) [4] 10:30:07 Übersetzung Fehler Template error: A template call failed (a call with 0 parameters: dladdr failed: not available on Windows). One possible reason could be that a template imported function call failed (which should not happen for functions called from within template code; templates preserve pure 'match'/non-failing semantics). }}} For the other two examples, the error is: {{{ NMAKE : fatal error U1077: ""cl"": R�ckgabe-Code ""0x2"" Stop. Compilation process failed. Exited with code 2. }}} The full log is pasted here: http://pastebin.com/3k3e7LMB Side note: There seems to be some encoding wrong with the word R�ckgabe" m.thorade@… 4513 expandable connector connects array-Variables Frontend Future defect somebody new 2017-09-06T13:34:53Z 2017-09-06T13:34:53Z "Hi, I would like to report, that having a connect statement for an expandable connector including an array-variable as connector variable causes an error during instantiation. {{{ expandable connector Bus end Bus; }}} {{{ model testBus Bus bus; Real x; equation connect(x, bus.x[1]); x = 1; end testBus; }}} " Volker Waurich 4554 Internal error CevalScript.calculateSimulationSettings - can't run simulation when stopTime/interval is above 1e6 Interactive Environment v1.13.0-dev-nightly Future defect Adrian Pop assigned 2017-10-10T09:52:13Z 2017-10-24T11:45:51Z "Hello, I cannot launch simulation if I state stopTime / interval (or number of interval above 1e6) above the limit of 1e6. " thomas.pedot@… 4706 Missing --output-def flag in Makefile (for Windows) in FMU sources FMI v1.13.0-dev-nightly Future defect Lennart Ochel new 2018-01-11T15:31:07Z 2018-01-11T15:31:07Z Without the '--output-def=modelname.def' flag in the ''sources/Makefile'' file, no DEF file is generated, thus giving errors when ''dlltool'' is called. dariomangoni@… 4979 An optimization with annotations trouble Optimization Future defect Vitalij Ruge new 2018-06-08T15:22:33Z 2021-10-22T20:55:31Z "I know that dynamical optimization is only partially supported. However, I guess that it is useful to report a simple issue I've seen, when dynamical optimisation with annotatios is used. Consider the file InputOptIssues enclosed. It contains two models: - TimeTable: it finds the optimal value for ""torque"" variable perfectly. Given the constraints, this is first the max allowed value (90), then the max allower power (9000), then min power, min torque. - Trapezoid, nearly identical to timetable, but has as load torque a trapezoid. In this case the '''Trapezoid output is constantly zero''' instead of the espected shape. The optimal torque is still found, but it is the one corresponding to zero load torque instead of the expected shape. To reproduce consider that the two models contain all the relevant options inside annotations. So they can reproduced as follows: - load OMedit (using all default options) - run TimeTable and see the results - run Trapezoid and see the results. " massimo ceraolo 5006 SimCode fails on array equations inside if equation Backend v1.13.0-dev-nightly Future defect Lennart Ochel new 2018-06-27T12:12:34Z 2018-06-27T12:12:34Z "The frontend doesn't scalarize array equations involving function calls, but it seems the backend can't handle this when the equations are inside an if equation. For example: {{{#!mo function f2 input Real x[:]; output Real y[:] = x; end f2; model test Real x[3]; equation if time > 1 then x = f2({time, time, time}); else x = f2({time, time, time}); end if; end test; }}} This gives the error: {{{ [SimCodeUtil.mo:2466:7-2466:46:writable] Error: Internt fel function createNonlinearResidualEquationsComplex failed for: {0.0, 0.0, 0.0} = x - f2({time, time, time}) Error: Internt fel function createNonlinearResidualEquations failed [SimCodeUtil.mo:5180:7-5180:46:writable] Error: Internt fel complex equations currently only supported on form v = functioncall(...). Equation: {0.0, 0.0, 0.0} = x - f2({time, time, time}) solve for {x[1],x[3],x[2]} [SimCodeUtil.mo:1366:5-1366:77:writable] Error: Internt fel createEquationsForSystems failed [SimCodeUtil.mo:636:5-636:146:writable] Error: Internt fel function createSimCode failed [Transformation from optimised DAE to simulation code structure failed] }}} I haven't seen any actual models that use this pattern. I found it because the new frontend decided what to scalarize before doing simplifications, so it wouldn't scalarize matrix constructors (which are translated into `cat` calls). I'll fix that, but fixing this issue would still be nice since it would give the frontend more flexibility when it comes to array equations." Per Östlund 5021 Wrong handling of selfcreated variables ($) // HideResult Run-time Future defect Karim Adbdelhak assigned 2018-06-29T11:44:10Z 2018-06-29T12:25:21Z "The expected behaviour of self created variables should be, that they are not shown in the result file (e.g. $cse variables). Currently they are shown if they have an alias that needs to be shown (due to accessibility i guess) but there are more exceptions to this rule to be made: - Optimica expressions (optimization goals should of course be shown) - StateSet variables (controllable by a flag?) - [...?] Self created variables are detected by the first character beeing equal to '$', but that is not always the case (e.g. derivatives of StateSet variables). Possible Fix: Use ""HideResult""-property while creating variables instead. " Karim Adbdelhak 5198 Model simulation failed *unknown* v1.12.0 Future defect somebody new 2018-11-01T20:12:21Z 2018-11-02T19:01:17Z "I tried to simulate a model in OMEdit and it failed. I received this error message but there is no information, is there any other way I can provide more information about this issue? [1] 21:03:20 Scripting Error Stack overflow detected and was not caught. Send us a bug report at https://trac.openmodelica.org/OpenModelica/newticket Include the following trace: [bt] Execution path: " javier.bonilla@… 5272 Inlining handles tuple inputs incorrectly MetaModelica v1.14.0-dev-nightly Future defect Martin Sjölund new 2019-01-14T10:46:12Z 2019-01-14T10:46:12Z "Flattening the following model with `-g=MetaModelica`: {{{#!mo function f input tuple<Real, Real> y; output Real z; algorithm (z, _) := y; annotation(__OpenModelica_EarlyInline=true); end f; model M Real x; algorithm x := f((time, time)); end M; }}} gives {{{#!mo class M Real x; algorithm x := Tuple(#(time), #(time)); end M; }}} I.e. the inlining replaces the call with the whole input tuple, instead of the first tuple element as expected." Per Östlund 5275 Backend issues with ThermalSeparation library Backend v1.14.0-dev-nightly Future defect new 2019-01-14T14:23:20Z 2019-11-15T10:21:35Z "Most of the ThermalSeparation library now flattens using the new frontend (`-d=newInst`), but the majority of the models fail in the backend due to various issues. Most of the failing models gives errors such as (this one is from Examples.Absorption_IdealGases): {{{ BackendDAEOptimize.makeEquationToResidualExp failed to transform equation: column1.balanceEquations.bool_eps[1] = false to residual form! }}} and seem to finally fail completely with the error: {{{ Internal error function createNonlinearResidualEquations failed }}} The library can be found at: https://github.com/thom-marx/ThermalSeparation The current status of the library can be found at: https://libraries.openmodelica.org/branches/newInst/ThermalSeparation/ThermalSeparation.html " Per Östlund 5315 Compiler fails when model has a long fileNamePrefix FMI v1.14.0-dev-nightly Future defect Lennart Ochel new 2019-02-04T13:31:54Z 2019-06-12T08:31:52Z "FMU export (with buildModelFMU) fails when model name is too long. Error message is not informative at all. I don't know exactly which is the maximum length. The problem disappears when the modelname is shortened. Here is the build output: {{{ Error: Error writing to file AltairVehicleTesting_Vehicles_VehicleFullFialaTyreSplitDriveline.fmutmp/sources/AltairVehicleTesting_Vehicles_VehicleFullFialaTyreSplitDriveline_literals.h. Error: Error writing to file AltairVehicleTesting_Vehicles_VehicleFullFialaTyreSplitDriveline.fmutmp/sources/AltairVehicleTesting_Vehicles_VehicleFullFialaTyreSplitDriveline_functions.h. Error: Error writing to file AltairVehicleTesting_Vehicles_VehicleFullFialaTyreSplitDriveline.fmutmp/sources/AltairVehicleTesting_Vehicles_VehicleFullFialaTyreSplitDriveline_functions.c. Error: Error writing to file AltairVehicleTesting_Vehicles_VehicleFullFialaTyreSplitDriveline.fmutmp/sources/AltairVehicleTesting_Vehicles_VehicleFullFialaTyreSplitDriveline_includes.h. Error: Error writing to file AltairVehicleTesting_Vehicles_VehicleFullFialaTyreSplitDriveline.fmutmp/sources/AltairVehicleTesting_Vehicles_VehicleFullFialaTyreSplitDriveline_records.c. Error: Error writing to file AltairVehicleTesting_Vehicles_VehicleFullFialaTyreSplitDriveline.fmutmp/sources/AltairVehicleTesting_Vehicles_VehicleFullFialaTyreSplitDriveline_model.h. Error: Error writing to file AltairVehicleTesting_Vehicles_VehicleFullFialaTyreSplitDriveline.fmutmp/sources/AltairVehicleTesting_Vehicles_VehicleFullFialaTyreSplitDriveline_01exo.c. Error: Template error: A template call failed (C:\OpenModelica\bin\omc.exe: [unknown function name]). One possible reason could be that a template imported function call failed (which should not happen for functions called from within template code; templates assert pure 'match'/non-failing semantics). }}}" dariomangoni@… 5520 OMSI build fails with newer sundials Build Environment v1.14.0-dev-nightly Future defect Martin Sjölund new 2019-06-10T09:25:39Z 2019-06-13T10:36:54Z "OMSI failed to build for me with an error from SimulationRuntime/OMSI/solver/CMakeLists.txt: {{{ CMake Error at solver/CMakeLists.txt:63 (STRING): STRING sub-command REGEX, mode REPLACE needs at least 6 arguments total to command. }}} It's looking for the pattern `#define SUNDIALS_PACKAGE_VERSION ""...""` in `sundials_config.h` to determine the sundials version, but it wasn't working on my system. The reason turned out to be that I had sundials 4.1.0 installed (3rdParty has 2.6.2), where `SUNDIALS_PACKAGE_VERSION` has been changed to `SUNDIALS_VERSION`. I ""solved"" it by uninstalling sundials, since I wasn't sure why I even had it installed. But this should be fixed anyway, either by ignoring system-installed sundials or making the version detection more robust." Per Östlund 5521 Connector with array of records - problem when assigned in algorithm section *unknown* v1.14.0-dev-nightly Future defect somebody new 2019-06-10T14:10:27Z 2019-06-10T14:10:27Z "Referred to [https://trac.openmodelica.org/OpenModelica/ticket/5493#comment:1] In the following package I declare a record called Rec, and two connectors (an input and an output one) with an array of Rec. When a block tries to modify its output connector in an algorithm section (see block named Sender) the simulation results in a problem. {{{ package connector_algorithm constant Integer BUFFER_SIZE = 5 ""size of the array""; record Rec ""simple record containing one variable"" discrete Real data; end Rec; connector INPort ""connector containg an array of records"" input Rec buffer[BUFFER_SIZE]; end INPort; connector OUTPort ""connector containg an array of records"" output Rec buffer[BUFFER_SIZE]; end OUTPort; block Sender ""block which updates the array using an algorithm section"" OUTPort OUT; algorithm when time > 0.6 then for i in 1:size(OUT.buffer, 1) loop OUT.buffer[i].data := 33.0; end for; end when; end Sender; block Receiver ""a block with an input port"" INPort IN; end Receiver; model test ""aggregate model"" Sender S; Receiver R; equation connect(S.OUT, R.IN); end test; end connector_algorithm; }}} Error: [1] 15:44:54 Symbolic Error Model is structurally singular, error found sorting equations 1: algorithm $whenCondition1 := time > 0.6; when $whenCondition1 then for i in 1:5 loop S.OUT.buffer[i].data := 33.0; end for; end when; ; for variables $whenCondition1(6), R.IN.buffer[5].data(1), R.IN.buffer[4].data(2), R.IN.buffer[3].data(3), R.IN.buffer[2].data(4), R.IN.buffer[1].data(5) [2] 15:44:54 Translation Error Internal error Transformation Module PFPlusExt index Reduction Method Pantelides failed! This problem disappears with the new frontend (the one ticked with ""Enable experimental new instantiation phase"" in simulation options)." domenico.nucera@… 5526 MetaModelica: loop over list<Integer> Code Generation v1.14.0-dev-nightly Future defect Lennart Ochel new 2019-06-12T07:22:43Z 2019-06-12T21:41:42Z "Using an Integer from a list<Integer> as array index will give the wrong array component, if the list is part of a record. Example: {{{#!mo uniontype Index record INDEX list<Integer> idx; end INDEX; end Index; uniontype Compo record COMPO array<Real> co; end COMPO; end Compo; }}} Supposed we have a Compo called compo and an Index called index, the for loop gives wrong array components: {{{#!mo for k in index.idx loop print(String(k)); r := compo.co[k]; end for; }}} The print command gives the correct number, but k as array index seems to have twice the value of the list member. So if it exceeds the array bounds we will see an error otherwise r has a wrong value. A known workaround: Assign k to an integer variable and use it instead of k or do an integer operation with k at the place where you use k. For instance r := compo.co[k+0]. " jens.schoenbohm@… 5539 Stack overflow with tearingSelect Backend Future defect Lennart Ochel assigned 2019-06-20T19:18:39Z 2019-10-07T09:55:08Z "The following model raise a Stack overflow {{{#!modelica model tearingSelect2 Real x1 annotation(tearingSelect = never); Real x2; Real x3; Real x4; Real x5; Real x6 annotation(tearingSelect = never); equation 0 = x1*x1 + x2; 0 = x1*x1 + x2 +x3; 0 = x1*x1 + x3 + x4; 0 = x1*x1 + x4 + x5; 0 = x1*x1 + x5 + x6; 0 = x1 + x6*x6; end tearingSelect2; }}} {{{#!bash [/home/vruge/packages/OpenModelica/OMCompiler/Compiler/BackEnd/BackendDAEUtil.mo:7137:3-7137:155:writable] Error: Internal error Stack overflow in BackendDAEUtil.getSolvedSystem... [bt] #1 /home/vruge/packages/OpenModelica/OMCompiler/build/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaRuntimeC.so(mmc_setStacktraceMessages_threadData) [bt] #2 /home/vruge/packages/OpenModelica/OMCompiler/build/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaRuntimeC.so(mmc_do_stackoverflow) [bt] #3 /home/vruge/packages/OpenModelica/OMCompiler/build/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(Tearing.removeMatched) [bt] #4 /home/vruge/packages/OpenModelica/OMCompiler/build/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(Tearing.getUnsolvableVarsConsiderMatching) [bt] #5 /home/vruge/packages/OpenModelica/OMCompiler/build/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(Tearing.omcTearingSelectTearingVar) [bt] #6...1024 /home/vruge/packages/OpenModelica/OMCompiler/build/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(Tearing.omcTearing2) [bt] #1025 [...] }}}" Vitalij Ruge 5540 plot window start OMEdit v1.13.2 Future defect Adeel Asghar new 2019-06-21T04:44:10Z 2019-07-18T03:53:56Z after a failure in simulation, the auto window opening disables itself and any further successful simulations won't show the plot results / visualization sathishmswamy@… 5601 Analyse impact: removeEqualFunctionCalls and avoid as tearing variable Backend Future defect somebody new 2019-07-21T09:33:44Z 2019-07-21T21:03:14Z "removeEqualFunctionCalls can replace `f(x,y)` with `a` where `f(x,y)` is a expression depending from `x,y` (if `a=f(x,y)`). In some cases `x,y` can have start values. but `a` doesn't. One idea is to avoid `a` in tearing select, like `start`-attribute is used to `prefer` a variable (see #5458). Maybe this should be done only for initialization." Vitalij Ruge 5604 Set the options FMU Name and Move FMU at the same time Backend v1.14.0-dev-nightly Future defect Lennart Ochel new 2019-07-26T07:46:45Z 2019-07-26T07:46:45Z "Exporting {{{myModel.mo}}} inside {{{myPacakge}}} as FMU. Setting FMU Name option as {{{myFMU}}} resulting a {{{myFMU.fmu}}} saved in working directory under {{{myPackage.myModel}}} folder. Setting Move FMU to {{{someLocation}}} resulting a {{{myPacakge.myModel.fmu}}} saved in {{{somelocation}}} but the each c-files has {{{myFMU}}} prefix. Is this the expected result? " Trista Arinomo <trista.arinomo@…> 5683 Mediums in fluid systems require explicit redeclare in OMEdit *unknown* v1.14.0-dev-nightly Future defect somebody new 2019-11-01T13:57:12Z 2019-11-05T21:46:23Z "Fluid components across many libraries (Modelica.Fluid, BuildSysPro.IBPSA.Fluid, OpenHydraulics.Fluids) all require adding ""redeclare package Medium = Medium"" (where the second ""Medium"" is the name of the medium you want to that component to have flowing through it. It seems, since fluid models already require adding a ""system"" component and most models will be based around a single fluid, that the components should default to a Medium that is defined by either the system block or by naming a specific medium to ""Medium"" in order to invoke it as the default. Writing this I realize that this may in fact be an issue with the language of Modelica and not with OMEdit but not entirely sure." anonymous 5688 Use of removed conditional component not reported New Instantiation Future defect Per Östlund new 2019-11-11T10:35:36Z 2019-11-11T15:25:52Z "{{{ class A parameter Boolean a = false; parameter Real b if a; Real v; equation v = time * b; end A; }}} Does not report an error for use of {{{b}}} in the equation. This causes problems on the generated code. E.g. https://libraries.openmodelica.org/branches/newInst/ThermoPower/files/ThermoPower_ThermoPower.PowerPlants.SteamTurbineGroup.Tests.TestTurbineHPefficiency.err " Mahder Alemseged Gebremedhin 5819 OMSens results are not displayed OMEdit v1.16.0-dev Future defect Adeel Asghar new 2020-02-01T16:51:34Z 2020-02-02T19:19:44Z "When executing OMSens on Ubuntu, the menu displaying the result of the sensitivity analysis are not shown. " John Tinnerholm 5955 OMSens does not stop running when failing OMSens Future defect John Tinnerholm new 2020-05-13T11:54:53Z 2020-05-13T11:54:53Z "Currently, OMSens does not prompt the user if it fails to execute. This issue is similar to what was reported in: https://trac.openmodelica.org/OpenModelica/ticket/5819 and recently raised as an issue here: https://github.com/OpenModelica/OMSens/issues/4 This gives the user of OMEdit the impression that OMSens is looping when in fact the script failed somewhere due to missing dependencies " John Tinnerholm 5966 Functional argument binding: wrong type mismatch error thrown Code Generation v1.16.0-dev Future defect Lennart Ochel new 2020-05-19T12:22:24Z 2020-05-20T12:38:51Z "Taking an example from Modelica Specifications 3.4, pag 151; OMC reports a bad mismatching while it shouldn't (I think). `[EmbeddedFunctions.quadrature: 5:3-5:49]: Type mismatch in binding integrand = Modelica.Math.sin, expected subtype of integrand<function>(#Real) => #Real, got type Modelica.Math.sin<function>(Real) => Real.` I'm on Win10 and OpenModelica v1.16.0-dev-275-g033f38916 (64-bit)" dariomangoni@… 2736 Final Constraints for Optimization missing Frontend trunk Future discussion Mahder Alemseged Gebremedhin accepted 2014-06-23T17:50:20Z 2017-11-14T22:08:53Z "Currently it's not possible to formulation final constraints in the optimization. In the moment we support path constraints with Otimica Extension. {{{ Real a,b,c,d,e; ..... constraint a*b + c/d < e }}} In Optimica it's possible to write for final constraints. {{{ Real a,b,c,d,e; ..... constraint a(finaTime)*b(finalTime) + c(1.0)*d(finalTime) < b(1.0) }}} where finalTime is a real parameter 1.0, which is unknown sometimes. Note: stopTime not equal finalTime! There some issues with different time point and the case if finalTime is unknown. It seem like the currently way in Modelica is to set marker via (Custom) annotations see e.g. http://www.ep.liu.se/ecp/096/018/ecp14096018.pdf It's would be nice to have something like {{{ Real a,b,c,d,e; ..... constraint a*b + c/d < e annotation(finalConstraint = true) }}} The issue is that a*b + c/d < e is an equation and the annotation going missing in the BackEnd. Alternative it should be possible to write {{{ Real a,b,c,d,e; Boolean f (finalConstraint = true); ..... equation f = a*b + c/d < e; }}} However custom annotations not really finished yet! Therefore, I prefer for the first prototype similar implementation like constraint with {{{ Real a,b,c,d,e; ..... equation .... final constraint a*b + c/d < e; constraint ... }}} " Vitalij Ruge 2838 ExternalMedia library, OMEdit crash with Test.fluidProp.WaterIF95.TestBasePropertiesDynamic Frontend trunk Future discussion Adrian Pop accepted 2014-09-24T15:41:33Z 2014-09-24T16:30:42Z "Hi, I try to work with the ExternalMedia and CoolProp2Modelica-library but I have some trouble. For example, OMEdit crash when i try to simulate ExternalMedia.Test.fluidProp.WaterIF95.TestBasePropertiesDynamic. Does these libraries really work on OpenModelica? https://github.com/modelica/ExternalMedia https://github.com/thermocycle/CoolProp2Modelica-library " anonymous 3538 function outputs array slice Backend Future discussion somebody new 2015-11-02T15:01:14Z 2015-11-03T16:28:13Z "Hi, A model of mine has a function call that outputs an array slice, which is part of a 2-dimensional array. This call is inside a for-loop: Something like: (_,x[:,i],_) := f(a); When compiling, I get the template-error from daeExpCrefLhsSimContext: {{{Template error: This should have been handled in indexed assign and should not have gotten here x[:,i]}}} Can anybody explain where exactly these things have to be handled? I dont know what is meant with ""indexed assign"". Thanks. " Volker Waurich 3908 Automated decision support for compilation and simulation flags *unknown* Future discussion somebody new 2016-05-13T11:05:56Z 2016-05-13T11:05:56Z "Small models can be simulated with default choices and the DASSL solver with a tight enough tolerance, producing correct results in a reasonable amount of time. As the problem size increases, selecting the correct code generation strategy and solution strategy might become crucial to obtain good (or even acceptable) performance. Features like stiffness, size, presence of many and/or large nonlinear strong components, presence and quantity of events, sparsity of the DAEs and of the ODEs jacobian are all elements that need to be considered for a correct choice. Most of these features could be detected automatically by running a diagnostic simulation with DASSL, then a report could be generated suggesting better flag settings. This seems a nice topic for a thesis. We have a large number of test cases in our coverage tests, that could be used as a benchmark. AFAIK, no other Modelica tool has anything like this. Comments?" Francesco Casella 4166 SimCodeFunctionUtil.lookForExtFunctionLibrary for msvc *unknown* Future discussion somebody new 2016-12-02T12:48:23Z 2016-12-02T12:48:23Z "Hi, In {{{SimCodeFunctionUtil.lookForExtFunctionLibrary}}}, only autotools are covered to build external libraries. Is there any implementation on invoking msvc project builds in OMC where I can borrow code? Or do I have to implement something new using msbuild? Thanks for sharing your opinion. " Volker Waurich 4588 Unit propagation and deduction. Backend Future discussion Lennart Ochel assigned 2017-10-25T08:07:04Z 2017-10-25T08:36:47Z "Consider the model units.mo (attached). It contains a feedback fed by two inputs with known units (m/s) Shouldn't they be propagated to the feedback inputs and also, by deduction, to the feedback output? Dymola shows for the two feedback inputs m/s, as expected, while for the output, unexpectedly, no unit. OM (1.13-dev 89) shows no unit for feedback inputs and output." massimo ceraolo 5429 SimulationInfos are not correctly saved in FMU init file FMI v1.14.0-dev-nightly Future discussion Lennart Ochel new 2019-04-10T11:18:27Z 2019-04-10T11:18:27Z "When exprting FMU, some settings can be punt in annotation that will used in FMU such as startTime, stopTime, stepSize and tolerance. All those setting are always correctly save in modelName_init_fmu.c but not the solverMethod, outputFormat and variableFilter. e.g. if i set solver to euler, dassl is alway saved as solverMethod in init file. Should user be able to set what solver would be used for the FMU?" Arinomo <trista.arinomo@…> 1792 Give more helpful comparisons on incorrectly used functions? Frontend Future enhancement somebody new 2012-09-02T13:29:58Z 2017-11-14T22:08:53Z "It is fairly hard to find errors when you call functions incorrectly, it would be nice to be able to get a unified comparison with more precise info for this. Here's an example of a current error message I got: {{{ Error: No matching function found for AvlTree.foldLeftWith(I.add1, 0, tree) of type .AvlTree.foldLeftWith<function>(foldLeftWithFunction:.I.add1<function>(x:#Integer, el:#Integer) => #Integer, foldAccum:Integer, avlTree:tuple<.I.Compare<function>(x:#Integer, y:#Integer) => Ordering.Ordering, I.Node>) => polymorphic<B> in component <NO COMPONENT> candidates are .AvlTree.foldLeftWith<function>(foldLeftWithFunction:.Collection.FoldLeftWithFunction<function>(inAccum:polymorphic<FoldAccum>, foldIn:polymorphic<Element>) => polymorphic<FoldAccum>, foldAccum:polymorphic<B>, avlTree:tuple<.AvlTree.Compare<function>(x:polymorphic<A>, y:polymorphic<A>) => Ordering.Ordering, AvlTree.Node>) => polymorphic<B> }}} Since the candidates are separated from the original call and the candidate types are still generic it is hard to spot the error. It would be nice to get the actual parameter(s) that caused this problem, something along the line of `AvlTree.foldLeftWith argument foldAccum cannot unify actual Integer with expected polymorphic<B>` if that's where the issue occured. " adabe588@… 1813 Warn on unused and unexported imports Frontend Future enhancement somebody new 2012-09-16T00:03:18Z 2017-11-14T22:08:53Z "When imports are specified as `protected import PKG.x;` `x` is not exported. If it also isn't used in the package the import isn't useful and it would be nice to get an ""unused import"" warning. Or is this available already through some compiler flag? Also, I can now access the bug tracker from home again, I hope the certificate doesn't cause more issues. " adabe588@… 1839 OMEdit: better autorouting OMEdit Future enhancement Adeel Asghar reopened 2012-09-25T09:46:57Z 2017-10-12T18:26:34Z * better autorouting (with collision detection) Henning Kiel 1869 detect completely constant parts Backend trunk Future enhancement Willi Braun new 2012-10-06T01:28:47Z 2017-10-26T22:47:58Z "We evaluate completely constant parts again an again, this should be avoided by detecting part that are independent on time, states or events. In particular we should avoid that for bigger non-linear loops. For example the non-linear loop below will solved 10000! {{{ model M Real x,y; equation x = sin(y); y = cos(x); annotation (experiment(StopTime=10, NumberOfIntervals=10000)); end M; }}}" Willi Braun 2000 Modelica.Fluid.Examples.IncompressibleFluidNetwork Backend trunk Future enhancement Willi Braun assigned 2012-12-26T11:37:01Z 2017-11-14T22:08:53Z "Hi, this model gives rise to some interesting questions, when merging alias variables. First, we have the warning {{{ Warning: Aliasset with several free start values Candidate pipe6.mediums[1].p(start = linspace(500000.0, 500000.0, 2)[1]) Candidate pipe8.mediums[2].p(start = linspace(500000.0, 500000.0, 2)[2]) Candidate pipe5.mediums[1].p(start = linspace(500000.0, 500000.0, 2)[1]) Candidate pipe4.mediums[2].p(start = linspace(500000.0, 500000.0, 2)[2]) Candidate pipe10.mediums[1].p(start = linspace(500000.0, 500000.0, 2)[1]) Select value from pipe6.mediums[1].p(start = linspace(500000.0, 500000.0, 2)[1]) }}} which might be avoided since {{{ linspace(x,x,n) = x*ones(n) }}} and thus {{{ linspace(500000.0, 500000.0, 2)[1] == linspace(500000.0, 500000.0, 2)[2] }}} Next, we have {{{ Warning: Aliasset with several free start values Candidate pipe2.m_flows[3](start = 0.0) Candidate pipe7.m_flows[1](start = 0.0) Candidate valve1.m_flow(start = valve1.m_flow_start) }}} which is interesting for several reasons. First, let's look at their definition {{{ Modelica.Media.Interfaces.PartialMedium.MassFlowRate pipe7.m_flows[pipe7.n+1] (start = fill(pipe7.m_flow_start, size(pipe7.m_flows, 1)), min = -1E+060); Modelica.Media.Interfaces.PartialMedium.MassFlowRate valve1.m_flow (start = valve1.m_flow_start, min = -1E+060); }}} with {{{ parameter Modelica.Media.Interfaces.PartialMedium.MassFlowRate pipe7.m_flow_start = system.m_flow_start; parameter Modelica.SIunits.MassFlowRate system.m_flow_start = 0; parameter Modelica.Media.Interfaces.PartialMedium.MassFlowRate valve1.m_flow_start = valve1.m_flow_nominal; parameter Modelica.Media.Interfaces.PartialMedium.MassFlowRate valve1.m_flow_nominal = 1; }}} Why does the first start attribute get evalauted while the second does not? For me the warning is correct in this case, I am puzzled though how a tool should decide which to take, since both start values have been given explicitly. Is it safe to say: ""Always take the non-zero start value""? Also, we get ""Warning: Modification or redeclaration of protected elements is not allowed."" which is correct as stated in Modelica Spec 3.3, Chapter 4.1, p. 33. However, it occurs quite frequently in MSL? What is your opinion?" Christian Schubert 2181 Add flag for model checking Command Prompt Environment trunk Future enhancement somebody new 2013-05-13T09:25:39Z 2013-05-13T09:50:54Z It would be nice to have a flag that enables model checking, i.e. the equivalent of the checkModel API call. This could be used to check if a model is balanced, without generating all the files that +s generates. Per Östlund 2354 activate dopri45 solver Run-time trunk Future enhancement Willi Braun new 2013-09-18T11:43:11Z 2017-11-14T22:08:53Z "solver dopri45 is deactivated since the cRuntime was re-structured. " Willi Braun 2547 No math parsing for experiment annotation Backend trunk Future enhancement probably noone new 2014-01-23T10:00:59Z 2017-11-14T22:08:53Z "Hi! Thanks to the great fix in r18715, it is now possible to use the experiment annotation with StartTime, StopTime and Interval. But sadly no math evaluation is done to rewrite the numbers for better readability, as demonstrated beneath: (stopTime will be 1 and NumberofIntervals will be 500, which are the standard values :-( {{{ model Test Real x; equation x = sin(3.141 * time / (3600 * 24)); annotation(experiment(StopTime = 60 * 60 * 24, Interval = 2 * 5)); end Test; }}} A warning appears: {{{ [:0:0-0:0] Warning: Ignoring unknown experiment annotation option: StopTime = 60 * 60 * 24 }}} " Jan Kokert 2638 Most Codegen* modules have dependencies to CodegenC Backend trunk Future enhancement probably noone new 2014-03-24T10:08:14Z 2017-11-14T22:08:53Z Move all shared functions CodegenC to CodegenUtil to remove all dependencies to CodegenC. And clean up CodegenC. Willi Braun 2819 List comprehensions that create zero or multiple lists MetaModelica trunk Future enhancement Martin Sjölund new 2014-09-12T13:28:37Z 2014-09-17T06:07:03Z "It would be nice if list comprehensions were a bit more flexible regarding the amount of lists created, so that something like this would work (possibly with some other syntax): {{{#!mo function f1 input Integer x; algorithm print(intString(x) + ""\n""); end f1; function f2 input Integer x; output Integer y := x*2; output Integer z := x*3; end f2; function test output list<Integer> l1; output list<Integer> l2; algorithm list(f1(i) for i in 1:3); // 'map' that doesn't return anything (l1, l2) := list(f2(i) for i in 1:3); // 'map' that returns two results for each element end test; }}} " Per Östlund 2826 Short version of match MetaModelica trunk Future enhancement Martin Sjölund new 2014-09-18T08:34:01Z 2014-09-18T14:04:02Z "It would be nice to have a more compact version of match, similar to what we have in Susan: {{{#!mo Boolean is_var := match e case DAE.VAR() then true else false; // Short version Boolean is_var := match e case DAE.VAR() then true; else false; end match; // Current version }}} I.e. just some syntactic sugar to make it more convenient to use match in assignments." Per Östlund 2957 MetaModelica reflection API MetaModelica trunk Future enhancement Martin Sjölund new 2014-11-04T09:39:07Z 2016-02-05T09:58:52Z "It would be nice to introduce a reflection API for MetaModelica (get ctor index, get record name, get field names, number of slots, index slot number). This is sometimes useful in order to debug functions where anyString provides too much information. Something like: {{{#!mo Error.addInternalError(functionName + "" failed: missing case for record "" + MetaModelica.Reflection.recordName(val), sourceInfo()) }}}" Martin Sjölund 3138 Eliminate missleading warnings concerning [min, max]-asserts Run-time trunk Future enhancement Lennart Ochel accepted 2015-02-06T10:22:13Z 2017-11-14T22:08:53Z "{{{ model testInit Real x(start=1.0, fixed=true); parameter Real b(min=0.5,fixed=false); initial equation b = 2; equation der(x) = b; end testInit; }}} A warning is issued, although the parameter b is initialized in the corresponding [min, max]-interval. Seems that the check is performed too early! Similar warnings are issued throughout most of the Modelica.Fluid.Examples. " Bernhard Bachmann 3228 Error message and expandable connectors *unknown* trunk Future enhancement somebody new 2015-03-16T15:24:57Z 2015-03-16T15:24:57Z "Consider the following code: {{{ package ExpandableConn model IntegConn Modelica.Blocks.Continuous.Integrator integrator; Conn conn; equation connect(integrator.u, conn.signal); end IntegConn; expandable connector Conn ""Control bus that is adapted to the signals connected to it"" extends Modelica.Icons.SignalBus; annotation(Diagram(graphics)); end Conn; model Master Conn conn; Modelica.Blocks.Sources.Step step(startTime = 0.5); equation connect(step.y, conn.signal); end Master; model Combined IntegConn integConn; Master master; equation connect(master.conn, integConn.conn); end Combined; annotation(uses(Modelica(version = ""3.2.1""))); end ExpandableConn; }}} If we check model ""Combined"" I get 5 equations and 5 variables. Correct. Now let us change Master so that the signal name in the connector becomes wrong: {{{ model Master Conn conn; Modelica.Blocks.Sources.Step step(startTime = 0.5); equation connect(step.y, conn.signal_); end Master; }}} When checking Combined we get the following message: Class ExpandableConn.Combined has 6 equation(s) and 7 variable(s). 5 of these are trivial equation(s). "" This is clearly because the name ""signal"" and ""signal_"" are different. This is true but it is not enough: imagine the same behaviour on a real-life simulation with hundreds of equations. A message saying that we have, let's say 500 equations and 501 variables might be VERY discouraging. However I suppose that the message can be much more selective: OM can understand that there is a variable that is taken from an expandable connector ""conn.signal"" that no other models has sent to that given connection set. So I thing a better error message could be envisaged. Just as an example it could be something like the following one ERROR: The input signal ""integrator.u"" is connected to the expandable connector signal ""conn.signal"" but no variable with this name is available in the given connection set " anonymous 3277 Discrete Fourier Transform support by OM *unknown* trunk Future enhancement somebody new 2015-04-13T18:31:15Z 2018-02-07T06:32:07Z "I would like to create a way to make the Discrete Fourier Transform (DFT) of selected signals, and then plot the harmonic spectrum (amplitudes and phases). This is very useful in electric circuits and system analysis, but useful also for vibration analysis in mechanical systems. This DFT computation, named FFT, is already available in Dymola, through a post-processing command; it would be nice if something similar can one day become available also in OMEdit. Indeed maybe DFT can in principle be already done in OM, using a modelica script to be launched from OMC Logger. Indeed I’m trying to do this, although it appears not a very easy task. Nevertheless, a specific OMEdit command would make computation of harmonic components of signals much easier. In my opinion, Dymolas’s way is not optimal: harmonic components should be shown in bar charts, not line charts. For instance I enclose DFT.pdf with pictures from Dymola and another program named PlotXY, that show the difference in readability of results. The vertical grey bar in PlotXY picture is a moveable cursor to see manually, in numerical form, the computed harmonic values For instance in the shown position it focused on the 5th harmonic and in the box viewable right-low in the window its value of 12.03 is shown. For me line plots -such as the one created by Dymola- are somewhat misleading: the computed values are indeed individual numbers, not points of a path. Moreover the bars immediately show where computed numbers are located on the horizontal axis. So my proposal is to plan a future enhancement of OMEdit so that it becomes possible to compute DFT via API, possibly in the form of a bar chart for amplitudes and another for phases of harmonic components. " massimo ceraolo 3534 Optimize FMI getters and setters for aliases FMI Future enhancement Adeel Asghar new 2015-10-31T10:17:09Z 2017-11-14T22:08:53Z "[changeset:5e6d738f1b768a0f1e9432e56f3b93bf9403de50/OMCompiler] uses value references of the original variables for positive aliases in FMI 2.0 modelDescription.xml. This causes two tests to fail: openmodelica_fmi_ModelExchange_2.0.Modelica_Mechanics_MultiBody_Examples_Elementary_DoublePendulum.mos openmodelica_fmi_ModelExchange_2.0.Modelica_Mechanics_MultiBody_Examples_Elementary_Pendulum.mos This is why the elimination of alias references has been disabled again for C FMI export in [changeset:2490aa1ec587f5a97b2cb6db6167b4e3fce40ad7/OMCompiler]. The reason for the error (incorrect alias variables with start attribute) can still be considered there -- it is just not visible in modelDescription.xml if alias variables have own value references. Once this is resolved, the respective case statements for getting or setting positive aliases can be removed from exported C code. The new function SimCodeUtil.getValueReference takes the boolean input `inElimNegAliases`. This can be set to true for FMI 1.0 to also eliminate getter/setter code for negated aliases." Rüdiger Franke 3564 Allow usage of polymorphic types as functional inputs MetaModelica Future enhancement Martin Sjölund new 2015-11-18T12:24:52Z 2015-11-18T12:33:19Z "It would be nice if this would work: {{{#!mo function f1<PF> input Real x; input PF pf; output Real y = pf(x); end f1; function f2 input Real x; input Real y = 2.0; output Real z = x + y; end f2; model test Real x = f1(3.0, f2); end test; }}} Currently the compiler complains that f1.pf is a component and not a type, but in this case it would be both. Allowing this would remove the need to declare partial functions everywhere when using functions as arguments." Per Östlund 3715 Horizontal-only and vertical-only zoom in plot window missing OMPlot v1.9.4-beta.2 Future enhancement Adeel Asghar new 2016-02-23T17:23:56Z 2016-02-24T16:21:36Z OMEdit is currently missing a horizontal/vertical-only zoom feature. In other tools this is normally accomplished by holding down the Shift key and at the same time left-click dragging either in horizontal or in vertical direction. Dietmar Winkler 3802 MetaModelica should be able to detect unassigned output variables on function return MetaModelica Future enhancement Martin Sjölund new 2016-03-29T00:22:13Z 2016-03-29T00:22:13Z "{{{#!mo function f output Boolean b; algorithm if blah then return; // b is not initialized on this branch. end if; b := true; end f; }}} See for example: [changeset:5e8c11b1932d7bbf72019fc19f62ce4c8a319d7e/OMCompiler]" Adrian Pop 3930 Better tuple access functions in MetaModelica MetaModelica Future enhancement Martin Sjölund new 2016-05-26T10:24:14Z 2016-05-26T10:24:14Z "To access elements in a tuple you currently need to either use pattern matching or one of the Util.tupleNN functions. It would be nice if there were some way of accessing the elements using an index instead, e.g.: {{{#!mo tuple<Integer, String> tup = (1, ""hello""); String s = tup[2]; // or some other equivalent syntax. // Maybe also a function to allow function pointer stuff: Integer i = tupleGet(tup, 1); // or tupleNth, or whatever. }}} This would be more flexible and possibly more efficient than using the Util.tupleNN functions, and would also make it possible to use enumerations to name elements: {{{#!mo type MyTupleNames = enumeration(index, name); String s = tup[MyTupleNames.name]; }}} An issue with this is that each tuple element has its own type, so type checking becomes a problem." Per Östlund 3962 OMEdit variable overrides OMEdit Future enhancement Adeel Asghar new 2016-06-15T14:53:51Z 2016-06-17T03:28:09Z "At some time in the last year, OMEdit switched from using -override to set changed simulation parameters to updating the parameters in the init.xml file directly. I don't like this change because the original set of start parameters are lost once an updated simulation is run. It is then no longer possible to use the original set as a reference point and it is also possible to mess up your start values such that the model no longer works (e.g., for initialization), thereby forcing the user to rebuild just to get a new init.xml file. My preference is to use the init.xml file as a reference file and then use the -override command line option to update parameter start values. This lets the user, for example, easily do parameter sweeps of one variable at a time without worrying about resetting old variables to their original values. Is there any way to revert back to the old behavior? Maybe there are good reasons for this change that I am unaware of? Perhaps giving OMEdit the option to reset parameters to the original values defined in the init.xml file would be a nice feature?" crupp@… 4010 clock ticks as time events in cpp runtime Cpp Run-time Future enhancement Volker Waurich new 2016-07-26T14:31:37Z 2016-08-11T06:23:44Z clock ticks should be implemented as time events, not a state events in the cpp runtime Volker Waurich 4078 OMEdit MetaModelica debugger suggestions OMEdit Future enhancement Adeel Asghar new 2016-10-18T13:35:20Z 2016-11-14T13:51:16Z "Since Martin fixed the compilation of OMEdit I tried to use it instead of MDT for debugging, and while it seems to work pretty well after I finally figured out how it works there are some minor issues with it. Rather than creating individual tickets for every little issue I'll just collect them here: 1. ~~If you specify an invalid program in a debug configuration, like using the wrong path for OMC, you don't get any error. It just looks like it's running without doing anything, and I didn't figure it out until I looked at the Debugger CLI.~~ 1. When stopping at a break point, a window pops up after a while (I'm guessing after 40 seconds) saying that GDB hasn't responded for 40 seconds. GDB seems to be working fine though, and choosing the option to give GDB more time allows you to continue. 1. ~~When the debugger steps into a file that's not yet open in a tab, OMEdit will open the file but will not go to the actual line. Double-clicking on the topmost stack frame will make OMEdit go to the line though.~~ 1. ~~Clicking on a stack frame seems to do nothing except highlight it, while double-clicking will go to that frame. I think it should be enough to single-click on a stack frame to go to it, since that's most likely what the user wants anyway.~~ 1. The only way I've found so far to run a debug configuration is to go into Debug->Debug Configurations, select the configuration, and press Save & Debug. This can get a bit annoying. One option would be to have a submenu under Debug that lists all configurations, or maybe only some of the configurations ordered by last use time. Another option would be to have a button with a dropdown menu like Eclipse does it. Some way of easily starting the last used configuration would also be nice. 1. ~~The variables browser lists name, type and value. I usually don't care about the type, since that can be inferred from the value most of the time anyway. So it would be nice to be able to configure which columns are shown. You can resize any column you want until it's really small though, so this is a very minor issue.~~ 1. The opened folders and the breakpoints are not saved when you quit OMEdit. 1. Right-clicking on an empty spot in the library browser doesn't do anything. I was expecting it to open a context menu where you can choose to add things, like folders for debugging, instead of having to go the File menu. 1. ~~After some further use I realised that this is not quite true, since strings are shown unquoted in the variable browser. I think it would be better to quote strings, because currently you can't differentiate between e.g. the string ""1"" and the number 1 without taking the extra step to look at the variable's type.~~ 1. ~~Another small issue: the variables in the variables browser are sorted alphabetically. That's fine for the local variables, but a bit annoying when record members are also sorted that way. As a developer I know many of the data structures in the compiler by heart, so I find it confusing when the order in OMEdit doesn't match the declared order I expect.~~ 1. OMEdit doesn't mark the line the debugger is on in any way, except for highlighting it. But if you click on another line it will highlight that line instead, and you won't know which line is active except if you double-click on the current frame in the stack browser to select the active line again. I would suggest that either the active line should be highlighted with another color than the currently selected line, or to have some symbol in the margin that indicates the active line. 1. The program, work directory and GDB path will often be the same for several debug configurations, so some way of cloning debug configurations would be nice." Per Östlund 4094 Assignment to _ should probably be illegal MetaModelica Future enhancement Martin Sjölund new 2016-10-25T14:55:21Z 2016-10-25T14:55:21Z "MetaModelica currently allows assigning to _, like this: {{{#!mo _ := match something case 1 then 1; case 2 then 2; end match; }}} This can easily occur if you change the return values of the match-statement but forget to change the lhs of the expression, and the compiler will happily accept it. But it can lead to subtle issues that can be annoying to debug, like the compiler removing the last statement in a case because it thinks it's not used. Since () is more correct than _ when a match-statement shouldn't return anything, I think it would make sense to forbid assignment to _." Per Östlund 4115 Clarify error message in the absence of voltage reference (ground) Backend v1.11.0 Future enhancement Volker Waurich assigned 2016-10-28T15:40:05Z 2017-12-04T13:25:49Z "When trying to simulate a simple electrical circuit (for example: constant voltage source + resistance) while foregetting to put a voltage reference (ground), the error message is not helpful. It complains about circular inequalities and singular linear systems (see attached Model and log). These messages actually miss the point which that ''one equation is missing'' to define electrical potentials. Is is possible to clarify the error message? In an ideal world, the error message would even suggest the user to add a Ground, but this is maybe too complex (I've no idea of the difficulty of detecting this kind of beginner's mistake)." Pierre Haessig <pierre.haessig@…> 4347 OMEdit: improve drawing of connections by correctly initiated x/y mode OMEdit Future enhancement Adeel Asghar new 2017-03-19T16:09:29Z 2017-03-19T16:21:17Z "When a connection (e.g. from a resistor to a gnd) is drawn, OMEdit seems to have a default behavior that the first line is already fixed in vertical position and when clicking the first horizontal position is set by then forming a corner. This is perfectly fine if the connectors of elements are oriented from left to right, which is the default orientation in MSL. Users, of course, will turn e.g. resistors in a way, that the connectors are vertically aligned. Then the default line initialization orientation is a bit annoying. I can imagine that it is a bit tricky for OMEdit (or the programmer :-P) to figure out, what the user actually mean. But what about the following: '''Idea 1:''' When starting a connection (by clicking and dragging) the user will already (roughly) point in the right direction e.g. 10 pixels up and 3 pixels left). By figuring out that amount and checking which is the most dominant one, the initial connection X/Y mode could be initiated properly. '''Idea 2:''' Another possibility is to update the x/y mode continuously until the first corner is set. So assume the start is at 0/0 and the mouse is at (10,3) then OMEdit is in y-fixed mode. If the mouse is moved (without clicking) to (10,23) then OMEdit switches to x-fixed mode. '''Idea 3:''' A further possibility is to allow manual switching of the mode by hitting the space bar. This is the default behavior in Eagle (a PCB layout program). After this x and y mode is alternating. I really hope that these ideas helps :D " Jan Kokert 4380 Improve result file reading Run-time Future enhancement somebody new 2017-04-03T14:05:23Z 2017-04-03T14:05:23Z "Too long ago I submitted [https://github.com/OpenModelica/OMCompiler/pull/1002 OMCompiler#1002] to enhance reading of .mat files. The intent was to improve the following: * Allow for reading files > 2Gb * Fixing the calculation of the matrix length from the matrix header information (there are truncation issues due to variable types) * Support reading files in which the results are incomplete due to a canceled solve or a solve in progress These improvements are helpful for large or long running simulations. In particular, you currently can't restart a simulation from a file >2Gb. Also, it enables viewing results in progress within OMEdit. I have not had time to fix the issues with this and won't for the foreseeable future, so I am opening it up to anyone who is willing to finish it and take credit. I will close my pull request once someone grabs the code. I got everything working for Windows, but found some issues in the Linux build after the initial pull request. I never tested macOS. There have also since recent changes to the read_matlab4.c file that need to be merged. " crupp@… 4408 top level parameter settings OMEdit Future enhancement Adeel Asghar new 2017-05-02T10:51:07Z 2017-05-02T10:51:07Z "Hi, I would like to propose a new feature for OMEdit. In order to manipulate the top-level parameters of a model from the graphical view, one could make a double-click on the canvas that opens a dialog which features all parameters (and maybe simulation settings annotations as well). What do you think? " Volker Waurich 4437 Quality of OMEdit plots not totally satisfying OMEdit Future enhancement Adeel Asghar new 2017-06-03T04:59:29Z 2017-06-03T04:59:29Z "I think that the quality of OMEdit’s line plots is not totally satisfying. We have several details that are sub-optimal and reduce the user experience’s quality. AFAIK the majority of them depends, directly or indirectly, on the plotting tool used, Qwt. I mean directly when a feature is actually not available in Qwt, indirectly when a feature is not directly supported but could be obtained through workarounds. Recently in the Qt world QChart has appeared, which is built-in in the Qt libraries. I did not try it yet, but I think it would be useful to have a look at it to see whether its quality is better or worse than Qwt’s, for OMEdit purposes. For the developers’ convenience, I try to list here the glitches that, IMO we should try to improve. 1) ''Zooming''. Very often the user might want to zoom a borderline zone of a plot. For instance the left part, or the right, or the upper or the lower. Consider the case one wants to zoom the left part. The most natural way is start to draw the zooming rectangle left of the left border of the plot to indicate that that left part of the plot is to be included. This is currently impossible in OMEdit. AFAIK there are not specific tickets on this 2) ''Number and size of numerical labels on axes''. When we make tiny plots (that are very useful and common for large simulations and tiled plots) the axes are too crowded, with even overlapping numbers. 3) ''Font size''. Both Dymola and OMEdit do not change the font size of the numerical labels on axes with plot’s size. Indeed for very tiny plots some reduction would be advisable. For me a small reduction (not a proportional reduction!) of font sizes for small plots is advisable. I see that OMEdit used a bit larger fonts than Dymola. Maybe they can be left as they are, in case of plots having both dimensions at least 400 pixels and reduced by 1-2 points for smaller plots (maybe 1 point for mildly small, 2 points for very small ones) 4) ''Minor gridlines'' Minor gridline were “invented” to find correct values when plots were on paper. On PC’s screens, basically they are useless since we can peek the actual values directly with mouse hovering. Being useless, they are more or less some “background noise” shat should be avoided; at least they should be disabled by default. (IMO they could be even dropped, but this is a question of taste) 5) ''Legend''. It occupies too much space. The space above and below legend names it is too large; in addition, the usage of coloured text would save even more space. 6) ''Minimum plot size''. When large simulations are analysed it could be useful to tile several plots, to have a global vision of the results. However, OM does not accept plots below a certain size, which is an unnecessary limitation, if the plot engine is good enough to understand that with smaller plots it has to reduce the number of numerical labels on the axes accordingly. '''Evaluation of some of the previous points based on examples. ''' I will now discuss two examples in which I compare OM plots (1.12 .alpha1) with other display tools. A) Comments TwinSmallPlots.png. This file shows twin Dymola and OMEdit windows displaying the same plot. I can comment as follows: a. ''Plot size'': the plot height I want is Dymola’s, but this is impossible to reach with OMEdit which has a larger minimum size b. ''Numerical labels'': OM’s plot has too many of them on both axes and on the horizontal axis even overlap c. ''Legend space occupation'': OM’s is too much and steals space to plot area d. ''Minor tick marks'': for tiny plots they are useless and should be removed in OM. In Dymola they are not shown. B) Comments ThreeSeveralPlots.png. This file shows three windows displaying the same plot. Above there are plots made using the freeware PlotXY, below the same plots made with Dymola and OMEdit. I can comment as follows: a. ''Legend space occupation''. Here, IMO, both Dymola and OM are bad: Dymola does not show some of the variables, OM uses too large vertical space for legend text. PlotXY exploits all the available space. In particular: • In comparison with OM’s PlotXY shows that the legend can occupy vertically much less space, and contain more information (also the file name) • In comparison with Dymola’s PlotXY shows that the legend can occupy roughly the same space and give also the file name. In case the file name is dropped, with less space than Dymola it can show all the variables, with the trick of using coloured text b. ''Labels on the vertical axis''. Here IMO the right solution would be to add once on the axis “*103” and use numerical labels without the exponential part (as per upper-left plot). Both Dymola and OM fail to do that. OM, in addition, is worse since the exponent part uses a 4-character space instead of two. Whenever the unit of measure is available it should be used, with correct usage of standard prefixes (upper-right plot) ''Just a final word on this ticket's meaning. I know that many people think that plotting in OMEdit simply works and therefore discussing these details is a waste of time. This is not my opinion: for me quality counts. That's why I created PlotXY. That's why I used on this ticket title the word ""quality"". This ticket is not on pure usability, but on quality of details. Steve Jobs changed the world just starting to make the same things others already made, but with higher quality... ''" massimo ceraolo 4443 Wish for background-color setting in OMEdit OMEdit Future enhancement Adeel Asghar new 2017-06-10T10:27:36Z 2020-04-13T14:41:24Z Using debian Jessie with xfce4.10 xfce-dusk (black background) Desktop Environment, in OMEdit it is possible to change text colors e.g. text from black to white. Still, dark/black library Icons are not visible. So far it is possible to omit the non-Visibles by changing the theme of xfce. It would be nice to have a feature in OMEdit to set the appearance of OMEdit (text background and whole OMEdit background color), to have it seperate from the general desktop theme. mbertele@… 4648 Add support for annotation for turning off replaceable check New Instantiation v1.13.0-dev-nightly Future enhancement Per Östlund new 2017-11-29T14:18:28Z 2017-11-29T14:18:28Z "#4646 was solved by introducing the --ignoreReplaceable flag for turning off the check that an element is replaceable before redeclaring it. Using this flag can mask actual mistakes by the user, so it would be good to have a more finegrained solution that allows the check to be turned off for an individual modifier. For example: {{{#!mo model M A a(redeclare model B = C annotation(__OpenModelica_IgnoreReplaceable)); end M; }}}" Per Östlund 4719 Saving plot sessions OMEdit v1.13.0-dev-nightly Future enhancement Adeel Asghar new 2018-01-24T11:22:56Z 2018-01-25T10:21:02Z "I'm not totally sure, but I think there are not tickets on this topic yet. It is very common that one starts OMEdit and wants to restart activity from were was last left. For this the ""Recent files"" menu in the Welcome tab is very useful. However to restore a previous session one has to reload a previous loaded plot file, re-create the plot windows that were previously displayed, select all the variables, and possibly re-zoom or select manual scales. I think this is a very common situation, and therefore some automation of this activity would save a lot of clicks to many users. What I propose: add a way ""to save a plot session"" and to ""restore a plot session"". Maybe a ""saved plot session"" list could be added to the Welcome tab. When we save a plot session we could give it a name for instance ""Filtered circuit"" or ""basic car model 1"", etc. When saving a plot session, ideally we should save, for each existing plot: - type (plot, parametric plot, array plot) - size and position of its window - customisation (min and max of axes, possible log axes, type of grid) - variables to be plot (name of file and name of variable) When restoring a plot session, ideally we should first reload the output files involved, then open the plot windows with the saved details and plot variables. There is the problem that a file with a given name could not be exactly the same when saved, for instance could have some more or less variables. So reloading should be aware of this, to avoid unpredictable results. ''Just a final comment. Since OMEdit is written in Qt, I can mention that the proposed feature is similar to what is in ""sessions"" list in the Qt Welcome page.''" massimo ceraolo 5118 OMC should generate debug information and PDB files for debugging with Visual Studio Code Generation Future enhancement Adrian Pop accepted 2018-09-12T02:37:14Z 2018-09-12T13:55:40Z "I had several issues with co-simulation FMUs to be run under Vector CANoe. Debugging them was not that easy, because I was not able to use Visual Studio, but had to resort to the {{{gdb}}} binary, which I found in the OpenModelica directory. Even when working with this, I first had to modify the FMU's {{{Makefile}}} to generate debug information. It would be helpful, if there would be a switch to generate debugging information and eventually generating mixed source and (dis)assembler listings. The debug information should also be made available as PDB files. [https://github.com/rainers/cv2pdb] might be helpful for this." tknodt@… 5181 OMSimulator and stand-alone simulation should be able to save results as ASAM MDF/ MF4 files *unknown* v1.13.0-dev-nightly Future enhancement somebody new 2018-10-22T20:17:44Z 2018-10-22T20:17:44Z OMSimulator and stand-alone simulation should be able to save results as ASAM MDF/ MF4 files. See [https://www.asam.net/standards/detail/mdf/]. Torsten Knodt <tknodt@…> 5222 adding OpenModelica to Windows package managers *unknown* Future enhancement Adrian Pop assigned 2018-11-21T08:59:36Z 2018-11-21T11:26:13Z There are plenty of package managers for windows including Chocolatey and Scoop. It would be beneficial for both users and developers to use/install and distribute the software through those package managers instead of just installing the binary. f.s.farimani@… 5432 Omitting stopTime in modelDescription.xml FMI Future enhancement Lennart Ochel new 2019-04-12T06:28:00Z 2019-04-12T08:46:39Z "I'm trying to implement the FMU from OM in a HiL test and one of the requierment is omit the stopTime on FMU's xml file in order to sucessfully run the application in a rt-machine. I know we can set the stopTime in model's annotation, but it is posible to omit this if for example the stopTime is set to Inf? {{{ annotationexperiment(StartTime = 0, StopTime = Inf, Tolerance = 1e-06, Interval = 1) }}} " Arinomo <trista.arinomo@…> 5884 Supporting OSI-interfaces OMSimulator v.1.15.0-dev Future enhancement Lennart Ochel new 2020-03-09T11:48:09Z 2020-03-09T13:20:14Z "When I want to create a .ssp, OSI-interfaces shall be available as possible interface. Supporting FMI 2.0 -> 3 integer ports - base.hi - base.lo - .size" nico.dahringer@… 1754 Change ADD/MUL to n-ary expressions Frontend Future task somebody new 2012-06-18T09:24:04Z 2012-08-30T10:05:50Z "Change ADD/MUL to n-ary expressions in order to simplify simplifications: {{{ record NARY Operator op; list<Exp> expl; end NARY; }}}" Martin Sjölund 4811 array_alloc_real_array error Code Generation v1.13.0-dev-nightly NeedsInput defect somebody assigned 2018-03-19T07:03:01Z 2018-04-09T11:44:51Z "Hello ... it's a great tool you have there !!! Well I have a program that runs on Linux Debian on a 32bit machine but doens't on a W10 64bit . The program is using vectors, and transpose of matrices. Here is the error message ... in fact it repeats itself a lot in one code. So thank you very much for checking this. I am running this from W10 and not from a cygwin or msys2_shell.cmd window. {{{ WENO.EXA.TestLine02_06inz.c:1740:37: error: incompatible type for argument 3 of 'array_alloc_real_array' array_alloc_real_array(&tmp11, 2, 0.0, data->localData[0]->realVars[414] /* line021.VV0[7] variable */); ^ In file included from C:/OpenModelica1.13.0-dev-64bit/include/omc/c/openmodelica_func.h:50:0, from MODELNAME.EXA.TestLine02_model.h:5, from MODELNAME.EXA.TestLine02_06inz.c:2: C:/OpenModelica1.13.0-dev-64bit/include/omc/c/util/real_array.h:144:13: note: expected 'real_array_t {aka struct base_array_s}' but argument is of type 'double' extern void array_alloc_real_array(real_array_t* dest,int n,real_array_t first,...); ^ WENO.EXA.TestLine02_06inz.c:1741:37: error: incompatible type for argument 3 of 'array_alloc_real_array' array_alloc_real_array(&tmp12, 2, 0.0, data->localData[0]->realVars[415] /* line021.VV0[8] variable */); ^ In file included from C:/OpenModelica1.13.0-dev-64bit/include/omc/c/openmodelica_func.h:50:0, from MODELNAME.EXA.TestLine02_model.h:5, from MODELNAME.EXA.TestLine02_06inz.c:2: C:/OpenModelica1.13.0-dev-64bit/include/omc/c/util/real_array.h:144:13: note: expected 'real_array_t {aka struct base_array_s}' but argument is of type 'double' extern void array_alloc_real_array(real_array_t* dest,int n,real_array_t first,...); }}} " brix.frederic@… 6220 Small array optimizations: stack allocation Run-time NeedsInput defect Mahder Alemseged Gebremedhin new 2020-11-12T15:39:10Z 2020-11-17T12:03:42Z "Arrays of OpenModelica runtime are defined as the following struct {{{#!c struct { int ndims; _index_t *dim_size; void* data; m_boolean flexible; }; }}} Here is a very basic ""small static"" array of 1 dimension that can be a starting point for implementation. {{{#!c #define SMALL_ARRAY_1(name, type, dim1) \ struct { \ int ndims; \ _index_t *dim_size; \ void* data; \ m_boolean flexible; \ _index_t dim_size_d[1]; \ type data_d[dim1]; \ } name = {1, arr1.dim_size_d, arr1.data_d, 0, {dim1}, {0}}; }}} Basically it is the normal array struct with additional members added at the bottom so that it can be ""sliced"" when casted as the normal array struct. The pointer members are initialized to point to the data allocated on the stack by the last two members respectively. I am not sure how `point of declaration` is enforced with C but if it does not work we will find out pretty soon. It can be used as {{{ SMALL_ARRAY_1(arr1, modelica_real, 3); }}} to declare an `arr1` array of `modelica_real` with 1 dimension of size 3. This matches the expected interface for normal (non-static) arrays while keeping its data on stack. That is, it can be passed to functions that we already use for the normal arrays. Of course there are warning about incompatibility of passed pointers and so on. For example this can be passed to ""getter"" functions as {{{#!c real_array_get(arr1, 1, _i) = 1; }}} We need to figure out a way to safely copy these and normal arrays between each other (if that turns out to be needed). There are many things that can go wrong with this. We will find out. If you have suggestions, ideas, tricks, concerns ... please let me know :). We want to implement this with as small change as possible to code generation and Modelica compilation. " Mahder Alemseged Gebremedhin 4171 "Schema of the ""dumpXMLDAE"" output points to dead URL" *unknown* defect somebody new 2016-12-06T10:19:01Z 2021-09-13T11:58:21Z "Hello, The XML schema of the ""dumpXMLDAE"" output points to http://home.dei.polimi.it/donida/Projects/AutoEdit/Images/DAE.xsd. This address doesn't exist anymore. In fact, the entire personal webpage of Filippo Donida, the coauthor of the 2009 paper which introduces this representation (1) is ""not found 404"". There is still the homepage of another coauthor (http://home.deib.polimi.it/casella/) Anyway, I believe it would be safer to put the schema (assuming somebody can find it, perhaps the other coauthors) at a more permanent address. Maybe modelica.org if this representation is standardized enough. Also, I saw other tickets here about the ""XML output from Modelica"", but I'm not sure it is the same one as this XML DAE (e.g. issues #4024 and #3857), since those tickets mention a schema defined by JModelica people. Is there a relationship ? best, Pierre (1) An XML Representation of DAE Systems Obtained from Modelica Models, 7th Modelica Conference, 2009 https://www.modelica.org/events/modelica2009/Proceedings/memorystick/pages/papers/0073/0073.pdf " Pierre Haessig <pierre.haessig@…> 4242 missing assert Backend defect Lennart Ochel new 2017-01-30T15:47:39Z 2021-09-13T11:58:21Z "following example does not trigger an assert {{{#!modelica model tsatAssert parameter Real t = Modelica.Media.Water.IF97_Utilities.BaseIF97.Basic.tsat(-1); end tsatAssert; }}} " Vitalij Ruge 4324 OMEdit: Additional space added after editing parameters Interactive Environment defect Martin Sjölund assigned 2017-03-15T21:35:57Z 2021-09-13T11:58:21Z "Sorry, another very minor issue: If we add a component from the Library to the Diagram View, we get something like this: {{{Modelica.Electrical.Analog.Basic.Resistor resistor1 annotation( ...);}}} If we now edit the parameters e.g. R = 1 via contextmenu->parameter, the line will change into: {{{Modelica.Electrical.Analog.Basic.Resistor resistor1(R = 1)__annotation( ...);}}} Have you ever noticed the two spaces? Or do they have a special reason? (Damn, two spaces are not possible in trac - I used two underscores {{{__}}} instead)" Jan Kokert 4422 Installation of OpenModelica fails if not explicitly executed as Administrator Installation program v1.11.0 defect Adeel Asghar new 2017-05-18T20:03:23Z 2017-05-18T20:03:23Z "Installing Openmodelica 1.11 64bit on a Windows 10 Machine with the latest updates (2017-05-01) and on an account that had Administrator rights, the installation program aborted shortly before finishing with an error. This was reproducable. After repeating the installation using the right click -> ""run as administrator"" command, it worked without any problems. I suggest adding a note on the download site to always ""run as administrator"" when installing." alexander.pollok@… 6040 Output variables changing name in FMU FMI v1.16.0-dev defect Andreas Heuermann assigned 2020-06-30T15:15:34Z 2021-09-13T11:58:21Z "When declaring a variable as an output and generating a FMU the variable name gets changed. Run {{{ loadString("" model simpleOutput output Real x (fixed=true, start=1); Real y (fixed=true, start=2); parameter Real a=2; equations der(x) = a*x; der(y) = a*y; end simpleOutput; ""); getErrorString(); buildModelFMU(simpleOutput); getErrorString(); system(""unzip -p simpleOutput.fmu modelDescription.xml > modelDescription.xml""); getErrorString(); }}} and than the modelDescription.xml will contain {{{ <ModelVariables> <!-- Index of variable = ""1"" --> <ScalarVariable name=""_D_outputAlias_x"" valueReference=""0"" initial=""exact""> <Real start=""1.0""/> </ScalarVariable> <!-- Index of variable = ""2"" --> <ScalarVariable name=""y"" valueReference=""1"" initial=""exact""> <Real start=""2.0""/> </ScalarVariable> <!-- Index of variable = ""3"" --> <ScalarVariable name=""der(_D_outputAlias_x)"" valueReference=""2"" > <Real derivative=""1""/> </ScalarVariable> <!-- Index of variable = ""4"" --> <ScalarVariable name=""der(y)"" valueReference=""3"" > <Real derivative=""2""/> </ScalarVariable> <!-- Index of variable = ""5"" --> <ScalarVariable name=""x"" valueReference=""4"" causality=""output"" > <Real/> </ScalarVariable> <!-- Index of variable = ""6"" --> <ScalarVariable name=""a"" valueReference=""5"" variability=""fixed"" causality=""parameter"" > <Real start=""2.0""/> </ScalarVariable> </ModelVariables> }}} This internal name should not be visible outside of the FMU." Andreas Heuermann 6092 Wrong time display for parameter for simulation not starting at 0 OMEdit v1.16.0-dev defect Adeel Asghar new 2020-08-21T17:13:20Z 2021-09-13T11:58:21Z "When simulating this simple model {{{ model paramTime parameter Real x = 1; equation annotation( experiment(StartTime=1, StopTime=2, Tolerance=1e-6, Interval=0.002)); end paramTime; }}} from `StartTime=1` OMEdit will display the time axis in the plot window starting at `time=0` and not starting from `1`. This only happens for mat-files, since we don't export parameters to CSV anyway (see #2876). I guess we save parameters only at one time point and that this point is not startTime but 0." Andreas Heuermann 6293 Function non-inputs are initialized in the wrong order New Instantiation v1.17.0-dev defect Per Östlund new 2020-12-17T15:02:24Z 2021-09-13T11:58:21Z "Non-input components in functions should according to 12.4.4 be initialized in an order such that a variable isn't used before it has been initialized. The NF does not yet do this, which causes e.g. `ModelicaTest.Fluid.Dissipation.Verifications.HeatTransfer.HeatExchanger.kc_flatTube` to fail during simulation due to using uninitialized variables. The old frontend handles this by reordering the protecteds component according to their dependencies, but obviously it can't do that with the output components which means it has issues with something like: {{{#!mo function f input Real x; output Real y = z; // OF assigns z to y before z has been initialized output Real z = x; end f; model M Real x, y; equation (x, y) = f(time); end M; }}} We should investigate whether there's some way to specify the initialization order without actually reordering the components so we can handle both protected and output components in the NF. " Per Östlund 6390 Cannot extend from RealOutput New Instantiation 1.16.2 defect Per Östlund new 2021-02-19T13:39:56Z 2021-09-13T11:58:21Z "{{{#!mo connector ElectricCurrentOut extends Modelica.Blocks.Interfaces.RealOutput( final quantity= ""ElectricCurrent"", final unit=""A"", displayUnit=""A""); annotation(uses(Modelica(version=""4.0.0""))); end ElectricCurrentOut; }}} {{{ Error: Internal error Invalid connector type on component unit }}}" Martin Sjölund 6424 linear_model.py : two syntax errors *unknown* 1.16.2 defect arunkumar palanisamy assigned 2021-03-13T18:07:04Z 2022-03-17T08:53:58Z "Good morning, after call of linearize with --linearizationDumpLanguage=python there is two syntax erros def linearized_model() should be terminate by : so def linearized_model(): No ""end"" at the end of file in python In file : OpenModelica-master/OMCompiler/Compiler/Template/CodegenC.tpl template functionlinearmodelPython from line 4806 to 4845 in particular line 4821 : return ""def linearized_model()\n"" become return ""def linearized_model():\n"" lines 4837-3488 "" return (n, m, p, x0, u0, A, B, C, D)\n"" ""end""; become "" return (n, m, p, x0, u0, A, B, C, D)\n""; Best regards " anonymous 4309 OMEdit: Status bar: Improve display of component coordinates OMEdit enhancement Adeel Asghar accepted 2017-03-14T06:43:08Z 2021-09-13T11:58:21Z "Sorry to bother you with another minor-issue ticket. I noticed that in the bottom status bar (""X: ~ | Y: ~"") the X and Y values are odd and not helpful. The values where probably correct back in the days, when we did not have a snap-to-grid feature. Today it is not possible to move icons to these odd positions and consequently, rounded values should be displayed instead. Also, one can think of displaying the origin of the component which is dragged at the moment and not the mouse position. Furthermore, a delta-display and an extent-display could be added, showing how many (integer) units are moved towards right or top and showing the width/height of the object. A good example for an excellent status bar is {{{paint.net}}} [http://www.getpaint.net/index.html] in the shape-editing mode. Paint.net is a free improved version of MS paint. " Jan Kokert 5945 Position of the output box always in the primary screen OMEdit enhancement Adeel Asghar new 2020-05-09T07:31:08Z 2021-09-13T11:58:21Z "OMEdit works nicely when is run on the secondary screen. A minor glitch is that the simulation output dialog box (the one shown when compilation and simulation are running and containing the progress bar) is always on the primary screen. Even if at the first simulation I move it into the secondary (where the main windows of OMEdit is), at the next one it is shown again on the primary screen. I think that at its first appearance it should be on the same screen in which the main OMEdit window is, and at the next ones on the same screen where it was left in the last earlier show. Note that the Re-simulate Setup window has a much better behaviour: the second time is displayed on the same screen as was left the previous time it was shown. Ideally both of them, the first time are open, should appear on the same screen in which OMEdit is shown." massimo ceraolo 6402 Enable/disable Line Wrapping from editor context menu (right-click) OMEdit v1.17.0-dev enhancement Adeel Asghar new 2021-03-04T02:50:42Z 2021-09-13T11:58:21Z "Hi there, I think it would be a good idea to be able to enable/disable line wrapping directly from the context menu (that is: right-click on the editor). Currently this option is available in Tool->Options->Text Editor. What do you think? Cheers, Franco Ferrucci" franco.ferrucci@… 3925 Protected variables are incorrectly written to the result file Run-time 2.0.0 defect Per Östlund assigned 2016-05-24T21:48:23Z 2017-11-14T16:49:18Z "I have some models where I am trying to make the size of the result file more manageable by making protected the internal variables of a model which are not of interest. I can do it in two ways: - put some variables in a model inside the protected section - for composite model, declare the sub-models in the protected section, so that their entire contents become protected In both cases, the corresponding variables are correctly marked as {{{isProtected = ""true"" hideResult = ""false""}}} in the {{{_init.xml}}} file. However, the variables from the first set are correctly not written to the result file, while the variables from the second set are written to the file. Q1: Why is this happening? Q2: Shouldn't the simulation runtime use the attributes from the XML file to decide whether or not a variable needs to be saved onto disk? I can provide the test case privately to any interested developer." Francesco Casella 4174 OMNotebook: change in text in LaTeX cell does not show the star (*) in the filename OMNotebook v1.12.0 2.0.0 defect arunkumar palanisamy assigned 2016-12-08T15:16:35Z 2016-12-15T11:25:18Z "The title says it all: if you saved a notebook and then modify the contens of a latex cell, the window title does not show the asterisk." Henning Kiel 3121 Missing bindings in flattened operator overloading example New Instantiation trunk 2.1.0 defect Per Östlund assigned 2015-01-30T14:38:26Z 2018-07-02T14:11:41Z "This model contains errors (in operator ""+"" inputs should be a BugRecord type). Trace is attached. {{{ #!mo model Bug operator record BugRecord Integer x; operator function '+' input Bug b1; input Bug b2; output BugRecord rec(x = b1.x + b2.x); end '+'; end BugRecord; BugRecord bugRecord = BugRecord(1) + BugRecord(0); end Bug; }}}" anonymous 1429 Some kinds of array equations are not supported Backend Future defect somebody assigned 2011-02-08T12:06:09Z 2017-11-14T22:08:53Z "The array equation in this model: {{{ function pointGravity input Real r[3] ""position""; output Real g[3] ""gravity acceleration""; parameter Real k=1; protected Real n[3]; algorithm n := -r/sqrt(r*r); g := k/(r*r) * n; end pointGravity; model Particle parameter Real m = 1; Real r[3](start = {1,1,0}) ""position""; Real v[3](start = {0,1,0}) ""velocity""; equation der(r) = v; m*der(v) = m*pointGravity(r); end Particle; }}} gives the error message (from SimCode.mo): {{{ Error: Internal error array equations currently only supported on form v = functioncall(...) }}}" Per Östlund 1703 Comments are not merged Frontend Future defect Martin Sjölund new 2012-02-29T14:44:36Z 2016-02-05T09:58:52Z "{{{ model M Real r; end M; model N extends M(r = 1.5 ""abc""); end N; }}} r does not get the description ""abc"" in the flattened code!" Martin Sjölund 2007 Typeinformation is wrong for components of an array Frontend trunk Future defect Adrian Pop new 2013-01-02T12:50:27Z 2017-10-29T21:53:22Z "Hi, the type information for t[i].x of the following model is wrong {{{ model TestVarType T t[4]; end TestVarType; }}} with {{{ model T Real x; equation x = 2; end T; }}} +d=dumpdaelow gives {{{ 1: t[4].x:VARIABLE() .TestVarType, .TestVarType.T, .Real type: Real [4] }}} but t[4].x should be a simple Real instead of Real[4]. " Christian Schubert 2377 Not returning in function with tuple output causes error in bootstrapped compiler MetaModelica trunk Future defect Martin Sjölund new 2013-09-30T15:03:03Z 2016-02-05T09:58:52Z "The following function causes an error (""Invalid pattern: (outString1,outString2) of type #NORETCALL#"") in the bootstrapped compiler: {{{ function test input String inString; output String outString1; output String outString2; algorithm (outString1, outString2) := matchcontinue(inString) case (_) then fail(); else then fail(); end matchcontinue; end test; }}}" Per Östlund 2417 Support arrayLayout Code Generation trunk Future defect assigned 2013-10-10T23:44:10Z 2017-11-14T22:08:53Z "It seems we don't support arrayLayout annotation. From the specification: {{{ function fie input Real[:,:] a; output Real b; external; annotation(arrayLayout = ""columnMajor""); end fie; This corresponds to the following C-prototype: double fie(double *, size_t, size_t); ] }}} " Adrian Pop 3591 "OMEdit fails when opening ""total save"" model" OMEdit Future defect Adeel Asghar new 2015-12-10T17:26:50Z 2015-12-11T00:48:51Z "The attached model is created by using `File->Save Total` on the model `Modelica.Blocks.Examples.PID_Controller`. It works to simulate the model using scripting: {{{ loadFile(""PID_ControllerTotal.mo""); simulate(PID_Controller_total); }}} However, it is not possible to open the model in OMEdit. Trying to open it results in an error message, similar to {{{ Only single nonstructured entity is allowed to be stored in the file PID_ControllerTotal.mo }}}" Bernhard Thiele 3972 Redefinition of OMC_FILE macro Code Generation Future defect Lennart Ochel new 2016-06-22T12:56:38Z 2016-06-22T12:56:38Z "Redefinition of OMC_FILE macro causes warnings from compiler: {{{ 1 warning generated. In file included from LotkaVolterra_16dae.c:23: In file included from ./LotkaVolterra_functions.h:15: ./LotkaVolterra_model.h:4:11: warning: 'OMC_FILE' macro redefined [-Wmacro-redefined] #define OMC_FILE ""/tmp/OMEdit/LotkaVolterra_model.h"" LotkaVolterra_16dae.c:4:11: note: previous definition is here #define OMC_FILE ""/tmp/OMEdit/LotkaVolterra_16dae.c"" }}} Appears only when compiling for algorithmic/transformational debugger: *_12jac.h *_13opt.h *_16dae.h *_model.h " Henning Kiel 4015 OMEdit Plot: Log scale dose not take settings from zoom box OMEdit Future defect Adeel Asghar new 2016-07-31T13:28:46Z 2016-07-31T13:28:46Z "I simulated a simple RC circuit model and plotted the graph (exp. decay). I zoom into a small area with the zoom tool. Then I activate ""Log Y"" to see a strait line. But now the y-axis starts at a very small value (1E-5). An explanation is that this y_min value is not the lowest value of the box zoom but the lowest value of the whole simulation result. Deactivating the ""Log Y"" option confirmes that. So could you please improve the switching from normal to log mode and back?" Jan Kokert 4217 OM Resolution issue OMEdit Future defect Adeel Asghar new 2017-01-17T15:01:18Z 2017-03-10T14:03:47Z "I recently built OM on a MacBook Pro with a ""retina"" display. The highlighted parts of selected tabs are only showing has half highlighted. I have attached a screen grab. Not the selected model (PID_Controller) and the selected window (Modeling). Each tab is half light and half dark. Additionally, when loading a model there is a scripting error, as shown, that might be related ([2] 09:56:25 Scripting Error QFont::setPixelSize: Pixel size <= 0 (0)) I suspect that the issue relates to how qt4 or OM read screen resolution. This is only a minor cosmetic issue, as OM seems to operate fine. But, I thought that it was worth having a ticket in the system. " Adam Dershowitz 4976 Optimization objective missing Optimization Future defect Vitalij Ruge new 2018-06-05T09:56:38Z 2018-06-05T16:22:54Z "If we follow the instructions in the OpenModelicaUsersGuide, chapter 8, we can reproduce the users's guide plots for Batch Reactor optimisation run. However there is something strange. I created as prescribed a file ""nmpcBatchReactor.mo"" containing: {{{ optimization nmpcBatchReactor(objective=-x2) extends BatchReactor; end nmpcBatchReactor; }}} But if I make {{{ loadFile(""nmpcBatchReactor.mo"") list(nmpcBatchReactor) }}} I get: {{{ ""optimization rmpcBatchReactor extends BatchReactor; end rmpcBatchReactor;"" }}} To the optimization objective is not shown. Also looking at the optimization output log, I cannot find indication that OMC has really minimised -x2 (this must be inferred from analysis of the plots). So I see two issues here: 1) list does not show the optimisation objective 2) record SimulationResult and following log do not show the optimisation objective as well. " massimo ceraolo 5893 Modelica.Mechanics.MultiBody.Examples.Elementary.Surfaces fails with internal error *unknown* v1.16.0-dev Future defect somebody new 2020-03-20T16:47:00Z 2020-03-20T16:47:00Z "The first command line options set gives the issue, the other doesn't. {{{ clo := {""--matchingAlgorithm=PFPlusExt --indexReductionMethod=dynamicStateSelection -d=newInst,nfAPI,nogen,initialization,evaluateAllParameters,NLSanalyticJacobian,infoXmlOperations,graphml,visxml,aliasConflicts,stateselection,bltmatrixdump --postOptModules=lateInlineFunction,wrapFunctionCalls,inlineArrayEqn,constantLinearSystem,simplifysemiLinear,removeSimpleEquations,simplifyComplexFunction,solveSimpleEquations,tearingSystem,inputDerivativesUsed,calculateStrongComponentJacobians,calculateStateSetsJacobians,symbolicJacobian,removeConstants,simplifyTimeIndepFuncCalls,simplifyAllExpressions,findZeroCrossings,collapseArrayExpressions --preOptModules=evaluateParameters,simplifyIfEquations,expandDerOperator,clockPartitioning,findStateOrder,replaceEdgeChange,inlineArrayEqn,removeSimpleEquations,comSubExp,resolveLoops,evalFunc,encapsulateWhenConditions --simCodeTarget=C --target=gcc +ignoreCommandLineOptionsAnnotation=false +ignoreSimulationFlagsAnnotation=false"", ""--matchingAlgorithm=PFPlusExt --indexReductionMethod=dynamicStateSelection -d=newInst,nfAPI,nogen,initialization,NLSanalyticJacobian,infoXmlOperations,graphml,visxml,aliasConflicts,stateselection,bltmatrixdump --postOptModules=lateInlineFunction,wrapFunctionCalls,inlineArrayEqn,constantLinearSystem,simplifysemiLinear,removeSimpleEquations,simplifyComplexFunction,solveSimpleEquations,tearingSystem,inputDerivativesUsed,calculateStrongComponentJacobians,calculateStateSetsJacobians,symbolicJacobian,removeConstants,simplifyTimeIndepFuncCalls,simplifyAllExpressions,findZeroCrossings,collapseArrayExpressions --preOptModules=evaluateParameters,simplifyIfEquations,expandDerOperator,clockPartitioning,findStateOrder,replaceEdgeChange,inlineArrayEqn,removeSimpleEquations,comSubExp,resolveLoops,evalFunc,encapsulateWhenConditions --simCodeTarget=C --target=gcc +ignoreCommandLineOptionsAnnotation=false +ignoreSimulationFlagsAnnotation=false""}; }}} the error returned: {{{ [1] 17:12:31 Translation Error [C:/dev/OM64bit/OMCompiler/Compiler/NFFrontEnd/NFCeval.mo: 2206:22-2206:79]: Internal error NFCeval.evalBuiltinFill2 got invalid arguments (b) }}} I'm on 1.16.0-dev-197-g05f528fd5 " dariomangoni@… 3568 Performance issues in DIVISION_SIM Run-time Future discussion somebody new 2015-11-19T15:02:13Z 2018-04-12T16:44:15Z "Hi all, I'm running a model that has lot of divisions. The C generated code inserts the macro DIVISION_SIM for each division. This macro (as far as I understand) checks for zero and allows zero division at initialization (when initial()==1). This is OK for user-friendliness but in my case I see a ~50% performance penalty for these checks. My model has no division by zero. Using the original DIVISION_SIM macro the simulation takes 26.81 seconds. If I replace this macro for the normal division it takes 14.15 s. Are these checks necessary for something else than showing a meaningful error message? If no, perhaps using the division should be the by-default behavior showing a not-so meaningful ""Division by zero"" message and asking the user to run the model with a specific flag that includes the check. Also the check of initial() is not necessary after the initialization. Perhaps the equations could be split into initials allowing division by zero, and dynamic ones not allowing it but without checking initial() on every division. What you guys think? " Federico Bergero 4458 Idea: OpenModelica Language Server Protocol *unknown* Future discussion somebody new 2017-06-28T07:42:39Z 2021-03-08T12:54:48Z "The Language Server Protocol LSP is a suggestion by Microsoft, how an editor could interact with a language server to offer features like syntax highlighting, type hints, word completion and more. http://langserver.org/ https://github.com/Microsoft/language-server-protocol Animated gifs of the features in action are e.g. here: https://github.com/palantir/python-language-server Editors that are supported include VS Code, Atom, Eclipse, Emacs, Vim and Sublime (partly work in progress). Inspired by these two tickets: https://trac.openmodelica.org/OpenModelica/ticket/3705 https://github.com/THM-MoTE/mope-server/issues/3 I would like to ask whether it would be possible to add a Modelica language server!?" m.thorade@… 1169 translateGraphics might also support 2.x to 3.x annotations update. Interactive Model Editor Interface Future enhancement donida new 2010-02-11T17:08:23Z 2013-06-05T10:54:34Z I would be nice to be able to update from Modelica 2.x to Modelica 3.x annotations by using the translateGraphics() API (which now is working for 1.6 to 2.2 translation). donida 1932 Redesign When Equation Implementation in Backend Backend trunk Future enhancement Willi Braun accepted 2012-11-09T12:13:10Z 2014-11-03T14:02:46Z "The current implementation for when equations does not consider the MSL3.2 requirements in an efficient way. cr = ... (cr,cr,..) = ... For example the following when when cond then (cr1,cr2) = func(...) elsewhen cond1 then cr1 = exp; cr2 = exp; end when; should be legal modelica but its not efficient supported. " Jens Frenkel 1974 Types in the OMC compiler Build Environment trunk Future enhancement Adrian Pop new 2012-12-07T10:00:27Z 2013-04-28T01:16:54Z " Maybe we should switch all the f2c types from int to long so they are the same size as void* on different platforms. Also, it might be a good idea to have our own types everywhere in the compiler. Have a new header omc_types.h where we define all the types we need and we use them everywhere: - SimulationRuntime/* - Compiler/runtime - generated code - parser We have this in openmodelica.h: {{{ #if defined(__alpha__) || defined(__sparc64__) || defined(__x86_64__) || defined(__ia64__) typedef int fortran_integer; typedef unsigned int fortran_uinteger; #else typedef long int fortran_integer; typedef unsigned long int fortran_uinteger; #endif }}} ""int"" is rather bad because it varies in size on different platform and various issues might appear because of data loss when casting, etc. Comments, suggestions? Feel free to comment here." Adrian Pop 2438 OMEdit - desired features OMEdit trunk Future enhancement Adeel Asghar new 2013-10-25T09:06:15Z 2017-10-12T18:26:34Z "Here is a wishlist of desired features in OMEdit: 1. display the extends in the class tree (and make it possible to expand it to the leafs) 2. display prefixes replaceable and inner for classes in the class tree " Adrian Pop 2937 Bootstrapped compiler - check for cases that are exactly the same (on some flag) MetaModelica trunk Future enhancement Adrian Pop accepted 2014-10-29T01:36:27Z 2014-10-30T16:34:07Z Seems that (incredibly) we have cases in matchcontinue that are exactly the same (probably some copy paste error). We should probably detect these. Adrian Pop 3320 Optimization settings as annotations OMEdit trunk Future enhancement Adeel Asghar new 2015-05-18T15:00:54Z 2015-05-18T15:36:05Z "OM does an incredibly good job with its optimization engine. I was taught to use it by setting ""optimization"" as integration method and ""-optimizerNP=1"" as simulation flag. Unfortunately these two settings are not saved in the file to be optimized, and they have therefore to be set manually whenever OMEdit is started-up or whenever one switches from ordinary simulation to optimization. I wonder whether it is possible to use a couple of vendor-specific annotations to store this info, so that it is kept inside the file. " anonymous 3555 Add option to save intermediate values at event iterations to result files? Run-time Future enhancement Lennart Ochel accepted 2015-11-11T23:29:47Z 2015-11-12T09:08:04Z "There already exists the option to save values at events. If one has event iterations it also would be interesting to see the values at intermediate events in an event iteration. E.g., the model below starts an event iteration at `time > 2` that results in the output {{{ D x: 2 A x: 5 B x: 6 }}} but in the (csv) result file at t=2 there are only two entries (x=2 and x=6). {{{ #!modelica model WhenPriority import S = Modelica.Utilities.Streams; Integer x(start=0,fixed=true); equation when pre(x) == 2 then S.print(""A x: ""+String(x)); x = pre(x) + 3; elsewhen pre(x) > 4 then S.print(""B x: ""+String(x)); x = pre(x) + 1; elsewhen pre(x) > 3 then S.print(""C x: ""+String(x)); x = pre(x) + 2; elsewhen time > 2 then S.print(""D x: ""+String(x)); x = 2; end when; end WhenPriority; }}} Of course that doesn't improve the insight to the model if plotting the variable with current OMPlot, but ""customized"" visualization solutions could profit from it and even try to visualize the event order. " Bernhard Thiele 4200 Save Animation *unknown* Future enhancement Volker Waurich assigned 2016-12-29T17:01:14Z 2017-09-21T17:14:53Z "I really like the new 3D animation feature in OMEdit. I would like to suggest that a feature be added to export the animation as a movie, or at least as images. At the moment it just opens the animation window, but there is no way that I see to save or share the animation with another person (except of course by sharing the model and having the other person install OM). Once a model has been run, the animation can be a great way to share the results." Adam Dershowitz 4321 OMEdit: Star behind filename in tabview is still visible although user did undo all steps OMEdit Future enhancement Adeel Asghar new 2017-03-15T19:58:12Z 2017-08-17T08:03:11Z "If one does some changes in a file and then does ALL changes back using UNDO, the star behind the filename is still displayed. This could make users a bit suspicious that really everything was un-done. So I recommend to remove that star in that case." Jan Kokert 4655 Derive Algorithms blocks with discrete and continuous variables Backend Future enhancement Volker Waurich new 2017-12-04T13:25:24Z 2017-12-04T13:25:24Z The issue from [ticket:3993] was solved with an MSL change and an omc fix. It's stil not supported completely to derive algorithms during index reduction that involve multiple statements with discrete and continuous variables. Volker Waurich 4946 Flipping shapes in icon view OMEdit Future enhancement Adeel Asghar new 2018-05-18T15:22:03Z 2018-05-18T15:22:03Z "Models images can be rotated and flipped in OMEdit's diagram view. However shapes can currently be rotated but not flipped in icon view. In case this needs a small programming effort, it would be nice to have a flip feature also in icon view (useful for lines and polygons)" massimo ceraolo 5180 OMSimulator and stand-alone simulation should be able to save results as HDF5 files *unknown* v1.13.0-dev-nightly Future enhancement somebody new 2018-10-22T20:15:27Z 2019-02-28T21:01:12Z OMSimulator and stand-alone simulation should be able to save results as HDF5 files. Torsten Knodt <tknodt@…> 5504 Make the startup box moveable OMEdit v1.9.3 Future enhancement John Tinnerholm new 2019-05-24T12:44:44Z 2019-05-27T05:49:00Z "Desc: (Update, 2019-05-27) Possible to move the window around on Linux using alt click. It is not possible to move around the startup window on windows using click and drag DOD: It should be possible to move around the OMEdit startup screen " John Tinnerholm 5825 [OMEDIT] Export to specific location OMEdit Future enhancement Adeel Asghar new 2020-02-04T08:40:15Z 2020-02-05T17:56:22Z "Just a quality of life improvement. I would suggest to add an aditional option for exporting FMUs, XMLs or Figaros to a specific location and not the default working directory. Something like Export->FMU to .. in the right-click menue on a model." Andreas Heuermann 5905 Clean up large copy pasted code parts in OMEdit OMEdit Future enhancement Adeel Asghar new 2020-04-05T15:22:04Z 2020-07-05T08:56:51Z "While adding a Call Function context menu entry back in 2018, I have spotted large amounts of copy-pasted code inside the OMEdit C++ codebase. While copy-pasted code does not introduce any bugs on its own, such refactoring could improve code maintainability a bit. Unfortunately, I have not managed to investigate it better since then. Creating a separate issue, because the [https://github.com/OpenModelica/OMEdit/pull/172 original pull request] was closed long ago. For example, at the time of writing, both `HTMLEditor.cpp` and `OMSimulatorEditor.cpp` files have 50-line `highlightMultiLine` functions. Such cases can be found by using Copy-Paste Detector component from [https://pmd.github.io/ PMD]. Meanwhile, it has Modelica support since 6.21.0 version. You could see the [https://github.com/OpenModelica/OMEdit/pull/172 original discussion] for more details, as well." Anatoly Trosinenko 6044 Formatted equation editor when editing models OMEdit Future enhancement Adeel Asghar new 2020-07-02T16:32:33Z 2020-07-03T10:58:45Z "Looking at equations with a monospace font on a single line is not that intuitive. Mathquill (https://github.com/mathquill/mathquill) provides an intuitive interface for inputting equations and is currently used in Desmos (https://desmos.com/calculator). Would it be possible to integrate this into or something similar into OMEdit for editing the equations of a model?" Johan Winther <johan.winther@…> 1747 Implement checks for all connection rules in chapter 9 New Instantiation Future task Per Östlund new 2012-05-22T11:18:23Z 2016-02-05T09:58:52Z We currently only check some of the rules for connections that are listed in chapter 9 in the specification, and some of the checks are not complete. Most of the rules are very hard to implement in the current design of the instantiation though, so the new instantiation should be designed to make it easier to check these rules. This task is to implement checks for all these rules in section 9.1, 9.2, and 9.3 of the specification. Per Östlund 6273 linearization enhancement Cpp Run-time v1.17.0-dev NeedsInput enhancement Rüdiger Franke new 2020-12-04T18:20:03Z 2020-12-04T18:20:03Z with reference to forum [https://www.openmodelica.org/forum/default-topic/3136-discussion-on-linearization] attached a proposal to provide linearization results (ABCD,x0) in MAT4 format which can be used for post-processing. anonymous