opusonesolutions / carsons Goto Github PK

The way we abstract a line right now, it has to have a .phases attribute which is a mapping of

{
    'A': 'A',
    'B': 'B',
    ...
}

... for each phase a wire has. This is a clumsy modelling and it also prevents us from modelling configurations that have multiple neutral wires that have different resistance / gmr / wire position properties.

An ideal solution would:

• simplify the return value of .phases
• support multiple wires with a phase of 'N'
• provide an abstract interface that third parties can implement to get their data into the Carsons Equations model

Overhead lines and underground cables from two different feeders commonly run in parallel. For example:

• Two different feeders leaving the same substation can share the same pole before branching out.
• Overhead lines of two feeders can also merge together, run in parallel for a while, and then branch out again.
• Underground cables from two feeders can also share the same common trench.

The work is to update calculations so the mutual impedances between the two lines are known. This will enable more accurate power-flow calculations.

IEEE 13 contains a number of different cable configurations and calculated impedances. It would be a good idea to add these as test cases for carsons

The test cases can be found at http://sites.ieee.org/pes-testfeeders/files/2017/08/feeder13.zip

Great job on the implementation of carsons equations, it's a very useful reference.

I believe this matrix in the tests is incorrectly ordered.

If I use the carsons.py file to generate the z_primitive_matrix for ABCN_geometry_line I get the following:

0.00017479262640653616 + j 0.000859886093793189    5.9217626406536145e-05 + j 0.0004848090114987014    5.9217626406536145e-05 + j 0.0005291270819387303    5.9217626406536145e-05 + j 0.000488729331339374
5.9217626406536145e-05 + j 0.0004848090114987014    0.00017479262640653616 + j 0.000859886093793189    5.9217626406536145e-05 + j 0.0004514956068104968    5.9217626406536145e-05 + j 0.000476865015771444
5.9217626406536145e-05 + j 0.0005291270819387303    5.9217626406536145e-05 + j 0.0004514956068104968    0.00017479262640653616 + j 0.000859886093793189    5.9217626406536145e-05 + j 0.0004675586100839125   
5.9217626406536145e-05 + j 0.000488729331339374    5.9217626406536145e-05 + j 0.000476865015771444    5.9217626406536145e-05 + j 0.0004675586100839125    0.00042706962640653615 + j 0.0009609520589591509

If you make this change, you will be able to get rid of the decimal=4 keyword argument in the assertion in your tests.

The CarsonsEquations model class is instantiated from another object that contains the necessary attributes. This poses a problem when you want to run Carson's equations on some values as you need to create a shim class to pass those values to the model.

Some ideas for improving this

• add property names in __init__ instead of a plain model
• keep the model and replace with a dictionary

The .rst readme is fragile and doesn't render well on pypi even though it renders fine on github and in most viewers. It seems like we could use markdown instead, based on this repo: https://github.com/di/markdown-description-example/blob/master/setup.py

I am attempting to load this package into:
Windows 10
Python 3.6
Anaconda 5.1

I receive the following error

(base) C:\Users\XXXXXXXXX>pip install carsons
Collecting carsons
  Downloading https://files.pythonhosted.org/packages/72/83/b0e2954f67741643b1fd2be62d3f1f6a5b96f99ad1c16fa4a0faabcff2eb/carsons-0.2.1.tar.gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "C:\Users\XXXXXXXXX\AppData\Local\Temp\pip-build-el644y7h\carsons\setup.py", line 31, in <module>
        long_description=readme(),
      File "C:\Users\XXXXXXXXX\AppData\Local\Temp\pip-build-el644y7h\carsons\setup.py", line 10, in readme
        return f.read()
      File "C:\Users\XXXXXXXXX\AppData\Local\Continuum\anaconda3\lib\encodings\cp1252.py", line 23, in decode
        return codecs.charmap_decode(input,self.errors,decoding_table)[0]
    UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 1163: character maps to <undefined>

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in C:\Users\XXXXXXXXX\AppData\Local\Temp\pip-build-el644y7h\carsons\

What do I need to do to solve this?

Carsons supports models with multiple neutrals. We need to validate that the results are correct. Most of the work involved would be in finding a test case in an existing IEEE model where someone has turned a geometric model into equivalent impedances -- given this, we could easily write a test to ensure that the z_ABC we produce for that cable is correct.

Currently, the Carsons model always uses a truncated expansion for computing the P/Q terms at each i/j combination:

Ideally we would expose the number of terms so a user can configure them, and we would have a reliable example calculation to use as a test case where, if you don't use the full P/Q series, the test would fail because the impedance is not calculated precisely enough.

One possible approach would be to expose a FullCarsons and ModifiedCarsons, which is how the Kersting source describes the simplification of taking only the first 1--2 terms of P/Q. The ModifiedCarsons model is needed for all cable calculations, since it can be formulated to not rely on having a y position. An overhead line can be supported by both the Full and Modified carsons equations

Carsons supports overhead wires as well as underground cables where each phase conductor has a concentric neutral. However, there is another somewhat common cable typology, the tape-shield. This is where the cable has a thin conductive shield around the insulation, and then there is a separate neutral cable pulled underground alongside the phase conductors.

Since we already support Concentric Neutrals using the modified carsons equations, it shouldn't be too hard to build a TapeShieldCarsonsEquations that implements the particular geometric equivalents for a tape shield cable.

Part of the work would involve exploring IEEE, OpenDSS or other resources for sample calculations that can be used as tests for this calculation. IEEE4/13 has a AN example, but we'd want to also have example calculations for 2- and 3-phase cables.

I wanted to confirm that this equation is correct?

Shouldn't it be this instead?

−π * k**4 * cos(4 * θ) / 1536

Or is there some simplification I'm missing?

currently, Carsons has the assumed operating frequency hard-coded to 60 hz. This is suitable for north-american markets but not for other ones. We should add the frequency as a parameter to all impedance calculations, with the default being 60hz for backwards compatibility.