On Thu, Jan 12, 2012 at 10:13:03AM +0100, Robert wrote: > 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
The missing link is [1] http://gid.cimne.upc.es/ ------------------------------------------------------------------------------ RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
