Re: [Libmesh-users] libmesh failing to build with sieve enabled in petsc

[David Fuentes <fuentesdt@gm...>]

petsc-dev with trunk libmesh



On Thu, Apr 26, 2012 at 1:14 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.kirk-1@...> wrote:

> On 4/25/12 1:35 PM, "David Fuentes" <fuentesdt@...> wrote:
>
> > libmesh will not seem to build with sieve enabled in petsc. perhaps the
> two
> > are using different versions of metis ? Is it possible to point libmesh
> to
> > use the version of exodusii and  metis that petsc is using ?
>
> Maybe.  I'm trying to recreate your PETSc build here for troubleshooting -
> what version is this?
>
> -Ben
>
>

[Libmesh-users] libmesh failing to build with sieve enabled in petsc

[David Fuentes <fuentesdt@gm...>]

libmesh will not seem to build with sieve enabled in petsc. perhaps the two
are using different versions of metis ? Is it possible to point libmesh to
use the version of exodusii and  metis that petsc is using ?


i'm building petsc with

config/config.py --CFLAGS=-O0 --CUDAFLAGS=-O0 --CXXFLAGS=-O0
--download-blacs --download-exodusii=yes --download-fiat=yes
--download-generator --download-metis --download-mumps --download-netcdf
--download-parmetis --download-scalapack --download-scientificpython
--download-superlu_dist --download-triangle
--with-blas-lapack-lib="[/opt/epd-7.1-2-rh5-x86_64/lib/libmkl_rt.so,/opt/epd-7.1-2-rh5-x86_64/lib/libmkl_intel_thread.so,/opt/epd-7.1-2-rh5-x86_64/lib/libmkl_core.so,/opt/epd-7.1-2-rh5-x86_64/lib/libiomp5.so]"
--with-boost-dir=/usr --with-boost=1 --with-clanguage=C++
--with-cuda-arch=sm_20 --with-cuda-dir=/opt/apps/cuda/4.1/cuda
--with-cuda=1 --with-cusp=1 --with-etags=1
--with-matlab-dir=/opt/MATLAB/R2011a --with-matlab-engine=1 --with-matlab=1
--with-mpi-dir=/usr --with-mpi4py=0 --with-shared-libraries --with-sieve=1
--with-thrust=1



SCRGP2$ mpicxx -DDEBUG  -DPETSC_USE_DYNAMIC_LIBRARIES -O0
-felide-constructors -g -W -Wall -Wextra -Wno-long-long -Wunused
-Wpointer-arith -Wformat -Wparentheses -fPIC -Woverloaded-virtual
-DMPICH_SKIP_MPICXX -I/usr/include -I/opt/apps/LIBMESH/libmesh/include/base
-I/opt/apps/LIBMESH/libmesh/include/enums
-I/opt/apps/LIBMESH/libmesh/include/error_estimation
-I/opt/apps/LIBMESH/libmesh/include/fe
-I/opt/apps/LIBMESH/libmesh/include/geom
-I/opt/apps/LIBMESH/libmesh/include/mesh
-I/opt/apps/LIBMESH/libmesh/include/numerics
-I/opt/apps/LIBMESH/libmesh/include/parallel
-I/opt/apps/LIBMESH/libmesh/include/partitioning
-I/opt/apps/LIBMESH/libmesh/include/physics
-I/opt/apps/LIBMESH/libmesh/include/quadrature
-I/opt/apps/LIBMESH/libmesh/include/reduced_basis
-I/opt/apps/LIBMESH/libmesh/include/solvers
-I/opt/apps/LIBMESH/libmesh/include/systems
-I/opt/apps/LIBMESH/libmesh/include/utils
-I/opt/apps/LIBMESH/libmesh/contrib/laspack
-I/opt/apps/LIBMESH/libmesh/contrib/parmetis/Lib
-I/opt/apps/LIBMESH/libmesh/contrib/metis/Lib
-I/opt/apps/LIBMESH/libmesh/contrib/sfcurves
 -I/opt/apps/LIBMESH/libmesh/contrib/gmv
