Electromagnetic Machine Simulation (Quasi-Poisson Equation in Multiple Domains) Setup

[Baoyun Ge]

Hello,

My background is electric machines.  I am doing independent research in my free time.  I have a conference paper to submit in a month, which requires me to do finite element simulation.  I have gone through some of the tutorial programs in dealii and I feel it's very promising for my need.

The setup of the system is actually not that complicate.  However, I didn't find much relevant documentation/posts in my area, so I decided to ask some guidance here.

Please see the following simplified diagram of the problem.  I also attached two images for better understanding.

Here are the details of the model:

1. A is the to be solved variable, it's a scalar in this particular problem.
2. J is the source, also a scalar.  It's nonzero only in the copper region.
3. mu_0 is the vacuum permeability and mu_r is the relative permeability of the iron material.
4. Left and right boundaries are periodic, i.e. the depicted model is part of a repeating structural.

Here are my questions:

1. What's the most appropriate/easiest way to setup the matrix for such a multi-domain problem in the dealii programming environment? 
2. In an actual electric machine, the air region is very thin, resulting a large aspect ratio.  What's the most appropriate way to mesh this region?
3. Any documentation/posts I can start with based on 1&2?

Also, I like programming and my long term plan is to participate in dealii's development, especially in the electric machine area if possible.

Thank you and Best Regards,

Baoyun

[Daniel Arndt]

Bayon,

What's the most appropriate/easiest way to setup the matrix for such a multi-domain problem in the dealii programming environment?

 

Essentially, you are solving a Laplace problem  with discontinuous coefficients. In case, there are no interface conditions between the different materials,

you should be good to just look at step-6 (and the previous tutorial programs of course) to begin with. For periodic boundary consitionsyou might want to have a look at step-45.

 

In an actual electric machine, the air region is very thin, resulting a large aspect ratio.  What's the most appropriate way to mesh this region?

We provide generators for a bunch of meshes in the GridGenerator namespace. In you case, I would make sure that each materials are not cut by cells.

You might want to merge triangulations via GridGenerator::merge_triangulations. With respect to the thin air region anisotropic refinement might be interesting (see https://www.dealii.org/current/doxygen/deal.II/step_30.html)

if you can't afford a suitably (isotropically) globally refined mesh.

Best,

Daniel

[Baoyun Ge]

Hi Daniel

Thanks for your prompt response and guidelines. After going through these examples, I have a better understanding now.

Best,

Baoyun

[Earl Fairall]

Dear Baoyun,

I too have been looking at this exact application. Building the mesh in deal.ii is difficult. Deal.ii only has some very fundamental shapes which require the use of boolean operations for increased complexity. This in itself is not challenging. The challenge is that the mesh nodes must line up exactly. This really requires a function which moves/merges/places nodes manually (i'm not sure if Deal.ii has such a "healing" function) or else an automatic mesh generator is required.  I have, at least temporarily, given up on Deal.ii meshing and started looking at Gmsh as a possible option for automatic mesh generation, but I would rather stay within the deal.ii framework if I can figure it out!

Earl

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups "deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dealii+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/e4082fe9-dcab-46cc-b38e-1adc87808733%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Wolfgang Bangerth]

On 6/4/19 11:01 PM, Earl Fairall wrote:
>
> I too have been looking at this exact application. Building the mesh in
> deal.ii is difficult. Deal.ii only has some very fundamental shapes which
> require the use of boolean operations for increased complexity. This in itself
> is not challenging. The challenge is that the mesh nodes must line up exactly.
> This really requires a function which moves/merges/places nodes manually (i'm
> not sure if Deal.ii has such a "healing" function) or else an automatic mesh
> generator is required.  I have, at least temporarily, given up on Deal.ii
> meshing and started looking at Gmsh as a possible option for automatic mesh
> generation, but I would rather stay within the deal.ii framework if I can
> figure it out!

We like to think of it as a feature :-) There are things we do well in
deal.II, like all of the finite element stuff, but we decided a long time ago
that we don't know enough about mesh generation and visualization (i.e.,
pre-processing and post-processing) that it is best if we leave this to the
experts. That's particularly true given that there is such high-quality
software out there for these tasks.

That said, the latest deal.II release has interfaces to gmsh built in. I
believe that you can now generate meshes internally, by calling gmsh under the
hood.

Best
W.

--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

[Baoyun Ge]

Hello Earl,

It's good to know I am not the only one from the machine area trying to use deal.ii ;)

Actually I was planning to use gmsh given my understanding of the deal.ii package. Again, it's good to have a confirmation from you.

Best Regards,

Baoyun

To unsubscribe from this group and stop receiving emails from it, send an email to dea...@googlegroups.com.

[Bruno Turcksin]

Earl,

On Wednesday, June 5, 2019 at 1:02:08 AM UTC-4, Earl Fairall wrote:

Dear Baoyun,

I too have been looking at this exact application. Building the mesh in deal.ii is difficult. Deal.ii only has some very fundamental shapes which require the use of boolean operations for increased complexity. This in itself is not challenging. The challenge is that the mesh nodes must line up exactly. This really requires a function which moves/merges/places nodes manually (i'm not sure if Deal.ii has such a "healing" function) or else an automatic mesh generator is required.  I have, at least temporarily, given up on Deal.ii meshing and started looking at Gmsh as a possible option for automatic mesh generation, but I would rather stay within the deal.ii framework if I can figure it out!

If you have a complex mesh, Gmsh is probably the way to go but if you have a mesh that is composed of simple geometries, you can use the Python wrappers to prototype the code (see here). It's a lot faster to try something in Python and you can either dump the mesh and reload it in C++ or once you have a working code, you can rewrite the code in C++

Best,

Bruno