Model uses constant SST, different from SST forcing file

[oliverwm1]

The output surface temperature (tsfc) over ocean is constant in time, despite using RTGSST.1982.2012.monthly.clim.grb which depends on month. Is this expected behavior? When doing the same run with the previous public release source code, the surface temperature over the ocean tracks much closer to the SST forcing file, as I would expect.

The figure below plots the monthly-mean tsfc (left panel) and t2m (right panel). Output is shown from a run with the source code of this repo (fv3atm) and the previous public release (fv3gfs). Data from the SST forcing file is also shown for the surface temperature plot.

Possibly related: I notice in the code, tsfc is described as the surface air temperature in a comment. Is that accurate?

Thanks for any guidance you can provide!

[junwang-noaa]

It depends on how the model is configured. Can you check what the "FHCYC" in your model namelist is set with?

[oliverwm1]

Thanks for the response! fhcyc is set to 24.0. You can find the complete namelist I used for the simulation above here.

[spencerkclark]

@junwang-noaa have you had a chance to investigate this further? Are there settings we are missing and/or does this issue exist with the current version of fv3atm?

In our fork -- which is a little behind the latest version here -- adding the following above these lines appears to fix things:

          if (islmsk(i) == 0) then
            Sfcprop%tsfco(i) = Sfcprop%tsfc(i)
            wet(i)  = .true.
            fice(i) = zero

As far as I can tell, without it, over ocean grid cells tsfco remains at its value from the initial condition throughout the entire simulation. This change allows it to be updated as tsfc is relaxed to the climatological SST over ocean. Could this be the correct solution, or is there a reason it was originally commented out and eventually removed altogether?

[junwang-noaa]

Sorry, I have not gotten time to check this. I just checked your code changes, it makes sense to me. What I see is that the if statement should be added to pass the updated tsfc on ocean points from gcycle to tsfc3 in gfs physics driver. I may need to double check with our physics experts.

…

On Fri, Oct 16, 2020 at 12:18 PM Spencer Clark ***@***.***> wrote: @junwang-noaa <https://github.com/junwang-noaa> have you had a chance to investigate this further? Are there settings we are missing and/or does this issue exist with the current version of fv3atm? In our fork -- which is a little behind the latest version here -- adding the following above these lines <https://github.com/NOAA-EMC/fv3atm/blob/90bc1a4d6b660b5497c36dc009e1624f9982a2b1/gfsphysics/GFS_layer/GFS_physics_driver.F90#L1159-L1163> appears to fix things: if (islmsk(i) == 0) then Sfcprop%tsfco(i) = Sfcprop%tsfc(i) wet(i) = .true. fice(i) = zero As far as I can tell, without it, over ocean grid cells tsfco remains at its value from the initial condition throughout the entire simulation. This change allows it to be updated as tsfc is relaxed to the climatological SST over ocean. Could this be the correct solution, or is there a reason it was originally commented out and eventually removed altogether? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#79 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI7D6TKFOSBMRRLLSSWCSATSLBW6TANCNFSM4LGQJ7IA> .

[spencerkclark]

Indeed I think another way to fix this would be to switch tsfco to tsfc here:

fv3atm/gfsphysics/GFS_layer/GFS_physics_driver.F90

Line 1242 in 90bc1a4

tsfc3(i,3) = Sfcprop%tsfco(i)

Keep us posted on what you think / what the physics experts say. Thanks again for your help!

[junwang-noaa]

The sst issue appears fixed in the latest develop branch. Here is what I get from the fv3 control run. The point is (179W, 45N)

[junwang-noaa]

[junwang-noaa]

Close the issue.

[spencerkclark]

Excellent, thanks @junwang-noaa! Would you happen to know the particular commit (or change) that fixed this?

[junwang-noaa]

I did not track the issue with each commit, but I think it is the FV3 PR#155 <#155> and PR #204 <#204>.

…

On Fri, Mar 5, 2021 at 2:51 PM Spencer Clark ***@***.***> wrote: Excellent, thanks @junwang-noaa <https://github.com/junwang-noaa>! Would you happen to know the particular commit (or change) that fixed this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#79 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI7D6TPKPNEQ77NR5ENB6PTTCEY2PANCNFSM4LGQJ7IA> .

[oliverwm1]

Thanks @junwang-noaa!