varinfo.yaml - Revision history

Arango at 17:12, 29 April 2022

2022-04-29T17:12:56Z

← Older revision		Revision as of 17:12, 29 April 2022
Line 6:		Line 6:
	The '''varinfo.yaml''' file specifies ROMS input and output fields metadata. Starting '''svn''' revision '''-r 1902''' released on March 1, 2022, the ROMS metadata is managed with a YAML file, and the regular text file '''varinfo.dat''' is deprecated. The YAML files are simple, easy to follow, elegant, portable, and expandable. ROMS can now process YAML files with its parser module, '''yaml_parser.F'''. Therefore, there is no need to use third-party YAML parsers. Basically, '''varinfo.yaml''' has the following structure:		The '''varinfo.yaml''' file specifies ROMS input and output fields metadata. Starting '''svn''' revision '''-r 1902''' released on March 1, 2022, the ROMS metadata is managed with a YAML file, and the regular text file '''varinfo.dat''' is deprecated. The YAML files are simple, easy to follow, elegant, portable, and expandable. ROMS can now process YAML files with its parser module, '''yaml_parser.F'''. Therefore, there is no need to use third-party YAML parsers. Basically, '''varinfo.yaml''' has the following structure:

	<div class="~~box~~"><span class="violet">svn_repository:</span> <span class="twilightBlue">$URL$</span><br /><span class="violet">convention:</span> <span class="twilightBlue">CF 1.10</span><br /><br /><span class="twilightBlue">#</span><span class="violet">shortwave:</span> <span class="green">&SWRAD</span> <span class="twilightBlue">swrad_daily</span><br /><span class="violet">shortwave:</span> <span class="green">&SWRAD</span> <span class="twilightBlue">swrad</span><br /><br /><span class="violet">metadata:</span><br /><br /> - <span class="violet">variable:</span> <span class="twilightBlue">temp # Input/Output</span><br /> <span class="violet">standard_name:</span> <span class="twilightBlue">sea_water_potential_temperature</span><br /> <span class="violet">long_name:</span> <span class="twilightBlue">potential temperature</span><br /> <span class="violet">units:</span> <span class="twilightBlue">Celsius # [Celsius]</span><br /> <span class="violet">field:</span> <span class="twilightBlue">temperature</span><br /> <span class="violet">time:</span> <span class="twilightBlue">ocean_time</span><br /> <span class="violet">index_code:</span> <span class="twilightBlue">idTvar(itemp)</span><br /> <span class="violet">type:</span> <span class="twilightBlue">r3dvar</span><br /> <span class="violet">add_offset:</span> <span class="twilightBlue">0.0d0</span><br /> <span class="violet">scale:</span> <span class="twilightBlue">1.0d0</span><br /><br /> - <span class="violet">variable:</span> <span class="salmon">*SWRAD</span> <span class="twilightBlue"># Input/Output</span><br /> <span class="violet">standard_name:</span> <span class="twilightBlue">net_downward_shortwave_flux_at_sea_water_surface</span><br /> <span class="violet">long_name:</span> <span class="twilightBlue">solar shortwave radiation flux</span><br /> <span class="violet">units:</span> <span class="twilightBlue">watt meter-2 # Input: [Watt/m2]</span><br /> <span class="violet">field:</span> <span class="twilightBlue">shortwave radiation # [Celsius m/s]</span><br /> <span class="violet">time:</span> <span class="twilightBlue">srf_time # Output: [Watt/m2]</span><br /> <span class="violet">index_code:</span> <span class="twilightBlue">idSrad</span><br /> <span class="violet">type:</span> <span class="twilightBlue">r2dvar</span><br /> <span class="violet">add_offset:</span> <span class="twilightBlue">0.0d0</span><br /> <span class="violet">scale:</span> <span class="twilightBlue">1.0d0</span><br /></span></div>		<div class="code"><span class="violet">svn_repository:</span> <span class="twilightBlue">$URL$</span><br /><span class="violet">convention:</span> <span class="twilightBlue">CF 1.10</span><br /><br /><span class="twilightBlue">#</span><span class="violet">shortwave:</span> <span class="green">&SWRAD</span> <span class="twilightBlue">swrad_daily</span><br /><span class="violet">shortwave:</span> <span class="green">&SWRAD</span> <span class="twilightBlue">swrad</span><br /><br /><span class="violet">metadata:</span><br /><br /> - <span class="violet">variable:</span> <span class="twilightBlue">temp # Input/Output</span><br /> <span class="violet">standard_name:</span> <span class="twilightBlue">sea_water_potential_temperature</span><br /> <span class="violet">long_name:</span> <span class="twilightBlue">potential temperature</span><br /> <span class="violet">units:</span> <span class="twilightBlue">Celsius # [Celsius]</span><br /> <span class="violet">field:</span> <span class="twilightBlue">temperature</span><br /> <span class="violet">time:</span> <span class="twilightBlue">ocean_time</span><br /> <span class="violet">index_code:</span> <span class="twilightBlue">idTvar(itemp)</span><br /> <span class="violet">type:</span> <span class="twilightBlue">r3dvar</span><br /> <span class="violet">add_offset:</span> <span class="twilightBlue">0.0d0</span><br /> <span class="violet">scale:</span> <span class="twilightBlue">1.0d0</span><br /><br /> - <span class="violet">variable:</span> <span class="salmon">*SWRAD</span> <span class="twilightBlue"># Input/Output</span><br /> <span class="violet">standard_name:</span> <span class="twilightBlue">net_downward_shortwave_flux_at_sea_water_surface</span><br /> <span class="violet">long_name:</span> <span class="twilightBlue">solar shortwave radiation flux</span><br /> <span class="violet">units:</span> <span class="twilightBlue">watt meter-2 # Input: [Watt/m2]</span><br /> <span class="violet">field:</span> <span class="twilightBlue">shortwave radiation # [Celsius m/s]</span><br /> <span class="violet">time:</span> <span class="twilightBlue">srf_time # Output: [Watt/m2]</span><br /> <span class="violet">index_code:</span> <span class="twilightBlue">idSrad</span><br /> <span class="violet">type:</span> <span class="twilightBlue">r2dvar</span><br /> <span class="violet">add_offset:</span> <span class="twilightBlue">0.0d0</span><br /> <span class="violet">scale:</span> <span class="twilightBlue">1.0d0</span><br /></span></div>

	The field key and value pair in the YAML blocking list is as follows:		The field key and value pair in the YAML blocking list is as follows:
