[MITgcm-support] THSIce noisy/unphysical output

Patrick Watts Watts at atm.ox.ac.uk
Mon Nov 17 23:22:49 EST 2014 

Thanks! I've made the changes you've suggested; I'll let you know how it turns out once it's run (not sure when).
Thanks again, Patrick
________________________________________
From: Jean-Michel Campin [jmc at ocean.mit.edu]
Sent: 16 November 2014 15:00
To: mitgcm-support at mitgcm.org
Subject: Re: [MITgcm-support] THSIce noisy/unphysical output

Hi Patrick,

The defaults in pkg/cheapaml fit a basin-scale / global-scale domain
using Lat-Lon grid.

I would recommand to try to specify  all the cheapaml input files
(so that you don't rely on any default)
like in this examples:
 MITgcm_contrib/verification_other/offline_cheapaml/input/data.cheapaml
Note that you probably want to set (like in the example above):
 useDLongWave=.TRUE.,
otherwise the long-wave is not right for a cartesian grid.
And I am not sure if, for seaice forcing, you can run without:
 useFreshWaterFlux=.TRUE.,

There is also a setup using seaice dynamics:
 MITgcm_contrib/verification_other/offline_cheapaml/input.dyn/

Cheers,
Jean-Michel

On Sat, Nov 15, 2014 at 07:11:34PM +0000, Patrick Watts wrote:
> Hi, sorry for being slow replying!
>
> I've attached the relevant files; these are for a typical test. The scale is in metres, so the difference in ice thickness's is as you say it is, Jean-Michel.
>
> One of the strange things about the pattern is it appears even when there's greater variation on top of it. For example, I ran a test with the temperature of the atmosphere varying in large blocks (larger than the tiles). This caused the variation you'd expect with the pattern over it (see attached figure), so it's not all the tiles acting exactly the same, or if it is it's acting the same on one level and differently on another.
>
> Thanks!
> Patrick
> ________________________________
> From: Chris Horvat [horvat at fas.harvard.edu]
> Sent: 14 November 2014 15:40
> To: MITgcm Support
> Subject: Re: [MITgcm-support] THSIce noisy/unphysical output
>
> Just to keep this going, this is similar to a problem I had earlier this year. All of the tiles in the simulation were the same even without any packages turned on.
>
> That link can be found here: http://dev.mitgcm.org/pipermail/mitgcm-support/2014-March/009002.html which suggests some help.
>
> I was able to solve the problem by changing FFOPTIM in build-options to O0 from O4 or some such thing, which slows down the gcm execution time significantly, but not terribly. After speaking with Patrick I was unable to replicate the error... which is fortunate and unfortunate in different ways. Perhaps just re-making the GCM may help.
>
> Since I had this problem, too, I figured we could look try to resolve what the underlying issue is!
>
> Chris
>
>
>
>
> On Wed, Nov 12, 2014 at 5:57 PM, Jean-Michel Campin <jmc at ocean.mit.edu<mailto:jmc at ocean.mit.edu>> wrote:
> Hi Patrick,
>
> Could you send (in attachement) the full set of parameter files
> (main parameter file "data" and all the other data.* files)
> as well as SIZE.h (since you try several tile domain decomposition)
> that correspond to the figure you sent ?
> Right now, it's difficult to guess where the noise comes from.
>
> Also, on the figure you sent, can you confirm that the amplitude of
> the noise in ice thickness is about 0.0172 - 0.0156 = 0.0016 m ?
>
> Cheers,
> Jean-Michel
>
> On Fri, Nov 07, 2014 at 05:05:21PM +0000, Patrick Watts wrote:
> > Hi MITgcmers,
> >
> > I have been running the model in a coupled setup, with ocean, a CheapAML atmosphere, and using the THSIce model. The resolution is very high (20m in all directions) and the setup is idealised, essentially a doubly periodic box.
> >
> > The output of the ice model is extremely noisy, with a pattern repeating for each tile (see attached for an example). I have tried changing the time step, minimum ice thickness, and mask of the ice model, as well as the fortran optimisation, number of tiles, and the number of grid points overlapping between tiles - the pattern has changed and there can be larger variations in ice thickness overlying it, but nothing so far has actually got rid of it.
> >
> > Absolutely any suggestions of what the root cause could be or how I can try to get rid of it are appreciated.
> > Thanks,
> > Patrick
>
>
> > _______________________________________________
> > MITgcm-support mailing list
> > MITgcm-support at mitgcm.org<mailto:MITgcm-support at mitgcm.org>
> > http://mitgcm.org/mailman/listinfo/mitgcm-support
>
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org<mailto:MITgcm-support at mitgcm.org>
> http://mitgcm.org/mailman/listinfo/mitgcm-support
>







> C $Header: /u/gcmpack/MITgcm/verification/tutorial_deep_convection/code/SIZE.h,v 1.2 2008/04/23 23:24:22 jmc Exp $
> C $Name:  $
> C
> C     /==========================================================\
> C     | SIZE.h Declare size of underlying computational grid.    |
> C     |==========================================================|
> C     | The design here support a three-dimensional model grid   |
> C     | with indices I,J and K. The three-dimensional domain     |
> C     | is comprised of nPx*nSx blocks of size sNx along one axis|
> C     | nPy*nSy blocks of size sNy along another axis and one    |
> C     | block of size Nz along the final axis.                   |
> C     | Blocks have overlap regions of size OLx and OLy along the|
> C     | dimensions that are subdivided.                          |
> C     \==========================================================/
> C     Voodoo numbers controlling data layout.
> C     sNx - No. X points in sub-grid.
> C     sNy - No. Y points in sub-grid.
> C     OLx - Overlap extent in X.
> C     OLy - Overlat extent in Y.
> C     nSx - No. sub-grids in X.
> C     nSy - No. sub-grids in Y.
> C     nPx - No. of processes to use in X.
> C     nPy - No. of processes to use in Y.
> C     Nx  - No. points in X for the total domain.
> C     Ny  - No. points in Y for the total domain.
> C     Nr  - No. points in Z for full process domain.
>       INTEGER sNx
>       INTEGER sNy
>       INTEGER OLx
>       INTEGER OLy
>       INTEGER nSx
>       INTEGER nSy
>       INTEGER nPx
>       INTEGER nPy
>       INTEGER Nx
>       INTEGER Ny
>       INTEGER Nr
>       PARAMETER (
>      &           sNx =  10,
>      &           sNy =  10,
>      &           OLx =   2,
>      &           OLy =   2,
>      &           nSx =   1,
>      &           nSy =   1,
>      &           nPx =  12,
>      &           nPy =  12,
>      &           Nx  = sNx*nSx*nPx,
>      &           Ny  = sNy*nSy*nPy,
>      &           Nr  =  50)
>
> C     MAX_OLX  - Set to the maximum overlap region size of any array
> C     MAX_OLY    that will be exchanged. Controls the sizing of exch
> C                routine buufers.
>       INTEGER MAX_OLX
>       INTEGER MAX_OLY
>       PARAMETER ( MAX_OLX = OLx,
>      &            MAX_OLY = OLy )
>


> _______________________________________________
> 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

More information about the MITgcm-support mailing list