[MITgcm-devel] problem in seaice_lsr with cubed sphere

[Jean-Michel Campin]

Hi Martin,

Sorry, I forgot to mention 1 thing:
proably better to change the call to:
> call fill_cs_corner_uv_rs(.true.,uice(1-OLx,1-OLy,bi,bj),vice(1-OLx,1-OLy,bi,bj),bi,bj,myThid)

Cheers,
Jean-Michel

On Wed, Dec 03, 2014 at 05:59:56PM +0100, Martin Losch wrote:
> OK, so I’ll make an exact rl-copy of fill_cs_corner_rs, just with _RS replaced by _RL in the declarations of uFld/vFld and I’ll call it like this in seaice_lsr:
> 
> Do bj=…
> Do bi=…
> call fill_cs_corner_uv_rs(.true.,uice(:,:,bi,bj),vice(:,:,bi,bj),bi,bj,myThid)
> ENDDO
> ENDDO
> 
> Martin
> 
> 
> On Dec 3, 2014, at 5:53 PM, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:
> 
> > Hi Martin,
> > 
> > Should be OK to keep a local (no bi,bj) argument within S/R 
> > fill_cs_corner_uv_rl since it only involves local copy from the
> > same tile.
> > And this way, it could also be re-used to fill the cormner of some
> > local (no bi,bj) array.
> > 
> > Cheers,
> > Jean-Michel
> > 
> > On Wed, Dec 03, 2014 at 05:29:41PM +0100, Martin Losch wrote:
> >> Hi Jean-Michel,
> >> 
> >> thanks for this trick: I inserted this routine after the exch_uv_xy_rl at the end of the linear iteration and this fixes the problem.
> >> 
> >> Now, do we need to make a _RL version that can also handle 4D arrays (with bi,bj indices) or can we just call it like this:
> >> 
> >> call fill_cs_corner_uv_rs(.true.,uice(:,:,bi,bj),vice(:,:,bi,bj),bi,bj,myThid)
> >> 
> >> I have the feeling that this only works for me because nSy = 1, so I would actually make a routine that takes 4D arrays (but that wouldn’t be consistent with the _RS version, what’s best in your opinion?
> >> 
> >> Martin
> >> 
> >> On Dec 3, 2014, at 2:26 PM, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:
> >> 
> >>> Hi Martin,
> >>> 
> >>> Did you try something like one or more calls to S/R FILL_CS_CORNER_UV
> >>> (we currently only have the _RS version but would not be difficult
> >>> to make an _RL ; and as long as _RS = real*8, you can certainly give 
> >>> it a try just calling the _RS version).
> >>> 
> >>> Cheers,
> >>> Jean-Michel
> >>> 
> >>> On Wed, Dec 03, 2014 at 01:47:33PM +0100, Martin Losch wrote:
> >>>> Hi again,
> >>>> 
> >>>> after playing a little, it seems there are more problems than just the zero recip_raw/ras, so it may be easier to just include a resetting of zero BU/BV at the end of the routine (although this may cover up unrecognized problems).
> >>>> 
> >>>> Since this all of this is sufficiently fragile, I’d like to add the new capabilitiies: RAS and strong implicit coupling in one of the test experiments. How about global_ocean.cs32x15/input.seaice ?
> >>>> 
> >>>> Martin
> >>>> 
> >>>> On Dec 2, 2014, at 11:55 AM, Martin Losch <Martin.Losch at awi.de> wrote:
> >>>> 
> >>>>> Hi Jean-Michel,
> >>>>> 
> >>>>> yesterday I implemented the option to compute the LSR solution on overlapping tiles, i.e. a restricted additive schwarz (RAS) method. imin/imax can be 1-SEAICE_OLx/sNx+SEAICE_OLx etc. This works fine for SEAICE_OLx <= OLx-2 on simple domains, but for cubed sphere experiments, I need to set SEAICE_OLx=OLx-3 for this to work. SEAICE_OLx = OLx-2 (=2) I get NaN in global_ocean.cs32x15.seaice (and others that use LSR), in the second linear iteration of the solver. 
> >>>>> The reason seems to be BU=0 in some of the corner halos (34,18,2,1), and this is because recip_raw(34,18,2,1) seems to be zero.
> >>>>> 
> >>>>> Can you reproduce this problem (set SEAICE_OLx=2, and SEAICE_OLy = 2 in global_ocean.cs32x15/input.seaice/data.seaice and run ./testreport -t global_ocean.cs32x15)?
> >>>>> Can we find a decent way to fix that? Initialise recip_raw=1 always? or do I have to check my BU/BV and reset them if they are zero?
> >>>>> 
> >>>>> Martin
> >>>>> 
> >>>>> 
> >>>>> _______________________________________________
> >>>>> MITgcm-devel mailing list
> >>>>> MITgcm-devel at mitgcm.org
> >>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >>>> 
> >>>> 
> >>>> _______________________________________________
> >>>> MITgcm-devel mailing list
> >>>> MITgcm-devel at mitgcm.org
> >>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >>> 
> >>> _______________________________________________
> >>> MITgcm-devel mailing list
> >>> MITgcm-devel at mitgcm.org
> >>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >> 
> >> 
> >> _______________________________________________
> >> MITgcm-devel mailing list
> >> MITgcm-devel at mitgcm.org
> >> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> > 
> > _______________________________________________
> > MITgcm-devel mailing list
> > MITgcm-devel at mitgcm.org
> > http://mitgcm.org/mailman/listinfo/mitgcm-devel
> 
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel