nudge-to-fine workflow not updating SSTs

[brianhenn]

The nudging runs are supposed to update coarse-model SSTs with the reference state but the N2F workflow in the sklearn_runfile is missing the actual state update call after it gets the reference SSTs:

https://github.com/VulcanClimateModeling/fv3net/blob/f646892b3c7fc752efadae9d70df94a45e512489/workflows/prognostic_c48_run/runtime/steppers/nudging.py#L89

[AnnaKwa]

@spencerkclark Does the sst_perturbation flag just act at the initialization of the run to add/subtract from the unperturbed SST and then the rest of the simulation just uses that fixed SST (in the current case where it's not set to the reference)? Just checking since my understanding, if we actually do set the SST to the reference, then is it correct that the sst_perturbation doesn't do anything in those nudging runs?

[spencerkclark]

Does the sst_perturbation flag just act at the initialization of the run to add/subtract from the unperturbed SST and then the rest of the simulation just uses that fixed SST (in the current case where it's not set to the reference)?

It normally will act throughout the run; basically what it does is add an offset to the climatological SST the model is relaxed to by default.

Just checking since my understanding, if we actually do set the SST to the reference, then is it correct that the sst_perturbation doesn't do anything in those nudging runs?

Exactly, if the surface temperature is set through the wrapper, indeed the sst_perturbation parameter should have no effect. The wrapper should override whatever the SST is set to in the fortran model; part of me wonders though whether we should verify this is still true since ai2cm/fv3gfs-fortran#93 was merged.

[spencerkclark]

The wrapper should override whatever the SST is set to in the fortran model; part of me wonders though whether we should verify this is still true since ai2cm/fv3gfs-fortran#93 was merged.

My suspicion here was correct. I have verified this with a test in the Python wrapper. Similar to the surface radiative fluxes, I think we will need to use a payload + namelist flag approach to setting this from Python.

Edit: actually in this case I think a namelist flag alone approach would do (i.e. just have a flag to restore the fortran behavior prior to ai2cm/fv3gfs-fortran#93 if we are prescribing SSTs).

[spencerkclark]

This notebook illustrates that when completing a nudged run with the namelist flag added in ai2cm/fv3gfs-fortran#173, that the SSTs are indeed modified when compared with a case without the namelist flag active. No changes to fv3net beyond updating submodules will be needed. Care will be needed to update configs for nudging runs; in those we should set the flag gfs_physics_nml.use_climatological_sst to .false..

[brianhenn]

So what were the differences in the notebook above from if they weren't from the nudging runs setting the SSTs?

[spencerkclark]

It's a little subtle. If we do not set the SST via the wrapper, but use Sfcprop%tsfco as the sea surface temperature in the fortran, it stays set at its initial condition value. In the default case, where we use Sfcprop%tsfc as the sea surface temperature in the fortran, it starts to follow the climatology. So after two days, we can see a difference appearing.

[brianhenn]

Thanks that makes sense.

[spencerkclark]

#1101 adds the fix required to fv3net to take advantage of this. Note per discussion with @mcgibbon I have modified the relevant namelist parameter in the fortran model. It is now called gfs_physics_nml.use_climatological_sst and by default is set to .true.. We must set it to .false. to enable overriding it in nudged runs.