default flux_albav value TRUE/FALSE?

[TomasTorsvik]

What default value do we actually want to have for flux_albav moving forwards - given that by default we are now coupling BLOM at an hourly frequency?

---

In cmeps we have by default.
flux_albav = .false.
and in cpl7 we have by default
flux_albav = .true.

Note that to change the value in cmeps you need to do it via an xml variable:
./xmlchange CPL_ALBAV=TRUE

What flux_albav does in the mediator is set the values of the albedo to constant values.
It was decided in CESM that if the ocean coupling would be hourly - then we should set flux_albav to .false. by default.

  if (flux_albav) then
      do n = 1,lsize
         ocnalb%anidr(n) = albdir
         ocnalb%avsdr(n) = albdir
         ocnalb%anidf(n) = albdif
         ocnalb%avsdf(n) = albdif
      end do
   else
      ! Solar declination
      ! Will only do albedo calculation if nextsw_cday is not -1.

      if (nextsw_cday >= -0.5_r8) then
         call shr_orb_decl(nextsw_cday, eccen, mvelpp,lambm0, obliqr, delta, eccf)

         ! Compute albedos
         do n = 1,lsize
            rlat = const_deg2rad * ocnalb%lats(n)
            rlon = const_deg2rad * ocnalb%lons(n)
            cosz = shr_orb_cosz( nextsw_cday, rlat, rlon, delta )
            if (cosz  >  0.0_r8) then !--- sun hit --
               ocnalb%anidr(n) = (.026_r8/(cosz**1.7_r8 + 0.065_r8)) +   &
                                 (.150_r8*(cosz         - 0.100_r8 ) *   &
                                 (cosz - 0.500_r8 ) * (cosz - 1.000_r8 )  )
               ocnalb%avsdr(n) = ocnalb%anidr(n)
               ocnalb%anidf(n) = albdif
               ocnalb%avsdf(n) = albdif
            else !--- dark side of earth ---
               ocnalb%anidr(n) = 1.0_r8
               ocnalb%avsdr(n) = 1.0_r8
               ocnalb%anidf(n) = 1.0_r8
               ocnalb%avsdf(n) = 1.0_r8
            end if
         end do
         update_alb = .true.

      endif    ! nextsw_cday
   end if   ! flux_albav

Using the code in this PR to do my comparison, I set flux_albav = .true. in the CMEPS run and the results look very similar to the cpl7 run.

@TomasTorsvik - can you please make this change in your nuopc run and try doing the yearly run again. Things should look okay.
@TomasTorsvik @matsbn @JorgSchwinger @jmaerz - what default value do we actually want to have for flux_albav moving forwards - given that by default we are now coupling BLOM at an hourly frequency.

Originally posted by @mvertens in #263 (comment)

[TomasTorsvik]

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

[TomasTorsvik]

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.

[TomasTorsvik]

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?

[mvertens]

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?

[jmaerz]

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.

[JorgSchwinger]

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.

[mvertens]

@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.

[JorgSchwinger]

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.