Seperate wind into wind_onshore and wind_offshore

[wolfbunke]

For several reasons we should split the generator source wind = 13 in wind_onshore and wind_offshore.

• assignment onshore and offshore time series
• see impact of offshore production in the system
• ...

As fare as can see following tables need to be changed:

Tables:

• model_draft.ego_grid_pf_hv_source
• model_draft.ego_grid_pf_hv_result_generator
• model_draft.ego_grid_pf_hv_result_generator_t
• model_draft.ego_supply_pf_generator_single
• ...
  Scripts:
• ego_dp_powerflow_assignment_generator.sql
• ego_dp_powerflow_timeseries_generator.sql
• ...
  Please add missing tables and scripts.

What do you think?

[MarlonSchlemminger]

I agree that this should be implemented. It generally makes sense to be able to see the production split into on- and offshore and I had (and still have) some trouble during my work on #206 with only having "wind" as source.

[ulfmueller]

We used to say that the information about on- and offshore lies within the geometry of the plant. This applies to both of your mentioned motivations. The assignment of the time series depend on the location of a wind mill and respectively in which weather cell it is located. This is the same for the onshore power plant. So from a clear logical point of view the information mentioned is already there without the separation in two carrier types. Am I wrong?

Anyway if the adjustments are rather minor and without bigger effort doable I am ok with it.

None of the tables (you mentioned) need to be changed in structure. So only the scripts would have to be changed. There has to be adjusted (at least) one more script:
ego_dp_powerflow_hv_setup.sql
in this part the new source would have to be added: https://github.com/openego/data_processing/blob/master/dataprocessing/sql_snippets/ego_dp_powerflow_hv_setup.sql#L1499-L1518

[MarlonSchlemminger]

We used to say that the information about on- and offshore lies within the geometry of the plant. This applies to both of your mentioned motivations. The assignment of the time series depend on the location of a wind mill and respectively in which weather cell it is located.

Both the geometry and the generation subtype is neither available in ego_supply_pf_generator_single nor in ego_grid_pf_hv_generator. This makes it really hard to find out if a generator is on- or offshore, because you have to go really far back into the process to get these information. I think issue #222 made this clear as well, where you need to write complicated join statements for a rather simple information. I am generally a fan of doing things explicitly instead of implicitly and I don't see a negative impact of having on- and offshore seperated in all tables.

Specifically for the process in #206, we encountered problems where one weather cell on coastal regions would have both on- and offshore generators where the assignment simply by weather cell does not work.

[ulfmueller]

I am ok with it and I also see the advantage. I just hope the general logic is kept and no special (buggy) work-around is created. Just by the way, explicitly keeping information can also mean to create carriers such as southern, northern, eastern, western, big, small (...) 'solar' which would be not desirable... so I guess it is not a 'black or white' issue.

Do you consider this change then also for the neighboring countries? To be consistent the should be divided in off and onshore as well...

Is it all clear now or is there more need for discussion/clarification?

So in the ego_dp_powerflow_assignment_generator.sql the wind power plants will get with respect to the power plant location (or with respect to the generation subtype?!)an on or offshore source id which will be set in the generator_single table and then you can simply use that information for your assignment of time series?!

[MarlonSchlemminger]

I am ok with it and I also see the advantage. I just hope the general logic is kept and no special (buggy) work-around is created.

My goal is to increase the general logic and don't implement any work-arounds.

Just by the way, explicitly keeping information can also mean to create carriers such as southern, northern, eastern, western, big, small (...) 'solar' which would be not desirable... so I guess it is not a 'black or white' issue.

I think the differentiation between on- and offshore wind is reasonable without the need to differentiate between things like roof- and ground-mounted solar. Most studies seperate on- and offshore wind, whereas solar is just solar, so I think we are fine here.

Do you consider this change then also for the neighboring countries? To be consistent the should be divided in off and onshore as well...

This would definitely be my plan, yes.

Is it all clear now or is there more need for discussion/clarification?
So in the ego_dp_powerflow_assignment_generator.sql the wind power plants will get with respect to the power plant location (or with respect to the generation subtype?!)an on or offshore source id which will be set in the generator_single table and then you can simply use that information for your assignment of time series?!

I didn't put any work into the detailed implementation, it is more a general idea so far, so I can't say yet how much clarification I will need. The goal would be to make this based on the generation subtype. This looks simple because it is an information we already have and we could get new bugs if we make it based on the location.

I would first finish my work on issue 206 (hopefully until the weekend) and could then put more work into this issue.

[ulfmueller]

@IlkaCu but then due to the time plan this is probably not part of v0.3.1, right?
@MarlonSchlemminger Is it possible that the so far changes you made with the direct integration can be included but without this offshore onshore differentiation? or do we get a bigger 'error'/problem then?

[MarlonSchlemminger]

Yes I think we can include this, this is what I am currently testing.

[IlkaCu]

@IlkaCu but then due to the time plan this is probably not part of v0.3.1, right?

Would be nice to include these changes in the v0.3.1 version already. I will think about the adjustments we/I need to implement it in the DP and let you know tomorrow whether I think this is realistic in v0.3.1 or not.