Modify

Opened 4 years ago

Last modified 2 years ago

#1656 reopened defect

CarpetInterp and MoL do not work properly together

Reported by: Ian Hinder Owned by: Erik Schnetter
Priority: minor Milestone:
Component: Carpet Version: development version
Keywords: Cc:

Description

I am trying to integrate interpolated quantities using MoL. I call the interpolator in MoL_CalcRHS, and want it to perform only a spatial interpolation of the current content of timelevel 0. This current content is what has been set by MoL; it is not the final value that will be at t_{n+1} or was at t_N, but is the intermediate value that should be used when computing the RHS at a given MoL substep. Since MoL does not set the Carpet time hierarchy values, CarpetInterp seems to get confused about how to do the interpolation. I need to tell CarpetInterp not to interpolate in time at all, but to use timelevel 0 only. Unfortunately, setting the interpolator option to use only one timelevel does not work. There is commented-out code to "use cctk_time to decide whether to interpolate", which essentially guarantees that no time interpolation will happen (since the interpolation is requested for cctk_time, and the current time is cctk_time, so they are always equal). Re-enabling this code allowed me to achieve 4th order convergence for integrated interpolated quantities, though I am not sure I understand everything that is going on in CarpetInterp. I have added a parameter which controls this, and with this parameter set to the default, nothing changes (i.e. it is not going to change anyone's results unless they set the parameter). I would like to commit this, so that collaborators can work off the same version. Since the patch is very small, I hope this will not add too much unneeded complexity. Is it OK to commit? Patch is attached.

Attachments (1)

0001-CarpetInterp-Add-a-parameter-to-use-cctk_time-instea.patch (1.9 KB) - added by Ian Hinder 4 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 4 years ago by Roland Haas

Ian: which mode are you calling the interpolator in? If you are in level or local mode it should never attempt to do time interpolation (it should also abort in that case if you ask for points not on the current level I think). Only if you are in global mode should it do so.

comment:2 Changed 4 years ago by Ian Hinder

I call the interpolator in level mode, set InterpNumTimelevels to 0, and "want_global_mode" to 1, so that the interpolator can access data from other levels.

comment:3 Changed 4 years ago by Ian Hinder

Priority: majorminor
Status: newconfirmed

This problem needs to be understood better; the patch is a temporary workaround which probably doesn't need to be applied right now.

comment:4 Changed 2 years ago by Ian Hinder

Status: confirmedreview

Would it be OK to commit this? It is indeed a workaround, but if there is no idea how to fix it properly, I would rather have it in the code. The commit does nothing if you don't use the parameter, so it should be safe. It is necessary to get 4th order convergence for interpolated quantities integrated with MoL (convergence is 1st order otherwise).

comment:5 Changed 2 years ago by Roland Haas

You are using want_global_mode but really only want data from a single reflevel. That seems very strange. Note that the different reflevels will not be at the same cctk_time (since RHS is done level by level) so accessing different reflevels should not be done since only the current reflevel will be at cctk_time (and the others at their level_times). Are you sure that this works fine (and that want_global_mode is needed?)?

I'd suggest making this parameter an option to the interpolator (like want_global_mode) rather than a global simulation parameter (you'd have to modify the extract_parameter_table_options function it seems).

comment:6 Changed 2 years ago by Ian Hinder

You are correct; this only works on the finest level. I tried many different things (2 years ago, so I don't recall the details), and this was the only thing that actually seemed to work, at least in unigrid or on the finest level with mesh refinement. Assuming that CarpetInterp has access to the interpolator option table, which it probably does, then yes, it should be there instead of a parameter.

comment:7 Changed 2 years ago by Ian Hinder

Status: reviewreopened

Modify Ticket

Change Properties
Set your email in Preferences
Action
as reopened The owner will remain Erik Schnetter.
Next status will be 'review'.
as The resolution will be set.
to The owner will be changed from Erik Schnetter to the specified user.
The owner will be changed from Erik Schnetter to anonymous.

Add Comment


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

 
Note: See TracTickets for help on using tickets.