[MITgcm-devel] changes in pkg/layers/layers_fluxcalc.F

[Ryan Abernathey]

Jean Michel,

I have some tests running now. I should be able to finish checking things tomorrow morning. Is it ok if the code stays as is over night?

Regarding the second point, I think I see what you mean: since u and v are both zero at that interface, it doesn't matter that the binning is wrong. Is that the correct interpretation?

I sincerely appreciate your help with checking this code. I have been working alone for a while, and obviously it is good to have another pair of eyes on it. I apologize for creating extra work for you.

-Ryan



Sent from my iPhone

> On Jun 4, 2015, at 6:34 PM, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:
> 
> Hi Ryan,
> 
> When I changed the minus sign to a plus, I recover the previous 
> pkg/layers output where hFac is identically =1 over the column.
> 
> And regarding the 2nd point (hFacC weighted average), I was not
> too much concerned (in the previous implementation) if one (i-1 or i / j-1 or j) 
> of the hFacC is zero since, in this case, the flow (uVel/vVel)
> and hFacW/hFacS are zero.
> 
> Cheers,
> Jean-Michel
> 
> On Thu, Jun 04, 2015 at 12:11:14PM -0400, Ryan Abernathey wrote:
>>> 
>>> I run a simple 2-D (y-z) test with the updated pkg/layers and the layers
>>> output (VH & Hs) are different, even where the bottom is flat and all
>>> hFac = 1 through the full column.
>>> I look into your changes in layers_fluxcalc.F and the code line 303-304
>>> seems wrong to me: When hFacS=1, I expect to find the same weighting as
>>> before
>>> (MapFact, 1-MapFact) but instead I am getting (2-MapFact, MapFact-1).
>>> Can you confirm this (I might have missed something) ?
>> 
>> What you say appears to be true. Currently I have
>> mfac = 1.0 - hFacS(i,j,k+1,bi,bj)*(MapFact(kk) - 1.0)
>> but it seems like instead it should be
>> mfac = 1.0 + hFacS(i,j,k+1,bi,bj)*(MapFact(kk) - 1.0)
>> i.e. a simple sign error.
>> This seems like such a big mistake that there is no way the code should
>> have worked at all. But I have been using it successfully for months. I
>> will have a closer look this afternoon and try to sort out what is going on.
>> 
>> 
>>> The second thing is that I am not sure that we want to consider an hFacC
>>> weighted averaged when computing the temperature/salt/rho at the
>>> velocity location. In the case where the model uses the default
>>> 2nd order centered  advection scheme, the previous layers averaging (no
>>> hFacC
>>> weight) was close to the model advection ; but with the new layers
>>> averaging
>>> (with hFacC weight) this is no longer the case.
>>> In other words, I am not convinced that this hFacC weighted averaged is
>>> more accurate for pkg/layers diagnostics.
>>> I am curious to know why your made this choice (hFacC weight).
>> 
>> I see your point here too. My thinking was, when there is topography in the
>> bordering cell, the previous averaging would simply interpolate using the
>> zero in that cell, producing a highly spurious value at the velocity point.
>> So there is no doubt that the previous averaging was wrong in this case.
>> The hFacC weighting was a way of dealing with this by de-weighting the
>> neighbor cell, eventually to zero for full topography. But I think you are
>> saying it would be better to just use the masks here.
>> 
>> 
>>> 
>>> Cheers,
>>> Jean-Michel
>>> 
>>> _______________________________________________
>>> 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