Skip using fluxes provided by land component for first time step #234
Conversation
uturuncoglu
requested review from
grantfirl,
rhaesung,
Qingfu-Liu,
dustinswales,
barlage and
cenlinhe
as code owners
|
JFYI, The top level UFS WM PR is still in draft mode. I am still working on it. |
|
@grantfirl JFYI, I might also need to introduce another input.nml option to make skipping first time step for land optional since it is related with the run sequence of the coupled application and we might not need for the data atmosphere coupled configurations. |
@uturuncoglu Thanks. I see that the upstream PRs are in draft. We'll re-review if necessary. There are several PRs to be merged before this one, so it's unlikely this would bubble to the top in 2 weeks time anyway. |
|
@grantfirl Thanks. That is totally fine. I am still working on it. Once it is ready I'll change UFS WM level PR from draft to ready to review. |
|
@uturuncoglu @barlage @HelinWei-NOAA I assume this is a temporary fix. Otherwise, updating land as a component model cannot happen. |
|
@yangfanglin This is just for fully coupled S2S application and we could make it optional. The main issue is the run sequence. If you have a cold start and all components are running in the same time then you could not provide land fluxes in the first coupling time step. It is very similar to MOM6 case. It is also skipping first coupling time step as I know (except warm start maybe). If you want I could implement similar way in land and we could get rid of this part or we could discuss other possible options (let me know if you have something in your mind). In atm-land only case, I am having one time step delay between components and we have no this issue. BTW, we are trying to finalize the JTTI project soon. So, this will be a last PR from my end. |
|
Just had a meeting with @uturuncoglu re: this. I think we need something similar to what is being done in sfc_ocean to calculate some initial consistent fluxes that aren't dependent on any specific land model. Then, this could also be used for other land components. |
|
@yangfanglin @barlage Probably, I'll implement and test it in a couple of days. |
|
@barlage I could not find anything related with 2 meter temperature and specific humidity. A this point, I am just setting like, Do you think that this is good estimation for the initial coupling time step? |
|
I think that's fine for the first time step. |
| zvfun(i) = zvfun_lnd(i) | ||
| enddo | ||
| ! Check if it is cold or warm run | ||
| if (flag_init .and. .not. flag_restart) then |
There was a problem hiding this comment.
@barlage I add this part to calculate land fluxes in the first time step. Let me know if you see any issue with it.
There was a problem hiding this comment.
@barlage The part that calculated land fluxes internally is producing very large values for latent and sensible heat flux. I am trying to debug it but it might be related to the way of calculation of qss (not sure now). Since this is based on sfc_ocean it might need to have some adjustment. Any suggestion?
There was a problem hiding this comment.
@uturuncoglu I was hoping we could get away with this simple approximation but perhaps there needs to be a constraint added based on available energy. Typically when this approach is used in the land model, there is an adjustment to qss for stomatal and soil evap resistance. What is being done here is essentially like a ponded surface, but I wouldn't think that would produce unreasonable values (though this could be happening over hot soils where the qss could get very large). In the land model, LH and SH are constrained by available energy, which we don't have here (neither does sfc_ocean), also we are considering them here to be independent, which they also aren't in the land model. But again, none of this should produce "very large" values, unless there is an initialization issue with some of the inputs.
There was a problem hiding this comment.
@barlage it seems that qss = fpvs(tskin(i)) is returning very large value for me even if tskin is in the range. Maybe we need to use another function. The values like 1442 is produced with curent version. Any idea?
There was a problem hiding this comment.
@uturuncoglu the qss coming from the function is vapor pressure in Pascals so 1400 is not unreasonable, it's the equivalent of about 0.009 kg/kg specific humidity
There was a problem hiding this comment.
If you are saying both fluxes are large, then I'm wondering if it's something with the input ch values
| @@ -986,7 +988,7 @@ subroutine noahmpdrv_run & | |||
| ! | |||
| ! --- Just return if external land component is activated for two-way interaction | |||
| ! | |||
| if (cpllnd .and. cpllnd2atm) return | |||
| if (cpllnd .and. cpllnd2atm .and. (.not. flag_init)) return | |||
There was a problem hiding this comment.
@uturuncoglu I'm a little confused at the logic now. I thought with the new approach that we wouldn't need to call ccpp noahmp at all. Isn't this saying that with the land component, on the first time step we need to run the ccpp noahmp?
There was a problem hiding this comment.
@barlage let me check this part again. I might need to remove (.not. flag_init) since I think it is not neccecary. The logic is that the sfc_land will calculate the fluxes internally in the initial step (if it is cold run) and after that will get the fluxes from component model.
There was a problem hiding this comment.
that was my main point, that the changes to noahmpdrv.F90 and .meta don't seem necessary anymore.
| zvfun(i) = zvfun_lnd(i) | ||
| enddo | ||
| ! Check if it is cold or warm run | ||
| if (flag_init .and. .not. flag_restart) then |
Due to the dependency between atmosphere and land components, the atmosphere model gets all zero from land component model in the initial coupling time step. This PR aims to fix this issue and skips data coming from land component (all zero) at first coupling time step and use the land fluxes calculated by noahmp land model found in ccpp/physics. After first coupling time step, the coupled configuration (cpld_control_p8_lnd) will continue to use fluxes coming from component model.