A question was asked:
I responded: I think I now understand the source of this difference.
We have some logic in the pre-processor that will "boost" dry lands and fresh water wetlands above the "salt boundary" if they fall below the salt boundary. Say, for example, that you have a contour interval of 10 feet. In your digital elevation map (DEM) you might have a lot of dry land that, according to the NED, is below that 10 foot contour. I have found that the DEMs from the NED assign pretty much everything under the lowest contour to some fairly arbitrary low value (Jim Titus once told me how they assigned the shoreline but I can't quite remember... maybe MHHW?... anyway). Unless the pre-processor intervenes, a whole lot of fresh marshes and dry land convert immediately.
To solve this problem we "boost" all of those dry-land elevations below the "salt boundary" to above the "salt boundary" (or "salt elevation.") Like wetlands we use a uniform distribution moving away from the "direction offshore" up to the elevation of the lowest contour (this is now editable as the "upper bound" in the elevation analysis screen).
Recently I had a problem when running a site with dikes. Land behind dikes should never be "boosted" because it often falls below the salt boundary due to the seawalls surrounding it. I tried to run a simulation with dikes removed and did not find any conversion of dry lands that I knew were well below the salt boundary. That was because the dikes were not being included so the software assumed that these lands needed to be "boosted."
Therefore I put in this piece of logic:
If a cell is protected by dikes OR if the dikes are not included, then do not boost the dry land elevations. (1-8-2010)
I did not realize that this meant a site would have different results if the site has no dikes file and if the "use dikes" option is changed.
The upshot is, with the current version, please do not run the model with "dikes turned off" if you don't have a dike file to begin with. I guess that I need to change that logic so that it knows whether a location is diked or not, even if dikes are not included so that SLAMM knows which land to boost and which land not to boost. (Previously the software was not even loading in the dike layer as it wasn't planning on "including dikes." So I will have to change that logic in the software.) But in the short run, leave "include dikes" on and that will give you the "correct" answer for this site. I'll also change the code so that it reads
If a cell is protected by dikes OR (if a dike file exists AND if the dikes are not included), then do not boost the dry land elevations. (2-22-2010)
That line of code should prevent further confusion as you experienced though it is not perfect (as it does not discern which lands should remain "boosted" due to their non-diked status and which lands should not).
I have to say that I have become a lot more comfortable using the model when there are high-vertical-resolution elevation data available. This whole pre-processing and "boosting" set of procedures is really trying to make the best of a bad situation. The model assigns uniform distributions to each wetland type from their lowest estimated range to their highest. LiDAR data have shown us that some wetlands are perched precariously above their lowest elevation (the elevation at which point they will convert to tidal flats or open water) and other wetlands are safely located high above it. These initial-condition elevations therefore make a difference in the extent and timing of wetland-loss predictions. When we are forced to use the pre-processor, lacking all of that information, we just assign the wetlands with elevations over their existing range. Boosting dry lands is similar. You need to hope you have the correct salt elevation assigned and there is not some other factor (like tide range reduction) that allows dry land to persist at a lower elevation.
Also, when running the model with LiDAR, you have a good sense of whether your MTL to NAVD88 correction is working, and your tide ranges are parameterized properly because, if not, then you have problems with your "time-zero" results or elevation analysis. With no LiDAR data, the model just "corrects" elevations that do not match its conceptual model, so you have no such check on your input parameters...
The uncertainty of the pre-processor is something that should be firmly caveated in any discussion of model results. "Model uncertainty for this site is quite a bit higher due to the absence of high-vertical-resolution elevation data."
I hope that this resolves your problem, thanks for being such helpful beta testers, and I'm sorry that I didn't think of this possibility when solving my other problem with what seemed like an innocuous line of logic! Let me know if your problem persists or if you find any other strange results.
-- Jonathan
QuoteWhy do my model results look different when I select to "ignore dikes" as I have no dike layer associated with my simulation? I am using the elevation pre-processor due to a low-vertical-resolution elevation coverage.
I responded: I think I now understand the source of this difference.
We have some logic in the pre-processor that will "boost" dry lands and fresh water wetlands above the "salt boundary" if they fall below the salt boundary. Say, for example, that you have a contour interval of 10 feet. In your digital elevation map (DEM) you might have a lot of dry land that, according to the NED, is below that 10 foot contour. I have found that the DEMs from the NED assign pretty much everything under the lowest contour to some fairly arbitrary low value (Jim Titus once told me how they assigned the shoreline but I can't quite remember... maybe MHHW?... anyway). Unless the pre-processor intervenes, a whole lot of fresh marshes and dry land convert immediately.
To solve this problem we "boost" all of those dry-land elevations below the "salt boundary" to above the "salt boundary" (or "salt elevation.") Like wetlands we use a uniform distribution moving away from the "direction offshore" up to the elevation of the lowest contour (this is now editable as the "upper bound" in the elevation analysis screen).
Recently I had a problem when running a site with dikes. Land behind dikes should never be "boosted" because it often falls below the salt boundary due to the seawalls surrounding it. I tried to run a simulation with dikes removed and did not find any conversion of dry lands that I knew were well below the salt boundary. That was because the dikes were not being included so the software assumed that these lands needed to be "boosted."
Therefore I put in this piece of logic:
If a cell is protected by dikes OR if the dikes are not included, then do not boost the dry land elevations. (1-8-2010)
I did not realize that this meant a site would have different results if the site has no dikes file and if the "use dikes" option is changed.
The upshot is, with the current version, please do not run the model with "dikes turned off" if you don't have a dike file to begin with. I guess that I need to change that logic so that it knows whether a location is diked or not, even if dikes are not included so that SLAMM knows which land to boost and which land not to boost. (Previously the software was not even loading in the dike layer as it wasn't planning on "including dikes." So I will have to change that logic in the software.) But in the short run, leave "include dikes" on and that will give you the "correct" answer for this site. I'll also change the code so that it reads
If a cell is protected by dikes OR (if a dike file exists AND if the dikes are not included), then do not boost the dry land elevations. (2-22-2010)
That line of code should prevent further confusion as you experienced though it is not perfect (as it does not discern which lands should remain "boosted" due to their non-diked status and which lands should not).
I have to say that I have become a lot more comfortable using the model when there are high-vertical-resolution elevation data available. This whole pre-processing and "boosting" set of procedures is really trying to make the best of a bad situation. The model assigns uniform distributions to each wetland type from their lowest estimated range to their highest. LiDAR data have shown us that some wetlands are perched precariously above their lowest elevation (the elevation at which point they will convert to tidal flats or open water) and other wetlands are safely located high above it. These initial-condition elevations therefore make a difference in the extent and timing of wetland-loss predictions. When we are forced to use the pre-processor, lacking all of that information, we just assign the wetlands with elevations over their existing range. Boosting dry lands is similar. You need to hope you have the correct salt elevation assigned and there is not some other factor (like tide range reduction) that allows dry land to persist at a lower elevation.
Also, when running the model with LiDAR, you have a good sense of whether your MTL to NAVD88 correction is working, and your tide ranges are parameterized properly because, if not, then you have problems with your "time-zero" results or elevation analysis. With no LiDAR data, the model just "corrects" elevations that do not match its conceptual model, so you have no such check on your input parameters...
The uncertainty of the pre-processor is something that should be firmly caveated in any discussion of model results. "Model uncertainty for this site is quite a bit higher due to the absence of high-vertical-resolution elevation data."
I hope that this resolves your problem, thanks for being such helpful beta testers, and I'm sorry that I didn't think of this possibility when solving my other problem with what seemed like an innocuous line of logic! Let me know if your problem persists or if you find any other strange results.
-- Jonathan