EM_levitation

Numerical methods and mathematical models of Elmer
Roland
Posts: 226
Joined: 12 Apr 2018, 11:29
Antispam: Yes

Re: EM_levitation

Post by Roland »

Hi Peter,
After comparing your levit.sif file, for which the solution is perfect and there is no mesh nodes overlapping in the bottom area of the liquid charge, and my case.sif file which is made with the GUI and, as I explained it in my former post, where the solution shows a mesh nodes overlapping in the bottom area of the liquid (on the symmetry axis), I saw that you have added the 2 following command lines in your file (which are not in my file):
1/ In the Navier Stokes solver 3: you have added "Internal Move Boundary = Logical False"
2/ In the Boundary condition 2 (the "FSI" BC): you have added: "Free Surface = True"
When I add manually these 2 additionnal lines in my case.sif file then the solution is also perfect and there are no more mesh nodes overlapping!
So please, could you explain what are these 2 command lines, is there something about that in the documentation, and at last how is it possible to enter these 2 additionnal command lines with the GUI ?
It would be very kind of you if you can give me some explanations about that because this seems to be the "secret trick" for getting a perfect solution, and I would really like to better understand this in order to be able to apply this in the next models.
Thanks in advance for your help and we keep us informed.
BR , Roland
Roland
Posts: 226
Joined: 12 Apr 2018, 11:29
Antispam: Yes

Re: EM_levitation

Post by Roland »

Hi,
In addition of what I said in my former post I saw also that in your levit.sif file,Peter, which gives a very nice solution of the EM levitated liquid charge, that you entered the following comand line in the simulation section: "Set Dirichlet BCs by BC Numbering = True".
When I add this command line and the 2 other command lines mentionned in my former post in my EM_levitation model (which I made with the GUI), then it gives also a very nice and realistic solution, and there are no more mesh nodes overlapping (which I got before entering these 3 command lines).
The problem is that I don't know what these 3 command lines really mean and how they act...!
So, to summarize, can you please, Peter, or anybody else who has already used this, give some explanations about the 3 following command lines:
1/ in the simulation section: " Set Dirichlet BCs by BC Numbering = True"
2/ in the Navier Stokes solver: "Internal Move Boundary = Logical False"
3/ in the "FSI" Boundary Condition for the liquid free surface: "Free Surface = True"
Thanks in advance for any help about that!
Roland
raback
Site Admin
Posts: 4812
Joined: 22 Aug 2009, 11:57
Antispam: Yes
Location: Espoo, Finland
Contact:

Re: EM_levitation

Post by raback »

Hi Roland,

1) The mesh displacement is the suggested displacement projected to the normal direction. At axis we know by contruction that there should be no displacement in x because of symmetry. Usually conflicting boundary conditions are not a problem. Here however we should be sure that the symmetry prevails. This is not usually guaranteed as the boundary elements are set in order of apperance. This keyword ensures that the symmetry Dirichlet condition is the last set and therefore wins.

2 & 3) This is historical and refers to a free surface solver that is inside the FlowSolver. We don't use this. Also the Free Surface needs to be set if the "Surface Tension Coefficient" is to be considered. I actually eliminated these keywords in the future but if you have an old code you have to use these to have surface tension be active. In the updated version it is enough to have the surface tension present.

-Peter
Roland
Posts: 226
Joined: 12 Apr 2018, 11:29
Antispam: Yes

Re: EM_levitation

Post by Roland »

Hi,
Now that the EM_levitation model works well in 2D_axi, I would like to make its extension in 3D.
Here attached is a sketch of this 3D model geometry which shows the initial spherical liquid charge set between a one turn conical lower coil and a one turn conical upper counter coil , these two coils beeing simple closed loop inductors in which we impose a given azimuthal current density. This means that there is no need of the "V" scalar potential variable, and only the "A" vector potential variable is needed.
As the MgHarm solver uses basically the two variables "V" and "A", is there a possibility to have this solver work only with the "A" variable?
Thanks for advance for any help.
Roland
Attachments
3D_EM_levitation_model.JPG
(102.79 KiB) Not downloaded yet
Roland
Posts: 226
Joined: 12 Apr 2018, 11:29
Antispam: Yes

Re: EM_levitation

Post by Roland »

