#295 Report found on the forum about CoNum not being consistent when used in parallel

[Bruno Santos]

Greetings,

I didn't want this bug to go unreported, specially since a diagnosis and fix has been made available on the forum: http://www.cfd-online.com/Forums/openfoam-bugs/94085-strange-processor-boundary-behavior-linearupwindv.html#post568787

Roughly quoting the relevant details from the thread:

1. In the files CourantNo.H, the following calculation is not parallel-safe:

~~~~~~
CoNum = max(SfUfbyDelta/mesh.magSf()).value()*deltaT;
~~~~~~

1. The proposed solution was this:

~~~~~~
CoNum = max(SfUfbyDelta/mesh.magSf()).value()*deltaT;
reduce(CoNum,minOp<scalar>());
~~~~~~

I've checked how OpenFOAM does this calculation, but they use a completely different calculation that is parallel safe: https://github.com/OpenFOAM/OpenFOAM-2.4.x/blob/master/applications/solvers/multiphase/cavitatingFoam/CourantNo.H

I haven't proposed a pull request, since I don't know what solution you prefer, nor am I familiar enough with this code :(.

Best regards,
Bruno

[Bruno Santos]

Quoting a recent post by the same person who reported this on the forum: http://www.cfd-online.com/Forums/openfoam-bugs/94085-strange-processor-boundary-behavior-linearupwindv.html#post571853

Strangely enough, I only observed this in some special cases. In other cases, the time steps were synchronized but it may have occured that some cores just waited for the others to complete intermediate time steps and afterwards these intermediate ones were deleted again. It seems that deep inside the source code there's something not working properly (because the same version of openmpi sometimes works, sometimes this bug occurs).