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
Ryan H. Lewis
@rhl-
Why not just maintain a vector of them then?
Jack Poulson
@poulson
no, various distributed data structures need different El::Grid instances over different sets of processes
maintain an std::vector of them where? and on which processes?
Ryan H. Lewis
@rhl-
Maybe im misunderstanding but it sounds like in the distmatrix
Or whatever is supposed to hold the lifetime of the grids
Based on your last sentence it sounds like a distributed data structure has a member which represents multiple grids
I would still use move semantics to move generated grids into that vector
Jack Poulson
@poulson
an El::DistMatrix currently holds a single const El::Grid*
Ryan H. Lewis
@rhl-
Yeah, I propose replace with vector<Grid>
Jack Poulson
@poulson
the distributed sparse-direct solvers involve trees of distributed matrices over different subsets of processes, and each requires a potentially different El::Grid pointer
Ryan H. Lewis
@rhl-
Or maybe some other container depending on your needs
Jack Poulson
@poulson
using a flat data structure for the El::Grid's for the sparse-direct solvers would eliminate all of the niceness of using recursive implementations to traverse the trees
what is your aversion to std::unique_ptr?
Ryan H. Lewis
@rhl-
Can you share a link to some code so I can grok?
Jack Poulson
@poulson
see, e.g., elemental/Elemental@75c5f5a
Ryan H. Lewis
@rhl-
I mean why do you need a unique_ptr, it seems like you just need to move some grids around
Jack Poulson
@poulson
and elemental/Elemental@69b6eb8 for the El::Grid change
Ryan H. Lewis
@rhl-
Be back in a bit. On a plane :) taking off
Jack Poulson
@poulson
Comments welcome! elemental/Elemental#214
Jack Poulson
@poulson
the sparse-direct interface shouldn't be so laughably complicated anymore
Ryan H. Lewis
@rhl-
I'm without a laptop this week. Just have a phone
I can review but it would require Waiting until Jan 1
Jack Poulson
@poulson
no worries
the improvement in the interface is substantial enough that it will be worth merging once the dust settles (probably in several more days)
Jack Poulson
@poulson
It seems someone removed the links to Elemental on the Wikipedia pages for permissively licensed LP, QP, and SOCP solvers :-(
also, I am bundling in a Mathematical Programming Software (MPS) reader in the sparse-direct changeset
easily checking that one gets the same results as http://www.netlib.org/lp/data/minos is useful
Ryan H. Lewis
@rhl-
Why did they remove elemental ?
Jack Poulson
@poulson
they removed all open source links
Carlos Borges
@cecborges_twitter
Hi Jack, are there any plans to include GMRES or any other iterative solvers in Elemental?
Jack Poulson
@poulson
there is a GMRES in Elemental
it just isn't documented yet I think
it is heavily used within Elemental's Interior Point Methods
see include/El/solve/FGMRES.hpp for the flexible GMRES implementation
and include/El/solve/LGMRES.hpp for the left-preconditioned standard GMRES
with that said, the iterative solvers in the library have only existed to the point that they were needed for the more "direct" techniques like the IPMs
not that I am opposed to the iterative solvers improving
Jack Poulson
@poulson
Hmm, it seems that the Clang bug response time is not so impressive :-( https://llvm.org/bugs/show_bug.cgi?id=31249
Carlos Borges
@cecborges_twitter
Thanks for the response. I didn't see it in any of the available documentation. It is good to know. Best
Jack Poulson
@poulson
@cecborges_twitter The documentation is currently very behind due to many recent changes to the IPMs, sparse-direct solvers, etc.
Carlos Borges
@cecborges_twitter
@poulson Thanks for letting me. I noticed that you have LSQR implemented using matrices as input, do you have plans to implement it using functions as input?
Jack Poulson
@poulson
I don't recall committing LSQR
do you have a link?
Carlos Borges
@cecborges_twitter
isn't your least squares function implementing LSQR? I thought I read that somewhere. Maybe I am wrong.
Jack Poulson
@poulson
LeastSquares uses Flexible GMRES with the preconditioner being an iteratively-refined application of a sparse-direct solution to a nearby quasi-semidefinite problem
there is a note that Michael Saunders tends to use LSQR for this rather than FGMRES
I like GMRES(k) and FGMRES(k)
Carlos Borges
@cecborges_twitter
ah ok. my bad, I saw lsqr there and I thought that the implementation was using it. Sorry about that. But anyway, do you plan to implement LSQR using functions as input?
Jack Poulson
@poulson
it would be nice but isn't in my critical path right now
I'm in the middle of refactoring the IPMs