How to support 2-winding and 3-winding transfomer data?

[nickrobinson251]

the tranformer data category is fun in a few ways:

1. each entry is spread over multiple rows
2. records for two-winding and three-winding transformers are in the same data category, but there's a different number of data points for each. That is, how many rows and how many values per row are in the entry depends on whether it is for a 2-winding or for a 3-winding transformer. The data for 2-winding transformers is a subset of data for 3-winding transformers. The "extra" columns for the 3-winding transformers comes at the end of rows 2 and 4, and on the addition row 5. And entries for 2-winding transformers and 3-winding transformers can be interspersed (there's e.g. no requirement that all 2-winding data comes before 3-winding data).

The five row transformer data block for three-winding transformers has the following format:

I,J,K,CKT,CW,CZ,CM,MAG1,MAG2,NMETR,’NAME’,STAT,O1,F1,...,O4,F4
R1-2,X1-2,SBASE1-2,R2-3,X2-3,SBASE2-3,R3-1,X3-1,SBASE3-1,VMSTAR,ANSTAR
WINDV1,NOMV1,ANG1,RATA1,RATB1,RATC1,COD1,CONT1,RMA1,RMI1,VMA1,VMI1,NTP1,TAB1,CR1,CX1
WINDV2,NOMV2,ANG2,RATA2,RATB2,RATC2,COD2,CONT2,RMA2,RMI2,VMA2,VMI2,NTP2,TAB2,CR2,CX2
WINDV3,NOMV3,ANG3,RATA3,RATB3,RATC3,COD3,CONT3,RMA3,RMI3,VMA3,VMI3,NTP3,TAB3,CR3,CX3

The four row transformer data block for two-winding transformers is a subset of the data required for three-winding transformers and has the following format:

I,J,K,CKT,CW,CZ,CM,MAG1,MAG2,NMETR,’NAME’,STAT,O1,F1,...,O4,F4
R1-2,X1-2,SBASE1-2
WINDV1,NOMV1,ANG1,RATA1,RATB1,RATC1,COD1,CONT1,RMA1,RMI1,VMA1,VMI1,NTP1,TAB1,CR1,CX1
WINDV2,NOMV2

Point (1) is mostly a finickity implementation detail; basically we have to treat multiple rows as we'd usually treat an individual row in other categories, but handle those tricksy end-of-line comments potentially appearing in 4 or 5 places rather than just one.

But point (2) requires us to decide how we want to handle the different transformer types:

If PSS/E had put these in two separate categories, then we'd have no problem: we could create a dedicated structure for each, like we always do for the separate categories. So one option, is to act as if 2-winding and 3-winding transformers were in different categories, and parse them into two different types e.g. TwoWindingTransformers and ThreeWindingTransformers. This would mean the Julia representation of the data diverges from the file format's representation, which we might not want. More practically, it means users would have two tables network.two_winding_transformers and network.three_winding_transformers, were they might reasonably expect (given the file's strucutre) to have a single network.transformers table.

Alternatively, we could have a single Transformers type, which has all the columns for 3-winding data, but which has missing entries in columns not present for 2-winding transformers. In addition, we can have Tables.schema check at run-time whether we have any 3-winding data, and if not just return the columns required for the 2-winding transformers.

[aside: As far as I know (which is not saying much), 3-winding transformers are not always present (e.g. for certain US Grids, there can be realistic data which contains no 3-winding transformers), so initially ignoring this complexity and supporting only files with only 2-winding transformers might be an okay-ish short-term option. #11].