-I/opt/apps/LIBMESH/libmesh/contrib/tetgen
-I/opt/apps/LIBMESH/libmesh/contrib/exodusii/Lib/include
-I/opt/apps/LIBMESH/libmesh/contrib/netcdf/Lib
-I/opt/apps/LIBMESH/libmesh/contrib/nemesis/Lib
-I/opt/apps/LIBMESH/libmesh/contrib/libHilbert/include
-I/opt/apps/LIBMESH/libmesh/contrib/fparser
-I/opt/apps/PETSC/petsc-dev/include
-I/opt/apps/PETSC/petsc-dev/bmake/gcc-4.4.3-mpich2-1.2-epd-sm_20-dbg
-I/opt/apps/PETSC/petsc-dev/gcc-4.4.3-mpich2-1.2-epd-sm_20-dbg/include
 -I/usr/include -I/usr/include/mpich2 -c src/base/libmesh.C -o
src/base/libmesh.x86_64-unknown-linux-gnu.dbg.o




/opt/apps/PETSC/petsc-dev/include/sieve/Partitioner.hh|239| error: there
are no arguments to ‘METIS_PartGraphKway’ that depend on a template
parameter, so a declaration of ‘METIS_PartGraphKway’ must be available
/opt/apps/PETSC/petsc-dev/include/sieve/Partitioner.hh|239| note: (if you
use ‘-fpermissive’, G++ will accept your code, but allowing the use of an
undeclared name is deprecated)
/opt/apps/PETSC/petsc-dev/include/sieve/Partitioner.hh|245| error: cannot
convert ‘PetscReal*’ to ‘float*’ for argument ‘10’ to ‘void
ParMETIS_V3_PartKway(idxtype*, idxtype*, idxtype*, idxtype*, idxtype*,
int*, int*, int*, int*, float*, float*, int*, int*, idxtype*, MPI_Comm*)’
|| /opt/apps/PETSC/petsc-dev/include/sieve/Partitioner.hh: At global scope:
/opt/apps/PETSC/petsc-dev/include/sieve/Partitioner.hh|275| warning: extra
‘;’
|| In file included from /opt/apps/PETSC/petsc-dev/include/sieve/Mesh.hh:32,
||                  from /opt/apps/PETSC/petsc-dev/include/petscdmmesh.h:12,
||                  from /opt/apps/PETSC/petsc-dev/include/petsc.h:9,
||                  from
/opt/apps/LIBMESH/libmesh/include/numerics/petsc_macro.h:81,
||                  from src/base/libmesh.C:46:
|| /opt/apps/PETSC/petsc-dev/include/sieve/Partitioner.hh: In static member
function ‘static int*
ALE::New::ParMetis::Partitioner<Bundle_>::partitionSieve(const
ALE::Obj<Bundle_, ALE::malloc_allocator<U> >&, int)’:
/opt/apps/PETSC/petsc-dev/include/sieve/Partitioner.hh|1944| error: there
are no arguments to ‘METIS_PartGraphKway’ that depend on a template
parameter, so a declaration of ‘METIS_PartGraphKway’ must be available
/opt/apps/PETSC/petsc-dev/include/sieve/Partitioner.hh|1950| error: cannot
convert ‘PetscReal*’ to ‘float*’ for argument ‘10’ to ‘void
ParMETIS_V3_PartKway(idxtype*, idxtype*, idxtype*, idxtype*, idxtype*,
int*, int*, int*, int*, float*, float*, int*, int*, idxtype*, MPI_Comm*)’
|| /opt/apps/PETSC/petsc-dev/include/sieve/Partitioner.hh: At global scope:
/opt/apps/PETSC/petsc-dev/include/sieve/Partitioner.hh|2015| warning: extra
‘;’
|| In file included from /opt/apps/PETSC/petsc-dev/include/petscdmmesh.h:12,
||                  from /opt/apps/PETSC/petsc-dev/include/petsc.h:9,
||                  from
/opt/apps/LIBMESH/libmesh/include/numerics/petsc_macro.h:81,
||                  from src/base/libmesh.C:46:
/opt/apps/PETSC/petsc-dev/include/sieve/Mesh.hh|64| warning: extra ‘;’
/opt/apps/PETSC/petsc-dev/include/sieve/Mesh.hh|73| warning: extra ‘;’
/opt/apps/PETSC/petsc-dev/include/sieve/Mesh.hh|81| warning: extra ‘;’
/opt/apps/PETSC/petsc-dev/include/sieve/Mesh.hh|89| warning: extra ‘;’
|| In file included from /opt/apps/PETSC/petsc-dev/include/petscdmmesh.h:13,
||                  from /opt/apps/PETSC/petsc-dev/include/petsc.h:9,
||                  from
/opt/apps/LIBMESH/libmesh/include/numerics/petsc_macro.h:81,
||                  from src/base/libmesh.C:46:
/opt/apps/PETSC/petsc-dev/include/sieve/CartesianSieve.hh|17| warning:
extra ‘;’

