-
Notifications
You must be signed in to change notification settings - Fork 112
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
Inconsistency in boundary conditions for nonconservative terms #2175
Comments
@ranocha I think this is related to issues that Marco discussed at the last Trixi meeting. |
As a starting idea, it would be handy if the boundary condition routine(s) could use a different |
As discussed in the last meeting, we should consider passing |
Unfortunately I couldn't join the Trixi Meeting yesterday. My suggestion and my understanding would have been that I could theoretically use an anti-symmetric volume flux for the non-conservative part, that is consistent with 0, so that no boundary conditions needs to be defined for the non-conservative flux. As far as I know, every non-conservative formulation in Flux Differencing form can be written as a product of a symmetric flux times a jump (i.e. anti-symmetric flux) (at the moment I don't know of any non-conservative flux that doesn't boil down to this form. This is basically, an equivalent form to the one presented here, https://arxiv.org/pdf/2211.14009, where a non-conservative flux can be written as a product of a symmetric times a local term). The anti-symmetric "formulation" would be also consistent with the point-wise source term, where no boundary conditions are imposed. However, that would require to modify all the existing non-conservative fluxes and might not be the best idea at the moment. Anyway, I can definitely work on the suggestion presented and pass the tuple directly to the boundary condition call and return the correct value |
That would be great! Feel free to ping me for a review whenever you have a PR ready. |
Even with anti-symmetric non-conservative terms, these don't need to be consistent with zero at the boundary, since |
You are definitely right! I didn't consider that option, it would not allow for such flexibility. |
When computing the boundary conditions for systems with nonconservative terms there is a potential to accidentally add the boundary contribution incorrectly on
P4estMesh
(https://github.com/trixi-framework/Trixi.jl/blob/main/src/solvers/dgsem_p4est/dg_2d.jl#L365-L371 ) orUnstructuredMesh2D
(https://github.com/trixi-framework/Trixi.jl/blob/main/src/solvers/dgsem_unstructured/dg_2d.jl#L443-L449).If one does not use the
surface_flux_function
ornonconservative_flux
to compute the boundary condition, e.g. as we do for something like the Euler slip walls (https://github.com/trixi-framework/Trixi.jl/blob/main/src/equations/compressible_euler_2d.jl#L299-L337), then the boundary condition will incorrectly be added as something likebecause
flux
andnoncons
will be identical and we actually get the boundary flux one and a half times.It would be better from my perspective if we did not assume / require that the boundary condition is set via a numerical flux for the sake of flexibility.
The text was updated successfully, but these errors were encountered: