On Mon, 21 Feb 2011, Roman Vetter wrote: >> EquationSystems::allgather() is actually a second step up in >> sophistication from where VTK output is - it gathers geometry data and >> degree of freedom numbering in the case of a distributed mesh. The >> gathering (and sadly, the decimation of higher-order solutions) of >> vector data happens in EquationSystems::build_vector(); > > Oh, I see. Well, it would certainly be preferable to have also the > higher order components written. From that point of view, I might be > better for me not to use the existing procedure from ExodusII, but > address the VTK output independently. I'll look into this soon.
Does VTK have native support for higher-order data? If so, adding that to our VTKIO output would be fantastic. If not, then it ought to be possible to implement a more general solution. "Subdivide an order-p element into p^d order-1 elements" is a pretty file-format-independent task, even if we limited the initial testing to VTKIO. > In the meantime, below is a patch that fixes two rather serious bugs > in VTK output (unrelated to parallelism), and removes annoying > debugging output leftovers from the original contributor. > > The first bug fixed is this one: > http://sourceforge.net/tracker/?func=detail&aid=3140652&group_id=71130&atid=530254 > The second one was that the values ranges were printed only in single > precision instead of double, which causes trouble in third-party VTK > readers such as in Paraview. Patch didn't apply cleanly for me (submit as an attachment next time? my email system must have mangled the whitespace or something) but it looks simple enough to apply by hand. I'll separate the bug fixes and the de-verbosifying into two separater commits and put them both in SVN now. --- Roy ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
