Thanks Amy.  I sent everything over to you on 1/14.  Would you mind just confirming that it got to you?

Thanks!
Jen

Hi Jonathan,

I am still in the process of trying to determine the sources of the problems that I'm seeing with our wetlands/elevation data not complying with SLAMM's conceptual model and as a result, significant conversions happening between initial input and T=0.  Recently I've been focusing on simply ensuring that our wetlands are all categorized correctly (we are not using NWI data) and making sure the parameterization is correct before I start editing any elevation ranges.

In looking at our GIS maps more closely I noticed an issue I cannot figure out.  As I've mentioned previously, large swaths of initial state salt marsh (we are calling all salt marsh "irregularly flooded" right now) are converting to mangrove in year 0.  I would have guessed this was due to the salt marsh elevation being lower than what SLAMM would have expected (i.e., lower than 0.5 HTU) and thus making the conversion to mangroves immediately.  However, as I click around the map to see elevations in this area they appear to be comfortably within SLAMM's range for irregularly flooded marsh (0.5 HTU - Salt elevation).

For example, I'm in an area where the elevation (NAVd88) is between about -0.07 m and 0.08 m NAVD88.  If my HTU value is 0.025 m, and my NAVD correction is 0.205, according to my calculations, the range for irregularly flooded salt marsh in NAVD 88 would be -0.19 m to 0.12 m (the salt elevation).  If the area of irreg. flooded salt marsh is comfortably within the range, why would it be converting to mangrove right away?  Could there be other causes for this problem that I should be considering?

Thank you!
Jen

Hi again,

Well that would certainly make a difference!  I don't see anywhere in the Tech Documentation or user manual that specifies that salt elevation should be in MTL=0 terms, but since the correction factor is specified I assumed it wanted all input information (LiDAR, salt elevation) in NAVD 88.  So we are going to have to re-run the model and elevation analysis with that revised parameter.  We are also making a few revisions to our wetland categorizations (we are not using NWI data) and to several of the other parameters.  We anticipate re-running the model early next week, and it would be great if you could take a look at the file after that.  I'm having quite a bit of difficulty with the Elevation Conceptual Model being very far off what we are seeing with our data (noticeable both from the elevation analysis and extensive conversion that happens between the initial condition and T=0 (see my other posts on these topics)).  It would be great if you were able to take a look at our project file to see if I'm making an error somewhere.

Please let me know where I can send this information.

Thanks!
Jen

Hi Amy,

Thanks very much for your response.  Regarding the elevation conversion, I did need to see it in meters NAVD 88.  This analysis was run just for one subsite for which we input one correction factor, so the variability in the tides and correction factor should not be an issue.

As far as the salt elevation conversion to HTU.  I was looking at the first section of the elevation analysis.  It shows the min elevation for several habitat types as 1 Salt Elevation.  It then also shows the minimum in HTU, in this case 1.09091.  To convert from 1 salt elevation to HTU I assume you would divide the salt elevation by the HTU in meters value.  So in this case, where I have a NAVD salt elevation of 0.12 (which is what is entered into the model) and an HTU of 0.11 m I end up with a salt elevation in HTU of 1.09091. 

If, instead, the salt elevation were based on salt elevation where MTL = 0, I end up with a different number.  In that case, I would convert my NAVD salt elevation of 0.12 m using the correction factor of 0.205 m to get 0.325 m.  If I then divide that by the HTU in m (0.11 m) I get 2.9455 m for the salt elevation in HTU.

Please let me know if I'm interpreting something incorrectly here.  This site is quite a challenge in terms of fitting it to the conceptual model and the salt elevation appears to be one of the most critical issues.....

Thanks!
Jen

Hello,

I am interested in converting the results of the elevation analysis to true elevation in order to allow for easier consideration by local experts of the elevation ranges in which the various habitat types exist.  To do so, I would think that the following conversion equation would be appropriate:

[results in HTU] * [HTU in meters] = Result in meters adjusted to MTL = 0
[results in meters adjusted to MTL = 0] - [NAVD 88 correction factor] = Results in meters, NAVD 88

So for example:
the 5th percentile elevation for Transitional Salt Marsh is -1.54 HTU. 
HTU in this system is 0.11 meters.
the 5th percentile elevation in meters is thus -1.54*0.11 = -0.17 meters (relative to a system in which MTL = 0)
The NAVD 88 correction factor in this area is 0.205 m
-0.17 meters - 0.205 m = -0.37 m NAVD 88

So -0.37 m NAVD 88 is the 5th percentile of the elevation range for Transitional Salt Marsh.

I would be grateful is someone could check my math on this and let me know if this is the appropriate way to do this conversion.  I thought it was, but got confused about whether the results of the analysis were already in NAVD88.  This came up because I noticed that in the Conceptual model output it calculated the "Min in HTU" and "Max in HTU" values based on the salt elevation in NAVD 88, rather than on the salt elevation corrected such that MTL = 0.

Thank you!

Eric,

This is very helpful, thank you.  It wasn't clear from the documentation how much "work" SLAMM was doing between the initial state entry and Time = 0 (thanks for clarifying the terminology there.)  It seems as though our suspicion was correct and SLAMM does not "like" where our habitats are falling elevation-wise.  We had run the Analysis and were in the process of figuring out what more appropriate ranges might be.  Related to that process, I'm wondering if there are any limitations to how flexible SLAMM is with these assignments.  Put another way, are there limits to what it will tolerate for ranges of specific habitat types because of how the background analysis is being run and presumably some order of succession it has hard-wired? 

Thanks!
Jen

I am modeling a large estuary with an "unconventional" tidal/sea level situation.  In the estuary, there is a relatively small daily tidal range, but a significant (approx. 1 ft) difference in sea level over the course of the year.  Specifically, sea level is about 1 foot higher in October than it is in May.  Thus, traditional mean tide level datapoints tend to mask the true extent of saline inundation/exposure in the area.   We are in the process of determining how best to accommodate this situation in SLAMM.

The most obvious issue that this creates in SLAMM is that the habitats in the region are not going to conform to SLAMM's predicted habitat ranges.  (see my previous post for an example of how this plays out in a model run).  It seems there are two options for dealing with this:
1. run the elevation analysis and revise the ranges to better reflect reality
2. rather than using the "sanctioned' calculations for the various tidal data, use proxies of other tidal statistics that would have the same operational meaning of the requested tidal data and would fit the habitat types better.  (e.g., define MLW as whatever the lower extent of the tidal flats are, rather than calculating it as you normally would).

Option 2 was suggested by individuals in the region prior to me becoming familiar with the elevation analysis.  It now seems that Option 1 would work well, and is a much more straightforward way to deal with this.

Other than providing a limit for some of the habitat types, how else does SLAMM utilize the user-provided tidal data?  Are there other tweaks that might need to be made to accommodate this situation?


Thanks,
Jen

Just to add another thought as I'm continuing to look at this issue.  The fact that the pre-processor eliminated the problem seems to potentially indicate that the issue IS being caused by SLAMM not liking the elevation ranges where it is finding our habitat types.  Because isn't the pre-processor revising our elevation data such that the elevation for a particular habitat type would be reassigned to the anticipated range of elevation for that habitat type?

I am running SLAMM in a large estuary using 2004 LULC data (converted to SLAMM categories) and circa 2006 LiDAR data (5 ft x 5 ft resolution).  We are running the model on a 10 m square resolution, and have resampled the LiDAR data using bilinear interpolation to get to that resolution.  We have run the model for 4 subsites and in each case the habitat conditions in T=0 (the input) are drastically different from what is being modeled for 2004 as the "initial" condition.  We're seeing things like an over 800% increase in mangroves, and conversion of large extents of irregularly flooded marsh being converted to regularly flooded marsh (there was no regularly flooded marsh identified in the input data), to name a few.

Just as a test, we ran one of the subsites with the Pre-processor on and it yielded a T=0 and 2004 initial condition that are nearly identical.  However, even with the resampling that we did, I wouldn't think we should be running the pre-processor since we have Lidar data.

What process is SLAMM going through from the input to the initial condition that could cause the extent of change that we are seeing?  My one thought is that it might have something to do with a unique tidal regime in the estuary (which I will ask about in detail in another post) which causes the elevation ranges of wetland habitats to be quite different from what SLAMM assumes.  In other words, perhaps at T=0 it is seeing habitat types at elevations it does not "agree" with and is revising them according to its assumptions about correct ranges? 

Any thoughts? 

Thanks!
Jen

I am modeling in an area that has been significantly altered by mosquito impoundments.  We have high quality LiDAR data for the region, so I'm wondering if there is any reason to use a separate dike file.  Based on our results, it appears that the dike is simply being overtopped after a sufficient sea level rise has occurred (I'm a bit confused, however, because the area behind the dike is becoming inundated but the dike itself, dry land which is not assumed to be protect in my run, remains as such).  It is not the intent to protect these diked areas from inundation, but rather to just let inundation occur naturally, and efforts are being made to re-establish connectivity.  Would the connectivity model allow water to simply flow into these diked areas, rather than inundation only occurring after the dike itself has been overtopped?

Thanks!
Jen

I'm modeling an area in which some "recoding" of the LiDAR data was done prior to its distribution and am wondering what effects this could potentially have on my results.  Specifically, all inland water bodies were recoded to a blanket elevation of -0.03 meters.  (The mean sea level in the region is about -0.21 meters).  Thus, in certain instances we have wetland habitats that are at a lower elevation than adjacent water bodies.

The model seemed to run without any trouble and I don't see anything jumping out as odd because of this issue.

On a somewhat related note, the LiDAR data have also been purged of any codes of the estuaries and open ocean (ie., those areas are all "no data").  It seemed critical to have at least a few cells of water adjacent to land coded as such, and I've assigned them all as the MSL elevation.

More generally, my question is, what role does the elevation of water play, if any, in habitat conversions or other model functions within SLAMM?  Would you suggest other strategies for getting around the issues described above?

Thanks,
Jen