Repository navigation
Implement and generalize design-driven config writer for OAT and ensemble runs #4215
Description
Description
#4066 made OAT and ensemble runs use write.ensemble.configs(). OAT parameter values are still prepared in run.write.configs(), and the workflow functions still have separate OAT and ensemble setup. Complete the shared path while retaining the outputs current SA post-processing needs.
Proposed Solution
Prepare one set of parameter values per OAT run during design generation, including the median run and each one-trait quantile change. Have the config-writing functions consume those prepared values and share the setup that is common to OAT and ordinary ensembles. Keep the OAT-specific run identities and downstream lookup data.
Preserve run IDs and outputs currently required by downstream SA code during this refactor, without adding new reliance on .Rdata files.
Test written parameter values, run IDs, and manifest rows for OAT and ordinary ensembles, including a multisite case.
Key files
modules/uncertainty/R/generate_OAT_SA_design.R: return per-run OAT parameter values with the labeled design.base/workflow/R/runModule.run.write.configs.R: consolidate shared OAT and ensemble setup while preserving multisite behavior.base/workflow/R/run.write.configs.R: consume prepared OAT values and reduce duplicate writer setup; retain SA-specific outputs needed downstream.
Additional Context
The Sobol parameter-row bug discussed in #4185 is separate. #4096 addresses reading the shared median run’s output; #4136 addresses extra OAT runs at multisite locations. #3692 tracks the run manifest, and #3882 tracks the median lookup bug.
Refactoring SA post-processing to stop reading .Rdata files is separate work.
Activity
S1DDHEY commentedon Oct 30, 2026
Hi @dlebauer, I’d like to work on this issue. I’ve recently been reviewing the design-driven
run.write.configs()changes from #4185 , so I have some context on the OAT/ensemble paths involved.Could you please assign this issue to me? I’ll first map the current OAT and ensemble flows and share a proposed implementation approach before making the refactor.
dlebauer commentedon Oct 30, 2026
@S1DDHEY Thanks for your interest - that would be great! Conceptually I think it is straightforward, though I'd like to see if @mdietze has further input.
mdietze commentedon Oct 30, 2026
A few comments
I disagree, I believe this should be handled in the OAT design generation function, not within run.write.configs
Maybe in the short term, but the thrust of how Om was refactoring the workflow was to get away from reliance on Rdata objects and instead pass data structures directly into and out of functions. What he didn't get to was refactoring the SA post-processing in this way, but that needs to be its own Issue. I think once that post-processing is refactored we should revisit what run.write.config actually needs to return -- I suspect its only a subset of what's currently being saved and, as noted above, a good bit of that might be better generated at the design stage and saved in the design object.
S1DDHEY commentedon Oct 31, 2026
Thanks for your input @mdietze . My understanding is:
run.write.configs()will focus on writing configs from an already prepared design..Rdataobjects (which follows direction established in this year's GSoC project for Modularity), since refactoring SA post-processing can be handled in a follow-up issue.LMK if there's something to be changed in this approach.
dlebauer commentedon Nov 2, 2026
@S1DDHEY @mdietze thanks for the clarification. I’ve updated the issue to reflect the feedback. I have assigned this to you.