[Getdp] Electric machines template moving band

Alexander Kreim alexander.kreim at hs-hannover.de
Sun Nov 29 12:48:21 CET 2020


Hello Théodore,

I started to collect information on the moving band I found in the 
electric machine examples and the getDp/gmsh archives (sometimes it's 
just a copy of a forum contribution or of a comment in the examples). 
Maybe this is helpful. Comments are welcome.

Regards,
Alexander


/* Creates Moving Band geometry for models containing a single pole
  *
  * The following variables must exist in the workspace:
  * lineMBstator ...  line between stator airgap and moving band
  * lineMBrotor  ...  line between rotor airgap and moving band
  * p ... total number of pole pairs
  * lineMBstatorAux[] ... moving band lines
  * 2019/07/24 A. Kreim */

//------------------------------------------------------------------------------
// Moving Band (information)
/*<f1>-----------------------------------------------------------------------*/
/*  The explanations are limited to rotating electric machines.
*  The moving band is the interface between stator (fixed) and rotor 
(moving).
*  In theory a layer of elements are placed in the middle of the airgap
* (moving band) [1]. Due to the rotation of the rotor the elements are 
distorted.
*  If the distortion is large enough the moving band will be remeshed.
*
*  The definition of the moving band requires several steps in the geo 
(gmsh)
*  and pro (getDp) files.
*
*  The airgap is split into three parts:
*  - stator airgap
*  - rotor airgap
*  - moving band between stator and rotor airgap
*
*  The following information are collected from example files (machine 
models [2])
*  and the getDp archive:
*
*  It is assumed that gmsh and getDp are used.
*
* The explanations are based on a four pole machine with one pole in the 
model
* (which is only an example, other configurations are possible)
*
*                              -----------------*
*                              | stator           |
*                              -----------------*
*                              | stator airgap |
*                              -----------------* <= stator moving band 
lines (one pole)
*                          moving band region (no mesh)
* 
-----------------*-----------------*-----------------*-----------------* 
<= rotor moving band lines (all poles)
*      aux 3        | rotor airgap   |      aux 1            aux 2
*                       -----------------*
*                       | rotor             |
*                       -----------------*
*
*  The moving band is defined in the getDp group object:
*  MB = MovingBand2D[MovingBand_PhysicalNb, Stator_Bnd_MB, Rotor_Bnd_MB, 
SymmetryFactor] ;
*
*  MovingBand_PhysicalNb (defined in getDp Group object):
*    'MovingBand_PhysicalNb' needs to contain exactly one region.
*    This region is assigned to the moving band.
*    The region is a dummy region since it is not defined in the mesh
*    created by gmsh.
*    Typically:  MovingBand_PhysicalNb = Region[0] ;
*
*  Stator_Bnd_MB (defined in getDp Group object)
*    is a Region defined by physical lines.
*    The Region contains all lines in the model which are at the 
interface of the
*    stator airgap and the moving band. If for example one pole is 
modelled the
*    Region Stator_Bnd_MB typically consists of one line.
*
*  Rotor_Bnd_MB (defined in getDp Group object)
*    Similar to Stator_Bnd_MB is Rotor_Bnd_MB a region defined by 
physical lines.
*    Even if not all poles are  modelled, the lines must define the
*    boundary between the rotor airgap and the moving band for the
*    complete electric machine (all poles). The corresponding lines are 
created
*    in gmsh and are for example called rotor_moving_band (line inside the
*    one pole modell) and rotor_moving_band_aux_x (lines outside the one 
pole model,
*    x is a number e.g. x=  1..3).
*    All lines are collected in the Rotor_Bnd_MB region.
*    To apply periodic constraints on the moving band there must be also 
a Region
*    for each line (e.g. rotor_moving_band       => Region Rotor_Bnd_MB_1,
*                        rotor_moving_band_aux_1 => Region 
Rotor_Bnd_MB_AUX_1,
*                        rotor_moving_band_aux_2 => Region 
Rotor_Bnd_MB_AUX_2,
*                        rotor_moving_band_aux_3 => Region 
Rotor_Bnd_MB_AUX_3)
*
*  SymmetryFactor (could for example be defined by a onelab parameter)
*    SymmetryFactor is the number of poles of the complete machine 
divided by
*    the number of poles in the model
*    SymmetryFactor = NbrPolesTot/NbrPolesInModel ;
*    For a four pole machine:
*    SymmetryFactor = 1 -> the complete machine is modeled
*    SymmetryFactor = 2 -> half of the machine is modeled
*    SymmetryFactor = 4 -> one pole is modeled
*
*  Meshing:
*     The user has to define the number of elements on the interface lines
*     rotor_moving_band, stator_moving_band and rotor_moving_band_aux.
*     This number must be the same for all lines. This can be achieved by
*     using the transfinite line command in gmsh.
*
*  Constraints:
*     The following has to be done in the getDp constraints object:
*     ? The degrees of freedom of the moving band line elements outside the
*     model area has to be linked to the degrees of freedom inside the 
one pole
*     rotor model. ? TODO
*
*  The following commands has to be inserted in the getDp object Resolution
*   InitMovingBand2D[MB]
*     No explanation - TODO
*   MeshMovingBand2D[MB]
*     Mesh operation. the moving band itself is not meshed by the user. 
This is
*     done during the getDp resolution process.
*
*  from getDp archieve ("Torque and force calculation based on Virtual 
Work prinzip")
*  InitMovingBand2D [MB], initialises the structures of the Moving Band.
*  MeshMovingBand2D[MB], does the actual mesh between the indicated 
limiting lines
*
*  Change of Coordinates - TODO
*  ChangeOfCoordinates[NodesOf[Region to rotate], transformation]
*
*  Limitations:
*  - The moving band tool in GetDP works with first-order triangular 
elements only
*  - limited to 2D
*
* References
* [1] N.Sadowski: FINITE ELEMENT TORQUE CALCULATION IN ELECTRICAL 
MACHINES WHILE
*                 CONSIDERING THE MOWEMENT, IEEE TRANSACTIONS ON MAGNETICS,
*                 VOL. 28, N0.2, MARCH 1992, p. 1410 - p. 1413
* [2] Onelab: Machine modells pmsm_data.geo pmsm.geo pmsm_rotor.geo
*             pmsm_stator.geo pmsm.pro, available on www.onelab.info */

