Dynamic water level correction - Revision history

Taylorgasher: Added note about file being read from the start of the run

2023-10-29T19:22:46Z

Added note about file being read from the start of the run

← Older revision		Revision as of 15:22, 29 October 2023
Line 17:		Line 17:

	===Water Level Correction Input File===		===Water Level Correction Input File===
	ADCIRC looks for the water level correction input file in the same directory as the other full-domain files, both in serial and in parallel. In parallel, each subdomain does domain decomposition of the correction data on the fly, so the only change to adcprep is the read/write of the new namelist to the subdomain fort.15 files. The water level correction input file starts with the following three header lines:		ADCIRC will begin reading this input file when the run starts, so time snaps are needed from the start of the run. ADCIRC looks for the water level correction input file in the same directory as the other full-domain files, both in serial and in parallel. In parallel, each subdomain does domain decomposition of the correction data on the fly, so the only change to adcprep is the read/write of the new namelist to the subdomain fort.15 files. The water level correction input file starts with the following three header lines:

	<nowiki>#</nowiki> test file for 1ft correction on hsofs mesh during matthew		<nowiki>#</nowiki> test file for 1ft correction on hsofs mesh during matthew

Taylorgasher: /* Water Level Correction Input File */ tweak

2022-08-23T14:48:57Z

Water Level Correction Input File: tweak

← Older revision		Revision as of 10:48, 23 August 2022
Line 17:		Line 17:

	===Water Level Correction Input File===		===Water Level Correction Input File===
	ADCIRC looks for the water level correction input file in the same directory as the other full-domain files, both in serial and in parallel. In parallel, each subdomain does domain decomposition of the correction data on the fly, so the only change to adcprep is the read/write of the new namelist to the subdomain fort.15 files. The water level correction input file starts with the following three lines:		ADCIRC looks for the water level correction input file in the same directory as the other full-domain files, both in serial and in parallel. In parallel, each subdomain does domain decomposition of the correction data on the fly, so the only change to adcprep is the read/write of the new namelist to the subdomain fort.15 files. The water level correction input file starts with the following three header lines:

	<nowiki>#</nowiki> test file for 1ft correction on hsofs mesh during matthew		<nowiki>#</nowiki> test file for 1ft correction on hsofs mesh during matthew
	14400.0 # time increment between datasets -- read but ignored if constant correction		14400.0 # time increment between datasets, must be positive -- read but ignored if constant correction
	0.0 # default correction value		0.0 # default correction value

	The first line is a comment line. The second line is the time interval in seconds between successive datasets. The third line is the default correction value; this allows us to create correction input files in a "sparse" format where only the non-default values are provided.If there is only one dataset in the correction file, then the values are treated as temporally constant. If there is more than one dataset, ADCIRC linearly interpolates between them in time. If ADCIRC runs out of correction data, it continues with the last dataset as a set of constant values for the remainder of the run.		The first line is a comment line. The second line is the time interval in seconds between successive datasets. The third line is the default correction value; this allows us to create correction input files in a "sparse" format where only the non-default values are provided.If there is only one dataset in the correction file, then the values are treated as temporally constant. If there is more than one dataset, ADCIRC linearly interpolates between them in time. If ADCIRC runs out of correction data, it continues with the last dataset as a set of constant values for the remainder of the run.

	Because each correction dataset may have a different number of values, the # (hash, pound, or number) symbol is used as a separator. Specifically, users should place a line containing # in the first and second columns, i.e. ##, of the file after the end of the current time snap of data. When ADCIRC sees this, it understands the next line is the start of the next time snap of data.		Because each correction dataset may have a different number of values, the # (hash, pound, or number) symbol is used as a separator. Specifically, users should place a line containing # in the first and second columns, i.e. <code>##</code>, of the file after the end of the current time snap of data. When ADCIRC sees this, it understands the next line is the start of the next time snap of data.

	===Output===		===Output===

Taylorgasher: tweaked refs

2020-06-17T13:57:29Z

tweaked refs

