[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