[Mitgcm-support] Note: November 2, 2000
mitgcm-support at dev.mitgcm.org
mitgcm-support at dev.mitgcm.org
Wed Jul 9 15:56:55 EDT 2003
HyperNews notification of new message. See:
http://escher.JPL.NASA.GOV:2000/HyperNews/get/forums/wkmtg/72.html
=======================================================================
NOTES FROM THE ASSIMILATION MEETING : 02 November 2000
1) BC K-filter
---------------
- The "ringing" reported last week about the meridional velocity
evolution resulting from an off-equator displacement perturbation
does seem to have something to do with waves and the
inertia-gravity band. This figure[1] shows time series (horizontal
axes, 0 to 3-days) of meridional (black) and zonal (blue)
velocities as a result of such perturbation. The locations of
these 21 stations are shown in this figure[2], which shows
meridional velocity at day8 depth 4 (initial perturbation at
j=144). The numbers on top of the time-series are the meridional
grid number, latitude and inertial period (also shown as vertical
dashed lines.) Most of the higher latitude fluctuations are at
the inertial period. The larger low-latitude fluctuations have
longer periods that, if inertia-gravity waves, cannot propagate
at higher latitudes.
- This "ringing" does not seem to have occurred in MOM. The 1st bc
mode amplitude for U, V, and displacement after 3-days from an
initial 1st mode displacement perturbation at 10N is shown in
this figure[3]. Top row is MOM, bottom row is MITgcm. Both are
based on the state transition matrix. MOM is a uniform 2-deg by
1-deg grid (80 is equator), MITgcm, of course is a stretched
grid (113 is equator).
--> Maybe the ringing has to do with the stretched meridional
grid. However, the ringing still occurs with an experiment
using an unstretched (but anisotropic) grid.
--> The qualitative similarity, nevertheless, demonstrates the
MITgcm transition matrix is sensible at least to first
approximation.
- Simulation error was estimated using the 1-day transition matrix.
This figure[4] (upper left) shows resulting simulation error
estimate (sea level, cm^2) assuming NCEP covariance as process
noise (3-day correlated winds). The pattern is more sensible
than the EOF based bc filter of last week, but are small and
values along the equator are larger to the west (prior experience
is otherwise). The eigenvalues of this matrix are small (0.94 as
opposed to over 0.99 for MOM) for some reason. The rest of the
figure above shows the resulting sl error when the state
transition matrix is multiplied by 1.056, 1.067, and 1.06.
The error on the equator becomes larger to the east when the
eigenvalues are raised. (Don't know what happened for x1.067.)
The error correlation is compact and sensible as shown here[5]
for the case of the unscaled transition matrix.
Why is the eigenvalue small?
==> It isn't because the background vertical mixing coefficient
is two orders of magnitude larger than the control.
The vertical mixing coefficient was boosted to eliminate waves
that strained T perturbation (see notes 00/09/14[6].) The
eigenvalues are hardly different even when the transition is
recomputed using the control run mixing coefficients. This
figure[7] shows elements of the transition matrix. The upper left
is the diagonal of the displacement. Blue (black) is for the
larger (smaller) vertical mixing coefficient.
In doing this calculation, it was discovered that the reason the
model failed to run using the time-mean UVTSH as the initial
condition was that the time-mean used had zero values at the
bottom. Correcting this enables us to linearize the model about
the time mean.
==> It isn't because of the restart algorithm.
The transition matrix calculation depends on the model properly
initialized following a perturbation. This figure[8] shows
evolution of meridional velocity at depth 3 for initial
displacement perturbation at 10N. The upper left is V at day 3.
The 2nd panel to the 7th show V at 12-h intervals; each
successive result follows an initialization. The similarity
between the 1st panel and the 7th demonstrates the accuracy of the
restart. The 1st panel went through only one restart, whereas
the 7th depended on six restarts.
==> Could it be because of some unrealistic leakage of energy; e.g.,
the "ringing"?
==> Could it be due to the mapping operator? The number of fine
grid points per coarse grid point is not uniform.
==> Could it be due to excessive horizontal mixing?
- The eigenvalue could be boosted by computing the state transition
matrix over a longer period (e.g., 3-days) instead of 24-h.
The mapping operator will be more accurate for such periods
because the signal will less likely be in between coarse grid
points and there will effectively be less mapping per transition
matrix period. (The mapping operator is dissipative.) However,
MOM transition was computed over 12h and it's OK.
A three-day transition does seem better. The other panels in
this previous figure[9] compares the 3-day transition matrix with
the 1-day and MOM transition. The second panel compares diagonal
elements of the displacement along 10N for the MOM 1-day
transition (black) and MITgcm (blue). MITgcm is smaller
indicating it retains less energy than MOM. The third panel
compares the same with a 3-day transition matrix. The red curve
is a direct computation of the 3-day MITgcm transition; it is
larger thus retains more energy and thus better. The fourth
panel compares the maximum displacement for columns of the
displacements along the equator. Again, the red 3-day MITgcm
transition is best.
2) Adjoint
-----------
- Initial try of the 1-year adjoint bombed. This is likely due to
the prescribed data error being too small in some locations. A
re-assimilation with corrected data error (minimum T/P error of 3
cm) runs OK. One iteration has been completed.
- The degradation of the 3-month adjoint may have been caused by
spurious signal in the individual T/P maps used every 10-days.
Degradation may be corrected by assimilating every 3-days
instead.
- New data weights (based on model-data comparison) gives similar
spatial pattern of weighted model-data difference of the 3-month
assimilation run as the weights based on data variance. This
indicates the degradation of the run will likely not improve by
changing the data weights.
- The degradation may have to do with Levitus not being a good data
set to use. Raw Levitus will be compared with TAO profiles.
- The relative impact on the 3-month adjoint of the estimated
initial condition and the winds will be evaluated.
- A bug in TAMC was discovered from comparing the two adjoint codes
of SIO. The bug was in compiling nested functions (e.g.,
sqrt(sqrt(...))); The problem can be avoided by rewriting the sqrt
by **0.5. Ralf has sent us a new version of TAMC that corrects
this bug. Ralf has also given us a beta version of his new
adjoint compiler, TAF, but this produces many error messages
related to I/O and doesn't work.
- Velocity field will be compared with Gary Lagerloef's surface
velocity estimate based on T/P (geostrophic) and SSM/I (Ekman).
3) Others
----------
- c20000630 files on guppy were corrupted because of alhena's RAID
problem back in July. The archive on /silo are believed to be
OK. Problem files have been re-ftp'ed from /silo.
Command md5sum produces a unique 32-byte code for a file, which can
be used to compare different files. It works faster than cmp.
=======================================================================
-----------------------------------------------------------------------
[1] http://escher.JPL.NASA.GOV:2000/hosts/escher/escher2/medea/if/forum_guppy/t15j2_uv.ps
[2] http://escher.JPL.NASA.GOV:2000/hosts/escher/escher2/medea/if/forum_guppy/t15j2.ps
[3] http://escher.JPL.NASA.GOV:2000/hosts/escher/escher2/medea/if/forum/t68d3.ps
[4] http://escher.JPL.NASA.GOV:2000/hosts/escher/escher2/medea/if/forum/t67.ps
[5] http://escher.JPL.NASA.GOV:2000/hosts/escher/escher2/medea/if/forum/t67b_2.ps
[6] http://escher.JPL.NASA.GOV:2000/HyperNews/get/forums/wkmtg/64.html
[7] http://escher.JPL.NASA.GOV:2000/hosts/escher/escher2/medea/if/forum/t68g.ps
[8] http://escher.JPL.NASA.GOV:2000/hosts/escher/escher2/medea/if/forum_guppy/t18b_v.ps
[9] http://escher.JPL.NASA.GOV:2000/hosts/escher/escher2/medea/if/forum/t68g.ps
More information about the MITgcm-support
mailing list