Line 194:		Line 194:
	In '''varinfo.yaml''', there must still be one entry for each unique <span class="violet">index_code</span> but you can have each entry point to the same <span class="twilightBlue">ONES_west</span> data. Assign the value you want for each variable in the scale entry. This scale will be multiplied by the 1.0 on input to set the open boundary values.		In '''varinfo.yaml''', there must still be one entry for each unique <span class="violet">index_code</span> but you can have each entry point to the same <span class="twilightBlue">ONES_west</span> data. Assign the value you want for each variable in the scale entry. This scale will be multiplied by the 1.0 on input to set the open boundary values.

	<div class="~~box~~"> - <span class="violet">variable:</span> <span class="twilightBlue">ONES_west # Input</span><br /> <span class="violet">standard_name:</span> <span class="twilightBlue">mole_concentration_of_ammonium_expressed_as_nitrogen_in_sea_water</span><br /> <span class="violet">long_name:</span> <span class="twilightBlue">ammonium western boundary condition</span><br /> <span class="violet">units:</span> <span class="twilightBlue">millimole_nitrogen meter-3 # [millimole/m3]</span><br /> <span class="violet">field:</span> <span class="twilightBlue">NH4 western-boundary</span><br /> <span class="violet">time:</span> <span class="twilightBlue">NH4_time</span><br /> <span class="violet">index_code:</span> <span class="twilightBlue">idTbry(iwest,iNH4_)</span><br /> <span class="violet">type:</span> <span class="twilightBlue">nulvar</span><br /> <span class="violet">add_offset:</span> <span class="twilightBlue">0.0d0</span><br /> <span class="violet">scale:</span> <span class="twilightBlue">0.1d0 # make all values equal to 0.1 millimole meter-3</span><br /><br /> - <span class="violet">variable:</span> <span class="twilightBlue">ONES_west # Input</span><br /> <span class="violet">standard_name:</span> <span class="twilightBlue">mole_concentration_of_phytoplankton_expressed_as_nitrogen_in_sea_water</span><br /> <span class="violet">long_name:</span> <span class="twilightBlue">phytoplankton western boundary condition</span><br /> <span class="violet">units:</span> <span class="twilightBlue">millimole_nitrogen meter-3 # [millimole/m3]</span><br /> <span class="violet">field:</span> <span class="twilightBlue">phytoplankton western-boundary</span><br /> <span class="violet">time:</span> <span class="twilightBlue">phyt_time</span><br /> <span class="violet">index_code:</span> <span class="twilightBlue">idTbry(iwest,iPhyt)</span><br /> <span class="violet">type:</span> <span class="twilightBlue">nulvar</span><br /> <span class="violet">add_offset:</span> <span class="twilightBlue">0.0d0</span><br /> <span class="violet">scale:</span> <span class="twilightBlue">0.08d0 # make all values equal to 0.08 millimole meter-3</span><br /></div>		<div class="code"> - <span class="violet">variable:</span> <span class="twilightBlue">ONES_west # Input</span><br /> <span class="violet">standard_name:</span> <span class="twilightBlue">mole_concentration_of_ammonium_expressed_as_nitrogen_in_sea_water</span><br /> <span class="violet">long_name:</span> <span class="twilightBlue">ammonium western boundary condition</span><br /> <span class="violet">units:</span> <span class="twilightBlue">millimole_nitrogen meter-3 # [millimole/m3]</span><br /> <span class="violet">field:</span> <span class="twilightBlue">NH4 western-boundary</span><br /> <span class="violet">time:</span> <span class="twilightBlue">NH4_time</span><br /> <span class="violet">index_code:</span> <span class="twilightBlue">idTbry(iwest,iNH4_)</span><br /> <span class="violet">type:</span> <span class="twilightBlue">nulvar</span><br /> <span class="violet">add_offset:</span> <span class="twilightBlue">0.0d0</span><br /> <span class="violet">scale:</span> <span class="twilightBlue">0.1d0 # make all values equal to 0.1 millimole meter-3</span><br /><br /> - <span class="violet">variable:</span> <span class="twilightBlue">ONES_west # Input</span><br /> <span class="violet">standard_name:</span> <span class="twilightBlue">mole_concentration_of_phytoplankton_expressed_as_nitrogen_in_sea_water</span><br /> <span class="violet">long_name:</span> <span class="twilightBlue">phytoplankton western boundary condition</span><br /> <span class="violet">units:</span> <span class="twilightBlue">millimole_nitrogen meter-3 # [millimole/m3]</span><br /> <span class="violet">field:</span> <span class="twilightBlue">phytoplankton western-boundary</span><br /> <span class="violet">time:</span> <span class="twilightBlue">phyt_time</span><br /> <span class="violet">index_code:</span> <span class="twilightBlue">idTbry(iwest,iPhyt)</span><br /> <span class="violet">type:</span> <span class="twilightBlue">nulvar</span><br /> <span class="violet">add_offset:</span> <span class="twilightBlue">0.0d0</span><br /> <span class="violet">scale:</span> <span class="twilightBlue">0.08d0 # make all values equal to 0.08 millimole meter-3</span><br /></div>

	=== Metadata: standard_name ===		=== Metadata: standard_name ===

Arango at 23:26, 27 April 2022

2022-04-27T23:26:29Z

← Older revision		Revision as of 23:26, 27 April 2022
Line 1:		Line 1:
	<div class="title">varinfo.yaml</div>		<div class="title">ROMS I/O Metadata File: varinfo.yaml</div>

	__TOC__		__TOC__

Robertson at 18:35, 27 April 2022

2022-04-27T18:35:45Z

