(0027293)
Takuya OSHIMA (reporter)
2011-08-07 01:03

Frank, can you post a test case that demonstrates the problem? And which version of OpenFOAM are you using?

(0027294)
Takuya OSHIMA (reporter)
2011-08-07 01:07

Alternatively you can point me to one of the tutorial cases with OF version specified.

(0027297)
Frank Albina (reporter)
2011-08-08 04:03
edited on: 2011-08-08 04:06

OpenFoam version is 1.7.x. The issue is reproducible with the rhoPimpleFoam tutorial, located in:
[...]/tutorials/compressible/rhoPimpleFoam/ras/angledDuct

Procedure:
a) run the tutorial in double precision (default) in parallel on 4 CPUs.
b) edit the system/controlDict and change the writeFormat to ascii.
c) convert the solution file to ascii format by running:
   mpirun -np 4 foamFormatConvert -parallel
d) Run paraview and try to read the solution from the last time step.

With the standard OF reader, for instance the following error will arise:
ERROR: In ParaView-3.10.1/VTK/IO/vtkOpenFOAMReader.cxx, line 6466
vtkOpenFOAMReaderPrivate (0x1a595b0): Error reading line 5579 of [...]/angledDuct/processor3/0.01/U: Expected punctuation token '(', found ;

The content of file processor3/0.01/U around the line 5579 is:
   5572 inlet
   5573 {
   5574 type turbulentFlowRateInletVelocity;
   5575 rho rho;
   5576 fluctuationScale ( 0.01 0.01 0.01 );
   5577 alpha 0.1;
   5578 flowRate 0.1;
   5579 value nonuniform 0;
   5580 }

Note that all other variables such as rho, p and T show the same errors.

With the patch supplied, these errors do not appear and the solution from the last time step is readable. The same issue on paraview 3.8.1 exists for which a similar fix was done and has been used extensively for parallel simulations without a glitch.

(0027298)
Takuya OSHIMA (reporter)
2011-08-08 09:29

The problem is that foamFormatConvert does not recover the correct syntax for zero-sized list when converting binary files to ascii format.

In OpenFOAM 1.7.x, if we pull decomposeParDict from the damBreak case and run the tutorials/compressible/rhoPimpleFoam/angledDuct case in parallel with writeFormat ascii, we find in processor3/10/U:

10047 inlet
10048 {
10049 type flowRateInletVelocity;
10050 flowRate 0.1;
10051 value nonuniform 0();
10052 }

which is in expected format and read correctly by the reader. However, if we run the case in parallel with writeFormat binary and run foamFormatConvert to convert to ascii format, it produces

10047 inlet
10048 {
10049 type flowRateInletVelocity;
10050 flowRate 0.1;
10051 value nonuniform 0;
10052 }

which is valid in binary format but not in ascii format. Especially, note that the ascii format requires the trailing '()' whereas the binary format does not, in which point your patch is not correct. I would rather say it is a problem in foamFormatConvert.

p.s. I see small discrepancies in your case and mine here and there (no ras/ path, time 0.01 vs 10, turbulentFlowRateInletVelocity vs. flowRateInletVelocity, ...). Are we really talking about the same case?

(0027299)
Frank Albina (reporter)
2011-08-08 10:04

We are talking about the same case, even though there are some discrepancies which are coming from me playing around with this tutorial case, but this does not change the result though.

To your comment concerning foamFormatConvert, you are right stating that there is a problem with the application not writing the trailing (), even though the field has a length of 0, so you end up with "value nonuniform 0;" instead of "value nonuniform 0();".

Basically, one has two options:
1) fix the code for foamFormatConvert to append the trailing (), even though the boundary patch is of size 0. However, OpenFOAM is capable of handling this format "discrepancy" seemlessly, which shows that the code is robust in handling this kind of issue.

2) Make the OF reader on the PV side more robust for handling this kind of mismatch. If the size if 0, why would you require the addtional () anyway? The patch I have submitted handles this and has been working for me for the last 6 months on a daily basis with Paraview 3.8.1. Note that I am talking about a particular case where a conversion from binary to ASCII is performed.

Of course, if the converter is ever going to be fixed one day, the issue will not exist any more. But for the time being, I would personnally go for having a more robust solution. I will check in the meantime if there is an easy fix for the application foamFormatConvert.

