Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • May 14 01:33
    poulson closed #276
  • May 14 01:33
    poulson commented #276
  • May 14 01:30

    poulson on master

    Update README.md (compare)

  • May 14 01:24

    poulson on master

    added logo (compare)

  • May 10 21:37
    jedbrown commented #276
  • May 10 21:25
    poulson commented #276
  • May 10 21:21
    jedbrown commented #276
  • May 10 17:08
    poulson commented #276
  • May 10 17:03
    tesch1 opened #276
  • Apr 10 13:18
    JM1 commented #275
  • Apr 10 13:16
    JM1 synchronize #275
  • Apr 10 08:56
    JM1 opened #275
  • Mar 06 03:47
    Raviteja1996 closed #274
  • Mar 05 05:46
    Raviteja1996 opened #274
  • Feb 11 21:53
    BenBrock commented #228
  • Feb 11 21:52
    BenBrock commented #228
  • Feb 11 21:51
    poulson commented #228
  • Feb 11 21:50
    poulson commented #228
  • Feb 11 21:45
    BenBrock commented #228
  • Jan 23 23:57
    adambaskerville commented #273
Yves Ineichen
@iff
Hi all. In order to facilitate our libSkylark build process we were looking into ways to provide an Elemental deb package. One very simple way is to let CMake/CPack take care of that and Travis to build different variations (MPI flavours etc).
One issue that arises is wrt to the external dependencies, i.e. the patched ParMETIS. The Elemental package depends on this specific version but it would not be proper to just ship the lib in the Elemental package (conflict with i.e. Ubuntu provided ParMETIS package). The cleanest approach would be to package all the dependencies as well and put the constraints for that in the Elemental deb information. All these packages could be pushed to ppa. Any opinions/suggestions how this issue can be resolved?
Jack Poulson
@poulson
Thanks Yves!
One constraint is that El depends on an extension of ParMETIS
With that said, most users probably would be fine with just the METIS wrappers
I used to have the ParMETIS extension in El and hooked into the ParMETIS internal API, but that caused its own problems
The nuclear option is to rensme the parmetis symbols
Yves Ineichen
@iff
Relying on METIS would be fine, as far as I see we can just put the Ubuntu package (libmetis-dev) as a dependency and use -DEL_DISABLE_PARMETIS=ON.. I guess that decision is up to you (I have no preference either way, but this approach is easier to implement).
The dependencies I currently use for the package are set(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>= 2.3.1-6), libgcc1 (>= 1:3.4.2-12), libgomp1, mpich, libmpich-dev, libopenblas-dev, liblapack-dev, python-numpy, libmetis-dev") (for the mpich package)
One remaining test is to check if libscalapack-mpi-dev is comparable to the version you pull when building Elemental (?).. Are there any other dependencies we are missing?
Jack Poulson
@poulson
Thanks, I think depending on libmetis-dev for now is a good idea; I can leave either adding a prefix to my parmetis modifications or waiting for the long shot of Karypis incorporating the changes I sent later.
As for ScaLAPACK: I fixed a bug in their Aggressive Early Deflation Schur decomposition
and this is the one routine Elemental currently makes use of
(though there are wrappers for benchmarking purposes for several other routines)
So depending upon libscalapack-dev is unfortunately not an option
It would be good to have the MPFR and MPC dependencies, as well as QD
(Everything except for the distributed Schur decomposition now supports float, double, DoubleDouble, QuadDouble, Quad, BigFloat, and their complex variants)
Yves Ineichen
@iff
so ScaLAPACK is the only dependency that does not exist as pre-packaged deb?
Jack Poulson
@poulson
Other than ParMETIS, yes
Yves Ineichen
@iff
ah so I maybe misunderstood: you want a package with -DEL_DISABLE_PARMETIS=ON or package ParMETIS yourself?
Jack Poulson
@poulson
For now the former would be better. Otherwise we need to change the parmetis symbols. Also, parmetis is more restricted with respect to distribution rights
Yves Ineichen
@iff
Ok. So do you expect us to look into the ScaLAPACK packaging?
Jack Poulson
@poulson
Only if you want the package to support distributed Schur decompositions, nonsymmetric eigensolvers, and pseudospectra
I'm in the middle of putting together a Divide and Conquer SVD and can provide guidance but my hands are somewhat full at the moment
Yves Ineichen
@iff
Well we dont use that in libSkylark at the moment (asfaik). The question is more what you would like to see in the merge request. Currently we have a package without ParMETIS that works for us (building libSkylark that is) based on 71fce6e65c065e0b2f993435ca7524db7f54fa6f (which is the latest supported version from the libSkylark side)
To facilitate the build process (users, feasible travis-ci build times) we would appreciate an Elemental deb package at the earliest convenience ;)
Jack Poulson
@poulson
We could disable the Aggressive Early Deflation for now
I can try to come up with a workaround
in fact, it might be disable by default because of lingering bugs
so I would say that using the prepackaged ScaLAPACK lib should be fine as long as it uses a compatible MPI
Ryan H. Lewis
@rhl-
@iff Hi, I am also interested in packaging Elemental for my purposes. I would like to do so with RPM packages though. I would be happy to collaborate to the extend that this is possible. You also should look at conan for c++ packages.
Jack Poulson
@poulson
More reason to package up Elemental I suppose: https://github.com/cvxgrp/cvxpy/issues/288#issuecomment-234671685
Yves Ineichen
@iff
@rhl- Hey Ryan, CPack also offers a way to create rpms. I can provide some pointers if you like. I have no experience with conan (IMO we should avoid additional dependencies)
Jack Poulson
@poulson
There is now a SecularSVD routine: elemental/Elemental@3712952
Jack Poulson
@poulson
Next up: a full D&C SVD
Ryan H. Lewis
@rhl-
@iff conan is not a dependency, it is a package manager for c++, and really a great thing. also, CPack sucks. yes you can create RPM's but no one will accept them to a real repo. You need to write an RPM Spec file or something. That is something you could compose with conan, since conanfile's, rpm spec, and deb package are all very similar. the way to think of conan, is it provides "rpm packages" which do not fix compiler versions or types.
Jack Poulson
@poulson
@rhl- It would be helpful if there was an example. The devil is often in the details with these things (as it is for CPack).
Yves Ineichen
@iff
@rhl- super, if you can package Elemental with conan even better. I know CPack has limitations, but its the only thing I know. I simply cannot spend time and dig into conan (or other solutions) to understand the details and package Elemental. Thats why we offered a CPack based solution.
Ryan H. Lewis
@rhl-
@jack happy to do that, what example do you want? of using spec files? I have plenty: https://rhl.fedorapeople.org/
@iff I am new to conan too, but, I am betting on that technology. CPack is a good start, it generates rpm's that don't pass most basic rpmlint violations. I'm happy to collaborate on this. I think the main thing is not elemental, but all it's dependencies.
Ryan H. Lewis
@rhl-
I can maintain the fedora packages
I am not a debian packager though.
Jack Poulson
@poulson
I agree that settling on how to handle dependencies is the deeper issue
LAPACK is up on GitHub officially as of this week
Perhaps we can get ScaLAPACK there as well
Metis and ParMetis are hopeless though
My conjecture is that if we iron out dependencies everything else is easy
Ryan H. Lewis
@rhl-
@poulson metis is available in most package managers
lapack is in most package managers