[MITgcm-devel] negative H in calc_r_star.F

[Dimitris Menemenlis]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: photo.JPG
Type: image/jpeg
Size: 146779 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20120531/73c3bbfd/attachment-0001.jpeg>