Replies: 2 comments
-
|
Having a face be all OBST is likely not the issue. It is likely something with the specific details of what is happening with the flow field. The default VELOCITY_TOLERANCE and MAX_PRESSURE_ITERATONS are not universal parameters. Value were picked that seem to work well for the V&V suite. Try upping the MAX_PRESSURE_ITERATIONS to 100. If you keep hitting 100, then probably worth more investigation as to what is going on. If you just have a few timesteps at the start that require lots of iterations, and then the count drops sometimes that happens. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the advice. I tried to run with MAX_PRESSURE_ITERATIONS=100, but it never settled down -- there was always the constant value of Maximum Velocity Error in a solid cell. It also ran slowly, of course. For now, I'm happy with the results when the MESH blocks are shaved down to remove pure-OBST layers -- this converges nicely after a short bit of chaos at the start. On future occasions, I'll try adjusting VELOCITY_TOLERANCE, as you suggest -- and/or try ITERATION_SUSPEND_FACTOR. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I have a case that ran with Pressure Iterations maxed out (at the default maximum 10) for every timestep (at least, every timestep reported in the .out file). As I understand it, this means that the solution is highly suspect.
The locations of Maximum Velocity Error (again in the .out file) were consistently in the same MESH block. The cell IJK varied slightly, but was always in a region occupied by OBST. I find this surprising in itself. I think that flow is effectively solved in all MESH cells, but the velocity field in OBST cells is damped down to effectively zero, as if by strong porous resistance. (That's more or less correct, isn't it?) I would have expected that that part of the flow solution is not likely to diverge.
In this specific case, I noted that the MESH block had OBST cells on all of its xmin side. So I increased the xmin of the MESH slightly, such that this was no longer true. On rerunning, I saw the same issue, with maxed-out Pressure Iterations, and Maximum Velocity Error inside an OBST region. This was also in a MESH whose xmin side was purely OBST. I increased that MESH xmin as well, and now the case is running with converged timesteps.
So, my questions are:
(1) Is there a known stability problem if one face of a MESH cuboid is entirely occupied by OBST? -- I realise that there is a (typically small) runtime penalty in specifiying a MESH that is bigger than it needs to be, because these OBST cells are being solved for without any useful results. (I had no HT3D in this case. I don't think there were any single-cell-thick OBSTs separating fluid cells -- these conduct heat, so removing those OBST cells could have had a physical effect on the solution. In the second MESH that I mentioned, the OBST at the xmin end of the cuboid was actually 4 cells thick, so I would expect no conduction effects there.)
(2) Are there any guidelines about how much of a MESH block can reasonably be OBST, without making flow solution difficult? (This did not apply to the two MESH blocks in the current case. It's more of a general question.)
(3) Are there any settings that help if Maximum Velocity Error is problematic inside OBST regions?
Thanks for any comments.
Beta Was this translation helpful? Give feedback.
All reactions