← Older revision		Revision as of 18:35, 27 April 2022
Line 4:		Line 4:


	The '''varinfo.yaml''' file specifies ROMS input and output fields metadata. Starting '''svn''' revision '''-r 1902''' released on March 1, 2022, the ROMS metadata is managed with a YAML file, and the regular text file '''varinfo.dat''' is deprecated. The YAML files are simple, easy to follow, elegant, portable, and expandable. ROMS now ~~can~~ process YAML files with its parser module, '''yaml_parser.F'''. Therefore, there is no need to use third-party YAML parsers. Basically, '''varinfo.yaml''' ~~have~~ the following structure:		The '''varinfo.yaml''' file specifies ROMS input and output fields metadata. Starting '''svn''' revision '''-r 1902''' released on March 1, 2022, the ROMS metadata is managed with a YAML file, and the regular text file '''varinfo.dat''' is deprecated. The YAML files are simple, easy to follow, elegant, portable, and expandable. ROMS can now process YAML files with its parser module, '''yaml_parser.F'''. Therefore, there is no need to use third-party YAML parsers. Basically, '''varinfo.yaml''' has the following structure:

	<div class="box"><span class="violet">svn_repository:</span> <span class="twilightBlue">$URL$</span><br /><span class="violet">convention:</span> <span class="twilightBlue">CF 1.10</span><br /><br /><span class="twilightBlue">#</span><span class="violet">shortwave:</span> <span class="green">&SWRAD</span> <span class="twilightBlue">swrad_daily</span><br /><span class="violet">shortwave:</span> <span class="green">&SWRAD</span> <span class="twilightBlue">swrad</span><br /><br /><span class="violet">metadata:</span><br /><br /> - <span class="violet">variable:</span> <span class="twilightBlue">temp # Input/Output</span><br /> <span class="violet">standard_name:</span> <span class="twilightBlue">sea_water_potential_temperature</span><br /> <span class="violet">long_name:</span> <span class="twilightBlue">potential temperature</span><br /> <span class="violet">units:</span> <span class="twilightBlue">Celsius # [Celsius]</span><br /> <span class="violet">field:</span> <span class="twilightBlue">temperature</span><br /> <span class="violet">time:</span> <span class="twilightBlue">ocean_time</span><br /> <span class="violet">index_code:</span> <span class="twilightBlue">idTvar(itemp)</span><br /> <span class="violet">type:</span> <span class="twilightBlue">r3dvar</span><br /> <span class="violet">add_offset:</span> <span class="twilightBlue">0.0d0</span><br /> <span class="violet">scale:</span> <span class="twilightBlue">1.0d0</span><br /><br /> - <span class="violet">variable:</span> <span class="salmon">*SWRAD</span> <span class="twilightBlue"># Input/Output</span><br /> <span class="violet">standard_name:</span> <span class="twilightBlue">net_downward_shortwave_flux_at_sea_water_surface</span><br /> <span class="violet">long_name:</span> <span class="twilightBlue">solar shortwave radiation flux</span><br /> <span class="violet">units:</span> <span class="twilightBlue">watt meter-2 # Input: [Watt/m2]</span><br /> <span class="violet">field:</span> <span class="twilightBlue">shortwave radiation # [Celsius m/s]</span><br /> <span class="violet">time:</span> <span class="twilightBlue">srf_time # Output: [Watt/m2]</span><br /> <span class="violet">index_code:</span> <span class="twilightBlue">idSrad</span><br /> <span class="violet">type:</span> <span class="twilightBlue">r2dvar</span><br /> <span class="violet">add_offset:</span> <span class="twilightBlue">0.0d0</span><br /> <span class="violet">scale:</span> <span class="twilightBlue">1.0d0</span><br /></span></div>		<div class="box"><span class="violet">svn_repository:</span> <span class="twilightBlue">$URL$</span><br /><span class="violet">convention:</span> <span class="twilightBlue">CF 1.10</span><br /><br /><span class="twilightBlue">#</span><span class="violet">shortwave:</span> <span class="green">&SWRAD</span> <span class="twilightBlue">swrad_daily</span><br /><span class="violet">shortwave:</span> <span class="green">&SWRAD</span> <span class="twilightBlue">swrad</span><br /><br /><span class="violet">metadata:</span><br /><br /> - <span class="violet">variable:</span> <span class="twilightBlue">temp # Input/Output</span><br /> <span class="violet">standard_name:</span> <span class="twilightBlue">sea_water_potential_temperature</span><br /> <span class="violet">long_name:</span> <span class="twilightBlue">potential temperature</span><br /> <span class="violet">units:</span> <span class="twilightBlue">Celsius # [Celsius]</span><br /> <span class="violet">field:</span> <span class="twilightBlue">temperature</span><br /> <span class="violet">time:</span> <span class="twilightBlue">ocean_time</span><br /> <span class="violet">index_code:</span> <span class="twilightBlue">idTvar(itemp)</span><br /> <span class="violet">type:</span> <span class="twilightBlue">r3dvar</span><br /> <span class="violet">add_offset:</span> <span class="twilightBlue">0.0d0</span><br /> <span class="violet">scale:</span> <span class="twilightBlue">1.0d0</span><br /><br /> - <span class="violet">variable:</span> <span class="salmon">*SWRAD</span> <span class="twilightBlue"># Input/Output</span><br /> <span class="violet">standard_name:</span> <span class="twilightBlue">net_downward_shortwave_flux_at_sea_water_surface</span><br /> <span class="violet">long_name:</span> <span class="twilightBlue">solar shortwave radiation flux</span><br /> <span class="violet">units:</span> <span class="twilightBlue">watt meter-2 # Input: [Watt/m2]</span><br /> <span class="violet">field:</span> <span class="twilightBlue">shortwave radiation # [Celsius m/s]</span><br /> <span class="violet">time:</span> <span class="twilightBlue">srf_time # Output: [Watt/m2]</span><br /> <span class="violet">index_code:</span> <span class="twilightBlue">idSrad</span><br /> <span class="violet">type:</span> <span class="twilightBlue">r2dvar</span><br /> <span class="violet">add_offset:</span> <span class="twilightBlue">0.0d0</span><br /> <span class="violet">scale:</span> <span class="twilightBlue">1.0d0</span><br /></span></div>

Arango at 15:42, 26 April 2022

2022-04-26T15:42:26Z

← Older revision		Revision as of 15:42, 26 April 2022
Line 6:		Line 6:
	The '''varinfo.yaml''' file specifies ROMS input and output fields metadata. Starting '''svn''' revision '''-r 1902''' released on March 1, 2022, the ROMS metadata is managed with a YAML file, and the regular text file '''varinfo.dat''' is deprecated. The YAML files are simple, easy to follow, elegant, portable, and expandable. ROMS now can process YAML files with its parser module, '''yaml_parser.F'''. Therefore, there is no need to use third-party YAML parsers. Basically, '''varinfo.yaml''' have the following structure:		The '''varinfo.yaml''' file specifies ROMS input and output fields metadata. Starting '''svn''' revision '''-r 1902''' released on March 1, 2022, the ROMS metadata is managed with a YAML file, and the regular text file '''varinfo.dat''' is deprecated. The YAML files are simple, easy to follow, elegant, portable, and expandable. ROMS now can process YAML files with its parser module, '''yaml_parser.F'''. Therefore, there is no need to use third-party YAML parsers. Basically, '''varinfo.yaml''' have the following structure:

	<div class="box"><span class="violet">svn_repository:</span> <span class="twilightBlue">$URL$</span><br /><span class="violet">convention:</span> <span class="twilightBlue">CF 1.10</span><br /><br /><span class="twilightBlue">#</span><span class="violet">shortwave:</span> <span class="green">&SWRAD</span> <span class="twilightBlue">swrad_daily</span><br /><span class="violet">shortwave:</span> <span class="green">&SWRAD</span> <span class="twilightBlue">swrad</span><br /><br /><span class="violet">metadata:</span><br /><br /> - <span class="violet">variable:</span> <span class="twilightBlue">temp # Input/Output</span><br /> <span class="violet">standard_name:</span> <span class="twilightBlue">sea_water_potential_temperature</span><br /> <span class="violet">long_name:</span> <span class="twilightBlue">potential temperature</span><br /> <span class="violet">units:</span> <span class="twilightBlue">Celsius # [Celsius]</span><br /> <span class="violet">field:</span> <span class="twilightBlue">temperature</span><br /> <span class="violet">time:</span> <span class="twilightBlue">ocean_time</span><br /> <span class="violet">index_code:</span> <span class="twilightBlue">idTvar(itemp)</span><br /> <span class="violet">type:</span> <span class="twilightBlue">r3dvar</span><br /> <span class="violet">add_offset:</span> <span class="twilightBlue">0.0d0</span><br /> <span class="violet">scale:</span> <span class="twilightBlue">1.0d0</span><br /><br /> - <span class="violet">variable:</span> <span class="~~orange~~">*SWRAD</span> <span class="twilightBlue"># Input/Output</span><br /> <span class="violet">standard_name:</span> <span class="twilightBlue">net_downward_shortwave_flux_at_sea_water_surface</span><br /> <span class="violet">long_name:</span> <span class="twilightBlue">solar shortwave radiation flux</span><br /> <span class="violet">units:</span> <span class="twilightBlue">watt meter-2 # Input: [Watt/m2]</span><br /> <span class="violet">field:</span> <span class="twilightBlue">shortwave radiation # [Celsius m/s]</span><br /> <span class="violet">time:</span> <span class="twilightBlue">srf_time # Output: [Watt/m2]</span><br /> <span class="violet">index_code:</span> <span class="twilightBlue">idSrad</span><br /> <span class="violet">type:</span> <span class="twilightBlue">r2dvar</span><br /> <span class="violet">add_offset:</span> <span class="twilightBlue">0.0d0</span><br /> <span class="violet">scale:</span> <span class="twilightBlue">1.0d0</span><br /></span></div>		<div class="box"><span class="violet">svn_repository:</span> <span class="twilightBlue">$URL$</span><br /><span class="violet">convention:</span> <span class="twilightBlue">CF 1.10</span><br /><br /><span class="twilightBlue">#</span><span class="violet">shortwave:</span> <span class="green">&SWRAD</span> <span class="twilightBlue">swrad_daily</span><br /><span class="violet">shortwave:</span> <span class="green">&SWRAD</span> <span class="twilightBlue">swrad</span><br /><br /><span class="violet">metadata:</span><br /><br /> - <span class="violet">variable:</span> <span class="twilightBlue">temp # Input/Output</span><br /> <span class="violet">standard_name:</span> <span class="twilightBlue">sea_water_potential_temperature</span><br /> <span class="violet">long_name:</span> <span class="twilightBlue">potential temperature</span><br /> <span class="violet">units:</span> <span class="twilightBlue">Celsius # [Celsius]</span><br /> <span class="violet">field:</span> <span class="twilightBlue">temperature</span><br /> <span class="violet">time:</span> <span class="twilightBlue">ocean_time</span><br /> <span class="violet">index_code:</span> <span class="twilightBlue">idTvar(itemp)</span><br /> <span class="violet">type:</span> <span class="twilightBlue">r3dvar</span><br /> <span class="violet">add_offset:</span> <span class="twilightBlue">0.0d0</span><br /> <span class="violet">scale:</span> <span class="twilightBlue">1.0d0</span><br /><br /> - <span class="violet">variable:</span> <span class="salmon">*SWRAD</span> <span class="twilightBlue"># Input/Output</span><br /> <span class="violet">standard_name:</span> <span class="twilightBlue">net_downward_shortwave_flux_at_sea_water_surface</span><br /> <span class="violet">long_name:</span> <span class="twilightBlue">solar shortwave radiation flux</span><br /> <span class="violet">units:</span> <span class="twilightBlue">watt meter-2 # Input: [Watt/m2]</span><br /> <span class="violet">field:</span> <span class="twilightBlue">shortwave radiation # [Celsius m/s]</span><br /> <span class="violet">time:</span> <span class="twilightBlue">srf_time # Output: [Watt/m2]</span><br /> <span class="violet">index_code:</span> <span class="twilightBlue">idSrad</span><br /> <span class="violet">type:</span> <span class="twilightBlue">r2dvar</span><br /> <span class="violet">add_offset:</span> <span class="twilightBlue">0.0d0</span><br /> <span class="violet">scale:</span> <span class="twilightBlue">1.0d0</span><br /></span></div>

	The field key and value pair in the YAML blocking list is as follows:		The field key and value pair in the YAML blocking list is as follows:
