update singularity to apptainer, change from poetry to uv

[mj-gomes]

Hi,

I realized the singularity files were pretty outdated. Here's what I did:

• Change to apptainer, which is the new name of singularity. The commands are pretty much the same, we just need to change singularity to apptainer everywhere. I also did change this for the docs.
• Update the container building commands, so that they use uv instead of poetry.

When building the container, the tests are failing because they can't access the IMo file, which should be automatic. If I do the same commands outside of the container the tests pass, so it may be some Path problem, which I could not yet figure out. Does someone have an idea as to why this is happening?

There also seems to be an error fetching maps from the astropy archive, it is a 404 error, and since it does not happen outside of the container it is a bit weird, as if for some reason the path to the online location of those maps is incorrect. The commands in the .m4 file are pretty straightforward, typical uv setting, I am not sure yet why it is happening.

TODO:

• Add BrahMap
• Fix IMo problem
• Fix pysm3 problem
• Update tutorial videos in the docs

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
litebird_sim
beam_convolution.py
dipole.py
input_sky.py
maps_and_harmonics.py
noise.py
non_linearity.py
observations.py
seeding.py
simulations.py
units.py
litebird_sim/hwp_harmonics
hwp_harmonics.py
jones_methods.py
Project Total

This report was generated by python-coverage-comment-action

[mj-gomes]

BrahMap installation was failing due to the lack of mpi binaries in the container. I added them and it is working now.

Now when no mpi backend is chosen, the user gets a message saying: "Skipping MPI installation. BrahMap will also not be installed as it is dependent on MPI binaries."

Also, in this case, uv sync can not include the mpi dependencies, as it will fail as well. So I also added that to the .m4 file, i.e., only add --extra mpi to uv sync when mpi binaries are present.

Thank you to @anand-avinash for pointing out the recent update in BrahMap installation, making it work without the --recursive option.

[mj-gomes]

To fix the other two problems, I had to create the imo.toml file inside .config inside the container and cache pysm3 files before running the tests. I basically had to follow a similar procedure to the one done in the tests workflow in .github. I had to do some specific changes, e.g. changing echo to printf when creating the imo.toml file, since echo was having some problems with (I believe) parsing.

I also had to be sure we were in the correct path everywhere and that the cache directory was /tmp, so that it is writable, and that the path on %runscript was set to the one with the uv venv.

Anyway, it is working now.

The only thing that I could not make work exactly as before is the opening of a python shell by simply ./litebird_sim.img. It works if we do the normal apptainer run ./litebird_sim.img ipython, or simply ./litebird_sim.img ipython. I am on it. EDIT: Fixed.

[mj-gomes]

EDIT: actually, I realized the discussion I had started was not really that important, as our definition file should be possible to build with either SingularityCE or Apptainer. This becomes a user defined choice, depending on the context. I would say we should however refer these two possibilities it in the docs. I am leaving what I had written below, since it is still useful information about Apptainer and SingularityCE.

Apptainer is a Singularity fork belonging to the Linux Foundation (still open source), while a SingularityCE (Community Edition) exists as another fork which followed a slightly different path at the moment where Apptainer was born. In the majority of things, they are still pretty similar and interoperable.

You can read more about their divergences read here, here or here

It seems that apptainer is preferred for HPC containerized jobs without root privileges, which is often the case for anyone running lbs. These discussions are from 2024, but I did not find recent similar ones. Also, I know at least one HPC cluster which opted for apptainer instead of singularity, while others like Cineca seem to accept both.

Another difference that I ran into is that apptainer seems to not automatically bind the $PWD path to the container. This means that, while before we could create a python script on the apptainer directory and simply run ./litebird_sim.img python3 script.py (see the second video in the docs), now we have to specify the binding ourselves apptainer run -B $PWD:$PWD \litebird_sim.img python3 script.py or setting it as the container's home apptainer run -H $PWD \litebird_sim.img python3 script.py.

This does not seem like a big deal, especially if we gain in ease of usage inside HPC environments without root privileges. It is just a little less user-friendly.