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

Physical Boundary Conditions - Fortran #2

Closed
pbrady opened this issue May 1, 2017 · 11 comments
Closed

Physical Boundary Conditions - Fortran #2

pbrady opened this issue May 1, 2017 · 11 comments

Comments

@pbrady
Copy link

pbrady commented May 1, 2017

I cannot find any example fortran code that uses the amrex_physbc fortran interface to supply boundary conditions. The current examples in Tuturials/*_CF use periodic bcs. I did notice that in some of the _C tutorials, an f77 file was present which provided a filcc routine. To impose boundary conditions, should I customize the filcc routines or is there a better way utilizing amrex_physbc?

@drummerdoc
Copy link
Member

filcc is an app-generic routine to handle reflections, extrapolations, etc, i.e., grow cells that don't require user intervention to fill. Typically, one calls filcc first to fill grow cells on such boundaries, and then follows in the bc routine with loops over each face of the box to be filled, checking for Dirichlet conditions that weren't handled by filcc (i.e., bc(dir,lohi,comp) == EXT_DIR, where dir=1,2,3 and lohi=1,2) and if the box to be filled sticks out past the boundary on that face. If such cases are found, the user-supplied code will need to set the Dirichlet values explicitly. Note that the values set in these grow cells will be enforced on the boundary FACE. We should add such an example to the tutorials.

@WeiqunZhang
Copy link
Member

I will update amrex/Tutorials/AMR_Adv_CF/Source/fillpatch_mod.F90's subroutine fill_physbc to show an example of setting physical boundary conditions.

@zingale
Copy link
Member

zingale commented May 1, 2017

@pbrady
Copy link
Author

pbrady commented May 1, 2017

Thanks for the example. What's the use case of the amrex_physbc_* routines in AMRex_physbc_mod.F90?

@WeiqunZhang
Copy link
Member

The Castro example was built with C++. As I understand, you are trying to use the Fortran interfaces Src/F_Interfaces.

@WeiqunZhang
Copy link
Member

Please check out the latest development branch. Tutorials/AMR_Adv_CF/Exec/SingleVortex has been modified to use a simple extrapolation for physical boundaries (https://github.com/AMReX-Codes/amrex/tree/development/Tutorials/AMR_Adv_CF). In inputs.physbc, we have geometry.is_periodic = 0 0 0 to set the boundaries to non-periodic. In https://github.com/AMReX-Codes/amrex/blob/development/Tutorials/AMR_Adv_CF/Source/my_amr_mod.F90#L74, we set the non-periodic bc to first-order extrapolation. The fillpatch module (https://github.com/AMReX-Codes/amrex/blob/development/Tutorials/AMR_Adv_CF/Source/fillpatch_mod.F90#L62) is modified accordingly.

If there are any problems, let us know.

@pbrady
Copy link
Author

pbrady commented May 2, 2017

Thanks for the updated example. It's very helpful.

So, if my problem specific boundary conditions are not handled by amrex_fillcc I would modify the fill_physbc subroutine to appropriately account for this (i.e. time dependent dirichlet bc). In that case, I wouldn't need to change to the fillpatch/fillcoarsepatch wrappers in the AMR_Adv_CF example, just the fill_physbc subroutine which is passed to the amrex_fillpatch routines.

However, If my boundaries warranted a unique discretization stencil, then I would have to take this explicitly into account in whatever problem specific "advance" routine I write. And based on @drummerdoc's comments, a custom discretization may be required depending on if the boundary conditions are interpreted as face of cell data.

Does this sound right?

@drummerdoc
Copy link
Member

Yes, that is correct. The linear solvers, for example, do this explicitly with polynomial extrapolation/interpolation.

@WeiqunZhang
Copy link
Member

First, I forgot to commit a new file. So you need to pull the latest version.

What Marc (@drummerdoc) said about face is true in some cases where filcc is used. It is however not always true. For example, in the hyperbolic solver of Castro, the ghost cells values are always treated as cell centered, not on faces. So it depends on how the application code views it.

@pbrady
Copy link
Author

pbrady commented May 2, 2017

I pulled the latest version and everything seems clear. This issue can be closed unless you think it would be better left open for a while as guide

@WeiqunZhang
Copy link
Member

The tutorial mentioned above has been moved to https://github.com/AMReX-Codes/amrex/tree/master/Tutorials/Amr/Advection_F/

bcfriesen pushed a commit that referenced this issue Nov 6, 2019
Fix compile errors due to AMReX renaming stuff.
mic84 added a commit to mic84/amrex that referenced this issue Sep 16, 2020
mic84 added a commit that referenced this issue Oct 13, 2020
* CMake: first basic attempt at HIP support

* Update Tools/CMake/AMReXParallelBackends.cmake

Co-authored-by: Axel Huebl <axel.huebl@plasma.ninja>

* CI: Add HIP-Clang

* fix typo: GCC 9.3 on focal

* Fix sources: set two lists

* fix target properties: append two lists

* CMake: some changes to debug issue with generated files

* CI: only run HIP check for now

* CMake: fix typo

* CMake: let's try this

* CMake: other small modifications

* CMake: attemp #1

* CMake: attemp #2

* CI: build just the bare minimum for now

* CMake: attempt #3

* CMake: missing defines for HIP builds

* CMake: defines were still missing :-P

* CMake: AMREX_HIP_PLATFORM is actually the HIP_COMPILER

* CMake: let's see if this works

* Install rocRAND

* CMake: re-factor and update defines for HIP compilation

* CMake: list against hiprand too

* CMake: find and link to hiprand

* CMake: add -DNDEBUG to any type of build when HIP is on

* CMake: we must manually add rocrand too

* CMake: let's see if it works with Fortran enabled

* Revert "CMake: let's see if it works with Fortran enabled"

This reverts commit 0650715.

* CMake: try this

* CMake: this should work too

* Revert "Revert "CMake: let's see if it works with Fortran enabled""

This reverts commit 6a92adc.

* CMake: no fortran for now

* CI: turn on linear solvers in HIP check

* CI: turn on particles in HIP checks

* Revert "CI: turn on linear solvers in HIP check"

This reverts commit c723560.
The reason is that Linear Solvers tutorials are not HIP-aware yet.

* CMake: hipify tutorials

* CMake: temporary fix

* Revert "CMake: temporary fix"

This reverts commit bd6724e.

* CMake: fix HIP compilation for Tutorials

* CMake: some cleanup

* CMake: add HIP options to pass in architecture and extra flags

* CMake: oops

* CMake: try to enable linear solvers

* CMake: update ROCm version number in CI check name

* CMake: enable Fortran

* CMake: disable tutorials for the time being

* CMake: commit custom FindHIP.cmake to debug the issue

* CMake: trying this

* CMake: now it should use the local FindHIP.cmake

* CMake: now custom FindHIP.cmake should be able to find helper files

* CMake: let's see if we really need this

* CMake: let's try this

* CMake: temporary fix

* Revert "CMake: disable tutorials for the time being"

This reverts commit 885b911.

* CMake: Tutorials/Particles/CellSortedParticles do not work with HIP

* CMake: remove local FindHIP.cmake.

* CMake: HIP arch flags are now PUBLIC and inheritable

* CMake: no use for setup_target_for_hip_compilation anymore

* CMake: remove unnecessary options for HIP

* CMake: check that HIP_COMPILER is the same as CMAKE_CXX_COMPILER

* CMake: better this

* CI: uncomment all checks

* CMake: fix visibility of arch flags for HIP

* Doc: add subsection on HIP+CMake

* Update Docs/sphinx_documentation/source/GPU.rst

Co-authored-by: Shreyas Ananthan <shreyas@umd.edu>

* CMake: fix incorrect configuration option passed to cmake

* CI: target 'tutorials' no longer exists

Co-authored-by: Axel Huebl <axel.huebl@plasma.ninja>
Co-authored-by: Shreyas Ananthan <shreyas@umd.edu>
kngott added a commit to kngott/amrex that referenced this issue Jun 8, 2021
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

No branches or pull requests

4 participants