(0027310)
Takuya OSHIMA (reporter)
2011-08-08 20:56

1) That is because OpenFOAM totally skips parsing the tokenized stream when it knows beforehand that the list size is zero (cf. Field<Type>::Field(const word& keyword, const dictionary& dict, const label s) in
OpenFOAM-1.7.x/src/OpenFOAM/fields/Fields/Field/Field.C). The reader combines tokenization and parsing processes of the stream for performance, which enforces the reader to read everything without the knowledge.

2) Skipping () leaves an extra '()' (which will be interpreted as an extra empty list) in the stream, which in turn may cause unexpected problem. Since OpenFOAM is a generic toolkit with great ability of modifications, a code for particular cases that is working for someone does not mean it will work for everyone.

My suggestion is to run your case with writeFormat ascii in the first place or file a bug report on the OpenFOAM site.

(0027311)
Frank Albina (reporter)
2011-08-09 02:37

Skipping the () does not leave an extra '()' if you use the patch applied, which does skip the tokenized stream. As I was mentioning it earlier, I am using this patch for quite a while now without any issues and I submitted it to make the OF reader more robust. This is probably not the most elegant way of doing it but it works for what it does.

Now, I can always file a bug to OF and ask them to fix the class Field.C, but they could also maintain that this is a ParaView issue and we would be back to square one. Meanwhile, unfortunately, I will still need to patch manually the OF reader if I want to have the flexibility to convert my solution from binary to ASCII format.

Anyway, from this discussion, it appears that this issue won't fix for the time being. Please consider this case closed.

(0038028)
Kitware Robot (administrator)
2016-08-12 09:58

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current ParaView Issues page linked in the banner at the top of this page.

Notes
(0027293) Takuya OSHIMA (reporter) 2011-08-07 01:03	Frank, can you post a test case that demonstrates the problem? And which version of OpenFOAM are you using?

(0027294) Takuya OSHIMA (reporter) 2011-08-07 01:07	Alternatively you can point me to one of the tutorial cases with OF version specified.

(0027297) Frank Albina (reporter) 2011-08-08 04:03 edited on: 2011-08-08 04:06	OpenFoam version is 1.7.x. The issue is reproducible with the rhoPimpleFoam tutorial, located in: [...]/tutorials/compressible/rhoPimpleFoam/ras/angledDuct Procedure: a) run the tutorial in double precision (default) in parallel on 4 CPUs. b) edit the system/controlDict and change the writeFormat to ascii. c) convert the solution file to ascii format by running: mpirun -np 4 foamFormatConvert -parallel d) Run paraview and try to read the solution from the last time step. With the standard OF reader, for instance the following error will arise: ERROR: In ParaView-3.10.1/VTK/IO/vtkOpenFOAMReader.cxx, line 6466 vtkOpenFOAMReaderPrivate (0x1a595b0): Error reading line 5579 of [...]/angledDuct/processor3/0.01/U: Expected punctuation token '(', found ; The content of file processor3/0.01/U around the line 5579 is: 5572 inlet 5573 { 5574 type turbulentFlowRateInletVelocity; 5575 rho rho; 5576 fluctuationScale ( 0.01 0.01 0.01 ); 5577 alpha 0.1; 5578 flowRate 0.1; 5579 value nonuniform 0; 5580 } Note that all other variables such as rho, p and T show the same errors. With the patch supplied, these errors do not appear and the solution from the last time step is readable. The same issue on paraview 3.8.1 exists for which a similar fix was done and has been used extensively for parallel simulations without a glitch.

(0027298) Takuya OSHIMA (reporter) 2011-08-08 09:29	The problem is that foamFormatConvert does not recover the correct syntax for zero-sized list when converting binary files to ascii format. In OpenFOAM 1.7.x, if we pull decomposeParDict from the damBreak case and run the tutorials/compressible/rhoPimpleFoam/angledDuct case in parallel with writeFormat ascii, we find in processor3/10/U: 10047 inlet 10048 { 10049 type flowRateInletVelocity; 10050 flowRate 0.1; 10051 value nonuniform 0(); 10052 } which is in expected format and read correctly by the reader. However, if we run the case in parallel with writeFormat binary and run foamFormatConvert to convert to ascii format, it produces 10047 inlet 10048 { 10049 type flowRateInletVelocity; 10050 flowRate 0.1; 10051 value nonuniform 0; 10052 } which is valid in binary format but not in ascii format. Especially, note that the ascii format requires the trailing '()' whereas the binary format does not, in which point your patch is not correct. I would rather say it is a problem in foamFormatConvert. p.s. I see small discrepancies in your case and mine here and there (no ras/ path, time 0.01 vs 10, turbulentFlowRateInletVelocity vs. flowRateInletVelocity, ...). Are we really talking about the same case?

