Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set conventions for the different rotating directions involved in magnetic calculation #468

Closed
EmileDvs opened this issue Oct 27, 2021 · 1 comment

Comments

@EmileDvs
Copy link
Collaborator

EmileDvs commented Oct 27, 2021

Hello all,

We faced some issues lately with the conventions of rotating directions that must be accounted for in magnetic simulation, to make sure that both rotor and stator fields rotate the same way and can produce torque in any conditions. As explained below there are many rotating parameters to account for if they are not all consistent then the simulation results are also not physically sound, and so new conventions have been chosen in PR #464 to clearly state on the different parameters.

Before talking about conventions, I would like to detail a bit more which rotating directions are involved based on a PMSM example. This may be a lot of information here but it can be useful to better understand the issue (which is clearly not trivial to my opinion) and further to document pyleecan conventions on the website. Otherwise you can jump straight to the conventions at the end of this post.


The first rotating direction parameter to consider is naturally the one the rotor mechanical rotation. The rotor mechanical speed can therefore be noted N0=rot_dir*60*f_elec/p, with rot_dir the rotating direction (rot_dir=+/-1), f_elec the fundamental electrical frequency and p is the pole pair number. Chosing the value of rot_dir necessarily freezes the direction of the fundamental rotor field wave in the airgap.

This field wave can be expressed as B_fund*cos(2*pi*f_elec*t + field_dir*p*alpha + phi), where B_fund is the field wave amplitude, t is time, field_dir is the rotating direction of the field (field_dir=+/-1), alpha is the angular position along the airgap (from 0 to 2*pi). The field wave frequency f is therefore f=f_elec and the wavenumber is r=field_dir*p. The ratio frequency over wavenumber "f/r" gives the algebraic mechanical speed, and the direction is given by the sign of field_dir: "clockwise" if field_dir=1, "counter-clockwise" if field_dir=-1.

Now, what is the relation between rot_dir and field_dir ? If rot_dir=1, rotor angle increases with time so rotor field rotates in trigonometric direction, i.e. counter-clockwise, thus field_dir=-1. If rot_dir=-1, it is the opposite: rotor angle decreases with time so rotor field rotates clockwise.

The next step is to consider the parameters that affect the rotating direction of the stator field, which must be equal to field_dir (the rotating direction of the rotor field) to ensure torque production (and so opposite to rot_dir). As it is done in pyleecan, it is much convenient to consider stator magnetomotive force (mmf) rather than stator field to calculate rotating direction of stator field, so stator field direction will be noted mmf_dir (mmf_dir=+/-1). mmf_dir depends on several parameters in stator phase currents definition and in the spatial distribution of phases in slots (winding pattern).

Let's look at the parameters in the polyphase stator currents definition, whose fundamental current on n^th phase (assuming phase shift is zero) can be expressed as: I_fund*cos(current_dir*2*pi*f_elec*t + phase_dir*2*pi*(n-1)/qs), where I_fund is the phase current amplitude, current_dir is the rotating direction over time (current_dir=+/-1), phase_dir is the phasor direction that is required in Clarke transform and determines if polyphase system is direct or inverse (phase_dir=+/-1) and qs is the number of phases.

The stator mmf fundamental wave that results from the stator currents flowing in the windings can be expressed as:
M_fund*cos(current_dir*2*pi*f_elec*t + phase_dir*wind_dir*p), introducing an additional rotating direction wind_dir (wind_dir=+/-1) that depends on winding pattern. Therefore rotating direction of stator mmf fundamental wave is given by the sign of current_dir/( phase_dir*wind_dir).

Consequently, the calculation of mmf_dir for a couple (current_dir, phase_dir) given as input of mmf calculation enables to determine wind_dir. If mmf_dir is opposite to field_dir (and so is equal to rot_dir) then either current_dir or phase_dir should be changed to ensure that both rotor and stator fundamental field waves rotates in same direction. This can be done by shuffling two phases in the matrix of stator currents or in the winding connection matrix.


In summary, the conventions chosen by default in PR #464 are:

  • convention 1: rot_dir=-1 to have counter-clockwise rotation of fundamental field wave, so that frequency (f=f_elec) and wavenumber (r=p) are both positive
  • convention 2: if mmf_dir=rot_dir because of the winding pattern, permute two phases in input to avoid modifying machine object during simulation (done in gen_input() of InputVoltage by storing the permutation array in OutElec.perm_phases)
  • convention 3: motor convention => positive torque for mmf_dir=1 => current_dir=-1 and phase_dir=-1

Of course these conventions could be changed in an .init file, I still have to find which .init file is the most relevant.

The validation test to check torque production with the new convention is test_mmf_dir.py, for Toyota_Prius case (wind_dir=1) et Protean_InWheel case (wind=-1 requiring the permutation of phase B and C).


I realize now that this is a huge text eventually and it took me a lot of time to write it but I hope it will help the pyleecan users to better find their way in the magnetics and electrical simulation setup.

Best regards,
Emile

@EmileDvs
Copy link
Collaborator Author

EmileDvs commented Dec 9, 2021

Issue solved with #464

@EmileDvs EmileDvs closed this as completed Dec 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant