View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0002950OpenFOAMBugpublic2018-05-22 17:582018-06-08 23:08
Reporterwyldckat Assigned Tohenry  
PrioritylowSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinux 
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:

    --> FOAM FATAL ERROR:
    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:

    --> FOAM FATAL IO ERROR:
    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:

    inlet
    {
        type fixedProfile;
        profile csvFile;

        profileCoeffs
        {
            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
  foamRunTutorials
  foamToVTK
  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:

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

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

Activities

wyldckat

2018-05-22 17:58

updater  

pitzDailyCSV.tar.gz (3,296 bytes)

wyldckat

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).

henry

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.

wyldckat

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 <http://openfoam.org>
  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.

henry

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
{
    Function1<Type>::writeData(os);
    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
    TableBase<Type>::writeEntries(os);

    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.

henry

2018-06-08 15:38

manager   ~0009728

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

wyldckat

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.

henry

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