From: Robert <libmesh@ro...>  20120112 09:13:17

Hi, On Wed, Jan 11, 2012 at 02:10:30PM 0600, Roy Stogner wrote: > On Tue, 10 Jan 2012, Robert wrote: > > I have just tested this with the default configure options. Any > > suggestions for improvements are of course welcome. > > Would you try running it in parallel? The serial results look > sensible in my eyeball norm, but with 'mpirun np 6' (with SerialMesh) > I seem to get mesh tangling before the first time step is even begun. I just checked this, the calculation runs fine, although it hits an assertion in fem_system.h:346 when running in parallel. It would fail with a "negative jacobian/deformation gradient"error if there are any serious problems. The problem here is the output. If you are using paraview try attaching a "Calculator" filter to the reader, input "x*iHat+y*jHat+z*kHat" and check the "Coordinate Result" box. This uses the x,y,z solution variables instead of the provided node coordinations and the result should look fine again. The VTKIO just uses one processor for writing the node coordinates, so the output just contains the coordinates of this first processor and zeros all other values. This behaviour was the reason for my earlier patch for VTKIO to write in parallel. But maybe using the node coordinates (and marking it as mesh_vars) as primary variables is not the way to go anyway as it causes trouble with the periodic boundaries also. Just another thought: It would be nice to have a own FEType for storing values at quadrature points instead of abusing the MONOMIALs for this. This would allow a correct method for projecting the values from quadrature points to the nodes. Additionally it would allow output filters for formats which support this to write solutions on gausspoints to the files (There is an output filter for GiD[1] on my disk which looks at the variable name to identify variables with gauss point data). The cauchy stress, which is computed at gauss points in a postprocessing routine, is usually the most important result of a calculation involving solids. And finally I found a small error in my patch: libmesh/examples/fem_system/solid_ex2> diff r Makefile Makefile.p1 33c33 < target := ./solid_ex2$(METHOD)  > target := ./solid_ex1$(METHOD) Robert 