psblas3/base/serial
Salvatore Filippone 98088ecf0e psblas3:
base/modules/psb_c_mat_mod.f90
 base/modules/psb_d_mat_mod.f90
 base/modules/psb_s_mat_mod.f90
 base/modules/psb_z_mat_mod.f90
 base/serial/impl/psb_c_mat_impl.F90
 base/serial/impl/psb_d_mat_impl.F90
 base/serial/impl/psb_s_mat_impl.F90
 base/serial/impl/psb_z_mat_impl.F90
 util/psb_d_renum_impl.F90
 util/psb_renum_mod.f90

psblas3: defined MOLD method for _SPMAT_TYPE containers.
..
aux psblas3:
f77 psblas3:
impl psblas3:
Makefile psblas3:
README.serial *** empty log message ***
psb_aspxpby.f90 psblas3:
psb_cgeprt.f90 psblas3:
psb_cnumbmm.f90 psblas3:
psb_crwextd.f90 psblas3:
psb_csymbmm.f90 psblas3:
psb_dgeprt.f90 psblas3:
psb_dnumbmm.f90 psblas3:
psb_drwextd.f90 psblas3:
psb_dsymbmm.f90 psblas3:
psb_lsame.f90 psblas3:
psb_sgeprt.f90 psblas3:
psb_snumbmm.f90 psblas3:
psb_sort_impl.f90 psblas3:
psb_spdot_srtd.f90 psblas3:
psb_spge_dot.f90 psblas3:
psb_srwextd.f90 psblas3:
psb_ssymbmm.f90 psblas3:
psb_zgeprt.f90 psblas3:
psb_znumbmm.f90 psblas3:
psb_zrwextd.f90 psblas3:
psb_zsymbmm.f90 psblas3:
psi_serial_impl.f90 psblas3:

README.serial

Most of the subdirectories here contain material that was originally
distributed through the serial sparse blas SPARKER project, plus a
number of extensions of our own design. The original file spblas.f can
be downloaded from matisa.cc.rl.ac.uk; of course any bugs in our 
implementation are our own to fix.  

The main reference for the serial
sparse BLAS is: 
Duff, I., Marrone, M., Radicati, G., and Vittoli, C.
Level 3 basic linear algebra subprograms for sparse matrices: a user 
level interface
ACM Trans. Math. Softw., 23(3), 379-401, 1997.

We also include  SMMP by Randolph E. Bank and
Craig C. Douglas  na.bank@na-net.ornl.gov and
na.cdouglas@na-net.ornl.gov;  we wrapped  it in a Fortran 95 interface
with dynamic memory allocation. 



How do you add a new storage format? Here is your checklist. 
1.  You have to invent a name for it, a name that can fit into 3
    letters.
2.  You have to decide whether you need fields into INFOA() for it, and
    invent their names/positions accordingly.
3.  You have to add an estimate (as good as possible) for the memory
    occupation into psb_cest.
4.  You have to be able to generate it. For our purposes, the minimum
    effort that still meets the requirements is the ability to convert
    to/from COOrdinate; the relevant code (properly encapsulated in
    subroutines) should be added into psb_spcnv; you can take Xcocr as
    the model. You may or may not be able to do it "in place";
    ipcoo2csr & friends do just that; if you can, please add it because
    it may come in handy.
5.  If you need to sort entries, it usually better to use imsrx than
    isrx. This is because coefficients lists are likely to contain
    multiple ordered sublists ("runs"), and the merge sort algorithm
    implemented in imsrx is capable of taking advantage of them,
    whereas the isrx quicksort cannot. 
6.  You have to be able to convert it back to COOrdinate. This is
    usually not hard, because the code that does the MV multiply is
    already (maybe implicitly) walking through the coefficients while
    keeping track of both row and column index, thus it suffices to
    copy them as you meet them, and then call psb_fixcoo (which sorts
    and compacts the output) on the result. 
7.  You have to embed the MV and SV codes in the infrastructure; this
    is done first in the xSWMM and xSWSM routines that do a select on
    the FIDA value. Below this level you're free to do as you please. 
8.  You have to extend the output capability of psb_Xcsprt. Again this
    is  easy for the same reasons as in 6. 
9.  You have to extend psb_Xcsrws for DIAG preconditioner. 
10. Provide an UPDATE functionality, and add it to psb_update_mod;
    currently JAD is out of this. 
11. You have to provide the query facilities used in PSB_XSPINFO
    (included  in base/modules/psb_spmat_type). 
12. You have to provide the functionality to extract a block of
    rows in psb_getrow_mod.f90. This is used in the GETROW/GETBLK/CLIP
    chain; GETROW is (all that is) used by the ILU factorization. 
13. You have to provide the GETDIAG functionality. 
14. RWEXTD: what do we do here? Should we switch to/from COO?????
    The current interface is ugly! 
15. CSC is currently a second class citizen; it is only needed for
    interfacing UMFPACK in the mld2p4 preconditioners. 

Is this complete? I sure hope so....