Re: [Libmesh-users] [Libmesh-devel] Exodus II visualization

[John P. <pet...@cf...>]

On Mon, Sep 14, 2009 at 7:20 PM, Boyce Griffith <gri...@ci...> wrote:
> Hi, Derek et al. --
>
> Unfortunately, according to one of the VisIt developers, what I was
> trying to do (store one Exodus file per timestep) is not currently
> possible.  So now I'm trying to use the VTK file writer in libMesh
> instead of the ExodusII file writer.
>
> I realize that the VTK file writer doesn't have the same level of
> support as the Exodus writer; however, I run into an odd memory error
> when trying to use the VTK writer, and I hoped someone on the list might
> have some suggestions:
>
> I am doing "VTKIO(mesh).write(filename)" and get the following:
>
> *** Warning, This code is untested, experimental, or likely to see
> future API changes: /Users/griffith/sfw/libmesh/include/mesh/vtk_io.h,
> line 150, compiled Sep 14 2009 at 20:03:31 ***
> write nodes
> write elements
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x00000006
> 0x91175f75 in std::ostream::flush ()
> (gdb) where
> #0  0x91175f75 in std::ostream::flush ()
> #1  0x9117602c in std::ostream::sentry::sentry ()
> #2  0x9117714c in std::operator<< <std::char_traits<char> > ()
> #3  0x031c34cc in vtkXMLWriter::StartFile ()
> #4  0x031bbb6b in vtkXMLUnstructuredDataWriter::ProcessRequest ()
> #5  0x037d0823 in vtkExecutive::CallAlgorithm ()
> #6  0x037c6a1a in vtkDemandDrivenPipeline::ExecuteData ()
> #7  0x037c927b in vtkDemandDrivenPipeline::ProcessRequest ()
> #8  0x03914fa0 in vtkStreamingDemandDrivenPipeline::ProcessRequest ()
> #9  0x037c6835 in vtkDemandDrivenPipeline::UpdateData ()
> #10 0x03915635 in vtkStreamingDemandDrivenPipeline::Update ()
> #11 0x037cf1ec in vtkExecutive::Update ()
> #12 0x037c61b1 in vtkDemandDrivenPipeline::Update ()
> #13 0x0391509d in vtkStreamingDemandDrivenPipeline::Update ()
> #14 0x03760d1b in vtkAlgorithm::Update ()
> #15 0x031c2d4b in vtkXMLWriter::Write ()
> #16 0x0149491e in VTKIO::write (this=0xbfffd960, name=@0xbfffd95c) at
> src/mesh/v
> tk_io.C:646
> #17 0x0010c555 in IBAMR::IBFEHierarchyIntegrator::advanceHierarchy
> (this=0x482d0
> 00, dt=0.00390625) at IBFEHierarchyIntegrator.C:663
> #18 0x00006a9b in main (argc=4, argv=0xbfffe15c) at main.C:423

It's likely you've just uncovered a bug in Libmesh's VTKIO class... it
was contributed by Wout Ruijter, but isn't used by any of the main
libmesh developers as far as I know.  Looks like you have a reasonable
place to start tracing back the problem, but if you need more help and
can create a minimal test case which exhibits the behavior, we'll have
a closer look at it.

-- 
John