Canal drainage area being passed to streams below intersection of canal

[Jdgilby]

Canals have an associated drainage area that is based off the reach of river they branch from. Everywhere canals intersect a stream that drainage area gets transferred to the stream reach below, potentially excluding small streams from having any dam capacity. Heres a good example of how big the difference can be.

[joewheaton]

@Jdgilby this is a really good catch. I moved it to a discussion because a) there was no action or verb in the issue to fix code, and b) it seems like @jtgilbert, yourself, @wally-mac and I need to discuss and decide what we think or want it to do, then c) assign the updating of BRAT code to fix. My questions from what you pointed out:

1. In your example above, I presume that the stream is draining up the page or north, and then it hits a canal that intersects it, and picks up the big drainage area, effectively jacking up the Qbaseflow and Q2 to the point there is no capacity in the same small stream?
2. Is this something "we do" in preparing our drainage area calculation or are we just inheriting this from the NHD+HR?
3. Do you have a sense as to how common this is?
4. Is there a difference in how it should handle this for low-flow calculations (may be appropriate in some instances to pick up bigger drainage area) vs. high flow (likely inappropriate)?
5. What do you think we want BRAT to do?

It seems to me that there are some very rare instances of canals that overflow into these channels when carrying flow (rarely flood flows), but if they are crossing a stream they likely just bypass it entirely? I'm guessing you think we should still have capacity downstream of this?

Once we hash this out, we can queue up a specific issue that references this discussion for a) what the proposed fix is, b) when we prioritize it (milestone) and c) who we will assign to do it with what budget.

[wally-mac]

@Jdgilby, yes, this is an important find. I was not aware that this was taking place. @joewheaton thanks for flushing out the questions. @Jdgilby I'm looking forward to seeing your answers to Joe's questions and deciding how to proceed on this.

[Jdgilby]

@joewheaton to answer your questions.

1. You are correct on this. The downstream network picks up the canals DA and jacks up the Q2 and QLow. However it looks like the limiting factor in capacity is not baseflow but limited by dam blowout because of the high Q2.
2. It looks like this is not something we are doing, rather it is taking those values from NHD+
3. I'm not sure how common it is, still looking into it. My guess is its only an issue in these big developed valleys where there are a ton of canals to begin with. Even here though in this HUC I have found areas where a canal intersects a stream and doesn't transfer its DA.
4. It appears for low flow its not changing it enough to matter, but that's just in this case, and it is a relatively low slope stream. Might be enough to limit capacity in higher slope streams. But once again it seems like this will generally be an issue in low slope areas so it might not matter.
5. Seems to me like we don't want canals to affect downstream. Seems like it would be a rarely if ever seen scenario where the canal is actually diverting more flow into a stream rather than taking it out. However I know there are instances where the flow leaves the canal and re enters at a lower point. Even in that case the affect would be as dramatic as this, this specific case streamflow is at least 7500 cfs higher than it should be.

[philipbaileynar]

My preference would be to avoid any kind of topological analysis (i.e. propagating values up or down the network) because:

1. it is error prone
2. it locks out users who possess reach networks without topology.

Is there a combination of NHD attributes where we can override the use of TotDASqKm in situ? For example, we could just use the hill slope drainage area (DivSASqKm) for all divergences:

reach_drainage_area = reach['DivDASqKm' if reach['Divergence'] == True else 'TotDASqKm']

This would solve a longstanding problem with the way that sqlBRAT incorrectly assigns drainage area to any side channel, not just downstream of canals.

[jtgilbert]

I like that idea @philipbaileynar simple but influential fix.

[jtgilbert]

Actually @philipbaileynar it doesn't look like that works because downstream of convergences the divergence code is 0 so you don't know if divergences happened upstream or not, but DA can still be altered. It actually looks like using the DivDASqKm field across the board may be the simplest solution. It basically makes it so canals don't influence the DA of streams they intersect.

[philipbaileynar]

@jtgilbert it would be a super quick experiment to run a single HUC that we have already run, but replacing DivDASqKm everywhere instead of TotDASqKm. This would provide some confidence that the only places that have changed are the places we want to fix.

[jtgilbert]

@philipbaileynar I can make the change on a branch and run the HUC in concern here to check it.

[jtgilbert]

@Jdgilby do you want to add here results from using DivDA. Benefits, drawbacks, any potential issues?

[Jdgilby]

From what I can tell it has solved the issue above as well as also solving the side channel issue. What is really cool is how much more accurate flows are when checked at a gage site below the canal diversions, where before they were super high. It basically accounts for an altered flow regime due to water management. Because of the routing/coding of the network, it applies return flow back to the network downstream and at that point TotDAsqkm = DivDAsqkm. So there shouldn't be any logic that needs to be applied. Issues might show themselves with future runs, but with this HUC(10190003) as example it appears to have done what we wanted it to.

[philipbaileynar]

This is exciting. The inappropriate side channel discharge has gnawed at me for a couple of years!

@jtgilbert and @Jdgilby when you get comfortable and want to proceed, please create a ticket for @KellyMWhitehead to revise the BRAT build step to include the NHD DivDAsqkm attribute.

[jtgilbert]

@philipbaileynar I already have a branch with the changes made, I could just PR after I've gone over and made sure I didn't miss anything.