[Users] Loop on timelevels in POSTREGRID
schnetter at cct.lsu.edu
Fri Jun 9 09:19:41 CDT 2017
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.
On Fri, Jun 9, 2017 at 3:42 AM, Federico Guercilena <
guercilena at 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.
> Il giorno gio 8 giu 2017 alle ore 14:50 Erik Schnetter <
> schnetter at cct.lsu.edu> ha scritto:
>> 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
>> 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.
>> On Thu, Jun 8, 2017 at 8:07 AM, Federico Guercilena <
>> guercilena at th.physik.uni-frankfurt.de> wrote:
>>> 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.
>>> Federico Guercilena
>>> Users mailing list
>>> Users at einsteintoolkit.org
>> Erik Schnetter <schnetter at cct.lsu.edu>
Erik Schnetter <schnetter at cct.lsu.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users