{5} Accepted, Active Tickets by Owner (Full Description) (110 matches)

The following model does not compile with omc 1.9.0:

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

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.

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.

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.

In the xml logFormat of the c runtime is the root element missing, what may leads to parsing error while usage.