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 < [email protected]> 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 < > [email protected]> 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 < >> [email protected]> 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 >>> [email protected] >>> http://lists.einsteintoolkit.org/mailman/listinfo/users >>> >>> >> >> >> -- >> Erik Schnetter <[email protected]> >> http://www.perimeterinstitute.ca/personal/eschnetter/ >> >> -- Erik Schnetter <[email protected]> http://www.perimeterinstitute.ca/personal/eschnetter/
_______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
