MagElmer Coupling

[schnib]

Hi, I would like to use pyleecan to run a magnetic simulation in Elmer.

To get started, I had a look at the MagElmer test cases . The simulation setup of test_ipm_Elmer is almost the same as the FEMM setup in this tutorial, but the results look quite different (0 average torque, weird flux contour plots, etc). test_spm_Elmer also creates 0 average torque and the Elmer geometry looks different from the pyleecan drawing. Is there something going wrong with the magnetic Elmer coupling for these 2 test cases?

I noticed that the magnetic Elmer coupling is only supported for IPMSM and SPMSM. Do you have a rough idea of what steps would have to be taken to implement the coupling for a different machine type, such as WRSM, or ideally even a user defined machine?

Thanks

[SebGue]

Hello Schnib,

there are indeed some issues with MagElmer. I'm already working on some code corrections. You could try to set a very low speed for now. Since MagElmer is a magneto dynamic simulation and conductors in the slots are not stranded yet there is significant proximity effect otherwise.

Actually I haven't tried other machine types but I saw in the code at least rotor current are not set. Did you get other errors for e.g. WRSM? I guess geometry issues will be related to draw_gmsh function which need some fixes as well.

If you want to help we would greatly appriciate that.

Best regards, Sebastian

[gforti84]

You can use https://github.com/ElmerCSC/elmer_circuitbuilder the set stranded (or foil) windings.

[schnib]

Hi, @SebGue: So the only reason why the results are different from the FEMM simulation is the fact that the conductors are not modelled as stranded? Or are there any other issues in addition to that?

There's 2 issues with the WRSM machine:

1. MagElmer.solve_FEA raises an error if the machine type is not IPMSM or SIPMSM. But presumably the rotor windings could be implemented in a similar way to the stator windings?
2. The geometry created by gmsh is not correct, there are some parts missing and labels wrongly assigned (I tried the Renault Zone machine from the templates). I haven't looked at the draw_gmsh function properly yet, so I'll see if I can figure out what's going wrong there when I get around to that.

@gforti84 : Are you saying I could define the stranded windings using elmer_circuitbuilder and then copy/paste them into the sif file created by pyleecan to get the expected output?

Thanks

[SebGue]

Hello schnib,

I don't know if thats the only reason but the eddy current in the massive conductors distorts the field a lot. So if you can run a test with very low speed (e.g. 1 rpm) or even create some test file to compare MagFEMM and MagElmer would really help, since I don't know when I will have time to do that.

Regarding WRSM:

1. We could remove this error and see what's happening :-) With windings, you are right. I already started to work on windings but I can't promise I will end it in time. But I will try.
2. In my opinion draw_gmsh need some general changes, i.e. a switch to the OCC kernal to fix other issues as well. But I will also try the Zoe machine. Maybe there are some small intermediate changes to get it running.

@gforti84 Thanks for that hint. I know there are a lot solvers and utilities in Elmer, but wasn't really aware of that python tool.

@schnib If you could try this copy/paste method, see if it works and send the respective sif, I can have a look if we could implement that straight forward.

Best regards, Sebastian

[schnib]

Hi Seb, I just quickly checked running the case at a very low speed and the output torque still converges towards 0. I'll have a proper look at the results tomorrow to see if I can figure out what's going wrong. I'll also try adding the stranded windings to see if that helps. Thanks

[schnib]

Hi, Is this assignment of the sliding mortar boundary conditions correct? I would have expected SB_STATOR to be the line adjacent/coincident with SB_ROTOR.

I am also getting different BCs in the pyleecan_elmer.sif file depending on which pyleecan version I use. If I install pyleecan through pip the rotor/stator mortar BC definition looks correct. If I clone it from github no mortar BC gets assigned (view attached sif files).

Thanks github_sif.txt pypi_sif.txt

[BonneelP]

Hello all,

Regarding WRSM, the first correct simulation with FEMM was done with https://github.com/Eomys/pyleecan/pull/557 in September. So when MagElmer was added, WRSM were not working in pyleecan. I think that drawing the machine should be straight forward but you will need to had a code to set the rotor current from Ir/If (you can check the FEMM equivalent). By doing that you should also enable the simulation of SCIM machines :)

