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

Connectivity and Model Settings

Started by cpapiez, October 20, 2010, 02:24:43 PM

Previous topic - Next topic

cpapiez

I am wondering about the model parameters when I run salinity Connectivity function.  Should I keep all the model parameters the same assuming they all affect the connectivity output, i.e. Include dikes, no-data elevs loaded as blanks, use soil saturation, and protected developed.  Would more salinity intrusion occur if I did not include dikes?

When I run the connectivity function I ask the model to pause with examination tools, but I've run into some error with this.  I have found that I need to uncheck the IPCC scenarios when running connectivity for a custom scenario otherwise the connectivity will only run the IPCC scenario and give me an error when I ask it to give me the next scenario.

Is there any way to have the connectivity saved as a GIS output instead of pausing the model run and taking a screen print (jpeg)?

Chelsie

Evan Larson

The connectivity feature is an attempt to make the inundation for each time step more realistic, but it is unrelated (as far as I know) to our salinity model.  With the feature turned off, the model works by inundating every cell that lies below a certain elevation value, regardless of land features which might prevent such inundation (high walls, dikes not designated as dikes in the dike file, etc.).

With the feature turned on, a search is performed at each cell to determine whether or not it could be inundated based on surrounding cells' elevations.  The cell determines whether it is below the current sea level, and if so tests whether or not it is ultimately "connected" (hence the name) to a cell that is flooded.

Using connectivity with dikes turned off may be a fun (although not necessarily scientifically defensible) way to test the efficacy of the dikes, assuming you are working with a high resolution elevation map that accurately represents the dike wall.  One little breach in the dike wall -- or more likely an error in the elevation data -- will lead to inundation. 

Note that more memory is required to run the connectivity feature.

What is the language of the error you receive and what are the exact steps leading up to it?

There is currently no way to save the connectivity raster as an asci file.

Hope this helps,
Evan

Jonathan S. Clough

Thanks Evan.  Yes please do document any SLAMM errors that are reported and whether they are reproducible.  If so, I should be able to fix the offending portion of the code.

katerinapyl

very helpful post but I was wondering which are the criteria to determine a cell "connected" to a cell that is flooded (for example it must be the next cell?)

You also mentioned that connectivity can be used (with dikes turned off) to test the efficacy of the dikes.  Does that mean that it checks if the dikes will be overtopped? (In my case the dikes are not very well depicted in the dem so i cant check this).
However, in the technical documentation is mentioned that dike overtopping occurs when the relative slr is more than 2m.  I run two simulations (one with the connectivity algorithm and one without it) under a custom 3m SLR by 2100 but the diked areas in both cases are not changed.

Thank you in advance
katerina

Jonathan S. Clough

The connectivity algorithm uses an "eight sided fill" function to find a group of cells that are below the salt elevation.  If it also finds open tidal water then cells are are assumed connected to tidal water.  If it finds a connected group of low-elevation cells, but no open water, then those cells are assumed not connected -- water cannot reach these cells.

We may have some additional written text about connectivity that we can share with you.

We have stopped using the simple 2 m assumption for dike overtopping for the most part.  This assumed a diked cell would be flooded if its elevation reached an elevation of negative 2 m relative to MTL.  For the most part, this meant that diked cells were not assumed to be overtopped in all scenarios we ran.  This assumption will be removed from the next version of the model.

Since this thread was created we have added the capability to import dike heights as well for a more sophisticated dike overtopping analysis.  This has replaced the earlier simplification if a dike-overtopping analysis is desired.