The ODE that is considered to model the electric behavior of the motor is given by:

[Priyadharshan2001]

          The ODE that is considered to model the electric behavior of the motor is given by:

(from the same documentation site that you also referenced)

In the code, the motor is represented via (in https://github.com/upb-lea/gym-electric-motor/blob/master/gym_electric_motor/physical_systems/electric_motors/permanent_magnet_synchronous_motor.py). Herein, each column is associated to one of the variable values that are annotated in line 110.

Mutual inductance as of is not implemented, (Retrieved from https://ei.uni-paderborn.de/lea/lehre/veranstaltungen/lehrangebote/geregelte-drehstromantriebe lecture notes can be downloaded at the bottom of the page). This would need to be modeled in three-phase coordinates, it seems.

In two-phase coordinates, one could make use of cross coupling inductances L_dq or L_qd, which are also not yet included. For that, a model of the form would need to be implemented into the code. (Equations retrieved from https://ieeexplore.ieee.org/abstract/document/9376968). This should fit well into the given structure. However, a mechanism to change motor parameters mid-simulation (e.g., to consider saturation effects) is also not yet provided. I guess one could code this quick and dirty by accessing the parameters at runtime.

From our side, an implementation of these features in the foreseeable future is not realistic. We would highly appreciate to hear from your solution if you decide to implement it in GEM yourself.

Originally posted by @max-schenke in https://github.com/upb-lea/gym-electric-motor/issues/228#issuecomment-1905570794

#MY QUESTIONS ARE: " Q. 1. The parameter 'p' which provides the number of pole pairs is not being used in the new set of equations which include the mutual inductance . Is this correct?

Q. 2. Can you provide some initial estimates for values of mutual inductances Ldq , Lqd ?

Q.3."Which part of the code uses the "update model"function ? Is this function being used implicitly or explicitly? " Thanks

[max-schenke]

A1: No, the notation conventions are just different. GEM utilizes the mechanical angular speed omega = omega_me as the default output quantity. To compute the electrical behavior correctly, we need to multiply this by the pole pair number: omega_el = p*omega_me which is done within the matrix calculations.

In contrast to that, the notation of the paper https://ieeexplore.ieee.org/abstract/document/9376968 utilizes omega = omega_el as the default case:

[max-schenke]

A2: Again, the paper https://ieeexplore.ieee.org/abstract/document/9376968 documents what can be expected from the differential inductances:

[max-schenke]

A3: As of now, the given system matrix is assumed constant and, hence, the _update_model function is called only upon initializing: (from https://github.com/upb-lea/gym-electric-motor/blob/master/gym_electric_motor/physical_systems/electric_motors/synchronous_motor.py)

I see two options making use of the structure as is: either the _update_model function is called more frequently (within each step) to update the inductance values, or the matrix remains constant and all current-dependent values are outsourced to some augmented state vector (Right now, the same is already happening for speed. Since speed is changing, the matrix has entries that will be multiplied with omega*i_d, for instance. Therefore, speed as a time-variant parameter is also outsource from the system matrix.) Maybe you have further ideas how this could be done.

[Priyadharshan2001]

A3: As of now, the given system matrix is assumed constant and, hence, the _update_model function is called only upon initializing: (from https://github.com/upb-lea/gym-electric-motor/blob/master/gym_electric_motor/physical_systems/electric_motors/synchronous_motor.py)

I see two options making use of the structure as is: either the _update_model function is called more frequently (within each step) to update the inductance values, or the matrix remains constant and all current-dependent values are outsourced to some augmented state vector (Right now, the same is already happening for speed. Since speed is changing, the matrix has entries that will be multiplied with omega*i_d, for instance. Therefore, speed as a time-variant parameter is also outsource from the system matrix.) Maybe you have further ideas how this could be done.

Thanks for your time. I apologize for the delay in responding; I was occupied with other tasks. However, one of my teammates and guide has already reviewed this and is working on it.