Scheduled Downtime
On Tuesday 24 October 2023 @ 5pm MT the forums will be in read only mode in preparation for the downtime. On Wednesday 25 October 2023 @ 5am MT, this website will be down for maintenance and expected to return online later in the morning.
Normal Operations
The forums are back online with normal operations. If you notice any issues or errors related to the forums, please reach out to help@ucar.edu

How to change atmosphere forcing in clm5.0 in a regional case?

majun

Member
Dear scientist,
I can run a regional case using GSWP3 as atmosphere forcing in clm5.0. Recently, I want to replace the default GSWP3 with my own atmosphere forcing( named CMFD, 700x400, 3hr, 0.1°). Now the CMFD data has been processed to a single file to meet the requirements of the clm atmosphere forcing(including ZBOT WIND FLDS PSRF FSDS PRECTmms SHUM TBOT ). It was stored in a daily format (i.e 2004-01-01.nc, 2004-01-02.nc .....2004-12-31.nc ). I have read related section,i.e."Customizing the DATM Namelist and Streams files" and "Running with your own atmosphere forcing" in clm user guide. However , I'm still confused about this. Here, I have some questions,

1. How to set DATM_MODE in 'env_run.xml'? CLM1PT? (however, my case is a regional case)

2. I see it also needs a domain file accompanied with the new atmosphere forcing, how to create this domain file ? Just follow the step during surface dataset creation using gen_domain ?

3. My atmosphere forcing's temporal resolution is 3 hourly, do I need to divide my data into three parts (i.e. Precip Solar TPHWL) and stored them in monthly format like GSWP3? How to store and name these data?

4. As for the atmosphere forcing's temporal resolution is 3 hourly, I see it may change the DATM settings. But I don't know how to operate it ? My guess is after ./preview_namelists, then cd CaseDocs, then modify the three stream files?

Thanks for your read, any help is highly appreciated.
 

majun

Member
Thanks for your links, I have read it carefully and did much try. However, it still failed. Could you please help me to find out what's wrong ? Here are the information of my case and the displayed error.
My study area is a land area(./mknoocnmap.pl -p 30.5,114.4 -n 80x60_wh -nx 80 -ny 60 -dx 4 -dy 3), I can run this regional case at 0.05° spatial resolution using GSWP3v1 successfully (using domain.lnd.80x60_wh_noocean.nc as atm and lnd domain file)
My own atm forcing is with 0.1° spatial resolution ,3hr temporal resolution (all of the seven variables are with 3hr) and spatial coverage of China (700x400) , all of the forcing data has been processed and cut to my study area(40x30) to a single monthly file (i.e. 2004-01.nc, 2004-02.nc .....2004-12.nc ) using matlab, they were put in $inputdata/atm/datm7/80x60_wh/CLM1PT_data.
Next I made the atm domain file(domain.lnd.40x30_wh_noocean.nc) using the following command:
(1)./mknoocnmap.pl -p 30.5,114.4 -n 40x30_wh -nx 40 -ny 30 -dx 4 -dy 3
(2)./gen_domain -m /home/shenhf/majun/clm5.0/tools/mkmapdata/map_40x30_wh_noocean_to_40x30_wh_nomask_aave_da_200708.nc -o domain.ocn_noocean.nc -l domain.lnd.40x30_wh_noocean.nc
Then case create, setup, build and submit normally, in the last step of case submit, it went wrong, and shows:
1 Invalid PIO rearranger comm max pend req (comp2io), 0
2 Resetting PIO rearranger comm max pend req (comp2io) to 64
.....
93 NetCDF: Variable not found
94 pio_support::pio_die:: myrank= -1 : ERROR: nf_mod.F90: 730 : NetCDF: Variable not found
95 application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0

I guess it may be caused by the problem of domain file, I want to ask:
(1) How to make the atm domain file in detail ? using ./gen.domain ?
(2) Cause all of my forcing data is with the same temporal resolution(3hr), do I need to separate them into solar radiation, precipitation, and other variables?
(3) Do I need to change the stream settings, like offset,mapalgo,taxmode,tintalgo,etc.

