- changed status to open
- removed comment
MoL Multirate capabilities. This add three new multirate RK schemes to MoL.
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)
-
-
- removed comment
Do you have a test case for this?
-
- 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)
-
- 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?
-
- removed comment
I tested this on Bethe.
-
- 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.
-
- removed comment
I believe I used 2 processes and 6 threads.
-
- 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...
-
- changed milestone to ET_2012_05
- removed comment
-
- changed milestone to ET_2012_11
- removed comment
-
- removed comment
Has there been progress?
-
reporter - removed comment
No, not yet. Still need track down the problem above. I will also prepare a test case.
-
- 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)?
-
- changed status to open
- removed comment
I suggest to apply the patch.
-
- changed status to resolved
- removed comment
Applied as ref 175 of MoL.
-
- edited description
- changed status to closed
- Log in to comment