Dockerfiles to build both with and without conda

[gonuke]

These dockerfiles will build Cardinal according to the typical installation instructions, within an Ubuntu 24.04 docker image.

[gonuke]

This doesn't seem to be accelerating the build

[nuclearkevin]

I believe you also need to set JOBS and MOOSE_JOBS to accelerate a full build from source. From my understanding update_and_rebuild_libmesh.sh overrides LIBMESH_JOBS in a few instances with those environment variables when building libMesh from source.

[gonuke]

That definitely made a difference

[aprilnovak]

@nuclearkevin thanks for this clarification! I updated the documentation (#994) to make sure its comprehensive.

[ahnaf-tahmid-chowdhury]

I assume INL has plans to create a conda package for Cardinal, as I noticed a repo is already available. I wonder when it will be released.

[aprilnovak]

@loganharbour can maybe answer this?

[loganharbour]

This file can be removed. It's actually not used.

We release every master commit of cardinal as a built container in https://hub.docker.com/r/idaholab/cardinal/tags.

[gonuke]

To be clear, this file is being considered as a contribution - it doesn't exist yet and thus there is nothing to remove...

I made this PR because some folks may want to build their own docker images for development purposes, and this provides a shortcut to figuring out those steps. Do you share the Dockerfile used to build the images shared on Docker Hub?

[loganharbour]

Sorry, my apologies. I responded to this from an e-mail and didn't capture any of the PR context.

https://hub.docker.com/repository/docker/idaholab/moose-dev/tags is the development base for all MOOSE-based applications (including cardinal). It contains compiled libmesh, petsc, wasp, and the moose-tools conda package for the needed python libraries.

This is the base image (ported from apptainer) used for CI testing of all MOOSE based apps, and also for released installed versions of all apps. We typically prefer that people start with this as it is easier for us to support issues with an environment that we are familiar with.

The version of the moose-dev image to use given an application is determined by running

scripts/versioner.py moose-dev

within the moose directory of the application.

[aprilnovak]

What is the status of this PR?

[lewisgross1296]

@aprilnovak asked today about cross sections and the OpenMC python API. In the past, I've used something like

RUN wget -q -O - LINK_TO_XS.gz | tar -C cross_sections -xJ
ENV OPENMC_CROSS_SECTIONS /PATH/TO/cross_sections/endfb-vii.1-hdf5/cross_sections.xml

for cross sections, but mounting would be another option. This only needs to happen once per successful build of this step, so it is probably fine enough to just wget the desired XS and set your environment variable. I was using the ANL box link that I believe Cardinal uses but there's also some tar versions of hdf5 data here.

I think installing the python API is as simple as

RUN cd /path/to/openmc/ && python -m pip install .

where /path/to is likely just /contrib/openmc. We could also have a build arg whether or not to

RUN ./run_tests -j8

at the end (may require some finagling with the nndc cross sections)

[lewisgross1296]

Some things I noticed when I went to build Cardinal with a Dockerfile

[lewisgross1296]

Testing out this Dockerfile for myself. These lines seem harmless here, since Docker defaults to

SHELL ["/bin/bash", "-c"]

and adding the "-i" allows this

       -i        Specify that the shell is interactive; see below. An
                 implementation may treat specifying the -i option as an
                 error if the real user ID of the calling process does
                 not equal the effective user ID or if the real group ID
                 does not equal the effective group ID.            

but the comment implies that they're included for conda and this is the from source Dockerfile. I think we should either use the default (remove these lines) or change the comment to explain why this is needed in the from source build.

[lewisgross1296]

Maybe we should make the -j 16 an argument since some people will have more or less CPUs available