View Issue Details

IDProjectCategoryView StatusLast Update
0001500OpenFOAMBugpublic2015-01-28 08:36
Reporteruser342Assigned Tohenry  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionno change required 
PlatformGNU/LinuxOSUbuntuOS Version12.04
Summary0001500: Patches get loaded twice in fvc or fvm solver
DescriptionI have reported in bug 0000797 that for that AMI case the patches get loaded twice (including not AMI patches). This leads to an imbalancefor all patches that have a recursive statement such as +=, -= etc. In addition, you use up unnecessary memory space and calculation. For constant value boundary conditions or constant gradient, you will not get an error in results, but still there is not necessary computing time.
Steps To ReproducePlot out pcorrEq or p_rghEq. You will see that patches are called twice, the matrix coeff. psi and the source term once. I used the mixer vessel AMI. I do not know if this applies on other solvers too.
TagsNo tags attached.

Activities

henry

2015-01-26 10:54

manager   ~0003583

Could you clarify what you mean by "for that AMI case the patches get loaded twice"? I have printed out pcorrEqn for the mixerVesselAMI2D and the matrix has the internal and boundary coefficients for the 6 patches as expected.

user342

2015-01-26 15:51

  ~0003585

Method 1: set pcorr to be {1} instead of {0}, no shaft turn. Then plotted rA (source is {0}) in PCG.C. I get -0.0034894 for certain cells (1st iteration). You also may plot wA, should be the same (in case source is not {0}). You should obtain {0} for rA. If you use {0} for pcorr, you get indeed {0} for rA. rA should be {0} for any pcorr.

Method 2: Using the same method as 1, print out "result" or result[1] in cyclicAMIFvPatchField.C after line 228. I get 2 printouts instead of 1. Multiplying line 226 by 0.5, I get the correct result for method 1

Method 3: print out pcorrEq after line 52 in correctPhi. I get something like: false true true 3072 (...) 5856 (...) [0 3 -1 0 0 0 0 ] 3072 (...) 6 ( 192 {0} 192 {0} 96 (-0.0034894 ... -0.0034894) 96 (-0.0034894 ... -0.0034894) 0() 0() ) 6 ( 192 {-0} 192 {0} 96 (-0.0034894 ... -0.0034894) 96 (-0.0034894 ... -0.0034894) 0() 0() ). Stator and rotor have each 192 faces, 96 for each AMI. So, I would think patches are read in twice or at least this information is redundant.

henry

2015-01-26 15:57

manager   ~0003586

Method 2: Using the same method as 1, print out "result" or result[1] in cyclicAMIFvPatchField.C after line 228. I get 2 printouts instead of 1. Multiplying line 226 by 0.5, I get the correct result for method 1

But you should get 1 for each AMI patch and there are two AMI patches, one for each side of the AMI dealing with the cells on their side of the AMI. Do you mean you get 1 printout for each AMI or two for each? I only see one call for each AMI as expected.

The matrix contains coefficients for the internal cells and boundary faces hence the two lists of 6.

user342

2015-01-27 14:23

  ~0003589

The result of the internal cell differential is already in the coefficient matrix, except for the patch side. In order to close the balance the patch side has just to be substracted.

I do not see how that can be different since the coefficient of the internal matrix is the result of the differential over all cell faces. The owner cell having a patch on one or several sides then is missing the patch faces. This is also why the result in the coefficient matrix is identical to the patch value for pcorr = {1} in my example.

From geometrial stand point one can say: the projection of all faces except one of a closed body is exactly that missing face. Applied on a triangle: the sum of the angles is always 180 °.

henry

2015-01-27 14:29

manager   ~0003590

Each AMI patch provides the coefficient to the cell on its side of the AMI. The AMI coefficients corresponding to the internal cell differential are not already in the coefficient matrix.

henry

2015-01-27 15:44

manager   ~0003591

I am testing AMI on a cavity case split into two blocks joined by an AMI and the results are practically identical (different only by round-off and tolerance) to the case without an AMI. If I apply the "0.5" coefficient you advocate the results are simply wrong.

user342

2015-01-28 08:09

  ~0003602

Yes, I agree with you that you will get wrong results by applying 0.5 on the patches. If it is correct that the internal cell differential is included already, you need only to apply the neighbour cell patch and not owner + neighbour patch neighbour patch multiplied by 0.5. This is correct only if pressure levels are identical in owner and neighbour cell. I am just not as deep in the the C++ code to know how to identify that property in the patch code.

Please try to increase pressure level in 0 in your cavity case and look if your results are identical (they should). If not, I have to look somewhere else where this error comes from that I see in my calculation.

I will try what you did on my side and see what I get.

henry

2015-01-28 08:36

manager   ~0003603

The converged solution in the cavity case is independent of the initial pressure or the reference pressure used with or without the AMI. The AMI implementation works exatcly as it should for this case because there is no continuity error. Issues with AMI arrise when there is a slight mismatch in the weighted delta coefficients due to inexact calculation of overlaps and weights on curves and corners leading to small continuity errors. For closed incompressible systems the continuity error mansifests itself as an error in the reference cell which does not occur in open systems.

Patches do NOT get loaded twice in fvc or fvm solver.

Issue History

Date Modified Username Field Change
2015-01-26 09:00 user342 New Issue
2015-01-26 10:54 henry Note Added: 0003583
2015-01-26 15:51 user342 Note Added: 0003585
2015-01-26 15:57 henry Note Added: 0003586
2015-01-27 14:23 user342 Note Added: 0003589
2015-01-27 14:29 henry Note Added: 0003590
2015-01-27 15:44 henry Note Added: 0003591
2015-01-28 08:09 user342 Note Added: 0003602
2015-01-28 08:36 henry Note Added: 0003603
2015-01-28 08:36 henry Status new => closed
2015-01-28 08:36 henry Assigned To => henry
2015-01-28 08:36 henry Resolution open => no change required