News:

Due to SPAM attacks, new members must be approved before posting.  Please email jclough@warrenpinnacle.com when registering and your account will be approved.

Main Menu
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Topics - Jonathan S. Clough

#21
Model Formulation & Parameters / Vertical Datums
November 11, 2009, 02:33:21 PM
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. 

#22
Using SLAMM / Command Line Option of SLAMM
November 05, 2009, 10:41:19 AM
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
#24
Model Formulation & Parameters / Accretion
April 24, 2009, 09:29:23 AM
Within SLAMM 5 The accretion model has been quite simple:  accretion rates for marshes may be spatially distributed at whatever resolution is deemed appropriate, but they do not change over time.  

Currently, under contract to TNC, the accretion model is being modified to allow for a more sophisticated approach.  The new approach will modifies a maximum theoretical accretion rate considering cell elevation, distance to channel, and salinity (if relevant).  In this manner, feedbacks to SLR will be possible to include in the accretion formulation.  More information about this model, as it continues to be derived and tested, will be posted here.




#25
This forum is designed to allow user feedback about model construction.  We welcome constructive criticism and especially individuals willing to point us towards new approaches that may be more general than what is currently in place.  I am hoping that through this forum the model can continue to evolve.
#26
Using SLAMM / SLAMM Users Guide
April 24, 2009, 09:25:52 AM
Hello:

In this topic, I hope to post some frequently asked questions about applying the SLAMM Model.  Please feel free to add a new topic if you do not see your question listed here:

GIS Projections:  It is recommended that an equal-area projection is utilized to avoid the potential for error in calculating surface area statistics.  

Site Data:

1.) I am having trouble understand the "water depth" input.  Could you clarify how one would develop this input?  In the documentation, you say "meters below MTL".  How would you estimate this?

This is not an important input to the model unless you are modeling a system in which sea level is falling.  We have not modeled such a site in many years.  (Projected Sea Level Rise almost always is greater than equal to projected rates of isostatic rebound)  To answer your question, though, this would be the depth of water two meters from shore (the depths in-between are interpolated.)  However, we haven't tested this accretion code in many years now.  Also, this should be replaced by code to read bathymetry data in the mid-term future.  You should find the model to be completely insensitive to this (vestigal) parameter.

2) We are having some trouble finding information on Mean High Water Spring.  Any thoughts as to the best source for this information.  The COOPS data does not appear provide MHWS.

This is an interesting issue.  In recent years and model applications I have replaced the concept of MHWS with the concept of frequency of inundation.  I usually define MHWS as the elevation above MTL that is expected to flood less than one time per month.  This usually lines up fairly closely with the dry-land/wetland boundary.  

"Spring Range" is available as part of NOAA tide table data.  However, this "MHWS" is actually the mean high water (not MHHW) on the dates of new moon or full moon and it is often quite close to the MHHW-MLLW range.  What we are really looking for is an elevation that floods infrequently enough so that we predict dry land above that elevation and wet lands below.  Based on consultation with wetland scientists a frequency of once per month was deemed as appropriate.  

You can use either NOAA tide predictions to try to derive this value or NOAA historic tide data.  Or, you can use a regional relationship, often something like 1.33 to 1.5 times the Great Diurnal Tide Range.

When the model is re-worked some of these parameters will need to be renamed for clarity sake.  (and some removed altogether!)

Frequency of Large Storms:  This parameter reflects the frequency of overwash for

Tide Range Inland vs. Tide Range Oceanic: These parameters were split up when the model was run with a single site record.  The inland tide-range reflects the tide range in a location where dry land is prevalent.  However, we generally keep these two parameters the same and parameterize gradients in tide ranges using the model's sub-site capabilities.

Do not forget that these "site" parameters can become "subsite" parameters by defining subsites in the set-map attirbutes mode.  Each of these parameters can be assigned to an individual polygon instead of a whole site.

Salinity Module:  


  • The salinity sub-model was written as part of the STAR grant as the original model was not working well when there was significant freshwater influence.   (Required as marsh-type is more highly correlated to salinity than elevation when fresh-water flow is significant, Higinbotham et. al, 2004)
  • We never originally had funding or scope to write the salinity portion of the model under STAR but managed to squeeze it in under the original scope.  The resulting model is therefore simple.  There are several nuances to applying this model (e.g. manner of defining estuaries and flow-vectors) that have never been adequately documented and are not likely to be so.  The salinity model is essentially unsupported by us at the current time (for use by other users than ourselves).
  • The salinity model does currently have funding to be significantly updated and refined under a TNC conrract.  That work is expected to be completed within the next six months.  Therefore, this "original" version of the salinity model is not expected to be fully documented or supported at any time as we are instead putting our efforts towards the refinement and documentation and support of that model.



#27
General Discussion / Introductions
December 05, 2008, 10:00:59 AM
Welcome to the SLAMM Forum! 

Our goal in creating this forum is to both provide the SLAMM user community a source for consolidated information on the model and to give the users a chance to voice their comments and concerns to one another.

If you are interested, please writing a short introduction about yourself and your relationship with the SLAMM model here.

Thanks!

The SLAMM Team