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
Hi Erik,
I believe Dana ran into similar problems a while back for some tests using CTGamma (not sure if that is related at all, as I don't remember the details anymore). But maybe this can be of help.
Philipp
On Feb 28, 2012, at 5: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
-- 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
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
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
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
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
Hee Il
Your setup for the generic RK4 integrator seems correct.
-erik
On Tue, Apr 3, 2012 at 6:04 AM, Heeil Kim heeilkim@gmail.com wrote:
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
On 29 Feb 2012, at 02:48, 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?
I don't think there is anything "bad" about RK4 itself. What gauge condition are you using to evolve Minkowski? If you are using lapse = 1 and shift = 0, I believe that the solution should be exact. 1 and 0 can both be represented exactly with floating point, all derivatives will be zero as the subtraction in the finite difference will be exact, and I think there are no other nonzero terms.
If RK4 is giving a different behaviour to generic RK4, I would look into where the differences are. Are you using the "device" branch of MoL? Have you tried the trunk? It might be that the linear combination function is not implemented correctly in the device branch.
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Heeil Kim -
Ian Hawke -
Ian Hinder -
Philipp Moesta -
Yosef Zlochower