OK; I'll give something like that a try. Incidentally, I just tried updating the Exodus writer, but it looks like the code in the SVN repository hasn't changed for a while and, in particular, write_timestep() still appears to clobber files. Am I looking in the wrong place?
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
