CFD Online Discussion Forums

CFD Online Discussion Forums (
-   OpenFOAM Bugs (
-   -   Failure to start from latest time when BC stores scalarlist (

Phicau February 25, 2014 07:13

Failure to start from latest time when BC stores scalarlist
1 Attachment(s)
Dear all,

I have observed that OpenFOAM fails to start from latest time when a custom boundary condition stores (and not even needs to read) a scalarlist. The error is as follows:


Create time

Create mesh for time = 0.1

Reading transportProperties

Reading field p

Reading field U

"ill defined primitiveEntry starting at keyword 'dumlist' on line 32 and ending at line 33"

file: /media/work/OpenFOAM/OpenFOAM-2.3.0/run/testBug/cavity_bin/0.1/U at line 33.

    From function primitiveEntry::readEntry(const dictionary&, Istream&)
    in file lnInclude/IOerror.C at line 132.

FOAM exiting

This only happens when you are writing the files in binary format. Simulations stored in ascii format or with scalars stored instead of scalarLists run flawlessly. The same error is present at least from version 2.1.1 to 2.3

I have created an easy-to-check scenario, so it can be reproduced in a direct manner (v. 2.2.2 or 2.3). Please, find it attached. The case is based on the cavity tutorial, only that the new BC has been applied. The new BC is called 'failFixedValue' and is a modified version of 'oscillatingFixedValue', tailored to behave as fixedValue and to store a dummy scalarList associated to the BC.

Am I doing something wrong or this is in fact a bug?



Phicau February 25, 2014 11:08

That was quick.

I have further questions and hope that someone is able to answer or correct me.

Defining the former scalarList as a scalarField in the following way yields the same error for the binary case:


    scalarField dumfield = scalarField(10, -1.0);
    dumfield[3] = 6.0;
    os.writeKeyword("dumfield") << dumfield << token::END_STATEMENT << nl;

The next thing I thought to implement this solution is to output the scalarField by defining it as an IOobject and running dumfield.write();

However some questions arise, as for example, if the BC is applied to two different boundaries, with different dumfield values, one would overwrite the other and mess everything, wouldn't it?

I could try to create the field as dumfield_boundaryName, but isn't it a mess? Any thoughts on a better solution?



Phicau February 26, 2014 04:43

Well, problem solved, it works either way as a scalarList or scalarField, but it has to be written out using the following command:


dumthing.writeEntry("dumthing", os);
Solution found in "totalTemperatureFvPatchScalarField.C". Apparently "#include fieldTypes.H " is not needed.

Thanks mattijs for your guidance!


This is great... now paraview fails to open this binary case due to not understanding the scalarLists embedded in the BC. Of course, no trouble with the ascii format.

All times are GMT -4. The time now is 20:59.