Regarding the sliding band, here is how FEMM handles it: Boundary conditions are set on the red arcs.

Best regards, Pierre

[SebGue]

Hello all,

I would also expect the airgap boundaries to be coincident in contrast to FEMM. @ajpina Could you help with this question?

Regarding the respective line names, there maybe some bug due to changes in naming conventions. I will have a look at my MagElmer branch since I did some label corrections there. So maybe this is already solved (but not PRed).

@schnib Could you tell the pyleecan versions (correct sif and incorrect). So we can compare changes more easily.

Best regards, Sebastian

[SebGue]

... I checked my branch and labels seem to be okay.

Further the flux density seems resonable and also the torque in scalars.dat is non-zero.

So you could pull my branch and see if this at least solves some of your issues.

Edit: The simulations is the ipm from test_magelmer.py with low speed, i.e. 1 rpm.

Best regards, Sebastian

[schnib]

@schnib Could you tell the pyleecan versions (correct sif and incorrect). So we can compare changes more easily.

Correct sif: pyleecan 1.4.0 installed through pip from pypi Incorrect sif: Current pyleecan version cloned from github (master, commit 2fa1126).

So you could pull my branch and see if this at least solves some of your issues.

Which branch is that? I tried [CC]-ForceTensor and set the rotational speed to 1rpm but the results are still the same:

Thanks

Edit: What Elmer and gmsh version are you using? Elmer v9.0 and gmsh 4.4.1 for me.

[SebGue]

Its branch MagElmer on my fork of pyleecan (commit 3c025d1)

gmsh is 4.7.1 and Elmer is also v9.0

[ajpina]

Hi, If I am not mistaken, the air gap for Elmer was implemented in PR #236 and it's not the same as FEMM. I implemented it in the way that it works better for Elmer solver. So don't expect to see similar meshing in FEMM and Elmer. Hope that helps, Alejandro

On Wed, Nov 2, 2022, 8:11 AM Sebastian Günther @.***> wrote:

Hello all,

I would also expect the airgap boundaries to be coincident in contrast to FEMM. @ajpina https://github.com/ajpina Could you help with this question?

Regarding the respective line names, there maybe some bug due to changes in naming conventions. I will have a look at my MagElmer branch since I did some label corrections there. So maybe this is already solved (but not PRed).

@schnib https://github.com/schnib Could you tell the pyleecan versions (correct sif and incorrect). So we can compare changes more easily.

Best regards, Sebastian

— Reply to this email directly, view it on GitHub https://github.com/Eomys/pyleecan/issues/568#issuecomment-1300245749, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHYYMBO2LKPRCPZJRAND6LDWGJK6HANCNFSM6AAAAAARRCIYDU . You are receiving this because you were mentioned.Message ID: @.***>

[SebGue]

Hello @ajpina ,

thanks for you quick response. I'd expected that there is no gap between rotor and stator sliding band. So can you confirm, that Elmer can handle this gap properly? Best regards, Sebastian

[ajpina]

Hi, It should work with gap or without it between the sliding bands as long as the two boundary conditions are there. If those bands overlap, they should "appear" as "conformal meshing". But I see in the github_sif.txt file above shared that there is no SB_STATOR_BOUNDARY, so something is preventing pyleecan from writing that condition. Best, Alejandro

[schnib]

Hi,

Its branch MagElmer on my fork of pyleecan (commit 3c025d1)

Thanks for sharing this. I am getting the same flux plot as you now and the sliding band BC assignment is working correctly as well (view attached sif). SebGue_sif.txt

I am still a bit confused about the torque results. This is the plot generated from the output object:

And these are the torque values saved into scalars.dat:

Shouldn't they be the same? Looks like the scalars.dat is just the single period multiplied by a constant factor, but I am not sure where that factor comes from?

[SebGue]

Hello,

the simulation utilizes time periodicity, i.e. is_periodicity_t=True.

Elmer 2D results should be on a per meter basis. So there will be a difference. The factor should be something like "FEA model periodicity * machine length" which seems not to be the case here.

Further it seems that there is a mismatch between rotor and stator frequency.

