[NF] Linear elasticity simulation (coupling with Elmer)

[SebGue]

Hello,

I would like to announce that I will try to do a first linear elasticity simulation implement with coupling to Elmer. A detailed discussion will follow as I (hopefully) proceed with this feature within the next weeks.

BR, S.

[SebGue]

Hello,

meanwhile I made some progress on this issue and wanted to show my first promising results. Actually the Elmer case files are setup manually. Next I will setup respective pyleecan class and automate the the complete simulation process. This is also the point where some help is appreciated :-)

• Discuss the implementation in general and in detail (when I'm done with it)
• Get the results (e.g. vtu file) into pyleecan for post processing (@Superomeg4 Maybe you could help here?)
• Discuss about the pyhsics and model assumptions (e.g. senseful boundary conditions) BTW: At the moment I am mainly interessted in centrifugal force calculation as you can see from my results :-) but magnetic force calculations may be derived from that easily.

Fig. 1 - Disc rotating at 10 krpm (analytical verification can be found here)

Fig. 2 - slightly modified "IPMSM_A" rotor @ 10 krpm - vonMises stress - Elmer

Fig. 3 - Ref. calc. - vonMises stress - Fusion360

Fig. 4 - slightly modified "IPMSM_A" rotor @ 10 krpm - displacement - Elmer

Fig. 5 - Ref. calc. - displacement - Fusion360

So stay tuned :-) Best regards, Sebastian

[RaphaelPile]

Impressive ! Yes, I can help you on this topic. Maybe a dedicated branch on Pyleecan could be a good idea ?

BR

[SebGue]

Hello @BonneelP

I am going to reuse your XOutput internal methods. Is it necessary to have a return on the setitem and getitem methods? What are the actual return values?

BR, S.

[BonneelP]

Hello Sebastian,

setitem and getitem are standard python methods that enables to use the XOutput as a dict and as a list. With getitem, XOutput["Tem"] returns the corresponding DataKeeper from the xoutput_dict, XOutput[2] return the 3rd output from the output_list (if is_keep_all_output=True) setitem is the equivalent to set but I don't know why there are return statement in this method. I guess we should be able to remove them.

Best regards, Pierre

[SebGue]

Hello Pierre, and thank you. Of course getitem needs a return :) I meant delitem instead.

[BonneelP]

Makes more sense ^^" Same issue as for setitem, I think we can remove it as well ;) I just try it on a normal python dict object and both methods returns nothing/None. Thank you for noticing :) Best regards, Pierre

[SebGue]

Hello @Superomeg4

