[NF] New magnetic workflow: transient resolution (for MagElmer at least)
Opened this issue · 7 comments
Hello,
The aim is to talk about a new magnetic worklow that can call Elmer to perform transient magnetic simulations.
Following a post of @SebGue in #200, the aim is to agree on how to choose a specific magnetic workflow, among at least magnetostatics (=steady state/transient) for MagFEMM and magnetodynamic (=transient) for MagElmer. One can also think of magnetoharmonic and there are probably others. Currently there is no need to state on other than transient.
In MagFEMM it is only possible to run magnetostatics simulation in pyleecan at the moment (besides, FEMM can also perform magnetoharmonic (mono harmonic) resolution). Presently, MagFEMM can already be used to perform either steady state or transient simulations depending on the currents and rotor position that we pass in Input.elec. Since it is magnetostatics, MagFEMM can't calculate transient effects such as induced currents for example (for magnet losses, for SCIM etc.).
For MagElmer I don't know how much magnetostatics is different from magnetodynamics, and whether it is necessary to split both solver types in two MagElmer models (e.g. MagElmerSta / MagElmerDyn).
-
If not, I propose to define a "type_solver" attribute in Magnetics class that is a string among "static", "transient" (or "dynamic" as you wish), and "harmonic", and that we check in MagElmer.comp_flux_airgap() to set up correctly the solver. This "type_solver" attribute also makes sense for MagFEMM if we do magnetoharmonic one day, since there is no big change in solve_FEMM to do static or harmonic analysis.
-
If yes, then we don't need this type_solver yet in Magnetics object, we have to build both classes MagElmerSta / MagElmerDyn and call the good object in the simulation workflow.
@ajpina, @SebGue, would you have any input on this ?
Best regards,
Emile
Hello Emile, you may wait for some feedback, but I didn't had time yet.
If it's okay to you I will answer this evening. BR S
Hello Emile,
I prefer the first solution with the additional Magnetics property 'type_solver'. Otherwise there will be classes with a lot duplicate code for no reason as you also stated. The current MagFEMM will then be 'static' (as there is no harmonic implementation yet).
As for the details on the Elmer workflow, I couldn't contribute much for now, since I haven't used it yet.
But I found some very interessting publication respectively tutorial on IM simulation with Elmer. Do you have some idea where we could collect such information, maybe on pyleecan.org?
Best regards, Sebastian
Hello Sebastian,
Regarding where to put publication and reference, I would say in run method of the model, in tests, in issues and on pyleecan.org but we need to find a new way to organize the website for that (open for idea on this point). What about gathering the data on pyleecan.org and adding the links in the other places I mentioned ? Sharing good publications and discussing about models is the first step to contribute to pyleecan. What about creating a "publication library" on pyleecan.org ?
By the way, in few days we should reorganize the "media" part to gather video, publications, images for pyleecan.
Best regards,
Pierre
Hi,
You guys have a better picture of the overall architecture of pyleecan and I am sure that you can split the objects/methods in a proper way. I would prefer to keep the methods for creating static or transient problems in different functions (for the same MagElmer object) rather than dealing with those in a single function. Harmonic analyses are useful for Induction machines but for the moment I can commit to work on the settings for solving synchronous PM machine models. After, by following the publication/tutorial above suggested, the settings for solving IMs can be extended.
Regarding post-processing, Elmer writes the mesh and results in VTU file format so I was thinking on dumping those into a MeshVTK/MeshSolution objects to calculate for example flux linkages. Electromagnetic torque and airgap flux density can be treated in a different way.
So I will wait for you guys to decide the best way to implement this while being compatible with your plans for MagFEMM future approach. I saw the skeleton created by @SebGue and I am fine with it if you all agree that's the best way to move forward.
Best,
Alejandro
Hello Alejandro,
Converting VTU files to MeshVTK/MeshSolution is a good idea, that way we will be able to reuse all the work on the mesh (post-processing, losses computation...).
Emile is reorganizing the Magnetic module organization in #206 we will have to reorganize the Elmer skeleton according to this new organization.
Best regards,
Pierre
Hello Alejandro,
do you have an idea when you will be able to contribute your work. I just ask because if you want to start immediately, I would propose you are using the actual skeleton and I will adapt it to the new organization after you finished. Else I will update the skeleton first.
What do you think?
BR, S