← Older revision		Revision as of 09:57, 17 June 2020
Line 5:		Line 5:
	== Version ==		== Version ==
	{{ADC version\|version=54\|relation=ge}}		{{ADC version\|version=54\|relation=ge}}
	Early versions of this feature were implemented in v53, however important bug fixes and a renaming of related variables<ref>If using an older version, note that in the fort.15 file, instances of "dynamicWaterLevelCorrection" should be changed to "offset" in the namelist parameter names, e.g. "offsetControl". </ref> were done later, so users are strongly encouraged to not use these earlier versions.		Early versions of this feature were implemented in v53, however important bug fixes and a renaming of related variables<ref group="note">If using an older version, note that in the fort.15 file, instances of "dynamicWaterLevelCorrection" should be changed to "offset" in the namelist parameter names, e.g. "offsetControl". </ref> were done later, so users are strongly encouraged to not use these earlier versions.

	==Controlling Water Level Correction==		==Controlling Water Level Correction==
Line 81:		Line 81:
	'''Question: '''Does the application of a dynamic water level correction surface affect the velocity solution (not just the elevation solution as it is primarily intended)? <br/>		'''Question: '''Does the application of a dynamic water level correction surface affect the velocity solution (not just the elevation solution as it is primarily intended)? <br/>
	'''Answer: '''Yes, hopefully in a physically realistic manner. As an example, when applying a water level correction to a back bay area with a nearby tidal inlet, the water level change in the back bay must be reflected in the velocity in the inlet in order to maintain continuity (conservation of mass). In the case of an initial application of a temporally steady water level correction, this velocity effect should be a one-time occurrence. On the other hand, for a time varying water level correction surface, the continuous adjustments to the water level will be continuously reflected in the velocity solution. This should be physically realistic when the water ''should have'' come from offshore, but if the elevated water level is due to rainfall, then the model is directing flow in the wrong direction. Further details are in Asher et al. 2019<ref name="asher2019"></ref>.		'''Answer: '''Yes, hopefully in a physically realistic manner. As an example, when applying a water level correction to a back bay area with a nearby tidal inlet, the water level change in the back bay must be reflected in the velocity in the inlet in order to maintain continuity (conservation of mass). In the case of an initial application of a temporally steady water level correction, this velocity effect should be a one-time occurrence. On the other hand, for a time varying water level correction surface, the continuous adjustments to the water level will be continuously reflected in the velocity solution. This should be physically realistic when the water ''should have'' come from offshore, but if the elevated water level is due to rainfall, then the model is directing flow in the wrong direction. Further details are in Asher et al. 2019<ref name="asher2019"></ref>.

			==Notes==
			<references group="note"/>

	==References==		==References==
	<references />		<references />

Taylorgasher: fixed ref bug

2020-06-17T13:31:49Z

fixed ref bug

