View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000778||OpenFOAM||[All Projects] Bug||public||2013-03-13 13:22||2013-08-16 17:12|
|Platform||Linux||OS||Other||OS Version||(please specify)|
|Fixed in Version|
|Summary||0000778: volPointInterpolation somewhat incompatible with cyclics|
|Description||In the attached test-cases volPointInterpolation seems to work with cyclics only if they were created with createPatch, not when they are set up directly with blockMesh. |
Test-volPointInterpolation crashes with:
--> FOAM FATAL ERROR:
More than one patch accessing the same transform but not of the same sign.
patch:cyclic_half0 transform:0 sign:1 current transforms:(1 0 0)
In practice this occurs when using cyclics with moveEngineMesh with fvMotionSolver (where volPointInterpolation is used). For my engine case, it did however not help to set up the cyclics with createPatch.
paraFoam plugin will also crash.
|Steps To Reproduce||1. Compile Test-volPointInterpolation in applications/test|
2. Unpack the attached file, export.tar.gz
3. Enter work directory and execute Allrun. Test-volPointInterpolation should now execute successfully.
4. Enter nonwork directory and execute Allrun. Test-volPointInterpolation should now fail.
|Additional Information||The only difference from the two cases is the ordering of faces and points, which is of course important for cyclics, but blockMesh is supposed to put them correctly. Maybe more problematic is that this occurs also in cases set up with createPatch. (such a case can be provided upon request)|
|Tags||No tags attached.|
export.tar.gz (2,900 bytes)
This is a known limitation of blockMesh. For opposite block-faces the native ordering of blockMesh is consistent with cyclic ordering but not for connected block-faces like in your case.
Just use createPatch with an empty patches list to force cyclic matching.
Your issue did turn up a problem in checkMesh reporting 180 degrees non-ortho. This has been fixed in a1264baad44158d49c262db1350b16f19ab0331c.
Thanks for reporting.
||Thanks for looking into it. Sorry for reopening, but I still believe there is something fishy here. I realize that blockMesh may not always put faces in correct order for cyclics... that is fine. My remaining problem is that even if I create my cyclics with createPatch (from sets or patches, makes the same), I may trigger the same error as above. I will upload a test case where this is demonstrated, createPatchExamp.tar.gz. I thought my initial test case could illustrate the same issue... Results are the same in 2.1.x and 2.2.x.|
createPatchExamp.tar.gz (3,324 bytes)
This problem is specific to 180 degree angle - the point synchronisation does not like having the same transformation tensor on both sides.
If you switch off the interpolation in paraFoam you can load the case. You still won't be able to run an fvMotionSolver though (since they use interpolation).
Do you need the 180 degree angle?
||Thanks for the clarification! I see the problem. Our engines have either twofold or threefold symmetry, so it would be useful. If it is just a matter of interpolation to pointFields, I guess I can find another way to describe mesh motion, though I liked the resulting mesh with the fvMotionSolver.|
|Fixed in commit 17439e8be57144bedd995b941232af2b03ba6bc5.|
|2013-03-13 13:22||nogenmyr||New Issue|
|2013-03-13 13:22||nogenmyr||File Added: export.tar.gz|
||Note Added: 0002005|
||Status||new => closed|
||Assigned To||=> user4|
||Resolution||open => no change required|
||Status||closed => resolved|
|2013-03-14 13:20||nogenmyr||Note Added: 0002007|
|2013-03-14 13:20||nogenmyr||Status||resolved => feedback|
|2013-03-14 13:20||nogenmyr||Resolution||no change required => reopened|
|2013-03-14 13:21||nogenmyr||File Added: createPatchExamp.tar.gz|
||Note Added: 0002010|
|2013-03-14 20:04||nogenmyr||Note Added: 0002011|
|2013-03-14 20:04||nogenmyr||Status||feedback => assigned|
||Note Added: 0002422|
||Status||assigned => resolved|
||Fixed in Version||=> 2.2.x|
||Resolution||reopened => fixed|