Hello,
after running a simulation I get several corrupted elements on the right hand side of the computational domain. The left side of the box is identical with the same boundary conditions and elements there are fine. The corrupted element is on the intersection between two different bodies and boundary wall, cf. attached picture . I can't find out how could that be possible. too large time step? Mesh update solver together with phase change solver are involved.
Regards, Martina.
corrupted element
corrupted element
- Attachments
-
- corrupted_element02.pdf
- (145.64 KiB) Downloaded 346 times
-
raback
- Site Admin
- Posts: 4828
- Joined: 22 Aug 2009, 11:57
- Antispam: Yes
- Location: Espoo, Finland
- Contact:
Re: corrupted element
Hi Martina,
There may sometimes be a positive feedback between the interface shape and temperature oscillation. It is somewhat strange that you would get it only on the right if the case is symmetric.
As remedy you could test some of the keywords that stabilize the solution: "Stabilize", "Velocity Relaxation Factor", "Velocity Smoothing Factor". Two first ones are consistant while the third one introduces a small diffusion. The fact that several strategies were implemented tells that there indeed has been problems before. My memory don't serve me so well that I could directly suggest the best remedy. However, make sure that it doesn't affect your results.
-Peter
There may sometimes be a positive feedback between the interface shape and temperature oscillation. It is somewhat strange that you would get it only on the right if the case is symmetric.
As remedy you could test some of the keywords that stabilize the solution: "Stabilize", "Velocity Relaxation Factor", "Velocity Smoothing Factor". Two first ones are consistant while the third one introduces a small diffusion. The fact that several strategies were implemented tells that there indeed has been problems before. My memory don't serve me so well that I could directly suggest the best remedy. However, make sure that it doesn't affect your results.
-Peter
Re: corrupted element
Hello Peter,
Do you think that using triangular elements could help? I tested them for one case but the mean temperature in the box and heat flow started to oscillate so I decided to go back to rectangles.
best regards, Martina.
Yes, BCs are symmetric (zero velocities and natural, i.e. zero flux, BC for temperature). Indeed, I doubt the result as well since it's not symmetric and the condition of zero flux is not really fulfilled. To have an idea look at two attached files where isotherm is plotted in the computational box. You can see vicinity of right and left wall. (In this case no corrupted elements were observed.)raback wrote: There may sometimes be a positive feedback between the interface shape and temperature oscillation. It is somewhat strange that you would get it only on the right if the case is symmetric.
In simulations stabilization is used for all solvers except mesh update solver. Velocity smoothing factor is set to be 0.0001 (that is probably too high (?) since elements are ~ 0.02 - 0.01) and finaly velocity relaxation factor is 0.1.raback wrote: As remedy you could test some of the keywords that stabilize the solution: "Stabilize", "Velocity Relaxation Factor", "Velocity Smoothing Factor". Two first ones are consistant while the third one introduces a small diffusion. The fact that several strategies were implemented tells that there indeed has been problems before. My memory don't serve me so well that I could directly suggest the best remedy. However, make sure that it doesn't affect your results.
Do you think that using triangular elements could help? I tested them for one case but the mean temperature in the box and heat flow started to oscillate so I decided to go back to rectangles.
best regards, Martina.
-
raback
- Site Admin
- Posts: 4828
- Joined: 22 Aug 2009, 11:57
- Antispam: Yes
- Location: Espoo, Finland
- Contact:
Re: corrupted element
Hi Martina
Are you sure that you have same BCs for the heat equation at both sides?
I may have a good reason to revisit the PhaseChangeSolver very soon. The current solver was an attempt to combine the transient and steady state algorithms to a same solver. So one could start off steady state and continue to smaller time scales. However, the tested strategies were not really that robust and therefore the users typically still choose either of the modes. The two different algorithms just make the solver quite confusing to use and debug. Therefore I might break the solver into two and at the same process sligthly generalize the transient version to allow 3D and periodic computations. All suggestions and critical testing is of course wellcome in the process. For example, it would be good to have this current case working properly in the future version.
-Peter
Are you sure that you have same BCs for the heat equation at both sides?
I may have a good reason to revisit the PhaseChangeSolver very soon. The current solver was an attempt to combine the transient and steady state algorithms to a same solver. So one could start off steady state and continue to smaller time scales. However, the tested strategies were not really that robust and therefore the users typically still choose either of the modes. The two different algorithms just make the solver quite confusing to use and debug. Therefore I might break the solver into two and at the same process sligthly generalize the transient version to allow 3D and periodic computations. All suggestions and critical testing is of course wellcome in the process. For example, it would be good to have this current case working properly in the future version.
-Peter