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

Distribution of wind generators / wind dispatch in v0.3.2 #305

Open
jankaeh opened this issue Jul 11, 2018 · 6 comments
Open

Distribution of wind generators / wind dispatch in v0.3.2 #305

jankaeh opened this issue Jul 11, 2018 · 6 comments

Comments

@jankaeh
Copy link

jankaeh commented Jul 11, 2018

Hi, I use data from v0.3.0 with generators from v0.3.2 and clip foreign components. I overwrite wind on/offshore with wind. For 2011-09-14 12:00 I get this distribution of dispatch from a merit order simulation:
bus_shares_by_carrier_prob

The two biggest wind inputs confuse me. They don't reflect reality, do they? Do you get similar distributions, or did I mess sth up? (The big coal dispatch is the slack output from pf post lopf calculation)

@ulfmueller
Copy link
Member

Looks weird. But it would be good know about the order of magnitude. I would check the p_nom distribution of the wind power plants and see if those are realistic (maybe also check the p_max_pu, if they are reasonable). If yes, then of course it would be possible that in some hours it can make sense to dispatch cheap wind near to the demand more than in other less demanded or/and more restricted regions.

@jankaeh
Copy link
Author

jankaeh commented Jul 11, 2018

All generators with marginal costs = 0 dispatch at p_nom or p_max_pu*p_nom. Only one uranium generator dispatches in the sense of merit order. I'll investigate further when my simulations are done and let you know if I found a mistake I made or if this might be a bug.

@ulfmueller
Copy link
Member

ah ok your RE are not flexibly dispatched. Then it is definitely wrongly distributed. Is it possible that somehow your offshore wind is attached falsely? Since they are two and the order of magnitude looks a bit like that. I will check what happens if I use 0.3.2 as a consistent dataset... Btw: why dont you take the entire 0.3.2?

@ulfmueller
Copy link
Member

just to be fast. what start_snapshot you used?

@jankaeh
Copy link
Author

jankaeh commented Jul 11, 2018

2011-09-14 12:00 is the timestamp. I use quartals as datasets, so the integer index isn't the same but I guess 6192?
When I find the time, I'll switch to v.0.3.2 entirely. Oh I just realize there is a v.0.4.2 released... So I'll probably upgrade to that version soon.

@ClaraBuettner
Copy link
Contributor

I'm not sure how helpful this is for this issue, but I just committed a bug fix in etrago/.io, that considers the grid version of carrier. So you don't need to overwrite carries manually anymore when you update eTraGo.
openego/eTraGo@9daf093

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

3 participants