[RussTreadon-NOAA]

This PR contains the changes to 3d variational templates required when oops PR #3374 and its build group are merged into GDASApp develop

[RussTreadon-NOAA]

Keep as draft until ready to merge. Required GDASApp changes will enter GDASApp develop via feature/stable-nightly.

Plan is to

1. update JEDI submodule hashes in working copy of GDASApp feature/stable-nightly
2. update working copy of GDASApp feature/stable-nightly with required parm updates
3. test feature/new_output_yaml in working copy of GDASApp feature/stable-nightly
4. assuming ctests pass in 3, change this PR to Open. Get approval and merge into develop
5. update parm/jcb-algorithms hash in GDASApp feature/stable-nightly
6. commit all changes in working copy of GDASApp feature/stable-nightly. Push to github.
7. merge GDASApp feature/stable-nightly into GDASApp develop

[RussTreadon-NOAA]

GDASApp PR #2312 tested the changes in this PR via GDASApp CI on Gaea C6, Hera, Hercules, Orion, Ursa, and WCOSS2 (Cactus). All ctests Passed on each machine.

This PR is ready for review.

[Copilot]

🟡 Changes recommended

Two unresolved moderate findings show the template restructuring can silently drop diagnostics.departures for departures-only configurations that lack analysis or increment output.

2 open issues

• Drop departures-only diagnostics when no output file is set · New
• Drop departures-only diagnostics when no output file is set · New

What changed in this PR

This PR restructures the final output: section of the two 3D variational algorithm templates (3dvar.yaml.j2 and 3dfgat.yaml.j2) to match the new output schema introduced by JCSDA-internal oops PR #3374. The previous layout split outputs across a final: block (diagnostics, increment to structured grid, analysis to structured grid, increment) plus a separate top-level output: key for the analysis. The new layout consolidates everything into a single output: section containing diagnostics, analysis, and increment, where analysis/increment are emitted as a two-item list when both a native and a lat/lon writer are configured, as a single mapping when only one is configured, and the whole section collapses to {} when no output is requested.

Changes:

• Consolidated the old final: block and top-level output: key into one unified output: section.
• Introduced has_analysis_output/has_increment_output flags and conditional logic to emit analysis/increment as either a list (both writers) or a single mapping (one writer), or {} when nothing is requested.
• Switched included files to inline {% include name + '.yaml.j2' %} instead of reassigning the variable first.

File	Description
3dvar.yaml.j2	Rewrites the final output section into the new unified output: schema (diagnostics/analysis/increment with list-or-mapping handling).
3dfgat.yaml.j2	Applies the identical output-section restructuring for the 3D-FGAT template.

Notes for the author: The restructuring is internally consistent between the two files and produces valid YAML in every branch I traced. My one substantive observation is that diagnostics.departures is now only emitted when an analysis or increment output is also configured, whereas it was previously always written — see the inline comments if departures-only output is a supported use case. Because the exact expected shape (list vs. single mapping for analysis/increment, and diagnostics gating) is defined by the unmerged oops PR #3374, final confirmation that these templates match that schema is best done by a maintainer familiar with that change; the template rendering itself is exercised by the integration tests in the separate NOAA-EMC/jcb repo rather than here.

_{Review effort: Balanced}

[RussTreadon-NOAA]

@CoryMartin-NOAA and @ADCollard : What do you think about Copilot's finding and suggestion. Is the case Copilot identified a configuration we plan on running? It seems like a plausible configuration to me but I don't know what we have in mind for JEDI monitoring.

[CoryMartin-NOAA]

I found it's explanation a bit confusing (must be my Monday AM brain) but I think it's not an issue. This is 3DVar or 3DFGAT, we wouldn't run departures only in this config I wouldn't think. That would be for the hofx case.

[RussTreadon-NOAA]

Valid point @CoryMartin-NOAA . The templates in question are for 3DVar. This implies generating an analysis or an increment.

[DavidNew-NOAA]

No objections

[RussTreadon-NOAA]

Thank you @CoryMartin-NOAA and @DavidNew-NOAA . Merging now.