Geometry and Models in EMDtool: Quick notes

As a rough summary, model creation for EMDtool happend in three levels of abstraction:

  1. Raw geometry level: points, curves, and surfaces
  1. 'Component level': stator and rotor model components, for example
  1. 'Motor level': For example this common wrapper model for radial flux machines

Contents

Raw geometry representation

Geometries in EMDtool are represented with 3 classes:

Important details and notes:

Higher-level geometry objects

In practice, you will most of the time work with higher-level geometry objects; subclasses of the GeoBase class. These encapsulate all the components and functionality of e.g. a stator model under one object:

Geometry objects take most of the meshing trouble out of your hands; see the next points. In practice, it is recommended to subclass one of the geometry base classes (StatorBase, SlottedRotorBase, SynRotorBase, ...). For quick testing, the RadialGeometry class can be used directly, see this example.

Periodic / repeated geometries

Usually, it makes sense to only create the geometry for e.g. one rotor pole or one stator slot pitch only. In this case, the resulting mesh will be automatically replicated accordingly. For this to work,

Airgap surface

By default, Curves on the airgap surface (such as the outer surface of a normal inrunner rotor) should be named 'n_ag'.

Meshing

In practice calling the .mesh_geometry method is enough. Underneath, this method successively calls the .mesh_elementary_geometry and .replicate_elementary_mesh methods, which do exactly what the name suggests.

High-level Model objects.

Finally, the individual components such as a stator and a rotor would be wrapped under a Model object, most commonly a RFmodel. Let's call it motor. But why the third level of complication?

Well, the actual analysis/simulation tasks are usually not handcoded; instead the handy MagneticsProblem class is used. By wrapping all the motor-related information - the 'personality' of the motor inside the motor object, the same problem can be used to analyse very different motor topologies, say

Return

Back to index.