Hi,
As discussed before, after the 2D_axi EM_levitation model which works nicely, I made its extension in 3D.
The two conical lower inductor and upper counter inductor are both fed on their ends by a 200 Volts voltage and give very realistic EM (electromagnetics) results (current densities, magnetic flux density, etc...). The coupling of the EM with the Mesh_Update and the Navier Stokes solvers give the first levitation results which are very promising, as showed in the here attached animation (from t=0s until t=0.05s/after unzipping the file, right_click on it and choose "open with Windows Media Player"): the liquid charge goes nicely upward due to the levitation forces, then is repulsed downward by the upper conical counter inductor, but then the mesh of the charge "explodes" and becomes completely crazy.
I tried several improvements like mesh refinement, and smaller time steps, but it does not change the behaviour: after a few time steps the mesh becomes crazy. There seems to be something wrong with the mesh_update of the liquid free surface which does no more follow the normal projection of the Navier Stokes velocity...
The GUI EM_levitation project is also joined to this mail.
It would be very nice if somebody could take a look at this and suggest something which could fix this problem!
Thanks in advance
Roland
Attachments
GUI_EM_levit_3D_AV.zip
3D_EM_levitation GUI project
(834.78 KiB) Downloaded 75 times
3D_EM_levitation.zip
3D_EM_levitation animation
(92.92 KiB) Downloaded 78 times
raback
Site Admin
Posts: 4812
Joined: 22 Aug 2009, 11:57
Antispam: Yes
Location: Espoo, Finland
Contact:

Re: EM_levitation

Post by raback »

Hi Roland,

You have done great work in trying to push this complex problem into 3D! I had a look at the sif file but could not find anything suspicious. Maybe you could try to compare step-by-step with the 2D version and check whether things look similar after 1st timestep, 2nd etc.

Some tolerances where quite strict (particularly for the WhitneySolver). You could maybe study the output and check that there are no Warnings or something suspicious. The code will continue even without nonlinear convergence but results may not be good.

I have not been terribly optimistic that this would work well in 3D since the CFD problem with the free surface is rather demanding. It is of course much more costly but also there are additional modes of movement in 3D when compared to 2D. These may make the simulation harder to converge.

-Peter
Roland
Posts: 226
Joined: 12 Apr 2018, 11:29
Antispam: Yes

Re: EM_levitation

Post by Roland »

Hi Peter,
Thank you for your answer.
I will follow your advices and investigate this thing a little more.
We keep us informed
Best regards and thanks again for your help
Roland
Roland
Posts: 226
Joined: 12 Apr 2018, 11:29
Antispam: Yes

Re: EM_levitation

Post by Roland »

Hi Peter,
As discussed I made some further investigations in the 3D EM_levitation model (like mesh refinement, time step decreasing, linear and non linear tolerances decreasing, etc...). But the behaviour remains always the same: the charge levitation starts very nicely but after several time steps the mesh explodes.
As you suggested it, at each time step, I looked at relevant entities like the Navier Stokes velocity vectors "v" and the Normals vectors (which, according to your explanations, are calculated in the ComputeNormals solver from "v" by: (v*n)*n*dt ).
And there I saw something strange: here attached are the Velocity vectors and Normals vectors respectively at t=0.04s (where the levitated charge shape is still correct) and at t=0.09s (where the mesh has exploded and the charge shape becomes completely crazy and uneven) / note that these images are plotted with Elmer VTK which does not display the charge deformation itself / the real charge deformation is displayed by Paraview).
When looking at these 4 images we see that:
- at t=0.04s, Velocity vectors are very even and the corresponding Normals vectors are also very even and really normal to the surface.
- at t=0.09s, Velocity vectors are still very even but the corresponding Normals vectors are no more even and neither normal to the surface for most of them!
Does that mean that there is a problem in the computation by the ComputeNormals solver of the normal velocity projection ? Meaning how is it that (at t=0.09s) the velocity vectors are still very even and that the corresponding Normals vetors are no more perpendicular to the surface?
So,please, Peter could you give your opinion and comments about that and have you perhaps an idea of how this could be improved and fixed? I am sure that we are very close from a complete working of this model...!
Thanks in advance for your help.
Roland
Attachments
Velocity_Normals.zip
Velocity and Normals vectors at t=0.04s and t=0.09s
(774.05 KiB) Downloaded 80 times
Post Reply