On 8/5/10 8:02 PM, Roy Stogner wrote:
>
>
> On Tue, 3 Aug 2010, rochan wrote:
>
>> I have been trying to move to the direction of vtk + Paraview. Libmesh
>> says that the vtk io is 'is untested, experimental, or likely to see future
>> API changes'. Anyway there seem to be some issues.
>
> Some major issues, it looks like.  Comments in vtk_io.C include
> "single processor implementation" and "now this is known to write
> nonsense on AMR meshes".  I'm still happy Wout started this class;
> serial unrefined grids are better than nothing at all and at least the
> parallelism problem will be easy to fix when someone has time.  For
> now I don't have time to fix VTKIO for general cases, but I'll at
> least rephrase those comments in "libmesh_assert()" form where they'll
> be a little more helpful at runtime in the future.
>
> And it looks like we need something better than this to replace GMV as
> our default visualization format.  Ben uses Tecplot, but that's out
> since it's commercial.  Derek uses ExodusII, which Paraview also
> reads... but IIRC that currently doesn't work with hybrid meshes.  I
> guess it could be usable for now if you stick to one element type per
> mesh.  And we have figured out a design to get around the "only one
> element type per block" limitation in the ExodusII format, so
> implementing hybrid mesh support could be done in the short term if we
> do need it.

FWIW, support for ExodusII seems to be improved in VisIt 2.0, so if you 
all decide to move towards making ExodusII the default format, there are 
a few freely available viz software options.

-- Boyce

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Reply via email to