PaStiX issueshttps://gitlab.inria.fr/solverstack/pastix/-/issues2017-08-23T09:14:53+02:00https://gitlab.inria.fr/solverstack/pastix/-/issues/2CRS and CCS format2017-08-23T09:14:53+02:00Ghost UserCRS and CCS formatDoes PaStiX handle compressed row formats? I tried running from the master branch and got a segfault when attempting to use my sparse matrix after passing row and column pointers to PaStiX (from an Eigen::SparseMatrix)
When I searched ...Does PaStiX handle compressed row formats? I tried running from the master branch and got a segfault when attempting to use my sparse matrix after passing row and column pointers to PaStiX (from an Eigen::SparseMatrix)
When I searched through the code to understand it, I came across Line 358 in `spm.c` where it sets the matrix to CCS by default and ignores the input argument layout.
What does PaStiX do with the row and column pointers that are passed to the `pastix_spm_s` struct? The problem occurs just after calling `pastixFinalize()`.https://gitlab.inria.fr/solverstack/pastix/-/issues/3Compiler warnings for abs2017-08-07T10:18:26+02:00Ghost UserCompiler warnings for absWhen compiling the tests with gcc-7, warnings are reported:
`warning: using integer absolute value function 'abs' when argument is
of floating point type [-Wabsolute-value]
result = abs(norms - normd) / (norms * eps);`
`note:...When compiling the tests with gcc-7, warnings are reported:
`warning: using integer absolute value function 'abs' when argument is
of floating point type [-Wabsolute-value]
result = abs(norms - normd) / (norms * eps);`
`note: use function 'fabs' instead
result = abs(norms - normd) / (norms * eps);
^~~
fabs`https://gitlab.inria.fr/solverstack/pastix/-/issues/4Compiler error with ifort 17.0.0 on pastixf.f902017-09-01T14:40:48+02:00AUMAGE OlivierCompiler error with ifort 17.0.0 on pastixf.f90Hi,
PaStiX rev "master 628bc7b" fails to build, producing the compiler error below on file pastixf.f90. The Fortran compiler used is Intel ifort 17.0.0.
```
Building Fortran object wrappers/fortran90/CMakeFiles/pastixf.dir/src/pastixf....Hi,
PaStiX rev "master 628bc7b" fails to build, producing the compiler error below on file pastixf.f90. The Fortran compiler used is Intel ifort 17.0.0.
```
Building Fortran object wrappers/fortran90/CMakeFiles/pastixf.dir/src/pastixf.f90.o
/home/cvtoauma/Linalg/pastix.git/wrappers/fortran90/src/pastixf.f90(548): error #8011: A pointer dummy argument with the
INTENT(IN) attribute shall not appear as an actual argument if the associated dummy argument has the INTENT(OUT) or INTENT(INOUT)
attribute. [FILENAME]
call c_f_pointer(filename_aux, filename)
-----------------------------------^
compilation aborted for /home/cvtoauma/Linalg/pastix.git/wrappers/fortran90/src/pastixf.f90 (code 1)
```
The following patch seems to fix the issue (the compiler seems to assume that all the arguments of pointed functions are inout):
```
diff --git a/wrappers/fortran90/src/pastixf.f90 b/wrappers/fortran90/src/pastixf.f90
index ee1fc94..72c6787 100644
--- a/wrappers/fortran90/src/pastixf.f90
+++ b/wrappers/fortran90/src/pastixf.f90
@@ -538,7 +538,7 @@ contains
real(kind=c_double), intent(inout), dimension(dparm_size), target :: dparm
integer(kind=c_int), intent(inout), target :: check
integer(c_int), intent(inout), target :: driver
- character(kind=c_char), intent(in), pointer :: filename
+ character(kind=c_char), intent(inout), pointer :: filename
type(c_ptr) :: argv_aux
type(c_ptr) :: filename_aux
```
Best regards,
--
Olivierhttps://gitlab.inria.fr/solverstack/pastix/-/issues/5Symbolic factorization segfault (for MaPHyS integration)2017-11-09T10:22:18+01:00MARAIT GillesSymbolic factorization segfault (for MaPHyS integration)When using MaPHyS + Pastix 6 on the matrix young1c with 8 processes, we obtain a segmentation fault during symbolic factorization.
Symbolic Factorization :
Symbol factorization using: Fax
*** Error in `./zmph_paddle': realloc()...When using MaPHyS + Pastix 6 on the matrix young1c with 8 processes, we obtain a segmentation fault during symbolic factorization.
Symbolic Factorization :
Symbol factorization using: Fax
*** Error in `./zmph_paddle': realloc(): invalid next size: 0x00000000026222f0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f1c002957e5]
After investigation, it seems that matrices 3 and 6 are concerned by the segmentation fault.
Attached files:
- the 8 subdomain matrices. [matrices.tar](/uploads/529d4331b0d2b495f8f486b12f0cc4d3/matrices.tar)
- the 8 domains description. The schurlist corresponds to the "myindexintrf" in the file. [domains.tar](/uploads/ac8cfc06f15209a99689225c57d1cb2f/domains.tar)
- The 8 "ordergen" and "symbgen" files dumped with IPARM_IO_STRATEGY = PastixIOSave. [newpastix_ordergen.tar](/uploads/e6b2f1567a4c005319d52178d7dd95db/newpastix_ordergen.tar)
- The same 8 "ordergen" and "symbgen" files but with the old pastix. [oldpastix_ordergen.tar](/uploads/1440318ed8cad15bb58294ea2b2ddd98/oldpastix_ordergen.tar)
NB: This issue appeared with 4 processes before the last commits.https://gitlab.inria.fr/solverstack/pastix/-/issues/6Expose pastixInitWithAffinity into the fortran wrapper2017-11-17T21:09:43+01:00KUHN MatthieuExpose pastixInitWithAffinity into the fortran wrapperWould be usefull to bind threads manually when using PaStiX into MaPHyS, so that PaStiX+MaPHyS = <3Would be usefull to bind threads manually when using PaStiX into MaPHyS, so that PaStiX+MaPHyS = <3https://gitlab.inria.fr/solverstack/pastix/-/issues/7Error in compilation (Fortran + intel)2017-12-01T13:11:52+01:00MARAIT GillesError in compilation (Fortran + intel)When compiling with spack pastix@solverstack+blasmt on Occigen, I get an error:
.../pastix/wrappers/fortran90/examples/fstep-by-step.f90(64): error #6691: A pointer dummy argument may only be argument associated with a pointer. [SPM]
...When compiling with spack pastix@solverstack+blasmt on Occigen, I get an error:
.../pastix/wrappers/fortran90/examples/fstep-by-step.f90(64): error #6691: A pointer dummy argument may only be argument associated with a pointer. [SPM]
call pastix_subtask_order( pastix_data, spm, null(), info )
------------------------------------------^
I think for the intel compiler, spm should be a 'pointer' and not a 'target', even though it is not a problem for the gnu compiler.https://gitlab.inria.fr/solverstack/pastix/-/issues/8Ordering issue on occigen2017-12-04T15:12:12+01:00KUHN MatthieuOrdering issue on occigenThere is an issue into the ordering of pastix on the occigen cluster when launching
the simple example on a laplacian.
Pastix has been installed with both scotch 6.0.4 and 5.1.10b, with mkl and intel compiler 17.0.0.
The simple exampl...There is an issue into the ordering of pastix on the occigen cluster when launching
the simple example on a laplacian.
Pastix has been installed with both scotch 6.0.4 and 5.1.10b, with mkl and intel compiler 17.0.0.
The simple example with a 1D laplacian (e.g. ./simple --lap 100 -t 4) is fine.
However, when considering a 2D laplacian (e.g. ./simple --lap 100:100 -t 4), the run
gets stuck into the ordering step of pastix, more precisely into scotch. See this ddt screenshot for more details: ![ddt](/uploads/00887cf9877a1d5f3426e9a3b6e090ee/ddt.png)
A similar behavior has been observed when attempting to use pastix into maphys on occigen on maphys' classical examples.https://gitlab.inria.fr/solverstack/pastix/-/issues/9MaPHyS + sparse pcd+ Pastix -> error in order_apply_level_order2018-02-19T16:42:28+01:00MARAIT GillesMaPHyS + sparse pcd+ Pastix -> error in order_apply_level_orderWhen using MaPHyS + Pastix with sparse preconditioning, we obtain a memory error in order_apply_level_order.c:276
It seems that the tree has cycles in it. Attached are the 2 spm files of the 2 processes used.[spmfiles.tgz](/uploads/c2f4...When using MaPHyS + Pastix with sparse preconditioning, we obtain a memory error in order_apply_level_order.c:276
It seems that the tree has cycles in it. Attached are the 2 spm files of the 2 processes used.[spmfiles.tgz](/uploads/c2f4d1b37702aac7669ec905435fa6c4/spmfiles.tgz)
NB: when setting iparm(IPARM_TASKS2D_LEVEL) = 0 in MaPHyS, we do not enter this part of the code and the error does not occur.https://gitlab.inria.fr/solverstack/pastix/-/issues/10Distributed matrix format2018-07-20T15:51:39+02:00Ghost UserDistributed matrix formatI have a question about the distributed matrix format in PaStiX.
Correct me if I'm wrong, but for the previous version is wasn't permitted to have a column split across more than one process, i.e. if the same column appeared in the `loc...I have a question about the distributed matrix format in PaStiX.
Correct me if I'm wrong, but for the previous version is wasn't permitted to have a column split across more than one process, i.e. if the same column appeared in the `loc2glob` vector in more than one process. From the user side it's definitely easier to assemble the stiffness matrix without much thought to the parallel environment and pass in the matrix with local indexing and the `loc2glob` vector during the solution stage. Will this restriction be present in the MPI release of PaStiX 6 too?https://gitlab.inria.fr/solverstack/pastix/-/issues/11spm nnz overflow2018-01-11T15:14:48+01:00Ghost Userspm nnz overflowThe current sparse matrix struct uses a pastix_int_t (potentially 32bit) for the nnz count. This could easily overflow a 32 bit integer when the other matrix indices will not. Should this be size_t instead?The current sparse matrix struct uses a pastix_int_t (potentially 32bit) for the nnz count. This could easily overflow a 32 bit integer when the other matrix indices will not. Should this be size_t instead?https://gitlab.inria.fr/solverstack/pastix/-/issues/12Fortran mangling with icc 17.02018-03-08T15:55:42+01:00KUHN MatthieuFortran mangling with icc 17.0https://gitlab.inria.fr/solverstack/pastix/-/issues/13Check multi-RHS and add a CI testing2018-07-23T13:01:15+02:00RAMET PierreCheck multi-RHS and add a CI testingMathieu FavergeMathieu Favergehttps://gitlab.inria.fr/solverstack/pastix/-/issues/14API migration from PaStiX 5 to PaStiX 6 (comprehension check)2018-02-21T18:45:23+01:00Andrea PiacentiniAPI migration from PaStiX 5 to PaStiX 6 (comprehension check)While porting my F90 application from PaStiX 5 to PaStiX 6 I'm not completely sure of all the parameters "translation".
In particular,
* is the old
```
iparm(IPARM_SYM) = API_SYM_YES
```
completely replaced by the spm featur...While porting my F90 application from PaStiX 5 to PaStiX 6 I'm not completely sure of all the parameters "translation".
In particular,
* is the old
```
iparm(IPARM_SYM) = API_SYM_YES
```
completely replaced by the spm feature
```
spm%mtxtype = PastixSymmetric
```
* is the old
```
iparm(IPARM_MATRIX_VERIFICATION) = API_YES
```
equivalent to a beforehand call to
```
call spmCheckAndCorrect( spm, spm2 )
```
* is the old
```
iparm(IPARM_RHS_MAKING) = API_RHS_B
```
equivalent to a beforehand call to
```
call spmGenRHS(
```
* is there any other important new tunable feature that we did not use to have in PaStiX 5?Mathieu FavergeMathieu Favergehttps://gitlab.inria.fr/solverstack/pastix/-/issues/15Compilation and link options generation tool2018-03-05T21:56:57+01:00Andrea PiacentiniCompilation and link options generation toolTo ease portability of our applications on different platforms where PaStiX is installed with customized compilation options, we relied on the `pastix-conf` tool with the useful `--fc`, `--fcopts` etc options.
Is there any plan to rein...To ease portability of our applications on different platforms where PaStiX is installed with customized compilation options, we relied on the `pastix-conf` tool with the useful `--fc`, `--fcopts` etc options.
Is there any plan to reinstate it?
For the moment, a similar information is contained in
```
build/example/make
```
but only for C applications.
Furthermore, `pkg-config` fails if hwloc was preinstalled and not known in `PKG_CONFIG_PATH`
In the specific case of intel ifort 16.0.4 (using mkl), some of the options turned on by ctest seem not to be strictly necessary, but I wonder if they could become meaningful in some situation.
They are `-f77rtl` as a compilation option, and the
`-lmkl_intel_lp64 -lmkl_sequential -lmkl_core -lpthread -lz -lm -lrt -lirng -ldecimal -lcilkrts -lstdc++` library links.
Most probably, the latter are installed as standard or default libraries on my test machine (and I am currently unable to remember how to display the full list of standard and default libraries for ifort).Mathieu FavergeMathieu Favergehttps://gitlab.inria.fr/solverstack/pastix/-/issues/16Check list of the PaStiX 6 implementation of the CERFACS customized features ...2018-07-23T16:47:15+02:00Andrea PiacentiniCheck list of the PaStiX 6 implementation of the CERFACS customized features in PaStiX 5For the effective integration of a sequential threadsafe version of PaStiX 5 as a routine called from an OpenMP region of a hybrid MPI+OpenMP application we had to customize both the sources and the compilation options of PaStiX 5.
Jus...For the effective integration of a sequential threadsafe version of PaStiX 5 as a routine called from an OpenMP region of a hybrid MPI+OpenMP application we had to customize both the sources and the compilation options of PaStiX 5.
Just to be more than sure that no customization is needed in PaStiX 6, here is a list of what we had to do
* *purely sequential version of PaStiX 5*
This was obtained by setting
```
-DFORCE_NOMPI
-DFORCE_NOSMP
```
and removing
```
-DCUDA_SM_VERSION=...
```
at compilation.
Is it now, simply enough to set `iparm(IPARM_THREAD_NBR) = 1` and `iparm(IPARM_VERBOSE) = PastixVerboseNot` to avoid any interference or rush condition?
* *activation of multiple RHS*
We had to explicitly activate
```
-DMULT_SMX
```
at compilation. I guess this is not necessary anymore (See issue #13).
* *algebra on multiple RHS*
Moreover, working with @faverge on the specific topic, we concluded that using BLAS2 for the operations on the multiple RHS was counterproductive if `nrhs` was actually set to 1. Is the specific case now handled separately?
* *memory management for multiple RHS*
In the same occasion we noticed a great performance improvement if the `STORAGE` mode was activated, which it was NOT by default. How has this aspect been ported to PaStiX 6? Is it a parametered choice ?
* *dependence on the non threadsafe section of Scotch 6.0.4*
A single treatment inside Scotch is not threadsafe. We made it critical by an OpenMP pragma, while in PaStiX 6 it is explicitly handled as atomic. Has this feature been tested in an intensive OpenMP application?
My tests up to 32 threads all passed once, but the bug is not systematic, therefore an extensive validation, also on the impact on performances is required.
By the way, is there any release announcement for a threadsafe Scotch?Mathieu FavergeMathieu Favergehttps://gitlab.inria.fr/solverstack/pastix/-/issues/17Test cases timing out or failing with intel162018-03-05T11:02:57+01:00Andrea PiacentiniTest cases timing out or failing with intel16With a standard installation under intel 16
```
cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/home/palm/USERS/andrea/ADOMOCA_LIB/64_intel/pastix_6.0.0 -DSCOTCH_DIR=/home/palm/USERS/andrea/ADOMOCA_LIB/64_intel/scotch_6.0.4 -...With a standard installation under intel 16
```
cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/home/palm/USERS/andrea/ADOMOCA_LIB/64_intel/pastix_6.0.0 -DSCOTCH_DIR=/home/palm/USERS/andrea/ADOMOCA_LIB/64_intel/scotch_6.0.4 -DHWLOC_DIR=/home/palm/USERS/andrea/ADOMOCA_LIB/64_intel/hwloc-1.11.3 -DPASTIX_INT64=OFF
```
the following ctests fails on a timeout
example_cg_simple
from example/CTestTestfile.cmake
and
test_hb_spm_convert_tests
test_hb_spm_norm_tests
test_hb_spm_matvec_tests
test_hb_spm_dof_expand_tests
test_hb_spm_dof_norm_tests
test_hb_spm_dof_matvec_tests
from test/CTestTestfile.cmake
and the following fail on a SEGFAULT
The following tests FAILED:
125 - example_hb_simple (SEGFAULT)
127 - example_gmres_simple (SEGFAULT)
128 - example_bicgstab_simple (SEGFAULT)
366 - test_hb_bcsc_norm_tests (SEGFAULT)
367 - test_hb_bcsc_matvec_tests (SEGFAULT)
Totalview indicates that the timeout is reached on
```
__lll_lock_wait_private, FP=7ffd1c8502d0
_L_lock_49, FP=7ffd1c850350
_IO_fgets, FP=7ffd1c850370
readHB_newmat_double, FP=7ffd1c852590
readHB, FP=7ffd1c8525e0
spmReadDriver, FP=7ffd1c852670
main, FP=7ffd1c852880
__libc_start_main, FP=7ffd1c852940
_start, FP=7ffd1c852948
```Mathieu FavergeMathieu Favergehttps://gitlab.inria.fr/solverstack/pastix/-/issues/18Need of "in place" format conversions2018-06-04T19:27:57+02:00Andrea PiacentiniNeed of "in place" format conversionsFor the sake of memory economy, we used to convert IJV (a.k.a. COO) matrices to the CSC format by a call to the Sparskit
```
SUBROUTINE coocsr_inplace ( n, nnz, job, a, ja, ia, iwk )
```
We wonder if spmConvert works in place or generate...For the sake of memory economy, we used to convert IJV (a.k.a. COO) matrices to the CSC format by a call to the Sparskit
```
SUBROUTINE coocsr_inplace ( n, nnz, job, a, ja, ia, iwk )
```
We wonder if spmConvert works in place or generate a second full spm and replaces the INOUT argument before returning.
Notice that coocsr_inplace only needs an integer work array `iwk(n+1)`Mathieu FavergeMathieu Favergehttps://gitlab.inria.fr/solverstack/pastix/-/issues/19Factorize multiple sparse matrices stored in multi-dimensional Fortran arrays2018-03-06T17:37:52+01:00Andrea PiacentiniFactorize multiple sparse matrices stored in multi-dimensional Fortran arraysThe PaStiX 5 fortran API allowed for the access to matrices stored as columns of a multidimensional array.
As an example, an application could have to choose a given matrix among a predefined set, accordingly to some run-time condition...The PaStiX 5 fortran API allowed for the access to matrices stored as columns of a multidimensional array.
As an example, an application could have to choose a given matrix among a predefined set, accordingly to some run-time condition.
The matrices could be stored with an extra index `self%il_ia(:,:), self%ila_ja(:,:), self%rla_L(:,:)` where the first dimension is the usual storage and the second is the linear system identfier.
In such a case, PaStiX 5 is called for the linear system `il_gsys` by
```
CALL pastix_fortran(self%sla_px(il_gsys)%pastix_data, &
self%sla_px(il_gsys)%pastix_comm, &
self%sla_px(il_gsys)%n, &
self%ila_ia(:,il_gsys),self%ila_ja(:,il_gsys), &
self%rla_L(:,il_gsys), &
self%sla_px(il_gsys)%perm,self%sla_px(il_gsys)%invp, &
self%rla_L(:,il_gsys),self%sla_px(il_gsys)%nrhs, &
self%sla_px(il_gsys)%iparm,self%sla_px(il_gsys)%dparm)
```
It turns out that neither this syntax
```
self%sla_spm%rowptr = c_loc(self%ila_ia(:,il_gsys))
```
nor
```
self%sla_spm%rowptr = c_loc(self%ila_ia(1,il_gsys))
```
lead to correct results.
As a workaround, we plan to rewrite our routines using arrays of derived datatypes
```
type sys_lin
type(pastix_data_t), pointer :: pastix_data
type(pastix_spm_t), pointer :: spm
type(pastix_spm_t), pointer :: spm2
integer(kind=pastix_int_t), dimension(:), pointer :: ila_ia
integer(kind=pastix_int_t), dimension(:), pointer :: ila_ja
complex(kind=c_double_complex), dimension(:), pointer :: rla_L
end type sys_lin
type(sys_lin), dimension(:), allocatable, target :: sla_lap
...
self%sla_lap(ib)%spm%rowptr = c_loc(sla_lap(ib)%ila_ia)
self%sla_lap(ib)%spm%colptr = c_loc(sla_lap(ib)%ila_ja)
self%sla_lap(ib)%spm%values = c_loc(sla_lap(ib)%rla_L)
```https://gitlab.inria.fr/solverstack/pastix/-/issues/20Reuse of a single factorized matrix for different concurrent solve calls2018-03-06T17:38:39+01:00Andrea PiacentiniReuse of a single factorized matrix for different concurrent solve callsNext step of experiments, leading to new questions:
*Aim:* Factorize once a single matrix, then use it for different solve calls (each possibly with nrhs>1) distributed among OpenMP threads
Questions:
1. Is the first argument of `...Next step of experiments, leading to new questions:
*Aim:* Factorize once a single matrix, then use it for different solve calls (each possibly with nrhs>1) distributed among OpenMP threads
Questions:
1. Is the first argument of `pastix_task_solve` (the `pastix_data_t` structure) input only, or is it modified/updated in the call? Otherwise stated, is `pastix_task_solve` threadsafe w.r.t. the pastix data?
2. If the answer to 1. is "yes", we'd need to run the factorization in a single OpenMP thread, but using all the available cores for PaStiX pthreads
```
iparm(IPARM_THREAD_NBR) = il_ompthr
```
while the solve phase should be single-pthreaded and concurrently run on the OpenMP threads.
How can we modify the `iparm(IPARM_THREAD_NBR)` in the pastix structure after initialization?
3. If we need to iterate around the switch from the pthreaded factorization and the single-pthreaded solve, what is the default value for `iparm(IPARM_SCHEDULER)` in pthreaded sections? (We learned to set it to `PastixSchedSequential` in conjunction to `iparm(IPARM_THREAD_NBR) = 1` to switch off pthreading and avoid interferences with OpenMP, but we do not know to what it has to be set back.https://gitlab.inria.fr/solverstack/pastix/-/issues/21Pb with Python solver interface2018-02-21T18:44:41+01:00Mathieu FavergePb with Python solver interfaceThe pb reported by @lpoirel is that the the following code in not working after a few iteration:
```
import pypastix as pastix
import scipy.sparse as sps
import numpy as np
# Set the problem
for n in range(5, 100):
print(n)
A =...The pb reported by @lpoirel is that the the following code in not working after a few iteration:
```
import pypastix as pastix
import scipy.sparse as sps
import numpy as np
# Set the problem
for n in range(5, 100):
print(n)
A = sps.spdiags([np.ones(n)*i for i in [4, -1, -1, -1, -1]],
[0, 1, 3, -1, -3], n, n)
x0 = np.ones(n)
b = A.dot(x0)
# Hack to make sure that the mkl is loaded
tmp = np.eye(2).dot(np.ones(2))
# Factorize
solver = pastix.solver(A, verbose=False, thread_nbr=1)
# Solve
x = solver.solve(b, x0=x0, check=True)
solver.finalize()
```
The problem is the corruption of the spm structure that is forwarded to PaStiX.Mathieu FavergeMathieu Faverge