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
I should mention that the slices have the same fields as the sim.foam:
- solid color
here is a screen capture of the setup I mentioned in the case for better understanding:
any guidence would be appreciated
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:
- solid color
Looks like you found the problem, could you share the data so I could reproduce and an issue could be logged ?
yes of course!
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.
Ok, by unchecking the “Skip Zero Time” I’m able to get the data and run the stream tracer on it.
I’m able to make it work on timestep zero, by extracting only the internal mesh in that case:
Maybe there is an issue in the way the OpenFOAM reader process the data, but I dont see any issue in the stream tracer.
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:
Is that the bug you are reffering to ?
what I meant is that:
- 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.
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!
It should not be too hard to implement, do not hesitate to contribute if you can