Problem
csauto prepare copies the shared MESH/ (and POST/) once into RUNS/MESH via
_copy_shared_dir (csauto/doe.py:282). For large meshes (.med files can be GBs) this
physical copy wastes disk space — the mesh already exists at the study level. Cases
reference it relatively (../MESH), so a symlink would work in principle.
Note: the copy is already shared (one RUNS/MESH, not one per case), and
_copy_shared_dir already partially tolerates symlinks (doe.py:103-114).
⚠️ The container trap (must be handled)
Docker/Singularity mount only the RUNS directory:
docker run -v <RUNS>:/home/code_saturne ... # docker.py:27
apptainer ... --bind <RUNS>:/home/code_saturne ... # execution.py:227
If RUNS/MESH becomes a symlink pointing to a source outside RUNS (e.g.
/study/MESH), then inside the container the target is not mounted → mesh not found,
run fails. A naive symlink works natively but breaks Docker/Singularity runs.
Candidate approaches (developer picks)
- Symlink + auto bind-mount —
RUNS/MESH becomes a symlink, and csauto also adds a
read-only bind of the mesh source into the container at /home/code_saturne/MESH.
Works native + docker + singularity; touches docker.py + execution.py.
- Config
mesh_mode = copy|symlink — opt-in symlink (default stays copy,
backward-compatible); document the container caveat. Minimal, no mount changes.
- Symlink only — simplest, native-only; explicitly breaks containers. Only if
container runtimes are out of scope.
The maintainer should choose based on how important container runtimes are (they are
commonly used here) vs. implementation cost.
Acceptance criteria
Notes
- Same reasoning applies to
POST/ (also shared-copied at doe.py:283).
- Windows: symlinks need privileges/dev-mode; keep
copy as a safe fallback there.
Problem
csauto preparecopies the sharedMESH/(andPOST/) once intoRUNS/MESHvia_copy_shared_dir(csauto/doe.py:282). For large meshes (.medfiles can be GBs) thisphysical copy wastes disk space — the mesh already exists at the study level. Cases
reference it relatively (
../MESH), so a symlink would work in principle.Note: the copy is already shared (one
RUNS/MESH, not one per case), and_copy_shared_diralready partially tolerates symlinks (doe.py:103-114).Docker/Singularity mount only the
RUNSdirectory:If
RUNS/MESHbecomes a symlink pointing to a source outsideRUNS(e.g./study/MESH), then inside the container the target is not mounted → mesh not found,run fails. A naive symlink works natively but breaks Docker/Singularity runs.
Candidate approaches (developer picks)
RUNS/MESHbecomes a symlink, and csauto also adds aread-only bind of the mesh source into the container at
/home/code_saturne/MESH.Works native + docker + singularity; touches
docker.py+execution.py.mesh_mode = copy|symlink— opt-in symlink (default stayscopy,backward-compatible); document the container caveat. Minimal, no mount changes.
container runtimes are out of scope.
The maintainer should choose based on how important container runtimes are (they are
commonly used here) vs. implementation cost.
Acceptance criteria
explicitly documented and guarded with a clear warning if the naive path is taken).
docs/concepts.mdorrun-lifecycle.md) note the mesh handling + any caveat.Notes
POST/(also shared-copied atdoe.py:283).copyas a safe fallback there.