soliwho.blogg.se - Interpolate between two cells paraview

#INTERPOLATE BETWEEN TWO CELLS PARAVIEW HOW TO#
#INTERPOLATE BETWEEN TWO CELLS PARAVIEW UPDATE#
#INTERPOLATE BETWEEN TWO CELLS PARAVIEW PATCH#

all other producers and consumers of Patch objects remain unchanged.

output higher order polynomials with no changes anywhere other than in the VTU/VTK writers.

Namely, rather than trying to output each patch with subdivision as multiple output-cells, output it only as a single cell and interpret the subdivided data as point evaluations of a higher order polynomial. What I would suggest is to add a flag to the VtkFlags structure that instructs the VTK/VTU writers to interpret patches with subdivision differently. Keeping the Patch data structure as is is therefore a useful approach.

#INTERPOLATE BETWEEN TWO CELLS PARAVIEW HOW TO#

Currently, the writers interpret this as the user wanting the output to be created in a way where the patch is split up into what I'll call "output-cells" (as opposed to "source-cells").Īll current producers of these Patch objects know how to create patches, and all current consumers (namely, output writers) of these Patch objects know how to interpret them. I gave this some thought, and I think the least intrusive way would be this: Right now, even if you have called DataOut::build_patches(n) with n>1, all of the output from one cell ends up in one Patch object. (I would be pleasantly surprised if they support isoparametric elements we may still have to build patches to fake that). Chances are paraview has not yet learned how to plot FE_RaviartThomas. As pointed out we might need to add an additional inter-finite element interpolation step.

#INTERPOLATE BETWEEN TWO CELLS PARAVIEW UPDATE#

Fortunately, since all data is placed in a dynamically allocated object (a Table), we can probably just reuse most of the existing infrastructure by encoding some scheme for putting higher-order interpolants (i.e., with our standard FE_Q ordering) in that object, but we will still have to update our entire output pipeline to understand the new patch data format. The Patch (see deal.II/base/data_out_base.h circa line 240) data structure assumes that everything is a nodal interpolant.Most peoples' workstations have older copies of paraview and visit (it seems like I am usually 3-4 years behind).It would be great to have this feature for our output so that these hacks are no longer needed. The workaround I use is to write the grid with GridOut and no patches and then write solutions with DataOut and lots of patches.

What you do essentially is represent a given field (scalar or vector - this does not matter) at a set of (Lagrange) points for every cell and VTK/Paraview does the rest (interpolation + rendering). I do not think it is limited to Lagrange elements. It looks like it would only work for Lagrange elements and I am not sure if there are other restrictions (curved geometry? vector-valued elements?). It is a bit of a hack, but we did it here and it works. This allows you to create a single cell mesh of order n and save it in VTU/VTK, where you will see the connectivity. To do this, one can either look at VTK's implementation or one can use Paraview -> Sources -> Unstructured Cell Types -> Lagrange Hexahedron/Quadrilateral. Since deal.II seems to write all cells individually, you only need to figure out a connectivity pattern for a single cell and then repeat it. It actually is not documented (which is not unusual for VTK). Do you know where we can find a specification for these elements in the vtu format?