Actually, the answer for SLAMM5 and SLAMM6 is different:

SLR (main) from SLAMM 5 is the estimated relative SLR since the NWI photodate [simulation start date] by adjusting global eustatic SLR scenarios for local effects using historical SLR rates.  It is labeled "main" because it is relevant for the main or "global" sub-site only.  If there are many sub-sites they may have different historical SLR and different NWI photo dates so the results may differ from one sub-site to the next.

In SLAMM6 uplift and subsidence may be specified with a spatial raster map.  Between that, and the problem with the sub-sites cited above, I gave up trying to quantify the relative SLR and instead just list eustatic SLR for the scenario since the NWI photodate.

-- J

Please use this forum to discuss successes or problems compiling the open source code so that we can continue to refine this process.

As I noted in the instructions for Open Source Compilation, the OpenGL library that we used for this project is not available on the web as the website went down.  However, I found a way to access it using the "Internet Archive"  This link should do the trick for now:

http://web.archive.org/web/20080220144905/http://www.delphi3d.net/download/dot.zip

If this doesn't work, please contact me directly and I will see what I can do to find another link or help the file compile.  I don't have permission to distribute the OpenGL library at this time but am trying to contact the developer. 

Also, please let me know about successes / failures compiling on other platforms such as Delphi 2010, Lazarus, etc. Thanks!

FYI, here are the compilation notes:

-------------------------------------------------------------------------------------------------------------------------------------------------------------

SLAMM Open-Source Code Distribution, 11/30/2009
Code Produces SLAMM 6 beta
Code is object oriented Pascal written with Borland Delphi 2007 development platform

This code is licensed under the Common Public License (CPL), see SLAMM_License.txt

------------------------------------------------------------------------------------

To compile this source code as-is, the following steps must be taken:

1. Install Borland Delphi 2007 for WIN32.   It is recommended that the latest Delphi 2007
   hot-patches and updates be installed though this does not appear to be strictly necessary to
   compile this particular code.

2. Unzip this zip file into a single directory.  This will be your main program directory.

3. Download the Delphi OpenGL Toolkit: http://www.delphi3d.net/  The resulting file structure
   must be placed in an OPENGL directory off of the main program directory, including the
   FRAMEWORK folder.   

   IMPORTANT UPDATE 11/30/2009.  This website is down, hopefully temporarily.  I  will
   do some research as to other sites to download this library or link in an alternative
   library.  Unfortunately I am unable to distribute the library directly via request from the
   developer who writes:  "Please do not redistribute the Dot source code. If you want to share
   the Dot with others, please provide a link to www.delphi3d.net/dot instead, so people can
   download the latest version of the Dot from there." 

   As noted above, you may use the web-archive for now:
   http://web.archive.org/web/20080220144905/http://www.delphi3d.net/download/dot.zip

4. Select File, Open Project, and Load SLAMM6.dproj file  Executable may be produced by selecting
  "Build" from the Project menu. 

Please send questions to jclough (at@) warrenpinnacle.com

For more information on the "dynamic" accretion model within SLAMM6 please see page 18 of the new Tech. Doc.

    http://warrenpinnacle.com/prof/SLAMM6/SLAMM6_Technical_Documentation.pdf

In my tests, relative paths seem to work, relative to the directory in which the program resides:  For example

../inputfile.txt moves to the directory in which the SLAMM subdirectory is located
subdirectory/inputfile.txt moves to "subdirectory" off of the SLAMM directory.

-- JC

Hi Dean.  When running "protect developed" the model simply takes cells designated as "protected" and does not allow them to be subject to inundation.  It is a very simple algorithm.

The model does not take into account from where developed lands will have to be protected or the measures that will be taken to protect those developed land or the other habitats that will also be protected along with the developed lands.  Trying to estimate this sounds quite complicated in terms of defining algorithms to best estimate where and how seawalls will be built.

Interestingly, a version created many years ago (prior to 1998) included economic estimates.  These included estimates of costs to build seawalls or other land protection to protect developed land.  However, economics changed and these estimates were subject to considerable uncertainty so they were eventually stripped from the code.   -- JC

The SLAMM 6.0.1 model has now been released along with an updated Users' Manual and Technical Documentation

Start with the Release Notes here

    http://warrenpinnacle.com/prof/SLAMM6/SLAMM_6_Release_Notes.pdf

You may download the Installer here

    http://warrenpinnacle.com/prof/SLAMM6/SLAMM6.exe

The Users Manual is located here, and also available as "context sensitive help" from the executable.

    http://warrenpinnacle.com/prof/SLAMM6/SLAMM_6_Users_Manual.pdf

The Technical Documentation may be downloaded here

    http://warrenpinnacle.com/prof/SLAMM6/SLAMM6_Technical_Documentation.pdf

