View Issue Details
ID  Project  Category  View Status  Date Submitted  Last Update 

0003488  OpenFOAM  Bug  public  20200426 21:42  20200429 12:52 
Reporter  handrake0724  Assigned To  
Priority  normal  Severity  minor  Reproducibility  have not tried 
Status  new  Resolution  open  
Platform  Unix  OS  Other  OS Version  (please specify) 
Product Version  dev  
Fixed in Version  
Summary  0003488: interfaceHeight results have nonzero mean wave level in parallel computation  
Description  I have tried wave simulation following a tutorial in multiphase/interFoam/laminar/wave. first, the case in multiphase/interFoam/laminar/wave gives correct wave elevation with zero mean level both in single and parallel computations. So, I have made a benchmark case for my own and ran some calculations. in single core calculation, the elevation looked correct. but in parallel computations, the wave elevations were shifted by nonzero mean. I looked into interfaceHeight.C to figure out what caused it and found that the following statements have different values from single core calculation. reduce(sumLength, sumOp<scalar>()); reduce(sumLengthAlpha, sumOp<scalar>()); As attached case which has length of 450 in z direction, the above statements give exactly 450 in single core calculation but in parallel calculation, it gives 900. I could not figure out what difference made it from the tutorial case yet.  
Tags  No tags attached.  

case.tar.gz (4,173 bytes) 

I studied the case little bit further. The results look like depending on the number of decomposed domain in gravity vector. in the decomposeParDict, set method to simple simpleCoeffs { n (3 2 1); delta 0.001; } and simpleCoeffs { n (3 1 2); delta 0.001; } gives different results. when there are more than one decomposed domain in z direction, interface height has the same values as single core results but when there are only one decomposed domain in z direction, the results depends on the number of decomposition in that direction. 

The problem is not the decomposition in Z, it's the decomposition in X and Y (in this case Y). You've put a processor boundary exactly on the sampling line (the given point with a ray shot in g and +g). The line is showing up in both processors. We can't account for that. You have to make sure that sampling lines are fully within a processor for this sort of thing to work. The same is true of graph generation or any number of other postprocessing operations. The traditional way of doing this on a structured mesh is to specify the point (1e6 1e6 1e6) rather than (0 0 0). Doing so in your case gives the correct answer. 

That makes sense to me. Thank you for enlightening me. 
Date Modified  Username  Field  Change 

20200426 21:42  handrake0724  New Issue  
20200426 21:42  handrake0724  File Added: case.tar.gz  
20200427 02:54  handrake0724  Note Added: 0011305  
20200428 09:12  will  Note Added: 0011306  
20200429 12:52  handrake0724  Note Added: 0011310 