Thanks Erik, I hadn't thought of that. I'll change my code. Federico
Il giorno ven 9 giu 2017 alle ore 16:19 Erik Schnetter < [email protected]> ha scritto: > 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
