Hello,
this might sound as a dumb question, but the situation is the following,
i do simulations in parallel in openfoam, and one of my issues is that when i load the internal mesh data and add transparency to the view, i can see the internal boundaries of the processors. for this reason I beging by using CleantoGrid filter over the openfoam reader. on the other side, sometimes i use the patches that I load on the foam reader, such as for example, inlet. the thing is that obviously after CleantoGrid filter i ‘loss’ the information of the inlet patch, eg., i can not use extract block on CleantoGrid to get the ‘inlet’ boundary.
the only solution i can see right now is to: load the patch, use extractBlock and CleantoGrid on the foam reader, and then use group datasets filter and continue from it with the rest of the paraview script. (this way i can use extractBlock and the display will not show the interface of the processors). i might be overthinking something in the middle, if thats the case, is there a ‘cleanner’ way to get; a source, that has the internalMesh and the boundaries separated AND that if it is in parallel and with opacity!=1 will not show the processors interfaces?
thanks in advance
EDIT: sorry, i see that if I do in the gui of paraview i can still extract the inlet on the CleantoGrid output, so i might be missing something (as i am doing it in python)
my code looks like this:
#open the foam case
simfoam = OpenFOAMReader(registrationName='sim.foam', FileName=casePath, CaseType=CaseType)
simfoam.SkipZeroTime = 0
simfoam.Createcelltopointfiltereddata = 1
#merge the processor boundaries
if simfoam.CaseType=='Decomposed Case':
nProc=len(glob.glob(casePath+'/processor*'))
filterForData = CleantoGrid(registrationName='filterWithoutProcBoundaries', Input=simfoam)
else:
filterForData=simfoam
#load the inlet patch
simfoam.Set(
MeshRegions=['internalMesh', 'patch/inlet'])
#extract the inlet patch
inlet0 = ExtractBlock(registrationName='ExtractBlock_inlet', Input=filterForData,
Selectors = [
'/Root/boundary/inlet'
]
)
when doing this in pvbatch i get an error, when I do this in the GUI it works, so maybe i am missing something that the trace tool does not show?
it is not the extractBlock that gives me issues it is the surfaceNormals0 that gives me actually.
if I run this in the python console of paraview, paraview does not give me any error (in principle) but when i hit the eye of the surfaceNormals0 it crashes completly and i get this error:
critical: In unknown, line 0
critical: Cannot open data file " "" "
error: exception occurred: Segmentation fault
if i uncomment the line ##filterForData=simfoam <== line to comment inside the if ... 'Decomposed Case'
then it does everything correctly (and i can ‘show’ the surfaceNormals0 without paraview crashing.)
if i run this script in pvbatch, in the following lines after i use the normals generated by the filter in a calculator, if i leave the line commented (so i am using the CleantoGrid filter to continue the script, it will throw an error during the calculation), and if i uncomment it, it works without error (the calculator filter)
yes, in paraview gui, paraview crashes, and I get the error (in the terminal):
critical: In unknown, line 0
critical: Cannot open data file " "" "
error: exception occurred: Segmentation fault
this happends when i try to ‘show’ the surfaceNormals0 filter.
when i do in pvbatch, i dont get an error when doing the surface filter, but when i try to use the normals field generated by it in a calculator filter.
this is in 6.0.0 -RC2
hello mathieu,
open paraview GUI, in the python terminal, run script select test.py (one should run the casePath). this will create all the different filters surfaceNormals0 → show (and paraview will close)
where, if you repeat the exact same tree of filters on the GUI (instead of running the script) it will be possible to work normally with surfaceNormals0
yes, with the python script, using the gui i dont get any error until ‘show’ the last filter where paraview simply crashes. and using the pvbatch, i dont get any error until i try to use the normal field generated by the filter.
where, if you repeat the exact same tree of filters on the GUI (instead of running the script) it will be possible to work normally with surfaceNormals0
if i do exactly the same but using the GUI only (no python script) and i get exactly the same tree structure as I am getting using the script, it works without issues. thats why i mentionned
so maybe i am missing something that the trace tool does not show?
but not sure what as the two workflows (full GUI or GUI+run script) generates the same dependencies in the tree structure of the pipeline objects.
in pvpython, with the current script (i simplified) you will not get any error as one is not using the normals of the surfaceNormals0 filter.
you can add this filter at the end and pvpython will give an error:
on the other hand if you run the script on the gui (by running it from the terminal) and hit the ‘eye’ icon on the pipeline browser of the surfaceNormals0 filter, paraview at least for me, will crash.
This is caused by the fact that CleanToGrid outputs a Unstructured Grid, which is not a valid input of the SurfaceNormals filter, which results into an empty output which causes the crash (still a but to crash here).
In any case, just add an ExtractSurface before the SurfaceNormals filter to fix the issue.
