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)
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.
So don't feel like you need to poll this medium; it is targeted at people perusing github that have a question
There is a lot to be said for HBR avoiding a sense of "us" vs. "them"
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?
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.
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
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: 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...
(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)
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?
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
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?
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)