← Older revision		Revision as of 09:31, 17 June 2020
Line 74:		Line 74:
	==Frequently Asked Questions==		==Frequently Asked Questions==
	'''Question: '''When writing the &dynamicWaterLevelCorrectionControl namelist, should I write the parameters on a single line, comma separated?<br/>		'''Question: '''When writing the &dynamicWaterLevelCorrectionControl namelist, should I write the parameters on a single line, comma separated?<br/>
	'''Answer: '''I always put fortran namelist parameters on a single line and separate the assignments with commas, but other formatting may be possible depending on the compiler you are using. ~~I've never had issues with the way I format these fortran namelist input lines~~, but I've ~~never~~ tried any other way ~~so I'll defer to your compiler's documentation on that~~.		'''Answer: '''I always put fortran namelist parameters on a single line and separate the assignments with commas, but other formatting may be possible depending on the compiler you are using. Commas has always worked for me, but I've not tried any other way.

	'''Question: '''Do I need to ramp the correction, i.e., is it wise to do so for some reason? <br/>		'''Question: '''Do I need to ramp the correction, i.e., is it wise to do so for some reason? <br/>
	'''Answer: '''It should behave the same as a sudden application of atmospheric pressure forcing, which could lead to (presumably spurious) waves. Our shortest ramp up period is 12 hours but you might get away with 6 hours or even less. We have seen that rapidly ramping in the correction can lead to two outcomes that may be undesirable. One is a strong geostrophic current response. The other is that the water level response can lag behind the correction. This is most common for large water bodies with narrow connections to the open ocean, such as Pamlico Sound in North Carolina. Further details are in Asher et al. 2019<ref name="asher2019">.		'''Answer: '''It should behave the same as a sudden application of atmospheric pressure forcing, which could lead to (presumably spurious) waves. Our shortest ramp up period is 12 hours but you might get away with 6 hours or even less. We have seen that rapidly ramping in the correction can lead to two outcomes that may be undesirable. One is a strong geostrophic current response. The other is that the water level response can lag behind the correction. This is most common for large water bodies with narrow connections to the open ocean, such as Pamlico Sound in North Carolina. Further details are in Asher et al. 2019<ref name="asher2019"></ref>.

	'''Question: '''Does the application of a dynamic water level correction surface affect the velocity solution (not just the elevation solution as it is primarily intended)? <br/>		'''Question: '''Does the application of a dynamic water level correction surface affect the velocity solution (not just the elevation solution as it is primarily intended)? <br/>
	'''Answer: '''Yes, hopefully in a physically realistic manner. As an example, when applying a water level correction to a back bay area with a nearby tidal inlet, the water level change in the back bay must be reflected in the velocity in the inlet in order to maintain continuity (conservation of mass). In the case of an initial application of a temporally steady water level correction, this velocity effect should be a one-time occurrence. On the other hand, for a time varying water level correction surface, the continuous adjustments to the water level will be continuously reflected in the velocity solution. This should be physically realistic when the water ''should have'' come from offshore, but if the elevated water level is due to rainfall, then the model is directing flow in the wrong direction. Further details are in Asher et al. 2019<ref name="asher2019">.		'''Answer: '''Yes, hopefully in a physically realistic manner. As an example, when applying a water level correction to a back bay area with a nearby tidal inlet, the water level change in the back bay must be reflected in the velocity in the inlet in order to maintain continuity (conservation of mass). In the case of an initial application of a temporally steady water level correction, this velocity effect should be a one-time occurrence. On the other hand, for a time varying water level correction surface, the continuous adjustments to the water level will be continuously reflected in the velocity solution. This should be physically realistic when the water ''should have'' come from offshore, but if the elevated water level is due to rainfall, then the model is directing flow in the wrong direction. Further details are in Asher et al. 2019<ref name="asher2019"></ref>.

	==References==		==References==
	<references />		<references />

Taylorgasher: buncha updates, think I'm done, article is in good shape now.

2020-06-16T20:40:07Z

buncha updates, think I'm done, article is in good shape now.

Show changes

Taylorgasher: several updates, am not done

2020-06-16T19:25:29Z

several updates, am not done

← Older revision		Revision as of 15:25, 16 June 2020
Line 1:		Line 1:
			'''Dynamic Water Level Correction''' is a process by which modeled water levels are dynamically adjusted by use of a forcing term. The correction can be applied as constant or varying in space and/or time.


	Improvements in forecasting and hindcasting of tropical cyclones have led to much more accurate meteorological data associated with these storms. These improvements, together with more detailed representations of the physics and greater model resolution, have improved storm surge model skill. This has led to a state in which storm surge forecast and hindcast errors are often dominated by what we refer to as unresolved drivers, i.e., physical processes that are not explicitly included in storm surge models. Common examples include baroclinic processes, major oceanic currents, precipitation, steric fluctuations and far-field atmospheric forcing. These phenomena typically have longer timescales than the storm surge itself and therefore often show up as biases in water level during the period leading up to, encompassing and following the surge event. [From T.G.Asher]		Improvements in forecasting and hindcasting of tropical cyclones have led to much more accurate meteorological data associated with these storms. These improvements, together with more detailed representations of the physics and greater model resolution, have improved storm surge model skill. This has led to a state in which storm surge forecast and hindcast errors are often dominated by what we refer to as unresolved drivers, i.e., physical processes that are not explicitly included in storm surge models. Common examples include baroclinic processes, major oceanic currents, precipitation, steric fluctuations and far-field atmospheric forcing. These phenomena typically have longer timescales than the storm surge itself and therefore often show up as biases in water level during the period leading up to, encompassing and following the surge event. [From T.G.Asher]

