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

Fix Field3D::setBoundaryTo for FCI methods #3030

Open
wants to merge 6 commits into
base: fci-auto-with-debug
Choose a base branch
from

Conversation

bendudson
Copy link
Contributor

Without this fix, boundary conditions set on yup/down fields are not applied when a boundary is copied from one field to another.

@dschwoerer This is needed in Hermes-3 with FCI so that this line correctly applies the sheath boundary conditions to the density field:
https://github.com/bendudson/hermes-3/blob/master/src/evolve_density.cxx#L217

Without this fix, boundary conditions set on yup/down fields are not
applied when a boundary is copied from one field to another.
// Interpolate midpoint value in f3d
const BoutReal val = pnt.interpolate_sheath_o1(f3d);
// Set the same boundary value in this field
pnt.dirichlet_o2(*this, val);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should either take o2 twice, or o1 twice:

Suggested change
pnt.dirichlet_o2(*this, val);
pnt.dirichlet_o1(*this, val);

I think o1 should be sufficient, as f3d and *this should be close. But I am not sure what is more stable ...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The FA code also uses first order, so I have pushed a fixed based on that ...

pnt.dirichlet_o2(*this, val);
}
}
return;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For hermes that might work, but should we not also copy the x-boundary conditions with FCI?

Suggested change
return;

@dschwoerer
Copy link
Contributor

@bendudson Are you ok with these changes?

@dschwoerer
Copy link
Contributor

I just noticed #2962 is also open - is the other still needed with this one?

Copy link
Contributor Author

@bendudson bendudson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @dschwoerer ! The changes look good to me.
I think #2962 is not needed once this is merged.

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.

2 participants