From: Derek G. <fri...@gm...> - 2009-09-14 21:02:45
|
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 <gri...@ci... >>>>>> > 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 >>>>>>> Lib...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/libmesh-devel |