Alternative solutions to infinities problem other than smaller step size or -neuron

[JustasB]

I have a LEMS simulation file that:

1. Produces a file output
2. Runs in jnml, but not with the -neuron flag
3. At larger simulation time steps results in Problem while trying to return a value for variable fcond: Infinity errors
4. At smaller time steps, results in java.lang.OutOfMemoryError: Java heap space, or multi-gigabyte output files, or very long simulation times.
5. I have a lot of such files and cannot automate individual tweaking of the LEMS files

It seems that the problem is that in a few small portions of the simulation window, the derivatives/eval results are outside machine-representable range.

What would be the simplest modification to the jnml euler method to handle infinities better?

[pgleeson]

Unfortunately modifying the numerical integration of jLEMS would require a deep dive into the code...
I've found this problem in the past, especially with models that have rapidly changing currents (e.g. voltage clamps), and I usually decrease the dt until it works.

If you need to increase the memory you can change the environment variable JNML_MAX_MEMORY and that will give java more mem when it's run (try half your total RAM).

There should be an option to save fewer points (than one each time step), but this is more likely to happen soonish in the Neuron export.

[JustasB]

I could take a look at the n. integration code. Has there been any discussion on the best/simplest solution to this problem?

The other issue is that if we modify the ni code, it could affect values for all other sims, triggering failed tests, etc...

I can think of the following simple scheme, which would not affect currently-non-crashing simulations, but would probably result in differences with other simulators, depending on how they handle this problem:

Conditional local-subsampling via halving of the time step:

1. At each time step, check for non-machine-representable variable values (e.g. +/- infinity, div by 0, etc...)
2. If detected, then temporarily halve the time step and compute twice the number of newly-shortened time steps ahead, storing only the value of the last sub-step
3. If still non-representable, halve the time step again and repeat step 2, until either the non-modified time step value is obtained or some minimum step value is reached.
4. If minimum time step value is reached, then crash the program, the problem is that the value is not-representable
5. If machine-representable non-modified time step value is obtained via the time step halving, then keep the value and restore the original time step and attempt to compute the next step, performing a similar method if further non-representable values are encountered