Modify

Opened 6 years ago

Last modified 5 years ago

#1066 reopened enhancement

Implement IMEX integrators in MoL

Reported by: Erik Schnetter Owned by:
Priority: major Milestone:
Component: EinsteinToolkit thorn Version:
Keywords: Cc:

Description

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.

Attachments (5)

MoL-IMEX.diff (93.0 KB) - added by Erik Schnetter 6 years ago.
MoL-IMEX.tgz (136.4 KB) - added by Erik Schnetter 6 years ago.
MoL-IMEX.diff.2 (47.0 KB) - added by Roland Haas 5 years ago.
MoL-IMEX.diff.3 (46.0 KB) - added by Roland Haas 5 years ago.
IMEX.patch (49.6 KB) - added by reisswig@… 5 years ago.

Download all attachments as: .zip

Change History (12)

Changed 6 years ago by Erik Schnetter

Attachment: MoL-IMEX.diff added

Changed 6 years ago by Erik Schnetter

Attachment: MoL-IMEX.tgz added

comment:1 Changed 6 years ago by Ian Hinder

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.

comment:2 Changed 6 years ago by Ian Hinder

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.

comment:3 Changed 5 years ago by Roland Haas

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.

Changed 5 years ago by Roland Haas

Attachment: MoL-IMEX.diff.2 added

Changed 5 years ago by Roland Haas

Attachment: MoL-IMEX.diff.3 added

comment:4 Changed 5 years ago by Roland Haas

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

comment:5 Changed 5 years ago by reisswig@…

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.

Changed 5 years ago by reisswig@…

Attachment: IMEX.patch added

comment:6 Changed 5 years ago by Roland Haas

Status: newreview

comment:7 Changed 5 years ago by Roland Haas

Status: reviewreopened

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, ...)

Modify Ticket

Change Properties
Set your email in Preferences
Action
as reopened The ticket will remain with no owner.
Next status will be 'review'.
as The resolution will be set.
to The owner will be changed from (none) to the specified user.
The owner will be changed from (none) to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.