View Issue Details

IDProjectCategoryView StatusLast Update
0002950OpenFOAMBugpublic2018-06-08 23:08
Reporterwyldckat Assigned Tohenry  
Status resolvedResolutionfixed 
Fixed in Versiondev 
Summary0002950: Strange issue triggered when reading an ascii label list, while the file is in binary mode
DescriptionWhile updating an internal validation case to OpenFOAM 5.x, we tripped over a strange bug with the boundary type 'fixedProfile', while using the profile 'csvFile'.

In the "Steps To Reproduce" section below are the complete steps on how to reproduce this bug, but in a nutshell:

- The binary written 'U' files with the 'componentColumns' entry, is not read properly when the file is re-read by OpenFOAM, may it be the solver, 'foamToVTK' or 'foamDictionary'.

- The solvers and 'foamToVTK' will complain with the following:

    Not implemented

        From function virtual Foam::Istream& Foam::ITstream::read(char*, std::streamsize)
        in file db/IOstreams/Tstreams/ITstream.C at line 159.

    FOAM aborting

- 'foamDictionary' will complain with:

    Expected a '(' while reading VectorSpace<Form, Cmpt, Ncmpts>, found on line 22 the word '#"$#$"#%"#'

    file: 100/U at line 22.

        From function Foam::Istream& Foam::Istream::readBegin(const char*)
        in file db/IOstreams/IOstreams/Istream.C at line 92.

    FOAM exiting

where '#"$#$"#%"#' is actually some other binary-to-ascii gibberish that can't be posted here.

The reason is that as of OpenFOAM 5 (version 4 did not have this issue), this will break the stream reader in binary mode:

   componentColumns 3(3 4 5);

but the following works just fine:

   componentColumns (3 4 5);

Namely the initial digit that OpenFOAM always strictly writes in ascii, will break when re-reading in binary mode.

I'm not familiar with this part of the parsing mechanisms in OpenFOAM, so I don't even imagine what changed between 4.x and 5.x that broke this reading ability.

As a work around, 'changeDictionary' can be used for overwriting the entry value to the acceptable entry.
Steps To ReproduceAttached is the package "pitzDailyCSV.tar.gz" that provides a modified tutorial case "incompressible/simpleFoam/pitzDaily".

The main modification to the case was for the inlet boundary condition in the 'U' field file:

        type fixedProfile;
        profile csvFile;

            nHeaderLine 1; // Number of header lines
            refColumn 1; // Reference column index
            componentColumns (3 4 5); // Component column indices
            separator " "; // Optional (defaults to ",")
            mergeSeparators yes; // Merge multiple separators
            file "Uprofile.csv"; // name of csv data file
            outOfBounds clamp; // Optional out-of-bounds handling
            interpolationScheme linear; // Optional interpolation scheme
        direction (0 1 0);
        origin 0;

Then run the case with the following commands:

  foamDictionary -entry "writeFormat" -set "ascii" system/controlDict
  foamDictionary -entry "boundaryField.inlet.profileCoeffs.componentColumns" 100/U

The last two commands should not give any errors and the last one should give the following:

    componentColumns 3 ( 3 4 5 );

Now run the case again, but in binary mode, as follows:

  foamDictionary -entry "writeFormat" -set "binary" system/controlDict
  foamDictionary -entry "boundaryField.inlet.profileCoeffs.componentColumns" 100/U

The last two will complain as reported in the "Description" section above.
TagsNo tags attached.



2018-05-22 17:58


pitzDailyCSV.tar.gz (3,296 bytes)


2018-05-22 18:01

updater   ~0009622

I forgot to mention/emphasize that this still occurs with OpenFOAM-dev, using a clean build with commit 9dcdf23a6b94a8d792d94664ccfd0d7948a5c905 (Mon May 21 11:05:55 2018 +0100).


2018-06-08 14:56

manager   ~0009724

> version 4 did not have this issue

Are you sure? I don't think this functionality has changed and I see the same problem in 4.x, 5.x and dev.


2018-06-08 15:19

updater   ~0009725

I've re-tested again with a build of OpenFOAM 4.x that I have got and I didn't get any errors.
It's built for following commit:

  commit 03c63bf7a50a4c966bc97d186910e5a9862f313c
  Author: Henry Weller <>
  Date: Mon Jul 24 10:35:00 2017 +0100

      MULES: Improve handling of very small geometries

So it's only missing the very last commit on 4.x... and I don't have any custom code changes on this build nor in the 'etc/controlDict'.

I haven't tested with OpenFOAM 4.0, 4.1... but the builds I'm using right now of 5.x and 4.x were built with a custom build of GCC 4.8.5 (using OpenFOAM's 'makeGcc'), both running on CentOS 6.9, both in double precision and 32-bit labels.

I can try at home with OpenFOAM 4.0 to 5.x, or at the very least to try and see if it's compiler/distro related, which I forgot to double-check sooner.


2018-06-08 15:23

manager   ~0009727

I certainly get the same problem with 4.x. A general solution to the problem is to write componentColumns as a "super-token" which supports binary writing. In CSV.C:

template<class Type>
void Foam::Function1Types::CSV<Type>::writeData(Ostream& os) const
    os << token::END_STATEMENT << nl;
    os << indent << word(this->name() + "Coeffs") << nl;
    os << indent << token::BEGIN_BLOCK << incrIndent << nl;

    // Note: for TableBase write the dictionary entries it needs but not
    // the values themselves

    os.writeKeyword("nHeaderLine") << nHeaderLine_ << token::END_STATEMENT
        << nl;

    os.writeKeyword("refColumn") << refColumn_ << token::END_STATEMENT << nl;

    componentColumns_.writeEntry("componentColumns", os);

    os.writeKeyword("separator") << string(separator_)
        << token::END_STATEMENT << nl;
    os.writeKeyword("mergeSeparators") << mergeSeparators_
        << token::END_STATEMENT << nl;
    os.writeKeyword("file") << fName_ << token::END_STATEMENT << nl;
    os << decrIndent << indent << token::END_BLOCK << endl;

Alternatively the reading would need to stream-type juggling to read this particular list in ASCII.


2018-06-08 15:38

manager   ~0009728

I ran some more tests on 4.x and it works up to foamToVTK but not foamDictionary.


2018-06-08 15:45

updater   ~0009729

Sorry, I was in a hurry in the latest tests and did stop at testing with foamToVTK. The same happens for me, foamDictionary fails with OpenFOAM 4.x... with is interesting in itself... but I haven't continued investigating further into it.


2018-06-08 23:08

manager   ~0009730

Resolved by commit 338af656851a0f67e7c779c47d7634f31c9ef403

Issue History

Date Modified Username Field Change
2018-05-22 17:58 wyldckat New Issue
2018-05-22 17:58 wyldckat File Added: pitzDailyCSV.tar.gz
2018-05-22 18:01 wyldckat Note Added: 0009622
2018-06-08 14:56 henry Note Added: 0009724
2018-06-08 15:19 wyldckat Note Added: 0009725
2018-06-08 15:23 henry Note Added: 0009727
2018-06-08 15:38 henry Note Added: 0009728
2018-06-08 15:45 wyldckat Note Added: 0009729
2018-06-08 23:08 henry Assigned To => henry
2018-06-08 23:08 henry Status new => resolved
2018-06-08 23:08 henry Resolution open => fixed
2018-06-08 23:08 henry Fixed in Version => dev
2018-06-08 23:08 henry Note Added: 0009730