Line 13:		Line 16:

	In order to accommodate these unresolved drivers, a water level correction ingestion feature has been added to ADCIRC.		In order to accommodate these unresolved drivers, a water level correction ingestion feature has been added to ADCIRC.

			== Version ==
			{{ADC version\|version=54\|relation=ge}}
			Early versions of this feature were implemented in v53, however important bug fixes and a renaming of related variables were done later, so users are strongly encouraged to not use these earlier versions. If using an older version, note that in the fort.15 file, instances of "dynamicWaterLevelCorrection" should be changed to "offset" in the namelist parameter names, e.g. "offsetControl".

	==Controlling Water Level Correction==		==Controlling Water Level Correction==
	The water level correction feature is triggered by the presence of the &~~dynamicWaterlevelCorrectionControl~~ namelist at the bottom of the [[fort.15 file]]. Here is an example of how this line is used:<br/>		The water level correction feature is triggered by the presence of the &dynamicWaterLevelCorrectionControl namelist at the bottom of the [[fort.15 file]]. Here is an example of how this line is used:<br/>
	<code>&~~dynamicWaterlevelCorrectionControl dynamicWaterlevelCorrectionFileName~~="hsofs_offset_test_ft.dat" ~~dynamicWaterlevelCorrectionMultiplier~~=0.3048, ~~dynamicWaterlevelCorrectionRampStart~~=0.0, ~~dynamicWaterlevelCorrectionRampEnd~~=259200.0 ~~dynamicWaterlevelCorrectionRampReferenceTime~~="hotstart", ~~dynamicWaterlevelCorrectionSkipSnaps~~=0 /</code>		<code>&dynamicWaterLevelCorrectionControl dynamicWaterLevelCorrectionFileName="hsofs_offset_test_ft.dat" dynamicWaterLevelCorrectionMultiplier=0.3048, dynamicWaterLevelCorrectionRampStart=0.0, dynamicWaterLevelCorrectionRampEnd=259200.0 dynamicWaterLevelCorrectionRampReferenceTime="hotstart", dynamicWaterLevelCorrectionSkipSnaps=0 /</code>

	The code looks for the water level correction input file in the same directory as the other fulldomain files, both in serial and in parallel. In parallel, each subdomain does domain decomposition of the correction data on the fly, so the only change to adcprep is the read/write of the new namelist to the subdomain fort.15 files.		The code looks for the water level correction input file in the same directory as the other fulldomain files, both in serial and in parallel. In parallel, each subdomain does domain decomposition of the correction data on the fly, so the only change to adcprep is the read/write of the new namelist to the subdomain fort.15 files.
Line 22:		Line 29:
	The multiplier value allows us to easily change the entire dataset by single factor. It may be needed in a case where the data were provided in ft but adcirc requires meters, for example.		The multiplier value allows us to easily change the entire dataset by single factor. It may be needed in a case where the data were provided in ft but adcirc requires meters, for example.

	The ~~dynamicWaterlevelCorrectionRampStart~~ and ~~dynamicWaterlevelCorrectionRampEnd~~ parameter are the time in seconds for a linear ramp up period. The ~~dynamicWaterlevelCorrectionRampReferenceTime~~ parameter controls whether the ramp times are relative to the hotstart time or the coldstart time. Prior to the start of the ramp, the correction values are multiplied by 0.0, eliminating the correction until the ramp period starts.		The dynamicWaterLevelCorrectionRampStart and dynamicWaterLevelCorrectionRampEnd parameter are the time in seconds for a linear ramp up period. The dynamicWaterLevelCorrectionRampReferenceTime parameter controls whether the ramp times are relative to the hotstart time or the coldstart time. Prior to the start of the ramp, the correction values are multiplied by 0.0, eliminating the correction until the ramp period starts.

	The input parameter ~~dynamicWaterlevelCorrectionSkipSnaps~~ is used to skip the specified number of initial data sets in the corrections data file. It can also be used to insert blank snaps at the beginning of the run if it is negative.		The input parameter dynamicWaterLevelCorrectionSkipSnaps is used to skip the specified number of initial data sets in the corrections data file. It can also be used to insert blank snaps at the beginning of the run if it is negative.

	==Water Level Correction Input File==		==Water Level Correction Input File==
