Open mortezah opened 2 years ago
This looks promising. Good find :+1: . Are there any drawbacks vs. the current approach?
@cwsmith
There is no drawback when compared to the current approach.
It makes things a lot cleaner though. For example we won't need two different outputs to load to paraview anymore, for curved meshes.
Both approaches are supposed to create large files.
@KennethEJansen mentioned in a call today that several filters (slice, contour, etc.) revert back to linear elements with some of the higher order element types. I'm not sure if the same element types were being used in both cases.
edit: @KennethEJansen also pointed out that there are bezier elements listed here: https://vtk.org/doc/nightly/html/classvtkCell.html
Due to increased involvement with high-order fem codes, I guess it would be worthwhile to extend/improve high-order visualization APIs in SCOREC/Core.
At the moment we support high-order mesh visualization via the two APIs
crv::writeCurvedVtuFiles
(which creates tesselations of mesh tets or tris) andcrv::writeCurvedWireFrame
(which tesselation of mesh edges). And we don't have any simple way of visualizing high-order solution fields.According to this (https://blog.kitware.com/modeling-arbitrary-order-lagrange-finite-elements-in-the-visualization-toolkit/) Kitware blogpost, VTK now supports arbitrary order Lagrange elements.
An example ASCII VTU file with higher order elements and fields is shown below (can also be downloaded from here https://data.kitware.com/#collection/5a4560018d777f5e872f779e).
Loading that file into Paraview (version 5.8.x) produces the following pictures