On Mon, Sep 14, 2009 at 7:20 PM, Boyce Griffith <[email protected]> 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, na...@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 ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
