What happens
-t is declared with nargs="+", so it takes a space-separated list:
-t, --targets TARGET [TARGET ...]
Repeating the flag does not append -- the later occurrence replaces the earlier one, silently. So
./mfc.sh run case.py --dry-run -t pre_process -t simulation ...
generates a batch script containing only simulation. The intended form is -t pre_process simulation.
Why it is worth a warning
The failure is quiet and lands far from its cause. In my case the generated MFC.sh ran simulation against an empty restart_data/, so the job was queued and would have spent 8 nodes on a case with no initial condition. Nothing in the toolchain output said a target had been dropped; the script simply had one fewer srun line than expected, which is not something you notice unless you go looking.
It is an easy mistake to make because repeating a flag appends in many CLIs, and because -t simulation alone is a completely legitimate invocation (restarting from existing data), so there is no downstream check that can distinguish "the user meant only simulation" from "the user's first -t was thrown away".
Suggested fix
Either warn when -t appears more than once, or use action="extend" so repeats accumulate. A warning is the smaller change and preserves current behaviour for anyone relying on it.
Found with Claude Code.
https://claude.ai/code/session_01HMJ7cycfo7kTFSFq5yhHLG
What happens
-tis declared withnargs="+", so it takes a space-separated list:Repeating the flag does not append -- the later occurrence replaces the earlier one, silently. So
generates a batch script containing only
simulation. The intended form is-t pre_process simulation.Why it is worth a warning
The failure is quiet and lands far from its cause. In my case the generated
MFC.shransimulationagainst an emptyrestart_data/, so the job was queued and would have spent 8 nodes on a case with no initial condition. Nothing in the toolchain output said a target had been dropped; the script simply had one fewersrunline than expected, which is not something you notice unless you go looking.It is an easy mistake to make because repeating a flag appends in many CLIs, and because
-t simulationalone is a completely legitimate invocation (restarting from existing data), so there is no downstream check that can distinguish "the user meant only simulation" from "the user's first-twas thrown away".Suggested fix
Either warn when
-tappears more than once, or useaction="extend"so repeats accumulate. A warning is the smaller change and preserves current behaviour for anyone relying on it.Found with Claude Code.
https://claude.ai/code/session_01HMJ7cycfo7kTFSFq5yhHLG