Federico
You can check the global variable Carpet::timelevel (also available via the aliased function GetTimeLevel), and do nothing unless it is zero. The time overhead of this is negligible.
-erik
On Fri, Jun 9, 2017 at 3:42 AM, Federico Guercilena < guercilena@th.physik.uni-frankfurt.de> wrote:
Hi Erik,
I understand the reasoning behind looping over the timelevels in POSTREGRID, I didn't really expect to be able to disable it.
My viscosity is not evolved (e.g. via MoL), but depends on the time derivative of the entropy, which I estimate using past timelevels (as a one sided, second order FD stencil, so just a linear combination of the values of the entropy at different timelevels at each grid point). After regridding the hydro variables have been interpolated/synchronized as you say, the entropy is recomputed (pointwise, no stencils involved) so that it is consistent, and the viscosity has to be recomputed as well (attempts to leave it to whatever the regridding operation did (i.e. not schedule the routine at postregrid) resulted in crashes). I also cannot schedule it later, since after timelvels are rotated I wouldn't have enough of them to computed the time derivative (unless I reduce the stencil to 1st order, but I'd rather not). As I said, I have a workaround for this, it's just that it's somewhat inelegant.
Thanks, Federico
Il giorno gio 8 giu 2017 alle ore 14:50 Erik Schnetter < schnetter@cct.lsu.edu> ha scritto:
Federico
The postregrid bin is run after regridding. All grid points on the new grid must be defined in some way -- either via interpolation (space and/or time) and boundary synchronization/prolongation, or they must be recalculated from other data. Typically, evolved quantities such as density and momentum are interpolated, and other quantities such as the pressure are defined based on the evolved quantities. This needs to happen on all time levels, hence this loop. This loop cannot be disabled, as it would leave past time levels undefined, which would lead to problems during the next boundary prolongation, as this might access past time levels for time interpolation.
Is your viscosity evolved, or can it be calculated from other quantities? How should its values be defined after regridding? This should probably be the same procedure as for setting up initial conditions.
-erik
On Thu, Jun 8, 2017 at 8:07 AM, Federico Guercilena < guercilena@th.physik.uni-frankfurt.de> wrote:
Hello,
I have a viscosity grid function I want to evaluate (among other places) at CCTK_POSTREGRID, so that it's consistent and ready for use at CCTK_EVOL. Problem is, the viscosity depends on the past timelevels of another grid function (the entropy). It seems Carpet loops on the timelevels in CCTK_POSTREGRID, which means that when the loop is on the "current" timelevel everything works fine, but when the loop moves onto some past timelevel, the other timelevels, the ones further in the past so to speak, are undefined. In particular the code segfaults when trying to access something like entropy_p_p[ijk], since entropy_p_p does not point to a valid memory address.
I was able to fix this simply by checking if the pointers to past timelevels are valid, and breaking out of the function otherwise. This does the trick, but I was wondering if there's a more elegant, Cactus/Carpet native solution. My fix could maybe also slightly impact performance.
Is there a way to disable the loop on timelevels in CCTK_POSTREGRID (but only for a given scheduled routine)? Or to schedule something after POSTREGRID, but before timelevels are rotated? As far as I know neither is possible, but hopefully I'm disregarding something.
Thanks, Federico Guercilena
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/