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 FWIW, I am using VTK 5.4 on a MacBook Pro (installed via Fink). I'm also going to try out VTK 5.2 to see if it makes any difference. Thanks! -- Boyce Derek Gaston wrote: > Usually what I do for these types of problems is just write out the node > displacement field as variables (it sounds like you're already solving > for that field anyway). Then in my visualizer of choice I just displace > the nodes using that field. In Ensight and Paraview I have to build a > vector field out of the scalar displacement fields.... then I just use > the mesh displacement capability of each visualizer to displace the > mesh. I'm sure Visit has something similar. > > Derek > > On Sep 14, 2009, at 2:44 PM, Boyce Griffith wrote: > >> OK, thanks --- I will try pulling the latest code. >> >> In the solver, everything is being done with respect to a fixed >> reference grid; however, the positions of the nodes of the mesh are >> time-dependent. So, for visualization purposes, I am cloning the mesh >> and re-setting the positions of the nodes of the cloned mesh to >> correspond to the positions of the updated mesh. (Is there a better >> way to do this?) I take it that this will require multiple files for >> multiple timesteps. >> >> Thanks! >> >> -- Boyce >> >> Derek Gaston wrote: >>> This works now... just create one ExodusII_IO object and keep calling >>> the write_timestep() method on it.... this will continue to append to >>> same exodus file. >>> Are you actually moving the mesh though?? Or are you just solving >>> for the displaced coordinates? If the mesh itself is changing >>> (either because nodes have moved or through adaptivity) then you MUST >>> start writing a new exodus file. Exodus can only store _1_ mesh per >>> file. >>> Note that in this situation you should still use the write_timestep() >>> method (even if you only call it once per file) because that will get >>> the correct timestep and time into the Exodus file which is probably >>> what Visit is looking for. If you use the normal write() method I >>> believe that timestep is always _0_ and time is always _0_ as well... >>> which will definitely screw up Visit. >>> If Visit still doesn't work... I do know that Ensight handles this >>> case beautifully (sucking in multiple Exodus files and displaying >>> them as one transient calculation)..... >>> Derek >>> On Sep 14, 2009, at 2:29 PM, Boyce Griffith wrote: >>>> Is there an easy way to modify the Exodus writer to put multiple >>>> timesteps in the same file? I am trying to visualize a >>>> time-dependent Lagrangian mesh, and it seems like VisIt (which I >>>> need to use for other parts of my code) is expecting multiple >>>> timesteps to be stored in the same file. >>>> >>>> Simply changing EX_CLOBBER to EX_NOCLOBBER in exodusII_io_helper.C >>>> doesn't seem to do the trick --- I get errors about initializing the >>>> file. >>>> >>>> Thanks, >>>> >>>> -- Boyce >>>> >>>> Derek Gaston wrote: >>>>> That's another hack that works... glad you found one ;-) >>>>> If you are looking for a free visualizer that reads Exodus and >>>>> handles Quad9... use Paraview: http://www.paraview.org >>>>> Derek >>>>> On Jul 27, 2009, at 8:03 AM, Boyce Griffith wrote: >>>>>> Hi, Derek -- >>>>>> >>>>>> Thanks for the explanation --- I hacked the Exodus II I/O to >>>>>> increment all block numbers by 1 and it seems to work. (Next >>>>>> problem is that VisIt doesn't seem to be able to handle QUAD9 >>>>>> elements, but that's a problem for another mailing list...) >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -- Boyce >>>>>> >>>>>> Derek Gaston wrote: >>>>>>> The issue is that Exodus blocks start numbering at 1 instead of >>>>>>> zero.... You can loop over the elements and set their subdomain >>>>>>> ID to one to fix that error... But unfortunately you will >>>>>>> probably run into the next problem which is that Exodus boundary >>>>>>> IDs start at 1 as well... >>>>>>> The real fix is not to use the internal mesh generation of >>>>>>> libmesh... And instead read an exodus mesh in (which will have >>>>>>> boundary ids and block ids starting at 1). >>>>>>> I have a hacked up version of libmesh's mesh generators that >>>>>>> forces them to start at 1 for numbering... But its just that: a >>>>>>> hack. It won't be commited. What I have on my list to do is to >>>>>>> turn ids of 0 to MAX_ID when output... That way the examples will >>>>>>> work. If I get a minute I'll try to do that today. >>>>>>> Sorry about the trouble. >>>>>>> Derek >>>>>>> Sent from my iPhone >>>>>>> On Jul 27, 2009, at 5:37 AM, Boyce Griffith >>>>>>> <[email protected]> wrote: >>>>>>>> Hi, Folks -- >>>>>>>> >>>>>>>> I am trying to get libMesh to output to an Exodus II file. I am >>>>>>>> using a >>>>>>>> recent pull of the SVN version of libMesh so that I can use >>>>>>>> libMesh with >>>>>>>> PETSc 3.0.0. >>>>>>>> >>>>>>>> (By the way, I don't really care whether it is Exodus II or not >>>>>>>> --- I am >>>>>>>> just trying to output data in a format which can be read by the >>>>>>>> VisIt >>>>>>>> visualization tool.) >>>>>>>> >>>>>>>> I tried modifying ex3.C to change the I/O from GMV to ExodusII, >>>>>>>> i.e., I >>>>>>>> simply changed the I/O from: >>>>>>>> >>>>>>>> // After solving the system write the solution >>>>>>>> // to a GMV-formatted plot file. >>>>>>>> GMVIO (mesh).write_equation_systems ("out.gmv", equation_systems); >>>>>>>> >>>>>>>> to: >>>>>>>> >>>>>>>> // After solving the system write the solution >>>>>>>> // to a Exodus II-formatted plot file. >>>>>>>> ExodusII_IO (mesh).write("out.exd"); >>>>>>>> >>>>>>>> This compiles fine but I get the following error at run time: >>>>>>>> >>>>>>>> [ex_put_block] Error: element block id 0 already exists in file >>>>>>>> id 13 >>>>>>>> exerrval = -1 >>>>>>>> Error writing element block. >>>>>>>> [0] src/mesh/exodusII_io_helper.C, line 118, compiled Jul 27 >>>>>>>> 2009 at >>>>>>>> 12:09:26 >>>>>>>> terminate called after throwing an instance of >>>>>>>> 'libMesh::LogicError' >>>>>>>> what(): Error in libMesh internal logic >>>>>>>> [griffith-macbook-pro:62440] *** Process received signal *** >>>>>>>> [griffith-macbook-pro:62440] Signal: Abort trap (6) >>>>>>>> [griffith-macbook-pro:62440] Signal code: (0) >>>>>>>> [griffith-macbook-pro:62440] [ 0] 2 libSystem.B.dylib >>>>>>>> 0x912762bb _sigtramp + 43 >>>>>>>> [griffith-macbook-pro:62440] [ 1] 3 ??? >>>>>>>> 0xffffffff 0x0 + 4294967295 >>>>>>>> [griffith-macbook-pro:62440] [ 2] 4 libSystem.B.dylib >>>>>>>> 0x912ea23a raise + 26 >>>>>>>> [griffith-macbook-pro:62440] [ 3] 5 libSystem.B.dylib >>>>>>>> 0x912f6679 abort + 73 >>>>>>>> [griffith-macbook-pro:62440] [ 4] 6 libstdc++.6.dylib >>>>>>>> 0x035b26ef _ZN9__gnu_cxx27__verbose_terminate_handlerEv + 335 >>>>>>>> [griffith-macbook-pro:62440] [ 5] 7 libstdc++.6.dylib >>>>>>>> 0x035b02a9 _ZSt14set_unexpectedPFvvE + 41 >>>>>>>> [griffith-macbook-pro:62440] [ 6] 8 libstdc++.6.dylib >>>>>>>> 0x035b02ec _ZSt9terminatev + 28 >>>>>>>> [griffith-macbook-pro:62440] [ 7] 9 libstdc++.6.dylib >>>>>>>> 0x035b03eb __cxa_throw + 107 >>>>>>>> [griffith-macbook-pro:62440] [ 8] 10 libmesh.dylib >>>>>>>> 0x0204bb03 _ZN18ExodusII_IO_Helper9check_errEiSs + 693 >>>>>>>> [griffith-macbook-pro:62440] [ 9] 11 libmesh.dylib >>>>>>>> 0x02050b76 _ZN18ExodusII_IO_Helper14write_elementsERK8MeshBase + >>>>>>>> 786 >>>>>>>> [griffith-macbook-pro:62440] [10] 12 libmesh.dylib >>>>>>>> 0x02048021 _ZN11ExodusII_IO5writeERKSs + 953 >>>>>>>> [griffith-macbook-pro:62440] [11] 13 ex3-dbg >>>>>>>> 0x00002e06 main + 1353 >>>>>>>> [griffith-macbook-pro:62440] [12] 14 ex3-dbg >>>>>>>> 0x0000275e start + 54 >>>>>>>> [griffith-macbook-pro:62440] *** End of error message *** >>>>>>>> >>>>>>>> I get similar errors if I try to do similar things in ex4. >>>>>>>> >>>>>>>> What do I need to do to output to this format? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -- Boyce >>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Libmesh-devel mailing list >>>>>>>> [email protected] >>>>>>>> https://lists.sourceforge.net/lists/listinfo/libmesh-devel > ------------------------------------------------------------------------------ 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
