Open forsyth2 opened 7 months ago
Hi @chengzhuzhang I'm on CEST time so I just now read that there's a time axis issue. It would be helpful if you pointed me to the location of the ELM raw input file(s) that have time_bounds = [-0.0208333333333333, 31]
and of the regional average timeseries files that NCO generates from that raw input file. I'll verify NCO whether just copies the time bounds and passes it through, or whether NCO creates the problem. Are you also saying that NCO creates a bad global average from that file? Or is the problem that something downstream does not know how to interpret the negative time bounds? Or...?
OK, I found the first ELM file in the PI control simulation. It has a negative time_bounds
. That is legal. Below I show the bounds and the dates to which it corresponds:
(e3sm_unified_1.9.3_login) ac.zender@chrlogin1:/lcrc/group/e3sm2/ac.golaz/E3SMv3/v3.LR.piControl/archive/lnd/hist$ ncks -v time v3.LR.piControl.elm.h0.0001-01.nc | m
netcdf v3.LR.piControl.elm.h0.0001-01 {
dimensions:
hist_interval = 2 ;
time = UNLIMITED ; // (1 currently)
variables:
float time(time) ;
time:long_name = "time" ;
time:units = "days since 0001-01-01 00:00:00" ;
time:calendar = "noleap" ;
time:bounds = "time_bounds" ;
double time_bounds(time,hist_interval) ;
time_bounds:long_name = "history time interval endpoints" ;
data:
time = 31 ;
time_bounds =
-0.0208333333333333, 31 ;
} // group /
(e3sm_unified_1.9.3_login) ac.zender@chrlogin1:/lcrc/group/e3sm2/ac.golaz/E3SMv3/v3.LR.piControl/archive/lnd/hist$ ncks -v time --cal v3.LR.piControl.elm.h0.0001-01.nc
netcdf v3.LR.piControl.elm.h0.0001-01 {
dimensions:
hist_interval = 2 ;
time = UNLIMITED ; // (1 currently)
variables:
float time(time) ;
time:long_name = "time" ;
time:units = "days since 0001-01-01 00:00:00" ;
time:calendar = "noleap" ;
time:bounds = "time_bounds" ;
double time_bounds(time,hist_interval) ;
time_bounds:long_name = "history time interval endpoints" ;
data:
time = "0001-01-31 23:32:16" ;
time_bounds =
"0000-12-31 23:30:00", "0001-02-01" ;
} // group /
So this appears to be a corner case that is due to the model. There is no reason I can think of why a monthly mean file should be written with an initial time corresponding to 11:30 PM of the last day of the previous month. Is there something that you want ncclimo
to do when it creates timeseries of files that include such behavior? LMK. One option is to continue to treat this file as a valid January monthly mean and ignore the 30 minutes that apparently belong in the previous month. Before treating it some other way, land model people should first confirm that the 30 minutes are "real", and not some typo/bug in the model that wrote the file. Pinging @thorntonpe for comment.
I ran into the same issue when testing zppy
on BGCv2 coupled simulation.
@thorntonpe , could you comment on this issue? The script I'm testing will be passed along to Xiaoying for V3 evaluations.
@czender @forsyth2 @chengzhuzhang , I'm a little bit puzzled by this error. In my case, global_time_series
was able to PLOT atm
variables but NOT land
variables. According to my investigation, both atm
and lnd
ts
have the same length in terms of time dimension but with some minor differences such as the name of attributes and the variables time_bounds
time_bnds
. For example,
netcdf TSA_185001_201412 {
dimensions:
rgn = 3 ;
time = UNLIMITED ; // (1980 currently)
lat = 360 ;
lon = 720 ;
rgn_len = 19 ;
hist_interval = 2 ;
variables:
char region_name(rgn, rgn_len) ;
region_name:long_name = "TSA timeseries array contains area-weighted averages over these regions" ;
float TSA(time, rgn) ;
TSA:cell_methods = "time: mean area: mean" ;
TSA:coordinates = "region_name" ;
TSA:long_name = "2m air temperature" ;
TSA:missing_value = 1.e+36f ;
TSA:units = "K" ;
netcdf FLNS_185001_201412 {
dimensions:
rgn = 3 ;
time = UNLIMITED ; // (1980 currently)
ncol = 21600 ;
rgn_len = 19 ;
nbnd = 2 ;
variables:
char region_name(rgn, rgn_len) ;
region_name:long_name = "FLNS timeseries array contains area-weighted averages over these regions" ;
float FLNS(time, rgn) ;
FLNS:Sampling_Sequence = "rad_lwsw" ;
FLNS:cell_methods = "time: mean area: mean" ;
FLNS:coordinates = "region_name" ;
FLNS:long_name = "Net longwave flux at surface" ;
FLNS:missing_value = 1.e+20f ;
FLNS:units = "W/m2" ;
Since global_time_series
produced atm
plots, my initial thoughts is to manipulate those minor differences in land
variables to match atm
variables. However, the same x, y errors appear....
lnd ts files were generated and placed in /lcrc/group/e3sm2/ac.sfeng1/E3SM_Simulations/20240315.v2.LR.BGC-LNDATM.CONTRL.ne30pg2_r05_EC30to60E2r2.chrysalis/zppy/post/lnd/glb/ts/monthly/165yr
.
atm
ts files are in
/lcrc/group/e3sm2/ac.sfeng1/E3SM_Simulations/20240315.v2.LR.BGC-LNDATM.CONTRL.ne30pg2_r05_EC30to60E2r2.chrysalis/zppy/post/atm/glb/ts/monthly/165yr
the test script is /lcrc/group/e3sm2/ac.sfeng1/E3SM_Simulations/20240315.v2.LR.BGC-LNDATM.CONTRL.ne30pg2_r05_EC30to60E2r2.chrysalis/zppy/post/scripts/global_time_series_1850-2014.bash
The attribute names do not make a difference. My impression is that the plotting routine either does not like the -'ve value of the first timestep in ELM time_bounds variable, or it does not like the fact that it translates to 11:30 PM the evening before the first day of the month. Not sure which.
What happened?
See https://github.com/E3SM-Project/zppy/pull/400#issuecomment-2048589364 -- there appears to be an edge case where dimensions differ, causing
global_time_series
plots to not display.What machine were you running on?
Chrysalis
Environment
zppy dev environment, while working on #400
What command did you run?
Copy your cfg file
What jobs are failing?
No response
What stack trace are you encountering?