[Users] Loop on timelevels in POSTREGRID
guercilena at th.physik.uni-frankfurt.de
Tue Jun 13 13:29:59 CDT 2017
Thanks Erik, I hadn't thought of that. I'll change my code.
Il giorno ven 9 giu 2017 alle ore 16:19 Erik Schnetter <
schnetter at cct.lsu.edu> ha scritto:
> 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