Use a uniform convention for boundary condition input parameters

[felker]

Following up on #492, specifically #492 (comment)

I understand that we want different BCs for different fields.... but the way BCs are being set in the input file is getting confusing.

why does mesh/ix1_bc correspond to hydro/field/fft_gravity physics BCs, mesh/ix1_rad_bc correspond to rad BCs, yet gravity/ix1_bc sets multigrid gravity boundaries.

In seems that every physics package should set its boundary conditions uniquely in the input file.

@pdmullen are you suggesting that we add even more BC flags, too? And change mesh/ix1_rad_bc to radiation/ix1_bc? FFT gravity boundary conditions are always periodic, right?

[yanfeij]

ix1_rad_bc is not used anymore. Radiation shares the same boundary flag as hydro. If we want to use different boundary for hydro and radiation, then just use user defined boundary flag

[pdmullen]

(1) To take a step back, it is clear that we definitely want the functionality of setting different BCs on different physics.

(2) As @yanfeij mentions, this can of course be handled via a user-defined boundary condition.

(3) Future extensions could consider enabling boundary condition specification for individual physics inside the input file (thereby eliminating the need to write a user-defined boundary condition for some problem configurations).

(4) Despite (1) -- (3), I would argue that it is still a bit confusing to set BCs for <mesh> and, for example, <grav> as in Athena++ main (see multigrid gravity BCs here). In the linked example, mesh BCs are set to periodic, and gravity BCs are set to multipole.

FFT gravity boundary conditions are always periodic, right?

Correct. However, one could imagine extensions to FFT gravity (i.e., James' algorithm) that enable open BCs. Would those then be set in <mesh> or <grav>? Should <mesh> BCs only every correspond to hydro & field & radiation?

My initial reaction to this was triggered by the existence of a mesh/ix1_rad_bc in PR #492... i.e., why are radiation BCs tunable inside <mesh> but not other physics? and why is it in <mesh> and not <radiation> (in analogy to gravity). However, @yanfeij informs us that this usage is deprecated...

[felker]

These are all great questions that deserve a longer discussion from more stakeholders. We can change things after merging #492 without breaking too much.

I agree we should at least decide on a consistent input file organization. I would lean to keeping mesh/ix1_bc be the fluid boundary condition, and any other BC-related input flags stuck in <grav>, <radiation>, <particles> ...

@yanfeij, just to be clear, ix1_rad_bc etc. are no longer anywhere in the pull request, right?

[yanfeij]

Yes, ix1_rad_bc etc. are not used anywhere.

…

On Sat, Jul 8, 2023 at 7:05 AM Kyle Gerard Felker ***@***.***> wrote: These are all great questions that deserve a longer discussion from more stakeholders. We can change things after merging #492 <#492> without breaking too much. I agree we should at least decide on a consistent input file organization. I would lean to keeping mesh/ix1_bc be the fluid boundary condition, and any other BC-related input flags stuck in <grav>, <radiation>, <particles> ... @yanfeij <https://github.com/yanfeij>, just to be clear, ix1_rad_bc etc. are no longer anywhere in the pull request, right? — Reply to this email directly, view it on GitHub <#534 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCWEJ55BOPB7FDCCS4MQCLXPCI3HANCNFSM6AAAAAA2BKX3DY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Best, Yan-Fei Jiang Associate Research Scientist, Flatiron Institute, 160 Fifth Avenue New York, NY 10010