View Issue Details

IDProjectCategoryView StatusLast Update
0000778OpenFOAMBugpublic2013-08-16 17:12
Reporternogenmyr Assigned Touser4 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinuxOSOtherOS Version(please specify)
Summary0000778: volPointInterpolation somewhat incompatible with cyclics
DescriptionIn 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 Reproduce1. 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 InformationThe 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)
TagsNo tags attached.

Activities

nogenmyr

2013-03-13 13:22

reporter  

export.tar.gz (2,900 bytes)

user4

2013-03-14 11:33

  ~0002005

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.

nogenmyr

2013-03-14 13:20

reporter   ~0002007

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.

nogenmyr

2013-03-14 13:21

reporter  

user4

2013-03-14 16:50

  ~0002010

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?

nogenmyr

2013-03-14 20:04

reporter   ~0002011

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.

user4

2013-08-16 17:12

  ~0002422

Fixed in commit 17439e8be57144bedd995b941232af2b03ba6bc5.

Issue History

Date Modified Username Field Change
2013-03-13 13:22 nogenmyr New Issue
2013-03-13 13:22 nogenmyr File Added: export.tar.gz
2013-03-14 11:33 user4 Note Added: 0002005
2013-03-14 11:33 user4 Status new => closed
2013-03-14 11:33 user4 Assigned To => user4
2013-03-14 11:33 user4 Resolution open => no change required
2013-03-14 11:35 user4 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
2013-03-14 16:50 user4 Note Added: 0002010
2013-03-14 20:04 nogenmyr Note Added: 0002011
2013-03-14 20:04 nogenmyr Status feedback => assigned
2013-08-16 17:12 user4 Note Added: 0002422
2013-08-16 17:12 user4 Status assigned => resolved
2013-08-16 17:12 user4 Fixed in Version => 2.2.x
2013-08-16 17:12 user4 Resolution reopened => fixed