Internal .foam reader for OpenFOAM data: Issue with fixedGradient boundary condition


(Yousef Kanani) #1

Hi,
The OpenFOAM data writer does not write the face values associated to the fixedGradient boundary condition. If ParaView is loaded with Openfoam libraries (i.e. ParaFoam), ParaView correctly evaluates the patch values according to the provided gradient.

However, using the internal reader (.foam) and without loading OpenFOAM libraries (e.g. ParaView in windows), the gradient provided in the boundary condition is not considered and the patch values will be evaluated with zeroGradient assumption and hence the displayed patch values are wrong. In the other words, it displays same values for face values (at the patch) and the adjacent cell center value.

I recently reported to Openfoam issue tracking (here) but since the reader provided by OpenFOAM works properly, no update has been made to the code (e.g. writing the patch values in the data file so ParaView can easily read it).
I have already fixed this issue for my own need by modifying OpenFOAM code and force it to write the patch values.

However, I am reporting this here to see if there is any possible solution to this issue from the ParaView’s side so that other Openfoam/ParaView users will not face this issue in the future. ParaView does not even issue any warning about this so it will be assumed that the patch values are correct (we have been looking at wrong values for a while before figuring this out).

Thanks,
Yousef


(Mathieu Westphal) #2

the .OpenFOAM reader in ParaFOAM and the .foam reader in ParaView are two completely separate code.

the .OpenFOAM reader is managed by the different developers of OpenFOAM while the .foam reader is managed by paraview developers.

If you have found some bugs or missing features with the .foam reader, feel free to discuss them in this topic or to open more specific issues on gitlab.kitware.com/paraview/paraview

If you are able to contribute to the .foam reader and improve it, contributions are very welcome as well.

I can’t help you much with your specific issue though.


(Yousef Kanani) #3

Thanks you for your response Mathieu. That is true, I was am aware this difference. And the issue that I reported was related to .foam reader.
I am certain that the problem that I reported exists in the .foam reader, what I am not sure is that whether it can be fixed by a reader or not.
Because the values at the patch are not available in the data files. The only information available is the gradient value. I am not sure if it is possible to modify the .foam reader to apply the patch normal gradient to the adjacent cell center values and calculate the patch values. Unfortunately, I don’t know the details of the readers and how they work…

I thought it would be better to make sure that there is a possible to fix before submitting an issue in the issue tracker.


(Mark) #4

Hi Yousef,
I wouldn’t necessarily consider this a bug in the native reader, but more of a “feature gap” between expectations and current reality.
As a very minimal implementation of fixedGradient, you would need the location of the face centre and then figure out which volume cell this corresponds to in order to determine the location of that cell centre and to access the corresponding cell field value for the particular field. If you get all that together, it should be too difficult to apply the gradient to obtain the face value.

In the VTK representation, the faces and the volume cells use the same points, but there is no immediate connection between a face and any particular volume cell. There might be a fast means of looking them up based on the points being used, or maybe you need an octree method to search based on nearest neighbours.

Unless there is already something like that already within VTK, I think that this is a non-trivial problem to solve … and probably too much to ask of a file “reader”.

/mark