Agenda:

·         CIM Dynamics - Motors and Generators

·         Verify that we are fine with Boundary setup - ConnectivityNodes, Names....; An additional issue I've received  - inclusion of Line class

·         Discuss Test Procedures - basic concept - to be discussed in the next call with priority 

·         AOB
- email Youssef, Svein - on Boundary
- email Michal - on profile doc

1) CIM Dynamics - Motors and Generators

In the last CIM for Dynamics call we discussed Generator and Motor modeling. We need a way to:

- separate pure load flow related classes/attributes in order to handle some documentation issues

- model Motor on Synchronous and Asynchronous machines

-model Generator on Synchronous and Asynchronous machines

3 jpg-s were provided before the call in order to explain the issue: {SynchronousGenerator.jpg} and {SynchronousMotor.jpg} and {SynchronousMachineDynamics.jpg}

During the last CIM for Dynamics call we discussed a variant which is presented in {SynchronousMachineDynamics.jpg}

Please pay attention that the diagrams for Asynchronous machine are similar

Questions:

·         Do you see a problem that we do not model GenEquiv explicitly, but as a type of an enumeration (together with transient, typeF, typeJ....)? No, there is no problem. The type "equiv" in the enumeration plays the same role

·         Which way of modelling do you see appropriate?:

o   using SynchronousMachineDynamics class {SynchronousMachineDynamics.jpg} - Better model

o   using GenSync and MotorSync i.e. {SynchronousGenerator.jpg} and {SynchronousMotor.jpg} - Not good

      ·         Do you agree with the separation of the enumeration SynchronousGeneratorType? 
  It looked like we were mixing characteristic which is related to the construction (roundRotor, silentPole) with way of modelling (transient, typeF, typeJ, equiv,...)

Yes, but we need to check if all other types are really related to modelling. The type motor in this enumeration should be deleted 

·         Do you agree that when {SynchronousMachineDynamics.jpg} type of modelling is applied the you should count on the active power sign convention to see if it is a Generator or Motor?

      It might be good to have an enumeration Generator; Motor in the RotatingMachine so that it is clear on the assets. What do you think on this? Yes, prefereble to inficate default mode: generator, motor, Generator_motor

• remark: It should be understood by all that Generators (which are SynchronousMachine) are only mechanical rotating machines. It should be understood by all that Generators (which are SynchronousMachine) are only mechanical rotating machines.

o   The rdf:ID cannot begin with a number. If rdf:ID begins with a number an underscore “_” must be added as the first character. An underscore may be added if the rdf:ID begins with an alpha.

1) The first draft of the test procedures is here. (Path: CIMug > Groups > ENTSO-E CIM IOP > 3rd IOP SDO - 2012 > Shared Documents > Test Procedures)

It is still practically the same as last year. This doc (or updated version) will be a priority for the next call

Changes are indicated with track changes

3) There is some information on HVDC links.

I uploaded docs coming from WG13 here. (Path: CIMug > Groups > ENTSO-E CIM IOP > 3rd IOP SDO - 2012 > Shared Documents > Other > HVDC)

It is expected that IOP participants provide input to WG13. It will be great if you manage by Wed so that I can inform WG13.