[MITgcm-devel] negative H in calc_r_star.F

[Jean-Michel Campin]

Hi Dimitris and Martin,

I agree with Martin, we have 2 options:
1) keep hFacW = min(hFacC_i-1,i) but then it would make sense to
 recompute, rLowW or rSurfW (probably better to pick rSurfW)
 to avoid the stop when using rStar.
2) reduce hFacW to just the common wet fraction of the 2 columns (i-1,i).
 This is implemented in calc_surf_dr.F ; can lead to some "thin-wall"; 
 but we also have to do something when hFacW < max(hFacMin,hFacMinDr/drF)
 since we don't want to let hFacW becoming too small (stability of momentum
 equation).

with solution (1), would need to change calc_surf_dr.F, but it's easy.

Seems to me that (1) is easier. What do you think ?

Cheers,
Jean-Michel

On Thu, May 31, 2012 at 07:08:42AM -0700, Dimitris Menemenlis wrote:
> Martin and Jean-Michel, sorry I have not done all my homework
> properly yet.  What I suspect is happening is what I have drawn on
> attached jpg.  In which case Martin is right, there should be a
> connection between the adjacent cells.  It's just that the
> particular model configuration (~20-km horizontal grid spacing and
> ~10-m vertical grid spacing) is unable to represent such a steep
> slope properly.
> 
> Let me confirm that this is indeed what is happening and then we can
> discuss what is best way to fix this.
> 
> Thanks for taking a look.
> 
> Dimitris Menemenlis
> 
> 
> On 05/31/2012 12:45 AM, Martin Losch wrote:
> >Hi there,
> >
> >I am not sure I understand the full problem. Is it htis: With the current combination of ini_masks_etc and shelfice_update_masks you can end up with hFacC's and consequently model geometry that potentially includes adjacent wet fractional cells that have no direct connection, as sketched in Dimitris's white board sketch. Then the code only knows about fractions, but does not care which fractions of the cell are dry (can be two parts). instead it implicitly assumes that all of the dry fraction is at the bottom (which it is for the usual open ocean applications). This can cause hFacW or hFacS between such cells to be nonzero, allowing flux between them: the model code "moves" the ice-shelf topography frac from the top of the cell (layer) to the bottom, thereby opening the connection between the cells. Is this the situation?
> >
> >If that's the case here's my opinion:
> > From a transport point of view, this shouldn't be a terrible issue, we approximate the topgography anyway, so I don't see a problem in allowing flux, where it isn't formally allowed. If the topographies of the bedrock and the ice shelves have been carelessly prepared to allow for such holes prior to computing hFac's (an modifying the topography to be representable in the model grid), then I'd say it's the users' own fault.
> >
> >I guess a different route would be to allow thin walls.,AFAIK, thin walls can be handled by the model.
> >You'd have to implement that in ini_masks_etc.F after Ro_surf/R_low and hFacW/S are already known, but before hFacW/S are exchanged in line 287, i.e. if Ro_surf(i,:)<=R_low(i-1,:) =>  hFacW(i:,:)=0. It's worth a try, isn't it?
> >It should lead to kSurfW/S=Nr+1 and then the corresponding rStarFacW/S=0 and there is no issue, right?
> >
> >Martin


> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel