View Issue Details

IDProjectCategoryView StatusLast Update
0003488OpenFOAMBugpublic2020-11-21 19:54
Reporterhandrake0724 Assigned Tohenry  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionno change required 
PlatformUnixOSOtherOS Version(please specify)
Product Versiondev 
Summary0003488: interfaceHeight results have non-zero mean wave level in parallel computation
DescriptionI 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.
TagsNo tags attached.

Activities

handrake0724

2020-04-26 21:42

viewer  

case.tar.gz (4,173 bytes)

handrake0724

2020-04-27 02:54

viewer   ~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.

will

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.

handrake0724

2020-04-29 12:52

viewer   ~0011310

That makes sense to me. Thank you for enlightening me.

henry

2020-11-21 19:54

manager   ~0011706

User support request.

Issue History

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