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
EM_levitation
Re: EM_levitation
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
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
-
- Site Admin
- Posts: 4812
- Joined: 22 Aug 2009, 11:57
- Antispam: Yes
- Location: Espoo, Finland
- Contact:
Re: EM_levitation
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
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
Re: EM_levitation
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
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
Re: EM_levitation
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
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
-
- Site Admin
- Posts: 4812
- Joined: 22 Aug 2009, 11:57
- Antispam: Yes
- Location: Espoo, Finland
- Contact:
Re: EM_levitation
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
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
Re: EM_levitation
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
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
Re: EM_levitation
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
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