[petsc-users] Flexiable AIJ matrix for nonzeros -- hash table version

[Jed Brown]

On Tue, May 10, 2011 at 10:16, Gong Ding <gdiso at ustc.edu> wrote:

> I just use uthash http://uthash.sourceforge.net. It is a bsd licensed hash
> table implementation.
>

I used uthash at one point and later switched to a slightly customized
version of khash (
https://github.com/attractivechaos/klib/blob/master/khash.h) which I like
much better. See these blog posts by the author:

http://attractivechaos.wordpress.com/2008/08/28/comparison-of-hash-table-libraries/
http://attractivechaos.wordpress.com/2008/09/02/implementing-generic-hash-library-in-c/

If PETSc is going to adopt a generic C hash implementation for use in
multiple places, it is worth considering.


> At present, the hash key is <row,col> pair. Using row index as hash key,
> and store each row as dynamic array of col, value
> is possible.
> In general, hash table with key <row,col> is fast enough.
>

This also has less overhead for when most rows are preallocated correctly.
Without benchmarks for specific use cases, I don't see a convincing argument
either way.


>
> Add hash table to original AIJ avoid the type name problem. However, there
> are some other matrix types also derived from AIJ. i.e.
> CSRPERM.
>

AIJPERM uses AIJ for assembly so it would also benefit if preallocation
spills were handled with the hash. There are also genuinely different
formats (e.g. BAIJ) that could benefit from the hash. As perhaps a future
matter, it may be worth hooking in at the level of MatSeqXAIJReallocateAIJ.
This might not actually be hard, it looks like the right information is
already available. I think that hideous macro would need to be turned into a
function before doing anything else.

As a result, I guess CSRPERM will also crash...
> I think each sub type (of AIJ matrix, i.e.) should hold its base type. And
> mumps interface only needs to check the base type.
>

Yes, better handling of base types is needed for several things now so it
will be done soon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20110510/f261844e/attachment-0001.htm>