Point data for OpenFOAM, coordinates

ParaView Support
1

Good day to everyone. I would like to ask for an advice of somebody more experienced with ParaView than me, and I will be grateful for any input.

I use paraview (paraFoam) to postprocess and also to export data after an OpenFOAM simulation. Specifically I export point data in .csv files using SpreadSheetView. And I’ve noticed that actual coordinates of points are slightly different from those in OpenFOAM (in “points” file), in 7-8-th digits, but different. That happened to be significant for some of mine additional postprocessing, so I would like to ask a couple of questions:

  1. Is that really true that ParaView uses different points for interpolating point data, or I am doing something wrong? Because it was surprising for me, to be honest.

  2. If it is true - is there a way to similarly get point data but in exact vertices of the OpenFOAM mesh? I understand, that OpenFOAM uses cellcenters for computation, but anyway the whole mesh is there.

I use an ubuntu build of OpenFOAM-11, and it shows version 5.10.0-RC1 of paraview, which I launch through paraFoam.

Thanks in advance for your time,
Best,

2

ParaView is not paraFOAM, paraFOAM is not ParaView but is merely based on it.
This is a ParaView support discourse, not paraFOAM.

In any case, please share data to reproduce.

version 5.10.0-RC1 of paraview

This is old, please use 5.13 or 6.0.0-RC2

3

Dear Mathieu,

thank you for the answer. Sorry for the confusion of paraFOAM with ParaView, I thought one may treat them as equivalents.

I’ve downloaded the latest version of ParaView (6.0.0-RC2) for Windows and the issue is still there. So I attach the data to reproduce, and I’ll be very grateful for any thoughts and advice:

test_case.rar (529.0 KB)

Attached is a folder of an OpenFOAM case, it can be opened in ParaView through the file “file_to_open_the_case.foam” (the way I know to open cases). Then if one goes to SpreadSheetView for point data, sets Precision for 16 and in parallel opens file Points from folder Constant/polyMesh, it can be immediately seen that, for example, Z coordinates of the first points are messed up after 11-th digit (it is even -0.01365 in Points and -0.01365000009536743 in ParaView). So I would like to know why does that happen and is there something to do to change that (I mean to make ParaView to use the mesh from the case).

Thanks again for your time,
Best,
Nikita

4

I can open the data you shared and I see -0.01365 in the spreadsheet view.

Where do you see -0.01365000009536743 ?

5

Have you set Precision to 16 digits? In our application we happened to need high precision. I attach a screenshot of my ParaView:

screenshot
screenshot1669×1001 112 KB

6

Please precise which setting you set

7

Thanks for your collaboration, Mathieu! But what setting exactly do you mean? I downloaded ParaView for Windows and haven’t changed there anything general, so all settings should be default. Then I open the case through opening file “file_to_open_the_case.foam”, then I press apply and choose two panel view (Split Horizontal Axis). On the right side I choose SpreadSheetView, there I remove all visible data except Points to see only coordinates and then I change in the upper menu of the SpreadSheetView window Precision to 16 (instead of default 6). And that’s how I see the screen attached above

8

Ok got it.

What you see is due to the fact that in not all number can be accuretely represented using floating point numbers, which ParaView (and all software except very specialized software uses).

You can read it up here: Double-precision floating-point format - Wikipedia

9

Thanks for the answer, Mathieu, I was contemplating it, but unfortunately I still don’t understand it. Could you please elaborate a bit?

Do I understand right, that paraView doesn’t use OpenFOAM mesh for points, but computes it by itself based on cell centers? And during these computations errors occur because of different reasons, including the one you mentioned? The thing is that I don’t see a problem of representing number -0.01365 as -0.01365000000000000, so where does -0.01365000009536743 come from?

10

It has nothing to do with OpenFOAM or ParaView, it’s just that using floating-point format it is not possible to store the number -0.01365000000000000 exactly, the closest number that can be stored using Single-precision floating-point format is -0.01365000009536743. You can check it here: Float (IEEE754 Single precision 32-bit)

For some reason OpenFOAM or ParaView is not using double-precision for your numbers. Maybe this is a OpenFOAM limitation, maybe this is a ParaView issue, even then, using double-precision you would get -0.0136500000000000006744604874598 instead.

11

A more comprehensive explanation here: https://0.30000000000000004.com/

12

Oh, so the problem is in single precision, I get it now, thanks for the elaboration! The problem is exactly with not enough digits, double precision would be fine for me. My OpenFOAM should work in double, but anyway since it is a ParaView discourse - could you please suggest how one can check if ParaView works in double precision and what settings may influence that?

13

A quick look at the vtkOpenFOAMReader shows that it casts down to float even if the data is in double:

        try
        {     
          if (io.IsFloat64())
          {
            dict.ReadNonUniformList<vtkFoamToken::VECTORLIST, //
              vtkFoamRead::vectorListTraits<vtkFloatArray, double, 3, true>>(io);
          }     
          else  
          {     
            dict.ReadNonUniformList<vtkFoamToken::VECTORLIST, //
              vtkFoamRead::vectorListTraits<vtkFloatArray, float, 3, true>>(io);
          }     

          // Transfer float tuples to points
          auto* pointArray = dict.ReleasePtr<vtkFloatArray>();

          points->SetData(pointArray);
          pointArray->Delete();
          missingCloud = false;
        }

So the OpenFOAMReader of ParaView doesn’t support double points properly yet.

what settings may influence that?

It should be implemented in the OpenFOAMReader properly.

(FYI @olesenm )

14

I see, it is a bit unexpected, but at least now it is clear. Thanks a lot again, Mathieu, for your time and help! We’ll try to deal with it as it is or find some workaround

1 Like
15

This was partly to keep consistency with the foamToVTK behaviour, and with the intention of reducing the memory footprint. Obviously the loss of precision is probably a bad idea for some applications. Will add to the mental “to-do” list, but currently no time available for fixing.

1 Like
16

I see, Mark, sure. Thanks for clarifying the situation.