DATM updates and fixes #8
Conversation
…MSdatm into feature/gridfix
is compatible with current NEMS; these field names will need to be changed for CMEPS and with the next commit of NEMS
|
Denise, Thanks for making the changes to fix the issues. This simplifies the code a lot. One question is on the longitude between CFSR and GEFS. Looking at the short wave radiation. latent and sensible heat. It seems to even though both are for 2011100218, the GEFS SW seems not in correct location. |
|
Yes, I have to admit that totally went by me! But the fields marked as being from the forcing are read directly from the original forcing files that are used as input. I just looked again and the two forcing files do not agree on the placement of the SWrad at hour 18. I suspect something is wrong in the original forcing file? |
|
Thank you, @DeniseWorthen . You tackled almost all the issues at once. My naive question: To test the PR NEMSdatm, do I have to update DATM-MOM6-CICE5 and run it, or is there any test that I am not aware of (e.g., the way that you created the plots)? |
|
@flampouris That is a good question. We don't have to update the coupled app even if one of the components updates to a new develop. Sometimes we do update the app right away if we know the baselines don't change. But in this case, we know for sure it will break the baselines so we don't need to test the coupled model until NEMS can also go to develop. But before we do that, I think we need to get to the bottom of the time off-set in the gefs forcing files. Do you think you could have someone look at that? The DATM is putting out exactly what it is getting, but as Jun noticed the GEFS files are time-shifted. |
|
@hyunchul386 can you check the issue with the shortwave with the GEFS input files? It appears to be shifted at 18.00 in comparison with the CFSR. Which one is correct? |
|
I have created issue #12 on DATM-MOM6-CICE5 and assigned it to @hyunchul386 |
Thank you @DeniseWorthen |
|
Sure I'll take a look at it and let you know.
…On Tue, Apr 28, 2020 at 8:36 AM flampouris ***@***.***> wrote:
I have created issue #12
<NOAA-EMC/DATM-MOM6-CICE5#12> on
DATM-MOM6-CICE5 and assigned it to @hyunchul386
<https://github.com/hyunchul386>
Thank you @DeniseWorthen <https://github.com/DeniseWorthen>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#8 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADQ73E6XMPHK3VDAFAKME3DRO3ETVANCNFSM4MPLHEFA>
.
|
|
Just an update on the issue of mismatching in time average in GEFS/CFSR.
Attached are comparisons of DSWRF (averaged surface downward short
radiation) of CFSR (black line)
and GEFS (red line) in 2000-01-01-00Z and 2000-06-01-00Z from DATM_INPUT.
As shown, there is off-set between CFSR and GEFS.
Followings are some findings,
- CFSR is consistent with the real position of sun
- CFSR's time info in the original grib2 is consistent with the file name
e.g. : flxf00.gdas.*2000010100*.grb2 --> 16:4672231:vt=*2000010100*
:surface:*0-0 day ave* fcst:DSWRF Downward Short-Wave Radiation Flux
[W/m^2]:
- GEFS is not consistent with the real position of the sun
- GEFS's time info in the original netCDF is not consistent with the file
name
e.g.: bfg_*2000010100*_fhr00_control.nc -->
time = *17522892* ;
time:units = "hours since 1-1-1 00:00:00" ;
==> actually *31-DEC-1999 12z*
- GEFS of bfg_*2000010100*_fhr00_control.nc is not consistent with the real
position of sun
in 31-DEC-1999 12z
Hyun-Chul
…On Tue, Apr 28, 2020 at 11:48 AM Denise Worthen ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In DATM/AtmBundleCreate.F90
<#8 (comment)>:
> @@ -87,7 +89,7 @@ subroutine AtmBundleCreate(gcomp,importState, exportState, rc)
write(msgString,'(i4,2a14,a16,2a14,a16)')ii,' added field ',trim(fnameb),' to AtmBundleBak', &
' and field ',trim(fnamef),' to AtmBundleFwd'
- call ESMF_LogWrite(trim(msgString), ESMF_LOGMSG_INFO, rc=rc)
I removed all the return codes at the end of the LogWrite calls that were
just for information messages vs an rc created by a call to an ESMF routine.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#8 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADQ73E5JVGXCBRQLDKEHPALRO33FFANCNFSM4MPLHEFA>
.
|
|
Thank you, Hyun-Chul.
Please, fix the timestamps for the GODAS GEFS forcing files.
|
will have same names as for coupled model
There was a problem hiding this comment.
@DeniseWorthen thank you for this massive update and bug fix.
About the PR, I followed the code, and I do not see something awkward, not that I understand everything.
Your plots seem reasonable, and also considering that Hyun-Chul is tackling the issue with the GEFS timestamp at the input files level, this PR is approved.
|
@binli2337: I think I need an admin on this repo to approve the PR and merge. Jun and Stelios have both approved but merging is still blocked. Could you please review/approve. |
|
Hi Denise, These code updates will fix several issues reported by Jun and me during our previous meetings. |
DATM updates and fixes (NOAA-EMC#8)
This PR incorporates the following updates to both simplify the DATM component as well as make it more robust. The following changes are made:
Issue #4: The DATM grid is now created by reading a SCRIP grid definition file which is created from one of the source forcing files. An NCL script will be added to the utilities folder of the DATM-MOM6-CICE5 to allow this grid file to be created. This change allows large sections of code to be removed.
Issue #5: The DATM previously required at least one import field because the run sequence for the coupled model included a MED->ATM phase. Removal of this phase from the run sequence allows large sections of code to be removed.
Issue #6: The export field net_lw_flx is now created from the downward lw and upward lw fluxes present in the forcing file. The requirement for this calculation w/in the DATM itself is set in the datm_data_table where the net_lw_flx is set to "false", indicating this field is not present in the forcing file.
Other changes include:
*simplifying the printing of pet log messages
*removal of un-used code and variables
Because of the number of code-changes, the code was tested in standalone mode where the DATM functions solely as a file reader and interpolator. It driven by a simple driver and the fields exported by the standalone have been verified against the fields exported by the DATM when run in coupled mode.
The attached figures show a comparison of the fields contained in the actual forcing file with the matching field exported by the DATM in standalone mode at that timestep.