(0027299) Frank Albina (reporter) 2011-08-08 10:04	We are talking about the same case, even though there are some discrepancies which are coming from me playing around with this tutorial case, but this does not change the result though. To your comment concerning foamFormatConvert, you are right stating that there is a problem with the application not writing the trailing (), even though the field has a length of 0, so you end up with "value nonuniform 0;" instead of "value nonuniform 0();". Basically, one has two options: 1) fix the code for foamFormatConvert to append the trailing (), even though the boundary patch is of size 0. However, OpenFOAM is capable of handling this format "discrepancy" seemlessly, which shows that the code is robust in handling this kind of issue. 2) Make the OF reader on the PV side more robust for handling this kind of mismatch. If the size if 0, why would you require the addtional () anyway? The patch I have submitted handles this and has been working for me for the last 6 months on a daily basis with Paraview 3.8.1. Note that I am talking about a particular case where a conversion from binary to ASCII is performed. Of course, if the converter is ever going to be fixed one day, the issue will not exist any more. But for the time being, I would personnally go for having a more robust solution. I will check in the meantime if there is an easy fix for the application foamFormatConvert.

(0027310) Takuya OSHIMA (reporter) 2011-08-08 20:56	1) That is because OpenFOAM totally skips parsing the tokenized stream when it knows beforehand that the list size is zero (cf. Field<Type>::Field(const word& keyword, const dictionary& dict, const label s) in OpenFOAM-1.7.x/src/OpenFOAM/fields/Fields/Field/Field.C). The reader combines tokenization and parsing processes of the stream for performance, which enforces the reader to read everything without the knowledge. 2) Skipping () leaves an extra '()' (which will be interpreted as an extra empty list) in the stream, which in turn may cause unexpected problem. Since OpenFOAM is a generic toolkit with great ability of modifications, a code for particular cases that is working for someone does not mean it will work for everyone. My suggestion is to run your case with writeFormat ascii in the first place or file a bug report on the OpenFOAM site.

(0027311) Frank Albina (reporter) 2011-08-09 02:37	Skipping the () does not leave an extra '()' if you use the patch applied, which does skip the tokenized stream. As I was mentioning it earlier, I am using this patch for quite a while now without any issues and I submitted it to make the OF reader more robust. This is probably not the most elegant way of doing it but it works for what it does. Now, I can always file a bug to OF and ask them to fix the class Field.C, but they could also maintain that this is a ParaView issue and we would be back to square one. Meanwhile, unfortunately, I will still need to patch manually the OF reader if I want to have the flexibility to convert my solution from binary to ASCII format. Anyway, from this discussion, it appears that this issue won't fix for the time being. Please consider this case closed.

(0038028) Kitware Robot (administrator) 2016-08-12 09:58	Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current ParaView Issues page linked in the banner at the top of this page.

Issue History
Date Modified	Username	Field	Change
2011-08-04 10:26	Frank Albina	New Issue
2011-08-04 10:26	Frank Albina	File Added: vtkOpenFOAMReader.cxx.patch
2011-08-07 01:03	Takuya OSHIMA	Note Added: 0027293
2011-08-07 01:07	Takuya OSHIMA	Note Added: 0027294
2011-08-08 04:03	Frank Albina	Note Added: 0027297
2011-08-08 04:06	Frank Albina	Note Edited: 0027297
2011-08-08 09:29	Takuya OSHIMA	Note Added: 0027298
2011-08-08 10:04	Frank Albina	Note Added: 0027299
2011-08-08 20:56	Takuya OSHIMA	Note Added: 0027310
2011-08-09 02:37	Frank Albina	Note Added: 0027311
2016-08-12 09:58	Kitware Robot	Note Added: 0038028
2016-08-12 09:58	Kitware Robot	Status	backlog => closed
2016-08-12 09:58	Kitware Robot	Resolution	open => moved
2016-08-12 09:58	Kitware Robot	Assigned To	=> Kitware Robot

Relationships