default `flux_albav` value TRUE/FALSE? about blom HOT 8 OPEN

I extended the test runs with flux_albav=true/false to 10 years and ran the diagnostics. There are quite significant differences between the runs, particulary at mid-latitudes.

The naming is a bit silly, since I didn't plan to do this from the start.

• NOINYOC_T62_tn14_noresm_develop_v7-master_1y_20230807T1210 :
  CPL_ALBAV: FALSE
  • This is the new default setting
• NOINYOC_T62_tn14_noresm_develop_v7-master_1y_20230811T1348 :
  CPL_ALBAV: TRUE
  • This is the old default setting

Diagnostics show 20230807T1210 - 20230811T1348 run (i.e. new default - old default)

Diagnostics are here:
https://ns2980k.web.sigma2.no/tomast/diagnostics/NOINYOC_T62_tn14_noresm_develop_v7-master_1y_20230807T1210/

Integrated primary production plot:
https://ns2980k.web.sigma2.no/tomast/diagnostics/NOINYOC_T62_tn14_noresm_develop_v7-master_1y_20230807T1210/HAMOCC_DIAG/yrs1to10-NOINYOC_T62_tn14_noresm_develop_v7-master_1y_20230811T1348/set2/set2_ann_ppint_2models.png

from blom.

From Mats:

In MakingWaves we did a JRA forced cycle using development tag noresm_develop_v6 with CPL_ALBAV = FALSE. The diagnostics of the last 20 years of the first cycle is here:

https://ns2345k.web.sigma2.no/diagnostics/noresm/aal069/AA_NOIIAJRA20TR_TL319_tn14_20230630/BLOM_DIAG/yrs42to61-obs/indexnew.html

Diagnostics of a similar simulation with NorESM2.0.6 and CPL_ALBAV = TRUE is here:

http://ns9560k.web.sigma2.no/diagnostics/noresm/matsbn/NOIIAJRAOC20TR_TL319_tn14_20230624/BLOM_DIAG/yrs1694to1713-obs/indexnew.html

The difference is here:

https://ns2345k.web.sigma2.no/diagnostics/noresm/matsbn/AA_NOIIAJRA20TR_TL319_tn14_20230630/BLOM_DIAG/yrs42to61-NOIIAJRAOC20TR_TL319_tn14_20230624/indexnew.html

Note that there is a year range mismatch, but the forcing period and time since initial conditions should be the same. These simulations uses hybrid BLOM. Comparing these simulations, the SST difference seems much smaller compared to what you found, Tomas. I do not have anything similar at hand comparing the impact with CORE2 interannual forcing. Maybe there is something with normal year vs interannual forcing that for some reason gives stronger sensitivity to the albedo averaging choice? Anyway, this should be checked further.

To my knowledge, there was no particular thoughts earlier about what setting to use for CPL_ALBAV. I think we just used what was default option from NCAR.

from blom.

Further test with NorESM2.0.6:

NOINYOC_T62_tn21:

• Similar response as with NOINYOC_T62_tn14, although not quite so strong reduction in PP.
  https://ns2980k.web.sigma2.no/tomast/diagnostics/NOINYOC_T62_tn21_noresm2.0.6_10y_NOfluxalbav_20230903T1644/

NOIIAJRAOC_TL319_tn14:

• Similar response as NOIIAJRAOC20TR.
  https://ns2980k.web.sigma2.no/tomast/diagnostics/NOIIAJRAOC_TL319_tn14_noresm2.0.6_10y_NOfluxalbav_20230904T0910/

So far it seems that this is a problem mainly for the NOINY/NOINYOC compset. Maybe we should have flux_albav = .true. as default for these compsets only?

from blom.

I think that it makes sense given the hourly coupling to always have the flux_albav=.true. - since you have the ability to impose a diurnal cycle of albedos given the hourly coupling. That is the default for CESM at this point. Does that make sense? Thoughts?

from blom.

Dear @TomasTorsvik, @JorgSchwinger , @mvertens, my first -maybe naive- thought on it that I would be hesitant to use different parameter sets/default flags in the NOINY simulations for this than in coupled simulations, since we may want to use the NOINY runs as initial spinup for ocean bgc (from there introducing it into coupled simulations for further spinup) - but correct me, if I am wrong. - I see the problem while not having an immediate solution at hand.

from blom.

Hi all,
I think we need to understand why it produces so different results for the two compsets.

To be clear: The results for NOINYOC_T62_tn21 (and similar for NOINYOC_T62_tn14) are rubbish from the HAMOCC perspective (but also huge SST biases are introduced). I would oppose making this the default as long as we don't understand what happens.

For NOIIAJRAOC_TL319_tn14 everything looks fine, here the differences with flx_albav=true/false look reasonably small.

Tomas, are you 100% sure that the flx_albav setting is the only difference for the two NOINYOC_T62_tn21 cases?

I'm sorry, I'm packed with project meetings and other stuff the next weeks, so I can't test this myself right now.

from blom.

@JorgSchwinger - your suggestion makes total sense. I think the reason for the difference is the forcing files for swdn.
If you look at /cluster/shared/noresm/inputdata/ocn/jra55/v1.3_noleap/JRA.v1.3.swdn.TL319.1958.171019.nc you will see that there is already a zenith angle dependence in the swdn.
However, if you look at /cluster/shared/noresm/inputdata/atm/datm7/NYF/nyf.giss.T62.051007.nc you will see no such pattern. So if you impose a zenith angle function on the latter you will see huge differences - as you are seeing.
Let me know if you agree.

from blom.

Thank you @mvertens for pointing this out - now it makes sense.

Then we should make the setting of flux_albav dependent on the compset. For all NOINY(OC), but also all NOIIAN(OC) compsets it should stay at flux_albav=true, whereas for everything(?) else it could be changed.

from blom.