|
2013-03-15 18:00
|
|
|
2013-03-15 18:00
|
twistPanel.png (28,099 bytes) |
|
|
Does this case work with OpenFOAM-2.2.0? |
|
|
It works for the boundary detach, when the faceZone is turned into boundary patches (I have the "valve" set to be initially open, then to close, then to open again). The failure occurs when the boundaries are attached and the mesh is reconnected. I was trying the compressible case and the thermo model fails at detachment, which I thought was the fault of the thermo model but only running an incompressible version revealed what was going on with the mesh. This case did work with 2.1.x |
|
|
Is there a difference in behaviour for this case between 2.2.0 and 2.2.x? |
|
|
The difference is in how the mesh is reconnected when boundaries are attached. I noticed that running renumberMesh doesn't put the faces in a faceZone in numerical order. |
|
|
Does it run in either 2.2.0 or 2.2.x if you do not use renumberMesh? |
|
|
The same error occurs even when not using renumberMesh. I just realized my additional note is inaccurate: the simulation fails right after the boundaries are removed at 1s. |
|
|
I am not sure what renumberMesh has to do with the issue, should it be applied or not? |
|
|
It was to allow running the case in debug mode, as attachDetach complains if the faces in the faceZone are out of order. |
|
|
How does renumberMesh help you run in debug mode? |
|
|
The instructions to reproduce tho problem are very confusing, it is not at all clear if renumberMesh is needed or not. Could you provide the steps to reproduce the problem and the log files you get of the failure in 2.2.0 and 2.2.x? |
|
|
Just download the tarball, extract it and run the Allrun script. If you want you can comment out the call to renumberMesh. It makes no difference. |
|
|
Could you also supply the log files you get of the failure in 2.2.0 and 2.2.x? |
|
2013-03-21 22:39
|
|
|
|
Just uploaded the log. It crashes because the mesh get screwed up so badly, so not sure if it will be much help. I would examine the polyMesh directory. |
|
|
I see the log for the run in 2.2.x but not the one in 2.2.0, could you upload that one as well? |
|
|
Just uploaded a truncated log; in 2.2.0 the case never actually crashes, but the timestep keeps dropping down to past 1e-66. You will need to use the downgraded incompressible turbulence (incompressibleTurb22.tar.gz) model included (just limits k and epsilon at topology change). |
|
2013-03-22 18:01
|
|
|
2013-03-22 18:02
|
|
|
|
I've also uploaded an image from ParaFoam of the grid at 1.0 s (when the internal boundaries are removed). I have isolated the group of cells at the junction and expanded it so you can see the issue with how the mesh is reconnected. Henry: I also realized I completely mis-read your comment about difference between 2.2.0 and 2.2.x (busy times in my office). There is no difference between the 2.2.0 and 2.2.x cases. Sorry about the confusion. |
|
2013-03-22 18:42
|
twist2.png (21,986 bytes) |
|
|
> This case did work with 2.1.x I have just tested this case in OpenFOAM-2.1.x and the attach fails in the same way an with 2.2.0 and 2.2.x. Could you please supply the version of the case and code which works with 2.1.x? |
|
|
We have resolved the mapping issues following the creation of new boundary faces from detachment so you no longer need the hacks in the turbulence and transport models to limit the unset values. See commit 36ef5464ffc10713b78a9f0064dbab0a77f208d8 |
|
2013-03-25 20:15
|
|
|
|
Thanks for that fix. I've uploaded the 2.1.x case. One thing I noticed is that if I don't run renumber mesh, the case stops working. Investigating further, I see that the problem is that the faceZones are not in ascending order. I copied over the 2.1.x faceZone file to the 2.2.x case and it was able to work. So the easiest (I think) fix would be to make sure topoSet and renumberMesh order point/face/cellZones. I will try the commit and see if I can get the 2.2.x case to work without turbulence/transport hacks. |
|
|
forgot to push: ordering of faceZones fix 45d31df6883e1a98f05084625641b20e698bb5ae. |
|
|
Confirmed that faceZone and mapping fixes resolve the problems. I'm going to see if this also carries over the the compressible case and the mapping of new boundary faces in the thermo models. The faceZones are in order after the topoSet call, but get disordered when renumberMesh is called. Its not critical for this to work, but it seems inconsistent. EDIT: Fantastic work, I now no longer need to hack the thermophysical properties for compressible flow either. |
- Anonymous
