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

[majun]

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.

 

[oleson]

I recommend you take a look at a couple of previous posts on this subject.

https://bb.cgd.ucar.edu/cesm/threads/running-with-your-own-atmosphere-forcing.5116/#post-35714

https://bb.cgd.ucar.edu/cesm/threads/using-atmospheric-forcing-with-masked-area.5174/

 

[majun]

I recommend you take a look at a couple of previous posts on this subject.

https://bb.cgd.ucar.edu/cesm/threads/running-with-your-own-atmosphere-forcing.5116/#post-35714

https://bb.cgd.ucar.edu/cesm/threads/using-atmospheric-forcing-with-masked-area.5174/

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'

 

[oleson]

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]

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]

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]

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]

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]

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);

 

[oleson]

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]

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.

 

[oleson]

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:

1.2.4. Customizing the DATM namelist — ctsm release-clm5.0 documentation

" 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]

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?