Investigate effects of CAM radiation reordering on CAM/CLM radiation coupling

[olyson]

The following discussion was prompted by a co-chairs meeting presentation (https://drive.google.com/file/d/11PykH6m4-VZWFO-Xf07HMWRp1xP5T_bK/view?usp=drive_web) on results from a fully coupled CAM_DEV (the new atmospheric model in development) simulation. It was noted that there were large SW rescaling errors in the CICE log and a large net heat budget error (~ 0.26 W/m2) in the CPL table. The question was asked whether the land model rescales SW fluxes to account for time lags. If so, this may affect the land model as well. In CAM_DEV, the radiation is called after CLM is called while in CAM6 the radiation is called before CLM is called. In CICE:

1. albedo is computed at end of time loop n (after state update) for use in next step n+1
2. albedo depends on FSDS … approximate albedo at n+1 using FSDS(t=n)
3. Correct for impact of lagged FSDS on albedo(n+1), at the top of time-step n+1

However, as first noted by @billsacks, “from a quick read of the CLM code, we don't have any rescaling like what is done in CICE. It looks like CLM calculates albedos at the end of the time step (if doalb is true, which is based on nextsw_cday), but it doesn't look like CLM attempts to calculate absorbed solar radiation at that point like CICE apparently does: It looks like everything computed in SurfaceAlbedoMod is in terms of fractions of the incoming solar radiation. Then in the next time step – in SurfaceRadiation – the albedos and other fractional values from the previous time step are multiplied by the incoming radiation to give actual absorbed / reflected solar radiation. So, if my understanding of this is right, then we have no need to do any rescaling – which maybe means we don't have the potential for the issues they are seeing in CICE?” I confirmed this myself and also discussed this further with Dave Bailey in the context of the differences between CICE and CLM. We agreed that there should be no need to do any shortwave rescaling in CLM.

However, we decided to investigate further the radiation coupling between CAM_DEV and CLM to identify any potential problems due to the reordering of the radiation call in CAM_DEV. The radiation coupling between CLM and CAM in general is shown in slide 1 of the following ppt and in more detail for a few time steps between CLM and CAM6 (left side of slide 2) and CLM and CAM_DEV (right side of slide 2).

LINK

I cloned one of the coupled simulations for CAM_DEV (b.cesm3_cam041_mom.B1850WcMOM.ne30_L58_t061.cice5.005) and output FSDS, FSR, and FSA at each time step for two days. The following ps file shows gridcells where all of the incoming solar radiation is reflected by CLM (determined by FSDS > 0 and FSA = 0, thus FSR=FSDS).

https://drive.google.com/file/d/1GBEvZ7mk5jP4wc7VijVglVi-UJQxHj-6/view?usp=sharing

At t=0 (this is an initialization time step, not a full time step), there are number of gridcells where all of the incoming solar radiation is reflected. Here, the albedos are from the initial file. Note that we set the albedos equal to one when CLM thinks the sun is below the horizon (determined by the solar zenith angle). So there appears to be some mismatch between the incoming solar radiation and the CLM albedos used for some gridcells. Note that we balance solar radiation because FSA+FSR still equals FSDS.
At the end of the t=0 timestep, doalb is false and the albedos are not updated. At t=1 (the first full time step), the albedos and incoming radiation are the same and nothing changes. At the end of t=1, doalb is still false and the albedos are not updated. At the end of t=3, doalb is now true and the albedos are updated. For t=4, etc. the incoming solar radiation and albedos appear to be synched up. However, I also looked at a CAM6/CTSM51 simulation I had done recently and the behavior is the same except the mismatch occurs for one less time step, presumably because in CAM6 radiation is called before CLM. We discussed this at the CLM business meeting on 06/10/22 and decided that there isn’t necessarily any problem with CAM_DEV radiation reordering (at least the behavior is the same as in CAM6). However, @dlawren noted that although there is not likely any effects in a climate application of the model, there could possibly be some effects in a weather application of the model and we should document and be aware of this behavior. Further discussion may be warranted.

[dlawrenncar]

Thanks for that excellent summary Keith and for all your analysis on this. At some point, I think we should inform the CAM group about the first few timesteps as they are the ones who are more likely to be doing prediction work on short timescales.

On Fri, Jun 10, 2022 at 5:03 PM Keith Oleson @.***> wrote:

The following discussion was prompted by a co-chairs meeting presentation ( https://mail.google.com/mail/u/0/?tab=cm&zx=5u2hovspc7sc#label/INBOX%2Fcesm2control/WhctKKXXHwQSdQXPvJmVkspDqCbnbxMTpbKhbNSdNmpxXKPNcPpcwMBkRvWpjnBdkgXMvwg?projector=1) on results from a fully coupled CAM_DEV (the new atmospheric model in development) simulation. It was noted that there were large SW rescaling errors in the CICE log and a large net heat budget error (~ 0.26 W/m2) in the CPL table. The question was asked whether the land model rescales SW fluxes to account for time lags. If so, this may affect the land model as well. In CAM_DEV, the radiation is called after CLM is called while in CAM6 the radiation is called before CLM is called. In CICE:

1. albedo is computed at end of time loop n (after state update) for use in next step n+1
2. albedo depends on FSDS … approximate albedo at n+1 using FSDS(t=n)
3. Correct for impact of lagged FSDS on albedo(n+1), at the top of time-step n+1

However, as first noted by @billsacks https://github.com/billsacks, “from a quick read of the CLM code, we don't have any rescaling like what is done in CICE. It looks like CLM calculates albedos at the end of the time step (if doalb is true, which is based on nextsw_cday), but it doesn't look like CLM attempts to calculate absorbed solar radiation at that point like CICE apparently does: It looks like everything computed in SurfaceAlbedoMod is in terms of fractions of the incoming solar radiation. Then in the next time step – in SurfaceRadiation – the albedos and other fractional values from the previous time step are multiplied by the incoming radiation to give actual absorbed / reflected solar radiation. So, if my understanding of this is right, then we have no need to do any rescaling – which maybe means we don't have the potential for the issues they are seeing in CICE?” I confirmed this myself and also discussed this further with Dave Bailey in the context of the differences between CICE and CLM. We agreed that there should be no need to do any shortwave rescaling in CLM.

However, we decided to investigate further the radiation coupling between CAM_DEV and CLM to identify any potential problems due to the reordering of the radiation call in CAM_DEV. The radiation coupling between CLM and CAM in general is shown in slide 1 of the following ppt and in more detail for a few time steps between CLM and CAM6 (left side of slide 2) and CLM and CAM_DEV (right side of slide 2).

LINK https://docs.google.com/presentation/d/1H1jolBYm3GaPvRono_ORm0heSY0QfrhY/edit?usp=sharing&ouid=104026900087612515425&rtpof=true&sd=true

I cloned one of the coupled simulations for CAM_DEV (b.cesm3_cam041_mom.B1850WcMOM.ne30_L58_t061.cice5.005) and output FSDS, FSR, and FSA at each time step for two days. The following ps file shows gridcells where all of the incoming solar radiation is reflected by CLM (determined by FSDS > 0 and FSA = 0, thus FSR=FSDS).

https://drive.google.com/file/d/1GBEvZ7mk5jP4wc7VijVglVi-UJQxHj-6/view?usp=sharing

At t=0 (this is an initialization time step, not a full time step), there are number of gridcells where all of the incoming solar radiation is reflected. Here, the albedos are from the initial file. Note that we set the albedos equal to one when CLM thinks the sun is below the horizon (determined by the solar zenith angle). So there appears to be some mismatch between the incoming solar radiation and the CLM albedos used for some gridcells. Note that we balance solar radiation because FSA+FSR still equals FSDS. At the end of the t=0 timestep, doalb is false and the albedos are not updated. At t=1 (the first full time step), the albedos and incoming radiation are the same and nothing changes. At the end of t=1, doalb is still false and the albedos are not updated. At the end of t=3, doalb is now true and the albedos are updated. For t=4, etc. the incoming solar radiation and albedos appear to be synched up. However, I also looked at a CAM6/CTSM51 simulation I had done recently and the behavior is the same except the mismatch occurs for one less time step, presumably because in CAM6 radiation is called before CLM. We discussed this at the CLM business meeting on 06/10/22 and decided that there isn’t necessarily any problem with CAM_DEV radiation reordering (at least the behavior is the same as in CAM6). However, @dlawren https://github.com/dlawren noted that although there is not likely any effects in a climate application of the model, there could possibly be some effects in a weather application of the model and we should document and be aware of this behavior. Further discussion may be warranted.

— Reply to this email directly, view it on GitHub https://github.com/ESCOMP/CTSM/issues/1782, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFABYVHOJXFE2J736AXG2ZDVOPCTZANCNFSM5YPCLQLQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[billsacks]

Thank you for this detailed analysis and writeup @olyson !

A few points possibly relevant to the issue of the first few time steps:

• If I remember correctly, in CLM4, albedos were calculated in initialization. This added a ton of complexity to the model initialization logic, so (if my memory is correct) @mvertens did a big cleanup at one point to use arbitrary albedo values in initialization, figuring that the impact on a climate simulation would be minimal. But does this analysis suggest that we should do something like forcing calculation of albedos in the first model time step?
• Note that we hope to stop running a 0th time step, which may have some impact here: https://github.com/ESCOMP/CTSM/issues/925

[mvertens]

@billsacks - thanks for pointing out #925. I was wondering the same thing. I think that forcing the calculation of albedos at the first model time step could be tricky - since if I remember you need the radiation information from the atm which in turn needs the albedo from the surface components. Do you and @olsyon agree with this? I think maybe what we need to do is have all the components agree on the calday for the first albedo computation. It would be great to have a call where all of these points could be hashed out.

[billsacks]

I think that forcing the calculation of albedos at the first model time step could be tricky - since if I remember you need the radiation information from the atm which in turn needs the albedo from the surface components. Do you and @olsyon agree with this? I think maybe what we need to do is have all the components agree on the calday for the first albedo computation. It would be great to have a call where all of these points could be hashed out.

Ah, interesting, thanks. This is definitely getting into territory where my understanding is weak, so I'm not going to try to reply here. I can join a call if that would be helpful.

[olyson]

That was my recollection as well, that there was a call to SurfaceAlbedo at initialization. I was actually looking for that here initially and didn't realize or forgot that had changed. Are the arbitrary albedo values used for a simulation that has an finidat or is that just for a cold start simulation. It seemed like the albedos from the finidat file were being used for t=0, etc., but I didn't verify that by actually checking values for a gridcell. I'm available for a call next week.

[billsacks]

Are the arbitrary albedo values used for a simulation that has an finidat or is that just for a cold start simulation. It seemed like the albedos from the finidat file were being used for t=0, etc., but I didn't verify that by actually checking values for a gridcell.

Sorry, I think you're right: I think the arbitrary values are just used for cold start.

[billsacks]

Some takeaways from a discussion with @olyson @mvertens @adamrher and myself yesterday (others: please correct anything I'm misstating here!). This discussion was focused on the inconsistency between CTSM and CAM in the first few time steps as highlighted by @olyson above:

• This discrepancy has existed for a while; the difference with the CAM reordering is that it persists for one more time step
• This discrepancy may have originated (or at least gotten worse) when we stopped recalculating albedos in CLM initialization. This change was done to greatly simplify the CLM initialization sequence.
• For short, forecast-style runs, we could see this discrepancy potentially being a problem, though we're not sure how big of a problem.
• Mariana suggested an alternative approach of forcing CTSM to recalculate albedos in the first time step of the run (i.e., forcing doalb to true for the first time step of the run). This would (at least mostly) resolve the issue raised by @olyson, but would create a new issue: Since CTSM wouldn't be sending these newly-calculated albedos to CAM for a few time steps, we'd have a situation where the albedos in CTSM are inconsistent with those in CAM for these time steps. We wonder if this could actually cause bigger problems than the current ones.
  • As a general rule, for conservation, we think it's important for CTSM to only update its albedos when it is about to send them to CAM, so that the albedos in CTSM remain consistent with those in CAM.
  • We don't have good intuition about approach is worse in terms of conservation or other issues: the current approach of waiting to update albedos for a few time steps or Mariana's suggestion. Part of the problem is that we don't have a good understanding of why there are currently solar radiation balance errors in the first few time steps (see #1563 for some discussion of this).
• Because of our uncertainty around what the best thing is to do here, our general feeling is that we should not do any major rework of this right now. However, we DO want to remove time step 0 (#925); this may help somewhat with the issue discussed here, but more importantly it will improve the handling of model output.

See also some relevant discussion in https://github.com/escomp/ctsm/issues/1563

[ekluzek]

@olyson should this be turned into a discussion? And could it be closed?

[olyson]

I think it could be turned into a discussion and then closed. Probably would have more visibility as a discussion than an issue if we need to go back to it. The conclusion was not to do anything at this point except to eliminate the zeroth time step, which is a CTSM pull request (#2084 )