[petsc-dev] clique

[Jack Poulson]

Jed,

I have made the current interface slightly more general by only requiring
the usage of the build directory header files in the case that a user has
used Sean's TLS patch:
https://github.com/poulson/Clique/blob/master/CMakeLists.txt#L48

Since there are clearly at least _some_ patches required for (Par)MeTiS, I
propose that PETSc standardize on one (which can hopefully incorporate my
additions for nodal bisection, though I assume that you will want to change
the routine names to something other than CliqBisect and
CliqParallelBisect).

Jack

On Fri, Aug 31, 2012 at 2:35 PM, Jack Poulson <jack.poulson at gmail.com>wrote:

> Jed,
>
> I completely agree that it is a nightmare. All that I want is (parallel)
> nodal bisection. Right now, the best solution is to create two trivial
> source files:
> https://github.com/poulson/Clique/blob/master/src/parmetis/ParallelBisect.c
> https://github.com/poulson/Clique/blob/master/src/metis/Bisect.c
> which I removed them from the ParMeTiS source tree upon request.
>
> It seems that, given the nightmare of forcing the user to provide me with
> the directory containing their ParMeTiS thread-local support configuration
> file, that I should just modify the symbol names of the ParMeTiS routines
> which I include with Clique. This should fix all of the problems.
>
> Jack
>
>
> On Fri, Aug 31, 2012 at 2:28 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
>> Jack, this bundling strategy is a distribution nightmare. Suppose that
>> some other package "X" independent of clique also bundles Elemental. How
>> does an application (or another library) use both X and clique?
>>  On Aug 31, 2012 1:49 PM, "Satish Balay" <balay at mcs.anl.gov> wrote:
>>
>>> Should have cc:d to petsc-dev
>>>
>>> context:
>>>
>>> clique packages metis,parmetis,elemental sources in a single bundle.
>>> So we were attempting to build them separately [from petsc configure].
>>>
>>> Jack has extensions to metis and parmetis functionality - thats used
>>> in clique. We tried to split this out into separate -lparmetis-addons
>>> library [using parmetis public includes] so that our current
>>> -lparmetis could be used.  But this doesn't work as it needs parmetis
>>> private includes.
>>>
>>> So looks like we'll have to add these extensions to the metis/parmetis
>>> tarballs we distribute [and have common metis/parmetis sources
>>> available for both petsc an clique]
>>>
>>> Satish
>>>
>>> On Fri, 31 Aug 2012, Satish Balay wrote:
>>>
>>> > On Fri, 31 Aug 2012, Satish Balay wrote:
>>> >
>>> > > On Fri, 31 Aug 2012, Jack Poulson wrote:
>>> > >
>>> > > > > Also does clique also build elemental? Can we split it up aswell
>>> with
>>> > > > > MANUAL_ELEMENTAL, ELEMENTAL_INCLUDE_DIR, ELEMENTAL_LIBS options?
>>> > > > >
>>> > > > >
>>> > > > I will take care of all of these issues as soon as I get a chance.
>>> Clique
>>> > > > does currently build Elemental (it sits in external/elemental). If
>>> both
>>> > > > Clique and Elemental are both to be used in the same package, I
>>> would think
>>> > > > it would make sense to just install Clique and use its version of
>>> > > > Elemental. Is there a problem with this approach? It ensures
>>> compatibility.
>>> > >
>>> > > I'll have to check this - but 2 ways of building the same thing is
>>> not
>>> > > easy in petsc build tools. Esp when we provide --with-elemental-dir
>>> > > option to configure.
>>> > >
>>> > > Sure we'll have to make sure the compatible elemental,clique are
>>> > > installed - when both are installed by petsc [or by user]
>>> >
>>> > Jack,
>>> >
>>> > [I'm having to add the flag BUILD_PARMETIS=0.] But now I get:
>>> >
>>> > cd /home/balay/spetsc/externalpackages/clique/arch-clique/src/parmetis
>>> && /usr/lib64/ccache/gcc   -Wall -Wwrite-strings -Wno-strict-aliasing
>>> -Wno-unknown-pragmas -g3 -fno-inline -O0
>>> -I/home/balay/spetsc/externalpackages/clique/arch-clique/external/elemental/include
>>> -I/home/balay/soft/linux64/mpich2-1.1/include
>>> -I/home/balay/spetsc/arch-clique/include
>>> -I/home/balay/spetsc/externalpackages/clique/external/parmetis/include
>>> -I/home/balay/spetsc/externalpackages/clique/external/parmetis/libparmetis
>>> -I/home/balay/spetsc/externalpackages/clique/external/parmetis/metis/GKlib
>>> -I/home/balay/spetsc/externalpackages/clique/external/parmetis/metis/include
>>>    -o CMakeFiles/parmetis-addons.dir/ParallelBisect.c.o   -c
>>> /home/balay/spetsc/externalpackages/clique/src/parmetis/ParallelBisect.c
>>> >
>>> /home/balay/spetsc/externalpackages/clique/src/parmetis/ParallelBisect.c:5:25:
>>> fatal error: parmetislib.h: No such file or directory
>>> >
>>> > Looks like this code needs parmetis private includes. So the current
>>> > stratergy [of splitting into -lparmetis-addons] isn't working.
>>> >
>>> > Perhaps we'll have to use a single patched metis/parmetis tarball for
>>> > both petsc and clique afterall..
>>> >
>>> > Satish
>>> >
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120831/21acbee6/attachment.html>