Using CoilSet.from_eqdsk mis-classifies coils

[cmacmackin]

Describe the bug

The CoilSet.from_group_vecs method (called by CoilSet.from_eqdsk) uses a simple heuristic to distinguish between PF coils and CS coils: if dx and dz are equal then they are PF coils, otherwise they are CS. Presumably this has been sufficient when working with conventional Tokamak designs but it is not reliable for Spherical Tokamaks.

Steps to reproduce

I encountered this when trying to design some new behaviour for the STEP code (making it possible to read in old runs). This code is not public. A JSON serialisation of the original coils is given below:

{
    "PF_1.1": {
        "x": 1.5,
        "z": 8.787573575105338,
        "dx": 0.175,
        "dz": 0.5,
        "current": 5894660.784269055
    },
    "PF_1.2": {
        "x": 1.5,
        "z": -8.787573575105338,
        "dx": 0.175,
        "dz": 0.5,
        "current": 5894660.784269055
    },
    "PF_2.1": {
        "x": 1.5,
        "z": 11.307573575105339,
        "dx": 0.25,
        "dz": 0.4,
        "current": 6791296.337239938
    },
    "PF_2.2": {
        "x": 1.5,
        "z": -11.307573575105339,
        "dx": 0.25,
        "dz": 0.4,
        "current": 6791296.337239938
    },
    "PF_3.1": {
        "x": 12.802467952311037,
        "z": 11.807573575105339,
        "dx": 0.25,
        "dz": 0.4,
        "current": 32920322.657766376
    },
    "PF_3.2": {
        "x": 12.802467952311037,
        "z": -11.807573575105339,
        "dx": 0.25,
        "dz": 0.4,
        "current": 32920322.657766376
    },
    "PF_4.1": {
        "x": 12.802467952311037,
        "z": 6.8,
        "dx": 0.25,
        "dz": 0.4,
        "current": -41363029.116069205
    },
    "PF_4.2": {
        "x": 12.802467952311037,
        "z": -6.8,
        "dx": 0.25,
        "dz": 0.4,
        "current": -41363029.116069205
    },
    "PF_5.1": {
        "x": 15.120639645587653,
        "z": 1.7,
        "dx": 0.35,
        "dz": 0.5,
        "current": 8144992.116116044
    },
    "PF_5.2": {
        "x": 15.120639645587653,
        "z": -1.7,
        "dx": 0.35,
        "dz": 0.5,
        "current": 8144992.116116044
    },
    "CS_1": {
        "x": 0.1225,
        "z": 4.205,
        "dx": 0.022,
        "dz": 2.0525,
        "current": 0
    },
    "CS_2": {
        "x": 0.1225,
        "z": 0.0,
        "dx": 0.022,
        "dz": 2.0525,
        "current": 0
    },
    "CS_3": {
        "x": 0.1225,
        "z": -4.205000000000001,
        "dx": 0.022,
        "dz": 2.0525,
        "current": 0
    }
}

After read-in, they were serialised as follows:

{
    "CS_17": {
        "x": 1.5,
        "z": 8.787573575105338,
        "dx": 0.175,
        "dz": 0.5,
        "current": 5894660.784269055
    },
    "CS_18": {
        "x": 1.5,
        "z": -8.787573575105338,
        "dx": 0.175,
        "dz": 0.5,
        "current": 5894660.784269055
    },
    "CS_19": {
        "x": 1.5,
        "z": 11.307573575105339,
        "dx": 0.25,
        "dz": 0.4,
        "current": 6791296.337239938
    },
    "CS_20": {
        "x": 1.5,
        "z": -11.307573575105339,
        "dx": 0.25,
        "dz": 0.4,
        "current": 6791296.337239938
    },
    "CS_21": {
        "x": 12.802467952311037,
        "z": 11.807573575105339,
        "dx": 0.25,
        "dz": 0.4,
        "current": 32920322.657766376
    },
    "CS_22": {
        "x": 12.802467952311037,
        "z": -11.807573575105339,
        "dx": 0.25,
        "dz": 0.4,
        "current": 32920322.657766376
    },
    "CS_23": {
        "x": 12.802467952311037,
        "z": 6.8,
        "dx": 0.25,
        "dz": 0.4,
        "current": -41363029.116069205
    },
    "CS_24": {
        "x": 12.802467952311037,
        "z": -6.8,
        "dx": 0.25,
        "dz": 0.4,
        "current": -41363029.116069205
    },
    "CS_25": {
        "x": 15.120639645587653,
        "z": 1.7,
        "dx": 0.35,
        "dz": 0.5,
        "current": 8144992.116116044
    },
    "CS_26": {
        "x": 15.120639645587653,
        "z": -1.7,
        "dx": 0.35,
        "dz": 0.5,
        "current": 8144992.116116044
    }
}

(There are also three coils missing but this appears to be due to a problem with the STEP reactor class itself creating coils separately from the EQDSK.)

Expected behaviour

The names of the coils in JSON above should be the same.

Environment (please complete the following information)

• OS: Ubuntu 20.0
• Branch: cmacmackin/build-refactor-demonstration (also applies on develop)

Additional context

This is not an urgent bug for me as I can reconstruct the coils directly from another serialisation produced by the STEP reactor code.

[CoronelBuendia]

One of the many problems with the official EQDSK format is that things like coil names are not included. So when we read one in, we give names to the coils in order to distinguish them, but they follow an ITER-like convention, and it cannot do the job if your coil names don't follow this, or are placed in an (even subtly) different way.

We could add a vector for the coil names to our "EQDSK" standard, which in JSON (which you should be using for anything internal) should not be a problem. Just need to make sure to put it somewhere in the output EQDSKs that won't break anyone else's (external) EQDSK reader.