Best Practice to Calculate Torque for PMSM

[zmladen]

Hello,

What are the possibilities to calculate the torque for the PMSM machine? In the attached example I used the "r outer" and "r inner" keywords in the rotor airgap body (just outside the rotor steel area). The torque shape seems to be ok. The values have to be scaled with the symmetry number and the machine length.

Code: Select all

Body 7 
 Name = "airgapRotor" 
 Equation = 1 
 Material = 1 
 Body Force = 1 
 r outer = Real 0.01630 
 r inner = Real 0.01625
End 

There are some examples which use the "Torque Groups" keyword whithin the body where the torque should be calculated. My problem is that I dont know how to use it. In which bodies I should add the "Torque Groups" keyword? In the attached example I added the "Torque Groups = Integer 1" in the rotor body and set the

Code: Select all

  Calculate Nodal Forces = Logical True
  Calculate Magnetic Torque = Logical True

inside the "MagnetoDynamicsCalcFields" solver. The results are completely different than the one obtained using the first approach.

Cogging Torque.jpg (26.13 KiB) Viewed 1611 times

[MartinHoeijmakers]

Hi,

I used several methods to calculate the torque in an electrical machine. My experience is that the use of "r inner" and "r outer" (method of Arkkio?) is much more accurate than the computations by means of nodal forces (Torque groups). I compared the results with FEMM and varied the mesh size. Further, I looked at the power balance by comparing the mechanical power with the electrical power in a lossless machine.

The use of "r inner" and "r outer" may be improved by using a circular "physical curve" in gmsh at those radii. These circles become a kind of dummy boundary, but are not used. I think that the effect is that the meshes are nicely located along those circles.

Kind regards,
Martin

[raback]

Hi

The results should not be "completely different". The nodal forces approach has had some evolution. I think it is basically the same but currently the idea is maybe best depicted in test case "TEAM30a_3ph_transient". Here "Component" section is used. It can be understood as defining a mechanical lumped components compared to usual electrical componenst. If there is circuit defined give the mechanical one the next free index.

Note that the nodal forces should not include the air gap of the rotor but only the mechanical parts. This is because the nodal forces should for the air sum up to zero but at the interface they are missing the balancing contributions. Hence the "master bodies" in the component section should only have the mechanical ones.

Still there will be some discrepancy but that should not be dramatic. Also the Arrkio's formula assumes that there is element layer characterized by two radiuses. This is not always the case. Also we might want to compute net forces on some parts of the assembly etc.

-Peter

[MartinHoeijmakers]

Hi Peter,

About a year ago I did many experiments for calculation of the torque. Using nodal forces, I experienced problems with
- air-holes in the rotor,
- permanent magnets (see also viewtopic.php?p=24964, on which I didn't get any response), and
- non-magnetic, electrically conductive rotor parts, such as aluminum.
I didn't include the air gap in the calculations of the nodal forces.

In many cases, the result was that the torque on the rotor did not equal the torque on the stator. I also used the steady-state power balance and FEMM to check result.

In some cases, the problems could be solved by using an extremely dense mesh.

I also would like to use nodal forces, but at this moment the number of problems is too large. For that reason I stopped my research in using the nodal forces and used Arkkio's formula. Perhaps some hints might be helpful to restart of my investigations.

Kind regards,
Martin

[raback]

Hi

Some background for the nodal force is here, for example:
https://www.researchgate.net/publicatio ... ap_Element

And the summing up happens in lines 1520 in:
https://github.com/ElmerCSC/elmerfem/bl ... Fields.F90

As you state it recovers Arkkio's results at best so I have no reason to doubt this. It has been critically more tested in 3D but the code is the same. The difference is of course significant since the 2D uses nodal elements while 3D uses edge elements. After B is deduced there should not be any difference though.

-Peter

[FabianH]

I can confirm, that there is no big difference between Arkkio and the nodal force method. My observation is more, that i have a shift in the mean of the torque which differ from zero, when i reduce the step size of the mesh rotation. A denser mesh doesn't bring any improvement. I know that the torque with a rough step size no longer fits, but an offset confuses me. Maybe someone have a hint for me

rough_step_sizet.PNG (116.5 KiB) Viewed 1515 times

fine_step_sizet.PNG (107.13 KiB) Viewed 1515 times

[MartinHoeijmakers]

Hi,

These are nice examples to show what I meant earlier.

The relative difference between "elmer Torque Arkkio" and "elmer Torque Component" is in the order of magnitude of 5%. Perhaps, that is not a big difference, but it is certainly not a small difference. If you want to calculate the efficiency of an electrical machine (generally more than 90%), such a difference is not acceptable.

If I compare the mechanical power and the electrical power of a loss-less electrical machine with a reasonable mesh size, I get a relative difference in the order of magnitude of 1e-4, if I use Arkkio's formula. If I use nodal forces, the order of magnitude of the relative difference is 1e-2.

Kind regards,
Martin

[FabianH]

Hello Martin,

maybe the example is not so simple after all. Even with small increments there is a small offset, which means that the error is not that big in the end. It still bothers me because I can't explain it.

The small error margin of your lossless machine is impressive. Especially because I can't immediately come up with a solution after initial considerations as to how I have to deal with the harmonics. I would definitely be very interested in a brief explanation, otherwise via PM.

Best regards
Fabian

[FabianH]

I think that I found my mistake. I assumed that Mesh Rotate 3 works with the increment of the rotation and doesn't need the absolute angle. Some examples are with tx and others define the line with tx(0) - tx(1).

Code: Select all

Body Force 1 
  Mesh Rotate 3 = Variable Time
	Real MATC "tx"
End

instead of

Code: Select all

Body Force 1 
  Mesh Rotate 3 = Variable Time, Timestep Size
	Real MATC "tx(0)-tx(1)"
End

solved the offset. I thought is would produce the same results, but this did not happen. The assumption was that solver recognizes this via the definition of Time Step Size.

I have one last question to this topic. The point at 0s is never calculated with transient solvers. Is not tragic, but would like to know if this is possible or not. Then the RigidMeshMapper must always be run with "Before Timestep", right?

[FabianH]

Another result: I have now tried all possible combinations. Simulated testcase is a surface PM machine without magnetization (magnets behave like iron). If I include the rotor air between the magnets in the respective calculations (Torque Group, Component), the results are almost identical. That also explains the difference above. I commented out the rotor air as I had errors in the first few tries as soon as I added rotor air at the air gap. I unwitting commented out the air pockets as well, as I assumed that only the iron parts should be taken into account.

elmer_torque_comparison.PNG (25.52 KiB) Viewed 1428 times