There are a lot of abstract classes in the EQ-profile such as Bay, VoltageLevel, Line, ConformLoad etc. Are these required classes or optional? I´m a bit sceptic since these classes are not actually equipment like ACLineSegment, Fuse, Substation etc.
What about network information systems that don´t have this abstract hierarchy. Could it be a possibility to make the EQ-profile a bit leaner and include these abstract classes in another subprofile?
abstract class are classes that is part of the hierarchy but not instantiated in the instance file, e.g. Equipment
Container classes that is primary used in regards to power flow is navigation and allocation of ConnectivtyNode, e.g. Substation, VoltageLevel, Bay etc
This has been a lot of discussion if we can create a pure EQ-profile for power flow. There is a very strong need for this as we are in a transition where all tool model the grid with what they need without having a modelling tool. A power flow tool should only need to read a EQ. It is noting that state that you can generate a EQ-profile based instance file that does not confirm to EQ. The file will fail some of the EQ validation, but this should still not prevent it from being imported to a given tool.
It is difficult to come with an agreement on a simplified standard, since different tools has different requirement. It therefore often becomes the supper set that is agreed on.
There are a lot of abstract classes in the EQ-profile such as Bay, VoltageLevel, Line, ConformLoad etc. Are these required classes or optional? I´m a bit sceptic since these classes are not actually equipment like ACLineSegment, Fuse, Substation etc.
What about network information systems that don´t have this abstract hierarchy. Could it be a possibility to make the EQ-profile a bit leaner and include these abstract classes in another subprofile?