Re: [Libmesh-devel] VTK output fails in parallel

[Derek G. <fri...@gm...>]

Sorry I haven't been more active in this conversation... I was on vacation all of last week.  I've sprinkled my thoughts below....

On Feb 23, 2011, at 7:51 AM, Roy Stogner wrote:

> 
> On Wed, 23 Feb 2011, Roman Vetter wrote:
> 
>> I suppose it's a matter of opinion/objective. Do the libMesh
>> developers/users want their solution output either
>> 
>> a) complete, including higher order terms, in a way that complies with
>> the VTK file format, but not necessarily perfectly visualizable in,
>> say, Paraview without further ado in all cases
> 
> At least for me this isn't useful until/unless there's *some* 3rd
> party support for reading/understanding the higher-order solution
> terms, and it's actually counterproductive if it makes it less likely
> for a reader to render the low-order decimated solution properly.
> 
> I'm not sure how it would be useful for others.  As a first step
> toward eventually having another option for restart files, I assume?
> Right now (IIRC, Derek please correct me if I'm wrong) we only support
> higher order restarts via our own xda/xdr based format, with a few
> more low order solution options.
> 
> I'd like to hear more opinions, if anyone wants to chime in.  I think
> Ben's busy with NASA stuff and John's busy moving across the country,
> though...


Agree with Roy.  If there is any chance that a user will use Hermites (or any higher order shape functions) and the _default_ result file won't load in Paraview.... that is a FULL STOP.  If you want to have an option on the VTK_IO writer to write the extra dofs out.... that's fine with me.  But the default should always be compatible with 3rd party viz tools.

This is actually a timely discussion for us because we are having trouble visualizing our higher order solutions.  We have actually added capability to our code to project higher order solutions onto arbitrarily refined meshes for output.... so that we can actually get a better idea of what the true solution looks like.  If _anyone_ knows of a 3rd party viz tool that will visualize higher order solutions.... I would REALLY love to hear about it.

The alternative to doing what I just said (projecting to refined meshes) is doing what Roy mentioned a few emails ago: refining _when_ you output.  That can be achieved but seemed like a lot more work than just doing a mesh to mesh projection and then using our normal IO code to write the solution out.  I wouldn't mind some other opinions here though.

As for restart... Roy you are right.  We can only _restart_ from xda/xdr in the case of higher order shape functions.  We can read "nodal values" out of both Exodus and GMV I believe.  But you will obviously not have any of the higher order coefficients.

To sum up:
1. Default behavior must work with 3rd party tools
2. If there is a tool that can visualize higher order data.... I want to know about it!
3. There are other alternatives for dealing with higher order data like projecting to finer grids.

BTW.... I'm attaching two images of a Cahn-Hilliard solution run with 3rd order hermites.... the first is on the original grid.... the second is the same solution... but projected to a finer grid before being written out.  There is no doubt that by visualizing the decimated solution on the original grid we're missing a TON of info!  (I believe this visualization was done with Paraview.... but I don't know for sure)

Derek