[MITgcm-devel] real-fresh-water-flux with pkg/shelfice

[Martin Losch]

Hi Jean-Michel,

I think we talked about this about a year ago, but I never completed my action item to actually implement this. 

From what I found in my multiple personal MITgcm copies, I think we agreed on option 2(b) and your suggestions in 3), because I had partly implemented that already. The extra code in shelfice_forcing_surf.F looks like this:

#ifdef EXACT_CONSERV
C NB: synchronous time step: PmEpR lags 1 time step behind EmPmR
C     to stay consitent with volume change (=d/dt etaH).
CML# ifdef ALLOW_AUTODIFF_TAMC
CMLCADJ STORE PmEpR = comlev1, key = ikey_dynamics,  kind = isbyte
CMLCADJ STORE EmPmR = comlev1, key = ikey_dynamics,  kind = isbyte
CML# endif
CML        IF ( staggerTimeStep ) THEN
        DO j=1-OLy,sNy+OLy
         DO i=1-OLx,sNx+OLx
          PmEpR(i,j,bi,bj) = PmEpR(i,j,bi,bj) 
     &         - SHELFICEfreshWaterFlux(i,j,bi,bj) 
         ENDDO
        ENDDO
CML        ENDIF
#endif /* EXACT_CONSERV */
        DO j=1-OLy,sNy+OLy
         DO i=1-OLx,sNx+OLx
          EmPmR(i,j,bi,bj) = EmPmR(i,j,bi,bj) 
     &         + SHELFICEfreshWaterFlux(i,j,bi,bj) 
         ENDDO
        ENDDO


cFac=1 adds temperature and salinity tendency due to the advection by meltwater. This is very tricky, because the underlying assumption is, that there is a thin boundary (not resolved) at T=tfreeze and S=sFreeze. This boundary layer will not vanish if freshwater is really added to the ocean, so I think that the cFac = 1 is still OK, but I can be convinced otherwise.

rFac is used on one place: computation of shelficeHeatFlux, which is “just” a diagnostic (and used in esoteric cost functions …), so I don’t see this as a crucial thing to understand (again). Currently, I don’t understand why it is used in the way it is.

Martin

On Jan 9, 2015, at 2:11 AM, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:

> Hi Martin and others,
> 
> Looking at how to make shelfice to work with useRealFreshWaterFlux=T :
> 
> 1) I think there will be few things to change in solve_for_pressure.F
>  (+ integr_continuity.F, integrate_for_w.F, cg3d.F & pre_/post_cg3d.F)
>  for z* and/or for Non-Hydrostatic,
>  but if we leave these 2 options on the side for now, should work
>  as long as EmPmR has been updated to include ice-shelf melting.
> 
> 2) Regarding where/when to modify EmPmR (to add melting):
> a) one option would be fill-up EmPmR (and may be also Qnet)
>  in shelfice_thermodynamics.F and rely on usual way surface forcing
>  is apply to T,S time-stepping.
>  The problem here is that external_forcing_surf.F is not ready yet 
>  to deal with ks > 1.
> b) a simpler alternative (involving less changes) would be to continue
>  to rely on shelfice_forcing_surf.F (called from external_forcing_surf.F)
>  to copy shelficeForcingT/S into surfaceForcingT,S
>  and to add a piece of code there to update/modify EmPmR.
>  This would make a difference if using balanceEmPmR (that would
>  balance EmPmR over ocean surface - excluding shelfice melting -
>  but this might even be better.
> 
> 3) The other things involve changes in shelfice_thermodynamics.F:
>  I would propose that:
>  a) we keep unchanged the "SHELFICEBoundaryLayer" part together with
>  the 2 S/R within shelfice_forcing.F but
>  b) for the case SHELFICEBoundaryLayer=F, we could just compute the melting
>  rate (shelfIceFreshWaterFlux ?) in shelfice_thermodynamics.F
>  and push shelficeForcingT/S calculation to shelfice_forcing_surf.F
>  I am not sure about the current setting of cFac/rFac according to
>  SHELFICEconserve/useRealFreshWaterFlux, and there might be some simpler
>  (and more consistent with main model options such as useRealFreshWaterFlux
>  & nonlinFreeSurf with temp,salt_EvPrRn settings) ways to change this.
> 
> I might have missed something there (did not check too carefully);
> and any comment is appreciated.
> 
> Cheers,
> Jean-Michel
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel