River Runoff - Revision history

Wilkin: /* River (Point Sources) Input */

2026-04-27T03:55:47Z

River (Point Sources) Input

← Older revision		Revision as of 03:55, 27 April 2026
Line 4:		Line 4:
	==River (Point Sources) Input==		==River (Point Sources) Input==

	To configure point sources (typically rivers) or sinks and their associated concentrations of tracers (temperature, salt, inert tracers, ecosystem,, and sediment constituents, etc.), it is necessary to specify ~~the~~ information on the locations of the sources, their transport as a volume flux, how the volume flux is to be distributed over vertical s-coordinate levels, flow direction, and tracer concentrations. The information can be provided analytically or in a forcing NetCDF file.		To configure point sources (typically rivers) or sinks and their associated concentrations of tracers (temperature, salt, inert tracers, ecosystem, and sediment constituents, etc.), it is necessary to specify information on the locations of the sources, their transport as a volume flux, how the volume flux is to be distributed over vertical s-coordinate levels, flow direction, and tracer concentrations. The information can be provided analytically or in a forcing NetCDF file.

	To provide the information analytically, you need to define the [[Options\|CPP option]] [[ANA_PSOURCE]] and configure the sources in the [[ana_psource.h]] Functional. This procedure is described later below. If [[ANA_PSOURCE]] is not defined, the default is to look for the information in a source/sink forcing NetCDF file.		To provide the information analytically, you need to define the [[Options\|CPP option]] [[ANA_PSOURCE]] and configure the sources in the [[ana_psource.h]] Functional. This procedure is described later below. If [[ANA_PSOURCE]] is not defined, the default is to look for the information in a source/sink forcing NetCDF file. You can't mix analytical sources and netcdf inputs. It has to be one or the other.

	Regardless of how the source locations and conditions are provided (whether by [[ANA_PSOURCE]] or a NetCDF file), the point source code is activated by two sets of logical flags in [[roms.in]].		Regardless of how the source locations and conditions are provided (whether by [[ANA_PSOURCE]] or a NetCDF file), the point source code is activated by two sets of logical flags in [[roms.in]].

Arango: /* river_direction */

2022-01-24T20:04:02Z

river_direction