Line 69:		Line 69:
	* <span class="violet">scale</span> is the factor to multiply input data for units conversion purposes.		* <span class="violet">scale</span> is the factor to multiply input data for units conversion purposes.
	<br \>		<br \>
	YAML allows '''alias''' and '''anchor''' to avoid repetition. However, here is used to select the desired option for input '''shortwave radiation''' data. If processing '''daily''' values, the input variable is specified by the anchor <span class="green">&SWRAD</span> and its value <span class="twilightBlue">swrad_daily</span> is used to replace the alias token <span class="~~orange~~">*SWRAD</span>. In this case, the [[DIURNAL_SRFLUX]] option needs to be activated in ROMS to modulate the '''shortwave radiation''' by the local daily cycle at each timestep. Notice, that this strategy is commented by default. In YAML, single or multiple line comments start with a hash <span class="twilightBlue">#</span>. Also, comment after a key/value pair is allowed. All comments are skipped during processing.		YAML allows '''alias''' and '''anchor''' to avoid repetition. However, here is used to select the desired option for input '''shortwave radiation''' data. If processing '''daily''' values, the input variable is specified by the anchor <span class="green">&SWRAD</span> and its value <span class="twilightBlue">swrad_daily</span> is used to replace the alias token <span class="salmon">*SWRAD</span>. In this case, the [[DIURNAL_SRFLUX]] option needs to be activated in ROMS to modulate the '''shortwave radiation''' by the local daily cycle at each timestep. Notice, that this strategy is commented by default. In YAML, single or multiple line comments start with a hash <span class="twilightBlue">#</span>. Also, comment after a key/value pair is allowed. All comments are skipped during processing.

	=== Input Fields Scaling ===		=== Input Fields Scaling ===

Robertson at 16:36, 22 April 2022

2022-04-22T16:36:53Z

← Older revision		Revision as of 16:36, 22 April 2022
Line 186:		Line 186:
	Note that if you specify stresses or heat fluxes with analytical functions, they must be converted to kinematic units within '''analytical.F'''. That is, stresses in '''Pa''' must be divided by '''rho0''', and heat fluxes by '''rho0*cp'''.		Note that if you specify stresses or heat fluxes with analytical functions, they must be converted to kinematic units within '''analytical.F'''. That is, stresses in '''Pa''' must be divided by '''rho0''', and heat fluxes by '''rho0*cp'''.

	=== A nifty varinfo.~~dat~~ trick ===		=== A nifty varinfo.yaml trick ===

	The <span class="violet">variable</span> keyword does not have to be unique. You can direct more than one <span class="violet">index_code</span> identifier to read the data from the same NetCDF variable in the input files. The <span class="violet">scale</span> value allow you to apply different scaling to each.		The <span class="violet">variable</span> keyword does not have to be unique. You can direct more than one <span class="violet">index_code</span> identifier to read the data from the same NetCDF variable in the input files. The <span class="violet">scale</span> value allow you to apply different scaling to each.

Arango at 01:11, 5 March 2022

2022-03-05T01:11:12Z

← Older revision		Revision as of 01:11, 5 March 2022
Line 69:		Line 69:
	* <span class="violet">scale</span> is the factor to multiply input data for units conversion purposes.		* <span class="violet">scale</span> is the factor to multiply input data for units conversion purposes.
	<br \>		<br \>
	YAML allows '''alias''' and '''anchor''' to avoid repetition. However, here is used to select the desired option for input '''shortwave radiation''' data. If processing '''daily''' values, the input variable is specified by the anchor <span class="green">&SWRAD</span> and its value <span class="twilightBlue">swrad_daily</span> is used to replace the alias token <span class="orange">*SWRAD</span>. In this case, the [[DIURNAL_SRFLUX]] option needs to be activated in ROMS to modulate the '''shortwave radiation''' by the local daily cycle at each timestep. Notice, that this strategy is commented by default. In YAML, single or multiple line comments start with a hash #. Also, comment after a key/value pair is allowed. All comments are skipped during processing.		YAML allows '''alias''' and '''anchor''' to avoid repetition. However, here is used to select the desired option for input '''shortwave radiation''' data. If processing '''daily''' values, the input variable is specified by the anchor <span class="green">&SWRAD</span> and its value <span class="twilightBlue">swrad_daily</span> is used to replace the alias token <span class="orange">*SWRAD</span>. In this case, the [[DIURNAL_SRFLUX]] option needs to be activated in ROMS to modulate the '''shortwave radiation''' by the local daily cycle at each timestep. Notice, that this strategy is commented by default. In YAML, single or multiple line comments start with a hash <span class="twilightBlue">#</span>. Also, comment after a key/value pair is allowed. All comments are skipped during processing.

	=== Input Fields Scaling ===		=== Input Fields Scaling ===

Arango: /* Input and output variables */

2022-03-05T01:05:18Z

Input and output variables

