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
Jack Poulson
@poulson
Since several people have voiced objections to private chat via Slack, it's probably a good idea that we have a public gitter as well
Jack Poulson
@poulson
I have been thinking that it would be worthwhile to change the README to give a tour of some of the unique functionality in the library (e.g., computing and displaying pseudospectra, fast computation of nonsymmetric eigenvectors, lattice reduction of complex bases via BKZ, and arbitrary-precision sparse Second-Order Cone Programs)
Jeff Hammond
@jeffhammond
I don't care about Gitter vs Slack but support the idea of using what the community wants. It's hard for me to keep track of all these different channels, but if you (Jack) can do it, more power to you.
Jed Brown
@jedbrown
I also don't particularly care about Gitter vs Slack, though I find Gitter to be a bit lighter weight and like openness. But I do think that having too many mechanisms just causes dilution, reducing the chance that people will connect and find the community vibrant and supportive. But I'm not very active with Elemental so this comment shouldn't carry much weight.
Jack Poulson
@poulson
Sayan was very opposed (and there have been numerous blog posts lamenting open source projects going publicly dark because of internal slack comms)
So don't feel like you need to poll this medium; it is targeted at people perusing github that have a question
Jack Poulson
@poulson
TIL about HBR and the Chatham House Rules
There is a lot to be said for HBR avoiding a sense of "us" vs. "them"
Jeff Hammond
@jeffhammond
Does HBR require Jack to log his internal monologue while developing Elemental? The "no private (substantive) discussions" clause of HBR may place an undue burden upon projects that have a small number (especially one) of contributors. Specific to me, do Sayan and I have to publicly document every substantive design discussion we had about RMAxpy for a related pull request to be in compliance with HBR?
Jack Poulson
@poulson
I think HBR is meant to be more of a guiding principle than a hard rule.
Jed Brown
@jedbrown
Yeah, I think it's a very rare project for which a strict HBR is necessary/desirable. But the principle that not just decisions but also the data used to justify the decisions take place in a public forum is important if you want a community to feel open and a meritocracy in which anyone can influence decisions to the extent they bring solid data and rationale to the discussion. If you want community members (that may be developers or future developers) to feel disenfranchised, just make decisions in private and wave your hands about private information. Note that many users may be fine with this approach; they need only trust that you know what you're doing and have all the information. But it stifles the kind of thinking and curiosity that fuels an active and enticing developer community.
Jack Poulson
@poulson
In the spirit of HBR, the next major step that I'm planning in finishing the development of the Aggressive Early Deflation Schur decomposition in https://github.com/elemental/Elemental/blob/47489373a0f632e48935af81ab4533b4ee08ccce/tests/lapack_like/HessenbergEig.cpp
Jack Poulson
@poulson
The callstack maintenance has just been greatly improved and simplified via the usage of a macro DEBUG_CSE which creates a CallStackEntry via DEBUG_ONLY(CallStackEntry cse(EL_FUNCTION)), where EL_FUNCTION maps to __PRETTY_FUNCTION__ if it is available and __func__ otherwise: elemental/Elemental@bc0cb4a
Jack Poulson
@poulson
Aggressive Early Deflation is now very nearly working for real matrices: elemental/Elemental@14a7d57
Jack Poulson
@poulson
Functioning and merged: elemental/Elemental#148
Jack Poulson
@poulson
Control structures were just introduced for the Hessenberg QR algorithm implementations and the source code for it is now pretty well organized: elemental/Elemental@1fc9c94
Jack Poulson
@poulson
Both real and complex AED now give correct answers (but are not yet optimized): elemental/Elemental@7cddfc7
Jack Poulson
@poulson
The real and complex sequential AED implementations are now incorporated under the name HessenbergSchur in the library: elemental/Elemental@a95d621
Jack Poulson
@poulson
A generic implementation of QL/QR iteration for the real symmetric tridiagonal EVP is now also well underway: elemental/Elemental@7919c6f
Jack Poulson
@poulson
the generic/arbitrary-precision symmetric tridiagonal QR algorithm is now functioning: elemental/Elemental@9f6a95d
Jack Poulson
@poulson
The interfaces to HermitianEig and HermitianGenDefEig now support all of El's datatypes: elemental/Elemental@9d29be3
Jeff Hammond
@jeffhammond
Jack: If you want to automate testing with the Intel toolchain, https://github.com/nemequ/icc-travis (https://github.com/jeffhammond/icc-travis) has details. I will try to work up a PR...
Jack Poulson
@poulson
That would be awesome. It has been a common point of failure recently
Jack Poulson
@poulson
The SVD implementation was just significantly extended: elemental/Elemental@1390194
(there is now sequential and distributed arbitrary-precision SVD via a custom bidiagonal QR algorithm implementation in the style of Demmel and Kahan's hybrid zero-shift approach)
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?