I will try to check this issues later. But you can also check if the respective currents in 'test_magelmer.py' are the same as in the sif file, so there is not a convertion issue. And you could check if the rotation direction make sense.

[SebGue]

Hello @schnib

I found another issue and corrected it in my latest commit. There was incorrect magnetization direction in case rot_dir == -1. Also machine length was multiplied twice with raw torque. Still there is a difference between 'group 1 torque' and 'airgap torque' in scalars.dat but I don't know why. So we got to compare results with FEMM in any case.

Best regards, Sebastian

[schnib]

Brilliant, thanks a lot @SebGue The difference in torque between the methods is only ~1%, that doesn't seem too bad if different methods are used for calculating them. I'll have a look at comparing it vs the FEMM results (torque results look similar at first sight now). Thanks

[schnib]

Hi, the torque results between Elmer and FEMM match reasonably well:

I tried to have a look at the flux contours as well, but whenever I try to plot them I got the following error message: cannot import name 'vtkExtractEdges' from 'vtkmodules.vtkFiltersExtraction'. Upgrading pyvista to the most recent version got rid of that. Any idea why it has to be <=0.31.3? But I ended up getting some other graphics related errors and gave up at that point.

What would be the best way forward for me for implementing the coupling for other machine types? Fork @SebGue's branch and go from there? Do you foresee any issues trying to get this to work for all machine types that are currently supported by pyleecan?

Thanks

[schnib]

I played around with a few different machine types and for most of them the machine geometry and mesh is being created correctly in gmsh, but the sliding bands are usually not.

The way the rotor and stator lines bounding the airgap are calculated in get_sliding_band looks very specific to one geometry, so I can see why this fails. Is there a clever way to automatically detect the lines bordering the airgap in pyleecan?

An easier way to create the sliding bands would be through boolean operations (draw a circle/arc) and subtract the laminations, but that would require switching the gmsh kernel to Open Cascade and rewriting draw_gmsh completely, right?

[SebGue]

I also think OCC kernal would be better choise to get rid of some issues. But as you meantioned we may need to rewrite draw_gmsh completely.

However, if you could upload at least one of your failing machines, I will try to find some fix for now. (With pyleecan default machines, e.g. Zoe or ETron, I get some line loop errors while exporting to gmsh.)

[schnib]

One of the machines that failed was this IPM: Sasaki_Igarashi.json.txt However, I think that was down to a bug regarding the active slot height calculation for SlotW18. Changing the calculation of Ztan2 in SlotW18.comp_height_active to be the same as in comp_height enabled me to mesh the machine correctly.

The Reanult_Zoe template generates a mesh for me in gmsh, but ROT-0-Lam and ROT-0_AirgapBot are not being generated correctly.

The Railway_Traction template fails to generate ROT-0_Lam, ROT-0_AirgapBot, None_SlidingBandBot, None_SlidingBandTop and None_Airbox is created incorrectly.

I also tried this Switched Reluctance Machine: SRM_6-4.json.txt This gets generated fine, except for the sliding bands and surrounding air, which have not been implemented for a non-symmetric case. That one is probably the easiest to fix.

[SebGue]

@schnib Are you able to use "export to GMSH" in the GUI with these machines? I get errors regarding wrong line loops.

[schnib]

Sorry, only just seen this. In 1.4.0 SRM is being generated, Sasaki and Railway_Traction fail with a wrong line loops error. The "Draw in GMSH" button seems to be greyed out for all machines in 1.4.1 now, so not sure about that.

[BonneelP]

Hello,

Regarding the gmsh button, are you referring to the exe version of the GUI for both version or are you using the code/pip version ? This button is disabled if the gmsh package is not available so there may be an error in the exe generation process or in the pip install to get gmsh.

Best regards, Pierre

[schnib]

You're right @BonneelP, I forgot to install the gmsh-sdk module when updating to 1.4.1, The GUI button isn't greyed out anymore now. In 1.4.1 the Sasaki machine gets generated, but Railway_Traction fails with the following error: 'Arc2' object has no attribute 'is_trigo_direction'.

[ajpina]

Pull request #600 has been submitted and now more example geometries in pyleecan will be successfully converted as gmsh files.