Hello Kevin, this has been explained by Peter when I was working on the EM_levitation model. He modified the "Compute Normal solver" so that it gives the components of the normal displacement(meaning velocity*dt) on the free surface.
What you say about the documentation is the same for the "PhaseSurface" variable : I still don't know exactly what this variable represents ( displacement of the nodes of the phase change interface, 2 components, or only 1 component, then which one...?).
At last, assuming that you have seen the former Comsol animation, how could it be possible to get the same smooth and nice mesh deformation in Elmer?
Thanks in advance for you comments and suggestions
Roland
Transient Phase Change Solver
-
kevinarden
- Posts: 2293
- Joined: 25 Jan 2019, 01:28
- Antispam: Yes
Re: Transient Phase Change Solver
The comsol mesh starts with a radius on it, this improves many things in the flow and meshing. Elmer will read a .mphtxt : Comsol Multiphysics mesh format. if you have that file, it may be a better starting point.
Re: Transient Phase Change Solver
Yes Kevin, you are completely right!
This is why I will modify the mesh(or try to import the Comsol mesh) in order to add a radius, which is indeed more coherent with the physical reality since it represents a meniscus of the liquid which"sticks" to the solid crystal (or seed). I am impatient to see what it will look like....
We keep us informed.
Roland
This is why I will modify the mesh(or try to import the Comsol mesh) in order to add a radius, which is indeed more coherent with the physical reality since it represents a meniscus of the liquid which"sticks" to the solid crystal (or seed). I am impatient to see what it will look like....
We keep us informed.
Roland
Re: Transient Phase Change Solver
Yes Kevin, you are completely right!
This is why I will try to add a radius to the geometry ( or import the Comsol file), which is more coherent with the physical reality since it represents a liquid meniscus which "sticks" on the solid crystal(or starting seed). We will see then how the mesh moves.....
We keep us informed
Roland
This is why I will try to add a radius to the geometry ( or import the Comsol file), which is more coherent with the physical reality since it represents a liquid meniscus which "sticks" on the solid crystal(or starting seed). We will see then how the mesh moves.....
We keep us informed
Roland
Re: Transient Phase Change Solver
Sorry for the answer duplication....!
I thought the 1rst one was not publicated...
Roland
I thought the 1rst one was not publicated...
Roland
-
kevinarden
- Posts: 2293
- Joined: 25 Jan 2019, 01:28
- Antispam: Yes
Re: Transient Phase Change Solver
1. In the Comsol animation boundary 4 is moving up and to the right with boundary 3 and 6. This is not happening in the Elmer simulation because boundary 4 is being update to the variable PhaseSurface. PhaseSurface is a very small number (-.000143) compared to the mesh update variable on boundary 3 and 6 (0.004) which is the normal (vdt). This is clearly not the case in the Comsol model.
2. Since the element at the triple point will always have a node on boundary 4 and a node on boundaries 3 and 6, this element will always be heavily distorted regardless of the mesh used. Since boundary 4 is basically held down to the variable PhaseSurface (a relatively small number) and boundaries 3 and 6 are moving to vdt (a relatively large number). This is not happening in the Comsol animation.
3. Updating boundaries to x=vdt will limit the time step size, since dt will always have to be a small number to avoid mesh distortion. The cast velocity is 0.05 so a time step size of 1.0 would mean a mesh update of 0.05 meters, which is the width of the whole model.
- meshupdate.png (416.53 KiB) Viewed 436 times
3. Updating boundaries to x=vdt will limit the time step size, since dt will always have to be a small number to avoid mesh distortion. The cast velocity is 0.05 so a time step size of 1.0 would mean a mesh update of 0.05 meters, which is the width of the whole model.
Re: Transient Phase Change Solver
Hi Kevin,
Still many thanks for your efforts! I feel less alone with your help and our discussions!
Concerning the cast velocity, 0.05m/s was just to try to speed up the casting but it is not physically realistic. Take rather v_cast=10mm/mn=0.15mm/s which is more realistic.
Concerning the mesh distortion which you mention, I guess that the problem comes from the fact that, if we know what means Normal1 and 2 for the update of boundaries 3 and 6(normals 1=v_1*dt, normals 2=v_2*dt), we don't know exactly what means the variable PhaseSurface which updates boundary 4, since this is not clear in the doc of the Transient Phase Change Solver. How could we find the exact meaning of this variable? Could perhaps Peter explain that? I guess that all the problem comes from this....
What do you think of this?
Still many thanks for your efforts! I feel less alone with your help and our discussions!
Concerning the cast velocity, 0.05m/s was just to try to speed up the casting but it is not physically realistic. Take rather v_cast=10mm/mn=0.15mm/s which is more realistic.
Concerning the mesh distortion which you mention, I guess that the problem comes from the fact that, if we know what means Normal1 and 2 for the update of boundaries 3 and 6(normals 1=v_1*dt, normals 2=v_2*dt), we don't know exactly what means the variable PhaseSurface which updates boundary 4, since this is not clear in the doc of the Transient Phase Change Solver. How could we find the exact meaning of this variable? Could perhaps Peter explain that? I guess that all the problem comes from this....
What do you think of this?
Re: Transient Phase Change Solver
Hi,
As discussed with you, Kevin, I changed the geometry of the crystal_growth model and added a meniscus in the contact area between the lower liquid and the upper solid, and also meshed the geometry with a quad mesh so that it looks quite the same as the Comsol one.
In order to simplify the things in a 1rst step, boundaries 1,5 and 7 (meaning the former free surface of the liquid and solid) are now considered as solid walls (meaning a no_slip BC for Navier Stokes) so that the geometry is like a bottle with the lower part beeing liquid and the upper par beeing like a freezed neck. Consequently the "ComputeNormal" solver is disabled since boundaries 1,5 and 7 are now solid walls and no more free surfaces.The v_cas velocity is also set to zero, so that only the solid/liquid phase change is considered (no crystal pulling velocity).The solver solves very nively with big time steps (2s for instance).
Here attached is the zipped GUI Elmer project and also a zipped animation (right clic on it and choose "open with" and choose VLC player or Windows Media Player).
According to the animation, the mesh moves nicely downward, corresponding to the increasing downward solidification of the upper solid phase. Unfortunately the boundaries 1, 5 and 7 (which should not deform since they are solid walls...!) are deforming (especially curved boundary 1). This is not correct since these 3 boundaries should not move and deform, but only the mesh nodes on these boundaries should glide along these fixed boundaries.
It would be very nice if somebody (Kevin or perhaps Peter...?) could take a look at this and give some comments about that.
Thanks in advance!
Roland
As discussed with you, Kevin, I changed the geometry of the crystal_growth model and added a meniscus in the contact area between the lower liquid and the upper solid, and also meshed the geometry with a quad mesh so that it looks quite the same as the Comsol one.
In order to simplify the things in a 1rst step, boundaries 1,5 and 7 (meaning the former free surface of the liquid and solid) are now considered as solid walls (meaning a no_slip BC for Navier Stokes) so that the geometry is like a bottle with the lower part beeing liquid and the upper par beeing like a freezed neck. Consequently the "ComputeNormal" solver is disabled since boundaries 1,5 and 7 are now solid walls and no more free surfaces.The v_cas velocity is also set to zero, so that only the solid/liquid phase change is considered (no crystal pulling velocity).The solver solves very nively with big time steps (2s for instance).
Here attached is the zipped GUI Elmer project and also a zipped animation (right clic on it and choose "open with" and choose VLC player or Windows Media Player).
According to the animation, the mesh moves nicely downward, corresponding to the increasing downward solidification of the upper solid phase. Unfortunately the boundaries 1, 5 and 7 (which should not deform since they are solid walls...!) are deforming (especially curved boundary 1). This is not correct since these 3 boundaries should not move and deform, but only the mesh nodes on these boundaries should glide along these fixed boundaries.
It would be very nice if somebody (Kevin or perhaps Peter...?) could take a look at this and give some comments about that.
Thanks in advance!
Roland
- Attachments
-
- CG_animation.zip
- (408.39 KiB) Downloaded 25 times
-
- CG_03_Elmer.zip
- (119.1 KiB) Downloaded 28 times
-
kevinarden
- Posts: 2293
- Joined: 25 Jan 2019, 01:28
- Antispam: Yes
Re: Transient Phase Change Solver
If you do not want the air body to move do not include the mesh update equation in it. This will fix the nodes that only belong to the air. However since the nodes on the boundary also belong to the silicone they will move. This is closer, but not exactly gliding along the boundary. If you want that the the air has to have its own nodes on the boundary separate from the silicon nodes. To transfer heat across a discontinuous you have to use mortar conditions.
Example case I created the left and right side separately in gmsh, converted to Elmer using ElmerGrid. Then united them inot one mesh using
ElmerGrid 2 2 left -in right -unitenooverlap -out mesh
Example case I created the left and right side separately in gmsh, converted to Elmer using ElmerGrid. Then united them inot one mesh using
ElmerGrid 2 2 left -in right -unitenooverlap -out mesh
Re: Transient Phase Change Solver
Hi,
Thanks for these elements. Say that, as boundaries 1,5 and 7 are considered as walls (just for the current test / after that they will again become free surfaces ok?) the nodes on these boundaries (if, in normal-tangential choice, MeshUpdate_1 = 0) should glide perfectly along these fixed boundaries which should not deform ok?
The air domain is here just for the future addition of the magnetic field, ok? Thus, for the current tested model (without mag field for the moment) I think I will suppress this air domain in gmsh and see what happens.
Thanks again and we keep us informed.
Roland
Thanks for these elements. Say that, as boundaries 1,5 and 7 are considered as walls (just for the current test / after that they will again become free surfaces ok?) the nodes on these boundaries (if, in normal-tangential choice, MeshUpdate_1 = 0) should glide perfectly along these fixed boundaries which should not deform ok?
The air domain is here just for the future addition of the magnetic field, ok? Thus, for the current tested model (without mag field for the moment) I think I will suppress this air domain in gmsh and see what happens.
Thanks again and we keep us informed.
Roland