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|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Platform||Unix||OS||Other||OS Version||(please specify)|
|Fixed in Version|
|Summary||0003488: interfaceHeight results have non-zero 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 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.
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
n (3 2 1);
n (3 1 2);
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 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.
||That makes sense to me. Thank you for enlightening me.|