Line 48:		Line 55:
	An ADCIRC model is coldstarted with a tide only run that uses a 10 day ramp, and runs for 15 days. How should the water level correction be configured?		An ADCIRC model is coldstarted with a tide only run that uses a 10 day ramp, and runs for 15 days. How should the water level correction be configured?

	In this case, I suggest that you apply your bias correction after reaching full strength tidal forcing (i.e., after the 10 day tidal ramp). So to have your bias correction ramp completed at the end of the 15 day tidal spinup, start the ramp period at 13.0 days and end it at 15.0 days. This should ensure you clearly see the correction occurring when you look at the output data, while avoiding applying the correction too rapidly. In summary, set your ramp period in the fort.15 file to <code>~~dynamicWaterlevelCorrectionRampStart~~ =~~1123200~~.0, ~~dynamicWaterlevelCorrectionRampEnd~~ = ~~1296000~~.0</code>		In this case, I suggest that you apply your bias correction after reaching full strength tidal forcing (i.e., after the 10 day tidal ramp). So to have your bias correction ramp completed at the end of the 15 day tidal spinup, start the ramp period at 10.0 days and end it at 13.0 days. This should ensure you clearly see the correction occurring when you look at the output data, while avoiding applying the correction too rapidly. In summary, set your ramp period in the fort.15 file to <code>dynamicWaterLevelCorrectionRampStart =864000.0, dynamicWaterLevelCorrectionRampEnd = 1036800.0</code>

	Since this is the model spin-up period, using a time-constant correction is likely sufficient. That means a single time snap of correction data can be supplied, for example:		Since this is the model spin-up period, using a time-constant correction is likely sufficient. That means a single time snap of correction data can be supplied, for example:
Line 60:		Line 67:
	##		##

	After the spinup, in preparation for a forecast run, when you want to migrate from one set of bias correction values to another over a 6 hour time period, the fort.15 file's <code>~~dynamicWaterlevelCorrectionControl~~</code> line would be something like this:<br/>		After the spinup, in preparation for a forecast run, when you want to migrate from one set of bias correction values to another over a 6 hour time period, the fort.15 file's <code>dynamicWaterLevelCorrectionControl</code> line would be something like this:<br/>
	<code>&~~dynamicWaterlevelCorrectionControl dynamicWaterlevelCorrectionFileName~~= "offset_migration_from_00Z_to_06Z.dat", ~~dynamicWaterlevelCorrectionMultiplier~~ = 1.0, ~~dynamicWaterlevelCorrectionRampStart~~ = 1252800.0, ~~dynamicWaterlevelCorrectionRampEnd~~ = 1296000.0, ~~dynamicWaterlevelCorrectionRampReferenceTime~~ = "coldstart", ~~dynamicWaterlevelCorrectionSkipSnaps~~ = 0 /</code>		<code>&dynamicWaterLevelCorrectionControl dynamicWaterLevelCorrectionFileName= "offset_migration_from_00Z_to_06Z.dat", dynamicWaterLevelCorrectionMultiplier = 1.0, dynamicWaterLevelCorrectionRampStart = 1252800.0, dynamicWaterLevelCorrectionRampEnd = 1296000.0, dynamicWaterLevelCorrectionRampReferenceTime = "coldstart", dynamicWaterLevelCorrectionSkipSnaps = 0 /</code>

	and the corresponding file would look like something like the following:		and the corresponding file would look like something like the following:
Line 85:		Line 92:

	==Frequently Asked Questions==		==Frequently Asked Questions==
	'''Question: '''When writing the &~~dynamicWaterlevelCorrectionControl~~ namelist, should I write the parameters on a single line, comma separated?<br/>		'''Question: '''When writing the &dynamicWaterLevelCorrectionControl namelist, should I write the parameters on a single line, comma separated?<br/>
	'''Answer: '''I always put fortran namelist parameters on a single line and separate the assignments with commas, but other formatting may be possible depending on the compiler you are using. I've never had issues with the way I format these fortran namelist input lines, but I've never tried any other way so I'll defer to your compiler's documentation on that.		'''Answer: '''I always put fortran namelist parameters on a single line and separate the assignments with commas, but other formatting may be possible depending on the compiler you are using. I've never had issues with the way I format these fortran namelist input lines, but I've never tried any other way so I'll defer to your compiler's documentation on that.

Taylorgasher: changed "offset" to correction and updated the dynamicWaterlevelCorrection namelist names

2020-06-16T17:53:08Z

changed "offset" to correction and updated the dynamicWaterlevelCorrection namelist names

Show changes

Taylorgasher: Taylorgasher moved page Water level offset to Dynamic water level correction: matching updates to input parameters and variables in code

2020-06-16T17:43:37Z

Taylorgasher moved page Water level offset to Dynamic water level correction: matching updates to input parameters and variables in code

← Older revision	Revision as of 13:43, 16 June 2020
(No difference)

Taylorgasher: /* Frequently Asked Questions */

2019-05-28T16:32:16Z

Frequently Asked Questions

← Older revision		Revision as of 12:32, 28 May 2019
Line 85:		Line 85:

	==Frequently Asked Questions==		==Frequently Asked Questions==
	Question: When writing the &offsetControl namelist, should I write the parameters on a single line, comma separated?		'''Question: '''When writing the &offsetControl namelist, should I write the parameters on a single line, comma separated?<br/>
			'''Answer: '''I always put fortran namelist parameters on a single line and separate the assignments with commas, but other formatting may be possible depending on the compiler you are using. I've never had issues with the way I format these fortran namelist input lines, but I've never tried any other way so I'll defer to your compiler's documentation on that.

	Answer: ~~I always put fortran namelist parameters on~~ a ~~single line and separate~~ the ~~assignments with commas~~, but ~~other formatting~~ may be ~~possible depending on~~ the ~~compiler you are using~~. ~~I've never had issues~~ with the ~~way I format these fortran namelist input lines~~, ~~but I've never tried any other way so I'll defer to your compiler's documentation on that~~.		'''Question: '''Do I need to ramp the offset, i.e., is it wise to do so for some reason? <br/>
			'''Answer: '''We haven't tried a sudden application of the water level offset to the solution, but it should behave the same as a sudden application of atmospheric pressure forcing, which could lead to (presumably spurious) waves. Our shortest ramp up period is 12 hours but you might get away with 6 hours or even less. We have seen that rapidly ramping in the offset can lead to two outcomes that may be undesirable. One is a strong geostrophic current response. The other is that the water level response can lag behind the offset. This is most common for large water bodies with narrow connections to the open ocean, such as Pamlico Sound in North Carolina.

	Question: ~~Do I need to ramp the offset, i.e., is it wise to do so for some reason?~~		'''Question: '''Does the application of a dynamic water level offset surface affect the velocity solution (not just the elevation solution as it is primarily intended)? <br/>
			'''Answer: '''Yes, hopefully in a physically realistic manner. As an example, when applying a water level offset to a back bay area with a nearby tidal inlet, the water level change in the back bay must be reflected in the velocity in the inlet in order to maintain continuity (conservation of mass). In the case of an initial application of a temporally steady water level offset, this velocity effect will be a one-time occurrence. On the other hand, for a time varying water level offset surface, the continuous adjustments to the water level will be continuously reflected in the velocity solution. This should be physically realistic when the water ''should have'' come from offshore, but if the elevated water level is due to rainfall, then the model is directing flow in the wrong direction.
	~~Answer: We haven~~'t tried a sudden application of the water level offset to the solution, but it should behave the same as a sudden application of atmospheric pressure forcing, which could lead to (presumably spurious) waves. Our shortest ramp up period is 12 hours but you might get away with 6 hours or even less. We have seen that rapidly ramping in the offset can lead to two outcomes that may be undesirable. One is a strong geostrophic current response. The other is that the water level response can lag behind the offset. This is most common for large water bodies with narrow connections to the open ocean, such as Pamlico Sound in North Carolina.

	~~Question:~~ Does the application of a dynamic water level offset surface affect the velocity solution (not just the elevation solution as it is primarily intended)?

	Answer: Yes, hopefully in a physically realistic manner. As an example, when applying a water level offset to a back bay area with a nearby tidal inlet, the water level change in the back bay must be reflected in the velocity in the inlet in order to maintain continuity (conservation of mass). In the case of an initial application of a temporally steady water level offset, this velocity effect will be a one-time occurrence. On the other hand, for a time varying water level offset surface, the continuous adjustments to the water level will be continuously reflected in the velocity solution. This should be physically realistic when the water ''should have'' come from offshore, but if the elevated water level is due to rainfall, then the model is directing flow in the wrong direction.

	==References==		==References==

