[petsc-dev] clique

Fri Aug 31 16:59:20 CDT 2012

On Fri, Aug 31, 2012 at 4:49 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> On Fri, Aug 31, 2012 at 4:17 PM, Jack Poulson <jack.poulson at gmail.com>wrote:
>
>> In these cases, it sounds like the current best option is then to avoid
>> using the CMake build system and manually link Elemental and Clique. If you
>> have any suggestions, I am happy to work towards them as soon as possible.
>>
>> Satish's suggestion (which I agree with) is for me to add support in
>> Clique's CMake build system for a user-specified Elemental library.
>>
>
> I think this the Right Way.
>

   Matt

>
>
>>
>> Yet another option is to avoid having any libelemental.a/libclique.a at
>> all. There is very little in it anyway, as well over 99% of both libraries
>> are in header files.
>>
>
> I'm not a fan of the rampant duplication implied by header-only, but do as
> you like.
>
> Note that elemental/config.h is somewhat concerning because if any part of
> the configuration is different (even for matching versions), you can have
> duplicate symbols with different implementations. The linker is free to
> take any implementation from anywhere. This can cause tricky run-time bugs
> such as the version used to allocate being different from the version used
> to deallocate.
>
>
>>
>> Would you find this more convenient? If so, I am willing to make the
>> transition.
>>
>> Jack
>>
>>
>> On Fri, Aug 31, 2012 at 4:12 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>>
>>> On Fri, Aug 31, 2012 at 3:17 PM, Jack Poulson <jack.poulson at gmail.com>wrote:
>>>
>>>> I seemed to have ignored your question.
>>>>
>>>> If compatible versions of the library are used in package "X", then
>>>> everything should work fine. Is there a problem which you are expecting?
>>>>
>>>
>>> Well, we may have duplicate symbols if we link an "equivalent" library
>>> twice. If we do as CMake does, the full path for the different
>>> libelemental.a will be passed to the linker.
>>>
>>>
>>>> I recognize that there is a potential issue of a newer version of
>>>> Elemental or Clique conflicting with an older version, but  surely you guys
>>>> are willing to deal with external libraries also changing their syntax from
>>>> time to time...
>>>
>>>
>>> I'm not concerned about version mismatch because that is an issue
>>> regardless of distribution if both libs are linked into the same
>>> executable. It's the duplicate symbols that bother me.
>>>
>>>
>>>>
>>>> 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
>>>>>> >
>>>>>>
>>>>>>
>>>>
>>>
>>
>

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120831/1f11c8f8/attachment.html>