[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 16:31:39 +0000
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
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,