View Issue Details

IDProjectCategoryView StatusLast Update
0001872OpenFOAMBugpublic2015-10-17 13:59
Reporterwyldckat Assigned Tohenry  
PrioritylowSeverityfeatureReproducibilitysometimes
Status resolvedResolutionfixed 
Product Versiondev 
Summary0001872: Automatic direction skipping in fvMatrixSolve can lead to confusion in case of 3D empty face
DescriptionAttached are two files for updating the ones at "src/OpenFOAM/include":

 - createMesh.H
 - createNamedMesh.H

The addition is a warning in case "mesh.nSolutionD()<2". This is as an attempt to avoid the user getting disoriented when the solver is not reporting any residuals for any one of the momentum direction equations, even if the "momentumPredictor" is turned on.

I don't suggest this to be checked on all "solve" calls because that would slow down things a few nano seconds more than necessary.
Steps To ReproduceOnce in a blue moon I get a weird looking behaviour from OpenFOAM's solvers: none of the momentum direction equations are solved.

Today this happened again. It feels something like getting "2 plus 2 equals 3".
After checking that "momentumPredictor" isn't used in "simpleFoam", that the "solverPerformance" debug options are turned on, that the boundary conditions are all correct, I went looking into the code... because clearly something in the matrix solver was making it quit for all directions.

The reason: https://github.com/OpenFOAM/OpenFOAM-2.4.x/blob/master/src/finiteVolume/fvMatrices/fvMatrix/fvMatrixSolve.C#L147

   if (validComponents[cmpt] == -1) continue;

All directions were skipped, without any warning. I went straight for "checkMesh" and got the answer: all directions were compromised. The reason: a single unassigned face was set to "empty", even after using "subsetMesh" + "createPatch" + "changeDictionary"; the face didn't have its normal aligned with any direction.

To reproduce, use in the tutorial "incompressible/simpleFoam/pitzDaily" the following commands:

  blockMesh
  transformPoints -rotate '( (1 0 0) (1 1 1) )'
  simpleFoam

and no momentum direction equations shall be solved! Without any warning at all...
Additional InformationStill need to check if the multi-region solvers also need this check added to them...
TagsNo tags attached.

Activities

wyldckat

2015-10-16 23:34

updater  

createMesh.H (516 bytes)   

wyldckat

2015-10-16 23:34

updater  

createNamedMesh.H (872 bytes)   

wyldckat

2015-10-16 23:41

updater  

createFluidMeshes.H (830 bytes)   

wyldckat

2015-10-16 23:42

updater  

createSolidMeshes.H (1,055 bytes)   

wyldckat

2015-10-16 23:46

updater   ~0005411

The attached file "createFluidMeshes.H" is for the folders "applications/solvers/heatTransfer/chtMultiRegionFoam/fluid" and "applications/solvers/heatTransfer/chtMultiRegionFoam/chtMultiRegionSimpleFoam/fluid".

The attached file "createSolidMeshes.H" is for the folder "applications/solvers/heatTransfer/chtMultiRegionFoam/chtMultiRegionSimpleFoam/solid".

henry

2015-10-17 11:33

manager   ~0005412

Solving 1D cases is valid in OpenFOAM so I don't think that it should be a warning. We could provide the number of solution directions as information but given that the user would generally already know this it might be considered clutter.

In the circumstances you describe I would use checkMesh to check that the BCs are appropriate and the number of solution directions are as expected. What does checkMesh print for your case? If it is not sufficient to diagnose the problem then we should add more checks and output to checkMesh.

wyldckat

2015-10-17 12:05

updater   ~0005413

On the rotated "incompressible/simpleFoam/pitzDaily" case I mentioned about, checkMesh with the default options only reports this:

  ***Number of edges not aligned with or perpendicular to non-empty directions: 61966
   <<Writing 25012 points on non-aligned edges to set nonAlignedEdges

This does hint at the problem.

But it is a bit daunting when the solver doesn't solve any of the momentum directions, when at first sight everything seems fine, given that it can solve everything else.
The "best part" is that all other equations are solved either way, so this can also give a false sense of security, given that the simulation still runs and can in some cases "converge". It has continuity errors in this test with the rotated pitzDaily, but since I didn't change the orientation of U at the inlet, it's natural that it doesn't behave all that well.

Either way, if a warning can be given, it does make a lot more sense that it only warns about when no directions will be solved, instead of detecting if it's lesser than 2.

Placing the warning in the "createMesh" sections that are mostly not related to mesh manipulators seemed to me to be the less intrusive way, although it does lead to a bit more repeated code than I would like. But placing it in the constructor didn't look like it would be the right place.

henry

2015-10-17 12:20

manager   ~0005414

The momentum equation is not solved because the case is appaently 0D which is also a valid option in OpenFOAM. All the other equations are solved for oD cases. I don't see a need to warn that a case is 0D except in cases for which it should not be 0D.

So the only issue here is that your mesh has errors in it which need to fixed to run. The purpose of checkMesh is to check that the mesh is suitable to run on. The error message you get from checkMesh is serious and should be dealt with before proceeding to run on the case. If you would like more diagnostics from checkMesh concening the number of valid geometric directions and solution directions I would be happy for this to be added to checkMesh.

wyldckat

2015-10-17 12:40

updater  

checkGeometry.C (24,791 bytes)   

wyldckat

2015-10-17 12:44

updater   ~0005416

Attached the file "checkGeometry.C" for the folder "applications/utilities/mesh/manipulation/checkMesh/".

The proposed change will affect this line in the output of checkMesh:

    Mesh (non-empty) directions (1 1 0)

Resulting in these kinds of output:

    Mesh (non-empty) directions (1 1 0), 2D solution space.

    Mesh (non-empty) directions (0 0 0), 0D solution space.


Using the expression "solution space" sounds weird, but it seems to be the one that conveys a good indication of what the directions/dimensions stand for, given that the 4th dimension usually is "time"...

henry

2015-10-17 13:16

manager   ~0005417

The number of geometric directions and solutions directions may be different, e.g. in the case of a wedge geometry. Does "solution space" convey geometric directions or solutions directions?

henry

2015-10-17 13:59

manager   ~0005418

I have added the number of solution and geometric directions to the output from checkGeometry.C in a manner consistent with the naming of the corresponding functions in OpenFOAM. I hope this sufficient.

OpenFOAM-dev: commit a10397d10fd68411fa008e616b0fb95b2fba5ecf

Issue History

Date Modified Username Field Change
2015-10-16 23:16 wyldckat New Issue
2015-10-16 23:17 wyldckat Steps to Reproduce Updated
2015-10-16 23:18 wyldckat Steps to Reproduce Updated
2015-10-16 23:34 wyldckat File Added: createMesh.H
2015-10-16 23:34 wyldckat File Added: createNamedMesh.H
2015-10-16 23:41 wyldckat File Added: createFluidMeshes.H
2015-10-16 23:42 wyldckat File Added: createSolidMeshes.H
2015-10-16 23:46 wyldckat Note Added: 0005411
2015-10-17 11:33 henry Note Added: 0005412
2015-10-17 12:05 wyldckat Note Added: 0005413
2015-10-17 12:20 henry Note Added: 0005414
2015-10-17 12:40 wyldckat File Added: checkGeometry.C
2015-10-17 12:44 wyldckat Note Added: 0005416
2015-10-17 13:16 henry Note Added: 0005417
2015-10-17 13:59 henry Note Added: 0005418
2015-10-17 13:59 henry Status new => resolved
2015-10-17 13:59 henry Resolution open => fixed
2015-10-17 13:59 henry Assigned To => henry