#### View Issue Details

ID Project Category View Status Date Submitted Last Update 0003488 OpenFOAM Bug public 2020-04-26 21:42 2020-04-29 12:52 handrake0724 normal minor have not tried new open Unix Other (please specify) dev 0003488: interfaceHeight results have non-zero mean wave level in parallel computation 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 non-zero 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());         reduce(sumLengthAlpha, sumOp()); 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. No tags attached.

#### Activities

 2020-04-26 21:42 reporter case.tar.gz (4,173 bytes) 2020-04-27 02:54 reporter   ~0011305 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. 2020-04-28 09:12 manager   ~0011306 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 post-processing operations. The traditional way of doing this on a structured mesh is to specify the point (1e-6 1e-6 1e-6) rather than (0 0 0). Doing so in your case gives the correct answer. 2020-04-29 12:52 reporter   ~0011310 That makes sense to me. Thank you for enlightening me.