[WIP] Build PyChaste on Ubuntu 25.10 Questing Quokka

[kwabenantim]

Supports #22

[kwabenantim]

PyChaste generates and builds wrappers okay with the default Clang 20 on Ubuntu 25.10 Questing Quokka.

[kwabenantim]

The bindings are now building correctly in the container @bdevans

[bdevans]

This works fine when building the base and develop images but fails on attempting to build the release image (with 2024.2):

48.94 ####################################
48.94 # Configuring components
48.94 ####################################
48.94 
48.96 Configuring component global
48.96 Configuring tests for global
48.98 Configuring component io
48.98 Configuring tests for io
48.98 Configuring component linalg
48.99 Configuring tests for linalg
48.99 Configuring component mesh
48.99 Configuring tests for mesh
49.01 Configuring component ode
49.01 Configuring tests for ode
49.03 Configuring component pde
49.03 Configuring tests for pde
49.06 Configuring component continuum_mechanics
49.06 Configuring tests for continuum_mechanics
49.07 Configuring component cell_based
49.08 Configuring tests for cell_based
49.17 Configuring component crypt
49.17 Configuring tests for crypt
49.19 Configuring component lung
49.20 Configuring tests for lung
49.22 Configuring component heart
54.22 Configuring tests for heart
54.30 Configuring main Chaste apps
54.30 Configuring Chaste app
54.30 Configuring MeshConvert app
54.30 Configuring tests for python
54.34 -- Configuring done (19.6s)
54.36 CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
54.36 Please set them or make sure they are set and tested correctly in the CMake files:
54.36 METIS_LIBRARY (ADVANCED)
54.36     linked by target "chaste_global" in directory /home/chaste/src/global
54.36     linked by target "chaste_io" in directory /home/chaste/src/io
54.36     linked by target "chaste_linalg" in directory /home/chaste/src/linalg
54.36     linked by target "chaste_mesh" in directory /home/chaste/src/mesh
54.36     linked by target "chaste_ode" in directory /home/chaste/src/ode
54.36     linked by target "chaste_pde" in directory /home/chaste/src/pde
54.36     linked by target "chaste_continuum_mechanics" in directory /home/chaste/src/continuum_mechanics
54.36     linked by target "chaste_cell_based" in directory /home/chaste/src/cell_based
54.36     linked by target "chaste_crypt" in directory /home/chaste/src/crypt
54.36     linked by target "chaste_lung" in directory /home/chaste/src/lung
54.36     linked by target "chaste_heart" in directory /home/chaste/src/heart
54.36 
60.13 CMake Warning:
60.13   Manually-specified variables were not used by the project:
60.13 
60.13     Chaste_ENABLE_PYCHASTE
60.13 
60.13 
60.13 CMake Generate step failed.  Build files cannot be regenerated correctly.
60.13 -- Generating done (5.8s)
------
Dockerfile:164
--------------------
 162 |     ARG GIT_TAG=-
 163 |     ENV GIT_TAG=${GIT_TAG}
 164 | >>> RUN build_chaste.sh ${GIT_TAG}
 165 |     
 166 |     # Automatically mount the home directory in a volume to persist changes made there.
--------------------
ERROR: failed to build: failed to solve: process "/bin/sh -c build_chaste.sh ${GIT_TAG}" did not complete successfully: exit code: 1

[bdevans]

At the time of writing, the latest develop image pulled from docker hub (20260329) is 9.8GB whereas building it in the pychaste branch results in an 18.2GB image (1.3GB of which is the difference in the base layer due to the extra dependencies).

Is this expected @kwabenantim or is there some significant duplication of the files?

[kwabenantim]

This works fine when building the base and develop images but fails on attempting to build the release image (with 2024.2):

