Strange magic number in timestepping routine

[nichollsh]

Feature description

I noticed that the time-steps in some of my PROTEUS simulations were surprisingly small, so the simulations were taking a long time to run. Turns out that the timestep_rel function has an arbitrary factor of 0.01 applied to it.

PROTEUS/src/proteus/interior/timestep.py

Line 233 in ee834f0

dtminimum += config.params.dt.minimum_rel * hf_row['Time'] * 0.01 # allow small steps

This should be removed because it's not necessary and confusing.

The time-stepping routine in PROTEUS generally needs an overhaul - something for a later PR. Maybe @egpbos has suggestions?

Preferred solution

Remove 0.01 magic number in timestep.py

Relevant people

@timlichtenberg

[egpbos]

Just discussed in the dev meeting. As I understand the issue (please correct): some events in simulations like outgassing require high temporal resolution, but in many other periods this is unnecessary and wastes a lot of CPU/wall clock time. It would be nice if this fixed number could somehow be replaced by a smarter, maybe adaptive timestepping scheme, perhaps something that first does longer timesteps, does some checks for certain events or evolutionary phases that require smaller timesteps and if they are found just goes back a step and redoes that time frame with smaller steps.

I would be happy to dig into this, but I'd have to know more about the physics-motivated constraints, e.g. perhaps there are conservation laws that must be taken into account (as with orbital dynamics, leap-frog etc). I guess in general every module (i.e. every type of physics) may have optimal timestepping schemes. But perhaps I'm overthinking it?

[nichollsh]

Thanks for noting this, @egpbos. I should be clear that PROTEUS already has a simple adaptive time-stepping scheme, but it's just not very 'clever'. We could get more performance out of it with some more thought/attention and a more robust treatment of certain transitionary points (e.g. when orbital migration starts).