Adds axom module to python interface with axom.sidre - #1896
Conversation
08306f7 to
06e053d
Compare
There was a problem hiding this comment.
Question for reviewers -- especially @bmhan12 -- do you think we need this pysidre shim?
I'm not aware of anyone that's currently using this, and the minimal fix in a script that uses this is very straightforward:
- import pysidre
+ import axom.sidre as pysidreThere was a problem hiding this comment.
do you think we need this pysidre shim?
I think we can get rid of the shim.
Thinking of packages like matplotlib, where it's standard practice to just do: import matplotlib.pyplot as plt as the recommended path (https://matplotlib.org/stable/tutorials/pyplot.html).
|
|
||
| if(NANOBIND_FOUND) | ||
| nanobind_add_module(pysidre nanobind_sidre.cpp) | ||
| # Python bindings for Sidre. |
There was a problem hiding this comment.
I think most of this logic belongs in the parent directory's CMakeLists.txt,
but I held off on moving it up for now since we only currently have one python submodule (axom.sidre)
Once we have another one, we'll likely have a better sense of what the general pattern should be.
On the other hand, I'm not against refactoring it in this PR.
There was a problem hiding this comment.
Leave it for now and refactor when we have another Python module to avoid churn?
|
|
||
| # gen python helper to build directory | ||
| set(_PYEXT_DIR ${PROJECT_BINARY_DIR}/lib) | ||
| # gen python helper to build directory. |
There was a problem hiding this comment.
Similarly here -- the installation logic for Axom's python modules probably doesn't belong in src/tools/CMakeLists.txt
| # SPDX-License-Identifier: (BSD-3-Clause) | ||
|
|
||
| import pysidre | ||
| import axom.sidre as pysidre |
There was a problem hiding this comment.
To minimize the changes in this PR, I only applied
- import pysidre
+ import axom.sidre as pysidreShould we use the full axom.sidre or perhaps something else instead of pysidre in our examples/tests for sidre's python interface?
There was a problem hiding this comment.
Is there an issue with using pysidre?
There was a problem hiding this comment.
The only thing I can think of is that this PR is changing the (sub)module name to axom.sidre but our tests are still using pysidre --
I don't think it's an actual issue, but was wondering if we might want the python to just call it sidre,
| if spec.satisfies("+python"): | ||
| # Install Axom's Python package(s) so a spack environment view merges them into | ||
| # a single site-packages and `import axom.sidre` works without updating PYTHONPATH | ||
| entries.append( | ||
| cmake_cache_path( | ||
| "AXOM_PYTHON_MODULE_INSTALL_PREFIX", | ||
| spec["python"].package.platlib, | ||
| ) | ||
| ) |
There was a problem hiding this comment.
Does this PR require updating the host-configs?
There was a problem hiding this comment.
Good call -- I'll do that.
Edit: On second thought, I think I'll add this in the follow-up PR (unless you feel strongly about it for this one).
It won't cause our CI to fail since it's related to how others import axom.sidre.
I think we should add an installation test for this, but will save it for a follow-up PR.
| parallel_io_concepts | ||
| sidre_conduit | ||
| mfem_sidre_datacollection | ||
| python_interface |
There was a problem hiding this comment.
There was a problem hiding this comment.
06e053d to
5114bc4
Compare
* Renames the extension module from `pysidre` to `_sidre` so can import `axom.sidre` * Adds python package scaffolding to `src/python` * Introduces `AXOM_PYTHON_MODULE_INSTALL_PREFIX` CMake cache variable * Update pysidre usage to `import axom.sidre as pysidre` and adds a shim to warning users that importing `pysidre` is deprecated.
This allows spack environment views to place Axom's installed Python packages onto the interpreter path automatically. This commit also emits `AXOM_PYTHON_MODULE_INSTALL_PREFIX` in the generated host-config.
One can call the macro with either a COMMAND or a SOURCE file.
Misc: Fixes typos and whitespace issues
This allows type checkers to see the sidre Python API
The tests are in our github-ci tests as well as for spack-based installations
This will allow the types from all of the Axom python modules to better interoperate.
5114bc4 to
c18ab0b
Compare
| example() | ||
| make("clean") | ||
|
|
||
| @run_after("install", when="+examples+python+tools components=sidre") |
There was a problem hiding this comment.
I tested this with:
./scripts/uberenv/uberenv.py --install --run_tests --spec "+python+devtools+hdf5+mfem+c2c+adiak+caliper+opencascade %clang_19"
Here's the relevant part of the installation test:
==> [2026-07-02-16:02:24.101027] '.../llvm-19.1.3/axom-develop-adk5fhlf3iangdg5wkn4kmd4mpsn7bvi/bin/run_python_with_axom.sh' '.../llvm-19.1.3/axom-develop-adk5fhlf3iangdg5wkn4kmd4mpsn7bvi/examples/axom/using-with-python/example.py'
Using installed axom.sidre v0.14.0
==> [2026-07-02-16:02:24.464562] '.../python-3.13.11/bin/python3' '-c' 'import axom.sidre as s; import numpy; print('"'"'axom.sidre'"'"', s.__version__)'
axom.sidre v0.14.0
Co-authored-by: Chris White <white238@llnl.gov>
| NUMPROCS=$(python3 -c 'import os; print(os.cpu_count())') | ||
| NUM_BUILD_PROCS=$(python3 -c 'import os; print(max(2, os.cpu_count() * 8 // 10))') | ||
|
|
||
| echo "~~~~~~ RUNNING CMAKE ~~~~~~~~" | ||
| or_die python3 ./config-build.py -bp builddir -hc ./host-configs/docker/${HOST_CONFIG} -bt ${BUILD_TYPE} -DENABLE_GTEST_DEATH_TESTS=ON ${CMAKE_EXTRA_FLAGS} | ||
| or_die cd builddir | ||
|
|
||
| echo "~~~~~~ BUILDING ~~~~~~~~" | ||
| if [[ ${CMAKE_EXTRA_FLAGS} == *COVERAGE* ]] ; then | ||
| or_die make -j $NUM_BUILD_PROCS | ||
| or_die make -j ${NUM_BUILD_PROCS} | ||
| else | ||
| or_die make -j $NUM_BUILD_PROCS VERBOSE=1 | ||
| or_die make -j ${NUM_BUILD_PROCS} VERBOSE=1 | ||
| fi | ||
|
|
||
| echo "~~~~~~ RUNNING TESTS ~~~~~~~~" | ||
| make CTEST_OUTPUT_ON_FAILURE=1 test ARGS='-T Test --output-on-failure -j$NUM_BUILD_PROCS' | ||
| or_die make CTEST_OUTPUT_ON_FAILURE=1 test ARGS="-T Test --output-on-failure -j${NUM_BUILD_PROCS}" |
There was a problem hiding this comment.
We weren't passing in -j flag properly:
2026-07-16T00:56:04.1126650Z ~~~~~~ FIND NUMPROCS ~~~~~~~~
2026-07-16T00:56:04.1127335Z + echo '~~~~~~~~~~~~~~~~~~~~~~'
2026-07-16T00:56:04.1127649Z + export BUILD_TYPE=Debug
2026-07-16T00:56:04.1127886Z + BUILD_TYPE=Debug
2026-07-16T00:56:04.1128090Z + [[ yes == \y\e\s ]]
2026-07-16T00:56:04.1128312Z + echo '~~~~~~ FIND NUMPROCS ~~~~~~~~'
2026-07-16T00:56:04.1128658Z ++ python3 -c 'import os; print(f'\''{os.cpu_count()}'\'')'
2026-07-16T00:56:04.1254132Z + NUMPROCS=4
2026-07-16T00:56:04.1256781Z ++ python3 -c 'import os; print(f'\''{max(2, os.cpu_count() * 8 // 10)}'\'')'
2026-07-16T00:56:04.1373763Z + NUM_BUILD_PROCS=3
...
2026-07-16T00:56:16.6263485Z + echo '~~~~~~ BUILDING ~~~~~~~~'
2026-07-16T00:56:16.6264412Z + [[ -DBUILD_SHARED_LIBS=ON -DBLT_CXX_STD=c++20 -DENABLE_BENCHMARKS:BOOL=ON -DAXOM_QUEST_ENABLE_EXTRA_REGRESSION_TESTS:BOOL=OFF == *COVERAGE* ]]
2026-07-16T00:56:16.6265219Z ~~~~~~ BUILDING ~~~~~~~~
2026-07-16T00:56:16.6265519Z + or_die make -j 3 VERBOSE=1
2026-07-16T00:56:16.6280465Z + make -j 3 VERBOSE=1
...
2026-07-16T01:38:02.1051791Z ~~~~~~ RUNNING TESTS ~~~~~~~~
2026-07-16T01:38:02.1052665Z + [[ 0 != 0 ]]
2026-07-16T01:38:02.1053239Z + echo '~~~~~~ RUNNING TESTS ~~~~~~~~'
2026-07-16T01:38:02.1054316Z + or_die make CTEST_OUTPUT_ON_FAILURE=1 test 'ARGS=-T Test --output-on-failure -j$NUM_BUILD_PROCS'
2026-07-16T01:38:02.1055900Z + make CTEST_OUTPUT_ON_FAILURE=1 test 'ARGS=-T Test --output-on-failure -j$NUM_BUILD_PROCS'
(the last line should end with -j3)
Summary
axom.sidreinstead ofpysidreAXOM_PYTHON_MODULE_INSTALL_PREFIXCMake variable for controlling where Axom's python modules get installed, and updates spack to have axomextendpython for improved access within spack environments.run_axom_with_sidrescript now allows relative paths to the Axom module in support of this.