The open source code has been updated to match this latest version (Build 6.0.0008)

    http://warrenpinnacle.com/prof/SLAMM6/SLAMM6_Open_Source.zip

Sample input data may be downloaded here.  These data are provided for model testing only.

    http://warrenpinnacle.com/prof/SLAMM6/Examples/S1_puget.zip


Please provide feedback and questions using these forums.  Ideas for new capabilities, bug reports, questions about existing capabilities, etc.

Thanks for your interest in the SLAMM model.  -- Jonathan Clough

The quick reply is that this is the local SLR predicted at 2100 relative to the NWI photo date.

So, historic SLR (assumed land movement) and the NWI photo date itself will both affect that calculated value.  It is only for the "global" subsite so may not be the most useful metric if many sub-sites are being utilized. 

Dear HeatherAnn:

The goal is certainly to provide better information about crashes in the new version.  The old version had very little bullet-proofing, a function of the lack of money for interface development (as opposed to model application):

The new version provides much more and better info about file compatibility and memory requirements.  I also have slowly been trapping errors and providing better error messages but I'm sure there are still a few out there.  It will not be perfect but it will be open source allowing users to better pinpoint any application problems.

I don't know why you would receive this Range-check error for A1T and not A1B.  You may need to send me the files for me to test that simulation here in "debug mode."  I may be able to get to that over Thanksgiving but I'm under the gun on many deadlines so I can't make promises.  First please make sure you can reproduce the problem by quitting SLAMM, reentering, and re-running the offending application overnight.

-- Jonathan

There is another potential solution to this problem if the offset is extremely small.

