For a node: Total incoming water flow <water demand

[lzhangisu2011]

Not sure if this was raised as an issue before. If it is, we could probably merge the two issues together.

For the one-year (2002) dataset Justin sent to me. There is an issue with infeasibility, caused by miss-match of water flow balance. For example: the total water inflow for node D94 in 2002-05-31 is 252.711434, while the demand for that node >=257.570129.

All nodes flow into D94.2002-05-31:
i j k cost amplitude lower_bound upper_bound
SR_CLE.2002-05-31 D94.2002-05-31 0 -0.66193747 1 0 71.940552
SR_CLE.2002-05-31 D94.2002-05-31 1 -0.612051128 1 0 35.970276
SR_CLE.2002-05-31 D94.2002-05-31 2 -0.589825833 1 0 35.970276
SR_CLE.2002-05-31 D94.2002-05-31 3 -0.56539109 1 0 35.970275
SR_CLE.2002-05-31 D94.2002-05-31 4 -0.535293252 1 0 35.970276
SR_CLE.2002-05-31 D94.2002-05-31 5 -0.48653858 1 0 35.970276
INFLOW.2002-05-31 D94.2002-05-31 0 0 1 0.919503 0.919503

All nodes flow out of D94.2002-05-31:
i j k cost amplitude lower_bound upper_bound
D94.2002-05-31 SINK.2002-05-31 0 0 1 257.570129 1000000000
D94.2002-05-31 SR_WHI.2002-05-31 0 -24.91741804 1 0 203

This is not the only node. My model also showed C35 as another node with similar issue, but I am not sure if those are the only two nodes.

Any idea why this is happening? How to fix this?

Thanks,
Leilei

[msdogan]

Thanks @lzhangisu2011 for opening this issue.

Since there are 4 links (2 incoming and 2 outgoing) connected to D94, here are all possible combinations of issues:
1- We messed up with capacity constraint on release or piecewise cost representation on SR_CLE to D94.
2- Inflow to node D94 is not correctly represented.
3- Link D94 to SINK, which represents minimum in-stream flow requirement. It is possible that there is a problem with lower bound of that link.
4- Finally, Link D94 to SR_WHI has a hydropower benefit. So, I need to check to see if it is correctly represented.

I will check those, compare to base CALVIN model and post my findings here.

[msdogan]

Okay here are the results:

• INFLOW.2002-05-31 D94.2002-05-31 0 0 1 0.919503 0.919503 is okay
• D94.2002-05-31 SINK.2002-05-31 0 0 1 257.570129 1000000000 is okay
• SR_CLE.2002-05-31 D94.2002-05-31 is okay
• D94.2002-05-31 SR_WHI.2002-05-31 is okay

This is a very interesting case. Everything comply with what we have in CALVIN. However, one thing is that we do not impose a physical upper bound on SR_CLE-D94 in CALVIN. This might be causing a problem.
I am not sure how HEC-PRM found a feasible solution for this case.
@jdherman as you noted earlier for this example. Sum of all upper bound pieces on SR_CLE-D94 plus INFLOW-D94 is less than outflow lower bound on D94-SINK in network export.
Following is output from CALVIN solution file. Looks like Flow on SR_CLE-D94 exceeded piecewise cost imposed upper bound.

Time    D94-SINK    D94-SR_WHI  SR_CLE-D94  D94
31May2002   257.57  0.00    256.65  0.9195

[jdherman]

Do you think the bound errors are the result of the piecewise curve extensions? -- maybe this is this a continuation of #36

[msdogan]

@jdherman yes, I think this is a continuation of #36 We need to revisit our extension logic. You know for some extension types we didn't match it with what HEC-PRM does. Maybe we should not do that. I will post my suggestions and let's discuss in #36