Hi,
The problems in my binary NS merge simulations seem to be related to this (fast) RK4 integration. I didn't make runs for sufficiently long time but the run with RK3 didn't crash yet.
But the generic RK4 doesn't seem to fix my problems. For this, I took the following parameter setup.
####### MoL #####################
mol::ode_method = "generic" mol::generic_type = "rk" mol::mol_intermediate_steps = 4 methodoflines::mol_num_scratch_levels = 3
Did I make right setup, or do I need more elaborations?
Cheers,
Hee Il
2012/3/1 Erik Schnetter schnetter@cct.lsu.edu:
Guys
Thanks for all the pointers!
I'm not using the device branch (vanilla checkout of ET development branch), and I'm not adding any noise. I really only evolve Minkowski, all variables are initially zero except for lapse and metric diagonals, which are one.
The RHS are not identically zero -- the RHS of the curvature and its trace are about 10^-30. (Should it be exactly zero?)
In unigrid, I see a secular drift; e.g. the lapse grows by 10^-15 every few time steps. Otherwise, things remain fine. With mesh refinement, the RHS soon becomes 10^-12 near refinement boundaries, and this triggers real badness.
MoL's generic RK4 integrator works fine for me, only the space-efficient RK4 integrator leads to problems.
-erik
On Wed, Feb 29, 2012 at 9:36 AM, Ian Hawke I.Hawke@soton.ac.uk wrote:
It's true that it should reproduce it at the continuum, but the use of the sum_alpha term may leading to differences at floating point round-off (as alpha is, for most substeps, not perfectly representable by floating point [alpha=1/3 in many cases], and sum_alpha is used in the form ...(1 - sum_alpha)). The effect that Erik describes may be accumulated floating point error. I'd expect this to manifest itself as a bulk secular drift (in the unigrid case); with MR the boundaries get involved (as the drift occurs depends on timesteps taken on the current level).
If the error is oscillatory in space even in unigrid then this can't be the problem, I don't think.
Ian
On 29/02/12 03:16, Yosef Zlochower wrote:
MoL RK4 should reproduce generic RK4. The only difference should be that MoL RK4 is more efficient with memory.
On 02/28/2012 08:48 PM, Erik Schnetter wrote:
I've just encountered a strange problem: I can't evolve Minkowski with MoL's RK4 integrator. Small errors in K grow from floating-point round-off, and the simulation quickly goes bad. The error grows slowly (but measurably) in unigrid, but much faster with mesh refinement.
For example, with unigrid the lapse grows by about 10^-15 every ten time steps or so; with mesh refinement, the simulation dies after a few ten time steps.
However, things are fine with other time integrators, in particular with the generic RK1 and RK4 integrators.
I've looked at other things as well, e.g. the CFL factor, the McLachlan implementation, the gauge parameters, dissipation, but could not find anything else that made a difference.
Is there something bad about the RK4 integrator? Is it intrinsically unstable, more so than other RK schemes? Or did it break in some of the recent changes?
-erik
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/ _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users