[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-gsl] finite element assembly and calling UMFPACK for linear sy
Re: [Help-gsl] finite element assembly and calling UMFPACK for linear system solution
Wed, 19 Jun 2019 22:40:30 +0300
Thank Patrick for your prompt response.
I saw lots of new update in git.gsl. And yes now I assemble the entire
matrix and add boundary conditions before compressing it. For now I'll just
clone and compile the newer version.
On Wed, Jun 19, 2019 at 7:41 PM Patrick Alken <address@hidden> wrote:
> On 6/19/19 9:15 AM, Brijesh Upadhaya wrote:
> > Hi everyone,
> > I am working on a finite element problem and wanted to ask if anyone of
> > have tried using UMFPACK for the linear algebra. I have following
> > when using sparse matrix module from gsl-2.5.
> > 1. In CCS the row indices are not sorted so UMFPACK gives error (see
> > attached example)
> Its on my todo list to add a "sorted CSC" and "sorted CSR" spmatrix
> type. Hopefully it will get done for the next release.
> > 2. Adding boundary conditions were also difficult once compressed, so I
> > couldn't utilize gsl_spmatrix_add() to add mass matrix with stiffness
> > matrix. Instead I had to do it with triplet and calling the get/set
> > routines. Could only add boundary condition at triplet level and
> > at the end and passed the pointers to UMFPACK routines.
> Yes the triplet (COO) format is designed for easy set/get operations,
> using a binary tree for fast lookup and insertion. Once you compress the
> matrix, the binary tree disappears, and you can only modify existing
> matrix entries - you cannot add new ones. Can't you assemble the entire
> matrix, including boundary conditions, before compressing it?
> > 3. Another thing (not related to gsl) was that UMFPACK don't use (size_t
> > *), instead it has (int *) and (long *) for column pointers and row
> > indices. I tried to cast (size_t *) to (long *) to utilize the pointers
> > gsl_spmatrix object.
> I have decided to change the size_t pointers to int in gsl_spmatrix, for
> the reason you cite. Many external libraries use integer arrays instead
> of size_t. This has already been done on the git repository (you can
> just clone the gsl git).
> > I am bit curious to know if anyone have a better experience. I wanted to
> > use direct solver instead of iterative solver.
> I would also like to include a direct solver in GSL itself, though I
> don't know when I'll have time to implement it.
> > King Regards,
> > Brijesh