I imported an vtu file with MeshVTK class (even if I don't know if it is intended to, but I guess). You will find it attached. If I plot the mesh all the quadrangle elements (quad9) are plot as triangle elements. I don't know if this is valid or by accident?

To be able to plot you got to add the following line just before 'mesh.write' in get_mesh_pv mesh.point_data = {k.replace(" ", "_"): v for k, v in mesh.point_data.items()}

What I'm actually trying to do is to import the results into MeshSolution object. Do you think I should rather use MeshMat for that purpose?

Therefore I also started to setup respectiv Ref Element types (e.g. Quad9) although I don't know if there are needed to do so right now. (Maybe you could have a look at my last commit.)

BTW. MeshVTK is missing the method get_mesh

Best regards, Sebastian case_t0001.zip

[RaphaelPile]

Hello @SebGue ,

I imported an vtu file with MeshVTK class (even if I don't know if it is intended to, but I guess). You will find it attached. If I plot the mesh all the quadrangle elements (quad9) are plot as triangle elements. I don't know if this is valid or by accident?

Funny result. It is not intended, but it could be useful somehow. I will take a look at it. How did you load it ? With the path of the MeshVTK object ? Or directly reading it with meshio then enforcing the mesh_pv attribute ?

What I'm actually trying to do is to import the results into MeshSolution object. Do you think I should rather use MeshMat for that purpose?

Depends on what you intend to do. If you need to do some mathematical operations, then MeshMat is recommended. Anyway, it is easy to switch from one or another now, there are converts method (I can add a new one for MeshMat if you want).

Therefore I also started to setup respectiv Ref Element types (e.g. Quad9) although I don't know if there are needed to do so right now. (Maybe you could have a look at my last commit.)

I can give you a hand on the corresponding reference cell ("RefQuad9" ?) for shell elements.

BTW. MeshVTK is missing the method get_mesh

Actually it has been replaced by "get_mesh_pv" as it was intended for plot purpose (a similar method is in MeshMat). What would you need this method "get_mesh" for ?

BR

Raphaël

[helene-t]

Hi Sebastian,

Actually it was intended to be able to load other formats in MeshVTK, provided that meshio can open them. Regarding the plot of quad9 as triangles, this concerns either meshio or PyVista package. No manipulation is done on our side.

Best regards, Helene

[SebGue]

Hello Helene, hello Raphaël,

thank you for your respond. Yes meshio can import vtu. So I think, I will use it for import and convert it then. I am not quiet sure if I need the mentioned mathematical operations. What I want to do is to get the area that exceed a certain stress (similar to demagnetization which we should also implement). Since values are point data, I guess I have to do some calculation. (@Superomeg4 your help is greatly appreciated e.g. on reference cells :-) )

The get_mesh method was requested by convert method. But the branch may be not even with master.

BR S

[SebGue]

Sorry, I was wrong. get_mesh is used in get_point method of MeshVTK. I will try to fix this.

[SebGue]

@Superomeg4 Did you used the convert method successfully, since I get a further issue. The key of for key in connect_all is of type CellBlock and therefore connect = connect_all[key] throw an error.

[RaphaelPile]

@SebGue I haven't check it in a while. What do you mean by CellBlock ?

[SebGue]

CellBlock is the class of 'key'

[SebGue]

I just wonder if I could fix this without breaking existing code, since there is no unit test on convert method.

[RaphaelPile]

Did you use a MeshMat or a MeshVTK ? I have just spotted an inconsistency between both classes.

If you are using MeshMat, it is returning a list with: A dict cells containing connectivity sorted by cell type (e.g. cell["triangle"] return connectivity of triangles) nb_cell is the total number of cell (all type included) indice_dict is containing the indices (unique by definition) of each cell sorted by cell type.

I should update MeshVTK to match with this definition of get_cell.

And add a test as well ...

[SebGue]

As you may guessed it was MeshVTK.

If you could do it today, I will be glad. Otherwise I will do it (at least without test).

[SebGue]

@Superomeg4 Your MeshSolution seems to be feasable to store the data without further modifications. Thx for that.

There are 2 things I noticed.

1. Normalizations seems to be ignored. Should we enable it by default or have an addition parameter to set it?
2. plot_contour also doesn't raise an error or show a warning if input label doesn't exists. Instead it plot first dataset with the input label. So it may not be distinguishable if the plot data are the correct one.

[SebGue]

The deflection plot also seems to work (with little modification). Very nice! :-)

[ajpina]

Hi @SebGue, Can you share how you are loading the vtu file into MeshSolution object? I am getting some errors when doing so for the magnetodynamics results, I am probably doing it wrong. Best, Alejandro

[SebGue]

Hello Alejandro, I wanted to ask you anyway what you think of the Elmer class I jus started. It is to collect all common code related to Elmer IO to have a convienent way to access Elmer, since there will be even more Elmer coupling in the future (e.g. for thermal simulation).

Actually it is only in StructElmer branch on Pulblic repo. The code you are looking for is in 'pyleecan/Methods/Simulation/StructElmer/get_meshsolution.py' but there were some little corrections I had to do to MeshVTK as well. Also I need to move the respective common code to the Elmer IO class.

If you got some more days, I will start a PR of it. Best, Sebastian

[ajpina]

Hi, I can see the changes in MeshVTK, so I wonder why I have to read the VTU file with meshio and then write it in VTK (while removing the blank spaces) to read it again with pyvista. Couldn't it be possible to put an if clause for VTU format and skip the meshio conversion so it can be read directly with pyvista (no label conversion needed)? By the way, I will spend some time looking at your StructElmer functions, they look great and the Elmer methods to parse the sif files may come handy. Thanks, Alejandro

On Fri, 11 Dec 2020, 02:06 Sebastian Günther, notifications@github.com wrote:

