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/
_______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
