hello,
I am having an issue with a workflow that I am used to do in my cases.
info about my case:
it is a OpenFOAM case (so .foam paraview reader)
paraview vr 5.11.1
in time step 0 the case has the U, p fields and lagrangean particles
in rest of time steps the U and p fields disappear as the time steps are due to the lagrangean particles and I froze the fields (with same values as 0) so OF does not write them
the case is decomposed and loaded without the skip zero time
for my workflow:
I load the case with the internalMesh and the inlet patch and apply it, and go to time 0 (sim.foam)
I use extract block filter to extract inlet
I use slice filter with multiple slices to cut in multiple lines the inlet in the extract block filter
I re use a slice filter with multiple slices over the previous one to create a regular grid of points
I use the streamTracerWithCustomSource over the case (sim.foam) and select seed source option, and select the second slice filter
use tube filter over the streamTracerWithCustomSource filter (this is outside of the error itself that comes from previous step)
hit apply
this commonly worked without any error, nevertheless I am getting ābad velocity arrayā, more specific:
ERROR: In vtkStreamTracer.cxx, line 1673
vtkStreamTracer (000001F44A386160): Bad velocity array.
the streamlines are created, nevertheless, I can not colorate them with U or p in the fields selection the only options I have are
solid color
angularVelocity
integrationTime
rotation
vorticity
vtkCompositeIndex
reasonsForTermination
seedlids
vtkCompositeIndex
vtkBlockColors
I should mention that the slices have the same fields as the sim.foam:
solid color
U
epsilon
k
nut
p
vtkCompositeIndex
U
epsilon
k
nut
p
vtkCompositeIndex
vtkBlockColors
here is a screen capture of the setup I mentioned in the case for better understanding:
any guidence would be appreciated
best regards, ========================================================================== EDIT: I finally found where the error was coming from, (and I think it is a bug of paraview). The error mentioned in this post only āhappensā when the lagrangean particles are loaded if they are not loaded the error is not generated and the stream line fields are as always:
hello Mathieu,
yes of course! linkForDownload https://filesender.renater.fr/?s=download&token=9a9600f1-0831-40f5-9108-2415bfa4ddd9
here is the case with the folder 0 and 0.0001 timesteps.
even simply by loading and using the classic stream tracer (without custom source) paraview has this issue. so to test, simply load the case in decomposed, with include zero and use the stream tracer in 0.the error it gives when opened (not the on discussing here) is because I deleted files in the serial mode to clean the case and that it weights a little less.
best regards, and hope that this helps the to debug the issueā¦
The OpenFOAM reader lagrangian data is only generated on the lagrangian point cloude and not on the internal mesh. It looks like either an OpenFOAM limitation or OpenFOAM reader limitation but maybe @olesenm has some inputs.
The streamtracer indeed cannot work only on the lagragian point cloud and needs a velocity array on the volume.
Hello @mwestphal ,
I think that we didnt understood correctly . In the folder 0, OF has the p scalar field and U vector field (in the volume), and if we stay in the folder 0 the stream tracer should work correctly, but as paraview detects lagrangian particles in the folder 0.0001 (I can not remember de timestep) the filter breaks and does not work in folder 0 where U and p exists. if you remove the time step 0.0001, and use the same data, the filter will work correctly. I understand that the stream tracer would not work in the time step 0.0001 as you mentioned it will be missing the necessary fields but at 0, it should work.
yes thats what I meant, but if you load also the particles to use on another filters streamtracer breaks it, (I know you can work around using extract block =>internal mesh.)
Indeed, if a block does not contain the velicity array, the stream tracer outputs an error, however it still generate the streamlines, although it seems to be missing some data in that case:
if I load the internalMesh alone the stramLines filter works as intended.
if I load the 2 regions ie., internalMesh and lagrangian/cellCloud and I use the streamLines filter, it gets the line but it is not able to be colored from U (or p also I think) fields. eventought, the sim.foam has this fields also paraviews presents an error that I mentioned previously.
I find at least strange the behavior and ābuggyā (but maybe it is not) that this happens as the information (U and p fields) in the 2. is still there.
In that case, the data is āpartialā and the streamtracer is removing it as you cannot have a partial output on a non composite output like the streamlines.
The streamtracer could ignore completely the block without the data so I suppose an improvement of the streamtracer for this usecase could be done.
thanks mathieu,
I know it might be āsimpleā thing that can be solved with an extract block filter, but nevertheless I do this workflow all the time and when I got that error that is not clear where is coming the issue, I didnāt thought that, that was the problem (the loading of it, specially as this is not an issue if we load for example patches). so even if not quite functional could be a good improvement
thanks for your time in any case!
best regards
. In the folder 0, OF has the p scalar field and U vector field (in the volume), and if we stay in the folder 0 the stream tracer should work correctly, but as paraview detects lagrangian particles in the folder 0.0001 (I can not remember de timestep) the filter breaks and does not work in folder 0 where U and p exists. if you remove the time step 0.0001, and use the same data, the filter will work correctly. I understand that the stream tracer would not work in the time step 0.0001 as you mentioned it will be missing the necessary fields but at 0, it should work.
