Improve equivalent transformation calculations in base.nc

[ekatef]

A suggestion on a possible to partially address #862 and #887 to decrease errors introduced by base.nc.

Changes proposed in this Pull Request

Currently, we are using voltage rebase in base.nc which purpose is to map all the voltages to a few "standard" values. However, information on the original voltage is lost during this rebase transformation.

The suggestion is:

1. keep the original voltage before mapping the voltage;
2. adjust num_parallel for the lines after the voltage rebase to compensate an effect of the voltage increase on the transmission capacity introduced during rebase.

Checklist

• I consent to the release of this PR's code under the AGPLv3 license and non-code contributions under CC0-1.0 and CC-BY-4.0.
• I tested my contribution locally and it seems to work fine.
• Code and workflow changes are sufficiently documented.
• Newly introduced dependencies are added to envs/environment.yaml and doc/requirements.txt.
• Changes in configuration options are added in all of config.default.yaml and config.tutorial.yaml.
• Add a test config or line additions to test/ (note tests are changing the config.tutorial.yaml)
• Changes in configuration options are also documented in doc/configtables/*.csv and line references are adjusted in doc/configuration.rst and doc/tutorial.rst.
• A note for the release notes doc/release_notes.rst is amended in the format of previous release notes, including reference to the requested PR.

[ekatef]

As a comment, there is also an effect of i_nom which may significantly impact the result for the transmission capacity and is determined by the wire design.

E.g. for Al-steel wires *-AL1/*-ST1A, i_nom varies between 0.21 and 1.15 across the types which can be used for 100kV (data taken from pandapower). Not sure there is a way to account for the size types which are really in use in one or another power system. Probably, it may be a good idea to add an empiric coefficient which accounts for an average difference between the i_nom values calculated according to the line types we assume and real i_nom values across the power system.

Obviously, that is a purely data-based perspective ideally should can be adjusted according to the real-world operation of the existing power grids.

[ekatef]

A quick demonstration of the effect of the linetype definition of the transmision capacity using the notebook by @GbotemiB (thanks for the handy tool!):

• original picture with 110kV mapped into "243-AL1/39-ST1A 110.0" (with i_nom 0.645 kA)

• a picture re-calculated with 110kV mapped into "N2XS(FL)2Y 1x120 RM/35 64/110 kV" (with i_nom 0.366 kA):

[davide-f]

Thanks katia!
It seems this PR is ready, but could you please explain the image you posted?
I don't see how much we improve or so.

I believe it is also worth adding a release_note in this case

[ekatef]

Thanks katia! It seems this PR is ready, but could you please explain the image you posted? I don't see how much we improve or so.

I believe it is also worth adding a release_note in this case

Thank you, Davide :)

The image was in fact rather a problem statement, not testing results. The point is, the PR is dealing with a part of uncertainty which relates to the voltage mapping, while we need some other approach to deal with the uncertainty linked with definition of the line type. The picture above demonstrates this effect of the linetype. (Sorry for messing things up!)

Testing results for the PR itself are as follows. When looking into data for Norway:

• ENTSOe data for an overall transmission capacity are 0.23e6 MVA when using PyPSA-Eur base.nc network build on ENTSOe data (or 0.27e6 MVA if taking ENTSOe csv directly);

• original PyPSA-Earth network has an overall transmission capacity 1.73e6 MVA;

• application of this PR reduces the transmission capacity to 1.07e6 MVA;

• application of this PR and filtering by the original voltage to match ENTSOe voltage levels (>=300kV) gives 0.55e6 MVA.

So, we are still two times off, but I'd say that is quite an improvement :D

The topology comparison looks like that:

[davide-f]

Many thanks @ekatef and totally understand!
Then, I think this PR can be merged as-is, that's great!