Attached are screenshots of (1) clm_error_log (2) case creation process (3) datm_in.png (4) datm.streams.txt.CLM1PT.CLM_USRDAT.png
Thanks a lot, beg for your help!

part of atm domain file is as follows:
Dimensions:
n = 1200
ni = 40
nj = 30
nv = 4
Variables:
xc
Size: 40x30
Dimensions: ni,nj
Datatype: double
Attributes:
long_name = 'longitude of grid cell center'
units = 'degrees_east'
bounds = 'xv'
.....
mask
Size: 40x30
Dimensions: ni,nj
Datatype: int32
Attributes:
long_name = 'domain mask'
note = 'unitless'
coordinates = 'xc yc'
comment = '0 value indicates cell is not active'
area
Size: 40x30
Dimensions: ni,nj
Datatype: double
Attributes:
long_name = 'area of grid cell in radians squared'
coordinates = 'xc yc'
units = 'radian2'
frac
Size: 40x30
Dimensions: ni,nj
Datatype: double
Attributes:
long_name = 'fraction of grid cell that is active'
coordinates = 'xc yc'
note = 'unitless'
filter1 = 'error if frac> 1.0+eps or frac < 0.0-eps; eps = 0.1000000E-11'
filter2 = 'limit frac to [fminval,fmaxval]; fminval= 0.1000000E-02 fmaxval= 1.000000'

Part of my new atm forcing (2004-01.nc) is as follows:
Format:
netcdf4
Global Attributes:
title = 'CMFD atmospheric data at 3-hr resolution'
conventions = 'CF-1.0'
Dimensions:
scalar = 1
lon = 40
lat = 30
time = 248
Variables:
EDGEE
Size: 1x1
Dimensions: scalar
Datatype: single
Attributes:
long_name = 'eastern edge in atmospheric data'
units = 'degrees_east'
mode = 'time-invariant'
......
LATIXY
Size: 40x30
Dimensions: lon,lat
Datatype: single
Attributes:
long_name = 'latitude '
units = 'degrees_north'
mode = 'time-invariant'
......
TBOT
Size: 40x30x248
Dimensions: lon,lat,time
Datatype: single
Attributes:
long_name = 'temperature at the lowest atm level (TBOT)'
units = 'K'
mode = 'time-invariant'
WIND
Size: 40x30x248
Dimensions: lon,lat,time
Datatype: single
Attributes:
long_name = 'wind at the lowest atm level (WIND)'
units = 'm/s'
mode = 'time-invariant'
ZBOT
Size: 40x30x248
Dimensions: lon,lat,time
Datatype: single
Attributes:
long_name = 'observational height'
units = 'm'
mode = 'time-invariant'
......
time
Size: 248x1
Dimensions: time
Datatype: single
Attributes:
long_name = 'observation time'
units = 'hours since 2004-01-01 00:00:00'
mode = 'time-invariant'
 

Attachments

  • CLM_error_log.png
    CLM_error_log.png
    167.2 KB · Views: 53
  • case_creation process.png
    case_creation process.png
    30 KB · Views: 54
  • datm_in.png
    datm_in.png
    96.9 KB · Views: 53
  • datm.streams.txt.CLM1PT.CLM_USRDAT.png
    datm.streams.txt.CLM1PT.CLM_USRDAT.png
    65.8 KB · Views: 67

oleson

Keith Oleson
CSEG and Liaisons
Staff member
Setup your case using GSWP3 forcing and modify files from there.
1) The domain file you should use in your datm.streams.txt files is not the same as the domain file you use in datm_in. It should be similar to the GSWP3 domain file (e.g., domain.lnd.360x720_gswp3.0v1.c170606.nc), but contain grid and mask information that is appropriate for your atmospheric forcing data. Create this using whatever application you normally use to create/manipulate netcdf files (matlab?)
2) Since your model time step is more frequent than your forcing data, you will need to split your forcing up into three separate streams (again, follow the GSWP3 example). This is needed because different methods of time interpolation are used for these three streams (solar uses a solar zenith angle type interpolation; temperature, humidity, etc uses linear interpolation, and precipitation uses a "nearest" interpolation).
3) I don't think you should have to change offset, mapalgo, etc
 

