Skip to content

doalb flag status explanation with CAM #3088

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
rgknox opened this issue Apr 24, 2025 · 3 comments
Open

doalb flag status explanation with CAM #3088

rgknox opened this issue Apr 24, 2025 · 3 comments

Comments

@rgknox
Copy link
Collaborator

rgknox commented Apr 24, 2025

I am working on some refactors with FATES and radiation scattering. However I have a knowledge gap related to the doalb flag, and generally, how CAM (and other atmospheric models) impose their needs on the land-model timestep.

From a FATES perspective, we want to perform normalized radiation scattering calculations in our vegetation canopies when the zenith angle is positive and non-zero, and also in-sync with calls to when CLM performs a land-energy balance (ie stuff in CanopyFluxesMod).

The land-energy balance (CanopyFluxesMod) is not blocked out by a doalb flag. So I would assume that if the zenith angle is positive, FATES should update radiation scattering (which it needs for photosynthesis) so that it can give canopyfluxes updated stomatal conductance.

On the FATES side, we have never discussed the need to perform radiation scattering or photosynthesis at temporal resolutions finer than the CLM model timestep, I don't believe that has changed.

At the beginning of a branch run, their is still some weirdness in the first model timesteps that I still don't understand. My solution there is to just initialize FATES abledo's to match the trivial assumption of CLM (thanks @mvdebolskiy) when doalb is not true, and also prevent updating diagnostics unless the FATES has been signalled to perform a normalized radiation scattering calculation (albedo). As I can tell, there is no current problem here, and we are passing tests.

So my question is, how does CAM influence all of this? Questions I don't know the answer to:

  1. When CAM is running (or not), do we ever have doalb = .false. and the coszen > 0 ? And if this is true, why and in what situations?
  2. I think it is safe to say the doalb flag is never true for coszen<=0

Locations of the doalb flag in main driver loop clm_driver:

  1. weighting veg interpolation,L262
  2. call to lai_advance(),L473
  3. fates satphen interp,L1055
  4. call bgc_vegetation_inst%EcosystemDynamicsPostDrainage,L1107
  5. the main normalized land radiation update,L1246

cc: @mvertens @mvdebolskiy

@mvertens
Copy link

@rgknox -
Quesiton: When CAM is running (or not), do we ever have doalb = .false. and the coszen > 0 ? And if this is true, why and in what situations?

the main normalized land radiation update,L1246
CAM only needs albedos when it does the radiation computation - which normally occurs every hour for short wave. Hence it needs to tell CTSM, CICE and the mediator the calendar day (nextsw_cday) when it will do the short wave computation and albedos are then return by CTSM, CICE and the mediator (for the ocean albedo) that will have been calculated with the coszen for that calendar day. Each of the components calculates the coszen given that the calendar day is. Note that in CTSM, SurfaceAlbedo is only called when doalb = .true. So, coszen will maintain that value even if doalb=.false.

[weighting veg interpolation,L262] and [call to lai_advance(),L473] and (https://github.com/ESCOMP/CTSM/blob/ctsm5.3.040/src/main/clm_driver.F90#L262-L266)
(https://github.com/ESCOMP/CTSM/blob/ctsm5.3.040/src/main/clm_driver.F90#L473-L475)
! need to update elai and esai only every albedo time step so do not
! have any inconsistency in lai and sai between SurfaceAlbedo calls (i.e.,
! if albedos are not done every time step).

Does this help? I'm happy to provide more clarifications or have a call.

@rgknox
Copy link
Collaborator Author

rgknox commented Apr 24, 2025

Thanks for the explanation @mvertens. I think this gives me enough information to work on my refactors.

My understanding is that the land-model (both fates and non-fates) would benefit in some situations from calculating the albedo (as well as the normalized soil and vegetation absorptions that come with it) on every time-step (ie 30 minutes or shorter), even coupled when coupled with the atmosphere model that provides boundary conditions not on every step. One issue is that the land-energy balance solver benefits from having smooth heating rates (from net radiation as well as photosynthesis), and there may be ecologically relevant FATES benefits to having radiation updates at shorter time-steps too.

I wonder if there are existing methods to run a zenith based interpolation on the downwelling direct and diffuse radiation forcing values that are generated by the atmosphere model so that we can calculate canopy and soil absorbed radiation on time-steps where it does not have an update by CAM.

cc'ing @rosiealice as well

@ekluzek
Copy link
Collaborator

ekluzek commented Apr 25, 2025

Hmm this is an interesting idea @rgknox . The thing that I know though is that this had to be carefully constructed this way so that the coupled model would work. As I recall CAM and CLM would end up with numerical instability without it. And even now that numerical instability can happen between the land and atmosphere where an oscillation will start and grow and kill the model.

I see the point about the benefits of allowing it to do this more slowly over two timesteps rather than one. But if this makes CAM and CLM unstable it wouldn't be something we could do. It's maybe possible that things have changed enough since then that this could be tried.

But thinking more deeply this is fundamental. Since radiation isn't updated in the atmosphere on the half hour, it's going to require that surface albedos and everything else to remain constant to remain in balance. Basically from the SW perspective solar is fixed and only changed on the hour. So there isn't a way to get around that and remain in balance.

There probably are other things that can respond on the faster cycle though. Just couldn't be anything that involves solar.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants