No, I didn't use the pre-processor in either run as both included only lidar-derived DEMs.
Thanks for the correction on estuarine beach. It's correct in the screenshots and rasters, I just misread it.
Good to know that the low elevation for Tidal Flats hasn't changed b/t versions.
There's no swamp class (or little of it) in these screenshots or at this site, just Regularly Flooded Marsh that's abutting the Tidal Flats you see. I've been using a different color scheme than the model's default.
I've been thinking about this some, and it seems that the issue may relate to me having used two sources of data for the different versions. For the version 5 run, I used 1983 landcover data. For v.6, I used 2006 land cover data. For both, I used 2007 lidar elevation data.
The total rise for the v.5 run is a little over 1.1 m, whereas for v.6 it's a little more than 0.9 m. Something you can't see in the screen shots is that the marsh converts to open water only in the last time step for the v.5 run (ie b/t 2075 and 2100). This is essentially the same for the v.6 run, except the change is to Tidal Flat. I'm assuming this means that if the model played out a little longer, so to 1.2 m rise using the custom scenario, that the Tidal Flats would likely turn to open water. I know this should be the same, but given the timesteps and different start date, perhaps I'm capturing the "cusp" of the change.
Has anyone else noticed some major differences b/t slamm 5.0.2 and 6.0.1 outputs, especially regarding conversion to open water vs estuarine beach? I seem to be having much more estuarine beach in ver. 6 compared with open water for ver. 5. I'm wondering if this is an error in the code or if something is new in slamm 6 that would be affecting this part of the decision tree. All input parameters were essentially the same. Is there some switch that is set to a different default, like erosion, in ver. 6? Some of the areas that convert from reg. flooded marsh to estuarine beach start out at 0m of elevation, so I know something's not processing correctly.
You can see the attached screenshots of the initial condition compared with slamm 5 and 6 ouputs. The only changes b/t the inputs b/t versions relate to using the MTL correction grid, instead of a global site value and some minor modifications (for the better) of the DEM.
Yes, my original raster is initialized with zeros, if by "initialized" you mean the relevant areas (such as open water) have zeros instead of no data. As you point out, the only problem then is all the space that vdatum doesn't account for in upland areas.
I'm looking into an interpolation technique that will resolve that matter. I'm also checking out Evan's post with the VDATUM2RASTER executable.
That would be great if you'd share an MTL-NAVD88 raster with me. I'd like to QA this work. This makes sense though not that I see the raster of correction values.
Great! Thanks for sharing those, Evan. I'll look into them.
After reading Jonathan's confirmation of my assumption about SLAMM wanting a raster of correction values (which is intuitive, but not spelled out in the documentation), I followed through on it and was successful. In other words (for others), I used MTL as the input datum and NAVD88 as the output datum in the VDATUM software (though this is counter-intuitive). This gave me a txt file labeled with the NAVD88 prefix (if output folder is same as input in VDATUM) which is a bit misleading, but useful for generating the grid of correction values. I then subtracted these values from my original raster, which gives a spatial grid of correction values for input to SLAMM.
So in short, my equation 2 product above is what I get as an output from VDATUM, but then in Arc I do:
eq. 3 vdatum output - vdatum input = navd88 correction [all in raster format] or to use my example 0.29m - 0.5m = -0.21 which is one example point.
I don't claim expert status, but I've attached my workflow as a text file, which isn't generalized, but I hope useful to others. There are some quirks, like the ASCII to XYZ script I downloaded from Arcscripts inverts the raster data on the Y axis, but the Flip tool takes care of that. Then on import, my 3D multipoint file snaps the grid off by one cell (ie 3m), so I use the shift tool to realign. I'm pretty sure this is working correctly, as all seems perfectly reasonable. BUT, please do let me know if you see mistakes.
I've been trying to get this to work correctly for a few days now, but am in need of assistance. I understand what Jonathan posted, but am unclear on exactly what SLAMM is expecting for the VDATUM [input] file. Can someone please elaborate?
Is it expecting a ascii txt file of correction values? For example, if NAVD88 = 1.806 and MTL datum = 1.596, then the correction factor, i.e. NAVDcorr. = -0.21. This indicates that a point with elevation of 0.5m in NAVD88, let's say, will become
eq. 1 0.5 - (-0.21) = 0.77m in the MTL datum
For the VDATUM software, I've read elsewhere on this forum comments that indicated loading the NAVD88 elevation raster (in XYZ format), but choosing for the input datum, MTL, and the output datum, NAVD88. The output VDATUM file then will have values (using the above example point) of:
eq. 2 0.5 - 0.21 = 0.29m
From here, I'm lost as to what to do next. Have I misunderstood the input datums for the VDATUM software (it does seem counter intuitive). I think a simple explanation of what SLAMM is actually looking for or doing with the "VDATUM file" will help me greatly.
If SLAMM is looking for a grid of spatially explicit correction values, then I would want to follow up with the above example by subtracting the NAVD88 elevation raster from the VADTUM output in ArcMap, right? Or does SLAMM do this for me? I put the VDATUM output grid into SLAMM but am getting highly erroneous values under the Set Map Attributes map. It appears SLAMM is taking my input elevation grid and subtracting the VDATUM input grid. If this is so, my assumption of SLAMM "wanting" an NAVD88corr grid (i.e., using my example, a spatially variable grid around my site level correction factor of -0.21m).
Thanks in advance for comments. I've been struggling to understand just what SLAMM "wants" as input for the VDATUM file.
One major criticism I keep hearing from people is that SLAMM does not model any uncertainty in its forecasts. Of course, one can spatially show some uncertainty by modeling various SLR scenarios (e.g. 1m, A1B, etc) and showing a range of options. However, is there a way to show an "envelope" or range of possibilities around one particular scenario (such as 1m)?
I have seen uncertainty modeled for bathtub type models in a recent publication, assessed against Geodetic benchmarks.
I was wondering what the effect of running the 1m scenario with the MTL changed to both MHW and MLW (and correspondingly changing the MHW and MLW by equal amoints in similar directions) for independent runs would do? Would this work, and potentially show a range of possibilities or uncertainty in the model?
Any feedback on these thoughts from folks working with SLAMM, especially regarding how to show model uncertainty would be great!
Great news about the possibility of elevation outputs.
I agree with you, Jonathan, about the misrepresentation of possible wetlands below MTL in some areas. I've already gone back and recoded to show: 1) upland (aka dryland), 2) non-tidal wetland, 3) tidal wetland, & 4) open water. I feel like this takes care of the possibility of wetlands below MTL. The maps look the same, it's just a renaming, more than a recoding.
And yes, I haven't forgotten about SLAMM holding tidal ranges constant. That would be a hard one to predict!
I agree that this would be a great idea. One thing coastal stakeholders are concerned about is where the new tide range will be, which isn't easy to depict based on the land cover outputs. However, having the predicted elevation map would facilitate adding and subtracting MHHW and MLLW from MTL, thereby showing the new tidal range.
So far the best I could come up with was a reclassification of the land cover to show four classes of 1) dryland, 2) non-tidal wetland, 3) upper tidal influence, and 4) below MTL. Basically all open water classes (i.e. 13-19) are considered Below MTL, while all other tidally influenced classes are in the Upper Tidal Influence (ie considered to be between MTL and MHHW). I'm not convinced this is accurate though. Advice is welcomed for depicting the tidal zone in the predicted outputs.
This has happened to me before, many months ago. I don't remember exactly what it was that was causing it, but I think it has to do with alignment of your input rasters. I *think* that all your input layers have to be exactly the same extent or you'll get this error. Good luck!
I'm checking the rasters for all years now, but having to import them from the ASCII format. I'll let you know how it checks out. So far, 2 of 19 sites were normal (including e3) for year 2100, but the others were all corrupted. I'll send you some of a corrupted site later. Thanks for your help again!
This was run with the command line. I haven't tried running it with that version (assuming the command line is a diff. ver. than the original v/6 release). The release executable from the 1st ran everything fine with a 10m resolution. I didn't run the maps, so I don't know the answer to that. This is the ascii from the output. I'll check the columns, but the same set of input ascii files run fine this way in 5.0.4.