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_Xcsdp; 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. This is used in the GETBLK/GETROW/CLIP chain (TO BE REVISED). GETROW is (all that is) used by the ILU factorization. 13. You have to provide the GETDIAG functionality. 14. You have to provide the functionality to NEIGH. WATCH OUT: THIS COULD BE CHANGED TO USE GETROW!!!! 15. RWEXTD: what do we do here? Should we switch to/from COO????? Is this complete? I sure hope so....