MoL Multirate capabilities. This add three new multirate RK schemes to MoL.

Issue #839 closed
Christian Reisswig created an issue

In order to make multirate work, we need to introduce new registration routines that explicitly register variables with the "slow" sector, i.e. those variables which are integrated by the lower order scheme. This also means that we require new "accumulator" parameters indicating how many "slow" variables we want to register.

Flags indicate whether it is time to execute slow RHS computation. For instance, in the RK4-RK2 scheme, there are 4 substeps in total, but the RK2 RHS are only evaluated in the very first and in the very last step of the four substeps.

Keyword: MoL
Keyword: Multirate

Comments (16)

  1. Erik Schnetter
    • removed comment

    This patch breaks two test cases:

    GRHydro_test_tov_ppm_ML_disable_internal_excision (from GRHydro) GRHydro_test_tov_ppm_no_trp_ML (from GRHydro)

  2. Roland Haas
    • removed comment

    Erik: both tests pass for me on my workstation (Debian Squeeze/Wheezy, simfactory config filedebian-lenny-gcc.cfg, gcc 4.6, OpenMPI, optimized build, both 2 threads and 4 cores and 2 threasd 2 cores).

    Can you provide more details on the machine where it fails, please?

  3. Roland Haas
    • removed comment

    Very strange. It torks for me on bethe as well (default simfactory bethe config) with 1 and 2 MPI processes and 4 cores. I committed them into release-info and they can be seen at bethe:/home/rhaas/simulations.

    Christian promises a test case using GRHydro.

  4. Roland Haas
    • removed comment

    Progress of a sort. I can get GRHydro_test_tov_ppm_no_trp_ML test to fail with 6 threads (but not GRHydro_test_tov_ppm_ML_disable_internal_excision). However now it is also failing with 2 threads and also without the MoL patch. Doing a fresh recompile now...

  5. Christian Reisswig reporter
    • removed comment

    No, not yet. Still need track down the problem above. I will also prepare a test case.

  6. Roland Haas
    • removed comment

    I attach an updated patch that adds support for the ChangeType like function calls and allows querying of the RHS variable of slow evolved quantities. It corrects some comments as well.

    The actual patch is in revised.patch (please ignore revised.2.patch). and differences.diff is a diff between original.patch and revised.patch to illustrate what was changed.

    I just tried and the patch passes all tests on bethe with 6 threads and 2 processes (current simfactory options). I thins that the failing test was affected by an OpenMP race condition that was fixed in rev 364 caused by an implicit Fortran SAVE attribute in Con2PrimPolytype_pt (which was used by the test the Erik found to fail since it uses GRHydro::GRHydro_eos_type = "Polytype").

    Ok to apply (a test for this is in GRHydro/Zelmani and will be pushed with the next batch of GRhydro updates)?

  7. Log in to comment