[MITgcm-devel] changes in pkg/layers/layers_fluxcalc.F
Jean-Michel Campin
jmc at ocean.mit.edu
Thu Jun 4 18:34:41 EDT 2015
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
More information about the MITgcm-devel
mailing list