[MITgcm-devel] negative H in calc_r_star.F

[Dimitris Menemenlis]

Sorry, it took me some time to get back to this.
My little schematic diagram from this morning (although plausible)
is not what was causing the majority of the negative depths.

Instead the negative depths occur everywhere where there is steep
bathymetry accompanied by steep SHELFICEtopo.  For example, see:
http://ecco2.jpl.nasa.gov/data1/cube/cube94/DUMP3/NegativeDepth.ps 
<http://ecco2.jpl.nasa.gov/data1/cube/cube94/DUMP3/NegativeDepth.jpg>

So the problem is much less subtle and much more widespread than I thought.
For example, you can see it happen all the way around Antarctica in 
Hong's plot.
But this also means that the simpler-to-implement solution (1) below 
should be
more than adequate for addressing this problem.

Cheers

Dimitris Menemenlis


On 05/31/2012 02:06 PM, Jean-Michel Campin wrote:
> Hi,
>
> I will make the little changes for method (1) (will be needed anyway for method (2))
> in calc_surf_dr.F and within IF (useShelfIce) THEN / ENDIF in ini_masks_etc.F
> so that results will not change (machine trucation) if not using shelfice.
> Will see later how method (2) can be implemented.
>
> There was also the idea of allowing hFac>  1 near the bottom instead
> of rounding off the depth if hFac below is too small.
> Might do both at the same time.
>
> Cheers,
> Jean-Michel
>
> On Thu, May 31, 2012 at 05:43:02PM +0200, Martin Losch wrote:
>> Difficult to decide:
>>
>> (1) looks good to me, because we will always have resolution issues and allowing some more "virtual" flow in unresolved topography does not appear to be a problem to me.
>>
>> (2) seems cleaner to me, reduces to modifications in the initialisation phase. hFacW can be subject to the same criteria as hFacC, cant it?
>>
>> If you say (1) is simple, then that's probably what we should do ..., but I am also happy with (2).
>>
>> Martin
>>
>> On May 31, 2012, at 5:21 PM, Jean-Michel Campin wrote:
>>
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20120601/f82826dd/attachment.htm>