Jump to content
GMS, SMS, and WMS User Forum
Sign in to follow this  
disgreen

Deleting Depression Polygon Mask

Recommended Posts

Hi,

This is a follow-up to a questions I asked previously. I have a model for which landscape depressions have been successfully masked and so are skipped over during the clean dams routine. However, for the purpose of run comparisons, I'd like to remove the polygon mask layer from my GSSHA model so that these features are filled while running the clean dam proceedure. It's not clear how this can be done easily. I've gone through the process of selecting the polygons using the select polygon tool in the map module and deleting these from the GSSHA coverage (I think). However, when I run clean dam, the output shows that numerous dams are still being ignored because of a depressional mask. How can I remove these masks without reconstructing the entire model from the raw DEM? Thanks.

David 

Share this post


Link to post
Share on other sites

David,

You can have multiple GSSHA coverages and multiple GSSHA models in your WMS project.  I'd recommend duplicating your existing GSSHA model (just right-click on your GSSHA model).  Then duplicate your GSSHA coverage and delete any depression polygons in this coverage.  Then assign the GSSHA coverage with the deleted polygons to your model.  You should be able to run cleandam with the coverage/model containing the deleted polygons and it should not include any depression cells in your cleandam run (all the cells should be filled).

Let me know if you have any other problems.

Chris 

Share this post


Link to post
Share on other sites

Hi Chris,

Thank you for the reply. Your answer makes complete sense and works. Also, I have a question about tile drainage networks as conceptualized in the SuperLink model.  According to Downer et al. (2014) the drainage spacing defines the lateral distance between parallel pipes. This parameter is a bit odd considering that individual pipes are represented by unique arcs in WMS and GSSHA. Does specifying a non-zero drainage spacing in WMS implicitly place additional pipes parallel to the primary pipe at the specified spacing, or does this parameter place pipes perpendicular to the primary pipe at the specified interval? Or, neither? Should I start a new topic, or can this be answered in this thread?

Thanks again for all of your help. 

David

Share this post


Link to post
Share on other sites

David,

That's a good question, and I don't fully understand the answer right now.  I do know that it is only used for tile drains and doesn't apply if you're modeling normal underground drain pipes (storm sewers).  I talked to the original programmer (Nawa) about it and understood the answer at one point, but the complete answer has left my mind.  I asked Chuck Downer, the writer of GSSHA about it and here's what he says:

"It has to do with the assumed shape of the curve for the water surface flowing into the pipes, assuming you are doing drains.  It doesn't actually add pipes.  It comes from the two pipe drain models that in GSSHA, Cooke and DrainMod.  Those are computations for the pipes only.  Those methods are described in that report.  Since GSSHA is integrated the ground water surface is being computed, so I guess you don't really need this in GSSHA but we'd have to re-derive a formula.  These are standard formulas.   I don't know how sensitive the model is to the parameter.  It might not matter a lot.  I don't think you can put zero.  I'd say if there is some pipe spacing in the fields just use that.  Typically there is.  Otherwise, probably make it on the larger side."

I found a Technical Release paper describing this "L" parameter in some detail here:

https://www.researchgate.net/publication/268076111_Modeling_Subsurface_Storm_and_Tile_Drain_Systems_in_GSSHA_with_SUPERLINK

(This may be the same paper you were referring to above)

So my understanding is that you would put your pipes in the GSSHA Storm Drain coverage where they actually exist and then enter an approximate spacing of the pipes in this "Drain spacing" field.

Chris

Share this post


Link to post
Share on other sites

Chris,

Thank you for looking into this. The paper you linked to is the one I referenced in my question, and unfortunately doesn't really clarify the meaning of the L parameter in the context of explicitly and spatially defined arcs. I'll likely use a value of 1 since both drawdown formulations have L in the denominator and because my tiles are explicitly defined. My guess is that GSSHA will either encounter an internal computational INF error or produce numerically unstable results if L is zero.

Thanks again. I really appreciate your help.

David

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×