Shortwave heat diagnostic problems

Hi all,
I am having an issue with the shortwave diagnostic output when running MOM5. I would like to save out the diagnostic:

sw_heat

This is a standard diagnostic that looks fine when running the ACCESS model. The problem is that in my GFDL CM2.1 simulations, I am using the namelist option:

use_shortwave_gfdl=.true.
use_shortwave_csiro=.false.

When I use the GFDL shortwave module, sw_heat diagnostic returns only zeros.
If I switch my GFDL simulation over to using the CSIRO shortwave module, then I get sensible looking output, like in the ACCESS model. The problem with doing that is that it makes a physical change to simulations that have been equilibrated for 5000 years already… hence I don’t want to just re-run the model with a different shortwave scheme.

The thing I am seeking help on:
If I look at lines 346 of the ocean_shortwave.F90 file

  call diagnose_3d(Time, Grd, id_sw_heat, Temp%wrk1(:,:,:))

This diagnostic call is written in a way that should not matter whether I am using the GFDL or the CSIRO shortwave modules. The modules themselves are called on Lines 294-297:

  if(use_shortwave_gfdl) then 
     call sw_source_gfdl (Time, Thickness, T_diag(:), swflx, swflx_vis, index_irr, Temp, sw_frac_zt, opacity)
  elseif(use_shortwave_csiro) then 
     call sw_source_csiro (Time, Thickness, T_diag(:), swflx, index_irr, Temp, sw_frac_zt)

Both should modify the Temp%wrk1(:,:,:) field, hence the diagnostic should work either way. But it doesn’t!! It comes back with zeros when using the GFDL scheme.

Can anyone please help me figure out why this is happening?

Thanks,
Dave

1 Like

Hi @dkhutch

I have tagged your post with help so that it is correctly triaged. As it happens I am also on triage today, so I’ve also tagged it as inscope, as this is something ACCESS-NRI supports, so someone will assign themselves to the topic and work through to a resolution.

Just to check the source code is correct, can you provide the suite id you’re running so we can check what version of the code is being used?

Thanks Aidan. Gadi on maintenance today so will update with the simulation information tomorrow.

1 Like

Hi David

My guess would be that there is only one shortwave flux field being coupled from oasis.

i.e. the swflux field contains the vis and infrared incoming shortwave radiation, and the swflx_vis is empty

Is there diagnostic output for the swflx_vis field ?

In the CICE driver, (which interfaces between the atmosphere and the ocean), there is only one swflx field from the UM:

and to the ocean:

There is reference in https://www.publish.csiro.au/es/pdf/ES19040 to running with the GFDL scheme, so it should be possible I guess.

Possibly @MartinDix has ideas?

Thanks Anton. That’s interesting to know that there is an ACCESS-CM2 version that did in fact use the GFDL SW radiation scheme. I saw in the Bi et al (2020) paper that you referenced that the job name: bb039 was using that scheme. If I could compare to a version where the GFDL shortwave scheme is returning sensible diagnostics for sw_heat that would be interesting.

I will get a diagnostic output for the swflx_vis field to compare with swflx.

To reiterate: my use case that is not working properly is for the GFDL CM2.1 model. It doesn’t use OASIS, but rather the FMS coupler and the GFDL SIS model. Nevertheless, I can get diagnostics for swflx that are coming from the ice model.

Thanks David - sorry we misunderstood about the model in use!

I think you will only get one swflx term into the ocean as output the ice_model (assuming Delta Eddington radiation scheme in SIS), but there should be seperate visible and infrared terms from the atmosphere ? I don’t understand how the two would get combined in cell with a mixture of sea-ice and ocean at the surface though

Yep no worries. Any idea where to find output from the bb039 run from Bi et al (2020)? @dhb599

P.S. I see it’s no longer in scope (understandable!) but still if anyone knows anything about the GFDL shortwave scheme and how to get diagnostic output from it, please shout.

1 Like

Yes, sorry about that.

You were quite clear @dkhutch. it is my fault. I saw “CM2” and didn’t read carefully enough.

@MartinDix or @sofarrell may be able to help with the location of the data.

Hi @Dave its a long time since we were running just MOM5 with these two shortwave options, and switching on diagnostics @dhb599 might remember if we ran into such problems or @russfiedler may not be regularly on the Hive. I don’t have any memory of it, occuring. But we must be getting diagnostics for the gfdl scheme in the output for the current CM2 model runs, I will dig more into it when I am back on gadi.

2 Likes