← Older revision		Revision as of 01:05, 5 March 2022
Line 162:		Line 162:
	=== Input and output variables ===		=== Input and output variables ===

	Some ~~variables~~ described in varinfo.~~dat~~ are both input and output variables. The model state variables zeta, temp, salt, ~~u, v…etc.~~ are obviously in this category. ~~Certain~~ surface flux variables can be either input forcing data, or output results computed internally.		Some field metadata described in '''varinfo.yaml''' are both input and output variables. The model state variables '''zeta''', '''ubar''', '''vbar''', '''u''', '''v''', '''temp''', '''salt''', and '''passive tracers''' are obviously in this category. Also, certain surface flux variables can be either input forcing data, or output results computed internally.

	~~Example: In~~ some ROMS configurations~~, such as #define~~ BULK_FLUX, surface u-~~stress,~~ sustr~~, is an~~ output ~~having been~~ computed internally. ~~It is~~ written to the output NetCDF file if Hout(idUsms) = T in the roms.in file.		For example, in some ROMS configurations when [[BULK_FLUX]] is activated, surface u-stresses ('''sustr''' and '''svstr''') are output fields computed internally in the surface boundary layer formulation. Such fields are written to the output history NetCDF file if <span class="red">Hout(idUsms) = T</span> and <span class="red">Hout(idVsms) = T</span> in the [[roms.in]] file. Otherwise, in other configurations '''sustr''' and '''svstr''' are input that drives the surface momentum forcing directly.

	~~In other configurations sustr~~ is an input, and ~~drives~~ the ~~surface momentum input directly~~.		The <span class="violet">scale</span> factor is only used on input. It is ignored on output and data are always written in default ROMS internal units with a few exceptions: namely, heat fluxes and surface and bottom stresses. The output <span class="violet">scale</span> factors applied can be seen in the source code (e.g., '''wrt_his.F'''). This re-scaling is made to give geophysically meaningful units of Watt/m2 for heat, and N/m2 (or Pa) for stresses.

	~~The scale factor is only used on input. It is ignored on output. Output data are always written in default ROMS internal units with a few exceptions~~: ~~namely, heat fluxes and surface and bottom stresses. The output scale factors applied can~~ be ~~seen in the source code (e~~.~~g. wrt_his.F). This re-scaling is made to give geophysically meaningful units of Watt/m2~~ for ~~heat, and N~~/~~m2 (or Pa) for stresses~~.		<span class="red">CAUTION:</span> You must be very careful here if you start tinkering with '''varinfo.yaml''' entries for mixed I/O variables.

	~~We will add more documentation on the default~~ internal units~~, and~~ the ~~distinction between input~~ and ~~output varibales, in~~ the ~~next model release~~.		For example, if you intend surface wind stress, '''sustr''' (taux), as input but have a data file in '''dynes/cm2''' (equals to '''0.1''' N/m2 or Pa), you need to convert these to ROMS internal units of kinematic stress '''taux/rho0''' of m2/s2. The <span class="violet">scale</span> factor is '''0.1/1025 = 9.8x10-5''' where the numerator '''0.1''' converts dynes/cm2 to Pa and the reference density of seawater is '''1025''' kg/m3.

	~~CAUTION:~~ You ~~must be very careful here if~~ you ~~start tinkering with varinfo.dat entries for mixed I/O variables~~.		The conversion of momentum stress (in '''Pa''') and heat flux (in '''Watts/m2''') to kinematic units (of '''m2/s2''' and '''degC m/s''', respectively) is why the report of Min/Max values sent to standard output shows different values to those you have in your input NetCDF file. You should always carefully inspect the range of data values read when working with a new model set-up or new forcing netCDF files to ensure that the data you are reading is what you expect.

	~~Example:~~ If you intend ~~surface wind stress tau,~~ sustr~~, as~~ an ~~input but have a data file in dynes/cm2 (= 0.1 N/m2 or Pa),~~ you ~~need to convert these to ROMS internal~~ units of kinematic stress tau/rho0 (like u*2~~) of m2/s2~~. The scale ~~factor~~ is ~~0.1/1025 = 9~~.~~8x10-5 where the numerator 0.1 converts dynes/cm2~~ to ~~Pa and~~ the ~~reference density~~ of ~~seawater is 1025 kg/m3~~.		If you intend '''sustr''' to be an output you should keep the '''units''' string as '''newton meter-2''' because this string will be the '''units attribute''' in the output NetCDF file. The <span class="violet">scale</span> value is irrelevant because it will not be applied on output. You can’t use it to alter the '''units''' of the output.

	~~The conversion of momentum (in Pa)~~ and ~~heat flux~~ (~~in Watts/m2) to kinematic units (of m2/s2 and degC m/s, respectively) is why the report of min/max values sent to stdout shows different values to those~~ you ~~have in your input NetCDF file. You should always carefully inspect the range of data values~~ read ~~when working with~~ a ~~new model set-up or new~~ forcing ~~netCDF files~~ to ~~make sure the data~~ you ~~are reading are what you expect. In~~ the ~~next version of~~ the ~~model will will clarify these procedures by documenting within varinfo.dat~~ the ~~default input and output units, and~~ the ~~internal units~~.		If you specify '''sustr''' as input and output (which you can do: ROMS will read forcing '''sustr''' from a forcing NetCDF file and write '''sustr''' to history, quicksave, averages, and stations.) even if you do a '''scale''' factor conversion you’d better keep the <span class="violet">scale</span> keyword units as '''Newton meter-2''' so that the output files have the correct metadata in the NetCDF attributes.

	~~If you intend sustr~~ to be an ~~output you should keep the units string Vinfo(3) as newton meter-2 because this string will be the units attribute in the output NetCDF file~~. The ~~scale~~ value ~~is irrelevant because it will~~ not ~~be applied on output~~. You ~~can’t use it to alter the~~ units ~~of the output~~.		Surface fluxes of salinity and passive tracers are always written in units of '''tracer_units m/s'''. It is not converted to an equivalent freshwater flux. The variable '''swflux''' is an input variable only. You can do the conversion yourself if you wish using a suitable surface salinity value. We do not do this conversion within ROMS to perform a tracer budget analysis. You would want fluxes in tracer units.

	If you ~~specify sustr as input and output (which~~ you can ~~do: ROMS will read forcing sustr from a forcing NetCDF file and write sustr to history, averages, stations file etc.) even if you do a scale factor conversion you’d better keep~~ the ~~Vinfo~~(3) ~~units as Newton meter-2 so that~~ the output ~~files have the correct metadata in the NetCDF attributes~~.		However, if you are using the [[BULK_FLUXES option]], you can have the computed evaporation rate (in '''kg m/s''') saved to the output file, and perform a freshwater budget calculation accordingly.

	~~Surface fluxes~~ of ~~tracers are always~~ output in units of ~~tracer_units m/s~~. ~~This is true also for~~ the ~~surface salt flux. It is not converted~~ to ~~an equivalent freshwater flux~~. The ~~variable swflux~~ is ~~an input variable only. You can do the conversion yourself~~ if you ~~wish using a suitable surface salinity value. We do not do this conversion within ROMS because in order to perform a tracer budget analysis~~ you would ~~want fluxes~~ in ~~tracer units~~.		We don’t recommend mixing the units of state variables on input and output. A user could give an initial condition file with sea level '''zeta''' in centimeters by setting the scale to '''0.01'''. The output history, averages, restart, and other files will nevertheless be written with '''zeta''' in units of meters. So you would want the <span class="violet">units</span> keyword string to reflect this. The risk here is that if you subsequently restart the model from one of these files, you would need to remember to re-set the scale for '''zeta''' in '''varinfo.yaml'''.

	~~However, if you are using the BULK_FLUXES option, you can have the computed evaporation rate (in kg m/s) saved to the output file, and perform a freshwater budget calculation accordingly.~~		Note that if you specify stresses or heat fluxes with analytical functions, they must be converted to kinematic units within '''analytical.F'''. That is, stresses in '''Pa''' must be divided by '''rho0''', and heat fluxes by '''rho0*cp'''.

	We don’t recommend mixing the units of state variables on input and output. A user could give an initial condition file with sea level zeta in centimeters by setting the scale to 0.01. The output history, averages, restart etc. files will nevertheless be written with zeta in units of meters. So you would want the Vinfo(3) string to reflect this. The risk here is that if you subsequently restart the model from one of these files, you would need to remember to re-set the scale for zeta in varinfo.dat.

	Note ~~also~~ that in if you specify stresses or heat fluxes ~~through~~ analytical~~.F that~~ they must be converted to kinematic units within
	analytical.F, ~~i.e. stress~~ in Pa must be divided by rho0, and heat fluxes by rho0*cp.

	=== A nifty varinfo.dat trick ===		=== A nifty varinfo.dat trick ===

