libmesh-users Mailing List for libMesh: A C++ Finite Element Library (Page 481)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi,

some days ago I forward a mail from the debian mantainer of the petsc package.
Have you looked it? There are some news about it?

Best regards,

Leo

Luca Antiga writes:
 > Hi guys,
 > Are there any
 > limitations in the design of libMesh that would make it impractical to
 > build hp elements on the existing framework?

There shouldn't be.  libMesh was designed to (someday) be capable of
the h-p version of finite elements.  The theoretical issues of h-p, e.g.
what error indicators are appropriate, how to implement anisotropic
h refinement, etc. are still research topics however.  I think Ben has
some plans in mind on how he would implement p refinement, which he might
post to the mailing list as well.

-John

Hi guys,
 congratulations for the great job you're doing.
I need to implement hp elements on unstructured grids. Are there any
limitations in the design of libMesh that would make it impractical to
build hp elements on the existing framework?
 Thank you in advance

Luca

Dear Ben,
thank you very much for your fast help!

I am evaluating libmesh for a CFD research project using a Finite Volume 
formulation.
I have found some problems with the library which I have solved, and which may 
be of interest for  other users:
- writing element data in the solution file (in GMV format): it is not to 
difficult, even in //e

-a bug in the distributed vector  init function
here is the patch for the file distributed_vector.h
440a441
>   // BUG MPI ?
441a443
>   std::vector<int> local_sizes_send(n_proc, 0);
443c445
<   local_sizes[proc_id] = n_local;
---
>   local_sizes_send[proc_id] = n_local;
445c447
<   MPI_Allreduce (&local_sizes[0], &local_sizes[0], local_sizes.size(),
---
>   MPI_Allreduce (&local_sizes_send[0], &local_sizes[0], local_sizes.size(),
462c464,465
<   assert (sum == static_cast<int>(size()));
---
>   // BUG Set the initialized flag not set
>   //assert (sum == static_cast<int>(size()));

the  MPI_Allreduce needs a different buffer for the send and the receive and 
we cannot call the size() function here because the vector is not initialized 
!
- I also add a public access to the PetSC vector in the PetscVector class 
 i.e.
// acces au vecteur Petsc
  Vec & PetscVec() { return vec; }
and in the class PetscMatrix i.e.
// acces a la matricePetsc
  Mat & PetscMat() { return mat; }
in order to be able to use all the PETSC lib, specially the print function.
Indeed, in //e the print function of the numeric_vector class works only for 
the processor 0 and gives erroneous values for the other proc.

Thank you very much again

	Marc

Dear Ben,

thank you very much for your fast help!
I think, it is almost working now.
Configure now finds PETSc, which is a real progress.
Less positive is, that when I run "make run_examples" now, I get the error 
message:

Catastrophic error: could not open source file 
"/usr/local/encap/mpich124-intel/lib"

compilation aborted for /usr/local/encap/mpich124-intel/lib (code 4)

Do you have any idea, what I could do about this?
Thank you very much again and best wishes!

Patrick

On Fri, 28 Nov 2003, Benjamin S. Kirk wrote:

> It sounds like configure did not find PETSc...  Did you put those directories in the Make.common file yourself?  If so, then there are #define's in include/base/libmesh_config.h that are missing, so the PETSc code is not getting compiled.  It is best if configure finds PETSc, that way everything else should work OK.
> 
> >From your email I see that you want to use the Intel icc compiler.  In that case, the general configuration approach I would suggest is this:
> 
> export CXX=icc
> export CC=icc
> export F77=ifc
> export PETSC_DIR=/usr/local/src/petsc-2.1.5
> export PETSC_ARCH=linux_intel
> 
> ./configure
> 
> 
> The ./configure script should find PETSc.  For exampe, here is my setup:
> 
> voyager(4)$ echo $PETSC_DIR
> /usr/local/petsc/petsc-2.1.6
> voyager(5)$ echo $PETSC_ARCH
> linux
> voyager(6)$ CXX=icc CC=icc F77=ifc ./configure
> ---------------------------------------------
> ----------- Configuring libMesh -------------
> ---------------------------------------------
> checking build system type... i686-pc-linux-gnu
> checking host system type... i686-pc-linux-gnu
> checking target system type... i686-pc-linux-gnu
> checking for C++ compiler default output... a.out
> checking whether the C++ compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables...
> checking for suffix of object files... o
> checking whether we are using the GNU C++ compiler... no
> checking whether icc accepts -g... yes
> checking for gcc... icc
> checking whether we are using the GNU C compiler... no
> checking whether icc accepts -g... yes
> checking for icc option to accept ANSI C... none needed
> <<< C++ compiler is Intel ICC >>>
> checking how to run the C++ preprocessor... icc -E
> checking for egrep... grep -E
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking for short int... yes
> checking size of short int... 2
> checking for int... yes
> checking size of int... 4
> checking for long int... yes
> checking size of long int... 4
> checking for float... yes
> checking size of float... 4
> checking for double... yes
> checking size of double... 8
> checking for void *... yes
> checking size of void *... 4
> checking getopt.h usability... yes
> checking getopt.h presence... yes
> checking for getopt.h... yes
> checking whether the compiler implements namespaces... yes
> checking whether the compiler has locale... yes
> checking whether the compiler has stringstream... yes
> checking hash_map usability... yes
> checking hash_map presence... yes
> checking for hash_map... yes
> checking hash_set usability... yes
> checking hash_set presence... yes
> checking for hash_set... yes
> checking zlib.h usability... yes
> checking zlib.h presence... yes
> checking for zlib.h... yes
> <<< Configuring library with AMR support >>>
> <<< Configuring library with expensive data structures enabled >>>
> checking rpc/rpc.h usability... yes
> checking rpc/rpc.h presence... yes
> checking for rpc/rpc.h... yes
> <<< Configuring library with XDR support >>>
> <<< Configuring library with real number support >>>
> <<< Configuring library with reference counting support >>>
> checking for ./contrib/netcdf/lib/i686-pc-linux-gnu/libnetcdf.a... yes
> checking for ./contrib/netcdf/include/netcdf.h... yes
> <<< Configuring library with netCDF support >>>
> checking for ./contrib/exodus/lib/i686-pc-linux-gnu/libexoIIv2c.a... yes
> checking for ./contrib/exodus/include/exodusII.h... yes
> <<< Configuring library with Exodus API support >>>
> ---------------------------------------------
> ----- Configuring for optional packages -----
> ---------------------------------------------
> checking for ./contrib/sfcurves/sfcurves.h... yes
> <<< Configuring library with SFC support >>>
> checking for ./contrib/gzstream/gzstream.h... yes
> <<< Configuring library with gzstreams support >>>
> checking for ./contrib/tecplot/lib/i686-pc-linux-gnu/tecio.a... yes
> checking for ./contrib/tecplot/include/TECIO.h... yes
> <<< Configuring library with Tecplot API support >>>
> checking for ./contrib/laspack/lastypes.h... yes
> <<< Configuring library with LASPACK version 1.12.3 support >>>
> checking for /usr/local/petsc/petsc-2.1.6/include/petsc.h... yes
> checking whether we are using the GNU Fortran 77 compiler... no
> checking whether ifc accepts -g... yes
> checking how to get verbose linking output from ifc... -v
> checking for Fortran 77 libraries...  -L/usr/local/intel/compiler70/ia32/lib -L/usr/lib -lintrins -lIEPCF90 -lF90 -limf -lm -lirc -lcxa -lunwind
> <<< Configuring library with PETSc version 2.1.6 support >>>
> checking for ./contrib/metis/Lib/metis.h... yes
> <<< Configuring library with Metis support >>>
> checking for ./contrib/parmetis/Lib/parmetis.h... yes
> <<< Configuring library with Parmetis support >>>
> checking for doxygen... /usr/bin/doxygen
> checking for dot... /usr/local/graphviz/bin/dot
> ----------------------------------------------
> --- Done configuring for optional packages ---
> ----------------------------------------------
> checking for perl... /usr/bin/perl
> configure: creating ./config.status
> config.status: creating Make.common
> config.status: creating include/base/libmesh_config.h
> configure: creating ./config.status
> config.status: creating Make.common
> config.status: creating doc/Doxyfile
> config.status: creating include/base/libmesh_config.h
> config.status: include/base/libmesh_config.h is unchanged
> ---------------------------------------------
> --------- Done Configuring libMesh ----------
> ---------------------------------------------
> 
> Notice how PETSc was found in the "optional packages" section.
> Please let me know if you still have an issue.
> 
> -Ben
> 
> 
> 
> 
> 
> Patrick O. Lechner wrote:
> 
> > Hello Steffen,
> >
> > thank you very much for your email and your help.
> > I've done the modifications, that you mentioned, but it still doesn't work so far.
> > The output from make echo, that I get, is:
> >
> > Source Files:
> > src/base/dof_map.C src/base/dof_map_constraints.C src/base/dof_object.C src/base/equation_systems.C src/base/equation_systems_io.C src/base/frequency_system.C src/base/libmesh_base.C src/base/libmesh.C src/base/newmark_system.C src/base/node.C src/base/reference_counted_object.C src/base/reference_counter.C src/base/steady_system.C src/base/system_base.C src/base/system_base_io.C src/base/system_base_projection.C src/base/transient_system.C src/fe/fe_base.C src/fe/fe_boundary.C src/fe/fe.C src/fe/fe_hierarchic.C src/fe/fe_hierarchic_shape_1D.C src/fe/fe_hierarchic_shape_2D.C src/fe/fe_hierarchic_shape_3D.C src/fe/fe_interface.C src/fe/fe_interface_inf_fe.C src/fe/fe_lagrange.C src/fe/fe_lagrange_shape_1D.C src/fe/fe_lagrange_shape_2D.C src/fe/fe_lagrange_shape_3D.C src/fe/fe_map.C src/fe/fe_monomial.C src/fe/fe_monomial_shape_1D.C src/fe/fe_monomial_shape_2D.C src/fe/fe_monomial_shape_3D.C src/fe/inf_fe_base_radial.C src/fe/inf_fe_boundary.C src/fe/inf_fe.C src/fe/inf_fe_j!
> acobi_20_00_eval.C src/fe/inf_fe_jacobi_30_00_eval.C src/fe/inf_fe_lagrange_eval.C src/fe/inf_fe_legendre_eval.C src/fe/inf_fe_map.C src/fe/inf_fe_map_eval.C src/fe/inf_fe_static.C src/geom/cell.C src/geom/cell_hex20.C src/geom/cell_hex27.C src/geom/cell_hex8.C src/geom/cell_hex.C src/geom/cell_inf.C src/geom/cell_inf_hex16.C src/geom/cell_inf_hex18.C src/geom/cell_inf_hex8.C src/geom/cell_inf_hex.C src/geom/cell_inf_prism12.C src/geom/cell_inf_prism6.C src/geom/cell_inf_prism.C src/geom/cell_prism15.C src/geom/cell_prism18.C src/geom/cell_prism6.C src/geom/cell_prism.C src/geom/cell_pyramid5.C src/geom/cell_pyramid.C src/geom/cell_tet10.C src/geom/cell_tet4.C src/geom/cell_tet.C src/geom/edge.C src/geom/edge_edge2.C src/geom/edge_edge3.C src/geom/edge_inf_edge2.C src/geom/elem.C src/geom/elem_quality.C src/geom/elem_refinement.C src/geom/elem_type.C src/geom/face.C src/geom/face_inf_quad4.C src/geom/face_inf_quad6.C src/geom/face_inf_quad.C src/geom/face_quad4.C src/geom/fa!
> ce_quad8.C src/geom/face_quad9.C src/geom/face_quad.C src/geo!
> m/face_tri3.C src/geom/face_tri6.C src/geom/face_tri.C src/geom/plane.C src/geom/point.C src/geom/sphere.C src/geom/surface.C src/mesh/boundary_info.C src/mesh/boundary_mesh.C src/mesh/mesh_base.C src/mesh/mesh_base_modification.C src/mesh/mesh.C src/mesh/mesh_communication.C src/mesh/mesh_data.C src/mesh/mesh_data_unv_support.C src/mesh/mesh_data_xdr_support.C src/mesh/mesh_diva_support.C src/mesh/mesh_exodus_support.C src/mesh/mesh_generation.C src/mesh/mesh_gmv_support.C src/mesh/mesh_misc_support.C src/mesh/mesh_modification.C src/mesh/mesh_refinement.C src/mesh/mesh_refinement_flagging.C src/mesh/mesh_refinement_smoothing.C src/mesh/mesh_smoother.C src/mesh/mesh_smoother_laplace.C src/mesh/mesh_tecplot_support.C src/mesh/mesh_ucd_support.C src/mesh/mesh_unv_support.C src/mesh/mesh_xdr_support.C src/numerics/analytic_function.C src/numerics/coupling_matrix.C src/numerics/dense_matrix_base.C src/numerics/dense_matrix.C src/numerics/dense_submatrix.C src/numerics/dense_sub!
> vector.C src/numerics/dense_vector_base.C src/numerics/dense_vector.C src/numerics/distributed_vector.C src/numerics/error_estimator.C src/numerics/function_base.C src/numerics/laspack_interface.C src/numerics/laspack_matrix.C src/numerics/laspack_vector.C src/numerics/linear_solver_interface.C src/numerics/mesh_function.C src/numerics/numeric_vector.C src/numerics/petsc_interface.C src/numerics/petsc_matrix.C src/numerics/petsc_vector.C src/numerics/sparse_matrix.C src/numerics/type_vector.C src/partitioning/centroid_partitioner.C src/partitioning/linear_partitioner.C src/partitioning/metis_partitioner.C src/partitioning/parmetis_partitioner.C src/partitioning/partitioner.C src/partitioning/sfc_partitioner.C src/quadrature/quadrature_build.C src/quadrature/quadrature.C src/quadrature/quadrature_gauss_1D.C src/quadrature/quadrature_gauss_2D.C src/quadrature/quadrature_gauss_3D.C src/quadrature/quadrature_gauss.C src/quadrature/quadrature_jacobi_1D.C src/quadrat
> 

-- 
Patrick Lechner				Phone: 	(+44) 1225 386974
Department of Mathematical Sciences	Fax:	(+44) 1225 386343
University of Bath			Email: 	ma...@ma...
Bath BA2 7AY			
United Kingdeom

Find out more about me on the WWW: http://www.maths.bath.ac.uk/~mappol

"I have little patience for scientists who take a board of wood, look for 
its thinnest part, and drill a great number of holes when the drilling is 
easy.", Albert Einstein (1949)

It sounds like configure did not find PETSc...  Did you put those directories in the Make.common file yourself?  If so, then there are #define's in include/base/libmesh_config.h that are missing, so the PETSc code is not getting compiled.  It is best if configure finds PETSc, that way everything else should work OK.

From your email I see that you want to use the Intel icc compiler.  In that case, the general configuration approach I would suggest is this:

export CXX=icc
export CC=icc
export F77=ifc
export PETSC_DIR=/usr/local/src/petsc-2.1.5
export PETSC_ARCH=linux_intel

./configure

The ./configure script should find PETSc.  For exampe, here is my setup:

voyager(4)$ echo $PETSC_DIR
/usr/local/petsc/petsc-2.1.6
voyager(5)$ echo $PETSC_ARCH
linux
voyager(6)$ CXX=icc CC=icc F77=ifc ./configure
---------------------------------------------
----------- Configuring libMesh -------------
---------------------------------------------
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for C++ compiler default output... a.out
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... no
checking whether icc accepts -g... yes
checking for gcc... icc
checking whether we are using the GNU C compiler... no
checking whether icc accepts -g... yes
checking for icc option to accept ANSI C... none needed
<<< C++ compiler is Intel ICC >>>
checking how to run the C++ preprocessor... icc -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for short int... yes
checking size of short int... 2
checking for int... yes
checking size of int... 4
checking for long int... yes
checking size of long int... 4
checking for float... yes
checking size of float... 4
checking for double... yes
checking size of double... 8
checking for void *... yes
checking size of void *... 4
checking getopt.h usability... yes
checking getopt.h presence... yes
checking for getopt.h... yes
checking whether the compiler implements namespaces... yes
checking whether the compiler has locale... yes
checking whether the compiler has stringstream... yes
checking hash_map usability... yes
checking hash_map presence... yes
checking for hash_map... yes
checking hash_set usability... yes
checking hash_set presence... yes
checking for hash_set... yes
checking zlib.h usability... yes
checking zlib.h presence... yes
checking for zlib.h... yes
<<< Configuring library with AMR support >>>
<<< Configuring library with expensive data structures enabled >>>
checking rpc/rpc.h usability... yes
checking rpc/rpc.h presence... yes
checking for rpc/rpc.h... yes
<<< Configuring library with XDR support >>>
<<< Configuring library with real number support >>>
<<< Configuring library with reference counting support >>>
checking for ./contrib/netcdf/lib/i686-pc-linux-gnu/libnetcdf.a... yes
checking for ./contrib/netcdf/include/netcdf.h... yes
<<< Configuring library with netCDF support >>>
checking for ./contrib/exodus/lib/i686-pc-linux-gnu/libexoIIv2c.a... yes
checking for ./contrib/exodus/include/exodusII.h... yes
<<< Configuring library with Exodus API support >>>
---------------------------------------------
----- Configuring for optional packages -----
---------------------------------------------
checking for ./contrib/sfcurves/sfcurves.h... yes
<<< Configuring library with SFC support >>>
checking for ./contrib/gzstream/gzstream.h... yes
<<< Configuring library with gzstreams support >>>
checking for ./contrib/tecplot/lib/i686-pc-linux-gnu/tecio.a... yes
checking for ./contrib/tecplot/include/TECIO.h... yes
<<< Configuring library with Tecplot API support >>>
checking for ./contrib/laspack/lastypes.h... yes
<<< Configuring library with LASPACK version 1.12.3 support >>>
checking for /usr/local/petsc/petsc-2.1.6/include/petsc.h... yes
checking whether we are using the GNU Fortran 77 compiler... no
checking whether ifc accepts -g... yes
checking how to get verbose linking output from ifc... -v
checking for Fortran 77 libraries...  -L/usr/local/intel/compiler70/ia32/lib -L/usr/lib -lintrins -lIEPCF90 -lF90 -limf -lm -lirc -lcxa -lunwind
<<< Configuring library with PETSc version 2.1.6 support >>>
checking for ./contrib/metis/Lib/metis.h... yes
<<< Configuring library with Metis support >>>
checking for ./contrib/parmetis/Lib/parmetis.h... yes
<<< Configuring library with Parmetis support >>>
checking for doxygen... /usr/bin/doxygen
checking for dot... /usr/local/graphviz/bin/dot
----------------------------------------------
--- Done configuring for optional packages ---
----------------------------------------------
checking for perl... /usr/bin/perl
configure: creating ./config.status
config.status: creating Make.common
config.status: creating include/base/libmesh_config.h
configure: creating ./config.status
config.status: creating Make.common
config.status: creating doc/Doxyfile
config.status: creating include/base/libmesh_config.h
config.status: include/base/libmesh_config.h is unchanged
---------------------------------------------
--------- Done Configuring libMesh ----------
---------------------------------------------

Notice how PETSc was found in the "optional packages" section.
Please let me know if you still have an issue.

-Ben

Patrick O. Lechner wrote:

> Hello Steffen,
>
> thank you very much for your email and your help.
> I've done the modifications, that you mentioned, but it still doesn't work so far.
> The output from make echo, that I get, is:
>
> Source Files:
> src/base/dof_map.C src/base/dof_map_constraints.C src/base/dof_object.C src/base/equation_systems.C src/base/equation_systems_io.C src/base/frequency_system.C src/base/libmesh_base.C src/base/libmesh.C src/base/newmark_system.C src/base/node.C src/base/reference_counted_object.C src/base/reference_counter.C src/base/steady_system.C src/base/system_base.C src/base/system_base_io.C src/base/system_base_projection.C src/base/transient_system.C src/fe/fe_base.C src/fe/fe_boundary.C src/fe/fe.C src/fe/fe_hierarchic.C src/fe/fe_hierarchic_shape_1D.C src/fe/fe_hierarchic_shape_2D.C src/fe/fe_hierarchic_shape_3D.C src/fe/fe_interface.C src/fe/fe_interface_inf_fe.C src/fe/fe_lagrange.C src/fe/fe_lagrange_shape_1D.C src/fe/fe_lagrange_shape_2D.C src/fe/fe_lagrange_shape_3D.C src/fe/fe_map.C src/fe/fe_monomial.C src/fe/fe_monomial_shape_1D.C src/fe/fe_monomial_shape_2D.C src/fe/fe_monomial_shape_3D.C src/fe/inf_fe_base_radial.C src/fe/inf_fe_boundary.C src/fe/inf_fe.C src/fe/inf_fe_j!
acobi_20_00_eval.C src/fe/inf_fe_jacobi_30_00_eval.C src/fe/inf_fe_lagrange_eval.C src/fe/inf_fe_legendre_eval.C src/fe/inf_fe_map.C src/fe/inf_fe_map_eval.C src/fe/inf_fe_static.C src/geom/cell.C src/geom/cell_hex20.C src/geom/cell_hex27.C src/geom/cell_hex8.C src/geom/cell_hex.C src/geom/cell_inf.C src/geom/cell_inf_hex16.C src/geom/cell_inf_hex18.C src/geom/cell_inf_hex8.C src/geom/cell_inf_hex.C src/geom/cell_inf_prism12.C src/geom/cell_inf_prism6.C src/geom/cell_inf_prism.C src/geom/cell_prism15.C src/geom/cell_prism18.C src/geom/cell_prism6.C src/geom/cell_prism.C src/geom/cell_pyramid5.C src/geom/cell_pyramid.C src/geom/cell_tet10.C src/geom/cell_tet4.C src/geom/cell_tet.C src/geom/edge.C src/geom/edge_edge2.C src/geom/edge_edge3.C src/geom/edge_inf_edge2.C src/geom/elem.C src/geom/elem_quality.C src/geom/elem_refinement.C src/geom/elem_type.C src/geom/face.C src/geom/face_inf_quad4.C src/geom/face_inf_quad6.C src/geom/face_inf_quad.C src/geom/face_quad4.C src/geom/fa!
ce_quad8.C src/geom/face_quad9.C src/geom/face_quad.C src/geo!
m/face_tri3.C src/geom/face_tri6.C src/geom/face_tri.C src/geom/plane.C src/geom/point.C src/geom/sphere.C src/geom/surface.C src/mesh/boundary_info.C src/mesh/boundary_mesh.C src/mesh/mesh_base.C src/mesh/mesh_base_modification.C src/mesh/mesh.C src/mesh/mesh_communication.C src/mesh/mesh_data.C src/mesh/mesh_data_unv_support.C src/mesh/mesh_data_xdr_support.C src/mesh/mesh_diva_support.C src/mesh/mesh_exodus_support.C src/mesh/mesh_generation.C src/mesh/mesh_gmv_support.C src/mesh/mesh_misc_support.C src/mesh/mesh_modification.C src/mesh/mesh_refinement.C src/mesh/mesh_refinement_flagging.C src/mesh/mesh_refinement_smoothing.C src/mesh/mesh_smoother.C src/mesh/mesh_smoother_laplace.C src/mesh/mesh_tecplot_support.C src/mesh/mesh_ucd_support.C src/mesh/mesh_unv_support.C src/mesh/mesh_xdr_support.C src/numerics/analytic_function.C src/numerics/coupling_matrix.C src/numerics/dense_matrix_base.C src/numerics/dense_matrix.C src/numerics/dense_submatrix.C src/numerics/dense_sub!
vector.C src/numerics/dense_vector_base.C src/numerics/dense_vector.C src/numerics/distributed_vector.C src/numerics/error_estimator.C src/numerics/function_base.C src/numerics/laspack_interface.C src/numerics/laspack_matrix.C src/numerics/laspack_vector.C src/numerics/linear_solver_interface.C src/numerics/mesh_function.C src/numerics/numeric_vector.C src/numerics/petsc_interface.C src/numerics/petsc_matrix.C src/numerics/petsc_vector.C src/numerics/sparse_matrix.C src/numerics/type_vector.C src/partitioning/centroid_partitioner.C src/partitioning/linear_partitioner.C src/partitioning/metis_partitioner.C src/partitioning/parmetis_partitioner.C src/partitioning/partitioner.C src/partitioning/sfc_partitioner.C src/quadrature/quadrature_build.C src/quadrature/quadrature.C src/quadrature/quadrature_gauss_1D.C src/quadrature/quadrature_gauss_2D.C src/quadrature/quadrature_gauss_3D.C src/quadrature/quadrature_gauss.C src/quadrature/quadrature_jacobi_1D.C src/quadrat

Hi,

I'm having a little bit trouble. The problem is the execution of my
code in parallel.

In the current implementation processor 0 reads in the mesh. After that
the mesh is distributed to every other processor. In the read method of
the class UnvMeshInterface is a call for close_foreign_id_maps() so that
the id_maps are closed after that, but only on processor 0. 
If you now try to read in mesh data in parallel, the programm would tell
you something like this:

src/mesh/mesh_data.C:257: void MeshData::read(const std::string&):
Assertion `_elem_id_map_closed && _node_id_map_closed' failed.

This is correct, since on processor 1, 2 and so on are the id_maps not
closed. If now try to close the id_maps with a little hack in Mesh::read
you will see, that there are no _elem_id, _id_elem, _node_id and
_id_node on these processors.
A solution for this could be to distribute these things with the mesh
and to call close_foreign_id_maps() in Mesh::read. Or to change the
read implementation Mesh and MeshData classes. In my opinion this should
be reading in the mesh on processor 0 and than close the id_maps. After
this processor 0 reads in the mesh data. At least the mesh and
mesh data should be distributed to every processor.

Am I'm right or did i misunderstood something?

I've tried to run example 12 on 2 or 3 processor. I got nearly the same
error message so I think that it's not my implementation of the TetGen
interface, which is more or less like UnvMeshInterface class.

Any hints or comments are welcome.

Best regards
Jens.

PS: Would you like to add the TetGen methods after some more tests from
my side?

-- 

Hi,

Thanks for the input on compiling libMesh on OS X.  The library compiles
and links successfully with --disable-shared, however I can't figure out
how to get the examples to work correctly.  I used ranlib on the
contributed libraries to generate a table of contents, which seemed to
work; however, when I run this on libmesh.a I get error messages saying
that:

- several objects contain no symbols
- there are multiple references of at least one symbol

I am using OS X 10.3 and GCC 3.3.

Any thoughts on how to fix this would be welcome!

Thanks

Kyle Passarelli

Hello,

We have an OSX box, but we've never really put much effort
into compiling on it.  You might try --disable-shared on
the configure line and see if that does anything.

-John

kp...@id... writes:
 > Hi
 > 
 > Does anyone have any experience with compiling libMesh on OSX?  I get a
 > linker error, "g++: unrecognized option '-shared'", followed by many lines
 > complaining about "definition of absolute".
 > 
 > Thanks

Hi

Does anyone have any experience with compiling libMesh on OSX?  I get a
linker error, "g++: unrecognized option '-shared'", followed by many lines
complaining about "definition of absolute".

Thanks

Hi,

yesterday I send/receive some mail with the debian packager of libpetsc. Here 
is the mail. Please, look it.

Best regards.

Leo

Pd 

----------  Missatge transmès  ----------

Subject: Re: Maybe a bug in libpetsc-2.1.6
Date: Dimecres 19 Novembre 2003 20:28
From: Adam C Powell IV <haz...@de...>
To: Leopold Palomo Avellaneda <le...@wo...>

Hello,

Two things:

        1. You can get woody petsc 2.1.6 (adjusted so it builds with the
           older mpich) by adding the following line to
           /etc/apt/sources.list deb http://lyre.mit.edu/~powell/debian
           woody math
        2. Either way, MPI_LIB is not meant to have all of the mpich
           link flags.  If you scroll further down in
           bmake/linux*/packages, you'll see "Location of MPE" with the
           MPE flags which are necessary for linking.

In general, if you want to link something against PETSc, you should
*not* be using variables like MPI_LIB, but variables like PETSC_MAT_LIB,
PETSC_TS_LIB, etc., which include PETSC_EXTERNAL_LIB_BASIC, which in
turn includes MPI, MPE if present, X11, BLAS and LAPACK, etc.  If you
install petsc2.1.6-doc, and unpack the src.tar.gz file with all the
examples, you'll see that this is how those makefiles do things.  [I've
also put together a petsc.m4 which defines these things, but only if you
use autoconf/automake.]

If libmesh is trying to directly use MPI_LIB, then that's a bug in
libmesh, due to a misunderstanding of how to link against the PETSc
libraries.

Also, the README.Debian in the -dev package gives the address of the
"package homepage" http://lyre.mit.edu/~powell/debian.html , which among
other things has a link to my aptable archive with the woody backport of
PETSc 2.1.6 (mentioned above).

On Wed, 2003-11-19 at 06:00, Leopold Palomo Avellaneda wrote:
> Dear Adam C. Powell,
>
> I have a question of the petsc package (version 2.1.6, from sid) and I
> don't know if is a bug in the debian package or not.
>
> I'm trying to use a library (libmesh) that need mpi and petsc. There's no
> debian package, so I tried to compile myself.
>
> I had some errors with the petsc2.1.3 version so I decided to use
> petsc2.1.6. I realised, because of the control file, that to backported
> petsc2.1.6 I needed to backport mpich package. So I did it first. You know,
> sources, fakeroot debian/rules binary. Ok, no problems, a have a debs 
thathttp://lyre.mit.edu/~powell/debian
> works Ok.
>
> I installed the mpich package, the backported 1.2.5 version.
>
> After I compiled the petsc package, and I obtain my need debs files of
> petsc2.16 and I installed it.
>
> When I tried to compiled the library libmesh I had this errors at link:
> [verbose errors snipped]
> In the libmesh list, we have realised that the pets-bmake have this values:
> [....]
> # For mpich:
> ifeq ($(PETSC_MPI),mpich)
>   MPI_HOME       = /usr/lib/mpich
>   MPI_LIB        = -L${MPI_HOME}/lib/shared -L${MPI_HOME}/lib -lmpich
>   MPIRUN         = /usr/bin/mpirun.mpich
>   MPI_INCLUDE    = -I/usr/lib/mpich/include
> endif
> [....]
> but, if I change this line
> -  MPI_LIB        = -L${MPI_HOME}/lib/shared -L${MPI_HOME}/lib -lmpich
> +   MPI_LIB        = -L${MPI_HOME}/lib/shared -L${MPI_HOME}/lib -lmpich
> -lmpe
>
> now the error dissapears and all is ok. So I deduce that if petsc2.1.6
> depends of mpi version 1.2.5, and that version had the mpe library, so
> maybe, if you want to link to a petsc library, you need to add -lmpe to
> your programs. That's all.
>
> Is this a bug in the debian package? I don't know.
>
> Please tell me something, I will comment to the libmesh.

Great, thanks for looking into this.  It's still possible there's a bug
in my package, but I suspect the problem is in libmesh.

Let me know if you need any further assistance.
--
-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg

-------------------------------------------------------

Sure...  What you want to use is the Monomials family instead of the 
Lagrange family.  The Lagrange basis functions assume values at the 
nodes and are C0 continuous.  The monomials only have DOFs associated 
with the element and have no continuity.

Try the following:

FEType fe_type (CONST, MONOMIAL);        
Eq("Laplace").add_variable("u", fe_type);

The other add_variable member assumes Lagrange elements. I mau make an 
option soon that will work like this:

add_variable ("u", CONST, MONOMIAL);

-Ben

Buffat Marc wrote:

>Hello,
>I am currently testing the libmesh library.
>I have a research project to develop an unstructured  FiniteVolume CFD code  
>using mesh refinement. The approximation use constant value per element 
>(Finite volume), i.e. a P0 (constant) approximation per element.
>Is it possible to use P0 element, i.e. element with 1 dof per element (and no 
>dof per node) with libmesh.
>Actually I can build the mesh and compute values per elements using
>vector class in sequential.
>But I cannot use the Equationsystem class which do not accept CONST Lagrange 
>F.E.
>
>code like 
>...
>EquationSystems Eq(geo);
>     {
>       Eq.add_system<SteadySystem> ("Laplace");
>       Eq("Laplace").add_variable("u", CONST);
>       Eq("Laplace").attach_assemble_function (assemble);
>       Eq.init();
>       Eq.print_info();
>     }
>..
>produce a runtime error
>[0] src/fe/fe_lagrange.C, line 526, compiled Nov 19 2003 at 17:30:01
>Abandon
>whereas the same code with FIRST instead of CONST works.
>
>Any Idea or advice are welcome?
>If the P0 Lagrange is not available yet, is it complicated to include it ?
>Thanks 
>	Marc
>
>  
>

Hello,
I am currently testing the libmesh library.
I have a research project to develop an unstructured  FiniteVolume CFD code  
using mesh refinement. The approximation use constant value per element 
(Finite volume), i.e. a P0 (constant) approximation per element.
Is it possible to use P0 element, i.e. element with 1 dof per element (and no 
dof per node) with libmesh.
Actually I can build the mesh and compute values per elements using
vector class in sequential.
But I cannot use the Equationsystem class which do not accept CONST Lagrange 
F.E.

code like 
...
EquationSystems Eq(geo);
     {
       Eq.add_system<SteadySystem> ("Laplace");
       Eq("Laplace").add_variable("u", CONST);
       Eq("Laplace").attach_assemble_function (assemble);
       Eq.init();
       Eq.print_info();
     }
..
produce a runtime error
[0] src/fe/fe_lagrange.C, line 526, compiled Nov 19 2003 at 17:30:01
Abandon
whereas the same code with FIRST instead of CONST works.

Any Idea or advice are welcome?
If the P0 Lagrange is not available yet, is it complicated to include it ?
Thanks 
	Marc

-- 
Marc BUFFAT, Pr. Universite Claude Bernard LYON I 
tel:  (33) 04/72/43/11/02 (UCBL)
fax:  (33) 04/72/44/80/54
bu...@uf... | http://p2chpd-cluster.univ-lyon1.fr

Hello Leopold,

good, that you finally managed to get libmesh on your system running.
However what you name an error in ex6 and ex12, is actually intended.
Example 6 (ex6) is _only_ functional when you configure libmesh with

 ./configure --enable-ifem

See details of the infinite elements e.g. in the class docs of InfFE.

Similar reasoning applies also to ex12.  Example 12 only works
_completely_ fine when you _do_ use gzstream functionality (check the
output of ex12 carefully!).  So, the behavior of ex6 and ex12 is expected,
and not erroneous.

A final recommendation: better use METHOD=dbg, and not optimized mode.
This helps a lot.

Again, congrat's for using the right stuff: libmesh! ;)
  Daniel

Dear people,

finally I have compiled the examples!!!!! Well, without gzstream part. I have 
download the cvs version and it have been compiled in a debian stable with 
this options:

#!/bin/sh
export PETSC_DIR="/usr/lib/petsc";
export PETSC_ARCH="linux";
./configure --disable-gzstreams;
make clean;
make -j 30;

the examples have been compiled, but someone have some errors:

ex6:

make[2]: Entering directory `/rhome/lepalom/test_finite/libmesh/examples/ex6'
Compiling C++ (in optimized mode) ex6.C...
Linking ex6...
/rhome/lepalom/test_finite/libmesh/contrib/tecplot/lib/i686-pc-linux-gnu/
tecio.a(tecxxx.o): In function `tecini':
tecxxx.o(.text+0x1a7): the use of `mktemp' is dangerous, better use `mkstemp'
***************************************************************
* Running Example  ./ex6
***************************************************************

ERROR: This example requires the library to be compiled with Infinite Element 
support!
[0] ex6.C, line 82, compiled Nov 17 2003 at 18:44:15

***************************************************************
* Done Running Example  ./ex6
***************************************************************

and the example 12 have done another  error:
make[2]: Entering directory `/rhome/lepalom/test_finite/libmesh/examples/ex12'
Compiling C++ (in optimized mode) ex12.C...
Linking ex12...
/rhome/lepalom/test_finite/libmesh/contrib/tecplot/lib/i686-pc-linux-gnu/
tecio.a(tecxxx.o): In function `tecini':
tecxxx.o(.text+0x1a7): the use of `mktemp' is dangerous, better use `mkstemp'
***************************************************************
* Running Example  ./ex12
***************************************************************

 Universal file Interface:
  Counting nodes and elements
  Convert from "D" to "e"
  Nodes   : 3977
  Elements: 3520
  Reading nodes
  Reading elements
  Finished.

Finished reading the mesh.  MeshData is active but empty:
---------------------------------------------------------
 Mesh Information:
  mesh_dimension()=3
  spatial_dimension()=3
  n_nodes()=3977
  n_elem()=3520
   n_local_elem()=3520
   n_active_elem()=3520
  n_subdomains()=1
  n_processors()=1
  processor_id()=0

 MeshData Information:
  object activated.

After inserting artificial data into the MeshData:
--------------------------------------------------
 MeshData Information:
  object activated.
  Element associated data initialized.
   n_val_per_elem()=0
   n_elem_data()=0
  Node associated data initialized.
   n_val_per_node()=2
   n_node_data()=3977

Writing MeshData to: data_first_out_with_default_header.unv

Attach our own MeshDataUnvHeader to the MeshData:
-------------------------------------------------
 (note the warning: the number of values per node in
  my_header is not correct)

Writing MeshData to: data_second_with_header_out.unv
WARNING: nvaldc=3 of attached MeshDataUnvHeader object not valid!
         re-set nvaldc to 2

Before clearing the MeshData:
-----------------------------
 MeshData Information:
  object activated.
  Element associated data initialized.
   n_val_per_elem()=0
   n_elem_data()=0
  Node associated data initialized.
   n_val_per_node()=2
   n_node_data()=3977

After clearing the MeshData:
----------------------------
 MeshData Information:
  object activated.

After re-reading the first file:
--------------------------------
 MeshData Information:
  object activated.
  Element associated data initialized.
   n_val_per_elem()=0
   n_elem_data()=0
  Node associated data initialized.
   n_val_per_node()=2
   n_node_data()=3977

----------------------------------------------
---------- next example with MeshData --------
----------------------------------------------

 Universal file Interface:
  Counting nodes and elements
  Convert from "D" to "e"
  Nodes   : 3977
  Elements: 3520
  Reading nodes
  Reading elements
  Finished.

De-activated MeshData:
----------------------
 Mesh Information:
  mesh_dimension()=3
  spatial_dimension()=3
  n_nodes()=3977
  n_elem()=3520
   n_local_elem()=3520
   n_active_elem()=3520
  n_subdomains()=1
  n_processors()=1
  processor_id()=0

 MeshData neither active nor in compatibility mode.

Writing _Mesh_ to: mesh_with_libmesh_ids.unv
Try 'diff mesh_with_libmesh_ids.unv ../../examples/ex8/pipe-mesh.unv'
to see the differences in node numbers.
---------------------------------------

 Universal file Interface:

*************************************************************************
* WARNING: MeshData neither active nor in compatibility mode.           *
*          Enable compatibility mode for MeshData.  Use this Universal  *
*          file with caution: libMesh node and element ids are used.    *
*************************************************************************

  Writing 3977 nodes
  Writing elements
  Finished writing 3520 elements

Writing MeshData to: data_third_with_libmesh_ids_out.unv
----------------------------------------------------------

Writing gzip'ed MeshData to: packed_data_third_with_libmesh_ids_out.unv.gz
---------------------------------------------------------------------------
 To verify the integrity of the packed version, type:

   gunzip packed_data_third_with_libmesh_ids_out.unv.gz;
   diff packed_data_third_with_libmesh_ids_out.unv 
data_third_with_libmesh_ids_out.unv

ERROR:  You must have the zlib.h header files and libraries to read and write 
compressed streams.
[0] src/mesh/mesh_data_unv_support.C, line 427, compiled Nov 17 2003 at 
18:19:04
make[2]: *** [run] Aborted
make[2]: Leaving directory `/rhome/lepalom/test_finite/libmesh/examples/ex12'
make[1]: *** [run] Error 2
make[1]: Leaving directory `/rhome/lepalom/test_finite/libmesh/examples'
make: *** [run_examples] Error 2
lepalom@e01:~/test_finite/libmesh$ locate zlib.h
/usr/include/zlib.h

Well, I hope that this information can help. I will try to understand the 
examples.

Thank's a lot,

best regards,

Leo

A Dilluns 17 Novembre 2003 16:58, Leopold Palomo Avellaneda va escriure:
> Hi,
>
> A Dilluns 17 Novembre 2003 16:08, Benjamin S. Kirk va escriure:
> > Right, that would be my thought.  If the PETSc provided for Debian
> > requires libmpe.a (which it clearly does) then it should list that
> > library in the packages file like this:
> >
> > ifeq ($(PETSC_MPI),mpich)
> >    MPI_HOME       = /usr/lib/mpich
> >    MPI_LIB        = -L${MPI_HOME}/lib/shared \
> >                     -L${MPI_HOME}/lib -lmpich -lmpe
> >    MPIRUN         = /usr/bin/mpirun.mpich
> >    MPI_INCLUDE    = -I${MPI_HOME}/include
> > endif
>
> In others distros, how is it?
>
> > I'm not sure about your gzstreams problem yet...  I'll look at that now.
> > In the mean time you can configure the library with --disable-gzstreams
> > and everything should work OK.
>
> No OK, KO.
> if I do:
> export PETSC_DIR="/usr/lib/petsc";
> export PETSC_ARCH="linux";
> ./configure --disable-gzstreams;
>
> I have
> [....]
> Compiling C++ (in optimized mode) src/mesh/mesh_data_unv_support.C...
> Compiling C++ (in optimized mode) src/mesh/mesh_data_xdr_support.C...
> Compiling C++ (in optimized mode) src/mesh/mesh_diva_support.C...
> Compiling C++ (in optimized mode) src/mesh/mesh_exodus_support.C...
> src/mesh/mesh_data_unv_support.C:29: gzstream.h: No such file or directory
> Compiling C++ (in optimized mode) src/mesh/mesh_generation.C...
> make: *** [src/mesh/mesh_data_unv_support.i686-pc-linux-gnu.o] Error 1
>
> so, I think that the libmesh script doesn't like a debian system :-(
>
> Regards,
>
> Leo
>
> > -Ben
> >
> > Leopold Palomo Avellaneda wrote:
> > > Hi,
> > >
> > > A Dilluns 17 Novembre 2003 11:11, Jens Oeser va escriure:
> > >>as I mentioned I'm running the same configuration like you. To find out
> > >>where your problem is, I configured libmesh in the same way. If
> > >>I try to link one of the examples I get the same error messages for
> > >>undefined references to "MPE_***" but not for gzstream.
> > >
> > > Ok, it's strange.
> > >
> > >>I think you are
> > >>missing a debian package like zlib1g or zlib1g-dev, but I'm not sure.
> > >
> > > I have installed.
> > > ii  zlib1g           1.1.4-1          compression library - runtime
> > > ii  zlib1g-dev       1.1.4-1          compression library - development
> > >
> > >>I
> > >>could also solve the mpe problem by adding -lmpe in the packages file.
> > >>This could be point of diskussion with the debain maintainer.
> > >
> > > Ok, so it's a bug in the debian package, no?
> > >
> > > regards,
> > >
> > > Leo
> > >
> > >>On Mon, 17 Nov 2003 10:25:03 +0100
> > >>
> > >>Leopold Palomo Avellaneda <le...@wo...> wrote:
> > >>>Hi,
> > >>>
> > >>>thank's for the answer.
> > >>>
> > >>>A Divendres 14 Novembre 2003 14:35, Benjamin S. Kirk va escriure:
> > >>>>post the output of 'make echo' so I can see what your configutation
> > >>>>is. Also, the symbol MPE_Log_event is defined in the MPI library
> > >>>>libmpe.a, so that needs to be linked in as well.
> > >>>
> > >>>See the attach file.
> > >>>
> > >>>>I have never needed this library for the PETSc's I have built from
> > >>>>source, but it seems to be required by the precompiled Debian
> > >>>>packages.
> > >>>
> > >>>Yes there's a dependencies. Also, there are a change betwend the
> > >>>version 2.1.3 (woody-stable) and 2.1.6 (sarge-testing). The last one
> > >>>needs the mpich library (version  mpich (>= 1.2.5-4)).
> > >>>
> > >>>>look at the file $PETSC_DIR/bmake/$PETSC_ARCH/packages and see what
> > >>>>it says about the MPI configuration.  If it only has -lmpich add
> > >>>>-lmpe and let me know what happens.
> > >>>
> > >>>In this file, the lines that you are talking about are:
> > >>>
> > >>># For mpich:
> > >>>ifeq ($(PETSC_MPI),mpich)
> > >>>  MPI_HOME       = /usr/lib/mpich
> > >>>  MPI_LIB        = -L${MPI_HOME}/lib/shared -L${MPI_HOME}/lib -lmpich
> > >>>  MPIRUN         = /usr/bin/mpirun.mpich
> > >>>  MPI_INCLUDE    = -I/usr/lib/mpich/include
> > >>>endif
> > >>>
> > >>>So, I have the error. But, if I add -lmpe I have this:
> > >>>
> > >>>make[1]: Entering directory
> > >>>`/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples'
> > >>>make[2]: Entering directory
> > >>>`/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples/ex1'
> > >>>Linking ex1...
> > >>>/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/contrib/tecplot/lib/i686
> > >>>-pc-linux-gnu/tecio.a(tecxxx.o): In function `tecini':
> > >>>tecxxx.o(.text+0x1a7): the use of `mktemp' is dangerous, better use
> > >>>`mkstemp'/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-lin
> > >>>ux-gnu_opt/libmesh.so: undefined reference to
> > >>>`gzstreambase::gzstreambase(int, char const *,
> > >>>int)'/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-linux-g
> > >>>nu_opt/libmesh.so: undefined reference to
> > >>>`gzstreambase::~gzstreambase(void)'/rhome/lepalom/test_finite/libmesh
> > >>>-0.4.1-rc2/lib/i686-pc-linux-gnu_opt/libmesh.so: undefined reference
> > >>>to `gzstreambase type_info
> > >>>node'/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-linux-g
> > >>>nu_opt/libmesh.so: undefined reference to `gzstreambase type_info
> > >>>function' collect2: ld returned 1 exit status
> > >>>make[2]: *** [ex1] Error 1
> > >>>make[2]: Leaving directory
> > >>>`/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples/ex1'
> > >>>make[1]: *** [run] Error 2
> > >>>make[1]: Leaving directory
> > >>>`/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples'
> > >>>make: *** [run_examples] Error 2
> > >>>lepalom@e01:~/test_finite/libmesh-0.4.1-rc2$
> > >>>
> > >>>So only there are one error. This could be a bug in the petsc package,
> > >>>so please confirm that you didn't have this and I will comment it to
> > >>>the debian package mantainer.
> > >>>
> > >>>>I'm not sure what the gzstreambase stuff is yet, but try what I
> > >>>>mention above and we'll go from there.
> > >>>
> > >>>Now, we have only the error on this part of code.
> > >>>
> > >>>Best regards,
> > >>>
> > >>>Leo
> > >
> > > -------------------------------------------------------
> > > This SF. Net email is sponsored by: GoToMyPC
> > > GoToMyPC is the fast, easy and secure way to access your computer from
> > > any Web browser or wireless device. Click here to Try it Free!
> > > https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmp
> > >l _______________________________________________
> > > Libmesh-users mailing list
> > > Lib...@li...
> > > https://lists.sourceforge.net/lists/listinfo/libmesh-users
> >
> > -------------------------------------------------------
> > This SF. Net email is sponsored by: GoToMyPC
> > GoToMyPC is the fast, easy and secure way to access your computer from
> > any Web browser or wireless device. Click here to Try it Free!
> > https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> > _______________________________________________
> > Libmesh-users mailing list
> > Lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/libmesh-users
>
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users

Hi,
A Dilluns 17 Novembre 2003 16:08, Benjamin S. Kirk va escriure:
> Right, that would be my thought.  If the PETSc provided for Debian
> requires libmpe.a (which it clearly does) then it should list that
> library in the packages file like this:
>
> ifeq ($(PETSC_MPI),mpich)
>    MPI_HOME       = /usr/lib/mpich
>    MPI_LIB        = -L${MPI_HOME}/lib/shared \
>                     -L${MPI_HOME}/lib -lmpich -lmpe
>    MPIRUN         = /usr/bin/mpirun.mpich
>    MPI_INCLUDE    = -I${MPI_HOME}/include
> endif

In others distros, how is it?

> I'm not sure about your gzstreams problem yet...  I'll look at that now.
> In the mean time you can configure the library with --disable-gzstreams
> and everything should work OK.

No OK, KO.
if I do:
export PETSC_DIR="/usr/lib/petsc";
export PETSC_ARCH="linux";
./configure --disable-gzstreams;

I have
[....]
Compiling C++ (in optimized mode) src/mesh/mesh_data_unv_support.C...
Compiling C++ (in optimized mode) src/mesh/mesh_data_xdr_support.C...
Compiling C++ (in optimized mode) src/mesh/mesh_diva_support.C...
Compiling C++ (in optimized mode) src/mesh/mesh_exodus_support.C...
src/mesh/mesh_data_unv_support.C:29: gzstream.h: No such file or directory
Compiling C++ (in optimized mode) src/mesh/mesh_generation.C...
make: *** [src/mesh/mesh_data_unv_support.i686-pc-linux-gnu.o] Error 1

so, I think that the libmesh script doesn't like a debian system :-(

Regards,

Leo

>
> -Ben
>
> Leopold Palomo Avellaneda wrote:
> > Hi,
> >
> > A Dilluns 17 Novembre 2003 11:11, Jens Oeser va escriure:
> >>as I mentioned I'm running the same configuration like you. To find out
> >>where your problem is, I configured libmesh in the same way. If
> >>I try to link one of the examples I get the same error messages for
> >>undefined references to "MPE_***" but not for gzstream.
> >
> > Ok, it's strange.
> >
> >>I think you are
> >>missing a debian package like zlib1g or zlib1g-dev, but I'm not sure.
> >
> > I have installed.
> > ii  zlib1g           1.1.4-1          compression library - runtime
> > ii  zlib1g-dev       1.1.4-1          compression library - development
> >
> >>I
> >>could also solve the mpe problem by adding -lmpe in the packages file.
> >>This could be point of diskussion with the debain maintainer.
> >
> > Ok, so it's a bug in the debian package, no?
> >
> > regards,
> >
> > Leo
> >
> >>On Mon, 17 Nov 2003 10:25:03 +0100
> >>
> >>Leopold Palomo Avellaneda <le...@wo...> wrote:
> >>>Hi,
> >>>
> >>>thank's for the answer.
> >>>
> >>>A Divendres 14 Novembre 2003 14:35, Benjamin S. Kirk va escriure:
> >>>>post the output of 'make echo' so I can see what your configutation
> >>>>is. Also, the symbol MPE_Log_event is defined in the MPI library
> >>>>libmpe.a, so that needs to be linked in as well.
> >>>
> >>>See the attach file.
> >>>
> >>>>I have never needed this library for the PETSc's I have built from
> >>>>source, but it seems to be required by the precompiled Debian
> >>>>packages.
> >>>
> >>>Yes there's a dependencies. Also, there are a change betwend the
> >>>version 2.1.3 (woody-stable) and 2.1.6 (sarge-testing). The last one
> >>>needs the mpich library (version  mpich (>= 1.2.5-4)).
> >>>
> >>>>look at the file $PETSC_DIR/bmake/$PETSC_ARCH/packages and see what
> >>>>it says about the MPI configuration.  If it only has -lmpich add
> >>>>-lmpe and let me know what happens.
> >>>
> >>>In this file, the lines that you are talking about are:
> >>>
> >>># For mpich:
> >>>ifeq ($(PETSC_MPI),mpich)
> >>>  MPI_HOME       = /usr/lib/mpich
> >>>  MPI_LIB        = -L${MPI_HOME}/lib/shared -L${MPI_HOME}/lib -lmpich
> >>>  MPIRUN         = /usr/bin/mpirun.mpich
> >>>  MPI_INCLUDE    = -I/usr/lib/mpich/include
> >>>endif
> >>>
> >>>So, I have the error. But, if I add -lmpe I have this:
> >>>
> >>>make[1]: Entering directory
> >>>`/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples'
> >>>make[2]: Entering directory
> >>>`/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples/ex1'
> >>>Linking ex1...
> >>>/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/contrib/tecplot/lib/i686
> >>>-pc-linux-gnu/tecio.a(tecxxx.o): In function `tecini':
> >>>tecxxx.o(.text+0x1a7): the use of `mktemp' is dangerous, better use
> >>>`mkstemp'/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-lin
> >>>ux-gnu_opt/libmesh.so: undefined reference to
> >>>`gzstreambase::gzstreambase(int, char const *,
> >>>int)'/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-linux-g
> >>>nu_opt/libmesh.so: undefined reference to
> >>>`gzstreambase::~gzstreambase(void)'/rhome/lepalom/test_finite/libmesh
> >>>-0.4.1-rc2/lib/i686-pc-linux-gnu_opt/libmesh.so: undefined reference
> >>>to `gzstreambase type_info
> >>>node'/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-linux-g
> >>>nu_opt/libmesh.so: undefined reference to `gzstreambase type_info
> >>>function' collect2: ld returned 1 exit status
> >>>make[2]: *** [ex1] Error 1
> >>>make[2]: Leaving directory
> >>>`/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples/ex1'
> >>>make[1]: *** [run] Error 2
> >>>make[1]: Leaving directory
> >>>`/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples'
> >>>make: *** [run_examples] Error 2
> >>>lepalom@e01:~/test_finite/libmesh-0.4.1-rc2$
> >>>
> >>>So only there are one error. This could be a bug in the petsc package,
> >>>so please confirm that you didn't have this and I will comment it to
> >>>the debian package mantainer.
> >>>
> >>>>I'm not sure what the gzstreambase stuff is yet, but try what I
> >>>>mention above and we'll go from there.
> >>>
> >>>Now, we have only the error on this part of code.
> >>>
> >>>Best regards,
> >>>
> >>>Leo
> >
> > -------------------------------------------------------
> > This SF. Net email is sponsored by: GoToMyPC
> > GoToMyPC is the fast, easy and secure way to access your computer from
> > any Web browser or wireless device. Click here to Try it Free!
> > https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> > _______________________________________________
> > Libmesh-users mailing list
> > Lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/libmesh-users
>
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users

Right, that would be my thought.  If the PETSc provided for Debian 
requires libmpe.a (which it clearly does) then it should list that 
library in the packages file like this:

ifeq ($(PETSC_MPI),mpich)
   MPI_HOME       = /usr/lib/mpich
   MPI_LIB        = -L${MPI_HOME}/lib/shared \
                    -L${MPI_HOME}/lib -lmpich -lmpe
   MPIRUN         = /usr/bin/mpirun.mpich
   MPI_INCLUDE    = -I${MPI_HOME}/include
endif

I'm not sure about your gzstreams problem yet...  I'll look at that now.
In the mean time you can configure the library with --disable-gzstreams
and everything should work OK.

-Ben

Leopold Palomo Avellaneda wrote:
> Hi,
> 
> A Dilluns 17 Novembre 2003 11:11, Jens Oeser va escriure:
> 
>>as I mentioned I'm running the same configuration like you. To find out
>>where your problem is, I configured libmesh in the same way. If
>>I try to link one of the examples I get the same error messages for
>>undefined references to "MPE_***" but not for gzstream. 
> 
> 
> Ok, it's strange.
> 
> 
> 
>>I think you are
>>missing a debian package like zlib1g or zlib1g-dev, but I'm not sure. 
> 
> 
> I have installed.
> ii  zlib1g           1.1.4-1          compression library - runtime
> ii  zlib1g-dev       1.1.4-1          compression library - development
> 
> 
>>I
>>could also solve the mpe problem by adding -lmpe in the packages file.
>>This could be point of diskussion with the debain maintainer.
> 
> 
> Ok, so it's a bug in the debian package, no?
> 
> regards,
> 
> Leo
> 
> 
> 
>>
>>
>>On Mon, 17 Nov 2003 10:25:03 +0100
>>
>>Leopold Palomo Avellaneda <le...@wo...> wrote:
>>
>>>Hi,
>>>
>>>thank's for the answer.
>>>
>>>A Divendres 14 Novembre 2003 14:35, Benjamin S. Kirk va escriure:
>>>
>>>>post the output of 'make echo' so I can see what your configutation
>>>>is. Also, the symbol MPE_Log_event is defined in the MPI library
>>>>libmpe.a, so that needs to be linked in as well.
>>>
>>>See the attach file.
>>>
>>>
>>>>I have never needed this library for the PETSc's I have built from
>>>>source, but it seems to be required by the precompiled Debian
>>>>packages.
>>>
>>>Yes there's a dependencies. Also, there are a change betwend the
>>>version 2.1.3 (woody-stable) and 2.1.6 (sarge-testing). The last one
>>>needs the mpich library (version  mpich (>= 1.2.5-4)).
>>>
>>>
>>>>look at the file $PETSC_DIR/bmake/$PETSC_ARCH/packages and see what
>>>>it says about the MPI configuration.  If it only has -lmpich add
>>>>-lmpe and let me know what happens.
>>>
>>>In this file, the lines that you are talking about are:
>>>
>>># For mpich:
>>>ifeq ($(PETSC_MPI),mpich)
>>>  MPI_HOME       = /usr/lib/mpich
>>>  MPI_LIB        = -L${MPI_HOME}/lib/shared -L${MPI_HOME}/lib -lmpich
>>>  MPIRUN         = /usr/bin/mpirun.mpich
>>>  MPI_INCLUDE    = -I/usr/lib/mpich/include
>>>endif
>>>
>>>So, I have the error. But, if I add -lmpe I have this:
>>>
>>>make[1]: Entering directory
>>>`/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples'
>>>make[2]: Entering directory
>>>`/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples/ex1'
>>>Linking ex1...
>>>/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/contrib/tecplot/lib/i686
>>>-pc-linux-gnu/tecio.a(tecxxx.o): In function `tecini':
>>>tecxxx.o(.text+0x1a7): the use of `mktemp' is dangerous, better use
>>>`mkstemp'/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-lin
>>>ux-gnu_opt/libmesh.so: undefined reference to
>>>`gzstreambase::gzstreambase(int, char const *,
>>>int)'/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-linux-g
>>>nu_opt/libmesh.so: undefined reference to
>>>`gzstreambase::~gzstreambase(void)'/rhome/lepalom/test_finite/libmesh
>>>-0.4.1-rc2/lib/i686-pc-linux-gnu_opt/libmesh.so: undefined reference
>>>to `gzstreambase type_info
>>>node'/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-linux-g
>>>nu_opt/libmesh.so: undefined reference to `gzstreambase type_info
>>>function' collect2: ld returned 1 exit status
>>>make[2]: *** [ex1] Error 1
>>>make[2]: Leaving directory
>>>`/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples/ex1'
>>>make[1]: *** [run] Error 2
>>>make[1]: Leaving directory
>>>`/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples'
>>>make: *** [run_examples] Error 2
>>>lepalom@e01:~/test_finite/libmesh-0.4.1-rc2$
>>>
>>>So only there are one error. This could be a bug in the petsc package,
>>>so please confirm that you didn't have this and I will comment it to
>>>the debian package mantainer.
>>>
>>>
>>>>I'm not sure what the gzstreambase stuff is yet, but try what I
>>>>mention above and we'll go from there.
>>>
>>>Now, we have only the error on this part of code.
>>>
>>>Best regards,
>>>
>>>Leo
> 
> 
> 
> 
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users

Hi,

A Dilluns 17 Novembre 2003 11:11, Jens Oeser va escriure:
> as I mentioned I'm running the same configuration like you. To find out
> where your problem is, I configured libmesh in the same way. If
> I try to link one of the examples I get the same error messages for
> undefined references to "MPE_***" but not for gzstream. 

Ok, it's strange.

> I think you are
> missing a debian package like zlib1g or zlib1g-dev, but I'm not sure. 

I have installed.
ii  zlib1g           1.1.4-1          compression library - runtime
ii  zlib1g-dev       1.1.4-1          compression library - development

>I
> could also solve the mpe problem by adding -lmpe in the packages file.
> This could be point of diskussion with the debain maintainer.

Ok, so it's a bug in the debian package, no?

regards,

Leo

>
>
>
> On Mon, 17 Nov 2003 10:25:03 +0100
>
> Leopold Palomo Avellaneda <le...@wo...> wrote:
> > Hi,
> >
> > thank's for the answer.
> >
> > A Divendres 14 Novembre 2003 14:35, Benjamin S. Kirk va escriure:
> > > post the output of 'make echo' so I can see what your configutation
> > > is. Also, the symbol MPE_Log_event is defined in the MPI library
> > > libmpe.a, so that needs to be linked in as well.
> >
> > See the attach file.
> >
> > > I have never needed this library for the PETSc's I have built from
> > > source, but it seems to be required by the precompiled Debian
> > > packages.
> >
> > Yes there's a dependencies. Also, there are a change betwend the
> > version 2.1.3 (woody-stable) and 2.1.6 (sarge-testing). The last one
> > needs the mpich library (version  mpich (>= 1.2.5-4)).
> >
> > > look at the file $PETSC_DIR/bmake/$PETSC_ARCH/packages and see what
> > > it says about the MPI configuration.  If it only has -lmpich add
> > > -lmpe and let me know what happens.
> >
> > In this file, the lines that you are talking about are:
> >
> > # For mpich:
> > ifeq ($(PETSC_MPI),mpich)
> >   MPI_HOME       = /usr/lib/mpich
> >   MPI_LIB        = -L${MPI_HOME}/lib/shared -L${MPI_HOME}/lib -lmpich
> >   MPIRUN         = /usr/bin/mpirun.mpich
> >   MPI_INCLUDE    = -I/usr/lib/mpich/include
> > endif
> >
> > So, I have the error. But, if I add -lmpe I have this:
> >
> > make[1]: Entering directory
> > `/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples'
> > make[2]: Entering directory
> > `/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples/ex1'
> > Linking ex1...
> > /rhome/lepalom/test_finite/libmesh-0.4.1-rc2/contrib/tecplot/lib/i686
> > -pc-linux-gnu/tecio.a(tecxxx.o): In function `tecini':
> > tecxxx.o(.text+0x1a7): the use of `mktemp' is dangerous, better use
> > `mkstemp'/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-lin
> > ux-gnu_opt/libmesh.so: undefined reference to
> > `gzstreambase::gzstreambase(int, char const *,
> > int)'/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-linux-g
> > nu_opt/libmesh.so: undefined reference to
> > `gzstreambase::~gzstreambase(void)'/rhome/lepalom/test_finite/libmesh
> > -0.4.1-rc2/lib/i686-pc-linux-gnu_opt/libmesh.so: undefined reference
> > to `gzstreambase type_info
> > node'/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-linux-g
> > nu_opt/libmesh.so: undefined reference to `gzstreambase type_info
> > function' collect2: ld returned 1 exit status
> > make[2]: *** [ex1] Error 1
> > make[2]: Leaving directory
> > `/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples/ex1'
> > make[1]: *** [run] Error 2
> > make[1]: Leaving directory
> > `/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples'
> > make: *** [run_examples] Error 2
> > lepalom@e01:~/test_finite/libmesh-0.4.1-rc2$
> >
> > So only there are one error. This could be a bug in the petsc package,
> > so please confirm that you didn't have this and I will comment it to
> > the debian package mantainer.
> >
> > > I'm not sure what the gzstreambase stuff is yet, but try what I
> > > mention above and we'll go from there.
> >
> > Now, we have only the error on this part of code.
> >
> > Best regards,
> >
> > Leo

Hi,

as I mentioned I'm running the same configuration like you. To find out
where your problem is, I configured libmesh in the same way. If
I try to link one of the examples I get the same error messages for
undefined references to "MPE_***" but not for gzstream. I think you are
missing a debian package like zlib1g or zlib1g-dev, but I'm not sure. I
could also solve the mpe problem by adding -lmpe in the packages file.
This could be point of diskussion with the debain maintainer.

Regards
Jens.

On Mon, 17 Nov 2003 10:25:03 +0100
Leopold Palomo Avellaneda <le...@wo...> wrote:

> Hi,
> 
> thank's for the answer.
> 
> A Divendres 14 Novembre 2003 14:35, Benjamin S. Kirk va escriure:
> > post the output of 'make echo' so I can see what your configutation
> > is. Also, the symbol MPE_Log_event is defined in the MPI library
> > libmpe.a, so that needs to be linked in as well.
> 
> See the attach file.
> 
> > I have never needed this library for the PETSc's I have built from
> > source, but it seems to be required by the precompiled Debian
> > packages.
> >
> Yes there's a dependencies. Also, there are a change betwend the
> version 2.1.3 (woody-stable) and 2.1.6 (sarge-testing). The last one
> needs the mpich library (version  mpich (>= 1.2.5-4)).
> 
> > look at the file $PETSC_DIR/bmake/$PETSC_ARCH/packages and see what
> > it says about the MPI configuration.  If it only has -lmpich add
> > -lmpe and let me know what happens.
> 
> In this file, the lines that you are talking about are:
> 
> # For mpich:
> ifeq ($(PETSC_MPI),mpich)
>   MPI_HOME       = /usr/lib/mpich
>   MPI_LIB        = -L${MPI_HOME}/lib/shared -L${MPI_HOME}/lib -lmpich
>   MPIRUN         = /usr/bin/mpirun.mpich
>   MPI_INCLUDE    = -I/usr/lib/mpich/include
> endif
> 
> So, I have the error. But, if I add -lmpe I have this:
> 
> make[1]: Entering directory 
> `/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples'
> make[2]: Entering directory 
> `/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples/ex1'
> Linking ex1...
> /rhome/lepalom/test_finite/libmesh-0.4.1-rc2/contrib/tecplot/lib/i686
> -pc-linux-gnu/tecio.a(tecxxx.o): In function `tecini':
> tecxxx.o(.text+0x1a7): the use of `mktemp' is dangerous, better use
> `mkstemp'/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-lin
> ux-gnu_opt/libmesh.so: undefined reference to
> `gzstreambase::gzstreambase(int, char const *,
> int)'/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-linux-g
> nu_opt/libmesh.so: undefined reference to
> `gzstreambase::~gzstreambase(void)'/rhome/lepalom/test_finite/libmesh
> -0.4.1-rc2/lib/i686-pc-linux-gnu_opt/libmesh.so: undefined reference
> to `gzstreambase type_info
> node'/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-linux-g
> nu_opt/libmesh.so: undefined reference to `gzstreambase type_info
> function' collect2: ld returned 1 exit status
> make[2]: *** [ex1] Error 1
> make[2]: Leaving directory 
> `/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples/ex1'
> make[1]: *** [run] Error 2
> make[1]: Leaving directory 
> `/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples'
> make: *** [run_examples] Error 2
> lepalom@e01:~/test_finite/libmesh-0.4.1-rc2$
> 
> So only there are one error. This could be a bug in the petsc package,
> so please confirm that you didn't have this and I will comment it to
> the debian package mantainer.
> 
> > I'm not sure what the gzstreambase stuff is yet, but try what I
> > mention above and we'll go from there.
> 
> Now, we have only the error on this part of code.
> 
> Best regards,
> 
> Leo
> 

-- 
Try to relax and enjoy the crisis.
		-- Ashleigh Brilliant

Hi,

thank's for the answer.

A Divendres 14 Novembre 2003 14:35, Benjamin S. Kirk va escriure:
> post the output of 'make echo' so I can see what your configutation is.
> Also, the symbol MPE_Log_event is defined in the MPI library libmpe.a,
> so that needs to be linked in as well.

See the attach file.

> I have never needed this library for the PETSc's I have built from
> source, but it seems to be required by the precompiled Debian packages.
>
Yes there's a dependencies. Also, there are a change betwend the version 2.1.3 
(woody-stable) and 2.1.6 (sarge-testing). The last one needs the mpich 
library (version  mpich (>= 1.2.5-4)).

> look at the file $PETSC_DIR/bmake/$PETSC_ARCH/packages and see what it
> says about the MPI configuration.  If it only has -lmpich add -lmpe and
> let me know what happens.

In this file, the lines that you are talking about are:

# For mpich:
ifeq ($(PETSC_MPI),mpich)
  MPI_HOME       = /usr/lib/mpich
  MPI_LIB        = -L${MPI_HOME}/lib/shared -L${MPI_HOME}/lib -lmpich
  MPIRUN         = /usr/bin/mpirun.mpich
  MPI_INCLUDE    = -I/usr/lib/mpich/include
endif

So, I have the error. But, if I add -lmpe I have this:

make[1]: Entering directory 
`/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples'
make[2]: Entering directory 
`/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples/ex1'
Linking ex1...
/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/contrib/tecplot/lib/i686-pc-linux-gnu/tecio.a(tecxxx.o): 
In function `tecini':
tecxxx.o(.text+0x1a7): the use of `mktemp' is dangerous, better use `mkstemp'
/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-linux-gnu_opt/libmesh.so: 
undefined reference to `gzstreambase::gzstreambase(int, char const *, int)'
/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-linux-gnu_opt/libmesh.so: 
undefined reference to `gzstreambase::~gzstreambase(void)'
/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-linux-gnu_opt/libmesh.so: 
undefined reference to `gzstreambase type_info node'
/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-linux-gnu_opt/libmesh.so: 
undefined reference to `gzstreambase type_info function'
collect2: ld returned 1 exit status
make[2]: *** [ex1] Error 1
make[2]: Leaving directory 
`/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples/ex1'
make[1]: *** [run] Error 2
make[1]: Leaving directory 
`/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples'
make: *** [run_examples] Error 2
lepalom@e01:~/test_finite/libmesh-0.4.1-rc2$

So only there are one error. This could be a bug in the petsc package, so 
please confirm that you didn't have this and I will comment it to the debian 
package mantainer.

> I'm not sure what the gzstreambase stuff is yet, but try what I mention
> above and we'll go from there.

Now, we have only the error on this part of code.

Best regards,

Leo

post the output of 'make echo' so I can see what your configutation is.  
Also, the symbol MPE_Log_event is defined in the MPI library libmpe.a, 
so that needs to be linked in as well.

I have never needed this library for the PETSc's I have built from 
source, but it seems to be required by the precompiled Debian packages.

look at the file $PETSC_DIR/bmake/$PETSC_ARCH/packages and see what it 
says about the MPI configuration.  If it only has -lmpich add -lmpe and 
let me know what happens.

I'm not sure what the gzstreambase stuff is yet, but try what I mention 
above and we'll go from there.

-Ben

Hi,

last wek I sent a message to the list, and, Ok, there's no obligation to 
answer, but I'm a bit lost about the error.

I have installed the petsc2.1.6, export the vars, etc. I can compile libmesh 
without problems, but I cannot link with the library, I have errors with the 
symbols table. Could you help me please because I'm a bit lost.

Best regards,

Leo

lepalom@e01:~/test_finite/libmesh-0.4.1-rc2$ make run_examples
make[1]: Entering directory 
`/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples'
make[2]: Entering directory 
`/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples/ex1'
Linking ex1...
/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/contrib/tecplot/lib/i686-pc-linux-gnu/tecio.a(tecxxx.o): 
In function `tecini':
tecxxx.o(.text+0x1a7): the use of `mktemp' is dangerous, better use `mkstemp'
/usr/lib/petsc/lib/libO/linux/libpetscsles.a(sles.o): In function `SLESSetUp':
sles.o(.text+0x15d1): undefined reference to `MPE_Log_event'
sles.o(.text+0x1a7e): undefined reference to `MPE_Log_event'
/usr/lib/petsc/lib/libO/linux/libpetscsles.a(sles.o): In function `SLESSolve':
sles.o(.text+0x2076): undefined reference to `MPE_Log_event'
sles.o(.text+0x2482): undefined reference to `MPE_Log_event'
/usr/lib/petsc/lib/libO/linux/libpetscsles.a(sles.o): In function 
`SLESSolveTranspose':
sles.o(.text+0x2b1f): undefined reference to `MPE_Log_event'
/usr/lib/petsc/lib/libO/linux/libpetscsles.a(sles.o)(.text+0x2c39): more 
undefined references to `MPE_Log_event' follow
/usr/lib/petsc/lib/libO/linux/libpetsc.a(plogmpe.o): In function 
`PetscLogMPEBegin':
plogmpe.o(.text+0x4): undefined reference to `MPE_Initialized_logging'
plogmpe.o(.text+0x1c): undefined reference to `MPE_Init_log'
/usr/lib/petsc/lib/libO/linux/libpetsc.a(plogmpe.o): In function 
`PetscLogMPEDump':
plogmpe.o(.text+0x165): undefined reference to `MPE_Finish_log'
/usr/lib/petsc/lib/libO/linux/libpetsc.a(eventLog.o): In function 
`EventRegLogRegister':
eventLog.o(.text+0x75a): undefined reference to `MPE_Log_get_event_number'
eventLog.o(.text+0x761): undefined reference to `MPE_Log_get_event_number'
eventLog.o(.text+0x7ff): undefined reference to `MPE_Describe_state'
/usr/lib/petsc/lib/libO/linux/libpetsc.a(pbarrier.o): In function 
`PetscBarrier':
pbarrier.o(.text+0x142): undefined reference to `MPE_Log_event'
pbarrier.o(.text+0x28f): undefined reference to `MPE_Log_event'
/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-linux-gnu_opt/libmesh.so: 
undefined reference to `gzstreambase::gzstreambase(int, char const *, int)'
/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-linux-gnu_opt/libmesh.so: 
undefined reference to `gzstreambase::~gzstreambase(void)'
/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-linux-gnu_opt/libmesh.so: 
undefined reference to `gzstreambase type_info node'
/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-linux-gnu_opt/libmesh.so: 
undefined reference to `gzstreambase type_info function'
collect2: ld returned 1 exit status
make[2]: *** [ex1] Error 1
make[2]: Leaving directory 
`/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples/ex1'
make[1]: *** [run] Error 2
make[1]: Leaving directory 
`/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples'
make: *** [run_examples] Error 2
lepalom@e01:~/test_finite/libmesh-0.4.1-rc2$

Hi

After some more hours of trying to find obscure linker problems, I
finally got libmesh working together with Petsc 2.1.6. on linux/gcc
3.3 (single processor, using MPIUNI).

To make this happen I had to do the following hacks:

o in libmesh.C: comment out the lines containing calls to
  MPI_Finalize.  MPI_Finalize gave me some strange linker errors
  (running the examples), as it is defined in libmpiuni.a

  > nm -C lib/i686-pc-linux-gnu_opt/libmesh.so |grep MPI_Finalize 
  >       U Petsc_MPI_Finalize()

  note the parentheses which do not appear using nm on libmpiuni.a

  I had a similar error with calls to MPIUNI_Memcpy, which went away
  as I updated the cvs some hour ago.

o I have to comment out all calls to CHKERRQ(ierr) in the files
  petsc-matrix.C, .... and in the header files.

  The reason for this is that CHKERRQ wants to leave the *calling
  function* with an error code. Since calls to CHKERRQ are made in
  functions declared as void, this causes a compiler error:

  > error: return-statement with a value, in function declared with a
  > void return type

  Alternatively, I could redeclare all functions with calls to CHKERRQ
  with an int return type. I have no clue which method is better.

o The file sfcurves.h is not found in the correct place, I have to
  copy it to include.

Wow, I am glad this finally works. Hopefully somebody can come up
with a less hacky solution. 

Best, Martin

Hi,

finally I have compiled libmesh on a debian woody system. Ok, thank's a lot 
for the help. Finally was had a directory WITHOUT spaces and some enviroment 
variables. So these are the steps:

To compile libmesh with MPI and PETSC you need these packages.

mpich
petsc2.1.3-dev

Also:
graphviz (non free section, for graphics in documentation)

$export PETSC_DIR="/usr/lib/petsc"
$export PETSC_ARCH="linux"
$./configure

This will create the library. About the examples I have found some problems. 
First of all you need some extra package, zlib1g-dev. Because you cannot 
compile the example 1. The error is:

/usr/bin/ld: cannot find -lz
collect2: ld returned 1 exit status

Sadly, the rest of the examples cannot be compiled, because some error (see 
below). I have found in the net about the mktemp and mkstemp question, but I 
understand that it's just a warning. About the undefined references in XXXX I 
have found that is a compiler error, but in the arm architecture not i386 
(gcc 2.95) 
http://lists.debian.org/debian-arm/2002/debian-arm-200201/msg00032.html

Please, could someone confirm this?

lepalom@e01:~/test_finite/libmesh-0.4.1-rc2$ make run_examples
make[1]: Entering directory 
`/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples'
make[2]: Entering directory 
`/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples/ex1'
Compiling C++ (in optimized mode) ex1.C...
Linking ex1...
/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/contrib/tecplot/lib/i686-pc-linux-gnu/tecio.a(tecxxx.o): 
In function `tecini':
tecxxx.o(.text+0x1a7): the use of `mktemp' is dangerous, better use `mkstemp'
/usr/lib/petsc/lib/libO/linux/libpetsc.so: undefined reference to 
`MPE_Initialized_logging'
/usr/lib/petsc/lib/libO/linux/libpetscsles.so: undefined reference to 
`MPE_Log_event'
/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-linux-gnu_opt/libmesh.so: 
undefined reference to `gzstreambase::gzstreambase(int, char const *, int)'
/usr/lib/petsc/lib/libO/linux/libpetsc.so: undefined reference to 
`MPE_Log_get_event_number'
/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-linux-gnu_opt/libmesh.so: 
undefined reference to `gzstreambase::~gzstreambase(void)'
/usr/lib/petsc/lib/libO/linux/libpetsc.so: undefined reference to 
`MPE_Init_log'
/usr/lib/petsc/lib/libO/linux/libpetsc.so: undefined reference to 
`MPE_Describe_state'
/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-linux-gnu_opt/libmesh.so: 
undefined reference to `gzstreambase type_info node'
/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/lib/i686-pc-linux-gnu_opt/libmesh.so: 
undefined reference to `gzstreambase type_info function'
/usr/lib/petsc/lib/libO/linux/libpetsc.so: undefined reference to 
`MPE_Finish_log'
collect2: ld returned 1 exit status
make[2]: *** [ex1] Error 1
make[2]: Leaving directory 
`/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples/ex1'
make[1]: *** [run] Error 2
make[1]: Leaving directory 
`/rhome/lepalom/test_finite/libmesh-0.4.1-rc2/examples'
make: *** [run_examples] Error 2
lepalom@e01:~/test_finite/libmesh-0.4.1-rc2$

Best reagrds,

Leo

>I have tried it and not it works. How about to put it in a FAQ, README, etc.  
>Howeber I have found a new error now. 
>
>lepalom@e01:~/Finite element/libmesh-0.4.1-rc2$ make
>Makefile:71: warning: overriding commands for target `/rhome/lepalom/Finite'
>Makefile:62: warning: ignoring old commands for target `/rhome/lepalom/Finite'
>Compiling C++ (in optimized mode) src/base/dof_map.C...
>g++: cannot specify -o with -c or -S and multiple compilations
>make: *** [src/base/dof_map.i686-pc-linux-gnu.o] Error 1
 ...
>./configure: line 7513: test: /rhome/lepalom/Finite: binary operator expected

Here is a "bad" name of working directory. For example "Finite_element",
i.e. without whitespace will be more better...

Denis.

2003	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (2)	Oct (2)	Nov (27)	Dec (31)
2004	Jan (6)	Feb (15)	Mar (33)	Apr (10)	May (46)	Jun (11)	Jul (21)	Aug (15)	Sep (13)	Oct (23)	Nov (1)	Dec (8)
2005	Jan (27)	Feb (57)	Mar (86)	Apr (23)	May (37)	Jun (34)	Jul (24)	Aug (17)	Sep (50)	Oct (24)	Nov (10)	Dec (60)
2006	Jan (47)	Feb (46)	Mar (127)	Apr (19)	May (26)	Jun (62)	Jul (47)	Aug (51)	Sep (61)	Oct (42)	Nov (50)	Dec (33)
2007	Jan (60)	Feb (55)	Mar (77)	Apr (102)	May (82)	Jun (102)	Jul (169)	Aug (117)	Sep (80)	Oct (37)	Nov (51)	Dec (43)
2008	Jan (71)	Feb (94)	Mar (98)	Apr (125)	May (54)	Jun (119)	Jul (60)	Aug (111)	Sep (118)	Oct (125)	Nov (119)	Dec (94)
2009	Jan (109)	Feb (38)	Mar (93)	Apr (88)	May (29)	Jun (57)	Jul (53)	Aug (48)	Sep (68)	Oct (151)	Nov (23)	Dec (35)
2010	Jan (84)	Feb (60)	Mar (184)	Apr (112)	May (60)	Jun (90)	Jul (23)	Aug (70)	Sep (119)	Oct (27)	Nov (47)	Dec (54)
2011	Jan (22)	Feb (19)	Mar (92)	Apr (93)	May (35)	Jun (91)	Jul (32)	Aug (61)	Sep (7)	Oct (69)	Nov (81)	Dec (23)
2012	Jan (64)	Feb (95)	Mar (35)	Apr (36)	May (63)	Jun (98)	Jul (70)	Aug (171)	Sep (149)	Oct (64)	Nov (67)	Dec (126)
2013	Jan (108)	Feb (104)	Mar (171)	Apr (133)	May (108)	Jun (100)	Jul (93)	Aug (126)	Sep (74)	Oct (59)	Nov (145)	Dec (93)
2014	Jan (38)	Feb (45)	Mar (26)	Apr (41)	May (125)	Jun (70)	Jul (61)	Aug (66)	Sep (60)	Oct (110)	Nov (27)	Dec (30)
2015	Jan (43)	Feb (67)	Mar (71)	Apr (92)	May (39)	Jun (15)	Jul (46)	Aug (63)	Sep (84)	Oct (82)	Nov (69)	Dec (45)
2016	Jan (92)	Feb (91)	Mar (148)	Apr (43)	May (58)	Jun (117)	Jul (92)	Aug (140)	Sep (49)	Oct (33)	Nov (85)	Dec (40)
2017	Jan (41)	Feb (36)	Mar (49)	Apr (41)	May (73)	Jun (51)	Jul (12)	Aug (69)	Sep (26)	Oct (43)	Nov (75)	Dec (23)
2018	Jan (86)	Feb (36)	Mar (50)	Apr (28)	May (53)	Jun (65)	Jul (26)	Aug (43)	Sep (32)	Oct (28)	Nov (52)	Dec (17)
2019	Jan (39)	Feb (26)	Mar (71)	Apr (30)	May (73)	Jun (18)	Jul (5)	Aug (10)	Sep (8)	Oct (24)	Nov (12)	Dec (34)
2020	Jan (17)	Feb (10)	Mar (6)	Apr (4)	May (15)	Jun (3)	Jul (8)	Aug (15)	Sep (6)	Oct (3)	Nov	Dec (4)
2021	Jan (4)	Feb (4)	Mar (21)	Apr (14)	May (13)	Jun (18)	Jul (1)	Aug (39)	Sep (1)	Oct	Nov (3)	Dec
2022	Jan	Feb	Mar (2)	Apr (8)	May	Jun	Jul	Aug (3)	Sep	Oct (3)	Nov	Dec
2023	Jan (2)	Feb	Mar	Apr	May	Jun	Jul	Aug (7)	Sep (3)	Oct	Nov	Dec (1)

libmesh-users Mailing List for libMesh: A C++ Finite Element Library (Page 481)

libmesh-users — General information for libmesh users