# Point data for OpenFOAM, coordinates
**URL:** https://discourse.paraview.org/t/point-data-for-openfoam-coordinates/16949
**Category:** ParaView Support
**Tags:** openfoam
**Created:** [July 14, 2025, 1:08pm UTC](https://discourse.paraview.org/t/point-data-for-openfoam-coordinates/16949 "2025-07-14T13:08:35Z")
**Posts on this page:** 16
**Page:** 1
### Author:  [@niklyush](https://discourse.paraview.org/u/niklyush)
#### Post date: [July 14, 2025, 1:08pm UTC](https://discourse.paraview.org/t/point-data-for-openfoam-coordinates/16949/1 "2025-07-14T13:08:35Z")
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,
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [July 15, 2025, 7:46am UTC](https://discourse.paraview.org/t/point-data-for-openfoam-coordinates/16949/2 "2025-07-15T07:46:14Z")
> [@niklyush](#):
>
> I use paraview (paraFoam)
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
---
### Author:  [@niklyush](https://discourse.paraview.org/u/niklyush)
#### Post date: [July 16, 2025, 3:13pm UTC](https://discourse.paraview.org/t/point-data-for-openfoam-coordinates/16949/3 "2025-07-16T15:13:06Z")
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](https://discourse.paraview.org/uploads/short-url/6YH9f1cwRIFbYxQpZjB5IHfQ1Ef.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
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [July 17, 2025, 7:33am UTC](https://discourse.paraview.org/t/point-data-for-openfoam-coordinates/16949/4 "2025-07-17T07:33:39Z")
I can open the data you shared and I see `-0.01365` in the spreadsheet view.
Where do you see `-0.01365000009536743` ?
---
### Author:  [@niklyush](https://discourse.paraview.org/u/niklyush)
#### Post date: [July 17, 2025, 8:13am UTC](https://discourse.paraview.org/t/point-data-for-openfoam-coordinates/16949/5 "2025-07-17T08:13:43Z")
Have you set Precision to 16 digits? In our application we happened to need high precision. I attach a screenshot of my ParaView:
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [July 17, 2025, 8:42am UTC](https://discourse.paraview.org/t/point-data-for-openfoam-coordinates/16949/6 "2025-07-17T08:42:51Z")
Please precise which setting you set
---
### Author:  [@niklyush](https://discourse.paraview.org/u/niklyush)
#### Post date: [July 17, 2025, 9:39am UTC](https://discourse.paraview.org/t/point-data-for-openfoam-coordinates/16949/7 "2025-07-17T09:39:27Z")
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
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [July 17, 2025, 9:45am UTC](https://discourse.paraview.org/t/point-data-for-openfoam-coordinates/16949/8 "2025-07-17T09:45:52Z")
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](https://en.wikipedia.org/wiki/Double-precision_floating-point_format)
---
### Author:  [@niklyush](https://discourse.paraview.org/u/niklyush)
#### Post date: [July 23, 2025, 10:51am UTC](https://discourse.paraview.org/t/point-data-for-openfoam-coordinates/16949/9 "2025-07-23T10:51:46Z")
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?
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [July 23, 2025, 10:58am UTC](https://discourse.paraview.org/t/point-data-for-openfoam-coordinates/16949/10 "2025-07-23T10:58:34Z")
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)](https://www.binaryconvert.com/result_float.html?decimal=045048046048049051054053048048048048048048048048048048048048)
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.
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [July 23, 2025, 11:00am UTC](https://discourse.paraview.org/t/point-data-for-openfoam-coordinates/16949/11 "2025-07-23T11:00:41Z")
A more comprehensive explanation here: [https://0.30000000000000004.com/](https://0.30000000000000004.com/)
---
### Author:  [@niklyush](https://discourse.paraview.org/u/niklyush)
#### Post date: [July 23, 2025, 11:15am UTC](https://discourse.paraview.org/t/point-data-for-openfoam-coordinates/16949/12 "2025-07-23T11:15:45Z")
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?
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [July 23, 2025, 11:19am UTC](https://discourse.paraview.org/t/point-data-for-openfoam-coordinates/16949/13 "2025-07-23T11:19:56Z")
A quick look at the vtkOpenFOAMReader shows that it casts down to float even if the data is in double:
```auto
try
{
if (io.IsFloat64())
{
dict.ReadNonUniformList>(io);
}
else
{
dict.ReadNonUniformList>(io);
}
// Transfer float tuples to points
auto* pointArray = dict.ReleasePtr();
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 )
---
### Author:  [@niklyush](https://discourse.paraview.org/u/niklyush)
#### Post date: [July 23, 2025, 11:37am UTC](https://discourse.paraview.org/t/point-data-for-openfoam-coordinates/16949/14 "2025-07-23T11:37:28Z")
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
---
### Author:  [@olesenm](https://discourse.paraview.org/u/olesenm)
#### Post date: [July 28, 2025, 8:47am UTC](https://discourse.paraview.org/t/point-data-for-openfoam-coordinates/16949/15 "2025-07-28T08:47:19Z")
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.
---
### Author:  [@niklyush](https://discourse.paraview.org/u/niklyush)
#### Post date: [July 31, 2025, 3:53pm UTC](https://discourse.paraview.org/t/point-data-for-openfoam-coordinates/16949/16 "2025-07-31T15:53:45Z")
I see, Mark, sure. Thanks for clarifying the situation.