Re: [petsc-users] Evaluation of Hybrid solvers ... test matrices

2018-03-11 Thread Matthew Knepley
On Mon, Mar 12, 2018 at 12:13 AM, Afrah Najib  wrote:

> Dir dirs,
>
> I am working on evaluation of hybrid solvers including PDSLin  which us
> Krylov method of PETSc as a dependency but I did not find the matrices used
> for evaluating these solvers used in literature namely, Matrix211
> , Tdr455k ,Tdr190kI ... they seem not to be publically available ,
>
> Do you have any idea how can I find them
>

They may be here

  https://sparse.tamu.edu/

Matt


> thank you
>



-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/ 


Re: [petsc-users] error regarding filling section fields

2018-03-11 Thread Matthew Knepley
On Sun, Mar 11, 2018 at 10:39 PM, Mohammad Hassan Baghaei <
mhbagh...@mail.sjtu.edu.cn> wrote:

> Hi
>
> I am trying to fill the global vector . Using single processor, it works
> fine. However, switching to several processors, I get the error regarding
> the section offset out of range for several points. The short of error
> message is below. Can you let me know what causes the offset to become [0,0
> ( in this case and How I can solve this issue. Thanks for your time.
>
>
This looks like you have not called PetscSectionSetChart(), or anything
else, on this Section. It could
be you only set it up on 1 process. I am not sure what you are trying to do.

   Matt


> Amir
>
>
>
> [1]PETSC ERROR: - Error Message
> --
>
> [1]PETSC ERROR: Argument out of range
>
> [1]PETSC ERROR: Section point 1 should be in [0, 0)
>
> [1]PETSC ERROR: #1 PetscSectionGetOffset() line 1155 in
> /home/amir/petsc/src/vec/is/utils/vsectionis.c
>
> [1]PETSC ERROR: #2 PetscSectionGetFieldOffset() line 1208 in
> /home/amir/petsc/src/vec/is/utils/vsectionis.c
>
>
>



-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/ 


[petsc-users] error regarding filling section fields

2018-03-11 Thread Mohammad Hassan Baghaei
Hi

I am trying to fill the global vector . Using single processor, it works
fine. However, switching to several processors, I get the error regarding
the section offset out of range for several points. The short of error
message is below. Can you let me know what causes the offset to become [0,0(
in this case and How I can solve this issue. Thanks for your time.

Amir 

 

[1]PETSC ERROR: - Error Message
--

[1]PETSC ERROR: Argument out of range

[1]PETSC ERROR: Section point 1 should be in [0, 0)

[1]PETSC ERROR: #1 PetscSectionGetOffset() line 1155 in
/home/amir/petsc/src/vec/is/utils/vsectionis.c

[1]PETSC ERROR: #2 PetscSectionGetFieldOffset() line 1208 in
/home/amir/petsc/src/vec/is/utils/vsectionis.c

 



[petsc-users] Evaluation of Hybrid solvers ... test matrices

2018-03-11 Thread Afrah Najib
Dir dirs,

I am working on evaluation of hybrid solvers including PDSLin  which us
Krylov method of PETSc as a dependency but I did not find the matrices used
for evaluating these solvers used in literature namely, Matrix211
, Tdr455k ,Tdr190kI ... they seem not to be publically available ,

Do you have any idea how can I find them
thank you


Re: [petsc-users] Tweaking my code for CUDA

2018-03-11 Thread Matthew Knepley
On Fri, Mar 9, 2018 at 3:05 AM, Manuel Valera 
wrote:

> Hello all,
>
> I am working on porting a linear solver into GPUs for timing purposes, so
> far i've been able to compile and run the CUSP libraries and compile PETSc
> to be used with CUSP and ViennaCL, after the initial runs i noticed some
> errors, they are different for different flags and i would appreciate any
> help interpreting them,
>
> The only elements in this program that use PETSc are the laplacian matrix
> (sparse), the RHS and X vectors and a scatter petsc object, so i would say
> it's safe to pass the command line arguments for the Mat/VecSetType()s
> instead of changing the source code,
>
> If i use *-vec_type cuda -mat_type aijcusparse* or *-vec_type viennacl
> -mat_type aijviennacl *i get the following:
>

These systems do not properly propagate errors. My only advice is to run a
smaller problem and see.


> [0]PETSC ERROR: --
> --
> [0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation,
> probably memory access out of range
> [0]PETSC ERROR: Try option -start_in_debugger or -on_error_attach_debugger
> [0]PETSC ERROR: or see http://www.mcs.anl.gov/petsc/
> documentation/faq.html#valgrind
> [0]PETSC ERROR: or try http://valgrind.org on GNU/linux and Apple Mac OS
> X to find memory corruption errors
> [0]PETSC ERROR: likely location of problem given in stack below
> [0]PETSC ERROR: -  Stack Frames
> 
> [0]PETSC ERROR: Note: The EXACT line numbers in the stack are not
> available,
> [0]PETSC ERROR:   INSTEAD the line number of the start of the function
> [0]PETSC ERROR:   is given.
> [0]PETSC ERROR: [0] VecSetValues line 847 /home/valera/petsc/src/vec/
> vec/interface/rvector.c
> [0]PETSC ERROR: [0] VecSetType line 36 /home/valera/petsc/src/vec/
> vec/interface/vecreg.c
> [0]PETSC ERROR: [0] VecSetTypeFromOptions_Private line 1230
> /home/valera/petsc/src/vec/vec/interface/vector.c
> [0]PETSC ERROR: [0] VecSetFromOptions line 1271 /home/valera/petsc/src/vec/
> vec/interface/vector.c
> [0]PETSC ERROR: - Error Message
> --
> [0]PETSC ERROR: Signal received
> [0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html
> for trouble shooting.
> [0]PETSC ERROR: Petsc Development GIT revision: v3.8.3-1817-g96b6f8a  GIT
> Date: 2018-02-28 10:19:08 -0600
> [0]PETSC ERROR: ./gcmSeamount on a cuda named node50 by valera Thu Mar  8
> 09:50:51 2018
> [0]PETSC ERROR: Configure options PETSC_ARCH=cuda --with-cc=mpicc
> --with-cxx=mpic++ --with-fc=mpifort --COPTFLAGS=-O3 --CXXOPTFLAGS=-O3
> --FOPTFLAGS=-O3 --with-shared-libraries=1 --with-debugging=1 --with-cuda=1
> --with-cuda-arch=sm_60 --with-cusp=1 --with-cusp-dir=/home/valera/cusp
> --with-vienacl=1 --download-fblaslapack=1 --download-hypre
> [0]PETSC ERROR: #5 User provided function() line 0 in  unknown file
> --
>
> This seems to be a memory out of range, maybe my vector is too big for my
> CUDA system? how do i assess that?
>
>
> Next, if i use *-vec_type cusp -mat_type aijcusparse *i get something
> different and more interesting:
>

We need to see the entire error message, since it has the stack.

This seems like a logic error, but could definitely be on our end. Here is
how I think about these:

  1) We have nightly test solves, so at least some solver configuration
works

  2) Some vector which is marked read-only (happens for input to solvers),
but someone is trying to update it.
  The stack will tell me where this is happening.

  Thanks,

 Matt


> [0]PETSC ERROR: - Error Message
> --
> [0]PETSC ERROR: Object is in wrong state
> [0]PETSC ERROR:  Vec is locked read only, argument # 3
> [0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html
> for trouble shooting.
> [0]PETSC ERROR: Petsc Development GIT revision: v3.8.3-1817-g96b6f8a  GIT
> Date: 2018-02-28 10:19:08 -0600
> [0]PETSC ERROR: ./gcmSeamount on a cuda named node50 by valera Thu Mar  8
> 10:02:19 2018
> [0]PETSC ERROR: Configure options PETSC_ARCH=cuda --with-cc=mpicc
> --with-cxx=mpic++ --with-fc=mpifort --COPTFLAGS=-O3 --CXXOPTFLAGS=-O3
> --FOPTFLAGS=-O3 --with-shared-libraries=1 --with-debugging=1 --with-cuda=1
> --with-cuda-arch=sm_60 --with-cusp=1 --with-cusp-dir=/home/valera/cusp
> --with-vienacl=1 --download-fblaslapack=1 --download-hypre
> [0]PETSC ERROR: #48 KSPSolve() line 615 in /home/valera/petsc/src/ksp/
> ksp/interface/itfunc.c
>  PETSC_SOLVER_ONLY   6.8672990892082453E-005 s
> [0]PETSC ERROR: - Error Message
> --
> [0]PETSC ERROR: Invalid argument
> [0]PETSC ERROR: Object (seq) is not seqcusp or 

Re: [petsc-users] PCLU diverges where PCILU converges on Dense Matrix

2018-03-11 Thread Matthew Knepley
On Sun, Mar 11, 2018 at 1:14 AM, Smith, Barry F.  wrote:

>
>   1) Run the problem with -ksp_view_mat and -ksp_view_rhs and mail
> petsc-ma...@mcs.anl.gov  the resulting file produced called binaryoutput
>
>2) By default PCLU does a reordering to reduce fill that could
> introduce a zero pivoit, PCILU does not do a reordering by default. You can
> use -pc_factor_mat_ordering_type none to force no reordering (PCLU does not
> do numerical pivoting for stability so can fail with zero pivots).
>
>3) If you need to solve these tiny 7 by 7 systems many times
> (presumably you are solving these to set up a large algebraic system solved
> afterwards) then you probably don't want to use KSP to solve them. You can
> use the low level kernel PetscKernel_A_gets_inverse_A_7() that does do
> pivoting followed by a multiply like
>
> s1 = v[0]*x1 + v[6]*x2  + v[12]*x3 + v[18]*x4 + v[24]*x5 + v[30]*x6;
>   s2 = v[1]*x1 + v[7]*x2  + v[13]*x3 + v[19]*x4 + v[25]*x5 + v[31]*x6;
>   s3 = v[2]*x1 + v[8]*x2  + v[14]*x3 + v[20]*x4 + v[26]*x5 + v[32]*x6;
>   s4 = v[3]*x1 + v[9]*x2  + v[15]*x3 + v[21]*x4 + v[27]*x5 + v[33]*x6;
>   s5 = v[4]*x1 + v[10]*x2 + v[16]*x3 + v[22]*x4 + v[28]*x5 + v[34]*x6;
>   s6 = v[5]*x1 + v[11]*x2 + v[17]*x3 + v[23]*x4 + v[29]*x5 + v[35]*x6;
>
> where v is the dense 7 by 7 matrix (stored column oriented like Fortran)
> an the x are the seven values of the right hand side.
>

Note that PCPBJACOBI will do this automatically.

   Matt


>Barry
>
>
>
>
>
> > On Mar 10, 2018, at 5:22 AM, Ali Berk Kahraman <
> aliberkkahra...@yahoo.com> wrote:
> >
> > Hello All,
> >
> > I am trying to get the finite difference coefficients for a given
> irregular grid. For this, I follow the following webpage, which tells me to
> solve a linear system.
> >
> > http://web.media.mit.edu/~crtaylor/calculator.html
> >
> > I solve a 7 unknown linear system with a 7x7 dense matrix to get the
> finite difference coefficients. Since I will call this code many many many
> times in my overall project, I need it to be as fast, yet as exact as
> possible. So I use PCLU. I make sure that there are no zero diagonals on
> the matrix, I swap required rows for it. However, PCLU still diverges with
> the output at the end of this e-mail. It indicates
> "FACTOR_NUMERIC_ZEROPIVOT" , but as I have written above I make sure there
> are no zero main diagonal entries on the matrix. When I use PCILU instead,
> it converges pretty well.
> >
> > So my question is, is PCILU the same thing mathematically as PCLU when
> applied on a small dense matrix? I need to know if I get the exact solution
> with PCILU, because my whole project will depend on the accuracy of the
> finite differences.
> >
> > Best Regards,
> >
> > Ali Berk Kahraman
> > M.Sc. Student, Mechanical Engineering Dept.
> > Boğaziçi Uni., Istanbul, Turkey
> >
> > Linear solve did not converge due to DIVERGED_PCSETUP_FAILED iterations 0
> >PCSETUP_FAILED due to FACTOR_NUMERIC_ZEROPIVOT
> > KSP Object: 1 MPI processes
> >   type: gmres
> > restart=30, using Classical (unmodified) Gram-Schmidt
> Orthogonalization with no iterative refinement
> > happy breakdown tolerance 1e-30
> >   maximum iterations=1, initial guess is zero
> >   tolerances:  relative=1e-05, absolute=1e-50, divergence=1.
> >   left preconditioning
> >   using PRECONDITIONED norm type for convergence test
> > PC Object: 1 MPI processes
> >   type: lu
> > out-of-place factorization
> > tolerance for zero pivot 2.22045e-14
> > matrix ordering: nd
> > factor fill ratio given 5., needed 1.
> >   Factored matrix follows:
> > Mat Object: 1 MPI processes
> >   type: seqaij
> >   rows=7, cols=7
> >   package used to perform factorization: petsc
> >   total: nonzeros=49, allocated nonzeros=49
> >   total number of mallocs used during MatSetValues calls =0
> > using I-node routines: found 2 nodes, limit used is 5
> >   linear system matrix = precond matrix:
> >   Mat Object: 1 MPI processes
> > type: seqaij
> > rows=7, cols=7
> > total: nonzeros=49, allocated nonzeros=49
> > total number of mallocs used during MatSetValues calls =0
> >   using I-node routines: found 2 nodes, limit used is 5
> >
> >
>
>


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/