Loading ...
Sorry, an error occurred while loading the content.

Re: [ublas-dev] Re: LAPACK eigenvalue solver bindings

Expand Messages
  • Matthias Troyer
    Hi Andreas, I am still working on other porting problems of our applications and did thus not find the time to finish testing and documentation of the bindings
    Message 1 of 12 , Oct 31, 2003
    • 0 Attachment
      Hi Andreas,

      I am still working on other porting problems of our applications and
      did thus not find the time to finish testing and documentation of the
      bindings for the syev and heev routines that I need most often, and
      thus kept the additional files with our ALPS project sources
      (httP://alps.comp-phys.org/). I have attached them to this mail for
      your or anybody else's use. I will not be able to bring them into shape
      for a ublas submission this year because I'm busy preparing a new
      course on high performance computing in C++, and that takes up all my
      spare time.

      Best regards

      Matthias

      On Oct 31, 2003, at 3:44 PM, groenewoudse wrote:

      > Hi Mattias,
      >
      > I just joined the list and I am interested in these ZGEEV and ZHEEV
      > bindings. I could not find them in the bindings_2003_09_11.zip
      > under "Files". Did you already implement these bindings?
      > Is it possible to obtain them from you?
      >
      > Thanks a lot ,

      > Andreas
      >
      >
    • Karl Meerbergen
      ... Hi Mattias, I am also working on blas and lapack bindings. I was wondering how you handle workspace. I have written bindings for gees, steqr and a few
      Message 2 of 12 , Nov 2, 2003
      • 0 Attachment
        Matthias Troyer wrote:

        >Hi Andreas,
        >
        >I am still working on other porting problems of our applications and
        >did thus not find the time to finish testing and documentation of the
        >bindings for the syev and heev routines that I need most often, and
        >thus kept the additional files with our ALPS project sources
        >(httP://alps.comp-phys.org/). I have attached them to this mail for
        >your or anybody else's use. I will not be able to bring them into shape
        >for a ublas submission this year because I'm busy preparing a new
        >course on high performance computing in C++, and that takes up all my
        >spare time.
        >
        >Best regards
        >
        >Matthias
        >
        >On Oct 31, 2003, at 3:44 PM, groenewoudse wrote:
        >
        >
        >
        >>Hi Mattias,
        >>
        >>I just joined the list and I am interested in these ZGEEV and ZHEEV
        >>bindings. I could not find them in the bindings_2003_09_11.zip
        >>under "Files". Did you already implement these bindings?
        >>Is it possible to obtain them from you?
        >>
        >>Thanks a lot ,
        >>
        >>
        >
        >
        >
        >>Andreas
        >>
        >>
        >>
        >>
        >
        >
        >To unsubscribe from this group, send an email to:
        >ublas-dev-unsubscribe@yahoogroups.com
        >
        >
        >
        >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        >
        >
        >

        Hi Mattias,

        I am also working on blas and lapack bindings.
        I was wondering how you handle workspace.
        I have written bindings for gees, steqr and a few other specialized
        routines that I need.
        In order to properly handle workspace I use an extra argument whose type
        decides how the workspace is allocated:
        for example:
        gees( a, e, vs, optimal_workspace() ) allocates memory dynamically with
        the optimal size
        gees( a, e, vs, minimal_workspace() ) allocates memory dynamically with
        the minimal size
        gees( a, e, vs, workspace( work ) ) uses the array work for the real case
        gees( a, e, vs, workspace( work, rwork ) ) uses the arrays work and
        rwork for the complex case.

        We should have a discussion on standardization of the bindings. I also
        discussed this with Kresimir.

        Best,

        Karl
      • groenewoudse
        Hi Mattias, thanks a lot for your files, I will have a look at them and will try to do my first steps with ublas. Until now I have been using a quite old
        Message 3 of 12 , Nov 3, 2003
        • 0 Attachment
          Hi Mattias,

          thanks a lot for your files, I will have a look at them and will try
          to do my first steps with ublas. Until now I have been using a
          quite old version of the TNT in combination with Fortran lapack.

          All the best,

          Andreas

          ----- Matthias wrote:
          > Hi Andreas,
          >
          > I am still working on other porting problems of our applications
          and
          > did thus not find the time to finish testing and documentation of
          the
          > bindings for the syev and heev routines that I need most often,
          and
          > thus kept the additional files with our ALPS project sources
          > (httP://alps.comp-phys.org/). I have attached them to this mail for
          > your or anybody else's use. I will not be able to bring them into
          shape
          > for a ublas submission this year because I'm busy preparing a
          new
          > course on high performance computing in C++, and that takes up
          all my
          > spare time.
          >
          > Best regards
          >
          > Matthias
        • Karl Meerbergen
          Hi, Suppose I have a number of sparse matrices with the same sparsity pattern. Is there an easy way to share the pattern data among these matrices without
          Message 4 of 12 , Jan 20, 2004
          • 0 Attachment
            Hi,

            Suppose I have a number of sparse matrices with the same sparsity
            pattern. Is there an easy way to share the pattern data among these
            matrices without duplication? This situation occurs in some finite
            element problems and also in some preconditioners. The major motivation
            is to save memory.

            Thanks,

            Karl
          • Michael Stevens
            Hi Karl, ... This seems to be a farily common requirement. I think I am correct in saying there is no direct support in uBLAS. It may be possible to reuse a
            Message 5 of 12 , Jan 20, 2004
            • 0 Attachment
              Hi Karl,

              >
              > Suppose I have a number of sparse matrices with the same sparsity
              > pattern. Is there an easy way to share the pattern data among these
              > matrices without duplication? This situation occurs in some finite
              > element problems and also in some preconditioners. The major motivation
              > is to save memory.
              >
              This seems to be a farily common requirement. I think I am correct in
              saying there is no direct support in uBLAS.

              It may be possible to reuse a lot of the existing storage code for the
              coordinate and compressed matrices to get the desired effect. It would
              be interesting if anyone else has looked at implmenting this.
              --
              Michael
            • Peter Schmitteckert
              Dear Karl, ... In my application I have the same problem. What I did, is to create my own matrix class which contails a list of pointers to matrices and an
              Message 6 of 12 , Jan 21, 2004
              • 0 Attachment
                Dear Karl,

                On 20 Jan 2004, Karl Meerbergen wrote:

                > Suppose I have a number of sparse matrices with the same sparsity
                > pattern. Is there an easy way to share the pattern data among these
                > matrices without duplication? This situation occurs in some finite
                > element problems and also in some preconditioners. The major motivation
                > is to save memory.

                In my application I have the same problem.
                What I did, is to create my own matrix class which
                contails a list of pointers to matrices and an additional
                prefactor, e.g.

                class TpEntry
                {
                double Scalar;
                TpMatrix* pMAtrix;
                }

                class MyMatrix
                {

                list<TpEntry> lstMatrices;
                // ...
                }


                In MyMatrix I dispatch all the work I have to
                do in loops over the matrix-list, e.g.

                for( list<TpEntry>::iterator = ... )
                it->Scalar * (* it->pMatrix) * ....


                The actual Matrices are stored outside the class.

                Im principle this is just a decomposition of my matrix
                in a sum of building matrices.

                However, my implementation has to deal with a more
                complicated layout which is special to my problem.
                Therefore I have not attempted to make my code
                usable for ublas.

                Best wishes,
                Peter
              Your message has been successfully submitted and would be delivered to recipients shortly.