Fix .silol.series generation

[wilfonba]

This PR moves the generation of the .silo.series file before the failure message in MFC.sh. If post process failed, then the silo series file wouldn't be generated. I'm not sure how this got reordered, because I thought I'd done the correct ordering when I first merged this. Git blame shows that I just did it wrong though.

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

This PR fixes the ordering of .silo.series generation so it happens before the post-process failure path in MFC.sh, ensuring the series file is still produced when post-processing fails.

Changes:

• Move the generate_silo_series.py invocation earlier in the post_process target block.
• Ensure .silo.series generation occurs before the $code == 22 early-exit error message.

[github-actions]

Claude Code Review

Head SHA: 93497a9

Files changed:

• 1
• toolchain/templates/include/helpers.mako

Findings

generate_silo_series.py now runs even when post_process fails

The move places the generate_silo_series.py call before the if [ $code -ne 0 ] guard that previously protected it. In the original code, the script only ran after both error checks ($code -eq 22 and $code -ne 0 ... exit 1), meaning it was effectively run-on-success-only. After this change, the silo series script is invoked regardless of whether post_process succeeded or failed.

On a failed post_process run, calling generate_silo_series.py against incomplete or missing output files may itself error or silently produce a corrupt/empty .visit series file. The overall exit behavior is unchanged (MFC still exits 1 on $code -ne 0), but the unnecessary script call runs and its own exit code is discarded.

If the intent is to generate a partial series on failure (e.g., for debugging), this should be explicit. Otherwise the call should remain after the if [ $code -ne 0 ]; then ... exit 1; fi block, as it was before.

[sbryngelson]

@wilfonba, what do you think of the Claude review above?

[sbryngelson]

Reorder looks right — moving the .silo.series generation ahead of the code -eq 22 / failure-exit blocks ensures it actually runs. One thing I checked that's reassuring: code=$? is captured at line 86, before this python call, so even if generate_silo_series.py errors it won't clobber the real post_process exit status used by the checks below. Minor inline note.

[sbryngelson]

Non-blocking: this now runs unconditionally (for post_process) even when post_process actually failed — i.e. it may execute generate_silo_series.py over missing or partial silo output. Since code is already captured above, it won't mask the real error, but worth confirming generate_silo_series.py degrades gracefully (no silo files / incomplete set) rather than dumping a traceback. If you'd rather only generate on success, gating this on [ $code -eq 0 ] would do it — though I suspect you want it to run on the spurious-failure case, which is the whole point of the PR.

[wilfonba]

generate_silo_series.py reads the list of files present in the root directory when it is called, so it should never fail if files exist in the root directory. I don't know what it would do if there were no files in the root directory. I'll have to check the actual script when I'm on the right computer.

[wilfonba]

@sbryngelson I tried stress testing this by adding a rm -rf silo_hdf5 in the MFC.sh file before the call to generate_silo_series.py and it fails gracefully. There's an

if not collection_files:
	return

that does an early return if no files are present. This should be fine to merge.