August 2012 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] clique
by Jed Brown 31 Aug '12

31 Aug '12

On Fri, Aug 31, 2012 at 4:59 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > On Fri, Aug 31, 2012 at 4:49 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > >> On Fri, Aug 31, 2012 at 4:17 PM, Jack Poulson <jack.poulson(a)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. >> > > I believe its The Right Way@ (copyright Barry Smith 1995). > Nope, it's a sleeper patent. The plan is to wait until enough corporations with money use this patented innovation, then sue them for billions. American Innovation at work.

1 0

Re: [petsc-dev] clique
by Matthew Knepley 31 Aug '12

31 Aug '12

On Fri, Aug 31, 2012 at 4:49 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Fri, Aug 31, 2012 at 4:17 PM, Jack Poulson <jack.poulson(a)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. > I believe its The Right Way@ (copyright Barry Smith 1995). 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(a)mcs.anl.gov> wrote: >> >>> On Fri, Aug 31, 2012 at 3:17 PM, Jack Poulson <jack.poulson(a)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(a)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(a)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

1 0

Re: [petsc-dev] clique
by Jed Brown 31 Aug '12

31 Aug '12

On Fri, Aug 31, 2012 at 4:17 PM, Jack Poulson <jack.poulson(a)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. > > 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(a)mcs.anl.gov> wrote: > >> On Fri, Aug 31, 2012 at 3:17 PM, Jack Poulson <jack.poulson(a)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(a)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(a)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 >>>>> > >>>>> >>>>> >>> >> >

1 0

Re: [petsc-dev] clique
by Jack Poulson 31 Aug '12

31 Aug '12

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. 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. 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(a)mcs.anl.gov> wrote: > On Fri, Aug 31, 2012 at 3:17 PM, Jack Poulson <jack.poulson(a)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(a)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(a)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 >>>> > >>>> >>>> >> >

1 0

Re: [petsc-dev] clique
by Jed Brown 31 Aug '12

31 Aug '12

On Fri, Aug 31, 2012 at 3:17 PM, Jack Poulson <jack.poulson(a)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(a)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(a)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 >>> > >>> >>> >

1 0

Re: [petsc-dev] components in PetscSection
by Matthew Knepley 31 Aug '12

31 Aug '12

On Fri, Aug 31, 2012 at 3:52 PM, Chris Eldred <chris.eldred(a)gmail.com>wrote: > Ok- so if I have a multicomponent field, I should define the number of > dofs at a point for that field to be the total number of dofs I want > for that field. Ex a 2 component field with 2 dofs per component > should have 4 dofs defined, not 2. Num components just serves to give > additional info about the field but it is not used in defining or > manipulating the PetscSection. Yes. Matt > On Fri, Aug 31, 2012 at 2:29 PM, Matthew Knepley <knepley(a)gmail.com> > wrote: > > On Fri, Aug 31, 2012 at 1:04 PM, Chris Eldred <chris.eldred(a)gmail.com> > > wrote: > >> > >> I was wondering how components were treated in PetscSection- my > >> understanding is that a field with multiple components and multiple > >> dofs would have those dofs duplicated for each component, but that > >> does not appear to be the case. For example, let's say I have a field > >> with 2 components and 2 dofs that covers 10 points. I expected that it > >> would have size 40: 4 dofs per point x 10 points. Instead, it appears > >> to have size 20: 2 dofs x 10 pts. > > > > > > Yep, that is not the case. What if the components are discretized with > > different numbers of dofs on different points? This definitely happens. > > > >> > >> What then are components in PetscSection- is it just a way of telling > >> the code that the dofs associated with a field at a point are really > >> split across multiple components (ie for my example, I should define 4 > >> dofs at each pt instead of 2)? How does that then interact with the > >> re-ordering done in DMComplexVecGetClosure? > > > > > > The idea of components is to give you an idea what kind of field you are > > dealing with. I know I don't go so far as to tell you its a vector, or a > > pseudo-vector, etc. I am not sure where to draw the line yet. Within > > GetClosure(), the dofs for reversed points are separately reversed per > > component. > > > > Matt > > > >> > >> > >> -- > >> Chris Eldred > >> DOE Computational Science Graduate Fellow > >> Graduate Student, Atmospheric Science, Colorado State University > >> B.S. Applied Computational Physics, Carnegie Mellon University, 2009 > >> chris.eldred(a)gmail.com > > > > > > > > > > -- > > 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 > > > > -- > Chris Eldred > DOE Computational Science Graduate Fellow > Graduate Student, Atmospheric Science, Colorado State University > B.S. Applied Computational Physics, Carnegie Mellon University, 2009 > chris.eldred(a)gmail.com > -- 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

