Hi,
first of all, all the results will have your starting date as the wetland layer initial date. So, for what concerns the SLR, the actual sea level increase is from the SLR scenario curve selected but only from the initial date of the model (2012 for you), e.g. if you select 1 m SLR scenario you will have 0 m SLR by 2012 and 0.8841 m SLR by 2100, calculated by rescaling A1B-Maximum (see Technical Documentation).  

In your case, your actual SLR curve cannot be included at the moment. However, you can select custom scenarios for studying a scenario that has same overall SLR change by 2100 but uses A1B-max as base curve. As an example, if you want to see x=CanadaSLR2100-CanadaSLR2012 you have to input x/0.8841, e.g. if you want to study the case of 1 m SLR between 2012-2100, you have to input 1.131 m.

Hope it helps and good luck,

The small size of the study area and the small number of land cover types present should not be a problem when running SLAMM.

The comment from the other thread referred to crosswalking to fewer land cover types with different land conversion rules. 

Uhmmm ...

then I would check if there is a problem with the values of some cells, e.g. wetland cover number should be either the assigned nodata value or an integer from 1 to 26.

Considering that you had previously a problem with the slope raster, I would start with it and make sure that the values are nodata or 0 to 90 degrees.  

Hope it helps.

Marco

Assuming that all the rasters have same number of rows and columns, most probably the error is because you need to count again the cells to track (in the file setup window) before executing the model.

Hi Elena,
I could not reproduce your problem. One possible explanation of your results is that the turbidity factor in the fresh flow parameters is used and set to zero (or a very small number). In fact, as it is described in the users manual, if the turbidity factor is used, then the actual accretion rates in the fresh flow areas are given by the nominal values multiplied by the specified turbidity factor.

If that is not the case then I would be happy to have a look at your project and see if I can identify the cause.

Marco

Hi Caroline,
the ASCII output files are already rasters. They are in ESRI ARC/INFO ASCII GRID format and you should be able to open them with any GIS software. The only thing you need to do is to set the color map you prefer for visualization (e.g. using same colors of SLAMM).

Best,
Marco

Hi Caroline,
I am not sure I have understood what you have done. I can see that you have lowered your initial salt elevation but that was not enough. However, it is not clear what you have done with the preprocessor. It seems that your data are LiDAR, therefore the pre-processor should be turned off. Also, I am not sure what the value 2 m refers to.

Another analysis you can make to estimate your salt elevation is to use historical daily inundation data. Based on our experience, "salt elevation" may usually be defined as the elevation that is expected to flood at least once per month. This frequency of flooding information is usually available from local NOAA tide gauges.

In any case, when you make a choice for your parameters, I would say that it is acceptable as long as it is defensible (e.g. literature, somebody expert, people knowing the area telling you that these low lines are actually flooded frequently, etc.).

Hope it helps,
Marco

 

Hi Elena,
the elevation analysis is done with respect to MTL. Therefore it implicitly accounts for spatially varying MTL-NAVD88. However, in the new SLAMM version the user can also select the zero reference to be NAVD88 (absolute elevation) or MTL, MHHW, MLLW (relative elevations that may vary spatially). In addition, statistics is shown in HTU (or also in absolute meters in the new version) meaning that each elevation is normalized by dividing it by the local, possibly spatially variable, half tide range.   

Thanks for the suggestion. Actually, allowing the user to run elevation analysis only for a specific subsite is a feature currently under development.

Marco

Hi,
if with Aspect you refer to the horizontal direction to which a mountain slope faces, then SLAMM does not use it.

The input parameter slope is usually derived from the DEM data by looking at the elevations around but there is no direction associated with it. It is used to estimate the minimum and maximum elevations of a particular cell.

Hope it helps,
Marco

Hi Lindsey,
it really depends on the salt elevation assigned for the area and the elevations connecting the dry land cells to the open water.

You can look at connectivity and elevation maps at 2100 to better understand where the water is coming from (or not coming at all) using the SLAMM Map Menu (or save the elevation rasters).

In addition, for SLAMM regularly flooded marsh can only convert when drowning but it continues to exist even when its elevation goes above being regularly flooded (for example with a very high constant accretion rate ... a more realistic model is to set the accretion rate as a function of the elevation, see the technical documentation). 

Marco

Hi Lindsey,
I believe that what is happening is the following.

When connectivity is on, SLAMM looks also if the cell is connected to open water and not just if it is below a reference elevation (e.g. below salt elevation). In other words, if there is a mountain in between, water will not be able to inundate the cell even if it lies below the water line.   

Therefore, in the first simulation, the dry land becomes connected to water through some paths that were initially occupied by the marsh and now have fallen very low in the tidal frame. Accretion in this case is not able to keep up with SLR.

In the second case, since the salt marsh is accreting at a rate that is comparable to SLR, water does not have a path to reach the dry land. In fact, the marsh continuously builds up enough elevation to act as a "protecting dike" for the land behind. This is also confirmed by the fact that around the dry land the marsh area remains regularly flooded and is not converted to tidal flat meaning that its elevation with respect to MTL is still high enough.

Hope it helps,
Marco

Hi,
the historic SLR is the locally measured SLR rate. Therefore it includes the eustatic SLR and subsidence/uplift rates.

When modeling future SLR scenarios, SLAMM first derives local subsidence/uplift by subtracting the historic eustatic trend (1.7 mm/yr) from the historic local SLR, and then it adds local subsidence/uplift to the future eustatic SLR. You can look the technical documentation for additional information.

The non null and positive value of the dike grid file is the elevation assigned to that particular cell, no matter the value from the DEM. In other words, if the cell area is covering the dike, its assigned elevation is from the dike grid file, otherwise it is from the DEM. If your dike heights data are from the ground level, then you should first add the elevation of the ground (may be from the DEM) so that dike elevations are from MTL and then  create a new dike grid file.

Once the elevations are assigned, for all non dike cells the usual elevation adjustments occur to refer elevation to MTL, account for subsidence, historic SLR, etc.

In the next release the dike elevations will be referred to NAVD88.

Hope it helps,
Marco

Thanks Elena,
I will have a look at the code on what is happening by selecting the different zeros. In the meantime, if you want to try, you could change all the no data values from -9999 to 999 and that may solve it for now. I will get back to you next week.

Hi Elena,
the latest 64bit version should have fixed this problem and exclude the nodata elevations from the statistics. It is a possibility: are you sure that in the elevation raster, the no data elevation is set to -9999? That should be written in one of the first lines of the raster file. You can open it with notepad (if it is not too big) or notepad++ or preview it if you change the file extension to txt. Otherwise you can send me an email if you still observe the problem.

Hope this helps