libMesh-centric containers for development?

[benkirk]

Is anyone using containers in their development (or production) workflow?

I had reason to create a rocky8 container this week with a specific petsc / libmesh install, and the idea struck me this could be a useful shared resource.

I'd envision some collaborative Dockerfiles for rhel/sles/ubuntu that make it 'easy' to stand up an image to build libmesh on that platform, and also therefore test any distro-specific dependency resolution bits.

-Ben

[roystgnr]

Moose keeps an Ubuntu-20.04 docker container up to date, https://mooseframework.inl.gov/getting_started/installation/docker.html

I agree that it would be useful to have something libMesh-only and to have more than just the one "flavor" of it. I don't recall the last time we hit distro-specific (that weren't compiler-specific or combination-of-dependency-installations-specific) issues, but it's not impossible. And I'd love to have a FreeBSD container to throw into CI, for that matter.

[benkirk]

Sounds good. I'm a few days into this so I'll contain my enthusiasm, but plan to start by uploading some reference Dockerfiles to GitHub for general use.

As for distro-specific stuff, my most recent example is that rocky8 has a petsc package available via yum. libMesh builds just fine on the system, so there is no problem per se, but doesn't know how to find that package via configure. So it would be nice to have a test bed for those kinds of things.

[roystgnr]

but doesn't know how to find that package via configure.

Doesn't have any way to find via configure arguments, or doesn't autodetect?

The former is definitely a bug, and it's a bug I've seen in other contexts (I had to create some symlinks to rearrange Ubuntu's HDF5 installation into the sort of $HDF5_DIR we expect...) and it's something we ought to fix.

The latter, though? I used to be the biggest cheerleader for team Autodetect All The Things, but in hindsight I think we should start wrapping any peek at /usr within some sort of explicit requirement of --enable-autodetect permission from the user. It's too easy otherwise for a user's carefully selected $HOME/modules/foo/libfoo.so.new to end up conflicting with an accidentally accessed /usr/lib/libfoo.so.ancient.

[benkirk]

I was unsuccessful getting even configure arguments to work; not to say it is impossible though - I'll continue down that path. The RHEL-8 petsc-{mpich,openmpi}-devel packages spread things around in a way that befuddled my initial efforts, at least, as it doesn't immediately map to our expectation of a PETSC_DIR and optionally PETSC_ARCH:

$ yum repoquery --list petsc-mpich-devel
/usr/include/mpich-x86_64/petsc/makefile
/usr/include/mpich-x86_64/petsc/petsc.h
/usr/include/mpich-x86_64/petsc/petscconf.h
...
/usr/lib64/mpich/lib/libpetsc.so
/usr/lib64/mpich/lib/petsc
/usr/lib64/mpich/lib/petsc/conf
/usr/lib64/mpich/lib/petsc/conf/petscrules
/usr/lib64/mpich/lib/petsc/conf/petscvariables
/usr/lib64/mpich/lib/petsc/conf/rules
/usr/lib64/mpich/lib/petsc/conf/variables
/usr/lib64/mpich/lib/pkgconfig/PETSc.pc
/usr/lib64/mpich/lib/pkgconfig/petsc.pc

I could get libMesh to interrogate the 'variables' file, but then there seemed to be double-prefixing of PETSC_DIR.

They do provide a pkg-config definition though, which should make it 'easy':

$ pkg-config --cflags  --libs  PETSc
-I/usr/include/mpich-x86_64/petsc -L/usr/lib64/mpich/lib -lpetsc -lhdf5 

So to the subject post, making such a container readily available could be useful. It also might provide a mechanism for advanced users to report issues as well, by sharing an image that replicates the problem.

[jwpeterson]

This definitely looks strange to me, but I guess can see the logic from a "not wanting to accidentally mix different MPI implementations" standpoint.

[tbridel]

Hi everyone !

I'm new in the libMesh world and I realize this conversation starts to be slightly old, but I thought it would make more sense to jump in rather than start a new thread ! 🙂

I just wanted to point out this tiny (nano really) repo of mine: libMesh_docker, where I quickly put together a Debian-based image for the latest libMesh with the basic dependencies like PETSc & SLEPc.
I needed it to have a stable dev environment to start playing around with libMesh and I mostly use it to spin-up VSC instances.

If it is of any interest to the dev team here, I would be happy to take in some requests to adapt/improve the Dockerfiles and/or to open a dedicated PR. We could even imagine leveraging the new Codespace capability of GitHub to provide the newcomers with an online playground where they could run the introduction examples for instance.

Take care !
Thibault

[jwpeterson]

Hello @tbridel

Thanks for your efforts, this definitely looks like something that could be useful. My normal workflow doesn't really involve Docker, so I don't know if I will be able to provide much useful feedback. One comment is that, in libmesh_debian.Dockerfile, I noticed that you don't run git submodule update --init --recursive before running configure and make? Does clone --recursive handle this step for you somehow?

--
John

[tbridel]

Hi @jwpeterson,

Thank you for coming back to me this quick !

Yes indeed git clone --recursive takes care of nested repos the same way git clone and git submodule update --init --recursive executed successively would :)

[jwpeterson]

OK, interesting. I confirmed that this does indeed work for my version of git (2.36.1) but the git help clone docs only mentions the --recurse-submodules flag.

[jwpeterson]

We could update our README.md file to mention this way of running git clone.

[tbridel]

Hi @jwpeterson !

I took another look at Git doc and it seems that indeed the flag --recursive was introduced for git clone in version 1.6.5 and replaced later by --recurse-submodules. Woops 😅
I am using Git v2.38.1 here and it still supports the (deprecated) --recursive too.

Anyways, I think it's best, if you edit the README, to use --recurse-submodules, and i'll update myself as well 😄.

[benkirk]

I'd be happy to share what I've done recently in this area too, in case it is helpful: https://github.com/benkirk/containers There are a number of containers in there that support libMesh, OpenSUSUE+OpenHPC, Rocky8+OpenHPC, Rocky9 Native... In case this is of interest!

…

-Ben

On Wed, Feb 15, 2023 at 9:07 AM tbridel ***@***.***> wrote: Hi everyone ! I'm new in the libMesh world and I realize this conversation starts to be slightly old, but I thought it would make more sense to jump in rather than start a new thread ! 🙂 I just wanted to point out this tiny (nano really) repo of mine: libMesh_docker <https://github.com/tbridel/libMesh_docker>, where I quickly put together a Debian-based image for the latest libMesh with the basic dependencies like PETSc & SLEPc. I needed it to have a stable dev environment to start playing around with libMesh and I mostly use it to spin-up VSC instances. If it is of any interest to the dev team here, I would be happy to take in some requests to adapt/improve the Dockerfiles and/or to open a dedicated PR. We could even imagine leveraging the new Codespace capability of GitHub to provide the newcomers with an online playground where they could run the introduction examples for instance. Take care ! Thibault — Reply to this email directly, view it on GitHub <#3253 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASBY3CBAQUJ7BLFWCLW2FTWXT5NHANCNFSM5UTV2S2A> . You are receiving this because you authored the thread.Message ID: ***@***.***>