Re: [Libmesh-users] libmesh failing to build with sieve enabled in petsc

[Roy Stogner <roystgnr@ic...>]

On Wed, 25 Apr 2012, David Fuentes wrote:

> libmesh will not seem to build with sieve enabled in petsc. perhaps the two
> are using different versions of metis ? Is it possible to point libmesh to
> use the version of exodusii and  metis that petsc is using ?

Didn't we have a name collision with sieve at one point?  Would
building libMesh without the "using namespace libMesh" enabled
help?
---
Roy

Re: [Libmesh-users] libmesh failing to build with sieve enabled in petsc

[David Fuentes <fuentesdt@gm...>]

I deleted it. still seem to have the same problem. the signature for
METIS_PartGraphKway  is different for petsc and libmesh  versions of
parmetis. 5.0.2 vs 3.1, respectively. would it be possible to put the two
version in different namespaces ?

btw what is the proper way to configure libmesh to
undef LIBMESH_REQUIRE_SEPARATE_NAMESPACE  ?


/opt/apps/PETSC/petsc-dev/include/sieve/Partitioner.hh|239| error: there
are no arguments to ‘METIS_PartGraphKway’ that depend on a template
parameter, so a declaration of ‘METIS_PartGraphKway’ must be available
/opt/apps/PETSC/petsc-dev/include/sieve/Partitioner.hh|239| note: (if you
use ‘-fpermissive’, G++ will accept your code, but allowing the use of an
undeclared name is deprecated)
/opt/apps/PETSC/petsc-dev/include/sieve/Partitioner.hh|245| error: cannot
convert ‘PetscReal*’ to ‘float*’ for argument ‘10’ to ‘void
ParMETIS_V3_PartKway(idxtype*, idxtype*, idxtype*, idxtype*, idxtype*,
int*, int*, int*, int*, float*, float*, int*, int*, idxtype*, MPI_Comm*)’


SCRGP2$ svn diff include/base/
Index: include/base/libmesh_base.h
===================================================================
--- include/base/libmesh_base.h (revision 5597)
+++ include/base/libmesh_base.h (working copy)
@@ -112,9 +112,5 @@
 // Unless configured otherwise, we import all of namespace libMesh,
 // for backwards compatibility with pre-namespaced codes.

-#ifndef LIBMESH_REQUIRE_SEPARATE_NAMESPACE
-using namespace libMesh;
-#endif






On Wed, Apr 25, 2012 at 1:41 PM, Roy Stogner <roystgnr@...>wrote:

>
> On Wed, 25 Apr 2012, David Fuentes wrote:
>
>  libmesh will not seem to build with sieve enabled in petsc. perhaps the
>> two
>> are using different versions of metis ? Is it possible to point libmesh to
>> use the version of exodusii and  metis that petsc is using ?
>>
>
> Didn't we have a name collision with sieve at one point?  Would
> building libMesh without the "using namespace libMesh" enabled
> help?
> ---
> Roy
>