Hello Alejandro, I wanted to ask you anyway what you think of the Elmer class I jus started. It is to collect all common code related to Elmer IO to have a convienent way to access Elmer, since there will be even more Elmer coupling in the future (e.g. for thermal simulation).

Actually it is only in StructElmer branch on Pulblic repo https://github.com/EOMYS-Public/pyleecan/tree/structElmer. The code you are looking for is in 'pyleecan/Methods/Simulation/StructElmer/get_meshsolution.py' but there were some little corrections I had to do to MeshVTK as well. Also I need to move the respective common code to the Elmer IO class.

If you got some more days, I will start a PR of it. Best, Sebastian

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Eomys/pyleecan/issues/231#issuecomment-743017653, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHYYMBIY5YYIFX45P4ZDNLDSUHAITANCNFSM4TP2PLXQ .

[SebGue]

Hello Alejandro,

:-) I had to look at it again to tell. It's a little bit tricky. At least that's what I figured out.

To get the mesh I use MeshVTK class, which therefore write it in VTK format. (I guess this is to also import other mesh formats. @Superomeg4 could tell that.). The culpit is, that included data in the VTU file are not allowed to have whitespaces in their names to write the VTK. If the VTK now is loaded with MeshVTK class, the data actually are not present in MeshVTK. So I load the data with another meshio call. I guess there are easier ways to get the data, but for now it seems to work. I think StructElmer has a lot more code that could be simplified and we should talk about that as soon as I PRed it.

Best regards, Sebastian

[SebGue]

Hello to everyone,

now this comment is to explain the details of the new structural simulation feature (StructElmer, PR #272). At the moment this simulation is only able to do centrifugal simulation with lamination only or 'HoleM50' lamination with magnets on a single pole (which should be sufficent for most use cases). Respective examples could be found in test file 'Test\Simulation\test_StructElmer.py'.

General notes:

• The respective PR introduces a new class Elmer to do the input/output with Elmer. I think this is the most convenient way to have unified Elmer interaction. Also I think this class is worth its own issue to discuss the details. (I still have to move the code to get the Elmer results there. Actually it is in get_meshsolution of StructElmer.)
• I have moved N0 (rotor speed) property to Input class so this class could be used as input to StructElmer
• We have to discuss the (common) properties that should be in OutStruct, since they may be very different depending on the type of structural simulation (e.g. centrifugal, magnetic force, ...)
• The only used output now is meshsolution.
• I changed comp_radius_mec of LamSlotMag to have lamination without magnets.

Technical notes:

• To determin the contacts of lamination and magnets, I utilize the line labels of the geometry. For now these labels are only set on HoleM50. Further the labels are really simple, e.g. 'Magnet_0_Left', 'Magnet_0_Top', ... With multiple poles the labels are not renamed so simulation is restricted to one pole. Further the contacts in Elmer are somehow 'hard coded', i.e. there is only contact at 'Magnet_0_Right', 'Magnet_1_Left' and 'Top' of both magnets. This has to be improved somehow to simulate 1 magnet and 3 magnet 'Holes' as well.
• With Elmer there are different ways to have multiple bodies that have discontinuities on their boundaries. With the current implementation I have actually seperated bodies but with conforming boundary nodes. This requires some additional processing on the original mesh (method is process_mesh). The contact is set by periodic boundary conditions (see physical notes).
• Futher improvement here could also enable to smooth the geometry, e.g. on sharp, critical corners to avoid (unphysical) singularities in the results.

Physical notes:

• The sides of the simulated lamination are 'fixed' in place by a 'no normal displacement' boundary condition to account for the periodicity of the lamination. There is no boundary condition on the inside which is true as long there is no dovetail key or glue fixing the lamination to the shaft.
• The contacts between lamination and magnets are to some extend unphysical. They are realized with periodic normal displacement boundary conditions. Tangential displacement is possible allowing the magnet to 'slide' along the boundary. The short coming with this is, that although the magnet may has moved, the pressure on the lamination is appied on the original (i.e. non displaced) position. So the results may only be valid for small displacements. Further this boundary condition 'glue' the magnet to the lamiation such that a bend of the pole is at least not fully developed (I may add some picture here to better explain.). This may also be okay since the main stress is in the small bridges of the lamination most of the time.
• The reason I choose this boundary conditions is that real contact simulation didn't converged at least with my simulations. Maybe someone with more experience can help here.

Improvements:

• I think next steps would be to improve the labels to enable all 'HoleMx' geometries.
• Further I think the simulations need some more settings or modulatization to also do other types of structural simulation or to set other boundary condition, e.g. to simulate glued magnets.
• Parallelization
• Add some test to compare results with analytical calculations.

Anyway, I really hope to have some discussion about this issue. So please give me some feedback even if it is only on one aspect.

Best regards, Sebastian

[ajpina]

Hi @SebGue , @Superomeg4 , I have this change in get_mesh_pv.py that is working for me as loading the vtu file into MeshSolution:

My vtu files also have Cell data, it means that @SebGue solution's by removing blank spaces from Point data before writing vtk files needs to be also done for Cell data. I guess the aforementioned change should work for ElmerStructural too without having to write vtk files.

There are two issues that I am facing right now: 1) I am able to load VTU point data into MeshSolution by following what @SebGue did in his get_meshsolution.py in StructElmer but I am not sure how to load the Cell data, could you advice?