Taylorgasher: /* Frequently Asked Questions */ conjecture

2019-05-28T16:31:14Z

Frequently Asked Questions: conjecture

← Older revision		Revision as of 12:31, 28 May 2019
Line 91:		Line 91:
	Question: Do I need to ramp the offset, i.e., is it wise to do so for some reason?		Question: Do I need to ramp the offset, i.e., is it wise to do so for some reason?

	Answer: We haven't tried a sudden application of the water level offset to the solution ~~so we don't yet know how that would~~ behave. Our shortest ramp up period is 12 hours but you might get away with 6 hours or even less. We have seen that rapidly ramping in the offset can lead to two outcomes that may be undesirable. One is a strong geostrophic current response. The other is that the water level response can lag behind the offset. This is most common for large water bodies with narrow connections to the open ocean, such as Pamlico Sound in North Carolina.		Answer: We haven't tried a sudden application of the water level offset to the solution, but it should behave the same as a sudden application of atmospheric pressure forcing, which could lead to (presumably spurious) waves. Our shortest ramp up period is 12 hours but you might get away with 6 hours or even less. We have seen that rapidly ramping in the offset can lead to two outcomes that may be undesirable. One is a strong geostrophic current response. The other is that the water level response can lag behind the offset. This is most common for large water bodies with narrow connections to the open ocean, such as Pamlico Sound in North Carolina.

	Question: Does the application of a dynamic water level offset surface affect the velocity solution (not just the elevation solution as it is primarily intended)?		Question: Does the application of a dynamic water level offset surface affect the velocity solution (not just the elevation solution as it is primarily intended)?

	Answer: Yes, hopefully in a physically realistic manner. As an example, when applying a water level offset to a back bay area with a nearby tidal inlet, the water level change in the back bay must be reflected in the velocity in the inlet in order to maintain continuity (conservation of mass). In the case of an initial application of a temporally steady water level offset, this velocity effect will be a one-time occurrence. On the other hand, for a time varying water level offset surface, the continuous adjustments to the water level will be continuously reflected in the velocity solution. This should be physically realistic when the water ''should have'' come from offshore, but if the elevated water level is due to rainfall, then the model is directing flow in the wrong direction.		Answer: Yes, hopefully in a physically realistic manner. As an example, when applying a water level offset to a back bay area with a nearby tidal inlet, the water level change in the back bay must be reflected in the velocity in the inlet in order to maintain continuity (conservation of mass). In the case of an initial application of a temporally steady water level offset, this velocity effect will be a one-time occurrence. On the other hand, for a time varying water level offset surface, the continuous adjustments to the water level will be continuously reflected in the velocity solution. This should be physically realistic when the water ''should have'' come from offshore, but if the elevated water level is due to rainfall, then the model is directing flow in the wrong direction.

	==References==		==References==