Ocean Modeling Discussion

ROMS/TOMS

Search for:
It is currently Fri Mar 22, 2019 2:33 pm




Post new topic Reply to topic  [ 5 posts ] 

All times are UTC

Author Message
PostPosted: Wed Aug 09, 2017 7:47 pm 
Offline
User avatar

Joined: Mon Apr 28, 2003 5:44 pm
Posts: 478
Location: Rutgers University
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?

_________________
John Wilkin: IMCS Rutgers University
71 Dudley Rd, New Brunswick, NJ 08901-8521, USA. ph: 609-630-0559 jwilkin@rutgers.edu


Top
 Profile  
Reply with quote  
PostPosted: Fri Dec 07, 2018 5:10 pm 
Offline

Joined: Wed Oct 22, 2003 6:59 pm
Posts: 31
Location: U. Wash., USA
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


Top
 Profile  
Reply with quote  
PostPosted: Fri Dec 07, 2018 6:27 pm 
Offline
User avatar

Joined: Mon Apr 28, 2003 5:44 pm
Posts: 478
Location: Rutgers University
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:
!
!  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.

_________________
John Wilkin: IMCS Rutgers University
71 Dudley Rd, New Brunswick, NJ 08901-8521, USA. ph: 609-630-0559 jwilkin@rutgers.edu


Top
 Profile  
Reply with quote  
PostPosted: Sat Dec 08, 2018 12:21 am 
Offline

Joined: Tue Nov 01, 2016 8:02 pm
Posts: 1
Location: CEOAS-OSU
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:
# 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:
# 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


Attachments:
DickeyetalJAOT94.pdf [1.57 MiB]
Downloaded 22 times
Top
 Profile  
Reply with quote  
PostPosted: Sat Dec 08, 2018 2:07 am 
Offline
User avatar

Joined: Mon Apr 28, 2003 5:44 pm
Posts: 478
Location: Rutgers University
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.

_________________
John Wilkin: IMCS Rutgers University
71 Dudley Rd, New Brunswick, NJ 08901-8521, USA. ph: 609-630-0559 jwilkin@rutgers.edu


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group