Re: Looking for gen symm sparse eigensolver in C or C++

From: Madhusudan Singh (spammers-go-here_at_spam.invalid)
Date: 03/28/05

  • Next message: Louis Krupp: "Re: Looking for gen symm sparse eigensolver in C or C++" 
    Date: Mon, 28 Mar 2005 12:19:25 -0500

    carlos@colorado.edu wrote:

    >> Returning to your OP, look at arpack++. I have heard that it is
    > written in
    >> C++, but the I do not know how well tested it is. Caveat Emptor.
    >
    >
    > The eigensolver is to be coupled to a volume acoustic analyzer based on
    > C++ libraries. These do mesh generation, ray tracing, graphics, GUI,
    > etc. Target 10^5 to 10^6 freedoms, about 1K-5K eigenmodes needed. The
    > C++ code is there and wont be touched.
    >

    Trying to do the frills (which can all be done in Fortran - gnuplotfortran /
    dislin / winteracter / gino are all tools for this kind of work) in C++
    when the heart of your program is best done in Fortran is a very bad design
    choice to start with. However, as you described, it does not seem that
    logic is a particularly strong consideration for the powers-that-be.

    I wish you the best.

    > Seems like a good fit for arpack or block-lanczos although it is the
    > generalized eigenproblem, not the standard one. Both matrices are
    > singular. arpack++ is a good suggestion; I didnt know it existed.
    > Is it an ongoing project?

    I have no idea. I remember seeing it on an ftp site a long time ago and
    reading a little bit of the README.

    I have never tried it and do not know how well-tested it is (unlike the f77
    arpack library which I used a lot for a while).

    >
    > If only f77 eigensolvers are available, C++/f77 wrappers would be
    > required. That always brings the chance of compiler and library
    > conflicts (e.g. I/O libraries). Intermix conflicts are best avoided if
    > the implementer is proficient in both languages and compilers, but that
    > is not the case here.

    Using Fortran calls in C/C++ code is trivial (I have heard good things about
    cfortran.h), as is using C in Fortran. Calling C++ from Fortran is usually
    messy. As long as you have the latest libc libraries with gcc/g77, I do not
    think it ought to matter. But you obviously know more about your situation
    than the content of your post conveys.

  • Next message: Louis Krupp: "Re: Looking for gen symm sparse eigensolver in C or C++"

    Relevant Pages

    • Re: DFPORT
      ... I work on a Windows XP platform. ... We normally use F77 Fortran and for this one problematic program we ... Since we also have the Intel Fortran compiler, we also had a lot of ... Windows Fortran comper (with appropriate libraries). ...
      (comp.lang.fortran)
    • Re: can somebody verify this C program which calls dsaupd_ ? (longish)
      ... > I compiled two Fortran libs separately. ... One ARPACK and the other BLAS. ... > makefiles of each of these libraries that I used and confirm I am on the ... > with the new gcc compiler. ...
      (sci.math.num-analysis)
    • Re: Looking for gen symm sparse eigensolver in C or C++
      ... That always brings the chance of compiler and library ... Intermix conflicts are best avoided if ... Using Fortran calls in C/C++ code is trivial (I have heard good things about ... As long as you have the latest libc libraries with gcc/g77, ...
      (sci.math.num-analysis)
    • Re: Reported any bugs in C-LAPACK routine DSPEVX?
      ... > difference being the libraries you tell the compiler to link against. ... > in CLAPACK, and of course the way you pass by reference the arguments ... The CLAPACK library was built using a Fortran to C conversion utility ...
      (sci.math.num-analysis)
    • Re: can somebody verify this C program which calls dsaupd_ ? (longish)
      ... discusses all aspects of Fortran, ... Are you willing to go over the makefiles of each of these libraries that I used and confirm I am on the right track? ... So, given this and the reasoning I gave at the top, either the gcc compiler is wrong or the g77 compiler is wrong or my syntax changes are wrong or the way I compiled Fortran libs is wrong. ...
      (sci.math.num-analysis)