Add coupled (FV3JEDI + SOCA) JCB templates

[shlyaeva]

Description

Assemble coupled atmosphere + ocean JEDI YAMLs from the existing single-component JCB fragments, rather than maintaining hand-written coupled YAMLs. Coupled hofx3d and 3dvar are supported.

New coupled algorithm wrappers (parm/jcb-gdas/algorithm/coupled/) loop over a coupled_components list and, for each component, emit its YAML key and include that component's existing model fragment unchanged:

• coupled_geometry_background.yaml.j2 - per-component geometry, plus the FV3JEDI exclude variables list.
• coupled_background.yaml.j2 - per-component background/state (used for the variational background and the hofx state).
• coupled_background_error.yaml.j2 - a Coupled Block Diagonal covariance with one block per component.
• coupled_3dvar_outer_loop_1.yaml.j2 - a single shared-geometry outer loop.

These wrappers live in algorithm/coupled/ (not model/) so they are exempt from the model-directory naming/variable constraints, and they reuse the stock jcb-algorithms hofx3d/3dvar templates via section-file overrides and model_component: coupled_.

New client integration config gdas-coupled-templates.yaml exercises both algorithms with one atmosphere observer (conventional_ps) and one marine observer (adt_rads_all). It uses the renderer's app_paths_model_extra / app_paths_observations_extra hooks to span both components.

Requires the matching jcb renderer support (NOAA-EMC/jcb#45).

Companion PRs

NOAA-EMC/jcb#46

Automated CI tests to run in Global Workflow

• atm_jjob
• C96C48_ufs_hybatmDA
• C96C48_hybatmsnowDA
• C96_gcafs_cycled
• C48mx500_3DVarAOWCDA
• C48mx500_hybAOWCDA
• C96C48_ufsgsi_hybatmDA
• C48_ufsenkf_atmDA
• C96C48_hybatmDA

[DavidNew-NOAA]

these templates should be in the model directory, not algorithm

[DavidNew-NOAA]

Sorry, disregard my previous comment, I don't read PR descriptions. Let me study more carefully.

[DavidNew-NOAA]

I'm still hung up on the model templates being in the algorithm directory. If there are model-directory naming/variable constraints, then we should find a way to adapt or relax them in JCB for something like the coupled case.

[shlyaeva]

@DavidNew-NOAA do you have a suggestion? I don't know enough about jcb to make an intelligent choice, but happy to change (have claude change) this. Let me know if it's easier to discuss on a call.

[DavidNew-NOAA]

@shlyaeva I don't have an immediate suggestion, because I don't know exactly how JCB enforces these constraints, but I can look into it.

[DavidNew-NOAA]

@shlyaeva I think you could take this line:

https://github.com/NOAA-EMC/jcb/blob/1a777fdfd99fe69dc64627f7e6a83c851eb61e53/test/client_integration/test_client_requirements.py#L95

And change it to something like

assert key.split('_')[0] in app_model_components

to enforce that the keys are prefixed with valid model component names but not necessarily one component's name

[shlyaeva]

@DavidNew-NOAA I've moved them to model/coupled; what do you think of the current version?

[DavidNew-NOAA]

@shlyaeva So I see you didn't need to make any changes to JCB like I suggested and the client integration testing still passed?

[DavidNew-NOAA]

No further objections

[shlyaeva]

@DavidNew-NOAA yes! great, thank you!

[shlyaeva]

I've merged jcb PR, and updated the jcb hash here. @DavidNew-NOAA do you mind re-reviewing and @AndrewEichmann-NOAA or @guillaumevernieres do you mind providing a second review?

[AndrewEichmann-NOAA]

No complaints, but I'm not familiar with what to expect

[shlyaeva]

@DavidNew-NOAA I did need an additional change in jcb for the tests to pass. I tagged you on a PR there.