[MITgcm-support] Non-linear free-surface and vertical resolution

Jean-Michel Campin jmc at ocean.mit.edu
Sat Sep 8 10:12:27 EDT 2012


Hi Chunyan,

You will find on the publications web page (http://mitgcm.org/publications/)
the paper: "Rescaled height coordinates for accurate representation of free-surface
flows in ocean circulation models", by Adcroft, A. and J-M. Campin,
Ocean Modeling, 2004, Vol. 7 (3-4), pp 269-284.
which explain the advantages of r* coordinate and implementation in MITgcm.

The key parameter to select r* coordinate is:
> select_rStar=2, 
in the first namelist (PARM01) of the main parameter file "data".
There are few verification experiments that uses r*:
 tutorial_held_suarez_cs   (atmospheric example)
 global_ocean.cs32x15      (oceanic example) 
 global_ocean.90x40x15     (an other one)
Note that the experiment "tidal_basin_2d" is not tested on a regular basis
so it's possible that this one is not up to date (but initially, this one
was meant to be a simple example of the use of r* coordinate).

Cheers,
Jean-Michel

On Fri, Sep 07, 2012 at 04:44:47PM +0000, Chun-Yan Zhou wrote:
> Hi all,
> In my case the the amplitude of the free-surface variations(tide elevation) becomes as large as the vertical resolution near the surface, and has the following warnings:
> WARNING: hFac < hFacInf near: i,j,k,bi,bj,Thid,Iter=  49   2   1   1   1   1         0
> hFac_n-1,hFac_n,eta =  1.000000  0.637263 -1.088210E+00
> WARNING: hFac < hFacInf near: i,j,k,bi,bj,Thid,Iter=  48   2   1   1   1   1         1
> hFac_n-1,hFac_n,eta =  0.866667  0.647780 -1.056660E+00
> WARNING: hFac < hFacInf near: i,j,k,bi,bj,Thid,Iter=  49   2   1   1   1   1         1
> hFac_n-1,hFac_n,eta =  0.866667  0.635711 -1.092868E+00
> when I set the hFacInf=0.1 or smaller, the model will overflow.
> 
>  http://mitgcm.org/public/r2_manual/latest/online_documents/node42.html
> in the manual 2.10.2.5 Non-linear free-surface and vertical resolution, it mentioned that
> A better alternative to the vanishing level problem has been found and implemented recently, and rely on a different vertical coordinate r*.
> Is there any example or description to show how to use this better alternative ways?
> Any suggestion is highly appreciated!
> 
> 
> # ====================
> # | Model parameters |
> # ====================
> #
> # Continuous equation parameters
>  &PARM01
>  viscAh=1.E2,
>  viscAz=1.E-3,
>  no_slip_sides=.TRUE.,
>  no_slip_bottom=.TRUE.,
>  viscC2Smag=2.0,
>  viscAhGridMax=0.5,
>  implicitViscosity=.TRUE.,
>  implicitDiffusion=.TRUE.,
>  diffKhT=1.E2,
>  diffKzT=1.E-3,
>  diffKhS=0.E2,
>  diffKzS=0.E-5,
>  tAlpha=2.E-4,
>  sBeta =0.,
>  gravity=9.81,
>  eosType='LINEAR',
>  tempStepping=.FALSE.,
>  saltStepping=.FALSE.,
>  implicSurfPress=0.5,
>  implicDiv2DFlow=0.5,
>  rigidLid=.FALSE.,
>  implicitFreeSurface=.TRUE.,
>  readBinaryPrec=64,
>  writeBinaryPrec=32,
>  hFacMin=0.05,
>  nonlinFreeSurf=4,
>  hFacInf=0.2,
>  exactConserv=.TRUE.,
>  &
> 
> # Elliptic solver parameters
>  &PARM02
>  cg2dMaxIters=1000,
>  cg2dTargetResidual=1.E-13,
>  &
> 
> # Time stepping parameters
>  &PARM03
>  nIter0=0,
>  nTimeSteps=21600,
>  deltaT=20,
>  deltaTtracer=20,
>  cAdjFreq=0.,
>  abEps=0.02,
>  pChkptFreq=432000,
>  chkptFreq=0.0,
> #dumpFreq=7200.0,
>  dumpFreq=3600,
> #taveFreq=86400.0,
>  monitorFreq=36000.,
> # periodicExternalForcing=.TRUE.,
> # externForcingPeriod=2592000,
> # externForcingCycle=31104000,
>  pickupStrictlyMatch=.FALSE.,
>  &
> 
> # Gridding parameters
>  &PARM04
> #constant delZ= 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140.,
> #variable
> 
>  usingSphericalPolarGrid=.TRUE.,
>  delX=174*0.0625,
>  delY=226*0.0625,
>  delZ=10*3.,10*7.,10*25.,5*100.,5*180.,
>  ygOrigin=27.03125,
>  xgOrigin=117.46875,
>  &
> 
> # Input datasets
>  &PARM05
> bathyFile='topognew1.bin',
> uVelInitFile='UVEL200201.bin',
> vVelInitFile='VVEL200201.bin',
> pSurfInitFile='initeta.bin'
>  &
> Chunyan Zhou
> Division of Civil Engineering
> School of Engineering, Physics and Mathematics
> College of Art, Science and Engineering
> Fulton Building,G19
> University of Dundee
> Dundee, UK DD1 4HN
> Tel. 01382 385431
> 
> 
> 
> ________________________________________
> From: mitgcm-support-request at mitgcm.org [mitgcm-support-request at mitgcm.org]
> Sent: 05 September 2012 17:00
> To: mitgcm-support at mitgcm.org
> Subject: MITgcm-support Digest, Vol 111, Issue 7
> 
> Send MITgcm-support mailing list submissions to
>         mitgcm-support at mitgcm.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://mitgcm.org/mailman/listinfo/mitgcm-support
> or, via email, send a message with subject or body 'help' to
>         mitgcm-support-request at mitgcm.org
> 
> You can reach the person managing the list at
>         mitgcm-support-owner at mitgcm.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of MITgcm-support digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: nonlinFreeSurf=4 casue flow field change a lot (Martin Losch)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 05 Sep 2012 08:57:28 +0200
> From: Martin Losch <Martin.Losch at awi.de>
> To: mitgcm-support at mitgcm.org
> Subject: Re: [MITgcm-support] nonlinFreeSurf=4 casue flow field change
>         a lot
> Message-ID: <1E2B6C25-BE94-429D-A7DD-AE1AB46E5C7F at awi.de>
> Content-Type: text/plain; CHARSET=US-ASCII
> 
> The default boundary value for ETAN is zero. For the linear free surface, this value is not used, but for the non-linear free-surface it is, so that you specify ETAN=0 along with your u and v velocities. You might want to add ETAN boundary values that are consistent with your normal boundary velocities (say from integrating geostrophy deta/dx = f/g * v)
> 
> M.
> On Sep 5, 2012, at 12:11 AM, Chun-Yan Zhou wrote:
> 
> > Hi all,
> > I did two cases of the regional without and with nonlinFreeSurf=4.
> > The model has south and east boundary,driven by boundary u v velocity.
> > The result of case without  nonlinFreeSurf seems reasonable, with all the conditions stay same except adding nonlinFreeSurf =4, the result change a lot, especially the flow direction in the southeast corner of the model(see the picture attached).
> >
> > Can anyone tell me where is the problem? Thanks a lot.
> >
> > # ====================
> > # | Model parameters |
> > # ====================
> > #
> > # Continuous equation parameters
> > &PARM01
> > viscAh=1.E2,
> > viscAz=1.E-3,
> > no_slip_sides=.TRUE.,
> > no_slip_bottom=.TRUE.,
> > viscC2Smag=2.0,
> > viscAhGridMax=0.5,
> > implicitViscosity=.TRUE.,
> > implicitDiffusion=.TRUE.,
> > diffKhT=1.E2,
> > diffKzT=1.E-3,
> > diffKhS=0.E2,
> > diffKzS=0.E-5,
> > tAlpha=2.E-4,
> > sBeta =0.,
> > gravity=9.81,
> > eosType='LINEAR',
> > tempStepping=.FALSE.,
> > saltStepping=.FALSE.,
> > implicSurfPress=0.5,
> > implicDiv2DFlow=0.5,
> > rigidLid=.FALSE.,
> > implicitFreeSurface=.TRUE.,
> > readBinaryPrec=64,
> > writeBinaryPrec=32,
> > hFacMin=0.05,
> > nonlinFreeSurf=4,
> > hFacInf=0.2,
> > hFacSup=2.,
> > exactConserv=.TRUE.,
> > &
> >
> > # Elliptic solver parameters
> > &PARM02
> > cg2dMaxIters=1000,
> > cg2dTargetResidual=1.E-13,
> > &
> >
> > # Time stepping parameters
> > &PARM03
> > nIter0=0,
> > nTimeSteps=21600,
> > deltaT=20,
> > deltaTtracer=20,
> > cAdjFreq=0.,
> > abEps=0.02,
> > pChkptFreq=432000,
> > chkptFreq=0.0,
> > #dumpFreq=7200.0,
> > dumpFreq=43200,
> > #taveFreq=86400.0,
> > monitorFreq=36000.,
> > # periodicExternalForcing=.TRUE.,
> > externForcingPeriod=2592000,
> > externForcingCycle=31104000,
> > pickupStrictlyMatch=.FALSE.,
> > &
> >
> > # Gridding parameters
> > &PARM04
> > #constant delZ= 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140., 140.,
> > #variable
> >
> > usingSphericalPolarGrid=.TRUE.,
> > delX=174*0.0625,
> > delY=226*0.0625,
> > delZ=10*3.,10*7.,10*25.,5*100.,5*180.,
> > ygOrigin=27.03125,
> > xgOrigin=117.46875,
> > &
> >
> > # Input datasets
> > &PARM05
> > bathyFile='topognew1.bin',
> > dragQFile='dragQFile.bin',
> > uVelInitFile='UVEL200201.bin',
> > vVelInitFile='VVEL200201.bin',
> > &
> >
> > # Open-boundaries
> > &OBCS_PARM01
> > OB_Ieast=226*-1,
> > OB_Jsouth=174*1,
> > useOBCSprescribe=.TRUE.,
> > OBEuFile = 'ueast4.bin',
> > OBSuFile = 'usouth4.bin',
> > OBEvFile = 'veast4.bin',
> > OBSvFile = 'vsouth4.bin',
> >
> > &
> >
> >
> > Chunyan Zhou
> > Division of Civil Engineering
> > School of Engineering, Physics and Mathematics
> > College of Art, Science and Engineering
> > Fulton Building,G19
> > University of Dundee
> > Dundee, UK DD1 4HN
> > Tel. 01382 385431
> >
> >
> > The University of Dundee is a registered Scottish Charity, No: SC015096
> > <average current run11-9 better iter=21600.jpg><nonlinfreesurf.jpg>_______________________________________________
> > MITgcm-support mailing list
> > MITgcm-support at mitgcm.org
> > http://mitgcm.org/mailman/listinfo/mitgcm-support
> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support
> 
> 
> End of MITgcm-support Digest, Vol 111, Issue 7
> **********************************************
> 
> 
> The University of Dundee is a registered Scottish Charity, No: SC015096
> 
> 
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support



More information about the MITgcm-support mailing list