Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Defining by nature "control" variables as "state" variable on the scenario tree #645

Closed
bitanalui opened this issue Jul 26, 2023 · 4 comments

Comments

@bitanalui
Copy link

I am solving a Multistage Stochastic Optimization problem, for dynamic cascade reservoir optimization. To incorporate non-anticipativity, release (control variable) needs to be decided prior to the realization of inflows at t, that is nodes belong to period t-1 . It is suggested to treat release as state variable.
Is this implementation correct?

@variable(subproblem, release[r=1:6] >= Cascade_system[r].release_min, SDDP.State, initial_value = Cascade_system[r].release_initial)

and then it appears in the following constraint:

@Constraints(subproblem,begin
storage_equa[r = 1:6],
storage[r].out == storage[r].in + (inflow[r] + sum(release[j].in*A[r,j] for j=1:r))*1.9835
end)

release[j].in is the release at node that belongs to period t-1.

@odow
Copy link
Owner

odow commented Jul 27, 2023

Without the full details, hard to offer advice. But seems correct.

See https://odow.github.io/SDDP.jl/stable/guides/access_previous_variables/#Access-a-decision-from-N-stages-ago

One thing you need to be careful of is that stage t is feasible for any release that might be chosen in stage t-1.

@bitanalui
Copy link
Author

Hello Oscar,
Thank you, by full details do you mean the complete model?
Here I am attaching a complete model with a small input file.
With the balance constraint as formulated with release[j].in we face infeasibility issue.
ControlvsStateVariable.zip

@odow
Copy link
Owner

odow commented Aug 2, 2023

Closing because it seems like @bitanalui and @bolbolim are the same people, and because the infeasibility is likely the same as #646.

Let's keep the discussion to a single post please.

@odow odow closed this as completed Aug 2, 2023
@bitanalui
Copy link
Author

Hi Oscar, we are not the same people, but we are trying to address and solve two issues of one model.

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants