write.config.* functions duplicate job.sh setup logic — candidate for shared helper

[Anurag-M1]

While exploring write.config.BASGRA and write.config.SIPNET as part of
my interest in Project 4 (Standardizing Model Couplers) for GSoC 2026, I
noticed both functions contain identical blocks for:

1. Loading the job template (template.job)
2. Building hostsetup from settings$model$prerun and settings$host$prerun
3. Building hostteardown from settings$model$postrun and settings$host$postrun
4. Applying common substitutions into job.sh:
   • @HOST_SETUP@, @HOST_TEARDOWN@
   • @SITE_LAT@, @SITE_LON@
   • @START_DATE@, @END_DATE@
   • @OUTDIR@, @RUNDIR@

These could be extracted into a shared helper function (e.g. build_job_sh())
in a common location, reducing duplication and making it easier to add new
models consistently.

Is this a good direction to pursue? Happy to start with a draft implementation
if the team thinks this is worth addressing.

[mdietze]

I think every model in PEcAn uses a job.sh. It's definitely worth looking at refactoring across models to see if there are bits of shared code that can be put into functions, but it's also important to note that no two models structure their inputs in exactly the same way, nor take in the exact same inputs, and we don't want to lock in users to specific assumptions that may exclude certain model types (e.g., most models have dedicated files for things like parameters and initial conditions but the version of DALEC we're working with takes every single input as a command-line argument)

[Anurag-M1]

Thanks @mdietze! That's really helpful context. The goal wouldn't be to force a single rigid interface, but rather to extract the parts that are genuinely identical across models — specifically the hostsetup/hostteardown construction and the common @HOST_SETUP@, @SITE_LAT@, @START_DATE@ etc. substitutions into job.sh, which appear word-for-word in at least BASGRA and SIPNET.
The idea would be a lightweight helper that handles just these shared substitutions, while leaving each model free to handle its own model-specific inputs (parameters, ICs, command-line args like DALEC) independently.
Would it make sense to first survey how many models share these exact patterns before proposing an implementation? I can go through the models/ directory and produce an inventory.

[KrupaShah20]

Hi sir, I’d like to work on this issue. It aligns well with my GSoC project focus on reducing duplicated coupler logic and extracting shared helpers. I’ll start by reviewing the current write.config.* implementations and identifying the repeated job.sh setup logic.