2) I have a VTU file per time step, Should all these be loaded into the same MeshSolution object?

Best, Alejandro

[BonneelP]

Hello Sebastian,

Sorry for the answer delay, I finally have some time to take a look on this issue.

The respective PR introduces a new class Elmer to do the input/output with Elmer. I think this is the most convenient way to have unified Elmer interaction. Also I think this class is worth its own issue to discuss the details. (I still have to move the code to get the Elmer results there. Actually it is in get_meshsolution of StructElmer.)

I was also thinking about a class to normalize the parameters around FEMM (Kmesh_fineness, Kgeo_fineness, FEMM_dict...). There are some parameters that are not linked to the models but to the coupling so having a general object to store all the parameters to properly handle the coupling could be a interesting idea. In particular when the coupling is used in several models it avoids duplicating all the parameters.

I have moved N0 (rotor speed) property to Input class so this class could be used as input to StructElmer

On our side we were investigating using an InputCurrent as part of InputFlux or InputForces to define the Operating point

We have to discuss the (common) properties that should be in OutStruct, since they may be very different depending on the type of structural simulation (e.g. centrifugal, magnetic force, ...)

We already have an OutStruct, I will try to find some time to check how we can merge the two objects in a general way

I changed comp_radius_mec of LamSlotMag to have lamination without magnets.

I will change this method in SlotMerge as well (to have the possibility to have winding in the airgap). It would then be a method of LamSlot directly

To determin the contacts of lamination and magnets, I utilize the line labels of the geometry. For now these labels are only set on HoleM50. Further the labels are really simple, e.g. 'Magnet_0_Left', 'Magnet_0_Top', ... With multiple poles the labels are not renamed so simulation is restricted to one pole. Further the contacts in Elmer are somehow 'hard coded', i.e. there is only contact at 'Magnet_0_Right', 'Magnet_1_Left' and 'Top' of both magnets. This has to be improved somehow to simulate 1 magnet and 3 magnet 'Holes' as well.

We were also thinking about labelling the bottom line of all the magnets as a standard to get the magnetization direction cf #22. Maybe we can have a method to check if Hole lines overlap with Magnet lines to automatically set contact (but then the current hole definition could be an issue)

Do you think that once the code and the test will be Ok you can also do a small tutorial on this amazing feature ?

Best regards, Pierre

[SebGue]

Hello Pierre, you're welcome and thank you for your feedback.

If you could check OutStruct that would be great. Do you actually use OutStruct (internally)?

Regarding line labels I'm not satisfied yet, as mentioned above. Maybe I should adapt the surface 'Magnet_Rx_Tx' label with the 'Left', 'Right', ... added and then check magnet position to set contact. But I may only do that with some future PR. Before I should do the tutorial :-) For now I think you could merge the PR if it is okay to you. I may only move the get_meshsolution to Elmer class before. BR Sebastian

