[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