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

committable generator constraint fails when min_up_time exceeds length of snapshots #124

Closed
2 tasks done
camiloromers opened this issue Jan 16, 2020 · 10 comments · Fixed by #128
Closed
2 tasks done
Assignees
Labels

Comments

@camiloromers
Copy link

camiloromers commented Jan 16, 2020

Checklist

  • I am using the current master branch or the latest release. Please indicate:
  • test whether potential bug persists for more than the one snapshot @camiloromers.

Describe the Bug

When I try to run a OPF using the network folder attached below I got the following error:

ERROR: Rule failed when generating expression for constraint
    gen_up_time_force_0 with index 1: IndexError: index 1 is out of bounds for
    axis 0 with size 1
ERROR: Constructing component 'gen_up_time_force_0' from data=None failed:
    IndexError: index 1 is out of bounds for axis 0 with size 1

May I know what's missing in my network or any clue relating the error I am getting?

Thanks for your help.

[L2RPN_2020_ieee_118_pypsa.zip](https://github.com/PyPSA/PyPSA/files/4071575/L2RPN_2020_ieee_118_pypsa.zip)

@FabianHofmann
Copy link
Collaborator

FabianHofmann commented Jan 18, 2020

Hey, I would not directly claim it a bug.

The error comes from having a network with one snapshot while ramp limits are given. This collides in the lopf. I think it makes sense to make an assertion for this case. Can you please test it for more than the one snapshot?

@camiloromers
Copy link
Author

Thanks for your help. I will test it.

One adicional question please. When you run a linear OPF given n snapshots, you are running n independent optimizers or it is just one in the whole space of the snapshots?

@fneum
Copy link
Member

fneum commented Jan 19, 2020

network.lopf() will formulate a single optimisation problem including all snapshots of the network to include time-coupled constraints due to storage units or stores. If you want to solve an operational problem (i.e. no capacity expansion) and do not have storage units or stores, you can also run the optimisation for each snapshot individually. Pass the relevant snapshot via network.lopf(snapshots=network.snapshots[0]).

@camiloromers
Copy link
Author

Thanks for your feedback. I tested my grid with more than one snapshots but I am having same issue. Any other clue?

@FabianHofmann
Copy link
Collaborator

weird... can you send the network (with multiple snapshots now) again?

@camiloromers
Copy link
Author

camiloromers commented Jan 20, 2020

Here you have it again.. Am I doing something wrong when I model my grid? .... Thanks for your support.

ieee118_pypsa.zip

@camiloromers
Copy link
Author

I was running some other tests and I found the variable which is causing problems are min_up_time and min_down_time. How they are linked with up_time_before and down_time_before? Apparently something is missing in the last variables when `min_up/down_time are set up.

@FabianHofmann
Copy link
Collaborator

Actually, the min_up_time for some of your generators is longer than the number of snapshots:

gen_72_31     576
gen_64_26    2016
gen_89_40    2016

This fails at a specific point in the assignments of the constraints. Can you clip your min_up_time to the length of snapshots. Like this

n.generators.min_up_time.clip(upper=len(n.snapshots), inplace=True)

@FabianHofmann FabianHofmann changed the title Got error when running opf committable generator constraint fails when min_up_time exceeds length of snapshots Jan 24, 2020
FabianHofmann added a commit that referenced this issue Jan 24, 2020
@camiloromers
Copy link
Author

camiloromers commented Jan 24, 2020

It fix my problem... Thanks a lot

@fneum fneum reopened this Jan 24, 2020
@fneum
Copy link
Member

fneum commented Jan 24, 2020

Keeping it open as this case should be caught in the code. Cf. ongoing pull request #128.

FabianHofmann added a commit that referenced this issue Jan 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants