-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
'time_beg' sometimes not initialized before being written to 'time_bounds' NetCDF variable (NetCDF files not usable by Panoply) #551
Comments
Just to clarify, standalone CICE output is read fine by panopoly but the coupled CICE output is not? Is the time axis different in those two sets of files? Is anything else in the header different in the two files? If not, could there be some bad data in the file that is creating problems? Maybe try producing a CICE history file with one field in it and see if that still fails? |
Yes
The only difference I see is that calendar...: # Standalone
$ ncdump -h iceh_inst.2005-01-01-43200.nc
netcdf iceh_inst.2005-01-01-43200 {
dimensions:
d2 = 2 ;
ni = 100 ;
nj = 116 ;
nc = 5 ;
nkice = 7 ;
nksnow = 1 ;
nkbio = 9 ;
nkaer = 11 ;
time = UNLIMITED ; // (1 currently)
nvertices = 4 ;
nf = 1 ;
variables:
double time(time) ;
time:long_name = "model time" ;
time:units = "days since 2005-01-01 00:00:00" ;
time:calendar = "Gregorian" ;
time:bounds = "time_bounds" ;
float time_bounds(time, d2) ;
time_bounds:long_name = "boundaries for time-averaging interval" ;
time_bounds:units = "days since 2005-01-01 00:00:00" ;
# ...
# Coupled
$ ncdump -h iceh_inst.2001-10-05-07200.nc
netcdf iceh_inst.2001-10-05-07200 {
dimensions:
d2 = 2 ;
ni = 528 ;
nj = 735 ;
nc = 5 ;
nkice = 7 ;
nksnow = 1 ;
nkbio = 9 ;
nkaer = 11 ;
time = UNLIMITED ; // (1 currently)
nvertices = 4 ;
nf = 1 ;
variables:
double time(time) ;
time:long_name = "model time" ;
time:units = "days since 2001-01-01 00:00:00" ;
time:calendar = "NoLeap" ;
time:bounds = "time_bounds" ;
float time_bounds(time, d2) ;
time_bounds:long_name = "boundaries for time-averaging interval" ;
time_bounds:units = "days since 2001-01-01 00:00:00"
# ...
Yeah I'll try some things. I'll try running standalone with the same namelist as the coupled run. |
My first guess would be that netcdf is struggling with the "NoLeap" calendar name. I wonder if the caps are creating problems? I believe netcdf should understand the following, http://cfconventions.org/cf-conventions/cf-conventions.html#calendar. Trying changing NoLeap to noleap in the file and see if panopoly is happier. You should be able to do this with nco or a similar tool. |
I tried that with |
I think it's the
I'm compiling with CICE/cicecore/cicedynB/analysis/ice_history.F90 Lines 1863 to 1869 in f5f487f
somehow is not reached and so that NaN gets written to the history file... I will run the model in a debugger tomorrow to try to understand how that happens. |
The NaN appears also in a standalone run when compiling with |
OK, I understand more what happens. The code that initializes CICE/cicecore/cicedynB/analysis/ice_history.F90 Line 1817 in f5f487f
but we use In any case I'll investigate more our in-house CICE4 code next week and compare. |
I'm bringing @dabail10 into the discussion since you worked on the multiple-stream history functionality (CICE-Consortium/CICE-svn-trunk@ab1c53e) for CICE 5. In that commit you removed that line in ice_init: @@ -327,7 +332,6 @@ subroutine input_data
ocn_data_format = 'bin'
#endif
- if (histfreq == '1') hist_avg = .false. ! potential conflict
if (days_per_year /= 365) shortwave = 'default' ! definite conflict
chartmp = advection(1:6) but there are still places in the code that make
Apart from these 3 places, I actually think that averaging over several time steps does work, because we have not made any changes to the averaging code in our version of CICE4. But I'd like others to confirm that my thinking is correct... |
I don't remember this very well, but it is possible I introduced a bug here. I guess I couldn't figure out how to average some streams but have others instantaneous. So, I guess I was thinking all or none. However, I would be happy to revisit this and see if there is a way to do this. I suppose making hist_avg into an array ... |
Well that would be useful but here I'm actually talking about a single stream, with CICE/cicecore/cicedynB/analysis/ice_history.F90 Lines 1817 to 1836 in f5f487f
that explicitely reset the accumulation arrays to zero (if I read the code correctly...) |
Is that not the behaviour you want? If it is step output (1) then you have nothing to accumulate. |
Could it have been a confusion between histreq_n(is)=1 and histfreq(is)='1'? The second condition would make more sense indeed if it was [...] |
@dabail10 I think there is indeed some confusion. As Fred is hinting at, we are using |
Makes sense. There are a few things in the history output that should probably be cleaned up. |
The code at the beginning of subroutine 'accum_hist' is responsible for resetting the accumulation arrays a2D, a3Dc, etc. to zero when writing snapshots, but it also resets them if "histfreq(ns) == '1'". This has been the case since ab1c53e (Many thanks to Dave Bailey (NCAR) for getting this ball rolling., 2009-06-01) [1], which implemented the multiple-stream history functionality in CICE 5. This means that averaging over multiple time steps, i.e. histfreq = '1' histfreq_n = m ! m > 1 hist_avg = .true. does not work: the accumulation arrays will always be reset to zero at the beginning of 'accum_hist' and no accumulation will happen. This also means that the variable 'time_beg' is not initialized in that configuration, since this it is initialized in the 'else' branch of that 'if' statement. Commit ab1c53e also *removed* the following line in ice_init::input_data: if (histfreq == '1') hist_avg = .false. ! potential conflict so it's unclear if that configuration was forgotten at the time. Allow overaging over multiple time steps by only resetting the accumulation arrays if 'hist_avg' is false. As a side effect, this correctly initializes the 'time_beg' variable, which avoids writing that variable uninitialized to the output files, which can lead to analysis tools failing if compiling with '-init=snan,arrays' (or similar [2]. While at it, remove a commented line in the 'else' branch since it's implemented just below. This commit does not modify neither ice_history_shared::construct_filename nor the different ice_history_write::ice_write_hist subroutines, that also assume that 'histfreq = 1' implies 'histfreq_n = 1'. They will be modified in subsequent commits. [1] CICE-Consortium/CICE-svn-trunk@ab1c53e?branch=ab1c53eaf0c4a0b0dbc65e582a5e1b35c2208a88&diff=unified#diff-aebd77751eba77ed6b6c194d4cd2e4b353258f7e903cc7877343911c9b25c283L1296-L1306 [2] Closes CICE-Consortium#551
The code at the beginning of subroutine 'accum_hist' is responsible for resetting the accumulation arrays a2D, a3Dc, etc. to zero when writing snapshots, but it also resets them if "histfreq(ns) == '1'". This has been the case since ab1c53e (Many thanks to Dave Bailey (NCAR) for getting this ball rolling., 2009-06-01) [1], which implemented the multiple-stream history functionality in CICE 5. This means that averaging over multiple time steps, i.e. histfreq = '1' histfreq_n = m ! m > 1 hist_avg = .true. does not work: the accumulation arrays will always be reset to zero at the beginning of 'accum_hist' and no accumulation will happen. This also means that the variable 'time_beg' is not initialized in that configuration, since this it is initialized in the 'else' branch of that 'if' statement. Commit ab1c53e also *removed* the following line in ice_init::input_data: if (histfreq == '1') hist_avg = .false. ! potential conflict so it's unclear if that configuration was forgotten at the time. Allow overaging over multiple time steps by only resetting the accumulation arrays if 'hist_avg' is false. As a side effect, this correctly initializes the 'time_beg' variable, which avoids writing that variable uninitialized to the output files, which can lead to analysis tools failing if compiling with '-init=snan,arrays' (or similar [2]. While at it, remove a commented line in the 'else' branch since it's implemented just below. This commit does not modify neither ice_history_shared::construct_filename nor the different ice_history_write::ice_write_hist subroutines, that also assume that 'histfreq = 1' implies 'histfreq_n = 1'. They will be modified in subsequent commits. [1] CICE-Consortium/CICE-svn-trunk@ab1c53e?branch=ab1c53eaf0c4a0b0dbc65e582a5e1b35c2208a88&diff=unified#diff-aebd77751eba77ed6b6c194d4cd2e4b353258f7e903cc7877343911c9b25c283L1296-L1306 [2] Closes CICE-Consortium#551
Hi everyone!
I'm still working on coupling CICE with NEMO in our systems and the output files that are created can't be read by Panoply (4.10.12), I get:
I can open that file in Ncview just fine (2.1.8) , so I'm not sure where the problem is, but I thought I'd ask here since I'm sure some people here know more about NetCDF than me...
Here is the header of the file (
ncdump -c iceh_inst.2001-10-05-07200.nc
):The file in question is attached, with the namelist and diagnostic output of the run that created it.
I thought for a moment that it was because of the
coordinates
attributes that is recorded as "TLON TLAT time", i.e. in a diffferent order than the variables' shape, which are all(time, nj, ni)
, but CICE standalone also produces files like these and Panoply does not complain....iceh_inst.2001-10-05-07200.tar.gz
The text was updated successfully, but these errors were encountered: