View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001867 | OpenFOAM | Bug | public | 2015-10-13 13:02 | 2015-10-14 09:26 |
| Reporter | fabian_roesler | Assigned To | henry | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | no change required | ||
| Platform | Unix | OS | CentOs | OS Version | 6.5 |
| Summary | 0001867: uniformFixedValue BC not read by praview | ||||
| Description | When 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. | ||||
| Tags | No tags attached. | ||||
|
|
I forgot one more information. This is happening to me when using a ramp for velocity inlet. Didn't check for scalar fields. |
|
|
@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: https://github.com/OpenFOAM/OpenFOAM-2.4.x/blob/master/src/finiteVolume/fields/fvPatchFields/derived/uniformFixedValue/uniformFixedValueFvPatchField.C#L162 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. |
|
|
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. |
|
|
This is a limitation in the built-in reader. If we run: cd $FOAM_RUN/tutorials/basic/potentialFoam/cylinder ./Allrun 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. |
|
|
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. |
|
|
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 <http://cfd.direct> 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. |
| 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 | |
| 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 |
