Virtual salt flux sea surface boundary condition

[wilkin]

Those of you working with large discharge river point sources have probably experienced over/under-shooting of the salt concentration due to poor performance of the advection near to the point source when using 3rd-order upwind, Akima, or other schemes (not MPDATA). These extremes usually mix away quickly and I generally put this in the category of things not to worry about.

But I've recently noticed some added fluctuations in regions of negative salinity in the upper reaches of small tributaries that occur over the entire patch of negative salinity and I think it might be due to the virtual salt flux surface condition.

When using BULK_FLUXES and allowing for EMINUSP to change sea surface salinity (SSS), we parameterize the freshwater flux (fwf) as a Virtual Salt Flux (VSF) calculated as fwf times SSS. If advection has taken SSS into the range SSS < 0, then net precipitation over evaporation EMINUSP < 0 turns into a negative salt flux: heavy rain makes the ocean more salty and strong evaporation makes it more fresh.

Moreover, since in the upper reaches of small tributaries I might have 1 to 2 m of water, and 40 levels, the dz is only a few cm and the impact could be significant.

I can't immediately think of an easy fix to this. In reality we should have the EMINUSP freshwater flux add a finite volume of zero salinity water and dilute the mass of salt. This will mess with the continuity equation.

I may experiment with a simple minded governor on the flux when there are negative salinities (i.e. it's already totally freshwater so more rain won't change that) ...

In set_vbc.F it would be this:

stflx(i,j,isalt)=stflx(i,j,isalt)*MAX(0.0_r8,t(i,j,N(ng),nrhs,isalt))

Anyone have any thoughts on this issue?

[pmaccc]

John,

I like all the ideas you mention to solve this problem. I favor the more physical solution (add of subtract freshwater) but understand that this will need modifications to the volume conservation.

My reason for replying is more basic. I use bulk fluxes and provide a rain field in my forcing, but do not have EMINUSP turned on. The possibly relevant flags in my .h file (and some questions) are:
#define SOLAR_SOURCE (what does this do when I provide downward long and shortwave radiation?)
#define BULK_FLUXES
#define LONGWAVE_OUT (do I need this?)
#define ANA_SSFLUX (presumably it executes the default because I do nothing).

so does this mean I am not using my rain forcing?

Finally - if I use ATM_PRESS will it apply the "inverse barometer" to my zeta?

Thanks,

Parker

[wilkin]

Parker,

If using BULK_FLUXES without EMINUSP the rain data will not be used in the salt flux. You will see that stdout reports the rain data were read - which may mislead you into thinking that rain is used somehow in the salt flux condition. It is not. Bulk fluxes uses rain in the momentum flux - the lateral momentum of rain falling on the sea surface imparts that horizontal momentum to the ocean. See the line:

Code: Select all

!
!  Compute momentum flux (N/m2) due to rainfall (kg/m2/s).
!
          Taur=0.85_r8*rain(i,j)*Wmag(i) 

To have the freshwater flux from rain enter the ocean to dilute salinity, you have to #define EMINUSP. Evaporation is computed from latent heat loss, which bulk fluxes always calculates, so there's no reason not to use EMINUSP is you have rain data. If you have #define ANA_SSFLUX the default is zero salt flux. The default analytical rain is also zero.

#define SOLAR_SOURCE separates the net shortwave radiation from the net heat flux and penetrates this over e-folding scales set by the Jerlov water type WTYPE. The net heat flux is unchanged - it is just partially distributed into the water column rather than being entirely applied at the surface as the boundary condition to the vertical turbulent mixing of temperate.

#define LONGWAVE_OUT will compute the upwelling infrared radiation based on SST (proportional to sigma*SST^4) and subtract off the downwelling radation (lwrad_down in varinfo.dat) to get net longwave. If you don't define this the default is to assume net longwave is provided (lwrad in varinfo.dat). In this event, model SST has no impact on the longwave radiation.

The LONGWAVE_OUT option is more realistic and somewhat guards against runaway SST if SST becomes very inconsistent with imposed lwrad (SST to the 4th power is a strong governor).

#define ATM_PRESS imposes the inverted barometer effect because the ocean dynamically adjusts to the horizontal gradient of Pair at z = zeta.

[zwallace]

John,

I have a question about the LONGWAVE_OUT option. In the bulk_flux.F code, with the option activated, the net longwave radiation, LRad(i,j) is computed as:

Code: Select all

# elif defined LONGWAVE_OUT
!
!  Treat input longwave data as downwelling radiation only and add
!  outgoing IR from model sea surface temperature.
!
          LRad(i,j)=lrflx(i,j)*Hscale-                                  &
     &              emmiss*StefBo*TseaK(i)*TseaK(i)*TseaK(i)*TseaK(i)

However, according to Dickey et al. 1994 (see attached file), equations 14 and 15 indicate that the code should be

Code: Select all

# elif defined LONGWAVE_OUT
!
!  Treat input longwave data as downwelling radiation only and add
!  outgoing IR from model sea surface temperature.
!
          LRad(i,j)=emmiss*lrflx(i,j)*Hscale-                                  &
     &              emmiss*StefBo*TseaK(i)*TseaK(i)*TseaK(i)*TseaK(i)

where the emissivity factor is applied to the downwelling longwave radiation term as well.

This is also in agreement with equation 211 from Kate’s BOEM report (Technical Manual for a Coupled Sea-Ice/OceanCirculation Model version 5) for the net longwave radiation at the ice/snow surface. However, her code also does not reflect the emissivity factor on the downwelling longwave radiation (lrflx) term.

Could you please shed some light on this? Am I misinterpreting something here?

Thanks,

Zach

[wilkin]

By no means am I an expert in air-sea radiative transfer, so I can't give you an authoritative answer.

I don't understand the Dickey et al. (1994) eqn. (15) at all.

Why should there be a contribution to upwelling longwave radiation that scales with downwelling longwave according to emmisivity? It's as through there a longwave reflectivity - not emmisivity. I hope you can explain eqn. (15).

But I am an engineer, and Dickey et al. suggest an epsilon_ss value for Atlantic and Pacific seawater of 0.985. So the factor (1-epsilon_ss) that determines the fraction of downwelling longwave "reflected" is 1.5%. That's not much.

My philosophy is not to change things in ROMS until someone proves there is a problem. Right or wrong, I doubt 1.5% of downward IR could be a substantial error, but if you can explain the basis of Dickey et al.'s (1994) equation I would be happy to advocate for a code change.

Please work this through, do some controlled runs to explore the magnitude of the effect, and report back to myroms.