Arango at 23:14, 4 March 2022

2022-03-04T23:14:42Z

← Older revision		Revision as of 23:14, 4 March 2022
Line 13:		Line 13:
	* <span class="violet">standard_name:</span> is the variable '''standard_name''' NetCDF attribute, which follows CF conventions. A list of all '''standard_name''' attribute are shown below.		* <span class="violet">standard_name:</span> is the variable '''standard_name''' NetCDF attribute, which follows CF conventions. A list of all '''standard_name''' attribute are shown below.
	* <span class="violet">long_name:</span> is the variable '''long_name''' NetCDF attribute.		* <span class="violet">long_name:</span> is the variable '''long_name''' NetCDF attribute.
	* <span class="violet">units:</span> is the variable '''units''' NetCDF attribute. It is a tricky key/value pair in ROMS. In output NetCDF files, it describes the units of output attribute and data. For variables that are used on input only, such as meteorological data, we have assumed a convention that its value describes the units that you have in your NetCDF file. It does not strictly describe the units ROMS assumes internally (though this is generally true if the scale factor is '''1.0d0'''). The '''scale''' can be used to make ROMS modify the data during input to be consistent with ROMS internal units without the need to re-create a new forcing file with adjusted units.		* <span class="violet">units:</span> is the variable '''units''' NetCDF attribute. It is a tricky key/value pair in ROMS. In output NetCDF files, it describes the units of output attribute and data.
	* <span class="violet">field:</span> is the variable '''field''' NetCDF attribute. It is a user-customizable attribute that can be used to create labels during post-processing for plotting, visualization, and so on. It can be in any language represented by the 255 ASCII sets of characters, letters, symbols, and signs).		* <span class="violet">field:</span> is the variable '''field''' NetCDF attribute. It is a user-customizable attribute that can be used to create labels during post-processing for plotting, visualization, and so on. It can be in any language represented by the 255 ASCII sets of characters, letters, symbols, and signs).
	* <span class="violet">time:</span> is the variable associated '''time''' NetCDF attribute, if record dependency. If your NetCDF file uses a different name from the default you don’t need to rename it in the NetCDF file, you can modify '''varinfo.yaml'''. However, it is not necessary nowadays because ROMS '''inquiry.F''' module search for the variable '''time''' attribute internally, and use that '''time''' variable during the processing. In such case, the value in varinfo.yaml is ignored and overwritten.		* <span class="violet">time:</span> is the variable associated '''time''' NetCDF attribute, if record dependency. If your NetCDF file uses a different name from the default you don’t need to rename it in the NetCDF file, you can modify '''varinfo.yaml'''. However, it is not necessary nowadays because ROMS '''inquiry.F''' module search for the variable '''time''' attribute internally, and use that '''time''' variable during the processing. In such case, the value in varinfo.yaml is ignored and overwritten.
Line 67:		Line 67:

	* <span class="violet">add_offset</span> is the value to be added to input NetCDF data. Currently, not used.		* <span class="violet">add_offset</span> is the value to be added to input NetCDF data. Currently, not used.
	* <span class="violet">scale</span> is the factor to multiply input data for units conversion purposes. For example, ROMS assumes surface air pressure is given in millibars. The COARE bulk formulae in '''bulk_flux.F''' demand this. If your input file is in Pascals you can convert these using the scale entry. You would set its to 0.01d0 because 1 Pascal = 0.01 millibar. In general, the rule is:		* <span class="violet">scale</span> is the factor to multiply input data for units conversion purposes.
	~~<br \>~~
	~~:<span class="twilightBlue">ROMS_internal_units</span> = (your_units) x (<span class="violet">scale</span>) + <span class="violet">add_offset</span>~~
	~~<br \>~~
	:If you change the '''scale''' factor in your '''varinfo.yaml''', We recommend you change the '''units''' string to be consistent with your data file, and insert a comment to remind yourself what you’ve done in using a new '''scale''' factor. You can append a comment using a hash <span class="twilightBlue">#</span> after any entry in '''varinfo.yaml'''.
	<br \>		<br \>
	YAML allows '''alias''' and '''anchor''' to avoid repetition. However, here is used to select the desired option for input '''shortwave radiation''' data. If processing '''daily''' values, the input variable is specified by the anchor <span class="green">&SWRAD</span> and its value <span class="twilightBlue">swrad_daily</span> is used to replace the alias token <span class="orange">*SWRAD</span>. In this case, the [[DIURNAL_SRFLUX]] option needs to be activated in ROMS to modulate the '''shortwave radiation''' by the local daily cycle at each timestep. Notice, that this strategy is commented by default. In YAML, single or multiple line comments start with a hash #. Also, comment after a key/value pair is allowed. All comments are skipped during processing.		YAML allows '''alias''' and '''anchor''' to avoid repetition. However, here is used to select the desired option for input '''shortwave radiation''' data. If processing '''daily''' values, the input variable is specified by the anchor <span class="green">&SWRAD</span> and its value <span class="twilightBlue">swrad_daily</span> is used to replace the alias token <span class="orange">*SWRAD</span>. In this case, the [[DIURNAL_SRFLUX]] option needs to be activated in ROMS to modulate the '''shortwave radiation''' by the local daily cycle at each timestep. Notice, that this strategy is commented by default. In YAML, single or multiple line comments start with a hash #. Also, comment after a key/value pair is allowed. All comments are skipped during processing.
Line 77:		Line 73:
	=== Input Fields Scaling ===		=== Input Fields Scaling ===

	For variables that are used on input only, such as meteorological data, we have assumed a convention that the <span class="violet">units</span> keyword describe the units that you have in your NetCDF file. It does not strictly describe the units ROMS assumes internally (though this is generally true if the <span class="violet">scale</span> factor is 1.0d0). The <span class="violet">scale</span> value can be used to make ROMS modify the data during input to be consistent with ROMS internal units without the need to re-create a new forcing file with adjusted units.		For variables that are used on input only, such as meteorological data, we have assumed a convention that the <span class="violet">units</span> keyword describe the units that you have in your NetCDF file. It does not strictly describe the units ROMS assumes internally (though this is generally true if the <span class="violet">scale</span> factor is '''1.0d0'''). The <span class="violet">scale</span> value can be used to make ROMS modify the data during input to be consistent with ROMS internal units without the need to re-create a new forcing file with adjusted units.

	For example, ROMS assumes ~~'''~~surface air pressure~~'''~~ is given in ~~'''~~millibars~~'''~~. The COARE bulk formulae in ~~subroutine~~ bulk_flux demand this. If your input file is in Pascals you can convert these using the ~~<span class="violet">~~scale~~</span>~~ entry. ~~In this case, the scale value should be~~ '''0.01d0''' because '''1 Pascal = 0.01 millibar'''. ~~Note that~~ the rule is		For example, ROMS assumes surface air pressure is given in millibars. The COARE bulk formulae in '''bulk_flux.F''' demand this. If your input file is in Pascals you can convert these using the scale entry. You would set its to '''0.01d0''' because '''1 Pascal = 0.01 millibar'''. In general, the rule is:

	<span class="twilightBlue">ROMS_internal_units</span> = (your_units) x (scale)		:<span class="twilightBlue">ROMS_internal_units</span> = (your_units) x (<span class="violet">scale</span>) + <span class="violet">add_offset</span>

	~~Hint: if you google search the string ''convert pascal to millibar'' you’ll get the necessary scale factor without overly taxing your brain.~~

	If you change the <span class="violet">scale</span> factor in your varinfo.y recommend you change the units string ~~in Vinfo(2)~~ to be consistent with your data file, and insert a comment to remind yourself what you’ve done in using a new scale factor. You can append a comment using a ! after ~~anyentry~~ in varinfo.~~dat~~.		If you change the <span class="violet">scale</span> factor in your '''varinfo.yaml''', We recommend you change the '''units''' string to be consistent with your data file, and insert a comment to remind yourself what you’ve done in using a new <span class="violet">scale</span> factor. You can append a comment using a hash <span class="twilightBlue">#</span> after any entry in '''varinfo.yaml'''.

	Here is a table of common conversions that might be required:		Here is a table of common conversions that might be required:
			<br /><br />

	{\| border="1" cellspacing="0" cellpadding="5" align="left"		{\| border="1" cellspacing="0" cellpadding="5" align="left"
Line 163:		Line 158:
	\|}		\|}
	<div style="clear: both"></div>		<div style="clear: both"></div>
			<br /><br />

	=== Input and output variables ===		=== Input and output variables ===

Arango: /* Vinfo() entries */

2022-03-04T23:01:39Z

Vinfo() entries

← Older revision		Revision as of 23:01, 4 March 2022
Line 75:		Line 75:
	YAML allows '''alias''' and '''anchor''' to avoid repetition. However, here is used to select the desired option for input '''shortwave radiation''' data. If processing '''daily''' values, the input variable is specified by the anchor <span class="green">&SWRAD</span> and its value <span class="twilightBlue">swrad_daily</span> is used to replace the alias token <span class="orange">*SWRAD</span>. In this case, the [[DIURNAL_SRFLUX]] option needs to be activated in ROMS to modulate the '''shortwave radiation''' by the local daily cycle at each timestep. Notice, that this strategy is commented by default. In YAML, single or multiple line comments start with a hash #. Also, comment after a key/value pair is allowed. All comments are skipped during processing.		YAML allows '''alias''' and '''anchor''' to avoid repetition. However, here is used to select the desired option for input '''shortwave radiation''' data. If processing '''daily''' values, the input variable is specified by the anchor <span class="green">&SWRAD</span> and its value <span class="twilightBlue">swrad_daily</span> is used to replace the alias token <span class="orange">*SWRAD</span>. In this case, the [[DIURNAL_SRFLUX]] option needs to be activated in ROMS to modulate the '''shortwave radiation''' by the local daily cycle at each timestep. Notice, that this strategy is commented by default. In YAML, single or multiple line comments start with a hash #. Also, comment after a key/value pair is allowed. All comments are skipped during processing.

	=== ~~Vinfo() entries~~ ===		=== Input Fields Scaling ===

	~~Vinfo~~(1): The ~~principal role of varinfo.dat is~~ to make the ~~connection between the unique index variable name that~~ ROMS ~~uses (Vinfo(6)) and~~ the ~~name of the corresponding variable in the NetCDF~~ file ~~(Vinfo(1))~~.		For variables that are used on input only, such as meteorological data, we have assumed a convention that the <span class="violet">units</span> keyword describe the units that you have in your NetCDF file. It does not strictly describe the units ROMS assumes internally (though this is generally true if the <span class="violet">scale</span> factor is 1.0d0). The <span class="violet">scale</span> value can be used to make ROMS modify the data during input to be consistent with ROMS internal units without the need to re-create a new forcing file with adjusted units.

	~~Example: The default varinfo.dat uses the name swrad for the solar shortwave radiation flux in the forcing NetCDF file. If you have a forcing NetCDF file that uses a different name~~, ~~say shortwave, you don’t need to rename the variable in the forcing file. Just change the Vinfo(1) entry in varinfo.dat to shortwave, and~~ ROMS ~~will find it.~~		For example, ROMS assumes '''surface air pressure''' is given in '''millibars'''. The COARE bulk formulae in subroutine bulk_flux demand this. If your input file is in Pascals you can convert these using the <span class="violet">scale</span> entry. In this case, the scale value should be '''0.01d0''' because '''1 Pascal = 0.01 millibar'''. Note that the rule is

	~~Vinfo(6): . This is the name by which variables are referred to internally in ROMS.~~

	~~Vinfo(5): This is the time variable name associated with the data. If your NetCDF file uses a different name from the default you don’t need to rename it in the NetCDF file, just in varinfo.dat.~~

	~~Example: If your file of shortwave radiation data is a time series defined at times given by variable shortwave_time then change the Vinfo(5) entry to this from the default srf_time.~~

	~~Note: If the data in your NetCDF file has an attribute of time the entry in Vinfo(5) is ignored, and the time variable indicated in the NetCDF is used instead.~~

	~~Vinfo(3) and scale: This is possibly the trickiest part of varinfo.dat and a place where~~ '''~~one can easily make an error~~'''.

	~~Note: For output only variables, the Vinfo(3) units string is used on output to describe the data in an output NetCDF file units attribute.~~

	For variables that are used on input only, such as meteorological data, we have assumed a convention that Vinfo(3) describes the units that you have in your NetCDF file. It does not strictly describe the units ROMS assumes internally (though this is generally true if the scale factor is 1). The scale can be used to make ROMS modify the data during input to be consistent with ROMS internal units without the need to re-create a new forcing file with adjusted units.

	~~Example: ROMS assumes surface air pressure~~ is given in millibars. The COARE bulk formulae in subroutine bulk_flux demand this. If your input file is in Pascals you can convert these using the scale entry. ~~You would change~~ scale ~~from its default of 1.0d0 to~~ 0.01d0 because 1 Pascal = 0.01 millibar. Note that the rule is

	<span class="twilightBlue">ROMS_internal_units</span> = (your_units) x (scale)		<span class="twilightBlue">ROMS_internal_units</span> = (your_units) x (scale)
Line 101:		Line 85:
	Hint: if you google search the string ''convert pascal to millibar'' you’ll get the necessary scale factor without overly taxing your brain.		Hint: if you google search the string ''convert pascal to millibar'' you’ll get the necessary scale factor without overly taxing your brain.

	If you change the scale factor in your varinfo.~~dat, I~~ recommend you change the units string in Vinfo(2) to be consistent with your data file, and insert a comment to remind yourself what you’ve done in using a new scale factor. You can append a comment using a ! after anyentry in varinfo.dat.		If you change the <span class="violet">scale</span> factor in your varinfo.y recommend you change the units string in Vinfo(2) to be consistent with your data file, and insert a comment to remind yourself what you’ve done in using a new scale factor. You can append a comment using a ! after anyentry in varinfo.dat.

	Here is a table of common conversions that might be required:		Here is a table of common conversions that might be required:

