Integration into openfoam

Start of efforts to integrate current code state (adios sliced streams, coherent file format) into OpenFOAM.

As discussed this morning with @gregorweiss (@Serge was on holidays) - I've spun off a new branch (feature-coherent-io) based on the current openfoam/develop branch.

The develop branch will be a pure mirror of the regular openfoam repo. As the low-level changes accumulate (in the feature-coherent-io branch), I'd then try my best to incorporate them back into develop and we'd rebase the feature branch accordingly (naturally after coordination to avoid getting in each other's way). This way I hope that we can get support as early as possible and make the final delta smaller.

Let's start with the stuff that could be tried for copy-and-paste portability, where the goal is compilation for now. Runability will be tested in polyMesh::write() (and constructor) later on.

src/foam/db/IOstreams/SliceStreams/
    buffer/*
    create/*
    FileSliceStream.C
    FileSliceStream.H
    primitives_traits.H (check/compare with the type traits that you recently covered)
    sliceReadPrimitives.C
    sliceReadPrimitives.H
    SliceStream.C
    SliceStream.H
    SliceStreamImpl.H
    SliceStreamPaths.C
    SliceStreamPaths.H
    SliceStreamRepo.C
    SliceStreamRepo.H
    SliceStreamRepoI.H
    sliceWritePrimitives.C
    sliceWritePrimitives.H

and

src/foam/meshes/polyMesh/CoherentMesh/*

The NBX implementation (nonblockConsensus.H/I.H/.C) could be omitted and its only usage in SliceMesh.C could be replaced by the NBX implementation in Pstream.

@mark : Thanks for proceeding on this. I dropped a few questions in the commits. In particular, did you have problems with the CoherentMesh::polyPatches that you turned off with

#ifdef OPENFOAM
NotImplemented

?

foam-extend has a resetPatches method that apparently changes start/len of a patch and resets all of the geometric values. There is no such method in OpenFOAM since this would probably results in inconsistent mesh addressing. Instead, a mesh is "repatched" in one go.

I pushed the fixes that enable the implementation of Foam::CoherentMesh::polyPatches.

The issue with the non-existence of resetPatches became obsolete because the method Foam::FragmentedPermutation::resetNextPatch is unused and could be removed.

And I had to cast the MPI_COMM_WORLD to type MPI_Comm during the adios2::ADIOS instantiation.

The copy-paste port compiles and the features should now be ready for a test drive. I would suggest continuing with the implementation of polyMesh::write(), however, removing the return statement of the implementation in the reduced foam-extend implementation.

Started some of this, but @Serge I really, really need cleaner and updated code for the IFstream/OFstream and output. These are some interwoven and bespoke it is hampering integration. Please push an updated (even a WIP) branch. I guess this request (email about 3 weeks ago) was previously missed.

I've pushed the latest changes to the io branch and also my WIP (io-coherentDev) but I should say Gregor and me update io with our commits as frequently as possible. Latest changes: IFCstream with types and IOstreamOption is now very similar to the OF-com. Further integration and overall cleanup are still needed.

OK thanks - it looks like your changes from 3-Aug onward were probably only local to your machine. These are the ones I was looking for.

I see that you added in the IOstreamOption but removed all of the copyright notices - why?

With the streams parwrite() method, do we need to pass in unique_ptr to UListProxy? I would have thought that a shallow copy of UListProxy would be enough.

Still trying to understand how the boundary counter in OFstream is supposed to work reliably.

Here is an example of what I mean:

boundaryField
{
    inlet
    {
        type            fixedValue;
        value           $internalField;
    }

    outlet
    {
        type            inletOutlet;
        inletValue      $internalField;
    }

    "(?i).*walls"
    {
        type            uniformFixedValue;
        value           uniform 350;

        uniformValue
        {
            type        expression;

            functions<scalar>
            {
                trigger
                {
                    type     functionObjectTrigger;
                    triggers (2 4);
                    defaultValue true;
                }
            }

            variables
            (
                "Tcrit = 500"
                "par1 = mag(internalField(U))/snGrad(T)"
            );
            expression
            #{
                Tcrit
              + par1*internalField(T) * max((Tcrit-T)/(Tcrit)*deltaT()/time(),0)
            #};
        }
    }
}

The number of type entries is 5, but for 3 (or more) boundaries. How can counting the number of times type was seen do anything proper? I think that if we are going to require that level of hook, we'd need to add something like a incrCounter() method to Ostream and then call that from fvPatchField::write() when the Ostream is COHERENT.

@mark

I see that you added in the IOstreamOption but removed all of the copyright notices - why?

This is not what I did. I started by taking all the corresponding options from foam-extend's IOstream to the new class and went so on. But I see your point. Let's discuss it tomorrow.

With the streams parwrite() method, do we need to pass in unique_ptr to UListProxy? I would have thought that a shallow copy of UListProxy would be enough.

Indeed, that should be fine.

Still trying to understand how the boundary counter in OFstream is supposed to work reliably.

I assume you're talking about the boundaryCounter_. This one was added by Gregor, I've never used it. OFstream code contains trial&error from the beginning of the development - nothing from it is used anymore (at least according to my knowledge). All the production code is in OFCstream. As I mentioned previously, we need to clean up the code before proper merging.

Hi @Serge - thanks for the comments. Can we loop on discussing the OFCstream? I also have some doubts about how the IFstream is managing the "fields/" entries. ie, under which conditions we have a non-relative path etc.

Good morning @mark, the same thing is true for IFstream: we don't use "fields/" directory anymore. The implementation for reading coherent fields is in IFCstream. We settled to keep ASCII files in time directories even if we have a single .bp file per run, which is @gregorweiss is experimenting with.

Pushed an intermediate snapshot as feature-coherent-io.wip with some added code comments and cleanup, but not yet convinced that I follow the logic at all. Some parts will not compile with OpenFOAM. These are marked as disabled or not-implemented.