There's no way that libmesh-users will pass the 10+MB attachment that Marro Massimo just tried to send... I'll host it at http://users.ices.utexas.edu/~roystgnr/TEST1.tar.gz for anyone else who also wants to take a look, and copy the message text below:
On Fri, 13 Nov 2009, MARRO MASSIMO wrote: > Dear Mr Stogner, > > thank you for your availability. > > We write you this e-mail as regards our discussion on the libmesh forum. > > We did not use Exodus format because the ExodusII_IO Class > has not a function for reading the equation_systems. > > We tested both libmesh-0.6.3-rc1 and libmesh-0.6.4 and we > found the same incorrect beahviour in writing/reading the > mesh and the solution. > The configure options are the following > > ./configure > --prefix=/home/marro/LIB_NUMERIC/LIBMESH/libmesh-0.6.4/libmesh > --enable-shared --enable-amr --enable-pfem --enable-ifem > --enable-second --enable-reference-counting > --enable-perflog --enable-xdr --enable-netcdf > --enable-exodus --enable-mpi --enable-petsc > --enable-laspack=no --enable-sfc --enable-gzstreams > --enable-tecplot=no --enable-metis --enable-parmetis > --enable-tetgen --enable-triangle > --with-mpi=$PETSC_DIR/externalpackages/mpich2-1.0.5p4/$PETSC_ARCH > CFLAGS="-fPIC" CXXFLAGS="-Wno-long-long" > LDFLAGS=-L$PETSC_DIR/externalpackages/mpich2-1.0.5p4/$PETSC_ARCH/lib > CXX=g++ > > We attach a short test case. > Our system has three variables and the code uses Lagrange quadratic elements > for > u and v, and linear elements for p. > It generates a square mesh and assigns to each variable > (u,v,p) the sum (x+y): u[i] = x[i] + y[i] (for the > variables u and v we consider all the nodes (vertices + > middle points), whereas for p we use only the vertices). > The .xda file are written in the directory NEW_SOLUTION, > whereas they are read in OLD_SOLUTION. > The .gmv files are written in GMV_RESULTS. > > The program is designed to be run as follows: > > $ ./WRITE_READ-opt P.in if we start > from an uniform square mesh with 200 elements. > $ ./WRITE_READ-opt P.in -read_solution if we start > from a previously adapted mesh and computed solution. > > If we restart the simulation from meshes obtained after > few adaptations, the writing/reading operations are > correct, but if the mesh adaptations are more than a > certain number (in this case > 10), there are differences > between the computed and the written/read solution. > > For example in this case u and v should have the same > values. > If we compare the computed values to the written/read > values using GMV, we observe that u seems to preserve the > right values, whereas v is clearly wrong. The variable p > is wrong too. > > We attach also the .gmv files for the computed > (out_comp.gmv) and written/read solution (out_read.gmv) > > Best regards, > Massimo and Stefano > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