/*</f1>*/


Am 27.11.20 um 18:44 schrieb Théodore CHERRIÈRE:
> Dear GetDP users,
> I'm new to OneLab, and I'm trying to calculate the average torque of 
> electric machines. I wrote my own .pro file for this after following 
> the tutorials, it works but it is quite slow. For example I 
> couldn't reuse the last iteration solution to initialize the 
> Newton-Raphson solver ; and I simulate the motion with hand-made 
> periodic boundary conditions while there are far better existing 
> implementations like the moving band.
>
> I took a look at the dedicated template, but I didn't find any 
> documentation to run it from scratch. I especially want to understand 
> how to use the moving band implementation. Can someone help me please?
> Best regards,
> Théodore CHERRIÈRE |/  Doctorant /
> Département EEA - Laboratoire SATIE, UMR8029
> Pôle CSEE - groupe de recherche SETE
> +33(0)6 42 39 83 82 <tel:+33642398382>
> ENS Paris-Saclay - 4 avenue des sciences 91190 Gif-sur-Yvette 
> <geo:///?q=%204%20Avenue%20des%20Sciences%20Gif-sur-Yvette%20France>
> www.ens-paris-saclay.fr <http://www.ens-paris-saclay.fr/>
>
> _______________________________________________
> getdp mailing list
> getdp at onelab.info
> http://onelab.info/mailman/listinfo/getdp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://onelab.info/pipermail/getdp/attachments/20201129/869f3ece/attachment.html>


More information about the getdp mailing list