majun

Member
Setup your case using GSWP3 forcing and modify files from there.
1) The domain file you should use in your datm.streams.txt files is not the same as the domain file you use in datm_in. It should be similar to the GSWP3 domain file (e.g., domain.lnd.360x720_gswp3.0v1.c170606.nc), but contain grid and mask information that is appropriate for your atmospheric forcing data. Create this using whatever application you normally use to create/manipulate netcdf files (matlab?)
2) Since your model time step is more frequent than your forcing data, you will need to split your forcing up into three separate streams (again, follow the GSWP3 example). This is needed because different methods of time interpolation are used for these three streams (solar uses a solar zenith angle type interpolation; temperature, humidity, etc uses linear interpolation, and precipitation uses a "nearest" interpolation).
3) I don't think you should have to change offset, mapalgo, etc
thanks so much ,I will have a try soon
 

majun

Member
Setup your case using GSWP3 forcing and modify files from there.
1) The domain file you should use in your datm.streams.txt files is not the same as the domain file you use in datm_in. It should be similar to the GSWP3 domain file (e.g., domain.lnd.360x720_gswp3.0v1.c170606.nc), but contain grid and mask information that is appropriate for your atmospheric forcing data. Create this using whatever application you normally use to create/manipulate netcdf files (matlab?)
2) Since your model time step is more frequent than your forcing data, you will need to split your forcing up into three separate streams (again, follow the GSWP3 example). This is needed because different methods of time interpolation are used for these three streams (solar uses a solar zenith angle type interpolation; temperature, humidity, etc uses linear interpolation, and precipitation uses a "nearest" interpolation).
3) I don't think you should have to change offset, mapalgo, etc
thanks for your kind help, it works. I do as follows:
(1) Setup my case using GSWP3 forcing and modify files from there
(2) create a new domain file which is matched with atm forcing.
(3) modify the three stream files
 

majun

Member
Setup your case using GSWP3 forcing and modify files from there.
1) The domain file you should use in your datm.streams.txt files is not the same as the domain file you use in datm_in. It should be similar to the GSWP3 domain file (e.g., domain.lnd.360x720_gswp3.0v1.c170606.nc), but contain grid and mask information that is appropriate for your atmospheric forcing data. Create this using whatever application you normally use to create/manipulate netcdf files (matlab?)
2) Since your model time step is more frequent than your forcing data, you will need to split your forcing up into three separate streams (again, follow the GSWP3 example). This is needed because different methods of time interpolation are used for these three streams (solar uses a solar zenith angle type interpolation; temperature, humidity, etc uses linear interpolation, and precipitation uses a "nearest" interpolation).
3) I don't think you should have to change offset, mapalgo, etc
thanks for your kind help, it works. I do as follows:
(1) Setup my case using GSWP3 forcing and modify files from there
(2) create a new domain file which is matched with atm forcing.
(3) modify the three stream files
Hi, olseon, under your kind help, I have successfully replace the default GSWP3 forcing with my atm forcing (named CMFD, all of the seven forcing variable is with 3hr and 0.1° resolution) and it works. Generally, driving by the new CMFD forcing, the result is fine, however, the simulated dirunal cycle of LST (2004 average) of my study region is unreal(with a outlier in UTC 10.30 am), see attached file1. It is reasonable under the condition driviing by GSWP3, see attached file2. The CMFD data has been validated by many people. So I guess the error is attributed to my data processing or model setting. Follow your tips, I split my forcing up into three separate streams (follow the GSWP3 example) and stored in monthly format and didn't change offset, mapalgo, etc. Do your know what's wrong? Thanks a lot, you have helped me so much, I can't express how gratitude I am!
 

oleson

Keith Oleson
CSEG and Liaisons
Staff member
GSWP3.pngCMFD.png

Just curious, what CLM variable are you using to represent LST?

