[MITgcm-devel] KPP and smoothing

[David Ferreira]

Dimitris Menemenlis wrote:

> Hi Natacha, the smoothing options for KPP are there to get rid of a 
> grid-scale computational mode.  Default smoothing options in 
> KPP_OPTIONS.h is what I recommend that you use.

Hi Dimitri,
do you mean by "default smoothing options" the ones which are activated
in pkg/kpp/KPP_OPTIONS.h ?  (That is KPP_SMOOTH_SHSQ
and KPP_SMOOTH_DBLOC)
On the cube, KPP_SMOOTH_SHSQ (smooth zonal shear meridionally)
doesn't mean much, no ?  It is better to use it along KPP_SMOOTH_DVSQ
(smooth meridional shear zonally) to be consistent or avoid using it ?
Thanks,
david


> KPP_REACTIVATE_OL4 appears to be an adjoint-related flag that Patrick 
> put in six years and two months ago.  It probably should not be 
> there.  I am not sure.
>
> There is a KPP_OPTIONS.h flag that allows you to get rid of the 
> requirement for increased overlap: #define FRUGAL_KPP
>
> C o When set, use exchange calls rather than recomputation
> C   to obtain KPP parameters in overlap region.  This option
> C   was added to reduce stack size requirements on the
> C   Origin 2000.  It decreases memory and computation
> C   requirements at the expense of increased communications.
> C   For a 64-processor 360x224x46 MPI configuration on the
> C   Exemplar or Origin 2000, wall clock time is about the
> C   same whether FRUGAL_KPP is turned on or off.
>
> You can experiment to see which is faster for your setup, i.e., 
> recomputation or increased overlap.
>
> Dimitris
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>


-- 

Ferreira David                           Tel : 617 253 7967
EAPS Room 54-1515,                       Fax : 617 253 4464
Massachusetts Institute of Technology,
77 Massachusetts Avenue
Cambridge, MA, 02139