Edit: I may also close this issue and open a new one with the main TODO's.

[BonneelP]

Hello Sebastian,

I just check your PR #272 and here are few remarks:

• Tests/Validation/Simulation/test_EM_SynRM_FL_001.py : I thought that the parallelization issue were solve with #282. I will try to find some time to investigate what is going on.
• pyleecan/Generator/ClassesRef/Elmer/ElmerResults.csv : Why did you use a dict for "data" ? What do you store in it ? Is it possible to create a dedicated object or use a {ndarray} ? It would be more convenient to save/load the results
• pyleecan/Generator/ClassesRef/Output/OutStruct.csv : What about moving FEA_dict to struct.internal as we did for FEMM (if it do is a internal data). That way we can know if we can clean it before saving for instance.
• pyleecan/Methods/Machine/LamSlotMag/comp_radius_mec.py : This method will be updated with PR #283
• pyleecan/Methods/Simulation/MagElmer/init.py: Is there still the name length constraints for the label ?
• pyleecan/Methods/Slot/HoleM50/build_geometry.py: Ok for the renaming. This file is rather complicated, maybe we should take some time to reorganize it ? Introducing the _comp_point_coordinate and creating all the line only once (with name like L_1_12 for line from Z1 to Z12) before creating the surfaces can make it clearer I think. Then label should be easier to set/understand.
• For OutStruct, we are working on our side on the new version of our commercial software MANATEE so we use this object for vibroacoustic. We use an alternative version of the object which is linked to our models (WFRF). But if I understood your PR, you are mostly using meshsolution and ElmerResults to store your results so it is Ok for us.

Nothing major so we can merge it if you want. Thank you again for this feature :)

Best regards, Pierre

[SebGue]

Hello Pierre, you can merge it. For the remarks, I will answer it later. BR S

[SebGue]

Hello Pierre,

here are my answers to your points.

Tests/Validation/Simulation/test_EM_SynRM_FL_001.py : I thought that the parallelization issue were solve with #282. I will try to find some time to investigate what is going on.

This test only failed if I'd run multiple tests, i.e. 'pytest -m "not (GMSH or Force)". If I added 'DEV' marker and run it with few other tests, everthing seems okay. So ... ???

pyleecan/Generator/ClassesRef/Elmer/ElmerResults.csv : Why did you use a dict for "data" ? What do you store in it ? Is it possible to create a dedicated object or use a {ndarray} ? It would be more convenient to save/load the results

In Test/Data/StructElmer there are 2 .dat files showing the result format of Elmer (beside the case file). I thought each named column could be a key of the dict. Alternatively we could also use SciDataTool with components axis to store the quantities. Also see last point for ElmerResults.

pyleecan/Generator/ClassesRef/Output/OutStruct.csv : What about moving FEA_dict to struct.internal as we did for FEMM (if it do is a internal data). That way we can know if we can clean it before saving for instance.

I will have a look at FEMM implementation.

pyleecan/Methods/Machine/LamSlotMag/comp_radius_mec.py : This method will be updated with PR #283

Okay :-)

pyleecan/Methods/Simulation/MagElmer/init.py: Is there still the name length constraints for the label ?

Yes labels will be constrained till the next release, which may take some time as Alejandro told.

pyleecan/Methods/Slot/HoleM50/build_geometry.py: Ok for the renaming. This file is rather complicated, maybe we should take some time to reorganize it ? Introducing the _comp_point_coordinate and creating all the line only once (with name like L_1_12 for line from Z1 to Z12) before creating the surfaces can make it clearer I think. Then label should be easier to set/understand.

I will have a look at this method. Does this also address Alejandros issue with surface magnets?

For OutStruct, we are working on our side on the new version of our commercial software MANATEE so we use this object for vibroacoustic. We use an alternative version of the object which is linked to our models (WFRF). But if I understood your PR, you are mostly using meshsolution and ElmerResults to store your results so it is Ok for us.

Yes, I mostly use meshsolution for now. So we may reduce OutStruct to a minimal set of common/usefull properties and inherit for different purpose? ElmerResult is only thought as a helper class to load Elmer results into pyleecan.

Thank you for your helpful feedback.

Best regards, Sebastian