Calculate grid expansion costs

[birgits]

• Costs have to be added to configs
• method to calculate costs has to be implemented (be careful to not count costs twice when component was expanded in several steps)

[birgits]

@nesnoj would you add the equipment costs to a config file, maybe the flexopt config or a new costs config?

[nesnoj]

Could you please specify which components you need costs for? E.g. just costs for each of the standard equipment in config_flexopt_default.cfg?

[birgits]

I need costs for all equipment used in dingo, since the first expansion step is usually to build a parallel component of the same kind, plus all standard equipment. @gplssm and I decided yesterday to for now have a new config holding all costs. After we finish the first grid-expansion-in-all-distribution-grids round we wanted to maybe rethink the edisgo input structure, but for now it has to work quickly... I planned to setup the new config and import it to the network object today if that is okay with you?

[nesnoj]

Is this done?
Otherwise I could do it right now..

[nesnoj]

Done in 020ea0a in dev.
Get values as usual via network.config[<category>][<equipment name>] (see new config file config_costs_default.cfg)
All costs are currently set to 0, please fill..

[birgits]

Thank you @nesnoj! One minor thing - right now the costs can be found under network.config['lv_cables'], network.config['lv_transformers'] etc. I think it would be easier to have network.config['costs'] and have all costs there or maybe one more level like network.config['costs']['lv_cables']. What do you think?

[nesnoj]

Unfortunately, configparser does not support subsections that could be used like config[x][y][z].

I see 3 options to solve this:

