Hi Dawn,
The differences you see might be coming up if your data is located at
the start of each month; the climatological axes including month_reg
are defined with their coordinates in the middle of each month. This
would cause an apparent shift in the result.
In that case you would need to first regrid your data onto a monthly
axis with the coordinates in the middle of the months. This is all
described in the Users Guide in the Modulo Regridding discussion;
several paragraphs down there is a paragraph that starts:
"Unlike other
transformations and regridding, modulo regridding is performed as an unweighted
average: ... " Following this is an example and commands to do
the regridding correctly
To see where your data coordinates are centered, look at the dates when
you list the time coordinates
yes? list/L=1:12 t[gt=v]
ferret ocean wrote:
Hi, Steve,
Thanks for your professional advices. I have to say that
I need some time to understand what you said. After using let v_clm =
v[gt=month_reg@MODNGD], fill v_clm[l=1], the value is from 0-10, is it
helpful to solve this problem?
Actually, I just want to get climatological Jan like tt, (simply
the mean of every Jan).
Dawn
Hi
Dawn,
After a few moment's reflection I realized that I may have given you a
bum steer with the advice below. The fact that the @mod regridding
uses an unweighted average makes it relatively insensitive to having
your time axis cells represented with great precision -- though it may
be sensitive if your axis uses the 1st of the month (rather than
mid-month) as the locations of the time axis points. (Some time axes do
this.)
To diagnose the behavior that you are seeing have a look at the
@MODNGD results
let v_clm = v[gt=month_reg@MODNGD]
which will tell you how many time points from your native axis are used
in the modulo calculation onto the climatological axis. See anything
peculiar?
- Steve
======================================
Hi Dawn,
You have chosen to regrid to axis month_reg instead of month_irreg.
This means that the calendar you are using consists of 12 equally-sized
months, instead of a true Gregorian climatological calendar. That's
the heart of your problem, probably.
To ensure that the climatological regridding is completely accurate you
have to make sure that the calendar axis of the original data exactly
matches the target climatological axis. From the Ferret Users' Guide:
Unlike
other transformations and regridding, modulo regridding is performed as
an unweighted average: each non-missing source point
contributes 100% of its weight to the destination grid box within which
it falls. If the source and destination axes are not properly aligned
this can lead to apparent shifts in the data. For example, if a monthly
time series has data points at the first of each month and a
climatological axis is defined at midmonths, then unweighted modulo
averaging will lead to an apparent 1/2-month shift. To avoid situations
of this type simply regrid to the climatological axis using linear
interpolation prior to the modulo regridding.
(I believe that the above unweighted behavior was selected specifically
to address the messy aspects of climatological regridding, where the
existence of leap years compromises the "modulo" nature of the calendar
axis.)
You can check the time axis of "atl.nc" using the SHOW GRID (or SHOW
AXIS) command:
SHOW GRID/T v
==> Make sure that TBOXLO of each month is the 1st of the month at
hour 00:00
If you try the SHOW AXIS command on the month_irreg axis you'll see how
the leap-year length of February complicates climatological calendar.
The length of Feb is not an integer number of days, so all months after
February appear to have a 5 hour and 49 minute offset. But the TBOX
values show that the length of each month is correct.
yes? use climatological_axes
*** NOTE: regarding
/home/porter/tmap/ferret/linux/go/climatological_axes.cdf ...
*** NOTE: Climatological axes SEASONAL_REG, MONTH_REG, and
MONTH_IRREG defined
yes? show axis/t MONTH_IRREG
name axis # pts start end
MONTH_IRREG TIME 12mi 16-JAN 12:00
15-DEC 17:49
T0 = 01-JAN-0000 00:00:00
Axis span (to cell edges) = 365.2425 (modulo length = axis
span)
L T TBOX
TBOXLO TSTEP (DAYS)
1> 16-JAN 12:00:00 31 01-JAN
00:00:00 15.5
2> 15-FEB 02:54:36 28.2425 01-FEB
00:00:00 45.12125
3> 15-MAR 17:49:12 31 29-FEB
05:49:12 74.7425
4> 15-APR 05:49:12 30 31-MAR
05:49:12 105.2425
5> 15-MAY 17:49:12 31 30-APR
05:49:12 135.7425
6> 15-JUN 05:49:12 30 31-MAY
05:49:12 166.2425
7> 15-JUL 17:49:12 31 30-JUN
05:49:12 196.7425
8> 15-AUG 17:49:12 31 31-JUL
05:49:12 227.7425
9> 15-SEP 05:49:12 30 31-AUG
05:49:12 258.2425
10> 15-OCT 17:49:12 31 30-SEP
05:49:12 288.7425
11> 15-NOV 05:49:12 30 31-OCT
05:49:12 319.2425
12> 15-DEC 17:49:12 31 30-NOV
05:49:12 349.7425
- Steve
==============================
ferret ocean wrote:
Dear ferreters,
The following script provide two ways to calculate
climatology. But I am confused with different results.
use atl.nc
set reg/y=43
show data
V Meridional Component of Velocit 1:61
1:31 1:23 1:156
U Zonal Component of Velocity 1:61 1:30
1:23 1:156
climatological_axes
CANCEL DATA climatological_axes
let v_clm = v[gt=month_reg@MOD]
! the first way to get Jan climatology
fill v_clm[l=1]
! the second way to get Jan climatology (the most stupid way)
let a=v[l=1]+v[l=13]+v[l=25]+v[l=37]+v[l=49];
let b=v[l=61]+v[l=73]+v[l=85]+v[l=97]+v[l=109];
let c=v[l=121]+v[l=133]+v[l=145]
let tt=(a+b+c)/13
fill tt
Of course, it has the similar results between the figure of
"fill v_clm[l=1]" and that of "fill tt", but still different.
Why? The calendar of the data is Gregorian, it might be the
reason?
Dawn
Expecting? Get great news right away with email
Auto-Check.
Try the Yahoo!
Mail Beta.
-- -- Steve Hankin, NOAA/PMEL -- Steven.C.Hankin@xxxxxxxx 7600 Sand Point Way NE, Seattle, WA 98115-0070 ph. (206) 526-6080, FAX (206) 526-6744
Expecting? Get great news right away with email
Auto-Check.
Try the Yahoo!
Mail Beta.
--
~> ~> ~> ~> ~> ~> ~> ~> ~> ~> ~>
Ansley Manke, NOAA/PMEL ansley.b.manke@xxxxxxxx
7600 Sand Point Way NE, Seattle WA
Phone 206-526-6246, FAX 206-526-6744
|