Multi-Dim Buildsystem Support#3309
Conversation
a1efbb9 to
6667b20
Compare
3428f53 to
1567c82
Compare
1567c82 to
27b0bfb
Compare
@ax3l blinking... This makes a lot of sense -- probably will also help Jackie with some of the things she wants to do. |
does not work when |
seems to work |
|
Thanks for spotting this! I agree we can make this a regular option now, I added other fail-safes now for EB: |
Warns and skips if selected for 1D
dca7b20 to
15b937a
Compare
Likely untested interface changes that need to be updated in tests and covered in CI for 2D.
8780162 to
bafbf10
Compare
In this CI, we also run installation tests and the spack smoke test. This is a follow-up on AMReX-Codes#3309.
In this CI, we also run installation tests and the spack smoke test. This is a follow-up on #3309.
Fix two regressions from AMReX-Codes#3309 in the installed `AMReXConfig.cmake`: ``` CMake Error at /scratch/AMReX_RegTesting/amrex/builddir/lib/cmake/AMReX/AMReXConfig.cmake:257 (add_library): add_library cannot create ALIAS target "AMReX::amrex" because another target with the same name already exists. ``` and setting properties for newer CUDA.
| list(LENGTH AMReX_SPACEDIM list_len) | ||
| math(EXPR list_last "${list_len} - 1") | ||
| list(GET AMReX_SPACEDIM ${list_last} AMReX_SPACEDIM_LAST) | ||
| add_library(AMReX::amrex ALIAS AMReX::amrex_${AMReX_SPACEDIM_LAST}d) |
There was a problem hiding this comment.
This file seems to be allowed to be included multiple times (seen as a comment in the auto-generated AMReXTargets.cmake, which defines the actual ND targets). Thus, we need an include guard for add_library: #3324
| if (@CMAKE_VERSION@ VERSION_GREATER_EQUAL 3.20 AND @AMReX_CUDA@) | ||
| # CUDA architectures amrex was built for -- should we make | ||
| set(AMREX_CUDA_ARCHS @AMREX_CUDA_ARCHS@ CACHE INTERNAL "CUDA archs AMReX is built for") | ||
| set_target_properties(AMReX::amrex |
There was a problem hiding this comment.
Ooops, should use the non-alias targets. Fix in #3324
## Summary Fix two regressions from #3309 in the installed `AMReXConfig.cmake`: ``` CMake Error at lib/cmake/AMReX/AMReXConfig.cmake:257 (add_library): add_library cannot create ALIAS target "AMReX::amrex" because another target with the same name already exists. ``` and setting properties for newer CUDA. ## Additional background Regression to #3309, spotted by @drangara, @ajnonaka, wdf et al. ## Checklist The proposed changes: - [x] fix a bug or incorrect behavior in AMReX - [ ] add new capabilities to AMReX - [ ] changes answers in the test suite to more than roundoff level - [ ] are likely to significantly affect the results of downstream AMReX users - [ ] include documentation in the code and/or rst files, if appropriate
It was broken in AMReX-Codes#3309, in which multi-D support was added.
It was broken in #3309, in which multi-D support was added.
Summary
This updates the CMake build system to allow to build multiple AMReX libraries at once, by building multiple, uniquely-named
(lib)amrex_[1|2|3]d.[so|a|dll|lib]artifacts. Developers can request this by specifying a list of dims instead of a single one during configure time, e.g.,-DAMReX_SPACEDIM="1;2;3".Providing this functionality will significantly reduce deployment burdens for:
because all dimension-related variants can be shipped at once and do not produce multiple, conflicting packages anymore.
Apps can use the same mechanism to pick up the dimensional variants and build multiple artifacts. (This is something we already do, but cannot generalize to package mangers just yet.)
Backward Compatibility
To stay backwards compatible, the last (or traditionally, only) passed dimensionality will define a few legacy artifacts:
amrex::amrex/amrexCMake targetslibamrex.[so|a]/amrex.[dll|lib]artifact (symlink)AMReX_Config.Hfile: defaults to the last dim inAMReX_SPACEDIMand definesAMREX_SPACEDIMvia a public CLI define nowAdditional background
I recently wrote an analysis piece lamenting that compile time software variants that define exclusive features are a productivity and usability challenge. One particular challenge we face in the shipping of WarpX and pyAMReX is that users (and developers) would like to seamlessly switch between the dims (1-3D) of our codes. Switching between compile-time and runtime description for such elementary workflows can and should be avoided.
Generally, this problem can be solved with more general interfaces in AMReX. Practically, this is a bit of work that we have not yet started.
Weiqun:
Things this does not yet solve
As before, this does not solve namespace and/or symbol clashes. We should introduce unique name spaces and rework many globals in AMReX for this, but this is an orthogonal issue.
Checklist
The proposed changes: