[Users] Can't evolve Minkowski with RK4 integrator?

[Heeil Kim]

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 at 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 at 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 at einsteintoolkit.org
>> http://lists.einsteintoolkit.org/mailman/listinfo/users
>
>
>
> --
> Erik Schnetter <schnetter at cct.lsu.edu>
> http://www.perimeterinstitute.ca/personal/eschnetter/
> _______________________________________________
> Users mailing list
> Users at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users