Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Native ParaView .foam reader cannot render fixedGradient BCs correctly #229

Open
davidscn opened this issue Jul 13, 2021 · 5 comments
Open

Comments

@davidscn
Copy link
Member

This issue is mainly re-documenting the following issue from ParaView: https://discourse.paraview.org/t/internal-foam-reader-for-openfoam-data-issue-with-fixedgradient-boundary-condition/698, since it is quite relevant for our partitioned approaches. To sum the issue up: in order to visualize an OpenFOAM case with fixedGradient boundary conditions correctly, one needs to use paraFoam/ ParaView with the OpenFOAM plugins which reads .OpenFOAM files. The native paraView reader assumes that a fixedGradient BC is essentially a zero gradient boundary condition, which obviously leads to wrong values at the respective interface.
I visualized the same result file of our partitioned-heat case (domain length of 1 with 50 uniform elements in surface normal direction which is rather fine resolved) with native ParaView (.foam) and the paraFoam (.OpenFOAM) reader and exported the data plot in a csv file in order to compare both plots. The result looks as follows (upper figure whole domain, lower figure zoom in):


Maybe we should document this somewhere in the adapter documentation.

@uekerman
Copy link
Member

Does this also happen when you use foam2vtk?

@davidscn
Copy link
Member Author

davidscn commented Jul 14, 2021

Yes, foamToVTK seems to resolve the boundary condition properly. As opposed to any ParaView, it even renders/evaluates time dependent groovyBC correctly.

@MakisH
Copy link
Member

MakisH commented Jul 27, 2021

To make an action out of this issue: would changing our tutorials to create a .OpenFOAM instead of a .foam resolve the issue?

The motivation for .foam was just that the stand-alone ParaView (at least old versions, I am not sure now) did not know how to read .OpenFOAM files. But in any case, the user can select the default .foam reader even for the .OpenFOAM files.

@davidscn
Copy link
Member Author

AFAIK the stand-alone paraView still does not render the .OpenFOAM files (they don't show even up if you try to open them up). Of course, it would resolve the issue assuming that everybody has the OpenFOAM plugins installed, but I guess that's for many users not the case.

@MakisH
Copy link
Member

MakisH commented Jul 28, 2021

I understand that if there is something we can do, then this should be done in the tutorials scripts/documentation. Therefore, I am transfering the issue.

@MakisH MakisH transferred this issue from precice/openfoam-adapter Jul 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants