id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
5208	IDA with dense numerical jacobian doesn't work well	Francesco Casella	Willi Braun	"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."	defect	accepted	high		Run-time				federico.terraneo@…