← Older revision		Revision as of 20:04, 24 January 2022
Line 89:		Line 89:
	* As a volumetric flux term to horizontal mass divergence and horizontal tracer divergence operators using input switch <span class="red">LwSrc = T</span>. The point source enters the cell through the '''w'''-face at the specified <span class="red">(i,j,k)</span> location.		* As a volumetric flux term to horizontal mass divergence and horizontal tracer divergence operators using input switch <span class="red">LwSrc = T</span>. The point source enters the cell through the '''w'''-face at the specified <span class="red">(i,j,k)</span> location.

	Notice that advection and divergence operators center the point Source/Sink effect at the ρ-point (cell center) for all values of [[Dsrc]].		Notice that advection and divergence operators center the point Source/Sink effect at the ρ-point (cell center) for all values of [[Dsrc]], as shown in the above figure.

	Starting update [https://www.myroms.org/projects/src/ticket/905 src:ticket:905 (Jan 2022)], both <span class="red">LuvSrc</span> and <span class="red">LwSrc</span> methods are allowed in an application. <span class="twilightBlue">However, applying both methods to the same grid location is incorrect.</span>		Starting update [https://www.myroms.org/projects/src/ticket/905 src:ticket:905 (Jan 2022)], both <span class="red">LuvSrc</span> and <span class="red">LwSrc</span> methods are allowed in an application. <span class="twilightBlue">However, applying both methods to the same grid location is incorrect.</span>

Arango: /* river_direction */

2022-01-24T18:17:32Z

river_direction

← Older revision		Revision as of 18:17, 24 January 2022
Line 79:		Line 79:
	=== river_direction ===		=== river_direction ===

	The NetCDF variable <span class="blue">river_direction</span> is a flag indicating the grid-cell face where the point source or sink is specified for a particular application. Its values are read into ROMS variable [[Dsrc]]. A value of <span class="blue">river_direction=1</span> corresponds for flow across the '''u'''-face, <span class="blue">river_direction=1</span> corresponds for flow across the '''v'''-face, and <span class="blue">river_direction=2</span> corresponds for flow across the '''w'''-face, as shown in the diagram below.		The NetCDF variable <span class="blue">river_direction</span> is a flag indicating the grid-cell face where the point source or sink is specified for a particular application. Its values are read into ROMS variable [[Dsrc]]. A value of <span class="blue">river_direction=0</span> corresponds for flow across the '''u'''-face, <span class="blue">river_direction=1</span> corresponds for flow across the '''v'''-face, and <span class="blue">river_direction=2</span> corresponds for flow across the '''w'''-face, as shown in the diagram below.

	[[File:RiversDsrc.png\|460px\|none\|thumb\|Point Source/Sink grid-cell face entry/exit]]		[[File:RiversDsrc.png\|460px\|none\|thumb\|Point Source/Sink grid-cell face entry/exit: <span class="orange">Dsrc=0</span> flow across '''u'''-face, <span class="green">Dsrc=1</span> flow across '''v'''-face, and <span class="cyan">Dsrc=2</span> flow across '''w'''-face.]]

	There are two different methods to impose the point Source/Sink forcing in ROMS:		There are two different methods to impose the point Source/Sink forcing in ROMS:

Arango: /* river_Vshape */

2022-01-14T18:27:53Z

river_Vshape

← Older revision		Revision as of 18:27, 14 January 2022
Line 131:		Line 131:
	=== river_Vshape ===		=== river_Vshape ===

	Variable <span class="blue">river_Vshape</span> sets the fractional distribution of the <span class="blue">river_transport</span> among the vertical cells and must sum to <span class="red">1.0</span> over the vertical. If the sum over <span class="red">k</span> is not <span class="red">1.0</span>, then the actual volume flux will depart from the value given in <span class="blue">river_transport</span>. Notice that <span class="blue">river_Vshape</span> variable can be also used to specify the vertical location of the point Source/Sink.		Variable <span class="blue">river_Vshape</span> sets the fractional distribution of the <span class="blue">river_transport</span> among the vertical cells and must sum to <span class="red">1.0</span> over the vertical. If the sum over <span class="red">k</span> is not <span class="red">1.0</span>, then the actual volume flux will depart from the value given in <span class="blue">river_transport</span>.

			Notice that <span class="blue">river_Vshape</span> variable can be also used to <span class="twilightBlue">specify the vertical location of the point Source/Sink</span>. The point Source/Sink can be distributed over the entire water column or be confined to a particular vertical level like surface, bottom, or other levels in between. The only constraint is that the non-dimensional shape function must sum to <span class="red">1.0</span> over the vertical range <span class="red">k=1:N</span> for each Source/Sink.

	If the river source is in shallow water several grid cells up a river tributary then a simple uniform vertical distribution (all <span class="blue">river_Vshape</span> values = <span class="red">1/s_rho</span>) usually works well. ROMS generates an estuarine circulation to mix the river water with the open ocean. You can manufacture a short tributary in the land/sea mask to do this.		If the river source is in shallow water several grid cells up a river tributary then a simple uniform vertical distribution (all <span class="blue">river_Vshape</span> values = <span class="red">1/s_rho</span>) usually works well. ROMS generates an estuarine circulation to mix the river water with the open ocean. You can manufacture a short tributary in the land/sea mask to do this.

	Some users set inflows directly into a deep cell along a coast and use <span class="blue">river_Vshape</span> to weigh the inflow toward the sea surface. Use caution if you do this because it can generate 2-grid-point noise at the source and lead to tracer concentration overshoot and undershoot which can introduce negative salinities.		Some users set inflows directly into a deep cell along a coast and use <span class="blue">river_Vshape</span> to weigh the inflow toward the sea surface. Use caution if you do this because it can generate 2-grid-point noise at the source and lead to tracer concentration overshoot and undershoot, which can introduce negative salinities.

	== Configuring point sources/sinks with ana_psource.h ==		== Configuring point sources/sinks with ana_psource.h ==

Arango: /* river_direction */

2022-01-13T21:31:40Z

river_direction

← Older revision		Revision as of 21:31, 13 January 2022
Line 91:		Line 91:
	Notice that advection and divergence operators center the point Source/Sink effect at the ρ-point (cell center) for all values of [[Dsrc]].		Notice that advection and divergence operators center the point Source/Sink effect at the ρ-point (cell center) for all values of [[Dsrc]].

	Starting update [https://www.myroms.org/projects/src/ticket/905 src:ticket:905], both <span class="red">LuvSrc</span> and <span class="red">LwSrc</span> methods are allowed in an application. <span class="twilightBlue">However, applying both methods to the same grid location is incorrect.</span>		Starting update [https://www.myroms.org/projects/src/ticket/905 src:ticket:905 (Jan 2022)], both <span class="red">LuvSrc</span> and <span class="red">LwSrc</span> methods are allowed in an application. <span class="twilightBlue">However, applying both methods to the same grid location is incorrect.</span>

	=== river_Xposition and river_Eposition ===		=== river_Xposition and river_Eposition ===

Arango: /* River (Point Sources) Input */

2022-01-13T21:29:37Z

River (Point Sources) Input

Arango: /* River (Point Sources) Input */

2022-01-13T21:26:47Z

River (Point Sources) Input

Arango: /* Function and interpretation of river forcing file variables */

2022-01-13T21:05:22Z

Function and interpretation of river forcing file variables

← Older revision		Revision as of 21:05, 13 January 2022
Line 81:		Line 81:
	The NetCDF variable <span class="blue">river_direction</span> is a flag indicating the grid-cell face where the point source or sink is specified for a particular application. Its values are read into ROMS variable [[Dsrc]]. A value of <span class="blue">river_direction=1</span> corresponds for flow across the '''u'''-face, <span class="blue">river_direction=1</span> corresponds for flow across the '''v'''-face, and <span class="blue">river_direction=2</span> corresponds for flow across the '''w'''-face, as shown in the diagram below.		The NetCDF variable <span class="blue">river_direction</span> is a flag indicating the grid-cell face where the point source or sink is specified for a particular application. Its values are read into ROMS variable [[Dsrc]]. A value of <span class="blue">river_direction=1</span> corresponds for flow across the '''u'''-face, <span class="blue">river_direction=1</span> corresponds for flow across the '''v'''-face, and <span class="blue">river_direction=2</span> corresponds for flow across the '''w'''-face, as shown in the diagram below.

	[[File:RiversDsrc.png\|~~400px~~\|none\|thumb\|Point Source/Sink grid-cell face entry/exit]]		[[File:RiversDsrc.png\|460px\|none\|thumb\|Point Source/Sink grid-cell face entry/exit]]

	There are two different methods to impose the point Source/Sink forcing in ROMS:		There are two different methods to impose the point Source/Sink forcing in ROMS:
Line 101:		Line 101:
	The '''u'''-face or '''v'''-face should be a land/sea mask boundary (''i.e.'', a coastline). If the cell face is placed wholly in the land you get nothing because there is no wet cell for the flow to enter. If the face is in the middle of open water you have a situation where the flow at that cell face computed by the advection algorithm is '''REPLACED''', not augmented, by the source.		The '''u'''-face or '''v'''-face should be a land/sea mask boundary (''i.e.'', a coastline). If the cell face is placed wholly in the land you get nothing because there is no wet cell for the flow to enter. If the face is in the middle of open water you have a situation where the flow at that cell face computed by the advection algorithm is '''REPLACED''', not augmented, by the source.

	~~[[File:RomsRiversLuvSrc.jpg]]~~

	<span class="~~twilightBlue~~">''LuvSrc river point source position indexing. Case (a) river flows into rho cell i,j from the u-face to the left, here river_Xposition = i and river_Eposition = j. Case (b) river flows into rho cell i,j from the u-face to the right, here river_Xposition = i+1 and river_Eposition = j~~.''~~</span>		[[File:RomsRiversLuvSrc.jpg\|600px\|none\|thumb\|<span class="red">LuvSrc</span> river point source position indexing. '''Case (a)''' river flows into rho cell <span class="red">(i,j)</span> from the '''u'''-face to the left, here <span class="blue">river_Xposition = i</span> and <span class="blue">river_Eposition = j</span>. '''Case (b)''' river flows into rho cell <span class="red">(i,j)</span> from the '''u'''-face to the right, here <span class="blue">river_Xposition = i+1</span> and <span class="blue">river_Eposition = j</span>.]]

	When using option <span class="red">LwSrc = T</span>, <span class="blue">river_Xposition</span> and <span class="blue">river_Eposition</span> refer to the <span class="red">(i,j)</span> index of the rho cell it flows into. The <span class="red">(i,j)</span> values must follow ROMS Fortran numbering convention appropriate to rho-points on the ROMS staggered grid. This is illustrated in the figure below.		When using option <span class="red">LwSrc = T</span>, <span class="blue">river_Xposition</span> and <span class="blue">river_Eposition</span> refer to the <span class="red">(i,j)</span> index of the rho cell it flows into. The <span class="red">(i,j)</span> values must follow ROMS Fortran numbering convention appropriate to rho-points on the ROMS staggered grid. This is illustrated in the figure below.

	[[File:RomsRiversLwSrc.jpg]]		[[File:RomsRiversLwSrc.jpg\|600px\|none\|thumb\|<span class="red">LwSrc</span> option river point source position indexing. '''Case (c)''' river flows into rho cell <span class="red">(i,j)</span> directly. Here <span class="blue">river_Xposition = i</span> and <span class="blue">river_Eposition = j</span>. Contrast with the figure of <span class="red">LuvSrc</span> to see why for '''Case (b)''' sources it is necessary to subtract <span class="red">1</span> from <span class="blue">river_Xposition</span> if changing between <span class="red">LwSrc</span> and <span class="red">LuvSrc</span> options.]]

	<span class="twilightBlue">''LwSrc option river point source position indexing. Case (c) river flows into rho cell i,j directly. Here river_Xposition = i and river_Eposition = j. Contrast with the figure of LuvSrc to see why for case (b) sources it is necessary to subtract 1 from river_Xposition if changing between LwSrc and LuvSrc options.''</span>		Comparing the two figures shows that you may not be able to simply switch between <span class="red">LuvSrc</span> and <span class="red">LwSrc</span> options in [[roms.in]] without modifying the <span class="blue">river_Xposition</span> and <span class="blue">river_Eposition</span> information. If all the inflows are '''Case (a)''', and enter the cell from the left then it so happens that the <span class="red">(i,j)</span> index of the receiving rho cell is the same, and <span class="blue">river_Xposition</span> does not need to be modified (likewise for '''v'''-direction inflows at <math>v_{i,j}</math>). But if the inflow is '''Case (b)''' and enters from the right, then the <span class="red">i</span>-index of the rho-cell will be one less and the rivers file needs modification. A change to <span class="blue">river_transport</span> is also required.

	Comparing the two figures shows that you may not be able to simply switch between <span class="red">LuvSrc</span> and <span class="red">LwSrc</span> options in [[roms.in]] without modifying the <span class="blue">river_Xposition</span> and <span class="blue">river_Eposition</span> information. If all the inflows are ~~case <span class="twilightBlue">~~(a)~~</span>~~, and enter the cell from the left then it so happens that the <span class="red">(i,j)</span> index of the receiving rho cell is the same, and <span class="blue">river_Xposition</span> does not need to be modified (likewise for '''v'''-direction inflows at <math>v_{i,j}</math>). But if the inflow is ~~case <span class="twilightBlue">~~(b)~~</span>~~ and enters from the right, then the <span class="red">i</span>-index of the rho-cell will be one less and the rivers file needs modification. A change to <span class="blue">river_transport</span> is also required.

	It is very easy to misconfigure source/sink positions so caution and		It is very easy to misconfigure source/sink positions so caution and

Arango: /* river_Vshape */

2022-01-13T20:49:30Z

river_Vshape

← Older revision		Revision as of 20:49, 13 January 2022
Line 134:		Line 134:
	=== river_Vshape ===		=== river_Vshape ===

	Variable <span class="blue">river_Vshape</span> sets the fractional distribution of the <span class="blue">river_transport</span> among the vertical cells and must sum to ~~'''~~1~~'''~~ over the vertical. If the sum over <span class="red">k</span> is not ~~'''~~1~~'''~~ then the actual volume flux will depart from the value given in <span class="blue">river_transport</span>. Notice that <span class="blue">river_Vshape</span> variable can be also used to specify the vertical location of the point Source/Sink.		Variable <span class="blue">river_Vshape</span> sets the fractional distribution of the <span class="blue">river_transport</span> among the vertical cells and must sum to <span class="red">1.0</span> over the vertical. If the sum over <span class="red">k</span> is not <span class="red">1.0</span>, then the actual volume flux will depart from the value given in <span class="blue">river_transport</span>. Notice that <span class="blue">river_Vshape</span> variable can be also used to specify the vertical location of the point Source/Sink.

	If the river source is in shallow water several grid cells up a river tributary then a simple uniform vertical distribution (all <span class="blue">river_Vshape</span> values = <span class="red">1/s_rho</span>) usually works well. ROMS generates an estuarine circulation to mix the river water with the open ocean. You can manufacture a short tributary in the land/sea mask to do this.		If the river source is in shallow water several grid cells up a river tributary then a simple uniform vertical distribution (all <span class="blue">river_Vshape</span> values = <span class="red">1/s_rho</span>) usually works well. ROMS generates an estuarine circulation to mix the river water with the open ocean. You can manufacture a short tributary in the land/sea mask to do this.

Arango: /* Configuring point sources/sinks with ana_psource.h */

2022-01-13T20:47:21Z

Configuring point sources/sinks with ana_psource.h

← Older revision		Revision as of 20:47, 13 January 2022
Line 144:		Line 144:
	To configure point sources and sinks analytically instead of via a NetCDF file, set the following variables in ana_psource.h		To configure point sources and sinks analytically instead of via a NetCDF file, set the following variables in ana_psource.h

	<div class="box"><span class="twilightBlue">Nsrc ! Number of sources.<br/>Dsrc(is) ! river_direction for each source is = 1,Nsrc<br/>Isrc(is) ! river_Xposition i coordinate (u or v point) for each source<br/>Jsrc(is) ! river_Eposition j coordinate (u or v point) for each source<br/>Qbar(is) ! river_transport for each source following sign conventions noted above<br/>Qshape(is,k) ! river_Vshape distribution of the flow for each source, <br/> ! and for every s-coordinate level k = 1,N</span></div>		<div class="box"><span class="twilightBlue">Nsrc ! Number of sources.<br/>Dsrc(is) ! river_direction for each source is = 1:Nsrc<br/>Isrc(is) ! river_Xposition i-coordinate (u or v point) for each source<br/>Jsrc(is) ! river_Eposition j-coordinate (u or v point) for each source<br/>Qbar(is) ! river_transport for each source following sign conventions noted above<br/>Qshape(is,k) ! river_Vshape distribution of the flow for each source, <br/> ! and for every s-coordinate level k = 1:N</span></div>

	The example code in ana_psource.h for the test cases [[RIVERPLUME2]] and [[SED_TEST1]] illustrate how to compute Qshape using the vertical layer thicknesses (by differencing <span class="red">z_w(i,j,k)</span>) to achieve an inflow velocity profile that is uniform with depth.		The example code in ana_psource.h for the test cases [[RIVERPLUME2]] and [[SED_TEST1]] illustrate how to compute Qshape using the vertical layer thicknesses (by differencing <span class="red">z_w(i,j,k)</span>) to achieve an inflow velocity profile that is uniform with depth.

← Older revision		Revision as of 21:29, 13 January 2022
Line 12:		Line 12:
	{{note}} '''Note:''' In versions of ROMS prior to November 2013 point sources were activated with CPP options [[UV_PSOURCE]] (or [[Q_PSOURCE]]) and [[TS_PSOURCE]]. Those options have been eliminated (see ticket https://www.myroms.org/projects/src/ticket/616) to allow nesting. All grids run the same executable in nesting, so code that might execute in one grid but not all must be activated selectively using logical flags.		{{note}} '''Note:''' In versions of ROMS prior to November 2013 point sources were activated with CPP options [[UV_PSOURCE]] (or [[Q_PSOURCE]]) and [[TS_PSOURCE]]. Those options have been eliminated (see ticket https://www.myroms.org/projects/src/ticket/616) to allow nesting. All grids run the same executable in nesting, so code that might execute in one grid but not all must be activated selectively using logical flags.

	The relevant section of roms.in is:		The relevant section of [[roms.in]] is:

	:<div class="box"><span class="twilightBlue">! Logical switches (TRUE/FALSE) to activate horizontal momentum transport<br/>! point Sources/Sinks (like river runoff transport) and mass point <br/>! Sources/Sinks (like volume vertical influx), [1:Ngrids].<br/><br/> LuvSrc == T ! horizontal momentum transport<br/> LwSrc == F ! volume vertical influx<br/></span></div>		:<div class="box"><span class="twilightBlue">! Logical switches (TRUE/FALSE) to activate horizontal momentum transport<br/>! point Sources/Sinks (like river runoff transport) and mass point <br/>! Sources/Sinks (like volume vertical influx), [1:Ngrids].<br/><br/> LuvSrc == T ! horizontal momentum transport<br/> LwSrc == F ! volume vertical influx<br/></span></div>
Line 30:		Line 30:
	With <span class="red">LuvSrc</span>, the rivers must be placed at cells on the land/sea boundary. With <span class="red">LwSrc</span>, they can in principle be located at any ocean cell.		With <span class="red">LuvSrc</span>, the rivers must be placed at cells on the land/sea boundary. With <span class="red">LwSrc</span>, they can in principle be located at any ocean cell.

	{{note}} '''Note:''' You may not be able to simply switch between <span class="red">LuvSrc</span> and <span class="red">LwSrc</span> options in roms.in without modifying the <span class="blue">river_Xposition</span> and <span class="blue">river_Eposition</span> information. This is explained below.		{{note}} '''Note:''' You may not be able to simply switch between <span class="red">LuvSrc</span> and <span class="red">LwSrc</span> options in [[roms.in]] without modifying the <span class="blue">river_Xposition</span> and <span class="blue">river_Eposition</span> information. This is explained below.

	The introduction of tracer fluxes at point sources/sinks is activated with a second set of logical flags.		The introduction of tracer fluxes at point sources/sinks is activated with a second set of logical flags.
Line 38:		Line 38:
	This example says to impose salinity but not temperature conditions in the river inflow. This requires that variable <span class="blue">river_salt</span> is present in the river forcing NetCDF, or is set in [[ana_psource.h]].		This example says to impose salinity but not temperature conditions in the river inflow. This requires that variable <span class="blue">river_salt</span> is present in the river forcing NetCDF, or is set in [[ana_psource.h]].

	If passive tracers are being used, by having set #define [[T_PASSIVE]] and the associated options in roms.in, then for those tracers to flow in at a point source the LtracerSrc must also be set to True:		If passive tracers are being used, by having set #define [[T_PASSIVE]] and the associated options in [[roms.in]], then for those tracers to flow in at a point source the LtracerSrc must also be set to True:

	:<div class="box"> <span class="twilightBlue">LtracerSrc == F T F T ! temperature, salinity, inert ...</span></div>		:<div class="box"> <span class="twilightBlue">LtracerSrc == F T F T ! temperature, salinity, inert ...</span></div>
Line 54:		Line 54:
	This example says impose concentrations of the first two Fennel model biogeochemical tracers (dissolved nitrate and ammonium) in the rivers but do not impose inflows for any of the other biological model tracers. In this case, variables river_NO3 and river_NH4 must be in the river forcing NetCDF file (or set in ana_psource.h).		This example says impose concentrations of the first two Fennel model biogeochemical tracers (dissolved nitrate and ammonium) in the rivers but do not impose inflows for any of the other biological model tracers. In this case, variables river_NO3 and river_NH4 must be in the river forcing NetCDF file (or set in ana_psource.h).

	The name of the river forcing file is set by its own keyword <span class="blue">SSFNAME</span> in roms.in.		The name of the river forcing file is set by its own keyword <span class="blue">SSFNAME</span> in [[roms.in]].

	:<div class="box"><span class="twilightBlue">! Input Sources/Sinks forcing (like river runoff) ~~file name~~.<br/><br/> SSFNAME == ocean_rivers.nc</span></div>		:<div class="box"><span class="twilightBlue">! Input Sources/Sinks forcing (like river runoff) filename.<br/><br/> SSFNAME == ocean_rivers.nc</span></div>

	{{note}} '''Note:'''This is a change from versions before 11/25/2013 in which the river file was included in the [[FRCNAME]] list with other forcing files (meteorology, tides, etc.).		{{note}} '''Note:'''This is a change from versions before 11/25/2013 in which the river file was included in the [[FRCNAME]] list with other forcing files (meteorology, tides, etc.).

	The rivers NetCDF forcing file format is presented in the template frc_rivers.cdl file (in the Data/ROMS/CDL section of the svn distribution).		The rivers NetCDF forcing file format is presented in the template <span class="blue">frc_rivers.cdl</span> file (in the Data/ROMS/CDL section of the svn distribution).

	== River NetCDF template ==		== River NetCDF template ==

← Older revision		Revision as of 21:26, 13 January 2022
Line 4:		Line 4:
	==River (Point Sources) Input==		==River (Point Sources) Input==

	To configure point sources (typically rivers) or sinks and their associated concentrations of tracers (temperature, salt, inert tracers, ecosystem and sediment constituents etc.) it is necessary to specify information on the locations of the sources, their transport as a volume flux, how the volume flux is to be distributed over vertical s-coordinate levels, flow direction, and tracer concentrations. The information can be provided analytically or in a forcing NetCDF file.		To configure point sources (typically rivers) or sinks and their associated concentrations of tracers (temperature, salt, inert tracers, ecosystem,, and sediment constituents, etc.), it is necessary to specify the information on the locations of the sources, their transport as a volume flux, how the volume flux is to be distributed over vertical s-coordinate levels, flow direction, and tracer concentrations. The information can be provided analytically or in a forcing NetCDF file.

	To provide the information analytically you need to define the [[Options\|CPP option]] [[ANA_PSOURCE]] and configure the sources in the [[ana_psource.h]] Functional. This procedure is described later below. If [[ANA_PSOURCE]] is not defined the default is to look for the information in a source/sink forcing NetCDF file.		To provide the information analytically, you need to define the [[Options\|CPP option]] [[ANA_PSOURCE]] and configure the sources in the [[ana_psource.h]] Functional. This procedure is described later below. If [[ANA_PSOURCE]] is not defined, the default is to look for the information in a source/sink forcing NetCDF file.

	Regardless of how the source locations and conditions are provided (whether by [[ANA_PSOURCE]] or a NetCDF file) the point source code is activated by two sets of logical flags in roms.in.		Regardless of how the source locations and conditions are provided (whether by [[ANA_PSOURCE]] or a NetCDF file), the point source code is activated by two sets of logical flags in [[roms.in]].

	{{note}} '''Note:''' In versions of ROMS prior to November 2013 point sources were activated with CPP options UV_PSOURCE (or Q_PSOURCE) and TS_PSOURCE. Those options have been eliminated (see ticket https://www.myroms.org/projects/src/ticket/616) to allow ~~for~~ nesting. ~~In nesting all~~ grids run the same executable, so code that might execute in one grid but not all must be activated selectively using logical flags.		{{note}} '''Note:''' In versions of ROMS prior to November 2013 point sources were activated with CPP options [[UV_PSOURCE]] (or [[Q_PSOURCE]]) and [[TS_PSOURCE]]. Those options have been eliminated (see ticket https://www.myroms.org/projects/src/ticket/616) to allow nesting. All grids run the same executable in nesting, so code that might execute in one grid but not all must be activated selectively using logical flags.

	The relevant section of roms.in is:		The relevant section of roms.in is:

	:<div class="box">! Logical switches (TRUE/FALSE) to activate horizontal momentum transport<br/>! point Sources/Sinks (like river runoff transport) and mass point <br/>! Sources/Sinks (like volume vertical influx), [1:Ngrids].<br/><br/> LuvSrc == T ! horizontal momentum transport<br/> LwSrc == F ! volume vertical influx<br/></div>		:<div class="box"><span class="twilightBlue">! Logical switches (TRUE/FALSE) to activate horizontal momentum transport<br/>! point Sources/Sinks (like river runoff transport) and mass point <br/>! Sources/Sinks (like volume vertical influx), [1:Ngrids].<br/><br/> LuvSrc == T ! horizontal momentum transport<br/> LwSrc == F ! volume vertical influx<br/></span></div>

	The LuvSrc option imposes sources/sinks via the horizontal velocity that crosses a u-face or v-face of a cell. The advection operator then ~~takes the divergence of~~ the associated volume and tracer fluxes.		The <span class="red">LuvSrc</span> option imposes sources/sinks via the horizontal velocity that crosses a u-face or v-face of a cell. The advection operator then diverges the associated volume and tracer fluxes.

	The LwSrc option imposes sources by directly adding to the volume and tracer divergence terms.		The <span class="red">LwSrc</span> option imposes sources by directly adding to the volume and tracer divergence terms.

	Only one of LuvSrc or LwSrc can be true and this selection applies to all sources in the model set-up.		Only one of <span class="red">LuvSrc</span> or <span class="red">LwSrc</span> can be true and this selection applies to all sources in the model set-up.

	Prior to July 2020 the LwSrc option was coded incorrectly and the majority of ROMS users opted for the LuvSrc approach when specifying river inflows. The LwSrc option is now corrected (see ticket https://www.myroms.org/projects/src/ticket/860) and both options are valid choices.		Prior to July 2020 the <span class="red">LwSrc</span> option was coded incorrectly and the majority of ROMS users opted for the LuvSrc approach when specifying river inflows. The <span class="red">LwSrc</span> option is now corrected (see ticket https://www.myroms.org/projects/src/ticket/860) and both options are valid choices.

	The principal difference between these options is that LuvSrc adds horizontal momentum to the system at the inflow cell whereas LwSrc does not.		The principal difference between these options is that LuvSrc adds horizontal momentum to the system at the inflow cell, whereas LwSrc does not.

	With LuvSrc it can happen that at very high river discharge the inflow velocity violates CFL stability because the inflow cell area is small (narrow width and/or small height h+~~zeta~~). In this situation, LwSrc should still be stable because it does not affect the horizontal momentum equations.		With LuvSrc it can happen that at very high river discharge the inflow velocity violates CFL stability because the inflow cell area is small (narrow width and/or small height <span class="red">h+ζ</span>). In this situation, <span class="red">LwSrc</span> should still be stable because it does not affect the horizontal momentum equations.

	With LuvSrc the rivers must be placed at cells on the land/sea boundary. With LwSrc they can in principle be located at any ocean cell.		With <span class="red">LuvSrc</span>, the rivers must be placed at cells on the land/sea boundary. With <span class="red">LwSrc</span>, they can in principle be located at any ocean cell.

	{{note}} '''Note:''' You may not be able to simply switch between LuvSrc and LwSrc options in roms.in without modifying the river_Xposition and river_Eposition information. This is explained below.		{{note}} '''Note:''' You may not be able to simply switch between <span class="red">LuvSrc</span> and <span class="red">LwSrc</span> options in roms.in without modifying the <span class="blue">river_Xposition</span> and <span class="blue">river_Eposition</span> information. This is explained below.

	The introduction of tracer fluxes at point sources/sinks is activated with a second set of logical flags.		The introduction of tracer fluxes at point sources/sinks is activated with a second set of logical flags.

	:<div class="box">! Logical switches (TRUE/FALSE) to activate tracers point Sources/Sinks<br/>! (like river runoff) and to specify which tracer variables to consider:<br/>! [1:NAT+NPT,Ngrids]. See glossary below for details.<br/><br/> LtracerSrc == F T ! temperature, salinity, inert ...</div>		:<div class="box"><span class="twilightBlue">! Logical switches (TRUE/FALSE) to activate tracers point Sources/Sinks<br/>! (like river runoff) and to specify which tracer variables to consider:<br/>! [1:NAT+NPT,Ngrids]. See glossary below for details.<br/><br/> LtracerSrc == F T ! temperature, salinity, inert ...</span></div>

	This example says impose salinity but not temperature conditions in the river inflow. This requires that variable "river_salt" is present in the river forcing NetCDF, or is set in ana_psource.h.		This example says to impose salinity but not temperature conditions in the river inflow. This requires that variable <span class="blue">river_salt</span> is present in the river forcing NetCDF, or is set in [[ana_psource.h]].

	If passive tracers are being used, by having set #define T_PASSIVE and the associated options in roms.in, then for those tracers to flow in at a point source the LtracerSrc must also be set to True:		If passive tracers are being used, by having set #define [[T_PASSIVE]] and the associated options in roms.in, then for those tracers to flow in at a point source the LtracerSrc must also be set to True:

	:<div class="box"> LtracerSrc == F T F T ! temperature, salinity, inert ...</div>		:<div class="box"> <span class="twilightBlue">LtracerSrc == F T F T ! temperature, salinity, inert ...</span></div>

	This example says impose the concentration of passive tracer 2, but not passive tracer 1, in all the rivers. (Remember, the first two flags are for temp and salt). In this case variable river_dye_02 must be in the river forcing NetCDF (or set in ana_psource.h). If you want dye_02 to enter through some rivers but not all, then you set the concentration of river_dye_02 to zero in the appropriate rivers in the forcing file.		This example says impose the concentration of passive tracer 2, but not passive tracer 1, in all the rivers. (Remember, the first two flags are for temp and salt). In this case, variable <span class="blue">river_dye_02</span> must be in the river forcing NetCDF (or set in [[ana_psource.h]]). If you want <span class="red">dye_02</span> to enter through some rivers but not all, then you set the concentration of <span class="blue">river_dye_02</span> to zero in the appropriate rivers in the forcing file.

	The LtracerSrc logical switches replace and eliminate the ~~for~~ variable "river_flag(river)" in the input rivers forcing NetCDF file.		The <span class="red">LtracerSrc</span> logical switches replace and eliminate the variable <span class="blue">river_flag(river)</span> in the input rivers forcing NetCDF file.

	In applications where point sources of biogeochemical or sediment tracers are to be imposed there are corresponding logical flags in e.g. bio_Fennel.in and sediment.in.		In applications where point sources of biogeochemical or sediment tracers are to be imposed there are corresponding logical flags in ''e.g.'' [[bio_Fennel.in]] and [[sediment.in]].

	For example, in bio_Fennel.in:		For example, in [[bio_Fennel.in]]:

	:<div class="box">! Logical switches (TRUE/FALSE) to activate biological tracers point<br/>! Sources/Sinks (like river runoff) and to specify which tracer variables<br/>! to consider: [NBT,Ngrids] values are expected. See glossary below for<br/>! details.<br/><br/> LtracerSrc == T T 10*F</div>		:<div class="box"><span class="twilightBlue">! Logical switches (TRUE/FALSE) to activate biological tracers point<br/>! Sources/Sinks (like river runoff) and to specify which tracer variables<br/>! to consider: [NBT,Ngrids] values are expected. See glossary below for<br/>! details.<br/><br/> LtracerSrc == T T 10*F</span></div>

	This example says impose concentrations of the first two Fennel model biogeochemical tracers (dissolved nitrate and ammonium) in the rivers but do not impose inflows for any of the other biological model tracers. In this case, variables river_NO3 and river_NH4 must be in the river forcing NetCDF file (or set in ana_psource.h).		This example says impose concentrations of the first two Fennel model biogeochemical tracers (dissolved nitrate and ammonium) in the rivers but do not impose inflows for any of the other biological model tracers. In this case, variables river_NO3 and river_NH4 must be in the river forcing NetCDF file (or set in ana_psource.h).
Line 56:		Line 56:
	The name of the river forcing file is set by its own keyword <span class="blue">SSFNAME</span> in roms.in.		The name of the river forcing file is set by its own keyword <span class="blue">SSFNAME</span> in roms.in.

	:<div class="box">! Input Sources/Sinks forcing (like river runoff) file name.<br/><br/> SSFNAME == ocean_rivers.nc</div>		:<div class="box"><span class="twilightBlue">! Input Sources/Sinks forcing (like river runoff) file name.<br/><br/> SSFNAME == ocean_rivers.nc</span></div>

	{{note}} '''Note:'''This is a change from versions ~~prior to~~ 11/25/2013 in which the river file was included in the FRCNAME list with other forcing files (meteorology, tides, etc).		{{note}} '''Note:'''This is a change from versions before 11/25/2013 in which the river file was included in the [[FRCNAME]] list with other forcing files (meteorology, tides, etc.).

	The ~~format of the~~ rivers NetCDF forcing file is presented in the template frc_rivers.cdl file (in the Data/ROMS/CDL section of the svn distribution).		The rivers NetCDF forcing file format is presented in the template frc_rivers.cdl file (in the Data/ROMS/CDL section of the svn distribution).

	== River NetCDF template ==		== River NetCDF template ==