[finn_amann]

Hello friends,

facts:

• OpenFoam 9 (foundation version) debug-mode
• Compiled with GCC/G++ 9.4.0 (also tried gcc-11)
• OS: Pop!_OS 22.04

whenever I try to use function objects in my simulation I get error message below:

...
Courant Number mean: 0 max: 0

Starting time loop



--> FOAM FATAL IO ERROR: 
error in IOstream "OSHA1stream.sinkFile_" for operation Ostream& operator<<(Ostream&, const char)

file: OSHA1stream.sinkFile_ at line 0.

    From function virtual bool Foam::IOstream::check(const char*) const
    in file db/IOstreams/IOstreams/IOstream.C at line 96.

FOAM exiting

I added the sub-dictionary into my controlDict as follows:

functions 
{
  myFunction
  {
    // I can write whatever I want in here, the error will occur anyway. 
    type whateverFunction;
    functionObjectsLibs (...);
    ...
  }
};

I also tried this on my work machine (Ubuntu 20.04, also gcc-9) on which it works fine.

The error occurs when OF tries to read the sub-dictionary for functions. I did some debugging and found out that the error originates (if I can say so) in the read() function of functionObjectList.C, line 799 when dict.digest() is called. I marked the exact spot in the following code. Of course it goes down deeper into the code, but I can't really follow what's happening in there since I have no idea what SHA1 digests are:

bool Foam::functionObjectList::read()
{
    bool ok = true;
    updated_ = execution_;

    // Avoid reading/initialising if execution is off
    if (!execution_)
    {
        return true;
    }

    // Update existing and add new functionObjects
    const entry* entryPtr = parentDict_.lookupEntryPtr
    (
        "functions",
        false,
        false
    );

    if (entryPtr)
    {
        PtrList<functionObject> newPtrs;
        List<SHA1Digest> newDigs;
        HashTable<label> newIndices;

        label nFunc = 0;

        if (!entryPtr->isDict())
        {
            FatalIOErrorInFunction(parentDict_)
                << "'functions' entry is not a dictionary"
                << exit(FatalIOError);
        }

        const dictionary& functionsDict = entryPtr->dict();

        libs.open
        (
            functionsDict,
            "libs",
            functionObject::dictionaryConstructorTablePtr_
        );

        newPtrs.setSize(functionsDict.size());
        newDigs.setSize(functionsDict.size());

        forAllConstIter(dictionary, functionsDict, iter)
        {
            const word& key = iter().keyword();

            if (!iter().isDict())
            {
                if (key != "libs")
                {
                    IOWarningInFunction(parentDict_)
                        << "Entry " << key << " is not a dictionary" << endl;
                }

                continue;
            }

            const dictionary& dict = iter().dict();
            bool enabled = dict.lookupOrDefault("enabled", true);

            newDigs[nFunc] = dict.digest(); // in here something goes wrong.
...

Did this ever happen to any of you? It's probably difficult to reproduce, as the exact same simulation works on my other machine...

I already opened an issue on Github (https://github.com/OpenFOAM/OpenFOAM-9/issues/12), however, I think this community is probably more active.

Any help is appreciated!

Best regards
Finn

[finn_amann]

The problem has been solved in the latest commit by Henry Weller
(https://github.com/OpenFOAM/OpenFOAM...9a60e33ed456eb).

Using git pull will get you the necessary update.

[olesen]

Originally Posted by finn_amann

The problem has been solved in the latest commit by Henry Weller
(https://github.com/OpenFOAM/OpenFOAM...9a60e33ed456eb).

Funnily enough I actually introduced that SHA1 handling and dictionary digests about 13 years ago:
https://develop.openfoam.com/Develop...4e1f9fee82b5c7

It aged fairly well, so I was also surprised by this too (I guess I didn't read the docs carefully enough the first time). Was solved about a month ago before the OpenFOAM-v2206 release (also included in the v1912, v2006, v2012, v2105, v2112 maintenance branches).
https://develop.openfoam.com/Develop.../-/issues/2481

I'm still not sure how the "OpenFOAM Foundation Ltd." manages to justify laying copyright claim to this bit of code too.