This is probably because Chaste 2024.2 will not work out of the box on Ubuntu 25.04 onwards due to parmetis being dropped (Chaste/Chaste#424). It will probably still work with a custom install of parmetis. develop should work fine on the newer Ubuntus because it now uses libscotch which is available on the newer Ubuntus.

[kwabenantim]

At the time of writing, the latest develop image pulled from docker hub (20260329) is 9.8GB whereas building it in the pychaste branch results in an 18.2GB image (1.3GB of which is the difference in the base layer due to the extra dependencies).

Is this expected @kwabenantim or is there some significant duplication of the files?

It seems the wrappers add about 5.5G to the build directory and 0.5G to site-packages so should total about 6G. That roughly adds up (18.2 - 9.8 - 6 - 1.3 = 1.1)

chaste@7ede4a9cd738:~/build$ du -sh pychaste                                        
5.5G    pychaste

chaste@7ede4a9cd738:~/build$ du -sh pychaste/*
4.4G    pychaste/CMakeFiles
4.0K    pychaste/CTestTestfile.cmake
860K    pychaste/Makefile
4.0K    pychaste/cmake_install.cmake
336K    pychaste/cppwg.log
9.2M    pychaste/libchaste_pychaste.so
1.1G    pychaste/package
9.8M    pychaste/test
5.9M    pychaste/wrappers

chaste@7ede4a9cd738:~/build$ du -sh pychaste/CMakeFiles/*
4.0K    pychaste/CMakeFiles/CMakeDirectoryInformation.cmake
4.4G    pychaste/CMakeFiles/_pychaste_all.dir
18M     pychaste/CMakeFiles/chaste_pychaste.dir
4.0K    pychaste/CMakeFiles/progress.marks
32K     pychaste/CMakeFiles/pychaste_wrappers.dir

chaste@7ede4a9cd738:~/build$ du -sh pychaste/CMakeFiles/_pychaste_all.dir/*
140K    pychaste/CMakeFiles/_pychaste_all.dir/DependInfo.cmake
1.2M    pychaste/CMakeFiles/_pychaste_all.dir/build.make
88K     pychaste/CMakeFiles/_pychaste_all.dir/cmake_clean.cmake
38M     pychaste/CMakeFiles/_pychaste_all.dir/compiler_depend.internal
40M     pychaste/CMakeFiles/_pychaste_all.dir/compiler_depend.make
4.0K    pychaste/CMakeFiles/_pychaste_all.dir/compiler_depend.ts
4.0K    pychaste/CMakeFiles/_pychaste_all.dir/depend.make
8.0K    pychaste/CMakeFiles/_pychaste_all.dir/flags.make
96K     pychaste/CMakeFiles/_pychaste_all.dir/link.d
48K     pychaste/CMakeFiles/_pychaste_all.dir/link.txt
12K     pychaste/CMakeFiles/_pychaste_all.dir/progress.make
4.3G    pychaste/CMakeFiles/_pychaste_all.dir/wrappers

chaste@7ede4a9cd738:~/build$ du -sh pychaste/CMakeFiles/_pychaste_all.dir/wrappers/*
4.3G    pychaste/CMakeFiles/_pychaste_all.dir/wrappers/all

chaste@7ede4a9cd738:~$ du -sh ~/.local/lib/python3.13/site-packages/*
547M    /home/chaste/.local/lib/python3.13/site-packages/chaste
36K     /home/chaste/.local/lib/python3.13/site-packages/chaste-2024.1.dist-info

[kwabenantim]

We can probably remove the intermediate wrapper binaries from the image since they aren't required for PyChaste to work:

rm $CHASTE_BUILD_DIR/pychaste/CMakeFiles/_pychaste_all.dir/wrappers/all/*.o

This should bring the size down by about 4GB, but they'll be rebuilt again if someone wants to re-compile PyChaste after making changes.

@bdevans

[bdevans]

Hi @kwabenantim, 4GB would be a nice saving but how much time would it add to rebuild those intermediates as part of a recompile?

Also, I think the 18.2GB figure may have included some unnecessary dependencies so hopefully we can reduce the image size further.

[kwabenantim]

4GB would be a nice saving but how much time would it add to rebuild those intermediates as part of a recompile?

That's a good point @bdevans. It's about 20m to build PyChaste with -j 4 on GitHub actions: https://github.com/Chaste/Chaste/actions/runs/24940069675/job/73032206831

Also, I think the 18.2GB figure may have included some unnecessary dependencies so hopefully we can reduce the image size further.

Thanks, I think that would be useful. Also, it seems there will be a decent amount of compression when it gets uploaded to Docker Hub (chaste/develop is currently less than 2.5 GB).

[kwabenantim]

We could also experiment with the OPT_SIZE flag in pybind11

A ~25% size reduction has been observed in practice.

[bdevans]

That's a good point @bdevans. It's about 20m to build PyChaste with -j 4 on GitHub actions: https://github.com/Chaste/Chaste/actions/runs/24940069675/job/73032206831

The average UK broadband speed is about 75MB/s so the extra 4GB adds about 7m to the download - roughly 1/3 of the time it takes to rebuild it. Considering a) the image is compressed by Docker Hub and b) most of those downloads will likely be on much faster campus networks, I think that's an acceptable up-front increase considering the time saved on rebuilding the files.