Arango: /* A nifty varinfo.dat trick */

2022-03-04T22:47:58Z

A nifty varinfo.dat trick

← Older revision		Revision as of 22:47, 4 March 2022
Line 213:		Line 213:
	=== A nifty varinfo.dat trick ===		=== A nifty varinfo.dat trick ===

	~~Vinfo(1)~~ does not have to be unique. You can direct more than one ~~variable index name (Vinfo(6))~~ to read the data from the same NetCDF variable in the input files. The scale ~~entry let’s~~ you apply different scaling to each.		The <span class="violet">variable</span> keyword does not have to be unique. You can direct more than one <span class="violet">index_code</span> identifier to read the data from the same NetCDF variable in the input files. The <span class="violet">scale</span> value allow you to apply different scaling to each.

	~~Example: Suppose~~ you wish to specify a constant value for the open boundary values for biological tracers. Rather than make a NetCDF file with data for all of NO3_west, NH4_west, phyt_west etc you could make a NetCDF file with a single variable named, say ~~ones_west~~, which is filled with nothing but 1.0 for all time~~, s_rho and eta_rho~~.		For example, suppose you wish to specify a constant value for the open boundary values for biological tracers. Rather than make a NetCDF file with data for all of <span class="twilightBlue">NO3_west</span>, <span class="twilightBlue">NH4_west</span>, <span class="twilightBlue">phyt_west</span>, and etc, you could make a NetCDF file with a single variable named, say <span class="twilightBlue">ONES_west</span>, which is filled with nothing but '''1.0''' for all time coordinate values.

	In varinfo.~~dat~~, there must still be one entry for each unique ~~index~~ but you can have each entry point to the same ONES_west data. Assign the value you want for each variable in the scale entry. This scale will be multiplied by the 1.0 on input to set the open boundary values.		In '''varinfo.yaml''', there must still be one entry for each unique <span class="violet">index_code</span> but you can have each entry point to the same <span class="twilightBlue">ONES_west</span> data. Assign the value you want for each variable in the scale entry. This scale will be multiplied by the 1.0 on input to set the open boundary values.

	<div class="box"> - <span class="violet">variable:</span> <span class="twilightBlue">ONES_west # Input</span><br /> <span class="violet">standard_name:</span> <span class="twilightBlue">mole_concentration_of_ammonium_expressed_as_nitrogen_in_sea_water</span><br /> <span class="violet">long_name:</span> <span class="twilightBlue">ammonium western boundary condition</span><br /> <span class="violet">units:</span> <span class="twilightBlue">millimole_nitrogen meter-3 # [millimole/m3]</span><br /> <span class="violet">field:</span> <span class="twilightBlue">NH4 western-boundary</span><br /> <span class="violet">time:</span> <span class="twilightBlue">NH4_time</span><br /> <span class="violet">index_code:</span> <span class="twilightBlue">idTbry(iwest,iNH4_)</span><br /> <span class="violet">type:</span> <span class="twilightBlue">nulvar</span><br /> <span class="violet">add_offset:</span> <span class="twilightBlue">0.0d0</span><br /> <span class="violet">scale:</span> <span class="twilightBlue">0.1d0 # make all values equal to 0.1 millimole meter-3</span><br /><br /> - <span class="violet">variable:</span> <span class="twilightBlue">ONES_west # Input</span><br /> <span class="violet">standard_name:</span> <span class="twilightBlue">mole_concentration_of_phytoplankton_expressed_as_nitrogen_in_sea_water</span><br /> <span class="violet">long_name:</span> <span class="twilightBlue">phytoplankton western boundary condition</span><br /> <span class="violet">units:</span> <span class="twilightBlue">millimole_nitrogen meter-3 # [millimole/m3]</span><br /> <span class="violet">field:</span> <span class="twilightBlue">phytoplankton western-boundary</span><br /> <span class="violet">time:</span> <span class="twilightBlue">phyt_time</span><br /> <span class="violet">index_code:</span> <span class="twilightBlue">idTbry(iwest,iPhyt)</span><br /> <span class="violet">type:</span> <span class="twilightBlue">nulvar</span><br /> <span class="violet">add_offset:</span> <span class="twilightBlue">0.0d0</span><br /> <span class="violet">scale:</span> <span class="twilightBlue">0.08d0 # make all values equal to 0.08 millimole meter-3</span><br /></div>		<div class="box"> - <span class="violet">variable:</span> <span class="twilightBlue">ONES_west # Input</span><br /> <span class="violet">standard_name:</span> <span class="twilightBlue">mole_concentration_of_ammonium_expressed_as_nitrogen_in_sea_water</span><br /> <span class="violet">long_name:</span> <span class="twilightBlue">ammonium western boundary condition</span><br /> <span class="violet">units:</span> <span class="twilightBlue">millimole_nitrogen meter-3 # [millimole/m3]</span><br /> <span class="violet">field:</span> <span class="twilightBlue">NH4 western-boundary</span><br /> <span class="violet">time:</span> <span class="twilightBlue">NH4_time</span><br /> <span class="violet">index_code:</span> <span class="twilightBlue">idTbry(iwest,iNH4_)</span><br /> <span class="violet">type:</span> <span class="twilightBlue">nulvar</span><br /> <span class="violet">add_offset:</span> <span class="twilightBlue">0.0d0</span><br /> <span class="violet">scale:</span> <span class="twilightBlue">0.1d0 # make all values equal to 0.1 millimole meter-3</span><br /><br /> - <span class="violet">variable:</span> <span class="twilightBlue">ONES_west # Input</span><br /> <span class="violet">standard_name:</span> <span class="twilightBlue">mole_concentration_of_phytoplankton_expressed_as_nitrogen_in_sea_water</span><br /> <span class="violet">long_name:</span> <span class="twilightBlue">phytoplankton western boundary condition</span><br /> <span class="violet">units:</span> <span class="twilightBlue">millimole_nitrogen meter-3 # [millimole/m3]</span><br /> <span class="violet">field:</span> <span class="twilightBlue">phytoplankton western-boundary</span><br /> <span class="violet">time:</span> <span class="twilightBlue">phyt_time</span><br /> <span class="violet">index_code:</span> <span class="twilightBlue">idTbry(iwest,iPhyt)</span><br /> <span class="violet">type:</span> <span class="twilightBlue">nulvar</span><br /> <span class="violet">add_offset:</span> <span class="twilightBlue">0.0d0</span><br /> <span class="violet">scale:</span> <span class="twilightBlue">0.08d0 # make all values equal to 0.08 millimole meter-3</span><br /></div>



	~~'ONES_west'~~
	~~'ammonium western boundary condition'~~
	~~'millimole_nitrogen meter-3'~~
	~~'NH4_east, scalar, series'~~
	~~'NH4_time'~~
	~~'idTbry(iwest,iNH4_)'~~
	~~'nulvar'~~
	~~0.1d0 ! make all values equal to 0.1 millimole meter-3~~
	!
	~~'ONES_west'~~
	~~'phytoplankton western boundary condition'~~
	~~'millimole_nitrogen meter-3'~~
	~~'phyt_west, scalar, series'~~
	~~'phyt_time'~~
	~~'idTbry(iwest,iPhyt)'~~
	~~'nulvar'~~
	~~0.08d0 ! make all values equal to 0.08 millimole meter-3~~

	=== Metadata: standard_name ===		=== Metadata: standard_name ===