[Users] Loop on timelevels in POSTREGRID

[Erik Schnetter]

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 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.
>
> Thanks,
> Federico
>
> Il giorno gio 8 giu 2017 alle ore 14:50 Erik Schnetter <
> schnetter at 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 at 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 at einsteintoolkit.org
>>> http://lists.einsteintoolkit.org/mailman/listinfo/users
>>>
>>>
>>
>>
>> --
>> Erik Schnetter <schnetter at cct.lsu.edu>
>> http://www.perimeterinstitute.ca/personal/eschnetter/
>>
>>


-- 
Erik Schnetter <schnetter at cct.lsu.edu>
http://www.perimeterinstitute.ca/personal/eschnetter/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20170609/753bad78/attachment.html