Community Data Models for Earth Prediction Systems
Home Page: https://escomp.github.io/CDEPS/versions/master/html/index.html
Community Data Models for Earth Prediction Systems
For documentation see
https://escomp.github.io/CDEPS/versions/master/html/index.html
This repository is setup to automatically create tags on merge to main using .github/workflows/bumpversion.yml It uses https://github.com/mathieudutour/github-tag-action to look for keywords in commit messages and determine what the new version should be. The default if no keywords is found is to bump the patch version.
NOTE: this is a duplicate of CIME issue: ESMCI/cime#3802
I am re-submitting the issue here also for the record.
When running with the JRA data streams, the coszen time interpolation algorithm in shr code appears to have a bug resulting in large flux values being passed from the coupler to components. We discovered this issue when running the G compset (both w/ POP and MOM6) and JRA-forced data atm. Note that the JRA SWDN datastream makes use of coszen time interpolation algorithm with an offset of 5400 sec, i.e., 1.5 hours. This issue doesn't occur with the CORE2 data streams, probably because CORE2 is daily average, whereas JRA is 3-hourly.
The following is the x2oacc_Foxx_swnet field passed from the coupler to the ocean component at the very first coupling timestep with a band of large values (with a max of ~6k W m-2)
My initial troubleshooting efforts suggest this has to to with the time averaging of the coszen term used in normalization. See the relevant line here:
In the above line, cosz(i)/tavCosz(i) term leads to these large values because, i think, there is a discrepancy between how the cosz and tavCosz terms are computed. The time value passed to the subroutine that computes cosz and the time values passed to the subroutine that computes tavCosz don't seem to agree. But I'll let someone who is more familiar with this part of the code further diagnose and come up with a fix.
One final comment that further puzzles me: When the offset is -5400, as it should be, this issue occurs only at the first two timesteps. When the offset is 0, however, the issue occurs routinely at every third timestep.
To reproduce the issue:
create_newcase --res TL319_g17 --compset GIAF_JRA --case g.e22.GJRA.TL319_g17.sw.001 --run-unsupportedIf I want to change CDEPS share code for a run - its not clear where CDEPS modifications should go in the $CASEROOT/SourceMods directory. In testing #97, changes to dshr_mod.F90 were put in src.share and then in src.datm - but the recompile did not pick them up.
Its interesting that it seemed to pick it up (in src.drv) if I blew away bld/intel/mpt/nodebug/nothreads/nuopc/CDEPS.
For the case where a stream has multiple files to go over, I have discovered a significant memory growth that occurs each time a new stream file is open. This became evident in longer runs. I have a fix for this in dshr_stream_mod.F90 that involves the addition of two additional closefile calls. This is the branch mvertens/dynfrac which I will be issuing a PR for soon. However I wanted to make everyone aware of this - particular for the HAFS use cases.
Current implementation of dshr_state_getfldptr in streams/dshr_methods_mod.F90 just returns if the field is not in the state. This silent return is an issue and creates crashes in the apps if it is not used correctly. It is better to add an extra argument to the call to set explicitly just return.
I actually have two issues with the cdeps build:
ERROR: Timeout waiting for /glade/scratch/kate/Bering_JRA_gnu/bld/gnu/mpt/nodebug/nothreads/nuopc/CDEPS/dwav/libdwav.a
This happens even after case.build --clean.
HERE exeroot /glade/scratch/kate/Bering_JRA_gnu/bld bldroot /glade/scratch/kate/Bering_JRA_gnu/bld/gnu/mpt/nodebug/nothreads/nuopc/CDEPS
ERROR: ERROR from make output=[ 12%] Built target FoX_fsys
[ 18%] Built target FoX_utils
[ 36%] Built target FoX_common
[ 43%] Built target FoX_wxml
[ 52%] Built target FoX_sax
[ 64%] Built target FoX_dom
Scanning dependencies of target streams
[ 65%] Building Fortran object streams/CMakeFiles/streams.dir/dshr_methods_mod.F90.o
streams/CMakeFiles/streams.dir/build.make:81: recipe for target 'streams/CMakeFiles/streams.dir/dshr_methods_mod.F90.o' failed
CMakeFiles/Makefile2:1358: recipe for target 'streams/CMakeFiles/streams.dir/all' failed
Makefile:148: recipe for target 'all' failed, error=f951: Warning: Nonexistent include directory ‘/glade/scratch/kate/Bering_JRA_gnu/bld/gnu/mpt/nodebug/nothreads/nuopc/CDEPS
/share’ [-Wmissing-include-dirs]
f951: Warning: Nonexistent include directory ‘/glade/scratch/kate/Bering_JRA_gnu/bld/gnu/mpt/nodebug/nothreads/nuopc/finclude’ [-Wmissing-include-dirs]
f951: Fatal Error: Reading module ‘esmf’ at line 1 column 2: Unexpected EOF
compilation terminated.
and on chinook:
ERROR: ERROR from make output=[ 12%] Built target FoX_fsys
[ 18%] Built target FoX_utils
[ 36%] Built target FoX_common
[ 43%] Built target FoX_wxml
[ 52%] Built target FoX_sax
[ 64%] Built target FoX_dom
[ 70%] Built target streams
Scanning dependencies of target dshr
[ 71%] Building Fortran object dshr/CMakeFiles/dshr.dir/dshr_dfield_mod.F90.o, error=f951: Warning: Nonexistent include directory ‘/import/c1/AKWATERS/kate/climate/kshedstrom
/Bering_JRA_2.2/bld/gnu/openmpi/nodebug/nothreads/nuopc/CDEPS/share’ [-Wmissing-include-dirs]
f951: Warning: Nonexistent include directory ‘/center1/AKWATERS/kate/climate/kshedstrom/Bering_JRA_2.2/bld/gnu/openmpi/nodebug/nothreads/nuopc/finclude’ [-Wmissing-include-di
rs]
f951: Fatal Error: Reading module ‘dshr_strdata_mod’ at line 6481 column 71: Expected left parenthesis
compilation terminated.
I'm not sure how to proceed.
The cdeps build does not currently look for or build files from the cesm SourceMods directory.
The data component gives following error when user uses empty <stream_data_files> xml tag. It would be nice to have more meaningful error message that indicates missing stream data file.
ERROR: (shr_stream_getCalendar) ERROR: k gt nfiles
Need to understand relationship between shortwave bands and net shortwave rad. Currently it is provided directly from ERA5 and the total of the bands are not consistent with the swnet. There is an active C3S/CAMS Data Support ticket at ECMWF (CUS-14300).
Just talked to @mvertens and @jedwards4b about this. I'd like to see the ability to modify individual settings in datm.streams.xml with something like user_nl_datm or a xmlchange (or a new streamchange command). Whichever makes the most sense. This way the user can easily change just a few settings for an individual case without having to copy the entire streams file for just a few small changes. This makes those changes portable to other cases with different versions of the models. By encapsulating the changes into a small file only those specific settings get changed. If the entire streams file is copied to a different case with a different model version it will overwrite changes in defaults that were changed because of the model difference.
I say for datm.streams.xml because that's what I care about, but if added as a general capability this should be added for other data components that use streams.
This likely needs to be addressed both here in CDEPS and in cime. So I'll create an issue there as well.
This is in v0.3.0
Two inputdata mesh files are in NetCDF4 format
atm/datm7/atm_forcing.datm7.cruncep_qianFill.0.5d.v7.c160715/clmforc.cruncep.V7.c2016.0.5d.ESMFmesh_260520.nc
atm/datm7/atm_forcing.datm7.NLDAS2.0.125d.v1/ctsmforc.NLDAS2.0.125d.v1.ESMFmesh_120620.nc
There's also a file listed as:
$DIN_LOC_ROOT/atm/datm7/anomaly_forcing/domain.permafrostRCN_P2.c2013.nc/domain.permafrostRCN_P2_ESMFmesh_120620.nc
and should be:
$DIN_LOC_ROOT/atm/datm7/anomaly_forcing/domain.permafrostRCN_P2.c2013.nc
Defining both wind and stress components in namelist_definition_datm.xml is not working. I have tested both
<value datm_mode="ERA5">u:v,taux:tauy</value>
and
<value datm_mode="ERA5">'u:v','taux:tauy'</value>
syntaxes and the stress components do not appear in the datm.streams.xml file and shown as <stream_vectors>u:v</stream_vectors>
For mizuRoute the mesh files are very large 5.7 GBytes, so it takes a long time to read them in. We still need to read in the center coordinates for history output. But, if a mapping file is already produced you don't really need to read in the mesh vertices. So would it be possible to setup NUOPC to have an option to only read the vertices only if the mapping file isn't input?
This is how mizuRoute standalone gets around reading in these large grid definition files -- by only reading in the mapping files. It would be good for CESM to have a way to do that as well.
We should support just supplying a lat and lon location for a single column data set instead of the domain file.
Should generate a docn stream file but does not.
If CLM is removed from DATM_ settings in cime we'll need to coordinate that change in CDEPS. There are a bunch of instances of these in datm config_component.xml and namelist_definition, as well as in the documentation. There's a print statement in datm buildnml that likely should change as well.
The CDEPS aux tests that includes f10_f10_musgs grids are failing as follows because the grid is deprecated in CLM side,
SMS_Vnuopc_Ld5.f10_f10_musgs.1850_DATM%GSWP3v1_SLND_SICE_SOCN_SROF_SGLC_SWAV_SESP.cheyenne_intel (Overall: FAIL) details:
FAIL SMS_Vnuopc_Ld5.f10_f10_musgs.1850_DATM%GSWP3v1_SLND_SICE_SOCN_SROF_SGLC_SWAV_SESP.cheyenne_intel CREATE_NEWCASE
SMS_Vnuopc_Ld5.f10_f10_musgs.2000_DATM%CRUv7_SLND_SICE_SOCN_SROF_SGLC_SWAV_SESP.cheyenne_intel (Overall: FAIL) details:
FAIL SMS_Vnuopc_Ld5.f10_f10_musgs.2000_DATM%CRUv7_SLND_SICE_SOCN_SROF_SGLC_SWAV_SESP.cheyenne_intel CREATE_NEWCASE
SMS_Vnuopc_Ld5.f10_f10_musgs.2000_DATM%NLDAS2_SLND_SICE_SOCN_SROF_SGLC_SWAV_SESP.cheyenne_intel (Overall: FAIL) details:
FAIL SMS_Vnuopc_Ld5.f10_f10_musgs.2000_DATM%NLDAS2_SLND_SICE_SOCN_SROF_SGLC_SWAV_SESP.cheyenne_intel CREATE_NEWCASE
SMS_Vnuopc_Ld5.f10_f10_musgs.2000_DATM%QIA_SLND_SICE_SOCN_SROF_SGLC_SWAV_SESP.cheyenne_intel (Overall: FAIL) details:
FAIL SMS_Vnuopc_Ld5.f10_f10_musgs.2000_DATM%QIA_SLND_SICE_SOCN_SROF_SGLC_SWAV_SESP.cheyenne_intel CREATE_NEWCASE
SMS_Vnuopc_Ld5.f10_f10_musgs.2010_DATM%GSWP3v1_SLND_SICE_SOCN_SROF_SGLC_SWAV_SESP.cheyenne_intel (Overall: FAIL) details:
FAIL SMS_Vnuopc_Ld5.f10_f10_musgs.2010_DATM%GSWP3v1_SLND_SICE_SOCN_SROF_SGLC_SWAV_SESP.cheyenne_intel CREATE_NEWCASE
SMS_Vnuopc_Ld5.f10_f10_musgs.HIST_DATM%GSWP3v1_SLND_SICE_SOCN_SROF_SGLC_SWAV_SESP.cheyenne_intel (Overall: FAIL) details:
FAIL SMS_Vnuopc_Ld5.f10_f10_musgs.HIST_DATM%GSWP3v1_SLND_SICE_SOCN_SROF_SGLC_SWAV_SESP.cheyenne_intel CREATE_NEWCASE
SMS_Vnuopc_Ld5.f10_f10_musgs.SSP585_DATM%GSWP3v1_SLND_SICE_SOCN_SROF_SGLC_SWAV_SESP.cheyenne_intel (Overall: FAIL) details:
FAIL SMS_Vnuopc_Ld5.f10_f10_musgs.SSP585_DATM%GSWP3v1_SLND_SICE_SOCN_SROF_SGLC_SWAV_SESP.cheyenne_intel CREATE_NEWCASE
This needs to be fixed by updating the grid or removing those tests from the cdeps stand-alone test suite.
There is a print "string" that needs to change to a print( "string" ) in a buildlib file for compatibility with both python2 and python3.
cime_config/buildlib
Here's the fix that also shows the problem...
diff --git a/cime_config/buildlib b/cime_config/buildlib
index 2608ff3..37ed71c 100755
--- a/cime_config/buildlib
+++ b/cime_config/buildlib
@@ -20,7 +20,7 @@ logger = logging.getLogger(__name__)
def buildlib(bldroot, libroot, case, compname=None):
if bldroot.endswith("obj") and not compname:
compname = os.path.basename(os.path.abspath(os.path.join(bldroot,os.pardir)))
- print "HERE compname is {} libroot={} bldroot={}".format(compname, libroot, bldroot)
+ print( "HERE compname is {} libroot={} bldroot={}".format(compname, libroot, bldroot) )
if case.get_value("DEBUG"):
strdebug = "debug"I think that dice and drof are not currently tested in the testlist.
Currently the CDEPS provides error messages as something like cryptic and it is hard to understand what is going on in the background to solve the issue. For example, if you are not providing data in correct temporal extent by using limit option, you are getting message like rDateIn gt rDategvd and this is not very informative and you need to go to code to understand the main issue. It would be nice to give/print more understandable information to regular users to see the issue and fix their streams or configurations.
NEON data will be updated monthly. As such the streams will need to be updated monthly for the last year of data, so that you can run to the end of it. So there needs to be a way to designate the last valid month for that last year of data.
There could be a XML variable to designate the last month of data, that could be invoked for the last year. Normally it wouldn't be used (or assumed to be 12). For generality you could also implement a start month to apply to the first year of data.
One catch for these series with less than a full year is that you can't cycle over less than a full year -- so you can't use them for any model spinups.
Test SMS_Vnuopc.T62_g37.A.cheyenne_pgi.drv-default fails in SHAREDLIB_BUILD with the message
PGF90-S-0155-Empty generic procedure - destroy (/glade/work/klindsay/cesm2_tags/cesm2.2_nuopc/components/cdeps/streams/dshr_stream_mod.F90: 284)
PGF90-S-0155-Empty generic procedure - destroy (/glade/work/klindsay/cesm2_tags/cesm2.2_nuopc/components/cdeps/streams/dshr_stream_mod.F90: 284)
0 inform, 0 warnings, 2 severes, 0 fatal for shr_stream_init_from_xml
make[2]: *** [streams/CMakeFiles/streams.dir/dshr_stream_mod.F90.o] Error 2
make[1]: *** [streams/CMakeFiles/streams.dir/all] Error 2
CASEROOT for a failing test is /glade/scratch/klindsay/SMS_Vnuopc.T62_g37.A.cheyenne_pgi.drv-default.20201221_115419_shjatv
This is with the current head of the nuopc_dev branch of CESM plus ESMCI/cime#3803. Relevant hashes are
cime: 7fb1700
cmeps: 0ccc872
cdeps: c669b39
We are in the process of adding JRA Repeat Year Forcing to CIME data models. This new capability will need to be added to CDEPS as well.
see CIME PR: ESMCI/cime#3691
Around the time when we switch to using NUOPC as our standard way of operating in CESM – and at least before scientific testing begins in earnest for CESM3 – we want to have a data glc model. In addition to being useful in its own right, this will serve as a replacement for the current use of CISM2%NOEVOLVE – i.e., providing a static snapshot of glacier areas and elevations as well as providing a high-resolution grid onto which surface mass balance can be downscaled. So, unlike most data components, we'll want the system to remap lnd -> glc fields to the glc grid given by this data glc model.
The following use statements and possibly others need only clauses.
Please assure that new code to be introduced includes only clauses on all use statements.
streams/dshr_tinterp_mod.F90: use ESMF
streams/dshr_strdata_mod.F90: use ESMF
streams/dshr_methods_mod.F90: use ESMF
drof/rof_comp_nuopc.F90: use ESMF
datm/atm_comp_nuopc.F90: use ESMF
datm/datm_datamode_era5_mod.F90: use ESMF
datm/datm_datamode_jra_mod.F90: use ESMF
datm/datm_datamode_clmncep_mod.F90: use ESMF
datm/datm_datamode_core2_mod.F90: use ESMF
dice/dice_datamode_ssmi_mod.F90: use ESMF
dice/ice_comp_nuopc.F90: use ESMF
dlnd/lnd_comp_nuopc.F90: use ESMF
dwav/wav_comp_nuopc.F90: use ESMF
docn/docn_datamode_som_mod.F90: use ESMF
docn/docn_datamode_aquaplanet_mod.F90: use ESMF
docn/ocn_comp_nuopc.F90: use ESMF
docn/docn_datamode_copyall_mod.F90: use ESMF
docn/docn_datamode_iaf_mod.F90: use ESMF
dshr/dshr_dfield_mod.F90: use ESMF
dshr/dshr_fldlist_mod.F90: use ESMF
I hit two error message when I try to build CDEPS in my local machine (Mac OS using gfortran) and I just want to document them in here to fix in the following PR,
1. For GNU compilers GCC>=10.x, the default Fortran argument mismatch checking has become stricter and this causes following error,
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:1947:26:
1947 | call MPI_ALLREDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,comm,ierr)
| 1
......
2004 | call MPI_ALLREDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,comm,ierr)
| 2
Error: Rank mismatch between actual argument at (1) and actual argument at (2) (rank-1 and scalar)
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:1950:23:
1950 | call MPI_REDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,0,comm,ierr)
| 1
......
2007 | call MPI_REDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,0,comm,ierr)
| 2
Error: Rank mismatch between actual argument at (1) and actual argument at (2) (rank-1 and scalar)
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:1890:26:
1890 | call MPI_ALLREDUCE(lvec,gvec,gsize,MPI_INTEGER,reduce_type,comm,ierr)
| 1
......
2004 | call MPI_ALLREDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:1893:23:
1893 | call MPI_REDUCE(lvec,gvec,gsize,MPI_INTEGER,reduce_type,0,comm,ierr)
| 1
......
2007 | call MPI_REDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,0,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:1833:26:
1833 | call MPI_ALLREDUCE(lvec,gvec,gsize,MPI_INTEGER,reduce_type,comm,ierr)
| 1
......
2004 | call MPI_ALLREDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:1836:23:
1836 | call MPI_REDUCE(lvec,gvec,gsize,MPI_INTEGER,reduce_type,0,comm,ierr)
| 1
......
2007 | call MPI_REDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,0,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:1719:26:
1719 | call MPI_ALLREDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,comm,ierr)
| 1
......
2004 | call MPI_ALLREDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,comm,ierr)
| 2
Error: Rank mismatch between actual argument at (1) and actual argument at (2) (rank-1 and scalar)
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:1722:23:
1722 | call MPI_REDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,0,comm,ierr)
| 1
......
2007 | call MPI_REDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,0,comm,ierr)
| 2
Error: Rank mismatch between actual argument at (1) and actual argument at (2) (rank-1 and scalar)
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:1662:26:
1662 | call MPI_ALLREDUCE(lvec,gvec,gsize,MPI_INTEGER,reduce_type,comm,ierr)
| 1
......
2004 | call MPI_ALLREDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:1665:23:
1665 | call MPI_REDUCE(lvec,gvec,gsize,MPI_INTEGER,reduce_type,0,comm,ierr)
| 1
......
2007 | call MPI_REDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,0,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:1605:26:
1605 | call MPI_ALLREDUCE(lvec,gvec,gsize,MPI_INTEGER,reduce_type,comm,ierr)
| 1
......
2004 | call MPI_ALLREDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:1608:23:
1608 | call MPI_REDUCE(lvec,gvec,gsize,MPI_INTEGER,reduce_type,0,comm,ierr)
| 1
......
2007 | call MPI_REDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,0,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:1377:26:
1377 | call MPI_ALLREDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,comm,ierr)
| 1
......
2004 | call MPI_ALLREDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,comm,ierr)
| 2
Error: Rank mismatch between actual argument at (1) and actual argument at (2) (rank-1 and scalar)
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:1380:23:
1380 | call MPI_REDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,0,comm,ierr)
| 1
......
2007 | call MPI_REDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,0,comm,ierr)
| 2
Error: Rank mismatch between actual argument at (1) and actual argument at (2) (rank-1 and scalar)
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:1320:26:
1320 | call MPI_ALLREDUCE(lvec,gvec,gsize,MPI_INTEGER8,reduce_type,comm,ierr)
| 1
......
2004 | call MPI_ALLREDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(8)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:1323:23:
1323 | call MPI_REDUCE(lvec,gvec,gsize,MPI_INTEGER8,reduce_type,0,comm,ierr)
| 1
......
2007 | call MPI_REDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,0,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(8)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:1263:26:
1263 | call MPI_ALLREDUCE(lvec,gvec,gsize,MPI_INTEGER8,reduce_type,comm,ierr)
| 1
......
2004 | call MPI_ALLREDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(8)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:1266:23:
1266 | call MPI_REDUCE(lvec,gvec,gsize,MPI_INTEGER8,reduce_type,0,comm,ierr)
| 1
......
2007 | call MPI_REDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,0,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(8)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:1206:26:
1206 | call MPI_ALLREDUCE(lvec,gvec,gsize,MPI_INTEGER,reduce_type,comm,ierr)
| 1
......
2004 | call MPI_ALLREDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:1209:23:
1209 | call MPI_REDUCE(lvec,gvec,gsize,MPI_INTEGER,reduce_type,0,comm,ierr)
| 1
......
2007 | call MPI_REDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,0,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:1149:26:
1149 | call MPI_ALLREDUCE(lvec,gvec,gsize,MPI_INTEGER,reduce_type,comm,ierr)
| 1
......
2004 | call MPI_ALLREDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:1152:23:
1152 | call MPI_REDUCE(lvec,gvec,gsize,MPI_INTEGER,reduce_type,0,comm,ierr)
| 1
......
2007 | call MPI_REDUCE(lvec,gvec,gsize,MPI_REAL8,reduce_type,0,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:893:19:
893 | call MPI_BCAST(arr,lsize,MPI_INTEGER,lpebcast,comm,ierr)
| 1
......
931 | call MPI_BCAST(arr,lsize,MPI_REAL8,lpebcast,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:781:19:
781 | call MPI_BCAST(vec,lsize,MPI_LOGICAL,lpebcast,comm,ierr)
| 1
......
931 | call MPI_BCAST(arr,lsize,MPI_REAL8,lpebcast,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (LOGICAL(4)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:745:19:
745 | call MPI_BCAST(vec,lsize,MPI_INTEGER8,lpebcast,comm,ierr)
| 1
......
931 | call MPI_BCAST(arr,lsize,MPI_REAL8,lpebcast,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(8)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:712:19:
712 | call MPI_BCAST(vec,lsize,MPI_INTEGER,lpebcast,comm,ierr)
| 1
......
931 | call MPI_BCAST(arr,lsize,MPI_REAL8,lpebcast,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:676:19:
676 | call MPI_BCAST(vec,lsize,MPI_REAL8,lpebcast,comm,ierr)
| 1
......
931 | call MPI_BCAST(arr,lsize,MPI_REAL8,lpebcast,comm,ierr)
| 2
Error: Rank mismatch between actual argument at (1) and actual argument at (2) (rank-1 and scalar)
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:640:19:
640 | call MPI_BCAST(vec,lsize,MPI_CHARACTER,lpebcast,comm,ierr)
| 1
......
931 | call MPI_BCAST(arr,lsize,MPI_REAL8,lpebcast,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (CHARACTER(0)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:604:19:
604 | call MPI_BCAST(vec,lsize,MPI_CHARACTER,lpebcast,comm,ierr)
| 1
......
931 | call MPI_BCAST(arr,lsize,MPI_REAL8,lpebcast,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (CHARACTER(0)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:568:19:
568 | call MPI_BCAST(vec,lsize,MPI_LOGICAL,lpebcast,comm,ierr)
| 1
......
931 | call MPI_BCAST(arr,lsize,MPI_REAL8,lpebcast,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (LOGICAL(4)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:532:19:
532 | call MPI_BCAST(vec,lsize,MPI_INTEGER8,lpebcast,comm,ierr)
| 1
......
931 | call MPI_BCAST(arr,lsize,MPI_REAL8,lpebcast,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(8)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:499:19:
499 | call MPI_BCAST(vec,lsize,MPI_INTEGER,lpebcast,comm,ierr)
| 1
......
931 | call MPI_BCAST(arr,lsize,MPI_REAL8,lpebcast,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:393:18:
393 | call MPI_RECV(lvec,lsize,MPI_REAL8,pid,tag,comm,status,ierr)
| 1
......
463 | call MPI_RECV(array,lsize,MPI_REAL8,pid,tag,comm,status,ierr)
| 2
Error: Rank mismatch between actual argument at (1) and actual argument at (2) (rank-1 and scalar)
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:358:18:
358 | call MPI_RECV(lvec,lsize,MPI_INTEGER,pid,tag,comm,status,ierr)
| 1
......
463 | call MPI_RECV(array,lsize,MPI_REAL8,pid,tag,comm,status,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:323:18:
323 | call MPI_RECV(lvec,lsize,MPI_INTEGER,pid,tag,comm,status,ierr)
| 1
......
463 | call MPI_RECV(array,lsize,MPI_REAL8,pid,tag,comm,status,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:220:18:
220 | call MPI_SEND(lvec,lsize,MPI_REAL8,pid,tag,comm,ierr)
| 1
......
288 | call MPI_SEND(array,lsize,MPI_REAL8,pid,tag,comm,ierr)
| 2
Error: Rank mismatch between actual argument at (1) and actual argument at (2) (rank-1 and scalar)
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:186:18:
186 | call MPI_SEND(lvec,lsize,MPI_INTEGER,pid,tag,comm,ierr)
| 1
......
288 | call MPI_SEND(array,lsize,MPI_REAL8,pid,tag,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/REAL(8)).
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/share/shr_mpi_mod.F90:152:18:
152 | call MPI_SEND(lvec,lsize,MPI_INTEGER,pid,tag,comm,ierr)
| 1
......
288 | call MPI_SEND(array,lsize,MPI_REAL8,pid,tag,comm,ierr)
| 2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/REAL(8)).
This can be solved by adding following to cmake command,
-DCMAKE_Fortran_FLAGS="-fallow-argument-mismatch -fallow-invalid-boz"
2. Some lines in the CDEPS source code is longer than expected and causes following error,
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/dshr/dshr_mod.F90:1471:132:
1471 | call ESMF_LogSetError(ESMF_RC_NOT_VALID, msg=msgstr, line=__LINE__, file=__FILE__, rcToReturn=rc)
| 1
Error: Line truncated at (1) [-Werror=line-truncation]
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/dshr/dshr_mod.F90:1471:81:
1471 | call ESMF_LogSetError(ESMF_RC_NOT_VALID, msg=msgstr, line=__LINE__, file=__FILE__, rcToReturn=rc)
| 1
Error: Unterminated character constant beginning at (1)
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/dshr/dshr_mod.F90:1485:132:
1485 | call ESMF_LogSetError(ESMF_RC_NOT_VALID, msg=msgstr, line=__LINE__, file=__FILE__, rcToReturn=rc)
| 1
Error: Line truncated at (1) [-Werror=line-truncation]
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/dshr/dshr_mod.F90:1485:81:
1485 | call ESMF_LogSetError(ESMF_RC_NOT_VALID, msg=msgstr, line=__LINE__, file=__FILE__, rcToReturn=rc)
| 1
Error: Unterminated character constant beginning at (1)
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/dshr/dshr_mod.F90:1502:132:
1502 | call ESMF_LogSetError(ESMF_RC_NOT_VALID, msg=msgstr, line=__LINE__, file=__FILE__, rcToReturn=rc)
| 1
Error: Line truncated at (1) [-Werror=line-truncation]
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/dshr/dshr_mod.F90:1502:81:
1502 | call ESMF_LogSetError(ESMF_RC_NOT_VALID, msg=msgstr, line=__LINE__, file=__FILE__, rcToReturn=rc)
| 1
Error: Unterminated character constant beginning at (1)
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/dshr/dshr_mod.F90:1510:132:
1510 | call ESMF_LogSetError(ESMF_RC_NOT_VALID, msg=msgstr, line=__LINE__, file=__FILE__, rcToReturn=rc)
| 1
Error: Line truncated at (1) [-Werror=line-truncation]
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/dshr/dshr_mod.F90:1510:78:
1510 | call ESMF_LogSetError(ESMF_RC_NOT_VALID, msg=msgstr, line=__LINE__, file=__FILE__, rcToReturn=rc)
| 1
Error: Unterminated character constant beginning at (1)
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/dshr/dshr_mod.F90:1568:132:
1568 | call ESMF_LogSetError(ESMF_RC_NOT_VALID, msg=msgstr, line=__LINE__, file=__FILE__, rcToReturn=rc)
| 1
Error: Line truncated at (1) [-Werror=line-truncation]
/Users/turuncu/Desktop/NUOPC/alldata/cdeps/dshr/dshr_mod.F90:1568:78:
1568 | call ESMF_LogSetError(ESMF_RC_NOT_VALID, msg=msgstr, line=__LINE__, file=__FILE__, rcToReturn=rc)
| 1
Error: Unterminated character constant beginning at (1)
f951: some warnings being treated as errors
and the correct solution is to break up the long lines with a continuation character or following fortran flag need to be passed to cmake
-DCMAKE_Fortran_FLAGS="-ffree-line-length-512"
The CDEPS tags so far are unannotated. I suggest it's better to make annotated tags when you want them to be permanent in the repository. With annotated tags "git describe" will automatically show you the closest annotated tag for example. With the unannotated tags I have to add an argument to it (--tags). We shouldn't change existing tags, but it would be good to have any new tags on CDEPS be annotated. That adds a commit hash to describe the tag, hence it's more permanent. Unannotated tags are sometimes referred to as local, throwaway, or lightweight tags. These version tags of CDEPS aren't meant to be any of those things.
man git-tag has this to say about why to use one over the other...
Tag objects (created with -a, -s, or -u) are called "annotated" tags; they contain a creation date, the tagger name and e-mail, a tagging message, and an optional GnuPG signature. Whereas a "lightweight" tag is simply a name for an object (usually a commit object). Annotated tags are meant for release while lightweight tags are meant for private or temporary object labels. For this reason, some git commands for naming objects (like git describe) will ignore lightweight tags by default..
I think the argument order on this line is wrong:
Line 130 in c999578
As noted in ESMCI/cime#4034, this is using argument parsing that is appropriate for components, which (confusingly!) differs from the order of arguments in calls to libraries' buildlibs. CDEPS is built using the library code, not the component code.
See (for example) buildlib.csm_share for what I think is a correct argument parsing.
This is only relevant if CDEPS's buildlib is called as a subprocess instead of as a function. Typically it is called as a function, so this isn't critical, but it would be good to fix it to avoid subtle issues in the future.
The CDEPS build is failing on certain platforms when built on compute notes that do not have access to GitHub.com. This is due to automatic download of genf90 from GitHub during the build process. See: https://github.com/ESCOMP/CDEPS/blob/master/share/CMakeLists.txt#L34
One option is to commit the .F90 files themselves (and not re-generate from the .in templates) since these files change infrequently. Then only the developer making the change would need the genf90 tool.
Another option is to add genf90 as a submodule so that it is cloned along with the rest of the source code - this means it will be available to run on the compute nodes during the build phase.
This may really be an issue in cime. And actually issue #76 supersedes this. But, until #76 is done it makes sense for a datm.stream.xml file in a test-mod directory to be copied into the $CASEDIR. But, with #78 and this issue I don't have a workaround to get the NEON test case to work.
It does make sense to me that if a user can change their own case with a datm.stream.xml file that this same capability should work for a test case. Once #76 comes in we may not even want to support the ability to have a user version of it in the $CASEDIR. So at that point this capability for both test mods and for a user datm.stream.xml file maybe should be removed.
So I don't put this as a high priority especially if #76 happens reasonably soon. But, if that's the case this issue can be a reminder to remove the ability to have a user datm.stream.xml file in the $CASEDIR.
Many of the taxmode's for CLM atmospheric forcing is set as extend. Extend is problematic for this data in CLM as it then leaves the atmospheric state at the last 1-hour to 3-hour period. This wipes out diurnal cycles, and produces persistent droughts in some locations and constant rain in others. Eventually this causes the land model to act strangely and often crash, since the forcing is so whacked. For some monthly or yearly fields (like presaero or CO2) extend is the reasonable thing to do. But, not for the daily to sub-daily atmospheric forcing.
When you override the datm.streams.xml file with a file in your $CASEDIR, it doesn't use the new list of files or the yearFirst and yearLast to determine the file list. It does use the stream file from the $CASEDIR, but it doesn't change datm.input_data_list by what's in the user file. Since, the inpudata_data_list is updated with each run of preview_namelists this makes it difficult to use if the reason you changed the streams file is because of missing files.
(Copying this from ESMCI/cime#3549, originally opened by @ekluzek.)
Both CLM and the ocean model need Nitrogen deposition to be sent in. We've handled this by having it sent in by CAM when WACCM is run -- but having each surface component handle prescribed datasets themselves. This means that OCN and LND could have inconsistent datasets. And it also leads to certain problems when surface components don't know if ndep is provided by the ATM model or not (see for example: ESCOMP/CTSM#946). Since, ndep physically is something in the atmosphere, it makes the most sense if ndep would ALWAYS be provided by the ATM component just like prescribed aerosols are now.
The CAM issue that relates to this is here:
Once CAM is able to send ndep, the surface components could stop having to prescribe it and just always rely on what is being sent from that ATM component.
The default way of running a standard CTSM long simulation is the following:
1. Run from 1850-1901 and cycle over the 1901-1920 GSWP3V1 forcing data
/glade/p/cgd/tss/people/oleson/atm_forcing.datm7.GSWP3.0.5d.v1.c200929/Solar/clmforc.GSWP3.c2011.0.5x0.5.Solr.1901-01.nc to
/glade/p/cgd/tss/people/oleson/atm_forcing.datm7.GSWP3.0.5d.v1.c200929/TPHWL/clmforc.GSWP3.c2011.0.5x0.5.TPQWL.1920-12.nc
/glade/p/cgd/tss/people/oleson/atm_forcing.datm7.GSWP3.0.5d.v1.c200929/Solar/clmforc.GSWP3.c2011.0.5x0.5.Solr.1901-01.nc
2. **Restart** (1) and run from 1901-2014 using the 1901-2014 atmospheric data
/glade/p/cgd/tss/people/oleson/atm_forcing.datm7.GSWP3.0.5d.v1.c200929/Solar/clmforc.GSWP3.c2011.0.5x0.5.Solr.1901-01.nc
to
/glade/p/cgd/tss/people/oleson/atm_forcing.datm7.GSWP3.0.5d.v1.c200929/Solar/clmforc.GSWP3.c2011.0.5x0.5.Solr.2014-12.nc
and issuing the following xmlchange commands
./xmlchange DATM_YR_ALIGN=1901
./xmlchange DATM_YR_START=1901
./xmlchange DATM_YR_END=2014
The problem is that for cdeps this is really not a restart and the following error occurs when during the read of the datm restart file at model date 19010101:
ERROR: something is wrong
The traceback is:
729:Image PC Routine Line Source
1729:cesm.exe 00000000013CEAF6 Unknown Unknown Unknown
1729:cesm.exe 0000000000EDC600 shr_abort_mod_mp_ 114 shr_abort_mod.F90
1729:cesm.exe 0000000000EC3577 dshr_stream_mod_m 1732 dshr_stream_mod.F90
1729:cesm.exe 0000000000E8BE65 dshr_mod_mp_dshr_ 941 dshr_mod.F90
1729:cesm.exe 0000000000527B94 datm_datamode_clm 576 datm_datamode_clmncep_mod.F90
1729:cesm.exe 000000000051DAE1 atm_comp_nuopc_mp 583 atm_comp_nuopc.F90
1729:cesm.exe 000000000051FD02 atm_comp_nuopc_mp 402 atm_comp_nuopc.F90
This is due the fact that the restart file expects 240 files in each stream (20 years X 12 months), whereas we are now using 1368 files (114 years X 12 months).
The quick solution was to comment out the following line in dshr_mod.F90
!call shr_stream_restIO(pioid, sdat%stream, 'read')
Another longer term solution needs to be implemented. One idea is to introduce a namelist variable that would skip the reading of the datm restart data if it was turned on. In fact - the simplest thing would have been to comment out the restart read in
datm_datamode_clmncep_mod.F90
based on the namelist variable.
At any rate - this needs to be fixed in a general manner as a high priority in order for CTSM to use cmeps/cdeps as their default data model and coupling architecture.
I am labeling this as a bug since this capability does work in mct.
CDEPS currently requires the FoX library. Since ESMF is already a dependency, it should be possible to use ESMF config and read in the same information as attributes. There is precedent for configuring NUOPC components through its cap using ESMF attributes read from a config file. NOAA UFS is particularly interested in this option to remove the FoX dependency.
stream_definition_datm.xml in datm/cime_config has the 2018 and 2019 start/end years hardcoded in it, but it should use the $DATM_YR_START and $DATM_YR_END xml variables so that the case case can change them. Right now it doesn't respond to changes in either.
The 2018/2019 defaults could be put in the config_component.xml file, but they would apply to all 1PT forcing cases, but that is likely OK.
This compset is used in scripts regression tests causing test
test_j_createnewcase_user_compset_vs_alias to fail with driver nuopc.
The issue is in the docn buildnml script:
Traceback (most recent call last):
File "/glade/work/jedwards/sandboxes/cesm2_x_alpha/components/cdeps/docn/cime_config/buildnml", line 195, in <module>
_main_func()
File "/glade/work/jedwards/sandboxes/cesm2_x_alpha/components/cdeps/docn/cime_config/buildnml", line 192, in _main_func
buildnml(case, caseroot, "docn")
File "/glade/work/jedwards/sandboxes/cesm2_x_alpha/components/cdeps/docn/cime_config/buildnml", line 183, in buildnml
_create_namelists(case, confdir, inst_string, namelist_infile, nmlgen, data_list_path)
File "/glade/work/jedwards/sandboxes/cesm2_x_alpha/components/cdeps/docn/cime_config/buildnml", line 104, in _create_namelists
streams.create_stream_xml(streamlist, case, outfile, data_list_path)
File "/glade/work/jedwards/sandboxes/cesm2_x_alpha/components/cdeps/docn/cime_config/../../cime_config/stream_cdeps.py", line 130, in create_stream_xml
value = self._resolve_values(case, value)
File "/glade/work/jedwards/sandboxes/cesm2_x_alpha/components/cdeps/docn/cime_config/../../cime_config/stream_cdeps.py", line 267, in _resolve_values
match = _var_ref_re.search(value)
TypeError: expected string or buffer
Some of the datm tests in aux_cdeps are with the f10_f10_musgs grid and need to be updated to the f10_f10_mg37 grid.
For the NEON work we need to have 2018_clim and trans_2018-PD options to DATM_PRESAERO and DATM_CO2_TSERIES. I suggest that taxmode for these should be limit so it doesn't cycle or extend, and that the end year (Present Day or PD) be set to $DATM_YR_END. Right now they will also need to use a SSP-RCP scenario since we don't have historical data beyond 2015. We suggest it use the SSP3-7.0 since that's what SMYLE used.
These new options will pointed to in CTSM as detailed in this issue: ESCOMP/CTSM#1363
I'm getting a seg-fault for a mpi-serial case with intel compiler on izumi.
SMS_Vnuopc.1x1_mexicocityMEX.I2000Clm50Sp.izumi_intel.clm-default
This is with cdeps: v0.5.0
cmeps: v0.8.0
cime: cime5.8.40
It appears to fail sometime early on in dealing with the streams files.
Looks like it from reading the following NetCDF-4 file:
/project/tss/atm_forcing.datm7.GSWP3.0.5d.v1.c170516/clmforc.GSWP3.c2011.0.5x0.5.TPQWL.SCRIP.210520_ESMFmesh.nc
which also isn't in svn inputdata.
The atm.log file ends at beginning of initialization:
(atm_comp_nuopc) ny_global = 1
(atm_comp_nuopc) restfilm = null
(atm_comp_nuopc) iradsw = 1
(atm_comp_nuopc) factorFn_data = null
(atm_comp_nuopc) factorFn_mesh = null
(atm_comp_nuopc) flds_presaero = T
(atm_comp_nuopc) flds_co2 = F
(atm_comp_nuopc) flds_wiso = F
datm datamode = CLMNCEP
The traceback looks like this from the cesm.log file:
[0] (t_initf) profile_add_detail= F
[0] (t_initf) profile_papi_enable= F
[0] forrtl: severe (174): SIGSEGV, segmentation fault occurred
[0] Image PC Routine Line Source
[0] cesm.exe 00000000012D627A Unknown Unknown Unknown
[0] libpthread-2.17.s 00007F3C435BB5F0 Unknown Unknown Unknown
[0] libnetcdff.so.7.0 00007F3C4FB2DA78 netcdf_mp_nf90_ge Unknown Unknown
[0] libesmf.so 00007F3C46D643B9 esmf_ioscripmod_m Unknown Unknown
[0] libesmf.so 00007F3C46E43DA3 esmf_meshmod_mp_e Unknown Unknown
[0] libesmf.so 00007F3C46E3A305 esmf_meshmod_mp_e Unknown Unknown
[0] cesm.exe 0000000000E8882F dshr_strdata_mod_ 418 dshr_strdata_mod.F90
[0] cesm.exe 0000000000E8D2FD dshr_strdata_mod_ 228 dshr_strdata_mod.F90
[0] cesm.exe 00000000005267B0 atm_comp_nuopc_mp 346 atm_comp_nuopc.F90
Note, that a similar setup works on cheyenne: SMS_Ld1_Mmpi-serial.1x1_mexicocityMEX.I1PtClm50SpRs.cheyenne_intel.clm-default
@mvertens @jedwards4b In the last PR the following statement had the issue
foreach(DEPS streams dshr cdeps_share FoX_dom FoX_wxml FoX_sax FoX_common FoX_utils FoX_fsys)
if(NOT BLD_STANDALONE AND ${DEPS} STREQUAL "cdeps_share")
continue()
endif()
install(TARGETS ${DEPS}
EXPORT ${DEPS}
LIBRARY DESTINATION lib
COMPONENT Library)
install(EXPORT ${DEPS}
DESTINATION lib/cmake)
endforeach(COMP)
In this case, there is a mismatch in foreach and endforeach. I am not sure why it is not catch before (it might related with the used cmake version) after all my tests with different applications but endforeach(COMP) needs to be endforeach(DEPS). I am plaining to fix it, I could make another PR or directly fix. Let me know what do you think?
This is especially true for datm because the list of files is long. But, it could apply to other data models as well. Currently the minimum and maximum years for the filenames in streams is hardcoded in. The actual years that will be used is set by $DATM_YR* variables. But, for instance for CLMGSWP3v1.Solar you have this...
<file first_year="1901" last_year="2014">$DIN_LOC_ROOT_CLMFORC/atm_forcing.datm7.GSWP3.0.5d.v1.c170516/Solar/clmforc.GSWP3.c2011.0.5x0.5.Solr.%ym.nc</file>
The downside I see to this is that at initialization it will open each of the files in the list in turn and get the time information from them. This can take awhile so it seems more prudent to have the list shortened so that it only has the filenames of the years it's actually going to use.
It will also make a difference when downloading the files. If the full range is given it will download the full list, even if the user wants one or two years. I actually recommend to users that they use $DATM_YR* to get a shorter list of files using check_input_data --download, and then after they've been downloaded to increase it to download another section.
This test fails due to an incorrect DATM_YR_ALIGN
This is likely both a problem with CDEPS and cime, so I'm posting both places. The test ERS_D_Mmpi-serial_Ld5_Vnuopc.1x1_brazil.I2000Clm50FatesRs.izumi_nag.clm-FatesColdDef worked previously, but is now failing to build because of a timeout for the dwav library.
The tail of the build log looks like this:
cat: FAILED,: No such file or directory
cat: cat: No such file or directory
Running cmake for CDEPS
ERROR: Timeout waiting for /scratch/cluster/erik/tests_ctsm51d39_na/sharedlibroot.ctsm51d39_na_nag/nag/mpi-serial/debug/nothreads/nuopc/CDEPS/dwav/libdwav.a
This is with the following versions:
cdeps: cdeps0.12.4
cmeps: tag = cmeps0.13.2
cime: cime5.8.47
ctsm: ctsm5.1.dev038-84-g16ad727f8 (jedwards4b neon_compsets branch)
It worked with:
cdeps: = 0.6.0
cmeps: tag = 0.9.0
cime: branch_tags/cime5.8.42_a01
ctsm: ctsm5.1.dev038
That test is currently the only nuopc test we are running in CTSM. I also see the same problem with these two tests:
SMS_D_Mmpi-serial_Vnuopc.CLM_USRDAT.I1PtClm51Bgc.izumi_nag.clm-NEON_NIWO
SMS_D_Vnuopc.CLM_USRDAT.I1PtClm51Bgc.izumi_nag.clm-NEON_NIWO
I'm getting a fail in the build of a simple mpi-serial case as follows...
qcmd -- ./create_test SMS_D_Vnuopc_Mmpi-serial_P1x1.5x5_amazon.I2000Clm50SpRsGs.cheyenne_intel.clm-default -r . --walltime 00:20:00 --queue premium
The build fails building the datm as follows...
clm built in 32.146116 seconds
Building case in directory /glade/scratch/erik/CESM/cime/scripts/SMS_D_Vnuopc_Mmpi-serial_P1x1.5x5_amazon.I2000Clm50SpRsGs.cheyenne_intel.clm-default.20200618_185117_t9q72h
sharedlib_only is False
model_only is True
- Building atm Library
Traceback (most recent call last):
File "./case.build", line 165, in
_main_func(doc)
File "./case.build", line 155, in _main_func
success = test.build(sharedlib_only=sharedlib_only, model_only=model_only, old_build=use_old, ninja=ninja, dry_run=dry_run)
File "/glade/scratch/erik/CESM/cime/scripts/Tools/../../scripts/lib/CIME/SystemTests/system_tests_common.py", line 93, in build
model_only=(phase_name==MODEL_BUILD_PHASE))
File "/glade/scratch/erik/CESM/cime/scripts/Tools/../../scripts/lib/CIME/SystemTests/system_tests_common.py", line 121, in build_phase
self.build_indv(sharedlib_only=sharedlib_only, model_only=model_only)
File "/glade/scratch/erik/CESM/cime/scripts/Tools/../../scripts/lib/CIME/SystemTests/system_tests_common.py", line 131, in build_indv
use_old=self._old_build, ninja=self._ninja, dry_run=self._dry_run)
File "/glade/scratch/erik/CESM/cime/scripts/Tools/../../scripts/lib/CIME/build.py", line 717, in case_build
return run_and_log_case_status(functor, cb, caseroot=caseroot)
File "/glade/scratch/erik/CESM/cime/scripts/Tools/../../scripts/lib/CIME/utils.py", line 1768, in run_and_log_case_status
rv = func()
File "/glade/scratch/erik/CESM/cime/scripts/Tools/../../scripts/lib/CIME/build.py", line 711, in
save_build_provenance, use_old, ninja, dry_run)
File "/glade/scratch/erik/CESM/cime/scripts/Tools/../../scripts/lib/CIME/build.py", line 667, in _case_build_impl
lid, caseroot, cimeroot, compiler, buildlist, comp_interface))
File "/glade/scratch/erik/CESM/cime/scripts/Tools/../../scripts/lib/CIME/build.py", line 107, in _build_model
os.makedirs(build_dir)
File "/usr/lib64/python2.7/os.py", line 157, in makedirs
mkdir(name, mode)
OSError: [Errno 17] File exists: '/glade/scratch/erik/SMS_D_Vnuopc_Mmpi-serial_P1x1.5x5_amazon.I2000Clm50SpRsGs.cheyenne_intel.clm-default.20200618_185117_t9q72h/bld/atm/obj'[1] Exit 1
It looks like there are some tricky softlinks being setup that don't work for above.
(Note I also get the same issue without any extra arguments to create_test)
This is with 4427dd05147c42f19f5283793676867572138ed7 for cime.
and 5b29c3e for CDEPS,
0ed59c1 for fox
70b5daa for CMEPS
I've found that the "limit" option for taxmode can be a really good way to find simulation setups that are invalid and will produce bad results. Sometimes the "extend" option is used where it shouldn't as the first or last value in a daily (or even yearly) varying series is a horrible thing to do. As well as the "cycle" option will go back to the beginning year of a transient period when it reaches the end, which is another horrible thing to do.
The problem with limit as it's currently implemented (both in MCT and NUOPC) is that it only considers data within the years that you are running over. So it won't use data outside that range even if it's available in the time-series. In many cases with our datasets we added "extra" data before or after to eliminate this kind of problem, but that data is essentially unavailable because the algorithm doesn't allow it to be used. I think it should only use the one time-sample before and the one time-sample after the years you are running for, but if that data is there it should use it.
I found this problem in a CTSM issue:
Here's the most relevant comment regarding it.
The latest PR has removed the correct mask in the GLC fields sent by DLND. Now the mask over land seems to be set to zero in the coupler history files.
I noticed that many (all?) of the stream_definition xml files define a first_year and last_year like this:
I see two problems with this:
A simple fix is to expand these years to have a ridiculously huge range, as I did in 48a26e6
I think a cleaner fix would involve making first_year and last_year optional here. From a quick glance through the code that parses this, it looks like these may currently be required.
The temporally subsetted stream files need to be handled by the CDEPS for especially high resolution input datasets such as ERA5. To test the capability in the current version of the CDEPS, I tested two different scenarios. To do that, i modified datm.streams.xml to include the only subsetted files,
<stream_data_files>
/glade/p/cesmdata/cseg/ufs_inputdata/atm/datm7/ERA5/ERA5.TL639.2019.08.200618_subset.nc
/glade/p/cesmdata/cseg/ufs_inputdata/atm/datm7/ERA5/ERA5.TL639.2019.09.200618_subset.nc
</stream_data_files>
and then i performed following tests;
CASE 1: I created a subsetted data based on the simulation RUN_STARTDATE. So, the data start exactly from RUN_STARTDATE and covers entire simulation period.
It seems CDEPS is working in this case and picking correct index (1) from the file for the first time step.
CASE 2: In this case, i generated a subsetted file that starts an earlier date than simulation RUN_STARTDATE i.e. 2019-08-28 and again covers entire simulation period. In this case, the first data read from input file need to be belong to index 24 (for 2019-08-29) because the data file starts 1 day earlier from simulation RUN_STARTDATE in this test.
In this case, CDEPS is not picking correct date from the file and still tries to get the field from index 1 rather than index 24. I think this is due to assuming having data for entire year (via start end end years in the XML definition) and fixed time interval. To have more generic implementation, CDEPS need to look at the dates (generated by using dataset time dimension - time unit, calendar etc.) not indexes.
The problem is that stepno is used to determine this. Problem is that stepno obtained via the advancecount argument to ESMF_GetClock and is the number of times the ESMF_Clock has been
advanced. The ESMF clock is actually advanced an additional time (in order to trigger alarms) in the routine dshr_set_runclock which is the specialized routine for the model_lable_SetRunClock.
This is called each time the ModelAdvance phase is called. Hence stepno is not used to trigger the calculation of nextsw_cday.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.