View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003488 | OpenFOAM | Bug | public | 2020-04-26 21:42 | 2020-11-21 19:54 |
Reporter | handrake0724 | Assigned To | henry | ||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | closed | Resolution | no change required | ||
Platform | Unix | OS | Other | OS Version | (please specify) |
Product Version | dev | ||||
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. 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. | ||||
|
|
|
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 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. |
|
User support request. |
Date Modified | Username | Field | Change |
---|---|---|---|
2020-04-26 21:42 | handrake0724 | New Issue | |
2020-04-26 21:42 | handrake0724 | File Added: case.tar.gz | |
2020-04-27 02:54 | handrake0724 | Note Added: 0011305 | |
2020-04-28 09:12 | will | Note Added: 0011306 | |
2020-04-29 12:52 | handrake0724 | Note Added: 0011310 | |
2020-11-21 19:54 | henry | Assigned To | => henry |
2020-11-21 19:54 | henry | Status | new => closed |
2020-11-21 19:54 | henry | Resolution | open => no change required |
2020-11-21 19:54 | henry | Note Added: 0011706 |