You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
a8ee048f8f
. base/modules/psb_const_mod.F90 prec/psb_c_bjacprec.f90 prec/psb_c_diagprec.f90 prec/psb_c_nullprec.f90 prec/psb_s_bjacprec.f90 prec/psb_s_diagprec.f90 prec/psb_s_nullprec.f90 prec/psb_z_bjacprec.f90 prec/psb_z_diagprec.f90 prec/psb_z_nullprec.f90 Further changes merged from fixprec branch. |
8 years ago | |
---|---|---|
.. | ||
aux | 8 years ago | |
comm | 8 years ago | |
desc | 8 years ago | |
psblas | 8 years ago | |
serial | 8 years ago | |
tools | 8 years ago | |
Makefile | 8 years ago | |
README.F2003 | 15 years ago | |
cutil.c | 14 years ago | |
error.f90 | 8 years ago | |
fakempi.c | 9 years ago | |
psb_base_mod.f90 | 8 years ago | |
psb_check_mod.f90 | 8 years ago | |
psb_const_mod.F90 | 8 years ago | |
psb_error_impl.F90 | 8 years ago | |
psb_error_mod.F90 | 8 years ago | |
psb_internals.h | 14 years ago | |
psb_penv_mod.F90 | 15 years ago | |
psb_realloc_mod.F90 | 8 years ago | |
psi_bcast_mod.F90 | 8 years ago | |
psi_c_mod.f90 | 8 years ago | |
psi_comm_buffers_mod.F90 | 8 years ago | |
psi_d_mod.f90 | 8 years ago | |
psi_i_mod.f90 | 8 years ago | |
psi_mod.f90 | 8 years ago | |
psi_p2p_mod.F90 | 8 years ago | |
psi_penv_mod.F90 | 8 years ago | |
psi_reduce_mod.F90 | 8 years ago | |
psi_s_mod.f90 | 8 years ago | |
psi_z_mod.f90 | 8 years ago |
README.F2003
Design principles for this directory. 1. What is a sparse matrix? It is an object which does have some properties (number of rows, number of columns, whether it is a triangle, and in that case upper/lower, unit/nonunit), a state (null, build, assembled, update), a type (real/complex, single/double), and a storage format. Thus we have a three-level inheritance chain: i. The base object, defining the methods to set/query the various properties, and allocate and free. Some of the property getters/setters, allocate and free depend on the storage format, so at this level they will just throw an error. ii. The X_base_object, where X=s,d,c,z thus defining the type. At this level we define the computational interfaces to MV and SV, since they require the type of the vectors/scalars involved (should also add NRMI here!!!!), but again they will be empty shells. We also define the interface to CSPUT, required to build the object, and TO_COO,FROM_COO (see below). iii. The X_YYY_object where the real implementation of the MV/SV/NRMI/CSPUT/ALLOCATE/FREE/TO_COO/FROM_COO takes place. 2. What is a sparse matrix (take 2)? The above structure by itself does not allow a sparse matrix to switch among different storage formats during its life. To do this, we define all of the above to be INNER objects, encapsulated in an OUTER object which is what the rest of the library sees, as follows: type :: psbn_d_sparse_mat class(psbn_d_base_sparse_mat), allocatable :: a end type psbn_d_sparse_mat type(psbn_d_sparse_mat) :: a In this way we can have an outer object whose type is stable both statically (at compile time) and at runtime, while at runtime the type of the inner object switches from COO to CSR to whatever as needed. All of the methods are simply thrown onto the corresponding methods of the (allocatable, polymorphic) component A%A as needed (provided the component is allocated, that is). This is what is called a STATE design pattern (different from the internal state we discussed above). As an example, consider the allocate/build/assembly cycle: the outer code would do the following: 1. Allocate(psbn_d_coo_sparse_mat :: a%a) 2. During the build loop a call to A%CSINS() gets translated into CALL A%A%CSINS() 3. At assembly time the code would do the following subroutine psb_spasb(a,....) type(psbn_d_sparse_mat), intent(inout) :: a class(psbn_d_base_sparse_mat), allocatable :: temp select case (TYPE) case('CSR') allocate(psbn_d_csr_sparse_mat :: temp, stat=info) end select call temp%from_coo(a%a) call a%a%free() call move_alloc(temp,a%a) 4. Note in the above that to_coo, from_coo are defined so that every conceivable storage representation provides just 2 conversion routines, avoiding quadratic explosion. But since all have to provide them, the to_coo/from_coo is defined in d_base_mat_mod together with d_coo_sparse_mat, which enjoys the "crown prince" status with respect to all the other types derived from d_base_sparse_mat (its "siblings"). 5. How does a user add a new storage format? Very simple. After deriving the class and implementing all the necessary methods, the user declares in the program a dummy variable of the new inner type type(X_YYY_sparse_mat) :: reftype then calls call psb_spasb(a,....,mold=reftype) In psb_spasb we have class(psbn_d_base_sparse_mat), intent(in), optional :: mold if (present(mold)) then allocate(temp,source=mold,stat=info) end select call temp%from_coo(a%a) call a%a%free() call move_alloc(temp,a%a) AND IT'S DONE! Nothing else in the library requires the explicit knowledge of type of MOLD.