[sophie_l]

Hello,

I'm working on the coupling of interFoam and solidParticle. The solver works well in serial. It runs in parallel as well, and the fluid phase behaves, however, the results of the solid phase are not reasonable, let alone resemble those produced in serial run. So there must be something wrong with the parallelisation of solidParticle, it runs without error message though. I checked the output, origId of the particles are all -1 at every time step. I suspect this might be the reason, however I didn't manage to get origId right, let alone to know whether this is the reason to the problem. Could anybody shed some light on this please? Any thoughts would be much appreciated!

Thanks in advance.
Sophie

[wyldckat]

Greetings Sophie,

That sounds to me like a bug that has already been fixed.

1. Can you provide more details regarding the version of OpenFOAM you're using?
2. And an example of the piece of code you're referring to? Preferably something that can be used to reproduce the same error.

Best regards,
Bruno

[sophie_l]

Hi Bruno,

Thanks a lot for your prompt help. Sorry I should have included these details in my post. I'm using OF 2.3.0. The code is in particleIO.C,

// * * * * * * * * * * * * * * * * Constructors  * * * * * * * * * * * * * * //

Foam::particle::particle(const polyMesh& mesh, Istream& is, bool readFields)
:
    mesh_(mesh),
    position_(),
    cellI_(-1),
    faceI_(-1),
    stepFraction_(0.0),
    tetFaceI_(-1),
    tetPtI_(-1),
    origProc_(Pstream::myProcNo()),
    origId_(-1)
{
    // readFields : read additional data. Should be consistent with writeFields.

    if (is.format() == IOstream::ASCII)
    {
        is  >> position_ >> cellI_;

        if (readFields)
        {
            is  >> tetFaceI_ >> tetPtI_ >> origProc_ >> origId_;
        }
    }
    else
    {
        // In binary read all particle data - needed for parallel transfer
        if (readFields)
        {
            is.read
            (
                reinterpret_cast<char*>(&position_),
                sizeof(position_)
              + sizeof(cellI_)
              + sizeof(faceI_)
              + sizeof(stepFraction_)
              + sizeof(tetFaceI_)
              + sizeof(tetPtI_)
              + sizeof(origProc_)
              + sizeof(origId_)
            );
        }
        else
        {
            is.read
            (
                reinterpret_cast<char*>(&position_),
                sizeof(position_)
              + sizeof(cellI_)
              + sizeof(faceI_)
              + sizeof(stepFraction_)
            );
        }
    }

    // Check state of Istream
    is.check("particle::particle(Istream&, bool)");
}

Do you think the incorrect value of 'origId' is the reason why the parallel output is wrong? If not, what else would you suggest me looking into?

Thanks!
Sophie

[sophie_l]

Besides, parallel run using MPPICFoam produces correct origId. However, both MPPICFoam and the solver I use with solidParticle are using the same 'lagrangian' library where origId is dealt with. Of course MPPICFoam employs the 'intermediate' library on top of that, but I didn't find any manipulation of origId in 'intermediate'. So it looks strange to me why MPPICFoam produces correct origId?

Thanks in advance!
Sophie

[floquation]

Originally Posted by sophie_l

Besides, parallel run using MPPICFoam produces correct origId. However, both MPPICFoam and the solver I use with solidParticle are using the same 'lagrangian' library where origId is dealt with. Of course MPPICFoam employs the 'intermediate' library on top of that, but I didn't find any manipulation of origId in 'intermediate'. So it looks strange to me why MPPICFoam produces correct origId?

The difference between your implementation and MPPICFoam is that MPPICFoam does not use the solidParticle class. In fact, when I sought 3 months ago, I couldn't find anything in OpenFOAM that uses the solidParticle class (using the OF23x source code). Rather, it uses KinematicParcel<particle> which extends the particle class.

With that being said, I'd recommend using the KinematicParcel class instead, since it seems like solidParticle is deprecated (correct me if I'm wrong).

Better yet, the third party tool 'swak4Foam' is able to introduce lagrangian particles to any solver (including interFoam) using a dictionary format (only ~10 lines) to interact with the user (i.e., we). I've used it with one-way coupled particles 3 months ago (interFoam). I recommend checking if it satisfies your needs. See: http://openfoamwiki.net/images/6/6d/...ng_OFW8.pdf#81

[sophie_l]

Hello,

Thanks for your reply. I'm developing my own code on the platform of OF 2.3.0. It's true MPPICFoam doesn't use solidParticle class, yet the variable 'origId' is only specified in the basic 'lagrangian' library, which is employed by both. I didn't find further manipulation of 'origId' in 'intermediate' library, so it's confusing to me.

[wyldckat]

Greetings to all!

@Sophie: I took a quick look at the first answer you posted and I went searching for changes in OpenFOAM's source code... and I found this commit: https://github.com/OpenFOAM/OpenFOAM...1cfd1c99f4953a
It refers to this bug report: http://www.openfoam.org/mantisbt/view.php?id=1304 - Looks familiar?!

Either way, I very strongly suggest that you upgrade to OpenFOAM 2.3.1, before continuing. There have been a ton of bug fixes made between 2.3.0 and 2.3.1, and if you don't upgrade, you risk going around and round and round...

If you continue to reproduce the same error, please create a small test case with which the error can be reproduced. Preferably something based on one of OpenFOAM's own tutorials.

Best regards,
Bruno