If you are working with a UTM projection, so you can see the difference between the lower left corner in meters, you can potentially force the lower left corner to be the same between the two input text files.  (This works with other projections as well though you'll have to do some math to determine the extent of the horizontal error.)

For example, I have received data inputs which were horizontally off-set by well less than 1cm when looking at 30meter cells.  Simply editing the "ASC format" text files so that they have the same lower left corner will solve that problem without introducing any relevant error to model results.

Unless there is a dramatic difference in terms of NWI dates, the model may not be particularly sensitive to the way that the sub-sites are drawn at the boundaries.  If the NWI map seems fairly contiguous between quads (as most of them do, even given varying NWI dates) not much may have changed in the interim. 

Additionally, by zooming in to 200% when drawing boundaries, the quad markers may be drawn fairly precisely.

The situation is similar with DEM dates.  SLAMM tries to use the DEM date and the estimated rate of land movement (based on historical SLR) to create a land elevation estimate at the time of the NWI photo.  Unless land is dramatically vertically moving the model is not likely to be sensitive to differences in the DEM date, especially if we're only talking about a "pixel or two" of misspecification in the boundaries. 

Let me put it this way:  I've never seen artifacts in model results as a result of mis-specifying these boundaries by a pixel or two, though we try to be as precise as possible.

The coordinates of the subsites.txt file are "pixels relative to the upper left corner" so they are not georeferenced.  If you are concerned about errors in the border regions you could do some precise calculations as to pixel locations and edit the subsites.txt file but I would be surprised if you would see any change in model results.   

Please let me know the results of your ongoing investigation and think that this is an important capability to add to the model.  In my experience, it really might not be very important, so has not made the "to do" list.

Thanks for the feedback.  This capability (to import shapefiles) is not something that we currently have planned for SLAMM6 unfortunately.  I agree that it would be quite useful.  It might not take too much effort to undertake such a capability but it has not been funded at this time. 

The use of a raster input site to designate NWI photo date was a short-lived capability in the model but using the hand-drawn polygons proved to be more useful ultimately so it was dropped from the model.

Hand drawn input polygons are a bit crude but I have found them to meet our needs without too much difficulty in the majority of cases.

-- Jonathan

A Scientist with National Geodetic Survey writes:

QuoteI'm writing to follow up on the question of how the tidal and geodetic datum offsets are applied in 6.0. In a nutshell, the issue is that in 5.0 the tidal / geodetic datum offset value for a single tide station was applied over large geographic areas where that relationship does not necessarily hold constant, therefore adding increasing sources of error/uncertainty in areas farther away from where the tidal geodetic relationship was established.

Jonathan Responds:

I have to clarify a few points about SLAMM 5--

The tidal / geodetic datum could be and usually was defined within smaller polygons or "sub-sites" as we call them in SLAMM jargon.  This allowed us to utilize a gradient based on multiple NOAA tide stations or the VDATUM product when it was available.  In recent model applications we have defined sub-sites as regions in which differences in the vertical datum correction would be minor.  Given that the vertical resolution of our best elevation (LiDAR) is in the range of 5-10 cm we usually would define these areas as having differences of 1 cm or less.  Given the vertical resolution of our input elevation data, the tidal / geodetic datum uncertainty was almost always an order of magnitude or so less. 

Perhaps more importantly, there is an "unpublished" capability in SLAMM 5 to read a raster map of tidal / geodetic datum offset values which we produced using the NOAA VDATUM product.  We have used this capability in many of our SLAMM applications where VDATUM coverages were available.

When there was no VDATUM coverage and considerable distances between NOAA stations, we generally used a spatial interpolation between stations.  In a recent workshop, Allison L. Allen of Center for Operational Oceanographic Products and Services stated that, absent VDATUM results, interpolation of "MTL to NAVD88" between stations is the best manner of determining the "MTL to NAVD88" correction.   

In SLAMM 6 the only difference will be that the VDATUM Raster import capability will be "published" that is to say, written up in the technical documentation and users manual.  Given the fact that VDATUM is now nearly ubiquitous throughout the continental US, I think this should solve the problem for the majority of our users. 

Dean, thank you very much for this.  I really like this idea for a thread as well.  I'll try to post some additional examples myself soon.  -- Jonathan

Pat wrote:

QuoteHi Jonathan!

I am starting a SLAMM project and want to construct a model in ArcMap
to at least output the ascii grids but hopefully more, like slope
conversion and the data join to the NWI.

Are there command line switches for setting parameters for the SLAMM
executable?

Cheers!

pat

My response:

Hello Pat:

There is a command line switch option for setting up SLAMM.  It is a new
feature and you need a new executable (attached)  Please see the
specifications including the URL below.

Also, a sample batch file is attached.

A reminder, version 6 will be available at the end of this month and
this version will have several new features as well as be fully
open-source.  Keep your eye on the SLAMM FORUM for more information.

Good Luck -- Jonathan

      Hello to all.

      Attached please find a version of SLAMM that works with a
      command-line input of a driving file.  An example of a "driving
      file" (infile_test.txt) and blank template (infile.txt) are also
      attached.

      Please use this URL:

      http://warrenpinnacle.com/prof/SLAMM/Slamm5.0.4.zip

      Some features and specifications:

            All GUI options on the main screen and GIS options screen
            that may be modified by the user may be modified in this
            input file.

            The name of the input file must be passed as a parameter to
            the slamm software (e.g. "SLAMM5.0.4.exe infile.txt")
            If there is a parse error, the software will raise an error
            pointing to the errant line

            If "Debug Mode" is set as true, the software will start up
            showing the user the selected options on the GUI screen.
            This allows the user to see that the parse is working as
            expected prior to executing the model.

            Otherwise the software will immediately execute the model
            with the options selected (without prompting) and the
            software .

            Procedural messages such as "your simulation is completed"
            have been suppressed.

            "Fatal" error messages are not suppressed so the user can
            see what went wrong.  These could potentially be written to
            a log file to avoid an iterative procedure from jamming up
            completely in a future version.  Hopefully, though, no fatal
            errors will be encountered in your use of the model.

      Also, I'm attaching a version of a site file that includes several
      new and optional parameters (such as max fetch threshold and
      overwash parameters).  See several emails copied below for more
      information on this.

      While I have tested the new capabilities several times, this
      version probably could benefit from more testing cycles; please
      let me know immediately if you notice any strange behavior from
      these new model capabilities.

      -- Jonathan Clough

I do have a SLAMM legend file but it may not be the format that you require.  (it is *.avl, or mwleg)

Here are the "standard" SLAMM colors FYI:  (they will be editable in SLAMM6)

This is hexadecimal RGB format.  See Delphi TColor format for more information.

  GridColors: ARRAY[Category] OF TColor
   = ($002D0398 {ClMaroon},    {DevDryland}
      $00002BD5 {ClMaroon}, {UndDryland}
      ClGreen,  {Swamp}
      $00005500, {CLWhite,  }{CypressSwamp}  {Darker Green}
      ClLime,   {InlandFreshMarsh}
      $00A4FFA4,{TidalFreshMarsh} {Lighter Green}
      ClOlive,  {TransitionSaltmarsh} {Lighter Teal}
      $00A6A600,{Saltmarsh }
      ClPurple, {Mangrove}
      $00B3FFFF,{EstuarineBeach}
      ClSilver, {TidalFlat}
      ClYellow, {OceanBeach}  {Lighter Yellow}
      $000059B3,{OceanFlat}   {Light Brown}
      $00FF80FF,{RockyIntertidal} {pink}
      $00FFA8A8,{InlandOpenWater} {light blue}
      ClBlue,   {RiverineTidalOpenWater}
      ClBlue,   {EstuarineWater}
      ClBlue,   {TidalCreek}
      ClNavy,   {OpenOcean}     
      $004080FF,{Brackish Marsh is Orange}
      $00006CD9,{Tall Spartina is dark orange, (Shows only when Requested)}
      $00004080,{Inland Shore is Brown}
      $00003E00,{Tidal Swamp is very dark green, almost black}
      ClWhite   {ClWhite   {Blank} );