They don't look too different, other than the anomaly at 10:30. One thing to try is to compare the average diurnal cycle of the forcing variables (FSDS, FLDS, QBOT, TBOT, etc.) with LST and see if any of them are correlated.
Another approach is to output a set of forcing and model variables at the time resolution of the model (half-hourly or hourly). It could be that some or all of the time dimension of the forcing is not lined up with the model time. We see this sometimes when incoming solar radiation is not lined up with the cosine of the solar zenith angle in the model (i.e., when the model thinks the sun should be above or below the horizon). Although this usually shows up at the beginning or end of the model day.
 

majun

Member
Hi, olseon, under your kind help, I have successfully replace the default GSWP3 forcing with my atm forcing (named CMFD, all of the seven forcing variable is with 3hr and 0.1° resolution) and it works. Generally, driving by the new CMFD forcing, the result is fine, however, the simulated dirunal cycle of LST (2004 average) of my study region is unreal(with a outlier in UTC 10.30 am), see attached file1. It is reasonable under the condition driviing by GSWP3, see attached file2. The CMFD data has been validated by many people. So I guess the error is attributed to my data processing or model setting. Follow your tips, I split my forcing up into three separate streams (follow the GSWP3 example) and stored in monthly format and didn't change offset, mapalgo, etc. Do your know what's wrong? Thanks a lot, you have helped me so much, I can't express how gratitude I am!
View attachment 518View attachment 519

Just curious, what CLM variable are you using to represent LST?

They don't look too different, other than the anomaly at 10:30. One thing to try is to compare the average diurnal cycle of the forcing variables (FSDS, FLDS, QBOT, TBOT, etc.) with LST and see if any of them are correlated.
Another approach is to output a set of forcing and model variables at the time resolution of the model (half-hourly or hourly). It could be that some or all of the time dimension of the forcing is not lined up with the model time. We see this sometimes when incoming solar radiation is not lined up with the cosine of the solar zenith angle in the model (i.e., when the model thinks the sun should be above or below the horizon). Although this usually shows up at the beginning or end of the model day.
The CLM variable I am using to represent LST is 'TSKIN' . Follow your suggestion, the forcing variables (FSDS, FLDS, QBOT, TBOT) of model output variables has been output at half-hourly time resolution(see the attached picture). I also output the original 3hr CMFD and GSWP3 FSDS in 2004-7-31(see attached picture). I found it is the problem of FSDS ( I used downward shortwave radiation in CMFD ). As you said, it may be caused by the reason that incoming solar radiation is not lined up with the cosine of the solar zenith angle in the model. I think its the time-interpolation method I used in incident solar is wrong. I see in clm user guide "Example of DATM stream files with your own forcing for 3-hourly data" , the offset of prec is -5400, while solar is -10800 and others is -5400. I set it all to zero. Meanwhile, I write the time dimension of incident solar from 0 (i.e. time=0:3:669,take February as an example), do you know what's wrong and how should I do to fix it ?
Following is the matlab code to write CMFD incident solar into the format of GSWP3(take February as an example):

clc;
netcdf.setDefaultFormat('NC_FORMAT_NETCDF4')
lat0=15.05:0.1:54.95;
lon0=70.05:0.1:139.95;
for i=1:700
for j=1:400
latvalue(i,j)=lat0(j);
lonvalue(i,j)=lon0(i);
end
end
EDGEE=140;
EDGEN=55;
EDGES=15;
EDGEW=70;
LATIXY=latvalue;
LONGXY=lonvalue;

FSDS=ncread('srad_CMFD_V0106_B-01_03hr_010deg_200402.nc','srad'); %incident solar (FSDS)
FSDS=FSDS(:,:,1:224) %clm only has 28 days in February in 2004

time = (0:3:669)';
filename='solar-2004-02.nc'

ncid= netcdf.create(filename,'NC_NOCLOBBER'); %1 create nc file

%2 Defining dimensions
dimis = netcdf.defDim(ncid,'scalar',1);
dimidx = netcdf.defDim(ncid,'lon',700);
dimidy = netcdf.defDim(ncid,'lat',400);
dimit = netcdf.defDim(ncid,'time',224);

