I use ParaView to read OpenFOAM cases with ParaView’s native reader.
I’m facing an issue regarding decomposed multi-region cases.
When I load my case, I select Case Type: Decomposed Case, the reader loads the internal meshes of all the regions it finds and it works just fine.
But if I uncheck some regions (for instance to work only with one region), the internalMesh fails to load : I only get parts of the mesh like if it failed to load some processors subdomains. (I use the same number of subdomains in every region)
I get this error from Paraview:
vtkMultiBlockDataSet (000000000DF127D0): Structure does not match. You must use CopyStructure before calling this method.
I also tried to load the whole case (3 regions) in paraView and then use the Extract Block filter in to extract only the region I want to work with but it doesn’t work and this is what I get:
It looks to me like the reader mixes up data from different regions (3 regions) and subdomains (in this example, each region is decomposed in 12 subdomains)
This is a tutorial case from openFOAM-v1806 and I’m having this issue with ParaView-5.6.0 as well as older versions (tried it on 5.5.2, 5.0.1 and 4.1.0)
The quick answer, but probably also the disappointing one: it is probably something that needs much more attention. In my case, I don’t get anything beyond error messages (for the decomposed case). Even if I disable the internalMesh, the error message appears that it cannot open “processor0/constant/polyMesh/faces.gz”
So it looks as if it is trying to load up the defaultRegion, which does not exist in this case - we only have regions (as per constant/regionProperties).
How large are your cases? Maybe there is another way to solve this sooner (waiting for someone to have time and funding to fix the reader is probably not going to happen very quickly).
Even if you could use the reader module provided with OpenFOAM (which does handle regions), you probably wouldn’t want to either since it requires reconstructed data, which doesn’t put you further ahead.
Your error message is due to the directory constant/polyMesh.
The region meshes are located in processorX/regionY/constant/polyMesh.
For some reason, if there is a constant/polyMesh directory (which happens everytime we run blockMesh to create a background mesh before decomposing and meshing in parallel), the reader looks for the equivalent directory in processors directories.
So it searches for processorX/constant/polyMesh and doesn’t look for processorX/regionY/constant/polyMesh.
Deleting the constant/polyMesh directory should solve the problem and get you to the issue I’m having.
EDIT:
I can’t use the reader module from OpenFOAM because I don’t have OpenFOAM on my desktop, the cases are computed on a remote cluster.
Since my cases are quite large, reconstruction is not really an option.
remove (rename) constant/polyMesh for the serial case
load the decomposed case
select all regions
extract block to extract one or more regions (eg, heater, or topAir etc).
All looks good for me (multiRegionHeaterRadiation tutorial)
I’m using paraview-5.6.0 on linux (leap 15) built from source with mpi and python, in case that makes a difference.
To be especially nasty, I now also tried with the chtMultiRegionFoam/multiRegionHeater tutorial. As expected I get a number of warnings about missing meshes, which makes sense since the case has been decomposed only have heater cells on one of processors and all others don’t have a mesh. But even this looks OK.
Based on a fresh multiRegionHeaterRadiation case and following the exact same steps you described in your last post, here is what I get:
On my desktop (windows 7), I still get the same issue I described in my first post with ParaView 5.5.2 and 5.6.0
Same thing with 2 other computers running windows 7, with a wide range of ParaView versions
On my old laptop (ubuntu 14.04), everything works fine with paraView 4.0.1 and 5.6.0 (both extract block or just selecting one internalMesh are working)
It seems there is something wrong with windows, unless this is something specific to our setup. (nothing fancy though, except maybe 7 not being up to date)
I will give a try to windows 10 as soon as I can get a machine running it.
I have been digging a bit more into this and there are really weird things going on.
Let’s sum it up:
Data are written on a FreeNAS data server
Cluster runs openFOAM-v1806 on openSUSE 13.1 and write data on the server through a NFS share
My desktop computer runs windows 7 and use a CIFS share to access the data server
Now, here is what happens:
When I load a case hosted on the data server in ParaView on my desktop, I have the issue I was talking about in the first post.
If I copy/paste the case from the data server to my desktop hard drive, and load it from here on ParaView, it works fine.
If I copy/paste the case from the data server to an NTFS usb stick on my desktop, and load the case from the usb stick it works fine
If I do the same thing on a FAT32 usb stick, I have the same issue as the first post.
On my laptop running ubuntu 14.04, it works fine from the local hard drive and NTFS usb stick, but not from the FAT32 stick.
Another weird thing on the multiRegionHeaterRadiation : in the “Mesh Regions” list in paraView, regions are usually listed in alphabetical order. When I open the case from the data server or FAT32 usb stick, the “topAir” region is the first in the list, while this is usually the bottomAir region.
Are you aware of some limitations related to file-systems?
I have this issue only with decomposed multiregion cases. Decomposed single region cases or reconstructed multiregion are OK.
Getting back to you about this. Do you know what can cause this issue and if there is a workaround?
@mwestphal: I don’t know if it is very helpful since the problem doesn’t seem to be related to the dataset itself but I’ve uploaded one. It’s just a regular tutorial case. I load the case through a dummy “case.foam” file. This dataset is perfectly read by paraview when it’s written on a NTFS or ext4 file system but it fails when written on a FAT32 or ZFS file systems as described in my previous post.
(Or at least it seems to be what is happening but maybe I am wrong about that)
