[MITgcm-devel] exf wind-stress masking

Jean-Michel Campin jmc at ocean.mit.edu
Mon Jan 30 09:17:36 EST 2012 

Hi Martin,

I will try something, on taux/tauy and you will be able to correct me
if I did it wrong.

I will also change exf_init_fixed.F (always mask atemp, aqh & lwflux)
since I am tired of seeing exf monitor changing in seaice experiments
with no impact on any results.

Cheers,
Jean-Michel

On Mon, Jan 30, 2012 at 09:56:49AM +0100, Martin Losch wrote:
> Jean-Michel,
> 
> I think that masking taux/tauy does make sense, so let's do it. Will you?
> 
> Martin
> 
> On Jan 27, 2012, at 9:24 PM, Jean-Michel Campin wrote:
> 
> > Hi Martin and others,
> > 
> > I think the masking is not "strictly necessary" so that
> > not masking fields in exf when using seaice is OK.
> > Was conscerned about wind-stress computation (which depends
> > on air temp & SST in exf), but it is masked in exf_mapfields.F
> > when put on C-grid. And in pkg/seaice wind-stress does not depend on 
> > air temperature.
> > 
> > However, I think it would be better to always masks the air-temp
> > (and may be also the air humidity & lwflux) to avoid computing
> > fluxes (sensible, latent, net-LW) using SST from a land point.
> > 
> > And regarding seaice_ocean_stress (in relation with useHB87stressCoupling),
> > might be cleaner to make the changes you propose to remove the exf-masking
> > dependency; or could leave it as it is (little odd, but more accurate ?).
> > 
> > Cheers,
> > Jean-Michel
> > 
> > On Tue, Jan 10, 2012 at 02:14:23PM -0500, Jean-Michel Campin wrote:
> >> Hi Martin,
> >> 
> >> I would like to do more tests, since I realized there are some 
> >> combinations that are not tested (but not so exotic that
> >> they can be used), such as exf-interp + seaice.
> >> 
> >> I think we agree that we don't want ocean surface temperature on land
> >> to have an effect on the solution. And this is what I would like to 
> >> check first.
> >> 
> >> Cheers,
> >> Jean-Michel
> >> 
> >> On Tue, Jan 10, 2012 at 10:56:01AM +0100, Martin Losch wrote:
> >>> Hi Jean-Michel,
> >>> 
> >>> the reason appears to be the unmasked taux/tauy.
> >>> 
> >>> The are added to FORCEX/Y0 which in turn is added to FORCEX/Y, and these are then added to the rhs, but with masking (seaiceMaskU/V). In seaice_ocean_stress taux/tauy are used, but without masking (and as far as I can see that's also the case in seaice_freedrift).
> >>> 
> >>> I can fix that by masking taux/y with maskW/S or seaiceMaskU/V if you like and then the dependence on the exf-masking goes away.
> >>> 
> >>> Martin
> >>> 
> >>> 
> >>> 
> >>> On Jan 9, 2012, at 9:20 PM, Jean-Michel Campin wrote:
> >>> 
> >>>> Hi Martin,
> >>>> 
> >>>> I did some quick tests, comparing with/without masking of exf variables
> >>>> (In the 1rst case, I've just commented out the block:      
> >>>>     IF ( useSEAICE ) THEN
> >>>> C     Do not filter with pkg/seaice because of B/C-grid interpolation
> >>>>      ....
> >>>> in pkg/exf/exf_init_fixed.F)
> >>>> 
> >>>> And I only get different results in 2 exp.:
> >>>> a) lab_sea/input.fd   (SEAICEuseFREEDRIFT=.true.)
> >>>> b) lab_sea/input.hb87 (EVP & useHB87stressCoupling)
> >>>>  (but diff goes away with useHB87stressCoupling=F)
> >>>> 
> >>>> Regarding SEAICEuseFREEDRIFT, the differences comes from 
> >>>> seaice_freedrift.F (I don't get any difference with my free-drift         
> >>>> computation within seaice_lsr.F).
> >>>> 
> >>>> To conclude:
> >>>> 1) it's worth to know that these 2 options (SEAICEuseFREEDRIFT
> >>>>  and useHB87stressCoupling) are sensitive to masking within EXF.
> >>>> 2) I think it might be better to always (whether we use SEAICE or
> >>>> not) mask heat-flux & fresh water flux related fields, 
> >>>> and to leave only wind & windstress not masked when using SEAICE.
> >>>> 
> >>>> Cheers,
> >>>> Jean-Michel
> >>>> 
> >>>> On Wed, Jan 04, 2012 at 09:32:35AM +0100, Martin Losch wrote:
> >>>>> Hi Jean-Michel,
> >>>>> 
> >>>>> I am not sure, but I think that for B-grid seaice, the wind (stress) needs to be available a Z-points and this interpolation is done in pkg/seaice/dynsolver.F, so that when masking in exf removes wind values over land, you underestimate the wind over boundary values of seaice.
> >>>>> Having said that, the boundary points of B-grid seaice have (uice,vice)=0 as a boundary conditions, so that this masking does not make any difference, so on second thought you are probably right, and this differentiation can be removed safely.
> >>>>> 
> >>>>> M.
> >>>>> 
> >>>>> On Jan 3, 2012, at 5:49 PM, Jean-Michel Campin wrote:
> >>>>> 
> >>>>>> Hi, 
> >>>>>> 
> >>>>>> I am going to check-in some unfinished changes in exf:
> >>>>>> I realized that the masking of the wind-stress is wrong (when not on 
> >>>>>> C-grid, which happen when interpolated or read from A-grid file).
> >>>>>> I fixed this problem and will check-in this (involves also EXF_PARAMS.h
> >>>>>> & exf_init_fixed.F) and update output of global_with_exf exp.
> >>>>>> 
> >>>>>> I also started to add some params in EXF_PARAMS.h + exf_init_fixed.F
> >>>>>> for 2-components vector interpolation (I did this before the stress
> >>>>>> mask fix), will be part of the changes but they are not yet used.
> >>>>>> 
> >>>>>> Regarding masking, I don't see a clear reason why it's only
> >>>>>> applied when not using SEAICE. If exf works fine without
> >>>>>> masking (when using SEAICE), then why do we care about applying
> >>>>>> masks ?
> >>>>>> 
> >>>>>> Also, noticed that exf_init_fixed.F does not compile with default 
> >>>>>> pkg/icefront settings (might have been better to put all this
> >>>>>> icefront - exf code in pkg/icefront and still call some utility 
> >>>>>> exf & cal S/R).
> >>>>>> 
> >>>>>> 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
> >>> 
> >>> 
> >>> _______________________________________________
> >>> 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
> 
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel

More information about the MITgcm-devel mailing list