You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
revisit default auto-submit behavior [was: logs are sometimes moved] #23
Thanks for the feedback. It's worth documenting the design intent rather than leaving it implicit.
The auto-submit is intentional rather than just the default setting. The WFE is constructed as a sequence of tasks: pre -> sim -> pos -> vis. These are submitted with dependencies scheduled, and for numsimstep > 1, each chunk's sim job is dependent on the previous one (afterok:${sim_id}). control_tsmp2.sh is responsible for submitting, as it captures the job IDs from which these dependencies are derived. Submitting manually bypasses the chain and the restart bookkeeping associated with it.
The second reason is reproducibility. The run directory is not an input; everything that defines a simulation lives in ctl/*.conf and nml/, and sim_config.sh regenerates the run directory from these files every time it is invoked. It moves an existing run directory aside to <sim_dir>_bku. Therefore, any edits made directly in the run directory will not be picked up by the following chunk, meaning that a result produced in this way could not be reproduced from the configuration alone. Anything that needs changing belongs in the parent layer.
Inspecting before submitting is already supported. This is precisely the purpose of debugmode=true, and I would prefer to refer to it as the supported approach rather than a workaround. The intended sequence is therefore exactly the one you describe: configure; inspect the run directory; then sbatch tsmp2.job. It is worth knowing that this submits a single chunk without the afterok dependency, which is fine for a one-off test, but not how a multi-chunk production run should be launched.
Activity
mvhulten commentedon Mar 18, 2026
This happened when I killed a job.
It is clear why it happens, but the fact that in
$wfe_dir/ctl/logs/stay exactly those logs is not intuitive. Users would be looking at old logs.s-poll commentedon Apr 13, 2026
Thank you for pointing this out and your understanding of the behavior is correct.
A clarification paragraph has been added to the documentation to make this more explicit in #28.
This behavior is intentional, but we agree that it is not immediately intuitive, and the documentation update is meant to help avoid confusion.
kvrigor commentedon Apr 16, 2026
Also surprising to me. Workaround is to set
debugmode=trueinmaster.conf:TSMP2_workflow-engine/ctl/master.conf
Lines 50 to 53 in e6c3fec
I'm also used to inspecting the
rundirectory before submitting the job myself. The default auto-submit behavior can be really annoying...[-]logs are sometimes moved[/-][+]revisit default auto-submit behavior [was: logs are sometimes moved][/+]s-poll commentedon Sep 6, 2026
Thanks for the feedback. It's worth documenting the design intent rather than leaving it implicit.
The auto-submit is intentional rather than just the default setting. The WFE is constructed as a sequence of tasks: pre -> sim -> pos -> vis. These are submitted with dependencies scheduled, and for numsimstep > 1, each chunk's sim job is dependent on the previous one (afterok:${sim_id}). control_tsmp2.sh is responsible for submitting, as it captures the job IDs from which these dependencies are derived. Submitting manually bypasses the chain and the restart bookkeeping associated with it.
The second reason is reproducibility. The run directory is not an input; everything that defines a simulation lives in ctl/*.conf and nml/, and sim_config.sh regenerates the run directory from these files every time it is invoked. It moves an existing run directory aside to <sim_dir>_bku. Therefore, any edits made directly in the run directory will not be picked up by the following chunk, meaning that a result produced in this way could not be reproduced from the configuration alone. Anything that needs changing belongs in the parent layer.
Inspecting before submitting is already supported. This is precisely the purpose of debugmode=true, and I would prefer to refer to it as the supported approach rather than a workaround. The intended sequence is therefore exactly the one you describe: configure; inspect the run directory; then sbatch tsmp2.job. It is worth knowing that this submits a single chunk without the afterok dependency, which is fine for a one-off test, but not how a multi-chunk production run should be launched.