Implement IMEX integrators in MoL

Create issue
Issue #1066 open
Erik Schnetter created an issue

Dana Alic contributed an implementation of IMEX integrators for MoL.

I attach the implementation as a patch (based on r133 of MoL). The implementation is well tested. The patch does not apply cleanly, and seems to make some modifications to the schedule etc. as well that have since been superseded by other changes to MoL.

Keyword:

Comments (7)

  1. Ian Hinder
    • removed comment

    I have created a new branch in the MoL repository called "imex" and committed this patch to it. The branch is based off r173, before the multirate changes, because there are nontrivial conflicts with multirate. The ET compiles if you exclude GRHydro (and its dependencies) from the thornlist, since GRHydro needs multirate. I have not run the code.

  2. Ian Hinder
    • removed comment

    There are some duplicated schedule items which were generated during the merge which were not detected at compile time, only run time. The duplicates should be removed.

  3. Roland Haas
    • removed comment

    The code in line 659 of the patch seems to be incorrect to me since it will always require a RHS2 for evolved grid arrays.

    There is also no test included that would allow us to check whether the merge succeeded.

    I attach an updated patch that applies against rev202 of MoL (ie after the multipatch changes).

    After this code has been merged in (or before if we find that the tests fail), we should rewrite the registration and changetype code. This is currently very messy with very much duplicated code and very long. Registration etc. should be possible with very few lines of code and a C++ map object, something like:

    enum MoLType {MoL_Type_Invalid = 0, MoL_Type_SafeAndrRestore. MoL_Type_Constrained, MoL_Type_Evolved, MoL_Type_EvolvedSlow, MoL_Type_EvolvedIMEX};
    map<int,int> RegisteredVariables;
    map<init,int> RHSIndex, RHS2Index;
    
    void MoLRegisterEvolved(groupIdx,rhsIdx) {
      RegisteredVariables[groupIdx] = MoL_Type_Evolved;
      RHSIndex[groupIdx] = rhsIdx;
    }
    
    void MoLChangeToConstrained(groupIdx) {
      RegisteredVariables[groupIdx] = MoL_Type_Constrained;
      if(RHSIndex.count(groupIdx)) RHSIndex.erase(groupIdx);
    }
    

    Rather than the 197 lines currently used.

  4. Roland Haas
    • removed comment

    updated diff to actually run. Fixed some compiler warnings. Re-instate evolution of complex variables (not for IMEX though).

  5. Christian Reisswig
    • removed comment

    I have applied MoL-IMEX.diff.3 and made some additional changes (mostly to make it more efficient). None of this will affect the original behavior of the patch. I tested the IMEX integrator with a small toy code and with the Einstein equations using a modified version of CTGamma. The attached patch works for me and also does not seem to break anything.

  6. Roland Haas
    • changed status to open
    • removed comment

    I had a look at the patch and have some comments (from important to nitpicking):

    • it uses steerable parameters RKevalRHSex, RKevalRHSim (lines 80 and 81) and RKstiff and RKtime to tell the client thorn which RHS to evalute. Instead it should use grid scalars.
    • implicit array variables seem broken

    • the error message in 169 and 235 seems wrong since "does not correspond to a GF" usually means varindex=-1 whereas here the error seems to be "has no storage"

    • no test case (so far)
    • no documentation

    • lines 534--537 mention an ODE_Method "RKIMEX" which does not exist and should be removed

    • commented out code in line 406
    • CCTK_GroupName in line 634 returns a string that needs to be free()'d (does not matter here since we abort anyway)
    • line 655 is leftover debug code
    • uses CCTK_VWarn(0, ...) instead of CCTK_VError
    • uses CCTK_VWarn(1, ...) instead of CCTK_VWarn(CCTK_WARN_ALERT, ...)
  7. Log in to comment