[MITgcm-support] how to compute MON ke_vol?

Martin Losch Martin.Losch at awi.de
Mon Sep 3 07:43:14 EDT 2012 

It's "just" the volume of the domain, and it's computed in pkg/monitor/mon_ke.F

M.

On Sep 1, 2012, at 5:10 PM, Chun-Yan Zhou wrote:

> Hi all,
> 
> I always find the MON ke_vol =  in the output file,but can't find the code to compute it. Is there anyone know the meaning of this parameter and how to compute it?
> 
> Thanks a lot
> 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: 27 August 2012 17:00
> To: mitgcm-support at mitgcm.org
> Subject: MITgcm-support Digest, Vol 110, Issue 19
> 
> 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: vertical velocities in high-res runs (Andreas Klocker)
>   2. changes in the use of "genmake_local" (Jean-Michel Campin)
>   3. Re: using gather/scatter to work with global fields
>      (Jean-Michel Campin)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 27 Aug 2012 18:59:08 +1000
> From: Andreas Klocker <andreas.klocker at anu.edu.au>
> To: mitgcm-support at mitgcm.org
> Subject: Re: [MITgcm-support] vertical velocities in high-res runs
> Message-ID: <503B36DC.1040306 at anu.edu.au>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Hi Jody,
> 
> Thanks for those ideas! We're just trying a linear EOS and we're looking
> at the horizontal diffusivities. I'll let you know how we go. If anyone
> has got any other ideas I'd be happy to hear them!
> 
> cheers,
> Andreas
> 
> On 26/08/12 06:23, Jody Klymak wrote:
>> Hi Andreas,
>> 
>> And you are happy w/ all the other vertical velocities?  Maybe turn off the non-linear EOS and use a linear one to start? Is there something interesting about our T/S relationship at those isopycnals that could interact with JMD95Z in funny ways, i.e. produce grid scale double diffusion?  I don't think KPP or Smagorinsky would help get rid of that.  You could also look at your horizontal diffusivities (not just viscosities).
>> 
>> I have to say, that your data file is full of options I've never heard of or used.  Did you think about trimming most of them out, and then adding them back in one by one until you get the physics you want?
>> 
>> Good luck,  Jody
>> 
>> On Aug 23, 2012, at  18:43 PM, Andreas Klocker wrote:
>> 
>>> Hi everyone,
>>> 
>>> I've got a little problem with vertical velocities in I high-res run which I don't understand and I have no idea how to get rid of that problem.
>>> 
>>> The model is a channel with realistic topography, 1/20 deg resolution, 150 vertical layers, see below data file for more info.
>>> 
>>> The problem: As you can see in the attached figure of the vertical velocity I always get two lines (which not quite follow isopycnals) which have very strong grid-scale vertical velocities along them which do not make sense. I tried both advection scheme 7 and 33 and it doesn't make much of a difference. When I add more Smagorinsky visc. the whole velocity filed gets much smoother and less energetic but the problem of the grid-scale noise doesn't change. If I use KPP it produces large vertical diff. in those regions but the problem doesn't go away...I'm not sure what else to try...
>>> 
>>> Has anyone got an idea what could cause that problem and how to solve it?
>>> 
>>> cheers,
>>> Andreas
>>> 
>>> # Continuous equation parameters
>>> &PARM01
>>> tRef               = 150*5.0,
>>> sRef               = 150*34.5,
>>> viscAr= 5.6614e-04,
>>> diffKrT=1.e-5,
>>> diffKrS=1.e-5,
>>> no_slip_sides=.FALSE.,
>>> no_slip_bottom=.TRUE.,
>>> rhonil=1027.5,
>>> rhoConstFresh=999.8,
>>> eosType='JMD95Z',
>>> # hFacMinDr=50.,
>>> # hFacMin=0.5,
>>> hFacInf=0.01,
>>> hFacSup=2.,
>>> select_rStar=2,
>>> nonlinFreeSurf=4,
>>> implicitDiffusion=.TRUE.,
>>> implicitViscosity=.TRUE.,
>>> # ivdc_kappa=100.,
>>> viscC4Leith=2.,
>>> viscC4Leithd=2.,
>>> viscC2Leith=1.5,
>>> viscC2Leithd=1.5,
>>> viscA4GridMax=0.5,
>>> viscC2Smag=1.5,
>>> # viscA4=2.0E8,
>>> # viscAhD=60,
>>> useAreaViscLength=.TRUE.,
>>> sideDragFactor=0.,
>>> # highOrderVorticity  = .TRUE.,
>>> useAbsVorticity=.TRUE.,
>>> selectVortScheme=2,
>>> selectKEscheme=3,
>>> bottomDragQuadratic = 0.0025,
>>> tempAdvScheme=7,
>>> saltAdvScheme=7,
>>> StaggerTimeStep=.TRUE.,
>>> multiDimAdvection=.TRUE.,
>>> vectorInvariantMomentum=.TRUE.,
>>> implicitFreeSurface=.TRUE.,
>>> exactConserv=.TRUE.,
>>> # debuglevel=4,
>>> convertFW2Salt=-1
>>> useRealFreshWaterFlux=.TRUE.,
>>> useSingleCPUio=.TRUE.,
>>> globalFiles=.TRUE.,
>>> allowFreezing=.TRUE.,
>>> # useJamartWetPoints=.TRUE.,
>>> &
>>> 
>>> --
>>> ===============================================
>>> Dr. Andreas Klocker
>>> Research Fellow
>>> 
>>> Center of Excellence for Climate System Science
>>> &
>>> Geophysical Fluid Dynamics Group
>>> Research School of Earth Sciences
>>> Room J7.221, Jaeger 7 Building
>>> The Australian National University
>>> Canberra ACT 0200 Australia
>>> 
>>> T:     +61 2 6125 0920
>>> M:     +61 437 870 182
>>> W:     http://web.mit.edu/aklocker/www/
>>> skype: andiklocker
>>> ===============================================
>>> 
>>> <w_vertical_slice.png>_______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>> --
>> Jody Klymak
>> http://web.uvic.ca/~jklymak/
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
> 
> --
> ===============================================
> Dr. Andreas Klocker
> Research Fellow
> 
> Center of Excellence for Climate System Science
> &
> Geophysical Fluid Dynamics Group
> Research School of Earth Sciences
> Room J7.221, Jaeger 7 Building
> The Australian National University
> Canberra ACT 0200 Australia
> 
> T:     +61 2 6125 0920
> M:     +61 437 870 182
> W:     http://web.mit.edu/aklocker/www/
> skype: andiklocker
> ===============================================
> 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 27 Aug 2012 09:44:37 -0400
> From: Jean-Michel Campin <jmc at ocean.mit.edu>
> To: mitgcm-support at mitgcm.org
> Subject: [MITgcm-support] changes in the use of "genmake_local"
> Message-ID: <20120827134437.GA4163 at ocean.mit.edu>
> Content-Type: text/plain; charset=us-ascii
> 
> Hi,
> 
> Changes have been made last Friday (Aug 24) to genmake2 regarding the
> use of the local config file "genmake_local": it is now sourced after
> processing all the genmake2 command arguments (as opposed to before
> in the previous version). The main reason for this modification is
> to offer more possibilities in the use of this local config file.
> 
> In practice, after updating your MITgcm code:
> 1) if you are not using such local config file "genmake_local",
>  nothing will change.
> 2) if the instructions in your genmake_local file do not conflict
>  with the list of arguments that you provide to the gemake2 command,
>  nothing will change.
> 3) in case of a conflict between the the genmake2 arguments and
>  the content of genmake_local, the resulting Makefile will
>  be different, since the conflicting arguments will be overwritten
>  by genmake_local (whereas in the previous version, the conflicting
>  parts of genmake_local were ignored).
> However, it should be easy to adapt the content of genmake_local
> to reproduce the old behavior (can post on this list if you need help).
> For instance, in verification/adjustment.128x64x1/build/genmake_local
> the previous instruction
>  MAKEDEPEND=cyrus_makedepend
> has been changed to:
>  if test "x$MAKEDEPEND" = x ; then MAKEDEPEND=cyrus-makedepend ; fi
> so that the resulting Makefile will remains identical to the one
> produced by the previous genmake2, even if the genmake2 "-makedepend"
> option is used.
> 
> Cheers,
> Jean-Michel
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Mon, 27 Aug 2012 10:19:55 -0400
> From: Jean-Michel Campin <jmc at ocean.mit.edu>
> To: mitgcm-support at mitgcm.org
> Subject: Re: [MITgcm-support] using gather/scatter to work with global
>        fields
> Message-ID: <20120827141955.GB4163 at ocean.mit.edu>
> Content-Type: text/plain; charset=us-ascii
> 
> Hi Katy,
> 
> few comments:
> 1) the BARRIER calls (either coded with the macro "_BARRIER" or
>  explicit call to BAR2) are itended to syncronise threads.
>  Unless you you are running multi-threads (nTx > 1 or nTy > 1 in eedata),
>  these barrier calls will do nothing.
> 
> 2) S/R GATHER_2D_R4 is used to write output when the default readBinaryPrec
>  is used (i.e., =32) with single CPU IO (useSingleCpuIO=.TRUE.).
>  It has been used & tested by many people in many different set-up,
>  so a bug is not very likely; but anyway, it would be useful to check that,
>  in your set-up, using these 2 options (readBinaryPrec=32 and
>  useSingleCpuIO=.TRUE.) give you the right output files.
>  Assuming this test passes, it means we can focus on (3):
> 
> 3) How to (re-) use  S/R GATHER_2D_R4 in a customised piece of code
>  within MITgcm.
> I would suggest to pass by MIT one day, so that we can get a more precised
> idea of the purpose of this piece of code and how to make it to work.
> Since few persons from AER are coming regularly to MIT, I imagine it
> should be possible to make this visit.
> 
> Cheers,
> Jean-Michel
> 
> On Thu, Aug 23, 2012 at 01:40:55PM -0400, Katherine Quinn wrote:
>> Hi all,
>> Within the MITgcm code (not matlab) I need to gather tiled variables
>> into a global array, specifically I'm trying to gather XC and YC.
>> I'm using the subroutine gather_2d_r4, which suggests "barrier
>> calls" before and after but it seems no matter what various barrier
>> calls I use, when I look at the global array there's chunks of tiles
>> missing.  Other relevant info - the MITgcm setup is for ecco version
>> 4 runs, with all_exch2 turned on.
>> Here's the relevant portions of my code, please suggest what I'm
>> doing wrong:
>> 
>> C     == Global variables ===
>> #include "SIZE.h"
>> #include "EEPARAMS.h"
>> #include "EESUPPORT.h"
>> #include "PARAMS.h"
>> #ifdef ALLOW_EXCH2
>> # include "W2_EXCH2_SIZE.h"
>> # include "W2_EXCH2_TOPOLOGY.h"
>> # include "W2_EXCH2_PARAMS.h"
>> #endif /* ALLOW_EXCH2 */
>> #include "EEBUFF_SCPU.h"
>> #include "GRID.h"
>> 
>> C     INPUT/OUTPUT PARAMETERS:
>> C     == Routine arguments ==
>> C     myThid - Thread number for this instance of the routine.
>>      INTEGER  myThid
>> 
>> C     LOCAL VARIABLES:
>>      LOGICAL zeroBuff, useExch2ioLayOut
>>      INTEGER xSize, ySize
>> #ifdef ALLOW_EXCH2
>>      _RL  XC_global(exch2_global_Nx,exch2_global_Ny)
>>      _RL  YC_global(exch2_global_Nx,exch2_global_Ny)
>> #else  /* ALLOW_EXCH2 */
>>      _RS  XC_global(Nx,Ny)
>>      _RS  YC_global(Nx,Ny)
>> #endif /* ALLOW_EXCH2 */
>> 
>> C Set dimensions and flags (e.g. mdsio_write_field.F)
>>      xSize = Nx
>>      ySize = Ny
>>      useExch2ioLayOut = .FALSE.
>>      zeroBuff = .TRUE.
>> #ifdef ALLOW_EXCH2
>>      IF ( W2_useE2ioLayOut ) THEN
>>         xSize = exch2_global_Nx
>>         ySize = exch2_global_Ny
>>         useExch2ioLayOut = .TRUE.
>>      ENDIF
>> #endif /* ALLOW_EXCH2 */
>> 
>> C gather XC and YC into global model grid
>> 
>>      CALL BAR2( myThid )
>>      _BEGIN_MASTER( myThid )
>>      CALL GATHER_2D_R4(
>>     O                  XC_global,
>>     I                  XC,
>>     I                  xSize, ySize,
>>     I                  useExch2ioLayOut,
>>     I                  zeroBuff,
>>     I                  myThid )
>>      _END_MASTER( myThid )
>>      CALL BAR2( myThid )
>> 
>>      _BEGIN_MASTER( myThid )
>>      CALL GATHER_2D_R4(
>>     O                  YC_global,
>>     I                  YC,
>>     I                  xSize, ySize,
>>     I                  useExch2ioLayOut,
>>     I                  zeroBuff,
>>     I                  myThid )
>>      _END_MASTER( myThid )
>>      CALL BAR2( myThid )
>> 
>> 
>> 
>> --
>> Katherine J. Quinn
>> Atmospheric and Environmental Research         voice: 781-761-2234
>> 131 Hartwell Avenue                              fax: 781-761-2299
>> Lexington, MA  02421-3126                     e-mail: kquinn at aer.com
>> 
>> _______________________________________________
>> 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 110, Issue 19
> ***********************************************
> 
> 
> 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