Re: [Libmesh-users] libmesh failing to build with sieve enabled in petsc

[Roy Stogner <roystgnr@ic...>]

On Wed, 25 Apr 2012, David Fuentes wrote:

> I deleted it. still seem to have the same problem. the signature for METIS_PartGraphKway  is different for petsc and libmesh  versions of
> parmetis. 5.0.2 vs 3.1, respectively. would it be possible to put the two version in different namespaces ? 

Hmm... no namespace support for a C library.  The best route I can
think of here would be to add a --with-parmetis= rather than just a
--enable-parmetis configure option, so that users can switch to a
third-party library rather than the one in contrib/

> btw what is the proper way to configure libmesh to undef LIBMESH_REQUIRE_SEPARATE_NAMESPACE  ?

The proper way is to write a new configure test for
--enable-namespace, send us a patch, then enable with
./configure --enable-namespace.  ;-)  We've been basically putting off
doing that ourselves until some user runs across a third party package
that really needs the separate namespace for compatibility reasons;
until then we just occasionally comment that bit out of libmesh_base.h
for testing.
---
Roy

Re: [Libmesh-users] libmesh failing to build with sieve enabled in petsc

[Kirk, Benjamin (JSC-EG311) <benjamin.kirk-1@na...>]

> On Wed, 25 Apr 2012, David Fuentes wrote:
> 
>> I deleted it. still seem to have the same problem. the signature for
>> METIS_PartGraphKway  is different for petsc and libmesh  versions of
>> parmetis. 5.0.2 vs 3.1, respectively. would it be possible to put the two
>> version in different namespaces ? 

As of r5662 libMesh has been updated to include the latest versions of metis
and parmetis.  There's a good chance this will resolve this compilation
issue, for now at least.

-Ben

Re: [Libmesh-users] libmesh failing to build with sieve enabled in petsc

[Kirk, Benjamin (JSC-EG311) <benjamin.kirk-1@na...>]

On 4/25/12 1:35 PM, "David Fuentes" <fuentesdt@...> wrote:

> libmesh will not seem to build with sieve enabled in petsc. perhaps the two
> are using different versions of metis ? Is it possible to point libmesh to
> use the version of exodusii and  metis that petsc is using ?

Maybe.  I'm trying to recreate your PETSc build here for troubleshooting -
what version is this?

-Ben 

Re: [Libmesh-users] libmesh failing to build with sieve enabled in petsc

[David Fuentes <fuentesdt@gm...>]

petsc-dev with trunk libmesh



On Thu, Apr 26, 2012 at 1:14 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.kirk-1@...> wrote:

> On 4/25/12 1:35 PM, "David Fuentes" <fuentesdt@...> wrote:
>
> > libmesh will not seem to build with sieve enabled in petsc. perhaps the
> two
> > are using different versions of metis ? Is it possible to point libmesh
> to
> > use the version of exodusii and  metis that petsc is using ?
>
> Maybe.  I'm trying to recreate your PETSc build here for troubleshooting -
> what version is this?
>
> -Ben
>
>

Re: [Libmesh-users] libmesh failing to build with sieve enabled in petsc

[Kirk, Benjamin (JSC-EG311) <benjamin.kirk-1@na...>]

On 4/26/12 1:19 PM, "David Fuentes" <fuentesdt@...> wrote:

> petsc-dev with trunk libmesh


Thanks.  I'll see if I can get that build here.

But I'm betting METIS is the tip of the iceberg - you listed a slew of
packages on the configure command line that could potentially clash with our
stuff.

It may be possible to have libmesh use the petsc metis, but I'm worried that
could be fragile if, for example, trilinos decided to bundle metis as well.

I'll see if I can recreate this and work through a solution.

-Ben