WIP: Stop running unnecessary UtoP at boundaries #128
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I think that when using the
kharma
driver, and thus syncing conserved variables, two boundary-related bugs were stacking and cancelling in terms of effects, but slowing down the code:Packages
code didn't select out theInverter
package from being run, only theGRMHD
package (where variable inversion used to live).IndexDomain
it was called with, instead always using the domain of physical zones (i.e. not domain boundary ghost zones).So, (1) was causing up to several times too many calls to
UtoP
, but (2) meant that each call just did exactly the same thing as the original call before treating the boundary conditions, and recovered primitive vars in the physical zones all over again (but with a perfect guess, so at least it was quick?).afaict, the boundaries were thus treated correctly:
PtoU
from theGRMHD
package (technically,PtoUMHD
from theFlux
package because KHARMA always makes perfect sense) was being called over each boundary.UtoP
from theInverter
package was also called accidentally, but should have been effectively a no-op because it basically repeated a previous call. So, the boundary had primitive variables mirrored/repeated/etc, and conserved variables that reflected callingPtoU
on those, as we'd expect.I'll note again this was only with the
kharma
driver, when normally the conserved variables are synchronized, so the boundaries have to be treated specially. In theimex
driver where all boundaries internal and external use primitive (fluid) variables, things are simpler.