[MITgcm-support] how to compute MON ke_vol?
Chun-Yan Zhou
c.zhou at dundee.ac.uk
Sat Sep 1 11:10:56 EDT 2012
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
More information about the MITgcm-support
mailing list