help-gsl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gsl] finite element assembly and calling UMFPACK for linear sy


From: Patrick Alken
Subject: Re: [Help-gsl] finite element assembly and calling UMFPACK for linear system solution
Date: Wed, 19 Jun 2019 16:31:39 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

Hello,

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 you
> have tried using UMFPACK for the linear algebra. I have following findings
> 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 compressed
> 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 of
> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]