APCEMM does not run on Docker (commit 6989e93)

[Calebsakhtar]

The current commit of APCEMM (https://github.com/MIT-LAE/APCEMM/commit/6989e93c65e7161bec16b2fe5f7d15c8b15d540a) does build on a Docker image, but it does not run the example issl_rhi140.

No files are written to APCEMM_out/, and the terminal gets stuck as follows:

/h/A/e/issl_rhi140 # ❯❯❯ ./run_example3.sh
 -> Running case 0 on thread 0
running epm... 
Calculated Timestep: 1[min]
/home/APCEMM/examples/issl_rhi140/APCEMM_out/
Saving TS_AERO files to: /home/APCEMM/examples/issl_rhi140/APCEMM_out//ts_aerosol_case0_hhmm.nc
Starting pressure of 26500 Pa. Pressure altitude is 9.98431 km

I have successfully built APCEMM on the same commit on the Cambridge HPC, and have also managed to run the example. This indicates to me that the issue outlined here is likely to be platform dependent.

[Calebsakhtar]

@sdeastham @dcdrake Any ideas?

[ddrake-mitre]

No, nothing off the top of my head. Some ideas for debugging below, ignore any you already did:

1. Are you able to attach a debugger and break once the program hangs? If yes, then dropping a few breakpoints after the last message that gets printed might point in the right direction.
2. If no, just logging some stuff to the terminal after that last message might also give some clues
3. Are there any new input files/directories/paths? If yes, make sure they're being built or mounted into the container. Same goes for any new outputs.
4. Permissions. Writing files into, but particularly out of, containers can leave you with files that have an owner or permissions you aren't expecting. I'm guessing this doesn't have much to do with your issue, but it's something I've run into enough times that it's worth having on the list.

[dcdrake]

@Calebsakhtar I took a look this morning, and here are some things that you might want to check:

1. README says you need GCC >= 11.2, docker builds with GCC 9 FROM --platform=linux/amd64 gcc:9.3-buster as builder

2. vcpkg seems to be installing the same dependencies that the docker image provides, but with different versions. For example, I noticed during the build that vcpkg was using boost 1.83, but the docker image uses 1.60. (And I see Catch2 going by now v3.4.0, but docker uses 3.2.1)

I've never used vcpkg, but it seems like it's just getting the latest versions of everything. It sounds like you're running in a few different places, so you're the best judge of which method for building makes the most sense. If you want to use vcpkg, then you could consider building a docker image with GCC 11 and not much else, and let vcpkg handle the dependency installs. Consider pinning specific release versions of your dependencies in that case.

If you have the time, you could also consider setting up some github actions to run the build and your test scenario. They provide some OS docker images to run in, but I think you can build and specify your own (although I'm not 100% sure how this works in the wild, we have our own internal way to deal with it).

[Calebsakhtar]

Hi @dcdrake, thank you for the above. I will take a look at what I can do this afternoon and report back with the findings. I think that for consistency we should probably use the vcpkg method for installing all C++ dependancies.

[dcdrake]

Yeah, if vcpkg is the easiest and functions across the environments you work in then I agree.

[Calebsakhtar]

I will take a look at this later this week, not tonight as initially foreseen.

[Calebsakhtar]

@dcdrake Your second comment was right on the money. PR to follow later today after some testing.

[Calebsakhtar]

Issue addressed in PR https://github.com/MIT-LAE/APCEMM/pull/49

[sdeastham]

Closed as issue now address (PR #49).