1. Add new parent section during import to allow getting values via config[x][y][z]. This sounds nice, but messing around with the config structure makes it hard to understand for users (they couldn't simply lookup a call from the source in the config since it is restructured)
2. In general, the structure network.config['costs']['lv_cables'] is possible, but only with 'lv_cables_XXX as key, so you will have to call it like network.config['costs']['lv_cables_NAYY 4x1x300'] - I guess that's not what you want?
3. Rename sections (add prefix), e.g. lv_cables -> costs_lv_cables

I prefer option 3 to keep it simple. What do you think?

[birgits]

Option 3 is fine. For me it would also be sufficient to just have a costs section without further specification.

[nesnoj]

Done.
Without this specification we might run the risk of mixing something up?! (if types from diff. sections have the same name)
Hmm, quite unlikely but possible..

If it makes it much easier for you not to have to specify the section we can kick it..

[birgits]

It's no problem for me, I just didn't think there could be duplicate names.

[birgits]

Concerning the equipment costs to calculate grid expansion costs I had a look at the following 3 studies:

[1] consentec 2006 S. 113/114
https://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/Sachgebiete/Energie/Unternehmen_Institutionen/Netzentgelte/Anreizregulierung/GA_AnalytischeKostenmodelle.pdf?__blob=publicationFile&v=1

[2] VNS BW S. 91
https://www.baden-wuerttemberg.de/fileadmin/redaktion/m-um/intern/Dateien/Dokumente/5_Energie/Versorgungssicherheit/170413_Verteilnetzstudie_BW.pdf

[3] DENA VNS S. 146/147
https://shop.dena.de/fileadmin/denashop/media/Downloads_Dateien/esd/9100_dena-Verteilnetzstudie_Abschlussbericht.pdf

[1] has a list of costs for different types of cables and transformers as well as earthwork costs for different territories (though they're from 2006 and thus a bit old). While earthwork costs range between 23-87 kEUR, cables costs only range between 3-15 kEUR (with costs for standard line NAYY 4x150 of 9 kEUR). [2] and [3] don't differentiate between different line types but only different territories ([2] rural, suburban, urban and [3] less/greater 500 inhabitants/km2).

Considering that earthwork costs make up most of the costs, that we don't have an up-to-date source for cable costs and that [2] and [3] do it that way I would suggest, that we too don't use different line costs for each line type. @nesnoj, @jochenbuehler, @gplssm do you agree? The next question is if there is a way for us to appoint different earthwork costs. Any suggestions?

[nesnoj]

Concerning your questions:

• I propose to use the same methodology as in [3] (depending on pop. density).
  You can easily calculate the population density by population and geom. For area calculation, you could do it the same way as in dingo, see here. Caution: You must use an equidistant projection (we always used ETRS) to get km^2 and not °^2.. I'm not sure which projection is used in the geom (either conformal WGS84 or ETRS), please check..
  @gplssm: where is the geom of former MVGD stored? Didn't we plan to use Network's _metadata attribute for stuff like this?
• I wouldn't worry too moch about cable costs since they only make up 10..20 % according to these studies.
• You only use cables for reinforcment, right? If you would use overhead lines, the old poles might be reused..

BTW, I've got one more study on asset costs:

[4] FFE 2016 S. 89
https://www.ffe.de/download/article/630/20160831_GE_02_Endbericht_Smart_Grid_Controller_final.pdf

They list earthwork costs of 40..100 kEUR/km and overall investment (earthwork+cables) costs of 50..90 kEUR/km depending on territory (same types as in [3]). They also provide exact costs for some specific cables+trafos.

[birgits]

Thank you @nesnoj, I'll implement the calculation of population density and adapt the cost config!

[birgits]

Since I couldn't find any transformation of the geometry in the importer from dingo and calculated population densities seem plausible when using WGS84 as projection of geom (stored in grid_district attribute of the grid) and converting it to ETRS I would say geom in edisgo is in WGS84. I also found this in the misc config. I thought it would be best to store the information on which projection is used directly in the shapely object but couldn't find the right attribute for it. Do you anything about this @nesnoj or @gplssm?
One more question - does the geometry give me the supplied area (versorgte Fläche) or the geographic area? As far as I could find DENA doesn't specify which area they are using so it doesn't really matter, but I'd just like to know.

[nesnoj]

We had the same issue in dingo but it's still unsolved: openego/ding0#38 and openego/ding0#62
To be safe, we always transformed the geom to WGS84 and if we needed equidistant data (as in this case) we transformed to ETRS. So yes...now I remember...always WGS84 :)

(note: You can easily see if a conformal (WGS84) or equidistant (ETRS) is used by looking at the geom's dimension: <90/180 (WGS84->degree) or >>10^3 (ETRS->meters)).

As you have noticed, the config_misc.cfg contains the CRS used by eDisGo to store geoms. I'm using it to transform geoms during import (e.g. here).

I think it's a good way to always use only one (the one from config) CRS for our geoms, thus we do not have to store it in an attribute. What do you think?

One more question - does the geometry give me the supplied area (versorgte Fläche) or the geographic area?

The geographic area of the entire MVGD.

EDIT: You may try it this way and if you realise that most of the MVGD show a pop. density of <500 we should test the other version (cum. area sum of all load areas) - you may create an issue to make sure we won't forget about it?

[birgits]

I'll close this issue but feel free to reopen it if I missed anything!

[nesnoj]

As written in the mail yesterday, new cables which were laid during generator connection (#21) have to be considered in the grid exp. costs.
I had a quite long discussion with @gplssm on this is the way how I'll solve it:

1. Always use standard cables to connect genos, pass the data on installed cables to the grid expansion part.
2. If grid exp. detects current or voltage violations on these lines, do regular reinforcement. In this case, the costs for regular reinforcement are the total costs --> costs of step 1 have to be neglected (otherwise we'd have both, installation+reinforcement costs!). If no problems occur, take costs from 1.
   @birgits: Do you have time for this?

@birgits: Where and in which format do you want me to provide the data? Same DF as in Result's equipment_changes()?
I guess we either need an additional flag in your DF (e.g. TRUE, if cable was laid during a previous process -> please also think of other non-generator-related scenarios such as additional loads which could have been connected after import but prior to reinforcement) or a separate DF. What do you prefer and where am I to store it?

[birgits]

If grid exp. detects current or voltage violations on these lines, do regular reinforcement. In this case, the costs for regular reinforcement are the total costs --> costs of step 1 have to be neglected (otherwise we'd have both, installation+reinforcement costs!). If no problems occur, take costs from 1.

I don't quite understand - you want to add the costs of the first step where you add standard cables to connect new generators to the total costs, right? If the standard line needs to be reinforced, meaning a parallel line is installed, we have to consider both the costs for the installation and the parallel line. Neglecting the costs of step 1 would not be correct I'd say. But we should not consider the earthwork costs twice, that's right. I noticed that mistake in the cost calculation the other day but have not fixed it yet. The thing is that we use costs from DENA but they only give total costs for cable and earthwork and no separate costs for the cables themselves. We could use costs from consentec or FFE for that?

Where and in which format do you want me to provide the data? Same DF as in Result's equipment_changes()?

That would be best. Everything in that dataframe is automatically considered in the total costs calculation.

I guess we either need an additional flag in your DF (e.g. TRUE, if cable was laid during a previous process -> please also think of other non-generator-related scenarios such as additional loads which could have been connected after import but prior to reinforcement) or a separate DF.

If the costs for connecting new loads and generators need to be considered in the total costs we can keep everything as it is without a flag I think. What do you think @nesnoj?

[nesnoj]

Yes, I'm gonna use standard cables only. Hence, line congestions / voltage violations may occur.

I don't quite understand - you want to add the costs of the first step where you add standard cables to connect new generators to the total costs, right?

Yupp!

Neglecting the costs of step 1 would not be correct I'd say

You're right, I wasn't thinking of parallel lines but replacement only.

We could use costs from consentec or FFE for that?

Sounds reasonable. I'd prefer consentec since it was conducted for the BNetzA.

If the costs for connecting new loads and generators need to be considered in the total costs we can keep everything as it is without a flag I think. What do you think @nesnoj?

Don't you need the information if this cable was laid in the geno/load/whatever connection process (and not in dingo)? Or is it sufficient to just add the costs to the DF? (If yes, I assume you search your DF for previous measures if you have to reinforce it?)

[birgits]

Don't you need the information if this cable was laid in the geno/load/whatever connection process (and not in dingo)? Or is it sufficient to just add the costs to the DF? (If yes, I assume you search your DF for previous measures if you have to reinforce it?)

The information how many new lines were added in an iteration step is in the quantity column of the equipment changes dataframe. So you just need to add one standard line to the dataframe and the rest is taken care of in the grid expansion part and the costs calculation (here the number of added lines for each line instance in the dataframe is added up and if it's not the same as the number of lines stored in line.quantity I know that one standard line was already installed in dingo).

[nesnoj]

@birgits Do you exclude lines which connect agg. units (genos/loads) from grid expansion (costs)? I assume you don't, since I couldn't find any usages of lines_by_attribute('line_aggr') in your code.

This leads to reinforcements in aggregated genos which were

1. imported from dingo
2. newly created

For 2., I use the max. available line type #71 to make sure there won't be any load/voltage issues. But to conform it to 1. I rather had to use the standard cable (+add to equipment_changes) which may subsequently be reinforced, right?

This leads to the general question, whether we want to include reinforcement costs to connect agg. genos or not, even though we neglect costs for MV cables within the agg. LA.

[birgits]

I didn't know that I should exclude those, sorry... Maybe we could discuss tomorrow whether or not we think those costs should be neglected. I can't really decide without hearing your arguments.

[nesnoj]

mkey

[gplssm]

We can discuss tomorrow. From a sales point of view I way recommend we exclude grid extension cost of aggr. LA entirely. Having these partially included does not help that much. But, reinforcing 1 m of cable for each aggregated PP does not affect total cost too much...

[birgits]

I excluded line costs for lines connecting aggregated units :)