%3 Defining variables
id1 = netcdf.defVar(ncid,'EDGEE','float',[dimis]);
id2 = netcdf.defVar(ncid,'EDGEN','float',[dimis]);
id3 = netcdf.defVar(ncid,'EDGES','float',[dimis]);
id4 = netcdf.defVar(ncid,'EDGEW','float',[dimis]);
id5 = netcdf.defVar(ncid,'LATIXY','float',[dimidx dimidy]);
id6 = netcdf.defVar(ncid,'LONGXY','float',[dimidx dimidy]);
%id7 = netcdf.defVar(ncid,'TBOT','float',[dimidx dimidy dimit]);
%id8 = netcdf.defVar(ncid,'SHUM','float',[dimidx dimidy dimit]);
%id9 = netcdf.defVar(ncid,'PRECTmms','float',[dimidx dimidy dimit]);
id10 = netcdf.defVar(ncid,'FSDS','float',[dimidx dimidy dimit]);
%id11 = netcdf.defVar(ncid,'PSRF','float',[dimidx dimidy dimit]);
%id12 = netcdf.defVar(ncid,'FLDS','float',[dimidx dimidy dimit]);
%id13 = netcdf.defVar(ncid,'WIND','float',[dimidx dimidy dimit]);
%id14 = netcdf.defVar(ncid,'ZBOT','float',[dimidx dimidy dimit]);
id15 = netcdf.defVar(ncid,'time','float',[dimit]);

%4 Complete the NetCDF file definition mode
netcdf.endDef(ncid);

%5 Write the data to the NetCDF file
netcdf.putVar(ncid,id1,EDGEE)
netcdf.putVar(ncid,id2,EDGEN)
netcdf.putVar(ncid,id3,EDGES)
netcdf.putVar(ncid,id4,EDGEW)
netcdf.putVar(ncid,id5,LATIXY)
netcdf.putVar(ncid,id6,LONGXY)
%netcdf.putVar(ncid,id7,TBOT)
%netcdf.putVar(ncid,id8,SHUM)
%netcdf.putVar(ncid,id9,PRECTmms)
netcdf.putVar(ncid,id10,FSDS)
%netcdf.putVar(ncid,id11,PSRF)
%netcdf.putVar(ncid,id12,FLDS)
%netcdf.putVar(ncid,id13,WIND)
%netcdf.putVar(ncid,id14,ZBOT)
netcdf.putVar(ncid,id15,time)

netcdf.putAtt(ncid,netcdf.getConstant('NC_GLOBAL'),'title','CMFD atmospheric data at 3-hr/0.1° resolution')
netcdf.putAtt(ncid,netcdf.getConstant('NC_GLOBAL'),'conventions','CF-1.0')

netcdf.putAtt(ncid,id1,'long_name','eastern edge in atmospheric data');
netcdf.putAtt(ncid,id1,'units','degrees_east');
netcdf.putAtt(ncid,id1,'mode','time-invariant');

netcdf.putAtt(ncid,id2,'long_name','northern edge in atmospheric data');
netcdf.putAtt(ncid,id2,'units','degrees_north');
netcdf.putAtt(ncid,id2,'mode','time-invariant');

netcdf.putAtt(ncid,id3,'long_name','southern edge in atmospheric data');
netcdf.putAtt(ncid,id3,'units','degrees_north');
netcdf.putAtt(ncid,id3,'mode','time-invariant');

netcdf.putAtt(ncid,id4,'long_name','western edge in atmospheric data');
netcdf.putAtt(ncid,id4,'units','degrees_east');
netcdf.putAtt(ncid,id4,'mode','time-invariant');

netcdf.putAtt(ncid,id5,'long_name','latitude ');
netcdf.putAtt(ncid,id5,'units','degrees_north');
netcdf.putAtt(ncid,id5,'mode','time-invariant');

netcdf.putAtt(ncid,id6,'long_name','longitude ');
netcdf.putAtt(ncid,id6,'units','degrees_east');
netcdf.putAtt(ncid,id6,'mode','time-invariant');

netcdf.putAtt(ncid,id10,'long_name','incident solar (FSDS)');
netcdf.putAtt(ncid,id10,'units','W/m2');
netcdf.putAtt(ncid,id10,'mode','time-dependent');

netcdf.putAtt(ncid,id15,'long_name','observation time');
netcdf.putAtt(ncid,id15,'units','hours since 2004-02-01 00:00:00');
netcdf.putAtt(ncid,id15,'mode','time-dependent');
netcdf.putAtt(ncid,id15,'calendar','noleap');
% close file
netcdf.close(ncid);
 

Attachments

  • CMFD_FLDS.png
    CMFD_FLDS.png
    59.8 KB · Views: 36
  • CMFD_FSDS.png
    CMFD_FSDS.png
    63 KB · Views: 23
  • CMFD_TBOT.png
    CMFD_TBOT.png
    119.1 KB · Views: 20
  • CMFD_QBOT.png
    CMFD_QBOT.png
    139.3 KB · Views: 18
  • GSWP3_FSDS.png
    GSWP3_FSDS.png
    62.5 KB · Views: 18
  • original_CMFD_FSDS.png
    original_CMFD_FSDS.png
    57.5 KB · Views: 20
  • original_GSWP3_FSDS.png
    original_GSWP3_FSDS.png
    54.4 KB · Views: 33

oleson

Keith Oleson
CSEG and Liaisons
Staff member
The solar radiation seems to peak three hours later in the CMFD case than GSWP3. You could try experimenting with the offset value in the streams file, or revise your script to write the data so that it lines up with GSWP3. I don't know matlab so I can't help there.
 

majun

Member
The solar radiation seems to peak three hours later in the CMFD case than GSWP3. You could try experimenting with the offset value in the streams file, or revise your script to write the data so that it lines up with GSWP3. I don't know matlab so I can't help there.
Thanks, oleson. I have set the offset value in user_datm.streams.txt.CLMGSWP3v1.Precip/Solar/TPQW to -5400 -10800 -5400 accroding to the example 5.8 in user guide. However, when ./case.submit, it came wrong and shows :
(shr_strdata_advance) ERROR: dt limit1 0.25000000000000000 0.12500000000000000 1.5000000000000000
(shr_strdata_advance) ERROR: dt limit2 20040101 5400 20040101 16200
ERROR: (shr_strdata_advance) ERROR dt limit for stream
Do you know how to fix it out ? (since all of my forcing variable is 3hr and I write the time dimension from UTC 0:00), screen shots of cesm.log and datm_in are attached below. Thanks again.
 

Attachments

  • cesm.log.png
    cesm.log.png
    45.9 KB · Views: 39
  • datm_in.png
    datm_in.png
    37.9 KB · Views: 41

oleson

Keith Oleson
CSEG and Liaisons
Staff member
I'm not sure where those offsets you are trying came from. The GSWP3 forcing data all have zero offsets.
In reading more about this in the CLM5 User's Guide:


" offset is the time offset in seconds to give to each stream of data. Normally it is NOT used because the time-stamps for data is set correctly for each stream of data. Note, the offset may NEED to be adjusted depending on the taxmode described above, or it may need to be adjusted to account for data that is time-stamped at the END of an interval rather than the middle or beginning of interval. The offset can is set in the stream file rather than on the stream namelist. For data with a taxmode method of coszen the time-stamp needs to be for the beginning of the interval, while for other data it should be the midpoint. The offset can be used to adjust the time-stamps to get the data to line up correctly."

" For coszen the time-stamps of the data should correspond to the beginning of the interval the data is measured for. Either make sure the time-stamps on the datafiles is set this way, or use the offset described above to set it."

" In CLMGSWP3v1 mode the GSWP3 NCEP forcing dataset is used and all of it’s data is on a 3-hourly interval. Like CLM_QIAN the dataset is divided into those three data streams: solar, precipitation, and everything else (temperature, pressure, humidity, Long-Wave down and wind). The time-stamps of the data were also adjusted so that they are the beginning of the interval for solar, and the middle for the other two. Because, of this the offset is set to zero, and the tintalgo is: coszen, nearest, and linear for the solar, precipitation and other data respectively."