1 0

Re: [petsc-dev] components in PetscSection
by Chris Eldred 31 Aug '12

31 Aug '12

Ok- so if I have a multicomponent field, I should define the number of dofs at a point for that field to be the total number of dofs I want for that field. Ex a 2 component field with 2 dofs per component should have 4 dofs defined, not 2. Num components just serves to give additional info about the field but it is not used in defining or manipulating the PetscSection. On Fri, Aug 31, 2012 at 2:29 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > On Fri, Aug 31, 2012 at 1:04 PM, Chris Eldred <chris.eldred(a)gmail.com> > wrote: >> >> I was wondering how components were treated in PetscSection- my >> understanding is that a field with multiple components and multiple >> dofs would have those dofs duplicated for each component, but that >> does not appear to be the case. For example, let's say I have a field >> with 2 components and 2 dofs that covers 10 points. I expected that it >> would have size 40: 4 dofs per point x 10 points. Instead, it appears >> to have size 20: 2 dofs x 10 pts. > > > Yep, that is not the case. What if the components are discretized with > different numbers of dofs on different points? This definitely happens. > >> >> What then are components in PetscSection- is it just a way of telling >> the code that the dofs associated with a field at a point are really >> split across multiple components (ie for my example, I should define 4 >> dofs at each pt instead of 2)? How does that then interact with the >> re-ordering done in DMComplexVecGetClosure? > > > The idea of components is to give you an idea what kind of field you are > dealing with. I know I don't go so far as to tell you its a vector, or a > pseudo-vector, etc. I am not sure where to draw the line yet. Within > GetClosure(), the dofs for reversed points are separately reversed per > component. > > Matt > >> >> >> -- >> Chris Eldred >> DOE Computational Science Graduate Fellow >> Graduate Student, Atmospheric Science, Colorado State University >> B.S. Applied Computational Physics, Carnegie Mellon University, 2009 >> chris.eldred(a)gmail.com > > > > > -- > 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 -- Chris Eldred DOE Computational Science Graduate Fellow Graduate Student, Atmospheric Science, Colorado State University B.S. Applied Computational Physics, Carnegie Mellon University, 2009 chris.eldred(a)gmail.com

1 0

Re: [petsc-dev] components in PetscSection
by Matthew Knepley 31 Aug '12

31 Aug '12

On Fri, Aug 31, 2012 at 1:04 PM, Chris Eldred <chris.eldred(a)gmail.com>wrote: > I was wondering how components were treated in PetscSection- my > understanding is that a field with multiple components and multiple > dofs would have those dofs duplicated for each component, but that > does not appear to be the case. For example, let's say I have a field > with 2 components and 2 dofs that covers 10 points. I expected that it > would have size 40: 4 dofs per point x 10 points. Instead, it appears > to have size 20: 2 dofs x 10 pts. > Yep, that is not the case. What if the components are discretized with different numbers of dofs on different points? This definitely happens. > What then are components in PetscSection- is it just a way of telling > the code that the dofs associated with a field at a point are really > split across multiple components (ie for my example, I should define 4 > dofs at each pt instead of 2)? How does that then interact with the > re-ordering done in DMComplexVecGetClosure? The idea of components is to give you an idea what kind of field you are dealing with. I know I don't go so far as to tell you its a vector, or a pseudo-vector, etc. I am not sure where to draw the line yet. Within GetClosure(), the dofs for reversed points are separately reversed per component. Matt > > -- > Chris Eldred > DOE Computational Science Graduate Fellow > Graduate Student, Atmospheric Science, Colorado State University > B.S. Applied Computational Physics, Carnegie Mellon University, 2009 > chris.eldred(a)gmail.com > -- 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

1 0

Re: [petsc-dev] clique
by Jack Poulson 31 Aug '12

31 Aug '12

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? 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... Jack On Fri, Aug 31, 2012 at 2:28 PM, Jed Brown <jedbrown(a)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(a)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 >> > >> >>

1 0

Re: [petsc-dev] clique
by Jack Poulson 31 Aug '12

31 Aug '12

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(a)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(a)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(a)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 >>> > >>> >>> >

1 0