View Issue Details

IDProjectCategoryView StatusLast Update
0001867OpenFOAM[All Projects] Bugpublic2015-10-14 09:26
Reporterfabian_roeslerAssigned Tohenry 
Status resolvedResolutionno change required 
PlatformUnixOSCentOsOS Version6.5
Product Version 
Fixed in Version 
Summary0001867: uniformFixedValue BC not read by praview
DescriptionWhen using a tabulated uniformFixedValue BC, paraview is unable to read the boundary field and thus does not display any information of the field. Internal field is omitted too.
As OpenFOAM doesn't replace the table of the BC, no nonuniform list is available of the patch and thus paraview cant read the whole field.
So when using this BC it's a pain to display the results by sed and awk the files.
TagsNo tags attached.



2015-10-13 13:31

reporter   ~0005395

I forgot one more information. This is happening to me when using a ramp for velocity inlet. Didn't check for scalar fields.


2015-10-13 13:33

updater   ~0005396

Last edited: 2015-10-13 13:34

View 2 revisions

@fabian_roesler: I believe I know what you're referring to, namely that you're using the built-in reader that ParaView has got, correct?
For example, running "paraFoam" with the "-builtin" option?
Or simply by opening a file with the extension ".foam"?

I've thought about this lately and perhaps it's possible to have a more consistent workaround, namely to have the "uniformFixedValue" class to also write the "value" entry.

But the problem that I can see right now is that the source code has a comment explicitly stating not to write the "value" entry:
Although in one of the constructors it explicitly looks for the "value" entry for initializing the patch field...

@Henry: I can't see any specific reason why the "value" entry cannot be written, unless it's to avoid inconsistencies.


2015-10-13 14:01

manager   ~0005397

The value does not need to be written as it is calculated from the table which guarantees consistency. If the value were read and used and inconsistent with the table then very sudden and accelerations could be generated and cause a crash. This is particularly a problem if the table is changed for a restart; if the value were present and read it would need to be updated by hand to correspond to the new table. It is MUCH better that the value is not written.

I have not seen any problem post-processing cases containing uniformFixedValue BCs.


2015-10-13 14:17

updater   ~0005398

This is a limitation in the built-in reader. If we run:

  cd $FOAM_RUN/tutorials/basic/potentialFoam/cylinder
  paraFoam -builtin

Then we choose to only load the U and p files (because the internal reader selects all fields by default), then ParaView will give this error message:

  ERROR: In /home/ofuser/OpenFOAM/ThirdParty-2.4.x/ParaView-4.1.0/VTK/IO/Geometry/vtkOpenFOAMReader.cxx, line 6524
  vtkOpenFOAMReaderPrivate (0x3d1cac0): Wrong list type for uniform field

One workaround is to create the "value" entry for the boundary conditions that ParaView/VTK is not familiar with, because it loads this field by default for unknown BCs.
Another workaround is as Fabian mentioned: to use sed and awk for modifying the files before opening in ParaView.

So I guess this is to be catalogued as a bug in ParaView/VTK's internal reader, not to do with OpenFOAM itself, given that foamToVTK can be used to export the results, albeit not as practical.


2015-10-13 14:27

manager   ~0005399

Alternatively paraFoam can be used with the OpenFOAM reader which uses the OpenFOAM classes to read OpenFOAM data and is hence guaranteed to be consistent and support all the functionality of the OpenFOAM IO system. If you find that the OpenFOAM reader has problem reading BCs please report and I will work on it.


2015-10-14 09:26

manager   ~0005400

I have made the behaviour of uniformFixedValueFvPatchField consistent between OpenFOAM-2.4.x and the latest version in OpenFOAM-dev:

commit 0fa65b7819806d6803dfa2a51b3f7dd726f7d328
Author: Henry Weller <>

    uniformFixedValueFvPatchField: Remove the inconsistent optional "value"
    read in the construction from dictionary.
    It is important that the initial value is obtained from the table
    provided to avoid the user having to evaluate a consistent one or risk
    the code crashing from a very sudden change in the value.
    The current value is now written for post-processing convenience only.

Issue History

Date Modified Username Field Change
2015-10-13 13:02 fabian_roesler New Issue
2015-10-13 13:31 fabian_roesler Note Added: 0005395
2015-10-13 13:33 wyldckat Note Added: 0005396
2015-10-13 13:34 wyldckat Note Edited: 0005396 View Revisions
2015-10-13 14:01 henry Note Added: 0005397
2015-10-13 14:17 wyldckat Note Added: 0005398
2015-10-13 14:27 henry Note Added: 0005399
2015-10-13 14:28 henry Status new => resolved
2015-10-13 14:28 henry Resolution open => no change required
2015-10-13 14:28 henry Assigned To => henry
2015-10-14 09:26 henry Note Added: 0005400