So it may be that your CMFD data is time-stamped at the end of an interval rather than the beginning of an interval. My suggestion was to use offset to test this hypothesis. Alternatively, you could write the data itself such that the data is shifted.
 

majun

Member
Dear oleson,
I checked the origional CMFD solar again, and make a comparsion with GSWP3 in 2004-07-31 and 2004-07 and found it is reasonable(see attached file). The solar(including FSDS and FLDS) in CMFD is 3-hourly mean (from −1.5hr to +1.5hr) surface downward shortwave(longwave) radiation, while precipitation is 3-hourly mean (from −3.0hr to 0.0hr) precipitation rate. I see the clm model needs to set the time axis from 00:00 UTC, so I write all of the seven forcing variables from 00:00 UTC and set all the offsets to zero, then an unexpected lst value has occurred in UTC 10:30 as I repoted before.

As you say " So it may be that your CMFD data is time-stamped at the end of an interval rather than the beginning of an interval. My suggestion was to use offset to test this hypothesis. Alternatively, you could write the data itself such that the data is shifted." I think CMFD data is time-stamped at the middle of an interval. I changed the offset of solar in user_datm.streams.txt.CLMGSWP3v1.Solar to -5400/-10800, however it came wrong when ./case submit:

NetCDF: Invalid dimension ID or name
NetCDF: Invalid dimension ID or name
NetCDF: Invalid dimension ID or name
NetCDF: Invalid dimension ID or name
NetCDF: Invalid dimension ID or name
NetCDF: Variable not found
NetCDF: Variable not found
(shr_strdata_advance) ERROR: for stream 2
(shr_strdata_advance) ERROR: dt limit1 0.25000000000000000 0.12500000000000000 1.5000000000000000
(shr_strdata_advance) ERROR: dt limit2 20040101 5400 20040101 16200
ERROR: (shr_strdata_advance) ERROR dt limit for stream
(shr_strdata_advance) ERROR: for stream 2
(shr_strdata_advance) ERROR: for stream 2
(shr_strdata_advance) ERROR: dt limit1 0.25000000000000000 0.12500000000000000 1.5000000000000000
(shr_strdata_advance) ERROR: dt limit2 20040101 5400 20040101 16200
ERROR: (shr_strdata_advance) ERROR dt limit for stream
(shr_strdata_advance) ERROR: for stream 2
(shr_strdata_advance) ERROR: dt limit1 0.25000000000000000 0.12500000000000000 1.5000000000000000
(shr_strdata_advance) ERROR: dt limit2 20040101 5400 20040101 16200
ERROR: (shr_strdata_advance) ERROR dt limit for stream
(shr_strdata_advance) ERROR: dt limit1 0.25000000000000000 0.12500000000000000 1.5000000000000000
(shr_strdata_advance) ERROR: dt limit2 20040101 5400 20040101 16200
ERROR: (shr_strdata_advance) ERROR dt limit for stream
(shr_strdata_advance) ERROR: for stream 2
ERROR: (shr_strdata_advance) ERROR dt limit for stream
(shr_strdata_advance) ERROR: dt limit1 0.25000000000000000 0.12500000000000000 1.5000000000000000
(shr_strdata_advance) ERROR: dt limit2 20040101 5400 20040101 16200
ERROR: (shr_strdata_advance) ERROR dt limit for stream
Do you know how to change the offset?

Thanks again. What's more , I didn't use spinup and ZBOT, does it matter?
 

Attachments

  • CMFD_FSDS_0228.png
    CMFD_FSDS_0228.png
    53.8 KB · Views: 36
  • CMFD_FSDS_0731.png
    CMFD_FSDS_0731.png
    41.1 KB · Views: 15
  • GSWP3_FSDS_0228.png
    GSWP3_FSDS_0228.png
    56.6 KB · Views: 11
  • GSWP3_FSDS_0731.png
    GSWP3_FSDS_0731.png
    54.3 KB · Views: 34
Top