Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump Parthenon & Fix SMR #39

Merged
merged 40 commits into from
Dec 4, 2023
Merged

Bump Parthenon & Fix SMR #39

merged 40 commits into from
Dec 4, 2023

Conversation

bprather
Copy link
Contributor

@bprather bprather commented Oct 19, 2023

This branch bumps the Parthenon version and pulls some branches, to test some AMR changes and provide the basis for recording face-centered fields.

It also fixes a nasty artifact previously present at some boundaries in torus/spherical-coordinate runs. This doesn't appear to be the only issue keeping divB==0 in SMR runs, but it at least clears up the obvious/quick issues (and points the way to solving the other, which also only appears in spherical runs).

Finally, this has been the landing spot to clear up compile/run issues in various places and address the bugs with kharma-next generally, so it fixes a handful of such things.

This will be pulled once it passes the tests in an hour or two.

Ben Prather and others added 30 commits October 19, 2023 12:20
Parthenon's conventions for prolongation operators call over a different
domain based on the values which determine the prolonged value.
In our case despite working from faces, we are preserving divB in cells,
so should be called over the same domain as the default prolongation
operator, not over a domain tied to the particular face we're working on

This was truly awful to chase down, but at least it's preventable going
forward -- documentation of the operator interface will start to solve
these sorts of issues.
B field initialization comments & one fix
Mark some device functions as forceinline
Remove old comments
Add new personal machine compile parameters
Try to avoid per-block segments in the ImEx driver.
This should make KHARMA faster & more flexible in future
Currently still slow since several "mesh" things are loops, but soon^TM
1. Zero EMFs on boundaries in boundaries.cpp.
   Supercedes B and EMF fixes in b_ct.cpp
2. Remove check_inflow_flux_X because they were confusing,
   and should always match check_inflow_X
@bprather bprather mentioned this pull request Nov 28, 2023
@bprather bprather changed the base branch from kharma-next to dev December 4, 2023 20:02
@bprather bprather merged commit f6d04de into dev Dec 4, 2023
1 of 2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant