From sumit_vaidya at persistent.co.in Wed Aug 1 08:42:30 2007 From: sumit_vaidya at persistent.co.in (Sumit Vaidya) Date: Wed, 1 Aug 2007 19:12:30 +0530 Subject: Running 'make' command in verbose mode Message-ID: <000901c7d441$ce68b5c0$4598580a@persistent.co.in> Hi, I want to run the 'make' command in verbose mode. I want to know which files(.c/.f) the compiler(gcc/g77) takes as an input and which are the libraries that are created as an output. How to achieve this? Regards, Sumit DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. -------------- next part -------------- An HTML attachment was scrubbed... URL: From balay at mcs.anl.gov Wed Aug 1 08:46:41 2007 From: balay at mcs.anl.gov (Satish Balay) Date: Wed, 1 Aug 2007 08:46:41 -0500 (CDT) Subject: Running 'make' command in verbose mode In-Reply-To: <000901c7d441$ce68b5c0$4598580a@persistent.co.in> References: <000901c7d441$ce68b5c0$4598580a@persistent.co.in> Message-ID: Could you tell us what exactly are you trying to acomplish? you can try: make ACTION=lib tree Satish On Wed, 1 Aug 2007, Sumit Vaidya wrote: > Hi, > > > > I want to run the 'make' command in verbose mode. > > I want to know which files(.c/.f) the compiler(gcc/g77) takes as an input > and which are the libraries that are created as an output. > > > > How to achieve this? > > > > Regards, > > Sumit > > > DISCLAIMER > ========== > This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. > From sumit_vaidya at persistent.co.in Wed Aug 1 09:22:30 2007 From: sumit_vaidya at persistent.co.in (Sumit Vaidya) Date: Wed, 1 Aug 2007 19:52:30 +0530 Subject: Running 'make' command in verbose mode In-Reply-To: References: <000901c7d441$ce68b5c0$4598580a@persistent.co.in> Message-ID: <001101c7d447$653cfa10$4598580a@persistent.co.in> Hi, I found your build procedure something different than the other applications. So I was eager to know about it. Other applications produce makefiles through configure script and use it for actual building. But here I found makefiles are already present along with the package and configure script is mainly doing some testing and producing architecture configuration files. Regards, Sumit -----Original Message----- From: owner-petsc-users at mcs.anl.gov [mailto:owner-petsc-users at mcs.anl.gov] On Behalf Of Satish Balay Sent: Wednesday, August 01, 2007 7:17 PM To: petsc-users at mcs.anl.gov Subject: Re: Running 'make' command in verbose mode Could you tell us what exactly are you trying to acomplish? you can try: make ACTION=lib tree Satish On Wed, 1 Aug 2007, Sumit Vaidya wrote: > Hi, > > > > I want to run the 'make' command in verbose mode. > > I want to know which files(.c/.f) the compiler(gcc/g77) takes as an input > and which are the libraries that are created as an output. > > > > How to achieve this? > > > > Regards, > > Sumit > > > DISCLAIMER > ========== > This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. > DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. From balay at mcs.anl.gov Wed Aug 1 09:55:06 2007 From: balay at mcs.anl.gov (Satish Balay) Date: Wed, 1 Aug 2007 09:55:06 -0500 (CDT) Subject: Running 'make' command in verbose mode In-Reply-To: <001101c7d447$653cfa10$4598580a@persistent.co.in> References: <000901c7d441$ce68b5c0$4598580a@persistent.co.in> <001101c7d447$653cfa10$4598580a@persistent.co.in> Message-ID: Is your interest either of: - use PETSc [by building PETSc libraries] - - investigate the build infrastructure in PETSc? If its the second one - could I enquire for what purpose would such investigation be useful? On Wed, 1 Aug 2007, Sumit Vaidya wrote: > I found your build procedure something different than the other > applications. So I was eager to know about it. > > Other applications produce makefiles through configure script and use it for > actual building. But here I found makefiles are already present along with > the package and configure script is mainly doing some testing and producing > architecture configuration files. This is inference is incorrect. [there is not much difference in the 2 methods you mention - except for a different organization of the makefiles] Our model is equivalent to autoconf model [you refer to]. With autoconf, [from what I understand] Makefile.in has the pre-written make targets [by the package developer], and then there are some variables [like CC etc] that configure detects and substitutes - and creates Makefile. We also have pre-written targets, and variables that configure detects and substitutes. The difference is - in case of autoconf, the generated makefile has both targets & variables. We chose to split up generated variables into different makefiles in bmake/$PETSC_ARCH, and the pre-written targets into bmake/common/* files. [And then the toplevel makefile that included the relavent generated/precoded targets] So, in both cases, the 'makefiles' are useable by the user only after configure is run. Hope this helps, Satish From zonexo at gmail.com Wed Aug 1 10:16:28 2007 From: zonexo at gmail.com (Ben Tay) Date: Wed, 01 Aug 2007 23:16:28 +0800 Subject: Fixing values in a poisson eqn Message-ID: <46B0A3CC.9050806@gmail.com> Hi, I am trying to solve a pressure poisson eqn resulting from the NS eqn. How can I fixed the pressure at some nodes while solving the poisson eqn? I tried to make the coefficient of the diagonal location of the node very big e.g. 1e100. I also use call KSPSetInitialGuessNonzero(ksp,PETSC_TRUE,ierr) and insert the original values as initial solution: do i=1,blk(1)%size_x do j=1,blk(1)%size_y call VecSetValue(xx,k,blk(1)%p(i,j),INSERT_VALUES,ierr) k=k+1 end do end do in my code. However, after solving the eqn, the value I got is 1e-16 or 0. So what have I done wrong? Thanks From knepley at gmail.com Wed Aug 1 10:28:41 2007 From: knepley at gmail.com (Matthew Knepley) Date: Wed, 1 Aug 2007 10:28:41 -0500 Subject: Fixing values in a poisson eqn In-Reply-To: <46B0A3CC.9050806@gmail.com> References: <46B0A3CC.9050806@gmail.com> Message-ID: On 8/1/07, Ben Tay wrote: > Hi, > > I am trying to solve a pressure poisson eqn resulting from the NS eqn. > How can I fixed the pressure at some nodes while solving the poisson eqn? > > I tried to make the coefficient of the diagonal location of the node > very big e.g. 1e100. I also use When you form the Jacobian, the row associated with the unknown should be the identity (not a big number as above). > call KSPSetInitialGuessNonzero(ksp,PETSC_TRUE,ierr) Should not matter. > and insert the original values as initial solution: > > do i=1,blk(1)%size_x > > do j=1,blk(1)%size_y > > call VecSetValue(xx,k,blk(1)%p(i,j),INSERT_VALUES,ierr) > > k=k+1 > > end do > > end do You want the boundary value on the rhs, not the solution. > in my code. However, after solving the eqn, the value I got is 1e-16 or > 0. So what have I done wrong? I would look at an example, like SNES ex5. Matt > Thanks > > > -- 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 From sumit_vaidya at persistent.co.in Thu Aug 2 00:26:04 2007 From: sumit_vaidya at persistent.co.in (Sumit Vaidya) Date: Thu, 2 Aug 2007 10:56:04 +0530 Subject: Running 'make' command in verbose mode In-Reply-To: References: <000901c7d441$ce68b5c0$4598580a@persistent.co.in> <001101c7d447$653cfa10$4598580a@persistent.co.in> Message-ID: <000001c7d4c5$9f15a470$4598580a@persistent.co.in> Hi, My interest is to use PETSc by building the libraries. I got the answer. Thank you for the information. Yes, the build procedure is equivalent to autoconf model. Regards, Sumit -----Original Message----- From: owner-petsc-users at mcs.anl.gov [mailto:owner-petsc-users at mcs.anl.gov] On Behalf Of Satish Balay Sent: Wednesday, August 01, 2007 8:25 PM To: petsc-users at mcs.anl.gov Subject: RE: Running 'make' command in verbose mode Is your interest either of: - use PETSc [by building PETSc libraries] - - investigate the build infrastructure in PETSc? If its the second one - could I enquire for what purpose would such investigation be useful? On Wed, 1 Aug 2007, Sumit Vaidya wrote: > I found your build procedure something different than the other > applications. So I was eager to know about it. > > Other applications produce makefiles through configure script and use it for > actual building. But here I found makefiles are already present along with > the package and configure script is mainly doing some testing and producing > architecture configuration files. This is inference is incorrect. [there is not much difference in the 2 methods you mention - except for a different organization of the makefiles] Our model is equivalent to autoconf model [you refer to]. With autoconf, [from what I understand] Makefile.in has the pre-written make targets [by the package developer], and then there are some variables [like CC etc] that configure detects and substitutes - and creates Makefile. We also have pre-written targets, and variables that configure detects and substitutes. The difference is - in case of autoconf, the generated makefile has both targets & variables. We chose to split up generated variables into different makefiles in bmake/$PETSC_ARCH, and the pre-written targets into bmake/common/* files. [And then the toplevel makefile that included the relavent generated/precoded targets] So, in both cases, the 'makefiles' are useable by the user only after configure is run. Hope this helps, Satish DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. From zonexo at gmail.com Thu Aug 2 23:24:15 2007 From: zonexo at gmail.com (Ben Tay) Date: Fri, 03 Aug 2007 12:24:15 +0800 Subject: Comparing between a PETSc matrix and a standard fortran array in compressed row format Message-ID: <46B2ADEF.4050806@gmail.com> Hi, I used 2 packages to solve my poisson eqn, which is part of my NS unsteady solver. One is the NSPCG solver package which uses the compressed row format to store the A matrix. The other is PETSc. I found that using both solvers gave me similar answers for a number of time step. However, after that, the answer will suddenly change drastically for the PETSc case. This does not happen for the NSPCG solver. For e.g. time step 1-315, oscillating airfoil case, pressure changes smoothly, similar answers in both cases at time=316, pressure changes from -3.22 to -3.2 for NSPCG, but pressure changes from -3.21 to -60.2 for PETSc This happens when I use HYPRE's AMG or PETSc's direct solver LU. I have been trying to find out what's the cause and I can't find the answer in debugging. I would like to compare the values of the matrix of the 2 different solvers and see if there's any difference. However, NSPCG's matrix is in compressed row format while PETSc's one is just an address and it can't be viewed easily. Moreover, it's a big matrix so it's not possible to check by inspection. I'm thinking of subtracting one matrix by the other and find if it's zero. What's the best way to solve this problem? Btw, I'm using fortran and there's no mpi Thank you. From gkells at thphys.nuim.ie Fri Aug 3 06:38:27 2007 From: gkells at thphys.nuim.ie (Graham Kells) Date: Fri, 3 Aug 2007 12:38:27 +0100 (IST) Subject: Scattering context options In-Reply-To: References: <46A9D4C5.6020001@thphys.nuim.ie> Message-ID: ------------------------------------------- Ok, thanks to you both. It looks like I will have to rethink this one :-/ Regards, Graham On Fri, 27 Jul 2007, Barry Smith wrote: > > Graham, > > It seems unlike the matrix was preallocated; this will > definitely slow things down a great deal. Pluse you have a > scatter for each row, this is fundamentally not scalable. > > Barry > > > On Fri, 27 Jul 2007, Graham Kells wrote: > >> Hi , >> >> I'm scattering from a global vector (used as a kind of look up table) to a >> bunch of local vectors and then using the values in the local vectors as >> indices to populate a global matrix. >> The basic population routine goes something like this >> >> do myrow=Istart,Iend-1 >> >> ! Returns column indices of full matrix for rowindex list(myrow+1) >> call getrow(list(myrow+1),rowCOO,colCOO,valCOO) >> call ISCreateGeneral(PETSC_COMM_WORLD,n,(colCOO-1),from,ierr) >> call ISCreateGeneral(PETSC_COMM_SELF,n,idx_to-1,to,ierr) call >> VecScatterCreate(vlist,from,outvec,to,scatter,ierr) >> call >> VecScatterBegin(scatter,vlist,outvec,INSERT_VALUES,SCATTER_FORWARD,ierr) >> call VecScatterEnd(scatter,vlist,outvec,INSERT_VALUES,SCATTER_FORWARD,ierr) >> call VecScatterDestroy(scatter,ierr) >> call ISDestroy(from,ierr) >> call ISDestroy(to,ierr) >> >> call VecGetValues(outvec,n,idx_to-1,idx_real,ierr) >> idx_from=int(idx_real) >> >> >> call MatSetValues(A,1,myrow,n,idx_from-1,valCOO,INSERT_VALUES,ierr) >> >> end do >> >> While this works, it is prohibitively slow. Any ideas on why this is? Of >> course if you can suggest a better way of doing this that would be great. >> >> Supposing you can't and I want to experiment with different MPI communication >> modes within the scatter context. How do specify the MPI_Ssend option, for >> example? >> >> Thanks in advance, >> >> Graham >> >> >> >> >> >> >> >> >> >> >> >> > From knepley at gmail.com Fri Aug 3 08:19:35 2007 From: knepley at gmail.com (Matthew Knepley) Date: Fri, 3 Aug 2007 08:19:35 -0500 Subject: Comparing between a PETSc matrix and a standard fortran array in compressed row format In-Reply-To: <46B2ADEF.4050806@gmail.com> References: <46B2ADEF.4050806@gmail.com> Message-ID: I am guessing that you are using MATAIJ format in PETSc, so both matrices are in the same format. How about using MatView()? Or reading in the NSPCG matrix and subtracting as you indicate? Matt On 8/2/07, Ben Tay wrote: > Hi, > > I used 2 packages to solve my poisson eqn, which is part of my NS > unsteady solver. One is the NSPCG solver package which uses the > compressed row format to store the A matrix. The other is PETSc. I found > that using both solvers gave me similar answers for a number of time > step. However, after that, the answer will suddenly change drastically > for the PETSc case. This does not happen for the NSPCG solver. > > For e.g. time step 1-315, oscillating airfoil case, pressure changes > smoothly, similar answers in both cases > > at time=316, pressure changes from -3.22 to -3.2 for NSPCG, but pressure > changes from -3.21 to -60.2 for PETSc > > This happens when I use HYPRE's AMG or PETSc's direct solver LU. > > I have been trying to find out what's the cause and I can't find the > answer in debugging. I would like to compare the values of the matrix of > the 2 different solvers and see if there's any difference. However, > NSPCG's matrix is in compressed row format while PETSc's one is just an > address and it can't be viewed easily. Moreover, it's a big matrix so > it's not possible to check by inspection. I'm thinking of subtracting > one matrix by the other and find if it's zero. What's the best way to > solve this problem? Btw, I'm using fortran and there's no mpi > > 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 From bsmith at mcs.anl.gov Fri Aug 3 09:08:08 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Fri, 3 Aug 2007 09:08:08 -0500 (CDT) Subject: Comparing between a PETSc matrix and a standard fortran array in compressed row format In-Reply-To: <46B2ADEF.4050806@gmail.com> References: <46B2ADEF.4050806@gmail.com> Message-ID: You can use MatCreateSeqAIJWithArrays() to "convert" the NSPCG matrix into PETSc format and then MatAXPY() to difference them and then MatNorm() to see how large the result is. Make sure the PETSc or hypre solver is always converging. Run with -ksp_converged_reason and or -ksp_monitor. My guess is that the matrix is becoming very ill-conditioned so the solvers with the default options are failing. Barry On Fri, 3 Aug 2007, Ben Tay wrote: > Hi, > > I used 2 packages to solve my poisson eqn, which is part of my NS unsteady > solver. One is the NSPCG solver package which uses the compressed row format > to store the A matrix. The other is PETSc. I found that using both solvers > gave me similar answers for a number of time step. However, after that, the > answer will suddenly change drastically for the PETSc case. This does not > happen for the NSPCG solver. > > For e.g. time step 1-315, oscillating airfoil case, pressure changes smoothly, > similar answers in both cases > > at time=316, pressure changes from -3.22 to -3.2 for NSPCG, but pressure > changes from -3.21 to -60.2 for PETSc > > This happens when I use HYPRE's AMG or PETSc's direct solver LU. > > I have been trying to find out what's the cause and I can't find the answer in > debugging. I would like to compare the values of the matrix of the 2 different > solvers and see if there's any difference. However, NSPCG's matrix is in > compressed row format while PETSc's one is just an address and it can't be > viewed easily. Moreover, it's a big matrix so it's not possible to check by > inspection. I'm thinking of subtracting one matrix by the other and find if > it's zero. What's the best way to solve this problem? Btw, I'm using fortran > and there's no mpi > > Thank you. > > > From zonexo at gmail.com Fri Aug 3 22:17:19 2007 From: zonexo at gmail.com (Ben Tay) Date: Sat, 04 Aug 2007 11:17:19 +0800 Subject: Comparing between a PETSc matrix and a standard fortran array in compressed row format In-Reply-To: References: <46B2ADEF.4050806@gmail.com> Message-ID: <46B3EFBF.5070909@gmail.com> Hi, I realised that the matrix storage format of NSPCG is actually ITPACK storage format. Anyway, I tried to insert the values into a PETSc matrix, use MatAXPY with the scalar a = -1 and then use MatNorm on the output matrix. Using NORM_1, NORM_FROBENIUS and NORM_INFINITY <../Vec/NORM_FROBENIUS.html#NORM_FROBENIUS>, I got ~543, 3194 and 556 respectively. Does this mean that the matrix are different? How "much" different does that means? So what is the next step? Is there anyway to find out the location of the value which is different? This is my comparison subroutine: subroutine matrix_compare !compare big_A & PETSc matrix integer :: k,kk,II,JJ,ierr Vec xx_test,b_rhs_test Mat A_mat_test PetscScalar aa PetscReal nrm aa=-1. call MatCreateSeqAIJ(PETSC_COMM_SELF,total_k,total_k,10,PETSC_NULL_INTEGER,A_mat_test,ierr) call VecCreateSeq(PETSC_COMM_SELF,total_k,b_rhs_test,ierr) call VecDuplicate(b_rhs_test,xx_test,ierr) call VecAssemblyBegin(b_rhs_test,ierr) call VecAssemblyEnd(b_rhs_test,ierr) call VecAssemblyBegin(xx_test,ierr) call VecAssemblyEnd(xx_test,ierr) do k=1,total_k do kk=1,10 II=k-1 JJ=int_A(k,kk)-1 call MatSetValues(A_mat_test,1,II,1,JJ,big_A(k,kk),INSERT_VALUES,ierr) call VecSetValue(b_rhs_test,II,q_p(k),INSERT_VALUES,ierr) end do end do ! call MatCopy(A_mat,A_mat_test,DIFFERENT_NONZERO_PATTERN ,ierr) call MatAssemblyBegin(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) call MatAssemblyEnd(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) call MatAXPY(A_mat_test,aa,A_mat,SAME_NONZERO_PATTERN,ierr) call MatNorm(A_mat_test,NORM_INFINITY,nrm,ierr) print *, nrm end subroutine matrix_compare Thanks! Barry Smith wrote: > You can use MatCreateSeqAIJWithArrays() to "convert" the NSPCG matrix into > PETSc format and then MatAXPY() to difference them and then MatNorm() to > see how large the result is. > > Make sure the PETSc or hypre solver is always converging. Run with > -ksp_converged_reason and or -ksp_monitor. My guess is that the matrix is > becoming very ill-conditioned so the solvers with the default options are > failing. > > Barry > > > On Fri, 3 Aug 2007, Ben Tay wrote: > > >> Hi, >> >> I used 2 packages to solve my poisson eqn, which is part of my NS unsteady >> solver. One is the NSPCG solver package which uses the compressed row format >> to store the A matrix. The other is PETSc. I found that using both solvers >> gave me similar answers for a number of time step. However, after that, the >> answer will suddenly change drastically for the PETSc case. This does not >> happen for the NSPCG solver. >> >> For e.g. time step 1-315, oscillating airfoil case, pressure changes smoothly, >> similar answers in both cases >> >> at time=316, pressure changes from -3.22 to -3.2 for NSPCG, but pressure >> changes from -3.21 to -60.2 for PETSc >> >> This happens when I use HYPRE's AMG or PETSc's direct solver LU. >> >> I have been trying to find out what's the cause and I can't find the answer in >> debugging. I would like to compare the values of the matrix of the 2 different >> solvers and see if there's any difference. However, NSPCG's matrix is in >> compressed row format while PETSc's one is just an address and it can't be >> viewed easily. Moreover, it's a big matrix so it's not possible to check by >> inspection. I'm thinking of subtracting one matrix by the other and find if >> it's zero. What's the best way to solve this problem? Btw, I'm using fortran >> and there's no mpi >> >> Thank you. >> >> >> >> > > > From bsmith at mcs.anl.gov Fri Aug 3 22:31:42 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Fri, 3 Aug 2007 22:31:42 -0500 (CDT) Subject: Comparing between a PETSc matrix and a standard fortran array in compressed row format In-Reply-To: <46B3EFBF.5070909@gmail.com> References: <46B2ADEF.4050806@gmail.com> <46B3EFBF.5070909@gmail.com> Message-ID: Unless the matrix values are huge then this is a big difference. All you can do is print the difference matrix with ASCII MatView and look for large entries. This will tell you the locations of the trouble entries. Barry On Sat, 4 Aug 2007, Ben Tay wrote: > Hi, > > I realised that the matrix storage format of NSPCG is actually ITPACK storage > format. Anyway, I tried to insert the values into a PETSc matrix, use MatAXPY > with the scalar a = -1 and then use MatNorm on the output matrix. > > Using NORM_1, NORM_FROBENIUS and NORM_INFINITY > <../Vec/NORM_FROBENIUS.html#NORM_FROBENIUS>, I got ~543, 3194 and 556 > respectively. Does this mean that the matrix are different? How "much" > different does that means? > > So what is the next step? Is there anyway to find out the location of the > value which is different? > > This is my comparison subroutine: > > subroutine matrix_compare > > !compare big_A & PETSc matrix > > integer :: k,kk,II,JJ,ierr > > Vec xx_test,b_rhs_test > Mat A_mat_test > > PetscScalar aa > > PetscReal nrm > > aa=-1. > > call > MatCreateSeqAIJ(PETSC_COMM_SELF,total_k,total_k,10,PETSC_NULL_INTEGER,A_mat_test,ierr) > > call VecCreateSeq(PETSC_COMM_SELF,total_k,b_rhs_test,ierr) > > call VecDuplicate(b_rhs_test,xx_test,ierr) > > call VecAssemblyBegin(b_rhs_test,ierr) > > call VecAssemblyEnd(b_rhs_test,ierr) > > call VecAssemblyBegin(xx_test,ierr) > > call VecAssemblyEnd(xx_test,ierr) > > do k=1,total_k > do kk=1,10 > > II=k-1 > > JJ=int_A(k,kk)-1 > call > MatSetValues(A_mat_test,1,II,1,JJ,big_A(k,kk),INSERT_VALUES,ierr) > call VecSetValue(b_rhs_test,II,q_p(k),INSERT_VALUES,ierr) > end do > > end do > > ! call MatCopy(A_mat,A_mat_test,DIFFERENT_NONZERO_PATTERN ,ierr) > > call MatAssemblyBegin(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) > call MatAssemblyEnd(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) > > call MatAXPY(A_mat_test,aa,A_mat,SAME_NONZERO_PATTERN,ierr) > > call MatNorm(A_mat_test,NORM_INFINITY,nrm,ierr) > > print *, nrm > > end subroutine matrix_compare > > Thanks! > > > > Barry Smith wrote: > > You can use MatCreateSeqAIJWithArrays() to "convert" the NSPCG matrix into > > PETSc format and then MatAXPY() to difference them and then MatNorm() to see > > how large the result is. > > Make sure the PETSc or hypre solver is always converging. Run with > > -ksp_converged_reason and or -ksp_monitor. My guess is that the matrix is > > becoming very ill-conditioned so the solvers with the default options are > > failing. > > > > Barry > > > > > > On Fri, 3 Aug 2007, Ben Tay wrote: > > > > > > > Hi, > > > > > > I used 2 packages to solve my poisson eqn, which is part of my NS unsteady > > > solver. One is the NSPCG solver package which uses the compressed row > > > format > > > to store the A matrix. The other is PETSc. I found that using both solvers > > > gave me similar answers for a number of time step. However, after that, > > > the > > > answer will suddenly change drastically for the PETSc case. This does not > > > happen for the NSPCG solver. > > > > > > For e.g. time step 1-315, oscillating airfoil case, pressure changes > > > smoothly, > > > similar answers in both cases > > > > > > at time=316, pressure changes from -3.22 to -3.2 for NSPCG, but pressure > > > changes from -3.21 to -60.2 for PETSc > > > > > > This happens when I use HYPRE's AMG or PETSc's direct solver LU. > > > > > > I have been trying to find out what's the cause and I can't find the > > > answer in > > > debugging. I would like to compare the values of the matrix of the 2 > > > different > > > solvers and see if there's any difference. However, NSPCG's matrix is in > > > compressed row format while PETSc's one is just an address and it can't be > > > viewed easily. Moreover, it's a big matrix so it's not possible to check > > > by > > > inspection. I'm thinking of subtracting one matrix by the other and find > > > if > > > it's zero. What's the best way to solve this problem? Btw, I'm using > > > fortran > > > and there's no mpi > > > > > > Thank you. > > > > > > > > > > > > > > > > > > > > From zonexo at gmail.com Sat Aug 4 03:30:10 2007 From: zonexo at gmail.com (Ben Tay) Date: Sat, 04 Aug 2007 16:30:10 +0800 Subject: Comparing between a PETSc matrix and a standard fortran array in compressed row format In-Reply-To: References: <46B2ADEF.4050806@gmail.com> <46B3EFBF.5070909@gmail.com> Message-ID: <46B43912.2050509@gmail.com> Hi, After using MatAXPY, I used MatGetRowMaxAbs, VecAb and VecMax to get the row with max value, get the absolute of that value and print out the location/value. I managed to find some minor mistakes and corrected them so that the 2 matrix are identical. Unfortunately, the same thing still happens! I've checked for convergence and the iteration no. is 1 and 8 for direct solving and HYPRE's AMG respectively. So there's no convergence problem. I've also tried to change to the same pc/ksp as that of NSPCG, which is jacobi presconditioning + KSPBCGS but the same thing happens. Any idea what's happening? Thanks Barry Smith wrote: > Unless the matrix values are huge then this is a big difference. > All you can do is print the difference matrix with ASCII MatView and > look for large entries. This will tell you the locations of the > trouble entries. > > Barry > > > On Sat, 4 Aug 2007, Ben Tay wrote: > > >> Hi, >> >> I realised that the matrix storage format of NSPCG is actually ITPACK storage >> format. Anyway, I tried to insert the values into a PETSc matrix, use MatAXPY >> with the scalar a = -1 and then use MatNorm on the output matrix. >> >> Using NORM_1, NORM_FROBENIUS and NORM_INFINITY >> <../Vec/NORM_FROBENIUS.html#NORM_FROBENIUS>, I got ~543, 3194 and 556 >> respectively. Does this mean that the matrix are different? How "much" >> different does that means? >> >> So what is the next step? Is there anyway to find out the location of the >> value which is different? >> >> This is my comparison subroutine: >> >> subroutine matrix_compare >> >> !compare big_A & PETSc matrix >> >> integer :: k,kk,II,JJ,ierr >> >> Vec xx_test,b_rhs_test >> Mat A_mat_test >> >> PetscScalar aa >> >> PetscReal nrm >> >> aa=-1. >> >> call >> MatCreateSeqAIJ(PETSC_COMM_SELF,total_k,total_k,10,PETSC_NULL_INTEGER,A_mat_test,ierr) >> >> call VecCreateSeq(PETSC_COMM_SELF,total_k,b_rhs_test,ierr) >> >> call VecDuplicate(b_rhs_test,xx_test,ierr) >> >> call VecAssemblyBegin(b_rhs_test,ierr) >> >> call VecAssemblyEnd(b_rhs_test,ierr) >> >> call VecAssemblyBegin(xx_test,ierr) >> >> call VecAssemblyEnd(xx_test,ierr) >> >> do k=1,total_k >> do kk=1,10 >> >> II=k-1 >> >> JJ=int_A(k,kk)-1 >> call >> MatSetValues(A_mat_test,1,II,1,JJ,big_A(k,kk),INSERT_VALUES,ierr) >> call VecSetValue(b_rhs_test,II,q_p(k),INSERT_VALUES,ierr) >> end do >> >> end do >> >> ! call MatCopy(A_mat,A_mat_test,DIFFERENT_NONZERO_PATTERN ,ierr) >> >> call MatAssemblyBegin(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) >> call MatAssemblyEnd(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) >> >> call MatAXPY(A_mat_test,aa,A_mat,SAME_NONZERO_PATTERN,ierr) >> >> call MatNorm(A_mat_test,NORM_INFINITY,nrm,ierr) >> >> print *, nrm >> >> end subroutine matrix_compare >> >> Thanks! >> >> >> >> Barry Smith wrote: >> >>> You can use MatCreateSeqAIJWithArrays() to "convert" the NSPCG matrix into >>> PETSc format and then MatAXPY() to difference them and then MatNorm() to see >>> how large the result is. >>> Make sure the PETSc or hypre solver is always converging. Run with >>> -ksp_converged_reason and or -ksp_monitor. My guess is that the matrix is >>> becoming very ill-conditioned so the solvers with the default options are >>> failing. >>> >>> Barry >>> >>> >>> On Fri, 3 Aug 2007, Ben Tay wrote: >>> >>> >>> >>>> Hi, >>>> >>>> I used 2 packages to solve my poisson eqn, which is part of my NS unsteady >>>> solver. One is the NSPCG solver package which uses the compressed row >>>> format >>>> to store the A matrix. The other is PETSc. I found that using both solvers >>>> gave me similar answers for a number of time step. However, after that, >>>> the >>>> answer will suddenly change drastically for the PETSc case. This does not >>>> happen for the NSPCG solver. >>>> >>>> For e.g. time step 1-315, oscillating airfoil case, pressure changes >>>> smoothly, >>>> similar answers in both cases >>>> >>>> at time=316, pressure changes from -3.22 to -3.2 for NSPCG, but pressure >>>> changes from -3.21 to -60.2 for PETSc >>>> >>>> This happens when I use HYPRE's AMG or PETSc's direct solver LU. >>>> >>>> I have been trying to find out what's the cause and I can't find the >>>> answer in >>>> debugging. I would like to compare the values of the matrix of the 2 >>>> different >>>> solvers and see if there's any difference. However, NSPCG's matrix is in >>>> compressed row format while PETSc's one is just an address and it can't be >>>> viewed easily. Moreover, it's a big matrix so it's not possible to check >>>> by >>>> inspection. I'm thinking of subtracting one matrix by the other and find >>>> if >>>> it's zero. What's the best way to solve this problem? Btw, I'm using >>>> fortran >>>> and there's no mpi >>>> >>>> Thank you. >>>> >>>> >>>> >>>> >>>> >>> >>> >> > > > From bsmith at mcs.anl.gov Sat Aug 4 11:11:16 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Sat, 4 Aug 2007 11:11:16 -0500 (CDT) Subject: Comparing between a PETSc matrix and a standard fortran array in compressed row format In-Reply-To: <46B43912.2050509@gmail.com> References: <46B2ADEF.4050806@gmail.com> <46B3EFBF.5070909@gmail.com> <46B43912.2050509@gmail.com> Message-ID: Ben, Are you comparing the two matrices at timestep 316? Also compare the two right hand sides at 316. Are they similar, totally different?? Barry On Sat, 4 Aug 2007, Ben Tay wrote: > Hi, > > After using MatAXPY, I used MatGetRowMaxAbs, VecAb and VecMax to get the row > with max value, get the absolute of that value and print out the > location/value. I managed to find some minor mistakes and corrected them so > that the 2 matrix are identical. Unfortunately, the same thing still happens! > > I've checked for convergence and the iteration no. is 1 and 8 for direct > solving and HYPRE's AMG respectively. So there's no convergence problem. I've > also tried to change to the same pc/ksp as that of NSPCG, which is jacobi > presconditioning + KSPBCGS but the same thing happens. > > Any idea what's happening? > > Thanks > > Barry Smith wrote: > > Unless the matrix values are huge then this is a big difference. All you > > can do is print the difference matrix with ASCII MatView and > > look for large entries. This will tell you the locations of the trouble > > entries. > > > > Barry > > > > > > On Sat, 4 Aug 2007, Ben Tay wrote: > > > > > > > Hi, > > > > > > I realised that the matrix storage format of NSPCG is actually ITPACK > > > storage > > > format. Anyway, I tried to insert the values into a PETSc matrix, use > > > MatAXPY > > > with the scalar a = -1 and then use MatNorm on the output matrix. > > > > > > Using NORM_1, NORM_FROBENIUS and NORM_INFINITY > > > <../Vec/NORM_FROBENIUS.html#NORM_FROBENIUS>, I got ~543, 3194 and 556 > > > respectively. Does this mean that the matrix are different? How "much" > > > different does that means? > > > > > > So what is the next step? Is there anyway to find out the location of the > > > value which is different? > > > > > > This is my comparison subroutine: > > > > > > subroutine matrix_compare > > > > > > !compare big_A & PETSc matrix > > > > > > integer :: k,kk,II,JJ,ierr > > > > > > Vec xx_test,b_rhs_test > > > Mat A_mat_test > > > > > > PetscScalar aa > > > > > > PetscReal nrm > > > > > > aa=-1. > > > > > > call > > > MatCreateSeqAIJ(PETSC_COMM_SELF,total_k,total_k,10,PETSC_NULL_INTEGER,A_mat_test,ierr) > > > > > > call VecCreateSeq(PETSC_COMM_SELF,total_k,b_rhs_test,ierr) > > > > > > call VecDuplicate(b_rhs_test,xx_test,ierr) > > > > > > call VecAssemblyBegin(b_rhs_test,ierr) > > > > > > call VecAssemblyEnd(b_rhs_test,ierr) > > > > > > call VecAssemblyBegin(xx_test,ierr) > > > > > > call VecAssemblyEnd(xx_test,ierr) > > > > > > do k=1,total_k > > > do kk=1,10 > > > > > > II=k-1 > > > > > > JJ=int_A(k,kk)-1 > > > call > > > MatSetValues(A_mat_test,1,II,1,JJ,big_A(k,kk),INSERT_VALUES,ierr) > > > call VecSetValue(b_rhs_test,II,q_p(k),INSERT_VALUES,ierr) > > > end do > > > > > > end do > > > > > > ! call MatCopy(A_mat,A_mat_test,DIFFERENT_NONZERO_PATTERN ,ierr) > > > > > > call MatAssemblyBegin(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) > > > call MatAssemblyEnd(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) > > > > > > call MatAXPY(A_mat_test,aa,A_mat,SAME_NONZERO_PATTERN,ierr) > > > > > > call MatNorm(A_mat_test,NORM_INFINITY,nrm,ierr) > > > > > > print *, nrm > > > > > > end subroutine matrix_compare > > > > > > Thanks! > > > > > > > > > > > > Barry Smith wrote: > > > > > > > You can use MatCreateSeqAIJWithArrays() to "convert" the NSPCG matrix > > > > into > > > > PETSc format and then MatAXPY() to difference them and then MatNorm() to > > > > see > > > > how large the result is. Make sure the PETSc or hypre solver is always > > > > converging. Run with > > > > -ksp_converged_reason and or -ksp_monitor. My guess is that the matrix > > > > is > > > > becoming very ill-conditioned so the solvers with the default options > > > > are > > > > failing. > > > > > > > > Barry > > > > > > > > > > > > On Fri, 3 Aug 2007, Ben Tay wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > I used 2 packages to solve my poisson eqn, which is part of my NS > > > > > unsteady > > > > > solver. One is the NSPCG solver package which uses the compressed row > > > > > format > > > > > to store the A matrix. The other is PETSc. I found that using both > > > > > solvers > > > > > gave me similar answers for a number of time step. However, after > > > > > that, > > > > > the > > > > > answer will suddenly change drastically for the PETSc case. This does > > > > > not > > > > > happen for the NSPCG solver. > > > > > > > > > > For e.g. time step 1-315, oscillating airfoil case, pressure changes > > > > > smoothly, > > > > > similar answers in both cases > > > > > > > > > > at time=316, pressure changes from -3.22 to -3.2 for NSPCG, but > > > > > pressure > > > > > changes from -3.21 to -60.2 for PETSc > > > > > > > > > > This happens when I use HYPRE's AMG or PETSc's direct solver LU. > > > > > > > > > > I have been trying to find out what's the cause and I can't find the > > > > > answer in > > > > > debugging. I would like to compare the values of the matrix of the 2 > > > > > different > > > > > solvers and see if there's any difference. However, NSPCG's matrix is > > > > > in > > > > > compressed row format while PETSc's one is just an address and it > > > > > can't be > > > > > viewed easily. Moreover, it's a big matrix so it's not possible to > > > > > check > > > > > by > > > > > inspection. I'm thinking of subtracting one matrix by the other and > > > > > find > > > > > if > > > > > it's zero. What's the best way to solve this problem? Btw, I'm using > > > > > fortran > > > > > and there's no mpi > > > > > > > > > > Thank you. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From zonexo at gmail.com Sat Aug 4 20:31:27 2007 From: zonexo at gmail.com (Ben Tay) Date: Sun, 05 Aug 2007 09:31:27 +0800 Subject: Comparing between a PETSc matrix and a standard fortran array in compressed row format In-Reply-To: References: <46B2ADEF.4050806@gmail.com> <46B3EFBF.5070909@gmail.com> <46B43912.2050509@gmail.com> Message-ID: <46B5286F.5040002@gmail.com> Hi, Now I'm comparing at every time step. The A matrix and rhs of the NSPCG and PETSc matrix are exactly the same, NORM is zero. The solutions given by both solvers are very similar for e.g. from 1-315 time step, and varying slowly since it is a oscillating body problem. Then strangely, at time=316, PETSc's answer suddenly differs by a great difference. e.g. p=0.3 to 50. I must also add that the flowfield at that time step still "looks ok". However, the large pressure change of the pressure poisson eqn caused the computation of the lift/drag coefficient to be erroneous. Moreover, after that, the pressure slowly "returns back" to the same answer such that of the NSPCG solver after a few time steps ... then after a while the sudden change happens again. In the end, I got a cl/cd vs time graph with lots of spikes. I hope that the thing can be solved because the NSPCG solver is much slower and it is not as stable. Thanks Barry Smith wrote: > Ben, > > Are you comparing the two matrices at timestep 316? Also compare the > two right hand sides at 316. Are they similar, totally different?? > > Barry > > > On Sat, 4 Aug 2007, Ben Tay wrote: > > >> Hi, >> >> After using MatAXPY, I used MatGetRowMaxAbs, VecAb and VecMax to get the row >> with max value, get the absolute of that value and print out the >> location/value. I managed to find some minor mistakes and corrected them so >> that the 2 matrix are identical. Unfortunately, the same thing still happens! >> >> I've checked for convergence and the iteration no. is 1 and 8 for direct >> solving and HYPRE's AMG respectively. So there's no convergence problem. I've >> also tried to change to the same pc/ksp as that of NSPCG, which is jacobi >> presconditioning + KSPBCGS but the same thing happens. >> >> Any idea what's happening? >> >> Thanks >> >> Barry Smith wrote: >> >>> Unless the matrix values are huge then this is a big difference. All you >>> can do is print the difference matrix with ASCII MatView and >>> look for large entries. This will tell you the locations of the trouble >>> entries. >>> >>> Barry >>> >>> >>> On Sat, 4 Aug 2007, Ben Tay wrote: >>> >>> >>> >>>> Hi, >>>> >>>> I realised that the matrix storage format of NSPCG is actually ITPACK >>>> storage >>>> format. Anyway, I tried to insert the values into a PETSc matrix, use >>>> MatAXPY >>>> with the scalar a = -1 and then use MatNorm on the output matrix. >>>> >>>> Using NORM_1, NORM_FROBENIUS and NORM_INFINITY >>>> <../Vec/NORM_FROBENIUS.html#NORM_FROBENIUS>, I got ~543, 3194 and 556 >>>> respectively. Does this mean that the matrix are different? How "much" >>>> different does that means? >>>> >>>> So what is the next step? Is there anyway to find out the location of the >>>> value which is different? >>>> >>>> This is my comparison subroutine: >>>> >>>> subroutine matrix_compare >>>> >>>> !compare big_A & PETSc matrix >>>> >>>> integer :: k,kk,II,JJ,ierr >>>> >>>> Vec xx_test,b_rhs_test >>>> Mat A_mat_test >>>> >>>> PetscScalar aa >>>> >>>> PetscReal nrm >>>> >>>> aa=-1. >>>> >>>> call >>>> MatCreateSeqAIJ(PETSC_COMM_SELF,total_k,total_k,10,PETSC_NULL_INTEGER,A_mat_test,ierr) >>>> >>>> call VecCreateSeq(PETSC_COMM_SELF,total_k,b_rhs_test,ierr) >>>> >>>> call VecDuplicate(b_rhs_test,xx_test,ierr) >>>> >>>> call VecAssemblyBegin(b_rhs_test,ierr) >>>> >>>> call VecAssemblyEnd(b_rhs_test,ierr) >>>> >>>> call VecAssemblyBegin(xx_test,ierr) >>>> >>>> call VecAssemblyEnd(xx_test,ierr) >>>> >>>> do k=1,total_k >>>> do kk=1,10 >>>> >>>> II=k-1 >>>> >>>> JJ=int_A(k,kk)-1 >>>> call >>>> MatSetValues(A_mat_test,1,II,1,JJ,big_A(k,kk),INSERT_VALUES,ierr) >>>> call VecSetValue(b_rhs_test,II,q_p(k),INSERT_VALUES,ierr) >>>> end do >>>> >>>> end do >>>> >>>> ! call MatCopy(A_mat,A_mat_test,DIFFERENT_NONZERO_PATTERN ,ierr) >>>> >>>> call MatAssemblyBegin(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) >>>> call MatAssemblyEnd(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) >>>> >>>> call MatAXPY(A_mat_test,aa,A_mat,SAME_NONZERO_PATTERN,ierr) >>>> >>>> call MatNorm(A_mat_test,NORM_INFINITY,nrm,ierr) >>>> >>>> print *, nrm >>>> >>>> end subroutine matrix_compare >>>> >>>> Thanks! >>>> >>>> >>>> >>>> Barry Smith wrote: >>>> >>>> >>>>> You can use MatCreateSeqAIJWithArrays() to "convert" the NSPCG matrix >>>>> into >>>>> PETSc format and then MatAXPY() to difference them and then MatNorm() to >>>>> see >>>>> how large the result is. Make sure the PETSc or hypre solver is always >>>>> converging. Run with >>>>> -ksp_converged_reason and or -ksp_monitor. My guess is that the matrix >>>>> is >>>>> becoming very ill-conditioned so the solvers with the default options >>>>> are >>>>> failing. >>>>> >>>>> Barry >>>>> >>>>> >>>>> On Fri, 3 Aug 2007, Ben Tay wrote: >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> I used 2 packages to solve my poisson eqn, which is part of my NS >>>>>> unsteady >>>>>> solver. One is the NSPCG solver package which uses the compressed row >>>>>> format >>>>>> to store the A matrix. The other is PETSc. I found that using both >>>>>> solvers >>>>>> gave me similar answers for a number of time step. However, after >>>>>> that, >>>>>> the >>>>>> answer will suddenly change drastically for the PETSc case. This does >>>>>> not >>>>>> happen for the NSPCG solver. >>>>>> >>>>>> For e.g. time step 1-315, oscillating airfoil case, pressure changes >>>>>> smoothly, >>>>>> similar answers in both cases >>>>>> >>>>>> at time=316, pressure changes from -3.22 to -3.2 for NSPCG, but >>>>>> pressure >>>>>> changes from -3.21 to -60.2 for PETSc >>>>>> >>>>>> This happens when I use HYPRE's AMG or PETSc's direct solver LU. >>>>>> >>>>>> I have been trying to find out what's the cause and I can't find the >>>>>> answer in >>>>>> debugging. I would like to compare the values of the matrix of the 2 >>>>>> different >>>>>> solvers and see if there's any difference. However, NSPCG's matrix is >>>>>> in >>>>>> compressed row format while PETSc's one is just an address and it >>>>>> can't be >>>>>> viewed easily. Moreover, it's a big matrix so it's not possible to >>>>>> check >>>>>> by >>>>>> inspection. I'm thinking of subtracting one matrix by the other and >>>>>> find >>>>>> if >>>>>> it's zero. What's the best way to solve this problem? Btw, I'm using >>>>>> fortran >>>>>> and there's no mpi >>>>>> >>>>>> Thank you. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > > > From bsmith at mcs.anl.gov Sat Aug 4 20:50:55 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Sat, 4 Aug 2007 20:50:55 -0500 (CDT) Subject: Comparing between a PETSc matrix and a standard fortran array in compressed row format In-Reply-To: <46B5286F.5040002@gmail.com> References: <46B2ADEF.4050806@gmail.com> <46B3EFBF.5070909@gmail.com> <46B43912.2050509@gmail.com> <46B5286F.5040002@gmail.com> Message-ID: At the "bad step" are the two matrices and right hand sides the same? The the resulting solution vectors are different (a lot)? Is there any reason to think the matrix is (nearly) singular at that point? Barry On Sun, 5 Aug 2007, Ben Tay wrote: > Hi, > > Now I'm comparing at every time step. The A matrix and rhs of the NSPCG and > PETSc matrix are exactly the same, NORM is zero. The solutions given by both > solvers are very similar for e.g. from 1-315 time step, and varying slowly > since it is a oscillating body problem. Then strangely, at time=316, PETSc's > answer suddenly differs by a great difference. e.g. p=0.3 to 50. I must also > add that the flowfield at that time step still "looks ok". However, the large > pressure change of the pressure poisson eqn caused the computation of the > lift/drag coefficient to be erroneous. Moreover, after that, the pressure > slowly "returns back" to the same answer such that of the NSPCG solver after a > few time steps ... then after a while the sudden change happens again. In the > end, I got a cl/cd vs time graph with lots of spikes. > > I hope that the thing can be solved because the NSPCG solver is much slower > and it is not as stable. > > Thanks > > Barry Smith wrote: > > Ben, > > > > Are you comparing the two matrices at timestep 316? Also compare the > > two right hand sides at 316. Are they similar, totally different?? > > > > Barry > > > > > > On Sat, 4 Aug 2007, Ben Tay wrote: > > > > > > > Hi, > > > > > > After using MatAXPY, I used MatGetRowMaxAbs, VecAb and VecMax to get the > > > row > > > with max value, get the absolute of that value and print out the > > > location/value. I managed to find some minor mistakes and corrected them > > > so > > > that the 2 matrix are identical. Unfortunately, the same thing still > > > happens! > > > > > > I've checked for convergence and the iteration no. is 1 and 8 for direct > > > solving and HYPRE's AMG respectively. So there's no convergence problem. > > > I've > > > also tried to change to the same pc/ksp as that of NSPCG, which is jacobi > > > presconditioning + KSPBCGS but the same thing happens. > > > > > > Any idea what's happening? > > > > > > Thanks > > > > > > Barry Smith wrote: > > > > > > > Unless the matrix values are huge then this is a big difference. All > > > > you > > > > can do is print the difference matrix with ASCII MatView and > > > > look for large entries. This will tell you the locations of the trouble > > > > entries. > > > > > > > > Barry > > > > > > > > > > > > On Sat, 4 Aug 2007, Ben Tay wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > I realised that the matrix storage format of NSPCG is actually ITPACK > > > > > storage > > > > > format. Anyway, I tried to insert the values into a PETSc matrix, use > > > > > MatAXPY > > > > > with the scalar a = -1 and then use MatNorm on the output matrix. > > > > > > > > > > Using NORM_1, NORM_FROBENIUS and NORM_INFINITY > > > > > <../Vec/NORM_FROBENIUS.html#NORM_FROBENIUS>, I got ~543, 3194 and 556 > > > > > respectively. Does this mean that the matrix are different? How "much" > > > > > different does that means? > > > > > > > > > > So what is the next step? Is there anyway to find out the location of > > > > > the > > > > > value which is different? > > > > > > > > > > This is my comparison subroutine: > > > > > > > > > > subroutine matrix_compare > > > > > > > > > > !compare big_A & PETSc matrix > > > > > > > > > > integer :: k,kk,II,JJ,ierr > > > > > > > > > > Vec xx_test,b_rhs_test > > > > > Mat A_mat_test > > > > > > > > > > PetscScalar aa > > > > > > > > > > PetscReal nrm > > > > > > > > > > aa=-1. > > > > > > > > > > call > > > > > MatCreateSeqAIJ(PETSC_COMM_SELF,total_k,total_k,10,PETSC_NULL_INTEGER,A_mat_test,ierr) > > > > > > > > > > call VecCreateSeq(PETSC_COMM_SELF,total_k,b_rhs_test,ierr) > > > > > > > > > > call VecDuplicate(b_rhs_test,xx_test,ierr) > > > > > > > > > > call VecAssemblyBegin(b_rhs_test,ierr) > > > > > > > > > > call VecAssemblyEnd(b_rhs_test,ierr) > > > > > > > > > > call VecAssemblyBegin(xx_test,ierr) > > > > > > > > > > call VecAssemblyEnd(xx_test,ierr) > > > > > > > > > > do k=1,total_k > > > > > do kk=1,10 > > > > > > > > > > II=k-1 > > > > > > > > > > JJ=int_A(k,kk)-1 > > > > > call > > > > > MatSetValues(A_mat_test,1,II,1,JJ,big_A(k,kk),INSERT_VALUES,ierr) > > > > > call VecSetValue(b_rhs_test,II,q_p(k),INSERT_VALUES,ierr) > > > > > end do > > > > > > > > > > end do > > > > > > > > > > ! call MatCopy(A_mat,A_mat_test,DIFFERENT_NONZERO_PATTERN ,ierr) > > > > > > > > > > call MatAssemblyBegin(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) > > > > > call MatAssemblyEnd(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) > > > > > > > > > > call MatAXPY(A_mat_test,aa,A_mat,SAME_NONZERO_PATTERN,ierr) > > > > > > > > > > call MatNorm(A_mat_test,NORM_INFINITY,nrm,ierr) > > > > > > > > > > print *, nrm > > > > > > > > > > end subroutine matrix_compare > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > Barry Smith wrote: > > > > > > > > > > > You can use MatCreateSeqAIJWithArrays() to "convert" the NSPCG > > > > > > matrix > > > > > > into > > > > > > PETSc format and then MatAXPY() to difference them and then > > > > > > MatNorm() to > > > > > > see > > > > > > how large the result is. Make sure the PETSc or hypre solver is > > > > > > always > > > > > > converging. Run with > > > > > > -ksp_converged_reason and or -ksp_monitor. My guess is that the > > > > > > matrix > > > > > > is > > > > > > becoming very ill-conditioned so the solvers with the default > > > > > > options > > > > > > are > > > > > > failing. > > > > > > > > > > > > Barry > > > > > > > > > > > > > > > > > > On Fri, 3 Aug 2007, Ben Tay wrote: > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I used 2 packages to solve my poisson eqn, which is part of my NS > > > > > > > unsteady > > > > > > > solver. One is the NSPCG solver package which uses the compressed > > > > > > > row > > > > > > > format > > > > > > > to store the A matrix. The other is PETSc. I found that using both > > > > > > > solvers > > > > > > > gave me similar answers for a number of time step. However, after > > > > > > > that, > > > > > > > the > > > > > > > answer will suddenly change drastically for the PETSc case. This > > > > > > > does > > > > > > > not > > > > > > > happen for the NSPCG solver. > > > > > > > > > > > > > > For e.g. time step 1-315, oscillating airfoil case, pressure > > > > > > > changes > > > > > > > smoothly, > > > > > > > similar answers in both cases > > > > > > > > > > > > > > at time=316, pressure changes from -3.22 to -3.2 for NSPCG, but > > > > > > > pressure > > > > > > > changes from -3.21 to -60.2 for PETSc > > > > > > > > > > > > > > This happens when I use HYPRE's AMG or PETSc's direct solver LU. > > > > > > > > > > > > > > I have been trying to find out what's the cause and I can't find > > > > > > > the > > > > > > > answer in > > > > > > > debugging. I would like to compare the values of the matrix of the > > > > > > > 2 > > > > > > > different > > > > > > > solvers and see if there's any difference. However, NSPCG's matrix > > > > > > > is > > > > > > > in > > > > > > > compressed row format while PETSc's one is just an address and it > > > > > > > can't be > > > > > > > viewed easily. Moreover, it's a big matrix so it's not possible to > > > > > > > check > > > > > > > by > > > > > > > inspection. I'm thinking of subtracting one matrix by the other > > > > > > > and > > > > > > > find > > > > > > > if > > > > > > > it's zero. What's the best way to solve this problem? Btw, I'm > > > > > > > using > > > > > > > fortran > > > > > > > and there's no mpi > > > > > > > > > > > > > > Thank you. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From zonexo at gmail.com Sat Aug 4 21:33:00 2007 From: zonexo at gmail.com (Ben Tay) Date: Sun, 05 Aug 2007 10:33:00 +0800 Subject: Comparing between a PETSc matrix and a standard fortran array in compressed row format In-Reply-To: References: <46B2ADEF.4050806@gmail.com> <46B3EFBF.5070909@gmail.com> <46B43912.2050509@gmail.com> <46B5286F.5040002@gmail.com> Message-ID: <46B536DC.4000400@gmail.com> Well, ya, they're the same ... that's why I don't know what's wrong. Is there any way to check on singularity? The iteration no. is only 8 for AMG and LU direct solver works. .. Thanks Barry Smith wrote: > At the "bad step" are the two matrices and right hand sides the same? > The the resulting solution vectors are different (a lot)? Is there any > reason to think the matrix is (nearly) singular at that point? > > Barry > > > > On Sun, 5 Aug 2007, Ben Tay wrote: > > >> Hi, >> >> Now I'm comparing at every time step. The A matrix and rhs of the NSPCG and >> PETSc matrix are exactly the same, NORM is zero. The solutions given by both >> solvers are very similar for e.g. from 1-315 time step, and varying slowly >> since it is a oscillating body problem. Then strangely, at time=316, PETSc's >> answer suddenly differs by a great difference. e.g. p=0.3 to 50. I must also >> add that the flowfield at that time step still "looks ok". However, the large >> pressure change of the pressure poisson eqn caused the computation of the >> lift/drag coefficient to be erroneous. Moreover, after that, the pressure >> slowly "returns back" to the same answer such that of the NSPCG solver after a >> few time steps ... then after a while the sudden change happens again. In the >> end, I got a cl/cd vs time graph with lots of spikes. >> >> I hope that the thing can be solved because the NSPCG solver is much slower >> and it is not as stable. >> >> Thanks >> >> Barry Smith wrote: >> >>> Ben, >>> >>> Are you comparing the two matrices at timestep 316? Also compare the >>> two right hand sides at 316. Are they similar, totally different?? >>> >>> Barry >>> >>> >>> On Sat, 4 Aug 2007, Ben Tay wrote: >>> >>> >>> >>>> Hi, >>>> >>>> After using MatAXPY, I used MatGetRowMaxAbs, VecAb and VecMax to get the >>>> row >>>> with max value, get the absolute of that value and print out the >>>> location/value. I managed to find some minor mistakes and corrected them >>>> so >>>> that the 2 matrix are identical. Unfortunately, the same thing still >>>> happens! >>>> >>>> I've checked for convergence and the iteration no. is 1 and 8 for direct >>>> solving and HYPRE's AMG respectively. So there's no convergence problem. >>>> I've >>>> also tried to change to the same pc/ksp as that of NSPCG, which is jacobi >>>> presconditioning + KSPBCGS but the same thing happens. >>>> >>>> Any idea what's happening? >>>> >>>> Thanks >>>> >>>> Barry Smith wrote: >>>> >>>> >>>>> Unless the matrix values are huge then this is a big difference. All >>>>> you >>>>> can do is print the difference matrix with ASCII MatView and >>>>> look for large entries. This will tell you the locations of the trouble >>>>> entries. >>>>> >>>>> Barry >>>>> >>>>> >>>>> On Sat, 4 Aug 2007, Ben Tay wrote: >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> I realised that the matrix storage format of NSPCG is actually ITPACK >>>>>> storage >>>>>> format. Anyway, I tried to insert the values into a PETSc matrix, use >>>>>> MatAXPY >>>>>> with the scalar a = -1 and then use MatNorm on the output matrix. >>>>>> >>>>>> Using NORM_1, NORM_FROBENIUS and NORM_INFINITY >>>>>> <../Vec/NORM_FROBENIUS.html#NORM_FROBENIUS>, I got ~543, 3194 and 556 >>>>>> respectively. Does this mean that the matrix are different? How "much" >>>>>> different does that means? >>>>>> >>>>>> So what is the next step? Is there anyway to find out the location of >>>>>> the >>>>>> value which is different? >>>>>> >>>>>> This is my comparison subroutine: >>>>>> >>>>>> subroutine matrix_compare >>>>>> >>>>>> !compare big_A & PETSc matrix >>>>>> >>>>>> integer :: k,kk,II,JJ,ierr >>>>>> >>>>>> Vec xx_test,b_rhs_test >>>>>> Mat A_mat_test >>>>>> >>>>>> PetscScalar aa >>>>>> >>>>>> PetscReal nrm >>>>>> >>>>>> aa=-1. >>>>>> >>>>>> call >>>>>> MatCreateSeqAIJ(PETSC_COMM_SELF,total_k,total_k,10,PETSC_NULL_INTEGER,A_mat_test,ierr) >>>>>> >>>>>> call VecCreateSeq(PETSC_COMM_SELF,total_k,b_rhs_test,ierr) >>>>>> >>>>>> call VecDuplicate(b_rhs_test,xx_test,ierr) >>>>>> >>>>>> call VecAssemblyBegin(b_rhs_test,ierr) >>>>>> >>>>>> call VecAssemblyEnd(b_rhs_test,ierr) >>>>>> >>>>>> call VecAssemblyBegin(xx_test,ierr) >>>>>> >>>>>> call VecAssemblyEnd(xx_test,ierr) >>>>>> >>>>>> do k=1,total_k >>>>>> do kk=1,10 >>>>>> >>>>>> II=k-1 >>>>>> >>>>>> JJ=int_A(k,kk)-1 >>>>>> call >>>>>> MatSetValues(A_mat_test,1,II,1,JJ,big_A(k,kk),INSERT_VALUES,ierr) >>>>>> call VecSetValue(b_rhs_test,II,q_p(k),INSERT_VALUES,ierr) >>>>>> end do >>>>>> >>>>>> end do >>>>>> >>>>>> ! call MatCopy(A_mat,A_mat_test,DIFFERENT_NONZERO_PATTERN ,ierr) >>>>>> >>>>>> call MatAssemblyBegin(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) >>>>>> call MatAssemblyEnd(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) >>>>>> >>>>>> call MatAXPY(A_mat_test,aa,A_mat,SAME_NONZERO_PATTERN,ierr) >>>>>> >>>>>> call MatNorm(A_mat_test,NORM_INFINITY,nrm,ierr) >>>>>> >>>>>> print *, nrm >>>>>> >>>>>> end subroutine matrix_compare >>>>>> >>>>>> Thanks! >>>>>> >>>>>> >>>>>> >>>>>> Barry Smith wrote: >>>>>> >>>>>> >>>>>>> You can use MatCreateSeqAIJWithArrays() to "convert" the NSPCG >>>>>>> matrix >>>>>>> into >>>>>>> PETSc format and then MatAXPY() to difference them and then >>>>>>> MatNorm() to >>>>>>> see >>>>>>> how large the result is. Make sure the PETSc or hypre solver is >>>>>>> always >>>>>>> converging. Run with >>>>>>> -ksp_converged_reason and or -ksp_monitor. My guess is that the >>>>>>> matrix >>>>>>> is >>>>>>> becoming very ill-conditioned so the solvers with the default >>>>>>> options >>>>>>> are >>>>>>> failing. >>>>>>> >>>>>>> Barry >>>>>>> >>>>>>> >>>>>>> On Fri, 3 Aug 2007, Ben Tay wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I used 2 packages to solve my poisson eqn, which is part of my NS >>>>>>>> unsteady >>>>>>>> solver. One is the NSPCG solver package which uses the compressed >>>>>>>> row >>>>>>>> format >>>>>>>> to store the A matrix. The other is PETSc. I found that using both >>>>>>>> solvers >>>>>>>> gave me similar answers for a number of time step. However, after >>>>>>>> that, >>>>>>>> the >>>>>>>> answer will suddenly change drastically for the PETSc case. This >>>>>>>> does >>>>>>>> not >>>>>>>> happen for the NSPCG solver. >>>>>>>> >>>>>>>> For e.g. time step 1-315, oscillating airfoil case, pressure >>>>>>>> changes >>>>>>>> smoothly, >>>>>>>> similar answers in both cases >>>>>>>> >>>>>>>> at time=316, pressure changes from -3.22 to -3.2 for NSPCG, but >>>>>>>> pressure >>>>>>>> changes from -3.21 to -60.2 for PETSc >>>>>>>> >>>>>>>> This happens when I use HYPRE's AMG or PETSc's direct solver LU. >>>>>>>> >>>>>>>> I have been trying to find out what's the cause and I can't find >>>>>>>> the >>>>>>>> answer in >>>>>>>> debugging. I would like to compare the values of the matrix of the >>>>>>>> 2 >>>>>>>> different >>>>>>>> solvers and see if there's any difference. However, NSPCG's matrix >>>>>>>> is >>>>>>>> in >>>>>>>> compressed row format while PETSc's one is just an address and it >>>>>>>> can't be >>>>>>>> viewed easily. Moreover, it's a big matrix so it's not possible to >>>>>>>> check >>>>>>>> by >>>>>>>> inspection. I'm thinking of subtracting one matrix by the other >>>>>>>> and >>>>>>>> find >>>>>>>> if >>>>>>>> it's zero. What's the best way to solve this problem? Btw, I'm >>>>>>>> using >>>>>>>> fortran >>>>>>>> and there's no mpi >>>>>>>> >>>>>>>> Thank you. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > > > From bsmith at mcs.anl.gov Sun Aug 5 10:58:58 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Sun, 5 Aug 2007 10:58:58 -0500 (CDT) Subject: Comparing between a PETSc matrix and a standard fortran array in compressed row format In-Reply-To: <46B536DC.4000400@gmail.com> References: <46B2ADEF.4050806@gmail.com> <46B3EFBF.5070909@gmail.com> <46B43912.2050509@gmail.com> <46B5286F.5040002@gmail.com> <46B536DC.4000400@gmail.com> Message-ID: Run with -ksp_type gmres -pc_type lu -ksp_monitor_true_residual -ksp_truemonitor At the bad iteration verify if the true residual is very small. Barry On Sun, 5 Aug 2007, Ben Tay wrote: > Well, ya, they're the same ... that's why I don't know what's wrong. Is there > any way to check on singularity? The iteration no. is only 8 for AMG and LU > direct solver works. .. > > > Thanks > > Barry Smith wrote: > > At the "bad step" are the two matrices and right hand sides the same? > > The the resulting solution vectors are different (a lot)? Is there any > > reason to think the matrix is (nearly) singular at that point? > > > > Barry > > > > > > > > On Sun, 5 Aug 2007, Ben Tay wrote: > > > > > > > Hi, > > > > > > Now I'm comparing at every time step. The A matrix and rhs of the NSPCG > > > and > > > PETSc matrix are exactly the same, NORM is zero. The solutions given by > > > both > > > solvers are very similar for e.g. from 1-315 time step, and varying slowly > > > since it is a oscillating body problem. Then strangely, at time=316, > > > PETSc's > > > answer suddenly differs by a great difference. e.g. p=0.3 to 50. I must > > > also > > > add that the flowfield at that time step still "looks ok". However, the > > > large > > > pressure change of the pressure poisson eqn caused the computation of the > > > lift/drag coefficient to be erroneous. Moreover, after that, the pressure > > > slowly "returns back" to the same answer such that of the NSPCG solver > > > after a > > > few time steps ... then after a while the sudden change happens again. In > > > the > > > end, I got a cl/cd vs time graph with lots of spikes. > > > > > > I hope that the thing can be solved because the NSPCG solver is much > > > slower > > > and it is not as stable. > > > > > > Thanks > > > > > > Barry Smith wrote: > > > > > > > Ben, > > > > > > > > Are you comparing the two matrices at timestep 316? Also compare the > > > > two right hand sides at 316. Are they similar, totally different?? > > > > > > > > Barry > > > > > > > > > > > > On Sat, 4 Aug 2007, Ben Tay wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > After using MatAXPY, I used MatGetRowMaxAbs, VecAb and VecMax to get > > > > > the > > > > > row > > > > > with max value, get the absolute of that value and print out the > > > > > location/value. I managed to find some minor mistakes and corrected > > > > > them > > > > > so > > > > > that the 2 matrix are identical. Unfortunately, the same thing still > > > > > happens! > > > > > > > > > > I've checked for convergence and the iteration no. is 1 and 8 for > > > > > direct > > > > > solving and HYPRE's AMG respectively. So there's no convergence > > > > > problem. > > > > > I've > > > > > also tried to change to the same pc/ksp as that of NSPCG, which is > > > > > jacobi > > > > > presconditioning + KSPBCGS but the same thing happens. > > > > > > > > > > Any idea what's happening? > > > > > > > > > > Thanks > > > > > > > > > > Barry Smith wrote: > > > > > > > > > > > Unless the matrix values are huge then this is a big difference. > > > > > > All > > > > > > you > > > > > > can do is print the difference matrix with ASCII MatView and > > > > > > look for large entries. This will tell you the locations of the > > > > > > trouble > > > > > > entries. > > > > > > > > > > > > Barry > > > > > > > > > > > > > > > > > > On Sat, 4 Aug 2007, Ben Tay wrote: > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I realised that the matrix storage format of NSPCG is actually > > > > > > > ITPACK > > > > > > > storage > > > > > > > format. Anyway, I tried to insert the values into a PETSc matrix, > > > > > > > use > > > > > > > MatAXPY > > > > > > > with the scalar a = -1 and then use MatNorm on the output matrix. > > > > > > > > > > > > > > Using NORM_1, NORM_FROBENIUS and NORM_INFINITY > > > > > > > <../Vec/NORM_FROBENIUS.html#NORM_FROBENIUS>, I got ~543, 3194 and > > > > > > > 556 > > > > > > > respectively. Does this mean that the matrix are different? How > > > > > > > "much" > > > > > > > different does that means? > > > > > > > > > > > > > > So what is the next step? Is there anyway to find out the location > > > > > > > of > > > > > > > the > > > > > > > value which is different? > > > > > > > > > > > > > > This is my comparison subroutine: > > > > > > > > > > > > > > subroutine matrix_compare > > > > > > > > > > > > > > !compare big_A & PETSc matrix > > > > > > > > > > > > > > integer :: k,kk,II,JJ,ierr > > > > > > > > > > > > > > Vec xx_test,b_rhs_test > > > > > > > Mat A_mat_test > > > > > > > > > > > > > > PetscScalar aa > > > > > > > > > > > > > > PetscReal nrm > > > > > > > > > > > > > > aa=-1. > > > > > > > > > > > > > > call > > > > > > > MatCreateSeqAIJ(PETSC_COMM_SELF,total_k,total_k,10,PETSC_NULL_INTEGER,A_mat_test,ierr) > > > > > > > > > > > > > > call VecCreateSeq(PETSC_COMM_SELF,total_k,b_rhs_test,ierr) > > > > > > > > > > > > > > call VecDuplicate(b_rhs_test,xx_test,ierr) > > > > > > > > > > > > > > call VecAssemblyBegin(b_rhs_test,ierr) > > > > > > > > > > > > > > call VecAssemblyEnd(b_rhs_test,ierr) > > > > > > > > > > > > > > call VecAssemblyBegin(xx_test,ierr) > > > > > > > > > > > > > > call VecAssemblyEnd(xx_test,ierr) > > > > > > > > > > > > > > do k=1,total_k > > > > > > > do kk=1,10 > > > > > > > > > > > > > > II=k-1 > > > > > > > > > > > > > > JJ=int_A(k,kk)-1 > > > > > > > call > > > > > > > MatSetValues(A_mat_test,1,II,1,JJ,big_A(k,kk),INSERT_VALUES,ierr) > > > > > > > call VecSetValue(b_rhs_test,II,q_p(k),INSERT_VALUES,ierr) > > > > > > > end do > > > > > > > > > > > > > > end do > > > > > > > > > > > > > > ! call MatCopy(A_mat,A_mat_test,DIFFERENT_NONZERO_PATTERN > > > > > > > ,ierr) > > > > > > > > > > > > > > call MatAssemblyBegin(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) > > > > > > > call MatAssemblyEnd(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) > > > > > > > > > > > > > > call MatAXPY(A_mat_test,aa,A_mat,SAME_NONZERO_PATTERN,ierr) > > > > > > > > > > > > > > call MatNorm(A_mat_test,NORM_INFINITY,nrm,ierr) > > > > > > > > > > > > > > print *, nrm > > > > > > > > > > > > > > end subroutine matrix_compare > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barry Smith wrote: > > > > > > > > > > > > > > > You can use MatCreateSeqAIJWithArrays() to "convert" the NSPCG > > > > > > > > matrix > > > > > > > > into > > > > > > > > PETSc format and then MatAXPY() to difference them and then > > > > > > > > MatNorm() to > > > > > > > > see > > > > > > > > how large the result is. Make sure the PETSc or hypre solver > > > > > > > > is > > > > > > > > always > > > > > > > > converging. Run with > > > > > > > > -ksp_converged_reason and or -ksp_monitor. My guess is that the > > > > > > > > matrix > > > > > > > > is > > > > > > > > becoming very ill-conditioned so the solvers with the default > > > > > > > > options > > > > > > > > are > > > > > > > > failing. > > > > > > > > > > > > > > > > Barry > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 3 Aug 2007, Ben Tay wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > I used 2 packages to solve my poisson eqn, which is part of my > > > > > > > > > NS > > > > > > > > > unsteady > > > > > > > > > solver. One is the NSPCG solver package which uses the > > > > > > > > > compressed > > > > > > > > > row > > > > > > > > > format > > > > > > > > > to store the A matrix. The other is PETSc. I found that using > > > > > > > > > both > > > > > > > > > solvers > > > > > > > > > gave me similar answers for a number of time step. However, > > > > > > > > > after > > > > > > > > > that, > > > > > > > > > the > > > > > > > > > answer will suddenly change drastically for the PETSc case. > > > > > > > > > This > > > > > > > > > does > > > > > > > > > not > > > > > > > > > happen for the NSPCG solver. > > > > > > > > > > > > > > > > > > For e.g. time step 1-315, oscillating airfoil case, pressure > > > > > > > > > changes > > > > > > > > > smoothly, > > > > > > > > > similar answers in both cases > > > > > > > > > > > > > > > > > > at time=316, pressure changes from -3.22 to -3.2 for NSPCG, > > > > > > > > > but > > > > > > > > > pressure > > > > > > > > > changes from -3.21 to -60.2 for PETSc > > > > > > > > > > > > > > > > > > This happens when I use HYPRE's AMG or PETSc's direct solver > > > > > > > > > LU. > > > > > > > > > > > > > > > > > > I have been trying to find out what's the cause and I can't > > > > > > > > > find > > > > > > > > > the > > > > > > > > > answer in > > > > > > > > > debugging. I would like to compare the values of the matrix of > > > > > > > > > the > > > > > > > > > 2 > > > > > > > > > different > > > > > > > > > solvers and see if there's any difference. However, NSPCG's > > > > > > > > > matrix > > > > > > > > > is > > > > > > > > > in > > > > > > > > > compressed row format while PETSc's one is just an address and > > > > > > > > > it > > > > > > > > > can't be > > > > > > > > > viewed easily. Moreover, it's a big matrix so it's not > > > > > > > > > possible to > > > > > > > > > check > > > > > > > > > by > > > > > > > > > inspection. I'm thinking of subtracting one matrix by the > > > > > > > > > other > > > > > > > > > and > > > > > > > > > find > > > > > > > > > if > > > > > > > > > it's zero. What's the best way to solve this problem? Btw, I'm > > > > > > > > > using > > > > > > > > > fortran > > > > > > > > > and there's no mpi > > > > > > > > > > > > > > > > > > Thank you. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From zonexo at gmail.com Sun Aug 5 20:04:37 2007 From: zonexo at gmail.com (Ben Tay) Date: Mon, 06 Aug 2007 09:04:37 +0800 Subject: Comparing between a PETSc matrix and a standard fortran array in compressed row format In-Reply-To: References: <46B2ADEF.4050806@gmail.com> <46B3EFBF.5070909@gmail.com> <46B43912.2050509@gmail.com> <46B5286F.5040002@gmail.com> <46B536DC.4000400@gmail.com> Message-ID: <46B673A5.7020206@gmail.com> Well, here's what I got: 0 KSP preconditioned resid norm 1.498836640002e+04 true resid norm 1.531062859147e+03 ||Ae||/||Ax|| 9.947622397959e-01 1 KSP preconditioned resid norm 4.832736106865e-08 true resid norm 2.037181386899e-09 ||Ae||/||Ax|| 1.323597595746e-12 Looks like everything's ok.... right? Any other suggestion? Thanks. Barry Smith wrote: > Run with -ksp_type gmres -pc_type lu -ksp_monitor_true_residual -ksp_truemonitor > > At the bad iteration verify if the true residual is very small. > > Barry > > > On Sun, 5 Aug 2007, Ben Tay wrote: > > >> Well, ya, they're the same ... that's why I don't know what's wrong. Is there >> any way to check on singularity? The iteration no. is only 8 for AMG and LU >> direct solver works. .. >> >> >> Thanks >> >> Barry Smith wrote: >> >>> At the "bad step" are the two matrices and right hand sides the same? >>> The the resulting solution vectors are different (a lot)? Is there any >>> reason to think the matrix is (nearly) singular at that point? >>> >>> Barry >>> >>> >>> >>> On Sun, 5 Aug 2007, Ben Tay wrote: >>> >>> >>> >>>> Hi, >>>> >>>> Now I'm comparing at every time step. The A matrix and rhs of the NSPCG >>>> and >>>> PETSc matrix are exactly the same, NORM is zero. The solutions given by >>>> both >>>> solvers are very similar for e.g. from 1-315 time step, and varying slowly >>>> since it is a oscillating body problem. Then strangely, at time=316, >>>> PETSc's >>>> answer suddenly differs by a great difference. e.g. p=0.3 to 50. I must >>>> also >>>> add that the flowfield at that time step still "looks ok". However, the >>>> large >>>> pressure change of the pressure poisson eqn caused the computation of the >>>> lift/drag coefficient to be erroneous. Moreover, after that, the pressure >>>> slowly "returns back" to the same answer such that of the NSPCG solver >>>> after a >>>> few time steps ... then after a while the sudden change happens again. In >>>> the >>>> end, I got a cl/cd vs time graph with lots of spikes. >>>> >>>> I hope that the thing can be solved because the NSPCG solver is much >>>> slower >>>> and it is not as stable. >>>> >>>> Thanks >>>> >>>> Barry Smith wrote: >>>> >>>> >>>>> Ben, >>>>> >>>>> Are you comparing the two matrices at timestep 316? Also compare the >>>>> two right hand sides at 316. Are they similar, totally different?? >>>>> >>>>> Barry >>>>> >>>>> >>>>> On Sat, 4 Aug 2007, Ben Tay wrote: >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> After using MatAXPY, I used MatGetRowMaxAbs, VecAb and VecMax to get >>>>>> the >>>>>> row >>>>>> with max value, get the absolute of that value and print out the >>>>>> location/value. I managed to find some minor mistakes and corrected >>>>>> them >>>>>> so >>>>>> that the 2 matrix are identical. Unfortunately, the same thing still >>>>>> happens! >>>>>> >>>>>> I've checked for convergence and the iteration no. is 1 and 8 for >>>>>> direct >>>>>> solving and HYPRE's AMG respectively. So there's no convergence >>>>>> problem. >>>>>> I've >>>>>> also tried to change to the same pc/ksp as that of NSPCG, which is >>>>>> jacobi >>>>>> presconditioning + KSPBCGS but the same thing happens. >>>>>> >>>>>> Any idea what's happening? >>>>>> >>>>>> Thanks >>>>>> >>>>>> Barry Smith wrote: >>>>>> >>>>>> >>>>>>> Unless the matrix values are huge then this is a big difference. >>>>>>> All >>>>>>> you >>>>>>> can do is print the difference matrix with ASCII MatView and >>>>>>> look for large entries. This will tell you the locations of the >>>>>>> trouble >>>>>>> entries. >>>>>>> >>>>>>> Barry >>>>>>> >>>>>>> >>>>>>> On Sat, 4 Aug 2007, Ben Tay wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I realised that the matrix storage format of NSPCG is actually >>>>>>>> ITPACK >>>>>>>> storage >>>>>>>> format. Anyway, I tried to insert the values into a PETSc matrix, >>>>>>>> use >>>>>>>> MatAXPY >>>>>>>> with the scalar a = -1 and then use MatNorm on the output matrix. >>>>>>>> >>>>>>>> Using NORM_1, NORM_FROBENIUS and NORM_INFINITY >>>>>>>> <../Vec/NORM_FROBENIUS.html#NORM_FROBENIUS>, I got ~543, 3194 and >>>>>>>> 556 >>>>>>>> respectively. Does this mean that the matrix are different? How >>>>>>>> "much" >>>>>>>> different does that means? >>>>>>>> >>>>>>>> So what is the next step? Is there anyway to find out the location >>>>>>>> of >>>>>>>> the >>>>>>>> value which is different? >>>>>>>> >>>>>>>> This is my comparison subroutine: >>>>>>>> >>>>>>>> subroutine matrix_compare >>>>>>>> >>>>>>>> !compare big_A & PETSc matrix >>>>>>>> >>>>>>>> integer :: k,kk,II,JJ,ierr >>>>>>>> >>>>>>>> Vec xx_test,b_rhs_test >>>>>>>> Mat A_mat_test >>>>>>>> >>>>>>>> PetscScalar aa >>>>>>>> >>>>>>>> PetscReal nrm >>>>>>>> >>>>>>>> aa=-1. >>>>>>>> >>>>>>>> call >>>>>>>> MatCreateSeqAIJ(PETSC_COMM_SELF,total_k,total_k,10,PETSC_NULL_INTEGER,A_mat_test,ierr) >>>>>>>> >>>>>>>> call VecCreateSeq(PETSC_COMM_SELF,total_k,b_rhs_test,ierr) >>>>>>>> >>>>>>>> call VecDuplicate(b_rhs_test,xx_test,ierr) >>>>>>>> >>>>>>>> call VecAssemblyBegin(b_rhs_test,ierr) >>>>>>>> >>>>>>>> call VecAssemblyEnd(b_rhs_test,ierr) >>>>>>>> >>>>>>>> call VecAssemblyBegin(xx_test,ierr) >>>>>>>> >>>>>>>> call VecAssemblyEnd(xx_test,ierr) >>>>>>>> >>>>>>>> do k=1,total_k >>>>>>>> do kk=1,10 >>>>>>>> >>>>>>>> II=k-1 >>>>>>>> >>>>>>>> JJ=int_A(k,kk)-1 >>>>>>>> call >>>>>>>> MatSetValues(A_mat_test,1,II,1,JJ,big_A(k,kk),INSERT_VALUES,ierr) >>>>>>>> call VecSetValue(b_rhs_test,II,q_p(k),INSERT_VALUES,ierr) >>>>>>>> end do >>>>>>>> >>>>>>>> end do >>>>>>>> >>>>>>>> ! call MatCopy(A_mat,A_mat_test,DIFFERENT_NONZERO_PATTERN >>>>>>>> ,ierr) >>>>>>>> >>>>>>>> call MatAssemblyBegin(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) >>>>>>>> call MatAssemblyEnd(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) >>>>>>>> >>>>>>>> call MatAXPY(A_mat_test,aa,A_mat,SAME_NONZERO_PATTERN,ierr) >>>>>>>> >>>>>>>> call MatNorm(A_mat_test,NORM_INFINITY,nrm,ierr) >>>>>>>> >>>>>>>> print *, nrm >>>>>>>> >>>>>>>> end subroutine matrix_compare >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Barry Smith wrote: >>>>>>>> >>>>>>>> >>>>>>>>> You can use MatCreateSeqAIJWithArrays() to "convert" the NSPCG >>>>>>>>> matrix >>>>>>>>> into >>>>>>>>> PETSc format and then MatAXPY() to difference them and then >>>>>>>>> MatNorm() to >>>>>>>>> see >>>>>>>>> how large the result is. Make sure the PETSc or hypre solver >>>>>>>>> is >>>>>>>>> always >>>>>>>>> converging. Run with >>>>>>>>> -ksp_converged_reason and or -ksp_monitor. My guess is that the >>>>>>>>> matrix >>>>>>>>> is >>>>>>>>> becoming very ill-conditioned so the solvers with the default >>>>>>>>> options >>>>>>>>> are >>>>>>>>> failing. >>>>>>>>> >>>>>>>>> Barry >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, 3 Aug 2007, Ben Tay wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I used 2 packages to solve my poisson eqn, which is part of my >>>>>>>>>> NS >>>>>>>>>> unsteady >>>>>>>>>> solver. One is the NSPCG solver package which uses the >>>>>>>>>> compressed >>>>>>>>>> row >>>>>>>>>> format >>>>>>>>>> to store the A matrix. The other is PETSc. I found that using >>>>>>>>>> both >>>>>>>>>> solvers >>>>>>>>>> gave me similar answers for a number of time step. However, >>>>>>>>>> after >>>>>>>>>> that, >>>>>>>>>> the >>>>>>>>>> answer will suddenly change drastically for the PETSc case. >>>>>>>>>> This >>>>>>>>>> does >>>>>>>>>> not >>>>>>>>>> happen for the NSPCG solver. >>>>>>>>>> >>>>>>>>>> For e.g. time step 1-315, oscillating airfoil case, pressure >>>>>>>>>> changes >>>>>>>>>> smoothly, >>>>>>>>>> similar answers in both cases >>>>>>>>>> >>>>>>>>>> at time=316, pressure changes from -3.22 to -3.2 for NSPCG, >>>>>>>>>> but >>>>>>>>>> pressure >>>>>>>>>> changes from -3.21 to -60.2 for PETSc >>>>>>>>>> >>>>>>>>>> This happens when I use HYPRE's AMG or PETSc's direct solver >>>>>>>>>> LU. >>>>>>>>>> >>>>>>>>>> I have been trying to find out what's the cause and I can't >>>>>>>>>> find >>>>>>>>>> the >>>>>>>>>> answer in >>>>>>>>>> debugging. I would like to compare the values of the matrix of >>>>>>>>>> the >>>>>>>>>> 2 >>>>>>>>>> different >>>>>>>>>> solvers and see if there's any difference. However, NSPCG's >>>>>>>>>> matrix >>>>>>>>>> is >>>>>>>>>> in >>>>>>>>>> compressed row format while PETSc's one is just an address and >>>>>>>>>> it >>>>>>>>>> can't be >>>>>>>>>> viewed easily. Moreover, it's a big matrix so it's not >>>>>>>>>> possible to >>>>>>>>>> check >>>>>>>>>> by >>>>>>>>>> inspection. I'm thinking of subtracting one matrix by the >>>>>>>>>> other >>>>>>>>>> and >>>>>>>>>> find >>>>>>>>>> if >>>>>>>>>> it's zero. What's the best way to solve this problem? Btw, I'm >>>>>>>>>> using >>>>>>>>>> fortran >>>>>>>>>> and there's no mpi >>>>>>>>>> >>>>>>>>>> Thank you. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > > > From bsmith at mcs.anl.gov Sun Aug 5 20:07:52 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Sun, 5 Aug 2007 20:07:52 -0500 (CDT) Subject: Comparing between a PETSc matrix and a standard fortran array in compressed row format In-Reply-To: <46B673A5.7020206@gmail.com> References: <46B2ADEF.4050806@gmail.com> <46B3EFBF.5070909@gmail.com> <46B43912.2050509@gmail.com> <46B5286F.5040002@gmail.com> <46B536DC.4000400@gmail.com> <46B673A5.7020206@gmail.com> Message-ID: Looks ok to me. Did you compare the right hand side and solution for the two codes at that iteration? On Mon, 6 Aug 2007, Ben Tay wrote: > Well, here's what I got: > > 0 KSP preconditioned resid norm 1.498836640002e+04 true resid norm > 1.531062859147e+03 ||Ae||/||Ax|| 9.947622397959e-01 > 1 KSP preconditioned resid norm 4.832736106865e-08 true resid norm > 2.037181386899e-09 ||Ae||/||Ax|| 1.323597595746e-12 > > Looks like everything's ok.... right? > > Any other suggestion? > > Thanks. > > Barry Smith wrote: > > Run with -ksp_type gmres -pc_type lu -ksp_monitor_true_residual > > -ksp_truemonitor > > > > At the bad iteration verify if the true residual is very small. > > > > Barry > > > > > > On Sun, 5 Aug 2007, Ben Tay wrote: > > > > > > > Well, ya, they're the same ... that's why I don't know what's wrong. Is > > > there > > > any way to check on singularity? The iteration no. is only 8 for AMG and > > > LU > > > direct solver works. .. > > > > > > > > > Thanks > > > > > > Barry Smith wrote: > > > > > > > At the "bad step" are the two matrices and right hand sides the same? > > > > The the resulting solution vectors are different (a lot)? Is there any > > > > reason to think the matrix is (nearly) singular at that point? > > > > > > > > Barry > > > > > > > > > > > > > > > > On Sun, 5 Aug 2007, Ben Tay wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > Now I'm comparing at every time step. The A matrix and rhs of the > > > > > NSPCG > > > > > and > > > > > PETSc matrix are exactly the same, NORM is zero. The solutions given > > > > > by > > > > > both > > > > > solvers are very similar for e.g. from 1-315 time step, and varying > > > > > slowly > > > > > since it is a oscillating body problem. Then strangely, at time=316, > > > > > PETSc's > > > > > answer suddenly differs by a great difference. e.g. p=0.3 to 50. I > > > > > must > > > > > also > > > > > add that the flowfield at that time step still "looks ok". However, > > > > > the > > > > > large > > > > > pressure change of the pressure poisson eqn caused the computation of > > > > > the > > > > > lift/drag coefficient to be erroneous. Moreover, after that, the > > > > > pressure > > > > > slowly "returns back" to the same answer such that of the NSPCG solver > > > > > after a > > > > > few time steps ... then after a while the sudden change happens again. > > > > > In > > > > > the > > > > > end, I got a cl/cd vs time graph with lots of spikes. > > > > > > > > > > I hope that the thing can be solved because the NSPCG solver is much > > > > > slower > > > > > and it is not as stable. > > > > > > > > > > Thanks > > > > > > > > > > Barry Smith wrote: > > > > > > > > > > > Ben, > > > > > > > > > > > > Are you comparing the two matrices at timestep 316? Also compare > > > > > > the > > > > > > two right hand sides at 316. Are they similar, totally different?? > > > > > > > > > > > > Barry > > > > > > > > > > > > > > > > > > On Sat, 4 Aug 2007, Ben Tay wrote: > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > After using MatAXPY, I used MatGetRowMaxAbs, VecAb and VecMax to > > > > > > > get > > > > > > > the > > > > > > > row > > > > > > > with max value, get the absolute of that value and print out the > > > > > > > location/value. I managed to find some minor mistakes and > > > > > > > corrected > > > > > > > them > > > > > > > so > > > > > > > that the 2 matrix are identical. Unfortunately, the same thing > > > > > > > still > > > > > > > happens! > > > > > > > > > > > > > > I've checked for convergence and the iteration no. is 1 and 8 for > > > > > > > direct > > > > > > > solving and HYPRE's AMG respectively. So there's no convergence > > > > > > > problem. > > > > > > > I've > > > > > > > also tried to change to the same pc/ksp as that of NSPCG, which is > > > > > > > jacobi > > > > > > > presconditioning + KSPBCGS but the same thing happens. > > > > > > > > > > > > > > Any idea what's happening? > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > Barry Smith wrote: > > > > > > > > > > > > > > > Unless the matrix values are huge then this is a big > > > > > > > > difference. > > > > > > > > All > > > > > > > > you > > > > > > > > can do is print the difference matrix with ASCII MatView and > > > > > > > > look for large entries. This will tell you the locations of the > > > > > > > > trouble > > > > > > > > entries. > > > > > > > > > > > > > > > > Barry > > > > > > > > > > > > > > > > > > > > > > > > On Sat, 4 Aug 2007, Ben Tay wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > I realised that the matrix storage format of NSPCG is actually > > > > > > > > > ITPACK > > > > > > > > > storage > > > > > > > > > format. Anyway, I tried to insert the values into a PETSc > > > > > > > > > matrix, > > > > > > > > > use > > > > > > > > > MatAXPY > > > > > > > > > with the scalar a = -1 and then use MatNorm on the output > > > > > > > > > matrix. > > > > > > > > > > > > > > > > > > Using NORM_1, NORM_FROBENIUS and NORM_INFINITY > > > > > > > > > <../Vec/NORM_FROBENIUS.html#NORM_FROBENIUS>, I got ~543, 3194 > > > > > > > > > and > > > > > > > > > 556 > > > > > > > > > respectively. Does this mean that the matrix are different? > > > > > > > > > How > > > > > > > > > "much" > > > > > > > > > different does that means? > > > > > > > > > > > > > > > > > > So what is the next step? Is there anyway to find out the > > > > > > > > > location > > > > > > > > > of > > > > > > > > > the > > > > > > > > > value which is different? > > > > > > > > > > > > > > > > > > This is my comparison subroutine: > > > > > > > > > > > > > > > > > > subroutine matrix_compare > > > > > > > > > > > > > > > > > > !compare big_A & PETSc matrix > > > > > > > > > > > > > > > > > > integer :: k,kk,II,JJ,ierr > > > > > > > > > > > > > > > > > > Vec xx_test,b_rhs_test > > > > > > > > > Mat A_mat_test > > > > > > > > > > > > > > > > > > PetscScalar aa > > > > > > > > > > > > > > > > > > PetscReal nrm > > > > > > > > > > > > > > > > > > aa=-1. > > > > > > > > > > > > > > > > > > call > > > > > > > > > MatCreateSeqAIJ(PETSC_COMM_SELF,total_k,total_k,10,PETSC_NULL_INTEGER,A_mat_test,ierr) > > > > > > > > > > > > > > > > > > call VecCreateSeq(PETSC_COMM_SELF,total_k,b_rhs_test,ierr) > > > > > > > > > > > > > > > > > > call VecDuplicate(b_rhs_test,xx_test,ierr) > > > > > > > > > > > > > > > > > > call VecAssemblyBegin(b_rhs_test,ierr) > > > > > > > > > > > > > > > > > > call VecAssemblyEnd(b_rhs_test,ierr) > > > > > > > > > > > > > > > > > > call VecAssemblyBegin(xx_test,ierr) > > > > > > > > > > > > > > > > > > call VecAssemblyEnd(xx_test,ierr) > > > > > > > > > > > > > > > > > > do k=1,total_k > > > > > > > > > do kk=1,10 > > > > > > > > > > > > > > > > > > II=k-1 > > > > > > > > > > > > > > > > > > JJ=int_A(k,kk)-1 > > > > > > > > > call > > > > > > > > > MatSetValues(A_mat_test,1,II,1,JJ,big_A(k,kk),INSERT_VALUES,ierr) > > > > > > > > > call VecSetValue(b_rhs_test,II,q_p(k),INSERT_VALUES,ierr) > > > > > > > > > end do > > > > > > > > > > > > > > > > > > end do > > > > > > > > > > > > > > > > > > ! call MatCopy(A_mat,A_mat_test,DIFFERENT_NONZERO_PATTERN > > > > > > > > > ,ierr) > > > > > > > > > > > > > > > > > > call MatAssemblyBegin(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) > > > > > > > > > call MatAssemblyEnd(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) > > > > > > > > > > > > > > > > > > call MatAXPY(A_mat_test,aa,A_mat,SAME_NONZERO_PATTERN,ierr) > > > > > > > > > > > > > > > > > > call MatNorm(A_mat_test,NORM_INFINITY,nrm,ierr) > > > > > > > > > > > > > > > > > > print *, nrm > > > > > > > > > > > > > > > > > > end subroutine matrix_compare > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barry Smith wrote: > > > > > > > > > > > > > > > > > > > You can use MatCreateSeqAIJWithArrays() to "convert" the > > > > > > > > > > NSPCG > > > > > > > > > > matrix > > > > > > > > > > into > > > > > > > > > > PETSc format and then MatAXPY() to difference them and then > > > > > > > > > > MatNorm() to > > > > > > > > > > see > > > > > > > > > > how large the result is. Make sure the PETSc or hypre > > > > > > > > > > solver > > > > > > > > > > is > > > > > > > > > > always > > > > > > > > > > converging. Run with > > > > > > > > > > -ksp_converged_reason and or -ksp_monitor. My guess is that > > > > > > > > > > the > > > > > > > > > > matrix > > > > > > > > > > is > > > > > > > > > > becoming very ill-conditioned so the solvers with the > > > > > > > > > > default > > > > > > > > > > options > > > > > > > > > > are > > > > > > > > > > failing. > > > > > > > > > > > > > > > > > > > > Barry > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 3 Aug 2007, Ben Tay wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > I used 2 packages to solve my poisson eqn, which is part > > > > > > > > > > > of my > > > > > > > > > > > NS > > > > > > > > > > > unsteady > > > > > > > > > > > solver. One is the NSPCG solver package which uses the > > > > > > > > > > > compressed > > > > > > > > > > > row > > > > > > > > > > > format > > > > > > > > > > > to store the A matrix. The other is PETSc. I found that > > > > > > > > > > > using > > > > > > > > > > > both > > > > > > > > > > > solvers > > > > > > > > > > > gave me similar answers for a number of time step. > > > > > > > > > > > However, > > > > > > > > > > > after > > > > > > > > > > > that, > > > > > > > > > > > the > > > > > > > > > > > answer will suddenly change drastically for the PETSc > > > > > > > > > > > case. > > > > > > > > > > > This > > > > > > > > > > > does > > > > > > > > > > > not > > > > > > > > > > > happen for the NSPCG solver. > > > > > > > > > > > > > > > > > > > > > > For e.g. time step 1-315, oscillating airfoil case, > > > > > > > > > > > pressure > > > > > > > > > > > changes > > > > > > > > > > > smoothly, > > > > > > > > > > > similar answers in both cases > > > > > > > > > > > > > > > > > > > > > > at time=316, pressure changes from -3.22 to -3.2 for > > > > > > > > > > > NSPCG, > > > > > > > > > > > but > > > > > > > > > > > pressure > > > > > > > > > > > changes from -3.21 to -60.2 for PETSc > > > > > > > > > > > > > > > > > > > > > > This happens when I use HYPRE's AMG or PETSc's direct > > > > > > > > > > > solver > > > > > > > > > > > LU. > > > > > > > > > > > > > > > > > > > > > > I have been trying to find out what's the cause and I > > > > > > > > > > > can't > > > > > > > > > > > find > > > > > > > > > > > the > > > > > > > > > > > answer in > > > > > > > > > > > debugging. I would like to compare the values of the > > > > > > > > > > > matrix of > > > > > > > > > > > the > > > > > > > > > > > 2 > > > > > > > > > > > different > > > > > > > > > > > solvers and see if there's any difference. However, > > > > > > > > > > > NSPCG's > > > > > > > > > > > matrix > > > > > > > > > > > is > > > > > > > > > > > in > > > > > > > > > > > compressed row format while PETSc's one is just an address > > > > > > > > > > > and > > > > > > > > > > > it > > > > > > > > > > > can't be > > > > > > > > > > > viewed easily. Moreover, it's a big matrix so it's not > > > > > > > > > > > possible to > > > > > > > > > > > check > > > > > > > > > > > by > > > > > > > > > > > inspection. I'm thinking of subtracting one matrix by the > > > > > > > > > > > other > > > > > > > > > > > and > > > > > > > > > > > find > > > > > > > > > > > if > > > > > > > > > > > it's zero. What's the best way to solve this problem? Btw, > > > > > > > > > > > I'm > > > > > > > > > > > using > > > > > > > > > > > fortran > > > > > > > > > > > and there's no mpi > > > > > > > > > > > > > > > > > > > > > > Thank you. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From knepley at gmail.com Sun Aug 5 20:12:45 2007 From: knepley at gmail.com (Matthew Knepley) Date: Sun, 5 Aug 2007 20:12:45 -0500 Subject: Comparing between a PETSc matrix and a standard fortran array in compressed row format In-Reply-To: <46B673A5.7020206@gmail.com> References: <46B2ADEF.4050806@gmail.com> <46B3EFBF.5070909@gmail.com> <46B43912.2050509@gmail.com> <46B5286F.5040002@gmail.com> <46B536DC.4000400@gmail.com> <46B673A5.7020206@gmail.com> Message-ID: If 1) The matrix and rhs are identical 2) The matrix is nonsingular then the solution will be identical. Thus, the code has a bug somewhere. I suggest 1) Read in the other matrix and rhs 2) Compare both matrices and rhs 3) Solve both systems 4) Check that the answer match Matt On 8/5/07, Ben Tay wrote: > Well, here's what I got: > > 0 KSP preconditioned resid norm 1.498836640002e+04 true resid norm > 1.531062859147e+03 ||Ae||/||Ax|| 9.947622397959e-01 > 1 KSP preconditioned resid norm 4.832736106865e-08 true resid norm > 2.037181386899e-09 ||Ae||/||Ax|| 1.323597595746e-12 > > Looks like everything's ok.... right? > > Any other suggestion? > > Thanks. > > Barry Smith wrote: > > Run with -ksp_type gmres -pc_type lu -ksp_monitor_true_residual -ksp_truemonitor > > > > At the bad iteration verify if the true residual is very small. > > > > Barry > > > > > > On Sun, 5 Aug 2007, Ben Tay wrote: > > > > > >> Well, ya, they're the same ... that's why I don't know what's wrong. Is there > >> any way to check on singularity? The iteration no. is only 8 for AMG and LU > >> direct solver works. .. > >> > >> > >> Thanks > >> > >> Barry Smith wrote: > >> > >>> At the "bad step" are the two matrices and right hand sides the same? > >>> The the resulting solution vectors are different (a lot)? Is there any > >>> reason to think the matrix is (nearly) singular at that point? > >>> > >>> Barry > >>> > >>> > >>> > >>> On Sun, 5 Aug 2007, Ben Tay wrote: > >>> > >>> > >>> > >>>> Hi, > >>>> > >>>> Now I'm comparing at every time step. The A matrix and rhs of the NSPCG > >>>> and > >>>> PETSc matrix are exactly the same, NORM is zero. The solutions given by > >>>> both > >>>> solvers are very similar for e.g. from 1-315 time step, and varying slowly > >>>> since it is a oscillating body problem. Then strangely, at time=316, > >>>> PETSc's > >>>> answer suddenly differs by a great difference. e.g. p=0.3 to 50. I must > >>>> also > >>>> add that the flowfield at that time step still "looks ok". However, the > >>>> large > >>>> pressure change of the pressure poisson eqn caused the computation of the > >>>> lift/drag coefficient to be erroneous. Moreover, after that, the pressure > >>>> slowly "returns back" to the same answer such that of the NSPCG solver > >>>> after a > >>>> few time steps ... then after a while the sudden change happens again. In > >>>> the > >>>> end, I got a cl/cd vs time graph with lots of spikes. > >>>> > >>>> I hope that the thing can be solved because the NSPCG solver is much > >>>> slower > >>>> and it is not as stable. > >>>> > >>>> Thanks > >>>> > >>>> Barry Smith wrote: > >>>> > >>>> > >>>>> Ben, > >>>>> > >>>>> Are you comparing the two matrices at timestep 316? Also compare the > >>>>> two right hand sides at 316. Are they similar, totally different?? > >>>>> > >>>>> Barry > >>>>> > >>>>> > >>>>> On Sat, 4 Aug 2007, Ben Tay wrote: > >>>>> > >>>>> > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> After using MatAXPY, I used MatGetRowMaxAbs, VecAb and VecMax to get > >>>>>> the > >>>>>> row > >>>>>> with max value, get the absolute of that value and print out the > >>>>>> location/value. I managed to find some minor mistakes and corrected > >>>>>> them > >>>>>> so > >>>>>> that the 2 matrix are identical. Unfortunately, the same thing still > >>>>>> happens! > >>>>>> > >>>>>> I've checked for convergence and the iteration no. is 1 and 8 for > >>>>>> direct > >>>>>> solving and HYPRE's AMG respectively. So there's no convergence > >>>>>> problem. > >>>>>> I've > >>>>>> also tried to change to the same pc/ksp as that of NSPCG, which is > >>>>>> jacobi > >>>>>> presconditioning + KSPBCGS but the same thing happens. > >>>>>> > >>>>>> Any idea what's happening? > >>>>>> > >>>>>> Thanks > >>>>>> > >>>>>> Barry Smith wrote: > >>>>>> > >>>>>> > >>>>>>> Unless the matrix values are huge then this is a big difference. > >>>>>>> All > >>>>>>> you > >>>>>>> can do is print the difference matrix with ASCII MatView and > >>>>>>> look for large entries. This will tell you the locations of the > >>>>>>> trouble > >>>>>>> entries. > >>>>>>> > >>>>>>> Barry > >>>>>>> > >>>>>>> > >>>>>>> On Sat, 4 Aug 2007, Ben Tay wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> I realised that the matrix storage format of NSPCG is actually > >>>>>>>> ITPACK > >>>>>>>> storage > >>>>>>>> format. Anyway, I tried to insert the values into a PETSc matrix, > >>>>>>>> use > >>>>>>>> MatAXPY > >>>>>>>> with the scalar a = -1 and then use MatNorm on the output matrix. > >>>>>>>> > >>>>>>>> Using NORM_1, NORM_FROBENIUS and NORM_INFINITY > >>>>>>>> <../Vec/NORM_FROBENIUS.html#NORM_FROBENIUS>, I got ~543, 3194 and > >>>>>>>> 556 > >>>>>>>> respectively. Does this mean that the matrix are different? How > >>>>>>>> "much" > >>>>>>>> different does that means? > >>>>>>>> > >>>>>>>> So what is the next step? Is there anyway to find out the location > >>>>>>>> of > >>>>>>>> the > >>>>>>>> value which is different? > >>>>>>>> > >>>>>>>> This is my comparison subroutine: > >>>>>>>> > >>>>>>>> subroutine matrix_compare > >>>>>>>> > >>>>>>>> !compare big_A & PETSc matrix > >>>>>>>> > >>>>>>>> integer :: k,kk,II,JJ,ierr > >>>>>>>> > >>>>>>>> Vec xx_test,b_rhs_test > >>>>>>>> Mat A_mat_test > >>>>>>>> > >>>>>>>> PetscScalar aa > >>>>>>>> > >>>>>>>> PetscReal nrm > >>>>>>>> > >>>>>>>> aa=-1. > >>>>>>>> > >>>>>>>> call > >>>>>>>> MatCreateSeqAIJ(PETSC_COMM_SELF,total_k,total_k,10,PETSC_NULL_INTEGER,A_mat_test,ierr) > >>>>>>>> > >>>>>>>> call VecCreateSeq(PETSC_COMM_SELF,total_k,b_rhs_test,ierr) > >>>>>>>> > >>>>>>>> call VecDuplicate(b_rhs_test,xx_test,ierr) > >>>>>>>> > >>>>>>>> call VecAssemblyBegin(b_rhs_test,ierr) > >>>>>>>> > >>>>>>>> call VecAssemblyEnd(b_rhs_test,ierr) > >>>>>>>> > >>>>>>>> call VecAssemblyBegin(xx_test,ierr) > >>>>>>>> > >>>>>>>> call VecAssemblyEnd(xx_test,ierr) > >>>>>>>> > >>>>>>>> do k=1,total_k > >>>>>>>> do kk=1,10 > >>>>>>>> > >>>>>>>> II=k-1 > >>>>>>>> > >>>>>>>> JJ=int_A(k,kk)-1 > >>>>>>>> call > >>>>>>>> MatSetValues(A_mat_test,1,II,1,JJ,big_A(k,kk),INSERT_VALUES,ierr) > >>>>>>>> call VecSetValue(b_rhs_test,II,q_p(k),INSERT_VALUES,ierr) > >>>>>>>> end do > >>>>>>>> > >>>>>>>> end do > >>>>>>>> > >>>>>>>> ! call MatCopy(A_mat,A_mat_test,DIFFERENT_NONZERO_PATTERN > >>>>>>>> ,ierr) > >>>>>>>> > >>>>>>>> call MatAssemblyBegin(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) > >>>>>>>> call MatAssemblyEnd(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) > >>>>>>>> > >>>>>>>> call MatAXPY(A_mat_test,aa,A_mat,SAME_NONZERO_PATTERN,ierr) > >>>>>>>> > >>>>>>>> call MatNorm(A_mat_test,NORM_INFINITY,nrm,ierr) > >>>>>>>> > >>>>>>>> print *, nrm > >>>>>>>> > >>>>>>>> end subroutine matrix_compare > >>>>>>>> > >>>>>>>> Thanks! > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Barry Smith wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>>> You can use MatCreateSeqAIJWithArrays() to "convert" the NSPCG > >>>>>>>>> matrix > >>>>>>>>> into > >>>>>>>>> PETSc format and then MatAXPY() to difference them and then > >>>>>>>>> MatNorm() to > >>>>>>>>> see > >>>>>>>>> how large the result is. Make sure the PETSc or hypre solver > >>>>>>>>> is > >>>>>>>>> always > >>>>>>>>> converging. Run with > >>>>>>>>> -ksp_converged_reason and or -ksp_monitor. My guess is that the > >>>>>>>>> matrix > >>>>>>>>> is > >>>>>>>>> becoming very ill-conditioned so the solvers with the default > >>>>>>>>> options > >>>>>>>>> are > >>>>>>>>> failing. > >>>>>>>>> > >>>>>>>>> Barry > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Fri, 3 Aug 2007, Ben Tay wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> I used 2 packages to solve my poisson eqn, which is part of my > >>>>>>>>>> NS > >>>>>>>>>> unsteady > >>>>>>>>>> solver. One is the NSPCG solver package which uses the > >>>>>>>>>> compressed > >>>>>>>>>> row > >>>>>>>>>> format > >>>>>>>>>> to store the A matrix. The other is PETSc. I found that using > >>>>>>>>>> both > >>>>>>>>>> solvers > >>>>>>>>>> gave me similar answers for a number of time step. However, > >>>>>>>>>> after > >>>>>>>>>> that, > >>>>>>>>>> the > >>>>>>>>>> answer will suddenly change drastically for the PETSc case. > >>>>>>>>>> This > >>>>>>>>>> does > >>>>>>>>>> not > >>>>>>>>>> happen for the NSPCG solver. > >>>>>>>>>> > >>>>>>>>>> For e.g. time step 1-315, oscillating airfoil case, pressure > >>>>>>>>>> changes > >>>>>>>>>> smoothly, > >>>>>>>>>> similar answers in both cases > >>>>>>>>>> > >>>>>>>>>> at time=316, pressure changes from -3.22 to -3.2 for NSPCG, > >>>>>>>>>> but > >>>>>>>>>> pressure > >>>>>>>>>> changes from -3.21 to -60.2 for PETSc > >>>>>>>>>> > >>>>>>>>>> This happens when I use HYPRE's AMG or PETSc's direct solver > >>>>>>>>>> LU. > >>>>>>>>>> > >>>>>>>>>> I have been trying to find out what's the cause and I can't > >>>>>>>>>> find > >>>>>>>>>> the > >>>>>>>>>> answer in > >>>>>>>>>> debugging. I would like to compare the values of the matrix of > >>>>>>>>>> the > >>>>>>>>>> 2 > >>>>>>>>>> different > >>>>>>>>>> solvers and see if there's any difference. However, NSPCG's > >>>>>>>>>> matrix > >>>>>>>>>> is > >>>>>>>>>> in > >>>>>>>>>> compressed row format while PETSc's one is just an address and > >>>>>>>>>> it > >>>>>>>>>> can't be > >>>>>>>>>> viewed easily. Moreover, it's a big matrix so it's not > >>>>>>>>>> possible to > >>>>>>>>>> check > >>>>>>>>>> by > >>>>>>>>>> inspection. I'm thinking of subtracting one matrix by the > >>>>>>>>>> other > >>>>>>>>>> and > >>>>>>>>>> find > >>>>>>>>>> if > >>>>>>>>>> it's zero. What's the best way to solve this problem? Btw, I'm > >>>>>>>>>> using > >>>>>>>>>> fortran > >>>>>>>>>> and there's no mpi > >>>>>>>>>> > >>>>>>>>>> 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 From zonexo at gmail.com Sun Aug 5 23:33:48 2007 From: zonexo at gmail.com (Ben Tay) Date: Mon, 06 Aug 2007 12:33:48 +0800 Subject: Programming in *.f90 free format with PETSc Message-ID: <46B6A4AC.4010308@gmail.com> Hi, I've no problem writing out codes in fortran fixed format with PETSc. However, is it possible to do it in fortran free format as well? I'm using visual fortran and there's error. original : test.F module global_data implicit none save #include "include/finclude/petsc.h" #include "include/finclude/petscvec.h" #include "include/finclude/petscmat.h" #include "include/finclude/petscksp.h" #include "include/finclude/petscpc.h" #include "include/finclude/petscmat.h90" Vec xx,b_rhs .... How can I change this code to fortran free format *.f90? Thanks From balay at mcs.anl.gov Sun Aug 5 23:42:13 2007 From: balay at mcs.anl.gov (Satish Balay) Date: Sun, 5 Aug 2007 23:42:13 -0500 (CDT) Subject: Programming in *.f90 free format with PETSc In-Reply-To: <46B6A4AC.4010308@gmail.com> References: <46B6A4AC.4010308@gmail.com> Message-ID: you can use .F90 suffix for free-from preprocesed code. [or use compiler options to force it always use free-form] And when using fortran modules use the following organization: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #define PETSC_AVOID_DECLARATIONS #include "include/finclude/petsc.h" #undef PETSC_AVOID_DECLARATIONS moudle foobar end module subroutine xyz() use foobar implicit none #include "include/finclude/petsc.h" end subroutine <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Satish On Mon, 6 Aug 2007, Ben Tay wrote: > Hi, > > I've no problem writing out codes in fortran fixed format with PETSc. However, > is it possible to do it in fortran free format as well? > > I'm using visual fortran and there's error. > > original : > > test.F > > module global_data > > implicit none > > save > > #include "include/finclude/petsc.h" > #include "include/finclude/petscvec.h" > #include "include/finclude/petscmat.h" > #include "include/finclude/petscksp.h" > #include "include/finclude/petscpc.h" > #include "include/finclude/petscmat.h90" > > Vec xx,b_rhs > > .... > > How can I change this code to fortran free format *.f90? > > Thanks > > From zonexo at gmail.com Mon Aug 6 03:07:34 2007 From: zonexo at gmail.com (Ben Tay) Date: Mon, 06 Aug 2007 16:07:34 +0800 Subject: Programming in *.f90 free format with PETSc In-Reply-To: References: <46B6A4AC.4010308@gmail.com> Message-ID: <46B6D6C6.1090504@gmail.com> Hi, I tried to use #define PETSC_AVOID_DECLARATIONS #include "include/finclude/petsc.h" #undef PETSC_AVOID_DECLARATIONS module ada ... subroutine .... end module ada but the compiler says that the module is placed in the wrong order. Anyway, I just move the top 4 lines into the subroutine instead and it worked. Thanks module ada ... subroutine ddd #define PETSC_AVOID_DECLARATIONS #include "include/finclude/petsc.h" #undef PETSC_AVOID_DECLARATIONS .... end subroutine ddd Satish Balay wrote: > you can use .F90 suffix for free-from preprocesed code. [or use > compiler options to force it always use free-form] > > And when using fortran modules use the following organization: > > > > #define PETSC_AVOID_DECLARATIONS > #include "include/finclude/petsc.h" > > #undef PETSC_AVOID_DECLARATIONS > > moudle foobar > > end module > > subroutine xyz() > use foobar > implicit none > #include "include/finclude/petsc.h" > > > end subroutine > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > Satish > > On Mon, 6 Aug 2007, Ben Tay wrote: > > >> Hi, >> >> I've no problem writing out codes in fortran fixed format with PETSc. However, >> is it possible to do it in fortran free format as well? >> >> I'm using visual fortran and there's error. >> >> original : >> >> test.F >> >> module global_data >> >> implicit none >> >> save >> >> #include "include/finclude/petsc.h" >> #include "include/finclude/petscvec.h" >> #include "include/finclude/petscmat.h" >> #include "include/finclude/petscksp.h" >> #include "include/finclude/petscpc.h" >> #include "include/finclude/petscmat.h90" >> >> Vec xx,b_rhs >> >> .... >> >> How can I change this code to fortran free format *.f90? >> >> Thanks >> >> >> > > > From zonexo at gmail.com Mon Aug 6 03:17:59 2007 From: zonexo at gmail.com (Ben Tay) Date: Mon, 06 Aug 2007 16:17:59 +0800 Subject: Problem with using ADD_VALUES Message-ID: <46B6D937.2030900@gmail.com> Hi, I am trying to insert values into a matrix. I used to use INSERT_VALUES with MatSetValues or MatSetValue. However, since I need to add values to the same II,JJ location more than 1 time, I have to use ADD_VALUES with MatSetValues. However I got this error message: Object is in wrong state! Cannot mix add values and insert values! My code is something like this: call MatSetValues(A_mat,1,II,1,JJ,0.,INSERT_VALUES,ierr) -> to reset values at II,JJ to zero 1st ... do JJ=1,5 call MatSetValues(A_mat,1,II,1,int_A(m,JJ)-1,big_A(m,JJ),ADD_VALUES,ierr) -> to put values into the matrix, with the possibility of adding values to the same II,JJ locations more than once. end do How can I solve this problem? Thanks. From knepley at gmail.com Mon Aug 6 06:26:15 2007 From: knepley at gmail.com (Matthew Knepley) Date: Mon, 6 Aug 2007 06:26:15 -0500 Subject: Problem with using ADD_VALUES In-Reply-To: <46B6D937.2030900@gmail.com> References: <46B6D937.2030900@gmail.com> Message-ID: 1) You could use MatZeroEntries() to zero out the matrix 2) You could call MatAssembly*(m, MAT_ASSEMBLY_FLUSH) in between INSERT and ADD. MAtt On 8/6/07, Ben Tay wrote: > Hi, > > I am trying to insert values into a matrix. I used to use INSERT_VALUES > with MatSetValues or MatSetValue. However, since I need to add values to > the same II,JJ location more than 1 time, I have to use ADD_VALUES with > MatSetValues. > > However I got this error message: > > Object is in wrong state! > Cannot mix add values and insert values! > > My code is something like this: > > call MatSetValues(A_mat,1,II,1,JJ,0.,INSERT_VALUES,ierr) -> > to reset values at II,JJ to zero 1st > > ... > > do JJ=1,5 > > call > MatSetValues(A_mat,1,II,1,int_A(m,JJ)-1,big_A(m,JJ),ADD_VALUES,ierr) > -> to put values into the matrix, with the possibility > of adding values to the same II,JJ locations more than once. > > end do > > How can I solve this problem? > > Thanks. > > -- 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 From balay at mcs.anl.gov Mon Aug 6 10:24:38 2007 From: balay at mcs.anl.gov (Satish Balay) Date: Mon, 6 Aug 2007 10:24:38 -0500 (CDT) Subject: Programming in *.f90 free format with PETSc In-Reply-To: <46B6D6C6.1090504@gmail.com> References: <46B6A4AC.4010308@gmail.com> <46B6D6C6.1090504@gmail.com> Message-ID: This is incorrect usage. If you are getting errors with the correct usage, send us the error messages, with your code, and we can sugest fixes. - one issue could be > > #define PETSC_AVOID_DECLARATIONS > > #include "include/finclude/petsc.h" > > #include "include/finclude/petscvec.h90" <--- This should be removed from here.. > > > > #undef PETSC_AVOID_DECLARATIONS > > > > moudle foobar > > > > end module Satish On Mon, 6 Aug 2007, Ben Tay wrote: > Hi, > > I tried to use > > #define PETSC_AVOID_DECLARATIONS > #include "include/finclude/petsc.h" > > #undef PETSC_AVOID_DECLARATIONS > > > module ada > ... > > subroutine .... > > end module ada > > but the compiler says that the module is placed in the wrong order. Anyway, I > just move the top 4 lines into the subroutine instead and it worked. Thanks > > module ada > > ... > > subroutine ddd > > #define PETSC_AVOID_DECLARATIONS > #include "include/finclude/petsc.h" > > #undef PETSC_AVOID_DECLARATIONS > > .... > > end subroutine ddd > > > > > Satish Balay wrote: > > you can use .F90 suffix for free-from preprocesed code. [or use > > compiler options to force it always use free-form] > > > > And when using fortran modules use the following organization: > > > > > > #define PETSC_AVOID_DECLARATIONS > > #include "include/finclude/petsc.h" > > > > #undef PETSC_AVOID_DECLARATIONS > > > > moudle foobar > > > > end module > > > > subroutine xyz() > > use foobar > > implicit none > > #include "include/finclude/petsc.h" > > > > > > end subroutine > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > Satish > > > > On Mon, 6 Aug 2007, Ben Tay wrote: > > > > > > > Hi, > > > > > > I've no problem writing out codes in fortran fixed format with PETSc. > > > However, > > > is it possible to do it in fortran free format as well? > > > > > > I'm using visual fortran and there's error. > > > > > > original : > > > > > > test.F > > > > > > module global_data > > > > > > implicit none > > > > > > save > > > > > > #include "include/finclude/petsc.h" > > > #include "include/finclude/petscvec.h" > > > #include "include/finclude/petscmat.h" > > > #include "include/finclude/petscksp.h" > > > #include "include/finclude/petscpc.h" > > > #include "include/finclude/petscmat.h90" > > > > > > Vec xx,b_rhs > > > > > > .... > > > > > > How can I change this code to fortran free format *.f90? > > > > > > Thanks > > > > > > > > > > > > > > > > > From jwicks at cs.brown.edu Mon Aug 6 10:10:50 2007 From: jwicks at cs.brown.edu (John R. Wicks) Date: Mon, 6 Aug 2007 11:10:50 -0400 Subject: Inefficient Multiplication? Message-ID: <000101c7d83b$f9ac30b0$6b249480@jwickslptp> I wrote a test program to compare the performance of the Matrix Template Library on packed array multiplication and although petsc outperformed mtl, I was surprised that its performance was not strictly linear in the number of entries: 1) I created a packed column major matrix of doubles in mtl with the corresponding row major version in petsc; all matrices were dense with 10 entries per column (row), where the indices are chosen randomly. 2) For each column size, I created a fixed (dense) vector of doubles and performed 1000 multiplications (transposed multiplications) and recored the timings, with the results as follows: Iterations rows columns entries mtl petc 1000 1000 1000 10000 5.35 0.1 1000 1000 2000 10000 5.69 0.1 1000 1000 4000 10000 5.91 0.11 1000 1000 8000 10000 7.85 0.13 1000 1000 16000 10000 9.82 0.21 1000 1000 32000 10000 12.18 0.21 1000 2000 2000 20000 10.94 0.21 1000 2000 4000 20000 11.11 0.21 1000 2000 8000 20000 12.12 0.26 1000 2000 16000 20000 13.47 0.31 1000 2000 32000 20000 16.69 0.4 1000 2000 64000 20000 23.66 0.68 1000 4000 4000 40000 24.7 0.44 1000 4000 8000 40000 26.24 0.52 1000 4000 16000 40000 27.73 0.64 1000 4000 32000 40000 31.23 0.76 1000 4000 64000 40000 37.91 1.26 1000 4000 128000 40000 50 2.02 1000 8000 8000 80000 49.79 1.08 1000 8000 16000 80000 53.24 1.29 1000 8000 32000 80000 56.63 1.61 1000 8000 64000 80000 59.54 2.44 1000 8000 128000 80000 69.85 3.55 1000 8000 256000 80000 95.39 4.61 1000 16000 16000 160000 103.58 2.52 1000 16000 32000 160000 100.83 2.92 1000 16000 64000 160000 104.57 4.68 1000 16000 128000 160000 127.82 6.67 1000 16000 256000 160000 151.82 8.18 1000 16000 512000 160000 200.33 9.97 1000 32000 32000 320000 206.65 6 1000 32000 64000 320000 218.44 9.41 1000 32000 128000 320000 234.82 12.95 1000 32000 256000 320000 260.71 15.22 1000 32000 512000 320000 304.17 18.38 1000 32000 1024000 320000 405.6 21.76 As you can see, while petsc was 30-60 times faster than mtl, the performance of both packages also depended significantly on the number of rows. Maybe this is not surprising, since I believe they both utilize the BLAS libraries at some level, but since I can write down a simple algorithm for performing the multiplication linearly in the number of entries, and I would expect such a standard library to use the most efficient algorithm available, I am wondering why this is happening? Any ideas? From aja2111 at columbia.edu Mon Aug 6 10:56:26 2007 From: aja2111 at columbia.edu (Aron Ahmadia) Date: Mon, 6 Aug 2007 11:56:26 -0400 Subject: Inefficient Multiplication? In-Reply-To: <000101c7d83b$f9ac30b0$6b249480@jwickslptp> References: <000101c7d83b$f9ac30b0$6b249480@jwickslptp> Message-ID: <37604ab40708060856x345189d3q47c628d8792cba74@mail.gmail.com> This is a direct consequence of the so-called memory mountain, i.e. the increasing costs of accessing memory further and further away from the processor on a standard Von Neumann architecture: cache -> RAM -> hard drive. Larger matrices don't completely fit in the cache, and you're paying a cache miss penalty. See Bryant and Hallaron, "Computer Systems: A Programmer's Perspective" for more on this, or for excruciating details, check out ATLAS (Automatically Tuned Linear Algebra System). ~A On 8/6/07, John R. Wicks wrote: > I wrote a test program to compare the performance of the Matrix Template > Library on packed array multiplication and although petsc outperformed mtl, > I was surprised that its performance was not strictly linear in the number > of entries: > > 1) I created a packed column major matrix of doubles in mtl with the > corresponding row major version in petsc; all matrices were dense with 10 > entries per column (row), where the indices are chosen randomly. > > 2) For each column size, I created a fixed (dense) vector of doubles and > performed 1000 multiplications (transposed multiplications) and recored the > timings, with the results as follows: > > Iterations rows columns entries mtl petc > 1000 1000 1000 10000 5.35 0.1 > 1000 1000 2000 10000 5.69 0.1 > 1000 1000 4000 10000 5.91 0.11 > 1000 1000 8000 10000 7.85 0.13 > 1000 1000 16000 10000 9.82 0.21 > 1000 1000 32000 10000 12.18 0.21 > 1000 2000 2000 20000 10.94 0.21 > 1000 2000 4000 20000 11.11 0.21 > 1000 2000 8000 20000 12.12 0.26 > 1000 2000 16000 20000 13.47 0.31 > 1000 2000 32000 20000 16.69 0.4 > 1000 2000 64000 20000 23.66 0.68 > 1000 4000 4000 40000 24.7 0.44 > 1000 4000 8000 40000 26.24 0.52 > 1000 4000 16000 40000 27.73 0.64 > 1000 4000 32000 40000 31.23 0.76 > 1000 4000 64000 40000 37.91 1.26 > 1000 4000 128000 40000 50 2.02 > 1000 8000 8000 80000 49.79 1.08 > 1000 8000 16000 80000 53.24 1.29 > 1000 8000 32000 80000 56.63 1.61 > 1000 8000 64000 80000 59.54 2.44 > 1000 8000 128000 80000 69.85 3.55 > 1000 8000 256000 80000 95.39 4.61 > 1000 16000 16000 160000 103.58 2.52 > 1000 16000 32000 160000 100.83 2.92 > 1000 16000 64000 160000 104.57 4.68 > 1000 16000 128000 160000 127.82 6.67 > 1000 16000 256000 160000 151.82 8.18 > 1000 16000 512000 160000 200.33 9.97 > 1000 32000 32000 320000 206.65 6 > 1000 32000 64000 320000 218.44 9.41 > 1000 32000 128000 320000 234.82 12.95 > 1000 32000 256000 320000 260.71 15.22 > 1000 32000 512000 320000 304.17 18.38 > 1000 32000 1024000 320000 405.6 21.76 > > As you can see, while petsc was 30-60 times faster than mtl, the performance > of both packages also depended significantly on the number of rows. Maybe > this is not surprising, since I believe they both utilize the BLAS libraries > at some level, but since I can write down a simple algorithm for performing > the multiplication linearly in the number of entries, and I would expect > such a standard library to use the most efficient algorithm available, I am > wondering why this is happening? Any ideas? > > From pbauman at ices.utexas.edu Mon Aug 6 19:55:34 2007 From: pbauman at ices.utexas.edu (Paul T. Bauman) Date: Mon, 06 Aug 2007 19:55:34 -0500 Subject: FORTRAN usage of SNESSetConvergenceHistory Message-ID: <46B7C306.3080600@ices.utexas.edu> Hello, Is it possible to use SNESSetConvergenceHistory/SNESGetConvergenceHistory with FORTRAN? Thanks, Paul From bsmith at mcs.anl.gov Mon Aug 6 22:51:57 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Mon, 6 Aug 2007 22:51:57 -0500 (CDT) Subject: FORTRAN usage of SNESSetConvergenceHistory In-Reply-To: <46B7C306.3080600@ices.utexas.edu> References: <46B7C306.3080600@ices.utexas.edu> Message-ID: Paul, Yes it is intended one can use them from Fortran. Note from the manual page for SNESGetConvergenceHistory() it does not return the arrays, just the count. You must keep around the arrays you passed into SNESSetConvergenceHistory() and read from them. Barry On Mon, 6 Aug 2007, Paul T. Bauman wrote: > Hello, > > Is it possible to use SNESSetConvergenceHistory/SNESGetConvergenceHistory with > FORTRAN? Thanks, > > Paul > > From zonexo at gmail.com Tue Aug 7 03:26:27 2007 From: zonexo at gmail.com (Ben Tay) Date: Tue, 7 Aug 2007 16:26:27 +0800 Subject: Programming in *.f90 free format with PETSc In-Reply-To: References: <46B6A4AC.4010308@gmail.com> <46B6D6C6.1090504@gmail.com> Message-ID: <804ab5d40708070126o3111c212gf3d386a7ee524a11@mail.gmail.com> Hi, I can compile and run with visual fortran by putting all the declarations inside a subroutine e.g. module ada ... subroutine ddd #define PETSC_AVOID_DECLARATIONS #include "include/finclude/petsc.h" #undef PETSC_AVOID_DECLARATIONS .... end subroutine ddd end module ada However, on my school's server which uses ifort, I get errors both using your way and my way e.g. #define PETSC_AVOID_DECLARATIONS #include "include/finclude/petsc.h" #include "include/finclude/petscvec.h" #include "include/finclude/petscmat.h" #include "include/finclude/petscksp.h" #include "include/finclude/petscpc.h" #include "include/finclude/petscmat.h90" #undef PETSC_AVOID_DECLARATIONS program test implicit none integer :: x,y Vec test_vec x=1 print *, x end program test I compile using ifort -r8 -132 -fPIC -g -c -static-libcxa -O3 -I/lsftmp/g0306332/petsc- 2.3.3-p0 -I/lsftmp/g0306332/petsc-2.3.3-p0/bmake/atlas3 -I/lsftmp/g0306332/petsc-2.3.3-p0/include -I/lsftmp/g0306332/petsc-2.3.3-p0 /externalpackages/hypre-2.0.0/atlas3/include -I/lsftmp/g0306332/mpich2/include temp.f90 and get the error msg: fortcom: Warning: Bad # preprocessor line fortcom: Warning: Bad # preprocessor line fortcom: Warning: Bad # preprocessor line fortcom: Warning: Bad # preprocessor line fortcom: Warning: Bad # preprocessor line fortcom: Warning: Bad # preprocessor line fortcom: Warning: Bad # preprocessor line fortcom: Warning: Bad # preprocessor line fortcom: Error: temp.f90, line 18: Syntax error, found IDENTIFIER 'TEST_VEC' when expecting one of: => = . ( : % Vec test_vec ----^ fortcom: Error: temp.f90, line 18: This name does not have a type, and must have an explicit type. [VEC] Vec test_vec ^ fortcom: Error: temp.f90, line 18: This name does not have a type, and must have an explicit type. [TEST_VEC] Vec test_vec ----^ compilation aborted for temp.f90 (code 1) I also tried shifting the declarations after the "program test" line but it also failed. There is no problem if I changed the code to fixed format. Thanks On 8/6/07, Satish Balay wrote: > > This is incorrect usage. > > If you are getting errors with the correct usage, send us the error > messages, with your code, and we can sugest fixes. > > - one issue could be > > > > #define PETSC_AVOID_DECLARATIONS > > > #include "include/finclude/petsc.h" > > > #include "include/finclude/petscvec.h90" <--- This should be removed > from here.. > > > > > > #undef PETSC_AVOID_DECLARATIONS > > > > > > moudle foobar > > > > > > end module > > > Satish > > On Mon, 6 Aug 2007, Ben Tay wrote: > > > Hi, > > > > I tried to use > > > > #define PETSC_AVOID_DECLARATIONS > > #include "include/finclude/petsc.h" > > > > #undef PETSC_AVOID_DECLARATIONS > > > > > > module ada > > ... > > > > subroutine .... > > > > end module ada > > > > but the compiler says that the module is placed in the wrong order. > Anyway, I > > just move the top 4 lines into the subroutine instead and it worked. > Thanks > > > > module ada > > > > ... > > > > subroutine ddd > > > > #define PETSC_AVOID_DECLARATIONS > > #include "include/finclude/petsc.h" > > > > #undef PETSC_AVOID_DECLARATIONS > > > > .... > > > > end subroutine ddd > > > > > > > > > > Satish Balay wrote: > > > you can use .F90 suffix for free-from preprocesed code. [or use > > > compiler options to force it always use free-form] > > > > > > And when using fortran modules use the following organization: > > > > > > > > > #define PETSC_AVOID_DECLARATIONS > > > #include "include/finclude/petsc.h" > > > > > > #undef PETSC_AVOID_DECLARATIONS > > > > > > moudle foobar > > > > > > end module > > > > > > subroutine xyz() > > > use foobar > > > implicit none > > > #include "include/finclude/petsc.h" > > > > > > > > > end subroutine > > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > > > Satish > > > > > > On Mon, 6 Aug 2007, Ben Tay wrote: > > > > > > > > > > Hi, > > > > > > > > I've no problem writing out codes in fortran fixed format with > PETSc. > > > > However, > > > > is it possible to do it in fortran free format as well? > > > > > > > > I'm using visual fortran and there's error. > > > > > > > > original : > > > > > > > > test.F > > > > > > > > module global_data > > > > > > > > implicit none > > > > > > > > save > > > > > > > > #include "include/finclude/petsc.h" > > > > #include "include/finclude/petscvec.h" > > > > #include "include/finclude/petscmat.h" > > > > #include "include/finclude/petscksp.h" > > > > #include "include/finclude/petscpc.h" > > > > #include "include/finclude/petscmat.h90" > > > > > > > > Vec xx,b_rhs > > > > > > > > .... > > > > > > > > How can I change this code to fortran free format *.f90? > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbauman at ices.utexas.edu Tue Aug 7 08:29:14 2007 From: pbauman at ices.utexas.edu (Paul T. Bauman) Date: Tue, 07 Aug 2007 08:29:14 -0500 Subject: Programming in *.f90 free format with PETSc In-Reply-To: <804ab5d40708070126o3111c212gf3d386a7ee524a11@mail.gmail.com> References: <46B6A4AC.4010308@gmail.com> <46B6D6C6.1090504@gmail.com> <804ab5d40708070126o3111c212gf3d386a7ee524a11@mail.gmail.com> Message-ID: <46B873AA.1060208@ices.utexas.edu> Hi Ben, Here is the format I use in my .f90 modules. Note I do not know what the standard is, but this "style" has worked with ifort, gfortran, g95 and Visual Studio (so I'm told). module IAmAModule implicit none private !(you don't need this if you don't want it) #PREPROCESSING STATEMENTS HERE (these will be seen by all subroutines contained in the module) public :: whatever needs to be public integer :: declare variables you want in the module contains subroutine IAmASubroutine (note this format works for a subroutine not in a module implicit none #PREPROCESSING STATEMENTS NOT INCLUDED IN THE MODULE variable declarations code here... end subroutine IAmASubroutine end module IAmAModule It looks like in your case below, the preprocessing statements are before the program - they must be inside the program. Put them after implicit none and before any variable declarations (in case you use a PETSc type variable). Good Luck, Paul Ben Tay wrote: > Hi, > > I can compile and run with visual fortran by putting all the > declarations inside a subroutine e.g. > > module ada > > ... > > subroutine ddd > > > #define PETSC_AVOID_DECLARATIONS > #include "include/finclude/ petsc.h" > > #undef PETSC_AVOID_DECLARATIONS > > .... > > end subroutine ddd > > > end module ada > > However, on my school's server which uses ifort, I get errors both > using your way and my way e.g. > > > #define PETSC_AVOID_DECLARATIONS > #include "include/finclude/petsc.h" > #include "include/finclude/petscvec.h" > #include "include/finclude/petscmat.h" > #include "include/finclude/petscksp.h" > #include "include/finclude/petscpc.h" > #include "include/finclude/petscmat.h90" > #undef PETSC_AVOID_DECLARATIONS > > program test > > implicit none > > integer :: x,y > > Vec test_vec > > x=1 > > print *, x > > end program test > > > I compile using > > ifort -r8 -132 -fPIC -g -c -static-libcxa -O3 > -I/lsftmp/g0306332/petsc-2.3.3-p0 > -I/lsftmp/g0306332/petsc-2.3.3-p0/bmake/atlas3 > -I/lsftmp/g0306332/petsc-2.3.3-p0/include > -I/lsftmp/g0306332/petsc-2.3.3-p0/externalpackages/hypre- > 2.0.0/atlas3/include -I/lsftmp/g0306332/mpich2/include temp.f90 > > and get the error msg: > > fortcom: Warning: Bad # preprocessor line > fortcom: Warning: Bad # preprocessor line > fortcom: Warning: Bad # preprocessor line > fortcom: Warning: Bad # preprocessor line > fortcom: Warning: Bad # preprocessor line > fortcom: Warning: Bad # preprocessor line > fortcom: Warning: Bad # preprocessor line > fortcom: Warning: Bad # preprocessor line > > fortcom: Error: temp.f90, line 18: Syntax error, found IDENTIFIER > 'TEST_VEC' when expecting one of: => = . ( : % > Vec test_vec > ----^ > fortcom: Error: temp.f90, line 18: This name does not have a type, and > must have an explicit type. [VEC] > Vec test_vec > ^ > fortcom: Error: temp.f90, line 18: This name does not have a type, and > must have an explicit type. [TEST_VEC] > Vec test_vec > ----^ > compilation aborted for temp.f90 (code 1) > > I also tried shifting the declarations after the "program test" line > but it also failed. There is no problem if I changed the code to fixed > format. > > Thanks > > > > > On 8/6/07, *Satish Balay* > wrote: > > This is incorrect usage. > > If you are getting errors with the correct usage, send us the error > messages, with your code, and we can sugest fixes. > > - one issue could be > > > > #define PETSC_AVOID_DECLARATIONS > > > #include "include/finclude/petsc.h" > > > #include "include/finclude/petscvec.h90" <--- This should be > removed from here.. > > > > > > #undef PETSC_AVOID_DECLARATIONS > > > > > > moudle foobar > > > > > > end module > > > Satish > > On Mon, 6 Aug 2007, Ben Tay wrote: > > > Hi, > > > > I tried to use > > > > #define PETSC_AVOID_DECLARATIONS > > #include "include/finclude/petsc.h" > > > > #undef PETSC_AVOID_DECLARATIONS > > > > > > module ada > > ... > > > > subroutine .... > > > > end module ada > > > > but the compiler says that the module is placed in the wrong > order. Anyway, I > > just move the top 4 lines into the subroutine instead and it > worked. Thanks > > > > module ada > > > > ... > > > > subroutine ddd > > > > #define PETSC_AVOID_DECLARATIONS > > #include "include/finclude/petsc.h" > > > > #undef PETSC_AVOID_DECLARATIONS > > > > .... > > > > end subroutine ddd > > > > > > > > > > Satish Balay wrote: > > > you can use .F90 suffix for free-from preprocesed code. [or use > > > compiler options to force it always use free-form] > > > > > > And when using fortran modules use the following organization: > > > > > > > > > #define PETSC_AVOID_DECLARATIONS > > > #include "include/finclude/petsc.h" > > > > > > #undef PETSC_AVOID_DECLARATIONS > > > > > > moudle foobar > > > > > > end module > > > > > > subroutine xyz() > > > use foobar > > > implicit none > > > #include "include/finclude/petsc.h" > > > > > > > > > end subroutine > > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > > > Satish > > > > > > On Mon, 6 Aug 2007, Ben Tay wrote: > > > > > > > > > > Hi, > > > > > > > > I've no problem writing out codes in fortran fixed format > with PETSc. > > > > However, > > > > is it possible to do it in fortran free format as well? > > > > > > > > I'm using visual fortran and there's error. > > > > > > > > original : > > > > > > > > test.F > > > > > > > > module global_data > > > > > > > > implicit none > > > > > > > > save > > > > > > > > #include "include/finclude/petsc.h" > > > > #include "include/finclude/petscvec.h" > > > > #include "include/finclude/petscmat.h" > > > > #include "include/finclude/petscksp.h" > > > > #include "include/finclude/petscpc.h" > > > > #include "include/finclude/petscmat.h90" > > > > > > > > Vec xx,b_rhs > > > > > > > > .... > > > > > > > > How can I change this code to fortran free format *.f90? > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > From zonexo at gmail.com Tue Aug 7 11:20:50 2007 From: zonexo at gmail.com (Ben Tay) Date: Wed, 08 Aug 2007 00:20:50 +0800 Subject: Programming in *.f90 free format with PETSc In-Reply-To: <46B873AA.1060208@ices.utexas.edu> References: <46B6A4AC.4010308@gmail.com> <46B6D6C6.1090504@gmail.com> <804ab5d40708070126o3111c212gf3d386a7ee524a11@mail.gmail.com> <46B873AA.1060208@ices.utexas.edu> Message-ID: <46B89BE2.40701@gmail.com> Hi, Thanks Paul. I finally realised where my problem lies. It's becos I forgot to add -fpp to the ifort option. It's working now. However, why can't I include #include "include/finclude/petscmat.h90" in the declaration? It seems to cause some conflicts... Thanks Paul T. Bauman wrote: > Hi Ben, > > Here is the format I use in my .f90 modules. Note I do not know what > the standard is, but this "style" has worked with ifort, gfortran, g95 > and Visual Studio (so I'm told). > module IAmAModule > > implicit none > > private !(you don't need this if you don't want it) > > #PREPROCESSING STATEMENTS HERE (these will be seen by all subroutines > contained in the module) > > public :: whatever needs to be public > > integer :: declare variables you want in the module > > contains > > subroutine IAmASubroutine (note this format works for a subroutine not > in a module > > implicit none > > #PREPROCESSING STATEMENTS NOT INCLUDED IN THE MODULE > > variable declarations > > code here... > > end subroutine IAmASubroutine > > end module IAmAModule > > It looks like in your case below, the preprocessing statements are > before the program - they must be inside the program. Put them after > implicit none and before any variable declarations (in case you use a > PETSc type variable). > > Good Luck, > > Paul > > Ben Tay wrote: >> Hi, >> >> I can compile and run with visual fortran by putting all the >> declarations inside a subroutine e.g. >> >> module ada >> >> ... >> >> subroutine ddd >> >> >> #define PETSC_AVOID_DECLARATIONS >> #include "include/finclude/ petsc.h" >> >> #undef PETSC_AVOID_DECLARATIONS >> >> .... >> >> end subroutine ddd >> >> >> end module ada >> >> However, on my school's server which uses ifort, I get errors both >> using your way and my way e.g. >> >> >> #define PETSC_AVOID_DECLARATIONS >> #include "include/finclude/petsc.h" >> #include "include/finclude/petscvec.h" >> #include "include/finclude/petscmat.h" >> #include "include/finclude/petscksp.h" >> #include "include/finclude/petscpc.h" >> #include "include/finclude/petscmat.h90" >> #undef PETSC_AVOID_DECLARATIONS >> >> program test >> >> implicit none >> >> integer :: x,y >> >> Vec test_vec >> >> x=1 >> >> print *, x >> >> end program test >> >> >> I compile using >> >> ifort -r8 -132 -fPIC -g -c -static-libcxa -O3 >> -I/lsftmp/g0306332/petsc-2.3.3-p0 >> -I/lsftmp/g0306332/petsc-2.3.3-p0/bmake/atlas3 >> -I/lsftmp/g0306332/petsc-2.3.3-p0/include >> -I/lsftmp/g0306332/petsc-2.3.3-p0/externalpackages/hypre- >> 2.0.0/atlas3/include -I/lsftmp/g0306332/mpich2/include temp.f90 >> >> and get the error msg: >> >> fortcom: Warning: Bad # preprocessor line >> fortcom: Warning: Bad # preprocessor line >> fortcom: Warning: Bad # preprocessor line >> fortcom: Warning: Bad # preprocessor line >> fortcom: Warning: Bad # preprocessor line >> fortcom: Warning: Bad # preprocessor line >> fortcom: Warning: Bad # preprocessor line >> fortcom: Warning: Bad # preprocessor line >> >> fortcom: Error: temp.f90, line 18: Syntax error, found IDENTIFIER >> 'TEST_VEC' when expecting one of: => = . ( : % >> Vec test_vec >> ----^ >> fortcom: Error: temp.f90, line 18: This name does not have a type, >> and must have an explicit type. [VEC] >> Vec test_vec >> ^ >> fortcom: Error: temp.f90, line 18: This name does not have a type, >> and must have an explicit type. [TEST_VEC] >> Vec test_vec >> ----^ >> compilation aborted for temp.f90 (code 1) >> >> I also tried shifting the declarations after the "program test" line >> but it also failed. There is no problem if I changed the code to >> fixed format. >> >> Thanks >> >> >> >> >> On 8/6/07, *Satish Balay* > > wrote: >> >> This is incorrect usage. >> >> If you are getting errors with the correct usage, send us the error >> messages, with your code, and we can sugest fixes. >> >> - one issue could be >> >> > > #define PETSC_AVOID_DECLARATIONS >> > > #include "include/finclude/petsc.h" >> > > #include "include/finclude/petscvec.h90" <--- This should be >> removed from here.. >> > > >> > > #undef PETSC_AVOID_DECLARATIONS >> > > >> > > moudle foobar >> > > >> > > end module >> >> >> Satish >> >> On Mon, 6 Aug 2007, Ben Tay wrote: >> >> > Hi, >> > >> > I tried to use >> > >> > #define PETSC_AVOID_DECLARATIONS >> > #include "include/finclude/petsc.h" >> > >> > #undef PETSC_AVOID_DECLARATIONS >> > >> > >> > module ada >> > ... >> > >> > subroutine .... >> > >> > end module ada >> > >> > but the compiler says that the module is placed in the wrong >> order. Anyway, I >> > just move the top 4 lines into the subroutine instead and it >> worked. Thanks >> > >> > module ada >> > >> > ... >> > >> > subroutine ddd >> > >> > #define PETSC_AVOID_DECLARATIONS >> > #include "include/finclude/petsc.h" >> > >> > #undef PETSC_AVOID_DECLARATIONS >> > >> > .... >> > >> > end subroutine ddd >> > >> > >> > >> > >> > Satish Balay wrote: >> > > you can use .F90 suffix for free-from preprocesed code. [or use >> > > compiler options to force it always use free-form] >> > > >> > > And when using fortran modules use the following organization: >> > > >> > > >> > > #define PETSC_AVOID_DECLARATIONS >> > > #include "include/finclude/petsc.h" >> > > >> > > #undef PETSC_AVOID_DECLARATIONS >> > > >> > > moudle foobar >> > > >> > > end module >> > > >> > > subroutine xyz() >> > > use foobar >> > > implicit none >> > > #include "include/finclude/petsc.h" >> > > >> > > >> > > end subroutine >> > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >> > > >> > > Satish >> > > >> > > On Mon, 6 Aug 2007, Ben Tay wrote: >> > > >> > > >> > > > Hi, >> > > > >> > > > I've no problem writing out codes in fortran fixed format >> with PETSc. >> > > > However, >> > > > is it possible to do it in fortran free format as well? >> > > > >> > > > I'm using visual fortran and there's error. >> > > > >> > > > original : >> > > > >> > > > test.F >> > > > >> > > > module global_data >> > > > >> > > > implicit none >> > > > >> > > > save >> > > > >> > > > #include "include/finclude/petsc.h" >> > > > #include "include/finclude/petscvec.h" >> > > > #include "include/finclude/petscmat.h" >> > > > #include "include/finclude/petscksp.h" >> > > > #include "include/finclude/petscpc.h" >> > > > #include "include/finclude/petscmat.h90" >> > > > >> > > > Vec xx,b_rhs >> > > > >> > > > .... >> > > > >> > > > How can I change this code to fortran free format *.f90? >> > > > >> > > > Thanks >> > > > >> > > > >> > > > >> > > >> > > >> > > >> > >> > >> >> > > From balay at mcs.anl.gov Tue Aug 7 11:42:01 2007 From: balay at mcs.anl.gov (Satish Balay) Date: Tue, 7 Aug 2007 11:42:01 -0500 (CDT) Subject: Programming in *.f90 free format with PETSc In-Reply-To: <804ab5d40708070126o3111c212gf3d386a7ee524a11@mail.gmail.com> References: <46B6A4AC.4010308@gmail.com> <46B6D6C6.1090504@gmail.com> <804ab5d40708070126o3111c212gf3d386a7ee524a11@mail.gmail.com> Message-ID: On Tue, 7 Aug 2007, Ben Tay wrote: > Hi, > > I can compile and run with visual fortran by putting all the declarations > inside a subroutine e.g. > > module ada > > ... > > subroutine ddd > > > #define PETSC_AVOID_DECLARATIONS > #include "include/finclude/petsc.h" > > #undef PETSC_AVOID_DECLARATIONS Using PETSC_AVOID_DECLARATIONS inside a subroutine is WRONG. You need declarations in subroutines [for ex: PETSC_NULL etc..] > > .... > > end subroutine ddd > > > end module ada > > However, on my school's server which uses ifort, I get errors both using > your way and my way e.g. > > > #define PETSC_AVOID_DECLARATIONS > #include "include/finclude/petsc.h" > #include "include/finclude/petscvec.h" > #include "include/finclude/petscmat.h" > #include "include/finclude/petscksp.h" > #include "include/finclude/petscpc.h" > #include "include/finclude/petscmat.h90" > #undef PETSC_AVOID_DECLARATIONS Remove include/finclude/petscmat.h90 from the above. the *.h90 files are not required here. I'll fix them to do no harm. > program test > > implicit none > > integer :: x,y > > Vec test_vec > > x=1 > > print *, x > > end program test > > I compile using > > ifort -r8 -132 -fPIC -g -c -static-libcxa -O3 -I/lsftmp/g0306332/petsc- > 2.3.3-p0 -I/lsftmp/g0306332/petsc-2.3.3-p0/bmake/atlas3 > -I/lsftmp/g0306332/petsc-2.3.3-p0/include -I/lsftmp/g0306332/petsc-2.3.3-p0 > /externalpackages/hypre-2.0.0/atlas3/include > -I/lsftmp/g0306332/mpich2/include temp.f90 The file should be temp.F90 If you still have errors, send the complete code so that I can reproduce the erorrs. Satish > > and get the error msg: > > fortcom: Warning: Bad # preprocessor line > fortcom: Warning: Bad # preprocessor line > fortcom: Warning: Bad # preprocessor line > fortcom: Warning: Bad # preprocessor line > fortcom: Warning: Bad # preprocessor line > fortcom: Warning: Bad # preprocessor line > fortcom: Warning: Bad # preprocessor line > fortcom: Warning: Bad # preprocessor line > > fortcom: Error: temp.f90, line 18: Syntax error, found IDENTIFIER 'TEST_VEC' > when expecting one of: => = . ( : % > Vec test_vec > ----^ > fortcom: Error: temp.f90, line 18: This name does not have a type, and must > have an explicit type. [VEC] > Vec test_vec > ^ > fortcom: Error: temp.f90, line 18: This name does not have a type, and must > have an explicit type. [TEST_VEC] > Vec test_vec > ----^ > compilation aborted for temp.f90 (code 1) > > I also tried shifting the declarations after the "program test" line but it > also failed. There is no problem if I changed the code to fixed format. > > Thanks > > > > > On 8/6/07, Satish Balay wrote: > > > > This is incorrect usage. > > > > If you are getting errors with the correct usage, send us the error > > messages, with your code, and we can sugest fixes. > > > > - one issue could be > > > > > > #define PETSC_AVOID_DECLARATIONS > > > > #include "include/finclude/petsc.h" > > > > #include "include/finclude/petscvec.h90" <--- This should be removed > > from here.. > > > > > > > > #undef PETSC_AVOID_DECLARATIONS > > > > > > > > moudle foobar > > > > > > > > end module > > > > > > Satish > > > > On Mon, 6 Aug 2007, Ben Tay wrote: > > > > > Hi, > > > > > > I tried to use > > > > > > #define PETSC_AVOID_DECLARATIONS > > > #include "include/finclude/petsc.h" > > > > > > #undef PETSC_AVOID_DECLARATIONS > > > > > > > > > module ada > > > ... > > > > > > subroutine .... > > > > > > end module ada > > > > > > but the compiler says that the module is placed in the wrong order. > > Anyway, I > > > just move the top 4 lines into the subroutine instead and it worked. > > Thanks > > > > > > module ada > > > > > > ... > > > > > > subroutine ddd > > > > > > #define PETSC_AVOID_DECLARATIONS > > > #include "include/finclude/petsc.h" > > > > > > #undef PETSC_AVOID_DECLARATIONS > > > > > > .... > > > > > > end subroutine ddd > > > > > > > > > > > > > > > Satish Balay wrote: > > > > you can use .F90 suffix for free-from preprocesed code. [or use > > > > compiler options to force it always use free-form] > > > > > > > > And when using fortran modules use the following organization: > > > > > > > > > > > > #define PETSC_AVOID_DECLARATIONS > > > > #include "include/finclude/petsc.h" > > > > > > > > #undef PETSC_AVOID_DECLARATIONS > > > > > > > > moudle foobar > > > > > > > > end module > > > > > > > > subroutine xyz() > > > > use foobar > > > > implicit none > > > > #include "include/finclude/petsc.h" > > > > > > > > > > > > end subroutine > > > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > > > > > Satish > > > > > > > > On Mon, 6 Aug 2007, Ben Tay wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > I've no problem writing out codes in fortran fixed format with > > PETSc. > > > > > However, > > > > > is it possible to do it in fortran free format as well? > > > > > > > > > > I'm using visual fortran and there's error. > > > > > > > > > > original : > > > > > > > > > > test.F > > > > > > > > > > module global_data > > > > > > > > > > implicit none > > > > > > > > > > save > > > > > > > > > > #include "include/finclude/petsc.h" > > > > > #include "include/finclude/petscvec.h" > > > > > #include "include/finclude/petscmat.h" > > > > > #include "include/finclude/petscksp.h" > > > > > #include "include/finclude/petscpc.h" > > > > > #include "include/finclude/petscmat.h90" > > > > > > > > > > Vec xx,b_rhs > > > > > > > > > > .... > > > > > > > > > > How can I change this code to fortran free format *.f90? > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From balay at mcs.anl.gov Tue Aug 7 12:04:11 2007 From: balay at mcs.anl.gov (Satish Balay) Date: Tue, 7 Aug 2007 12:04:11 -0500 (CDT) Subject: Programming in *.f90 free format with PETSc In-Reply-To: <804ab5d40708070126o3111c212gf3d386a7ee524a11@mail.gmail.com> References: <46B6A4AC.4010308@gmail.com> <46B6D6C6.1090504@gmail.com> <804ab5d40708070126o3111c212gf3d386a7ee524a11@mail.gmail.com> Message-ID: Let me reiterate the f90 include usage in modules and the rationale.. <<<<< #define PETSC_AVOID_DECLARATIONS #include "include/finclude/petsc.h" #include "include/finclude/petscvec.h" #undef PETSC_AVOID_DECLARATIONS moudle foobar Vec abc contains subroutine xyz() use foobar implicit none #include "include/finclude/petsc.h" #include "include/finclude/petscvec.h" #include "include/finclude/petscvec.h90" Vec foobar call VecNorm(foobar,NORM_MAX,...) end subroutine end module <<<<<< - Note: Currently .h90 files should not be listed inside PETSC_AVOID_DECLARATIONS. They are not necessary there. [I'll fix this issue in the next patch update]. The fortran includes have 2 types of code: - Macros: like 'Vec' that get preprocessed into integer*4. These macros are needed in both the module definition for 'abc', and in the subroutines 'foobar'. - Some DECLARATIONS like PETSC_NULL, NORM_MAX etc. These are declared as parameters <<<< integer NORM_MAX parameter NORM_MAX=3 >>> Such DELCARATIONS cannot be used inside the module 'data section?' This is because they become global variables, and will cause duplicate symbol errors. Also these declarations should be included in ALL subroutines. So one should not use PETSC_AVOID_DECLARATIONS in subroutines. Hence the recommended usage. There is another alternative usage - creating petsc.mod etc. One can create these files by doing: cd include/finclude make all [I haven't explored this usage completely] Satish From pbauman at ices.utexas.edu Tue Aug 7 14:49:08 2007 From: pbauman at ices.utexas.edu (Paul T. Bauman) Date: Tue, 07 Aug 2007 14:49:08 -0500 Subject: FORTRAN usage of SNESSetConvergenceHistory In-Reply-To: References: <46B7C306.3080600@ices.utexas.edu> Message-ID: <46B8CCB4.5030809@ices.utexas.edu> Hi Barry, Thanks. I didn't make it that far down in the manpage before I sent the email - sorry. I got everything to work fine. Paul Barry Smith wrote: > Paul, > > Yes it is intended one can use them from Fortran. Note from the manual > page for SNESGetConvergenceHistory() it does not return the arrays, just the > count. You must keep around the arrays you passed into > SNESSetConvergenceHistory() and read from them. > > Barry > > > On Mon, 6 Aug 2007, Paul T. Bauman wrote: > > >> Hello, >> >> Is it possible to use SNESSetConvergenceHistory/SNESGetConvergenceHistory with >> FORTRAN? Thanks, >> >> Paul >> >> >> From sumit_vaidya at persistent.co.in Wed Aug 8 04:04:51 2007 From: sumit_vaidya at persistent.co.in (Sumit Vaidya) Date: Wed, 8 Aug 2007 14:34:51 +0530 Subject: Testing only 'vec' folder Message-ID: <000101c7d99b$2e225a30$4598580a@persistent.co.in> I want to test the source files present in 'src\vec\vec\examples\tests' folder. How to achieve it? Like the command 'make ACTION=lib tree', is there any other command to test the examples of particular source directory? I know 'make test' command. But this command tests all the examples. I want to test the examples of only 'vec' directory. How to do this? Regards, Sumit DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsmith at mcs.anl.gov Wed Aug 8 07:44:24 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Wed, 8 Aug 2007 07:44:24 -0500 (CDT) Subject: Testing only 'vec' folder In-Reply-To: <000101c7d99b$2e225a30$4598580a@persistent.co.in> References: <000101c7d99b$2e225a30$4598580a@persistent.co.in> Message-ID: make testexamples_C testexamples_C_X11 testexamples_FORTRAN see the bottom of the makefile for the various possibilities. Barry On Wed, 8 Aug 2007, Sumit Vaidya wrote: > I want to test the source files present in 'src\vec\vec\examples\tests' > folder. > > > > How to achieve it? Like the command 'make ACTION=lib tree', is there any > other command to test the examples of particular source directory? > > I know 'make test' command. But this command tests all the examples. I want > to test the examples of only 'vec' directory. > > > > How to do this? > > > > Regards, > > Sumit > > > DISCLAIMER > ========== > This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. > From zonexo at gmail.com Wed Aug 8 19:07:08 2007 From: zonexo at gmail.com (Ben Tay) Date: Thu, 09 Aug 2007 08:07:08 +0800 Subject: Programming in *.f90 free format with PETSc In-Reply-To: References: <46B6A4AC.4010308@gmail.com> <46B6D6C6.1090504@gmail.com> <804ab5d40708070126o3111c212gf3d386a7ee524a11@mail.gmail.com> Message-ID: <46BA5AAC.7020601@gmail.com> Hi, when I changed my global.F to global.f90, I was told that PETSC_COMM_SELF, PETSC_NULL_INTEGER and PETSC_NULL_CHARACTER does not have a type. I declare MPI_Comm PETSC_COMM_SELF and it works So, what about the other 2? You mention to use integer NORM_MAX parameter NORM_MAX=3 What values do I use then? Thanks Satish Balay wrote: > Let me reiterate the f90 include usage in modules and the rationale.. > > <<<<< > #define PETSC_AVOID_DECLARATIONS > #include "include/finclude/petsc.h" > #include "include/finclude/petscvec.h" > > #undef PETSC_AVOID_DECLARATIONS > > moudle foobar > > Vec abc > > contains > subroutine xyz() > use foobar > implicit none > #include "include/finclude/petsc.h" > #include "include/finclude/petscvec.h" > #include "include/finclude/petscvec.h90" > > Vec foobar > call VecNorm(foobar,NORM_MAX,...) > > end subroutine > end module > <<<<<< > > - Note: Currently .h90 files should not be listed inside > PETSC_AVOID_DECLARATIONS. They are not necessary there. [I'll fix > this issue in the next patch update]. > > The fortran includes have 2 types of code: > > - Macros: like 'Vec' that get preprocessed into integer*4. These > macros are needed in both the module definition for 'abc', and > in the subroutines 'foobar'. > > - Some DECLARATIONS like PETSC_NULL, NORM_MAX etc. These are > declared as parameters > <<<< > integer NORM_MAX > parameter NORM_MAX=3 > > > Such DELCARATIONS cannot be used inside the module 'data section?' > This is because they become global variables, and will cause duplicate > symbol errors. > > Also these declarations should be included in ALL subroutines. So one > should not use PETSC_AVOID_DECLARATIONS in subroutines. > > Hence the recommended usage. There is another alternative usage - > creating petsc.mod etc. One can create these files by doing: > > cd include/finclude > make all > > [I haven't explored this usage completely] > > Satish > > > From zonexo at gmail.com Wed Aug 8 22:00:23 2007 From: zonexo at gmail.com (Ben Tay) Date: Thu, 09 Aug 2007 11:00:23 +0800 Subject: Conversion matrix from Ellpack-Itpack to CSR to PETSc format Message-ID: <46BA8347.2070903@gmail.com> Hi, My original matrix is stored in Ellpack-Itpack format, which is used by the NSPCG solver. I have problems when I insert the values of the matrix into a PETSc matrix. I guessed I made some mistakes but I can't find where during debugging. So I intent to just convert from the Ellpack-Itpack to CSR using a subroutine by SPARSKIT2 called ellcsr. Then I use MatCreateSeqAIJWithArrays to get my PETSc matrix. I'm programming in fortran so index starts from 1. I tried to shift the row and column index by -1. The 1st step works but there's error when solving at the 2nd time step. The error is: [0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably m emory 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/petsc-as/documentation/troub leshooting.html#Signal[0]PETSC ERROR: or try http://valgrind.org on linux or man libgmalloc on Apple 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. My subroutine is as follows: Note that A_mat is declared as global variable. if (time==1) then call ellcsr(total_k,big_A,int_a,total_k,9,A_spar,ja_spar,ia_spar,nzmax,ierr) - convert big_A,int_A in Ellpack-Itpack format to CSR using ellcsr ia_spar=ia_spar-1; ja_spar=ja_spar-1 - shift by -1 call MatCreateSeqAIJWithArrays(PETSC_COMM_SELF,Ntot,13,ia_spar,ja_spar,A_spar,A_mat_spar,ierr) call MatAssemblyBegin(A_mat,MAT_FINAL_ASSEMBLY,ierr) call MatAssemblyEnd(A_mat,MAT_FINAL_ASSEMBLY,ierr) end if ... I thought I would only need to do this once since the A_mat does not change and it is declared globally. If I remove the "IF - END IF" and execute at every time step, everything will be fine. But I thought that will be very inefficient. So how should I solve the problem? Thanks From balay at mcs.anl.gov Thu Aug 9 01:16:04 2007 From: balay at mcs.anl.gov (Satish Balay) Date: Thu, 9 Aug 2007 01:16:04 -0500 (CDT) Subject: Programming in *.f90 free format with PETSc In-Reply-To: <46BA5AAC.7020601@gmail.com> References: <46B6A4AC.4010308@gmail.com> <46B6D6C6.1090504@gmail.com> <804ab5d40708070126o3111c212gf3d386a7ee524a11@mail.gmail.com> <46BA5AAC.7020601@gmail.com> Message-ID: On Thu, 9 Aug 2007, Ben Tay wrote: > Hi, > > when I changed my global.F to global.f90, Any perticular reason why you keep using .f90 suffix even though I've recommended using .F90 suffix [for preprocessed free form] a few times? > I was told that PETSC_COMM_SELF, PETSC_NULL_INTEGER and > PETSC_NULL_CHARACTER does not have a type. Please send a test code that demonstrates this problem. Satish From balay at mcs.anl.gov Thu Aug 9 01:30:53 2007 From: balay at mcs.anl.gov (Satish Balay) Date: Thu, 9 Aug 2007 01:30:53 -0500 (CDT) Subject: Conversion matrix from Ellpack-Itpack to CSR to PETSc format In-Reply-To: <46BA8347.2070903@gmail.com> References: <46BA8347.2070903@gmail.com> Message-ID: - make sure the input to MatCreateSeqAIJWithArrays() is correct as per the example in the manpage - run it in the debugger to determine the actual cause of the problem Satish On Thu, 9 Aug 2007, Ben Tay wrote: > Hi, > > My original matrix is stored in Ellpack-Itpack format, which is used by the > NSPCG solver. I have problems when I insert the values of the matrix into a > PETSc matrix. I guessed I made some mistakes but I can't find where during > debugging. So I intent to just convert from the Ellpack-Itpack to CSR using a > subroutine by SPARSKIT2 called ellcsr. Then I use MatCreateSeqAIJWithArrays to > get my PETSc matrix. > I'm programming in fortran so index starts from 1. I tried to shift the row > and column index by -1. The 1st step works but there's error when solving at > the 2nd time step. The error is: > > [0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably > m > emory 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/petsc-as/documentation/troub > leshooting.html#Signal[0]PETSC ERROR: or try http://valgrind.org on linux or > man > libgmalloc on Apple 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. > > > > > My subroutine is as follows: > > Note that A_mat is declared as global variable. > > if (time==1) then > > call > ellcsr(total_k,big_A,int_a,total_k,9,A_spar,ja_spar,ia_spar,nzmax,ierr) - > convert big_A,int_A in Ellpack-Itpack format to CSR using ellcsr > > ia_spar=ia_spar-1; ja_spar=ja_spar-1 - shift by -1 > > call > MatCreateSeqAIJWithArrays(PETSC_COMM_SELF,Ntot,13,ia_spar,ja_spar,A_spar,A_mat_spar,ierr) > > call MatAssemblyBegin(A_mat,MAT_FINAL_ASSEMBLY,ierr) > > call MatAssemblyEnd(A_mat,MAT_FINAL_ASSEMBLY,ierr) > > end if > > ... > > I thought I would only need to do this once since the A_mat does not change > and it is declared globally. If I remove the "IF - END IF" and execute at > every time step, everything will be fine. But I thought that will be very > inefficient. So how should I solve the problem? > > Thanks > > > From zonexo at gmail.com Thu Aug 9 01:45:32 2007 From: zonexo at gmail.com (Ben Tay) Date: Thu, 09 Aug 2007 14:45:32 +0800 Subject: Programming in *.f90 free format with PETSc In-Reply-To: References: <46B6A4AC.4010308@gmail.com> <46B6D6C6.1090504@gmail.com> <804ab5d40708070126o3111c212gf3d386a7ee524a11@mail.gmail.com> <46BA5AAC.7020601@gmail.com> Message-ID: <46BAB80C.2030807@gmail.com> Hi, Guess I'm too used to typing .f90 ;-) .... I've changed it to .F90 before but perhaps at that time the error I got didn't disappear so I didn't bother after that. I'm working in windows so I thought the capital letter doesn't really matter. Moreover, .f90 also works with my ifort in linux. Is it really important? If so, I'll change all my .f90 to F90. Thanks for highlighting. Here's a sample code test.F90: module global_data implicit none save #define PETSC_AVOID_DECLARATIONS #include "include/finclude/petsc.h" #include "include/finclude/petscvec.h" #include "include/finclude/petscmat.h" #include "include/finclude/petscksp.h" #include "include/finclude/petscpc.h" #undef PETSC_AVOID_DECLARATIONS integer :: size_x,size_y Mat A_mat ! /* sparse matrix */ !MPI_Comm PETSC_COMM_SELF - commented out will result in error contains subroutine allo_var !allocate memory for variables integer :: status(2),ierr,k size_x=10;size_y=10 call PetscInitialize(PETSC_NULL_CHARACTER,ierr) call MatCreateSeqAIJ(PETSC_COMM_SELF,size_x*size_y,size_x*size_y,13,PETSC_NULL_INTEGER,A_mat,ierr) end subroutine allo_var end module global_data I got "Error: This name does not have a type, and must have an explicit type. [PETSC_NULL_CHARACTER]". Same for PETSC_NULL_INTEGER and PETSC_COMM_SELF. It was ok when I'm programming in fixed format. Thanks Satish Balay wrote: > On Thu, 9 Aug 2007, Ben Tay wrote: > > >> Hi, >> >> when I changed my global.F to global.f90, >> > > Any perticular reason why you keep using .f90 suffix even though I've > recommended using .F90 suffix [for preprocessed free form] a few > times? > > >> I was told that PETSC_COMM_SELF, PETSC_NULL_INTEGER and >> PETSC_NULL_CHARACTER does not have a type. >> > > Please send a test code that demonstrates this problem. > > Satish > > > From balay at mcs.anl.gov Thu Aug 9 01:58:09 2007 From: balay at mcs.anl.gov (Satish Balay) Date: Thu, 9 Aug 2007 01:58:09 -0500 (CDT) Subject: Programming in *.f90 free format with PETSc In-Reply-To: <46BAB80C.2030807@gmail.com> References: <46B6A4AC.4010308@gmail.com> <46B6D6C6.1090504@gmail.com> <804ab5d40708070126o3111c212gf3d386a7ee524a11@mail.gmail.com> <46BA5AAC.7020601@gmail.com> <46BAB80C.2030807@gmail.com> Message-ID: On Thu, 9 Aug 2007, Ben Tay wrote: > Hi, > > Guess I'm too used to typing .f90 ;-) .... I've changed it to .F90 before but > perhaps at that time the error I got didn't disappear so I didn't bother after > that. I'm sorry - but you can't keep silently discarding the sugestions we make and keep reporting the same issues multiple times.. This is frustrating. > I'm working in windows so I thought the capital letter doesn't really > matter. I've indicated this before. Most compilers use .F90 for prerpocessed free form. And you keep indicating this is what you require. [Most compilers don't preprocess .f90 files] > Moreover, .f90 also works with my ifort in linux. Is it really > important? If so, I'll change all my .f90 to F90. Thanks for highlighting. > > Here's a sample code test.F90: I'll need a test code that can reproduce the problems you report. > > module global_data > > implicit none > > save > > #define PETSC_AVOID_DECLARATIONS > #include "include/finclude/petsc.h" > #include "include/finclude/petscvec.h" > #include "include/finclude/petscmat.h" > #include "include/finclude/petscksp.h" > #include "include/finclude/petscpc.h" > #undef PETSC_AVOID_DECLARATIONS > > integer :: size_x,size_y > > Mat A_mat ! /* sparse matrix */ > > !MPI_Comm PETSC_COMM_SELF - commented out will result in error > > contains > > subroutine allo_var Again you are ignoring the sample template I sent you. You need to include PETSc include files in every subroutine. I'm sorry I can't repeat this anymore. Satish > > !allocate memory for variables > > integer :: status(2),ierr,k > > size_x=10;size_y=10 > > call PetscInitialize(PETSC_NULL_CHARACTER,ierr) > > call > MatCreateSeqAIJ(PETSC_COMM_SELF,size_x*size_y,size_x*size_y,13,PETSC_NULL_INTEGER,A_mat,ierr) > > end subroutine allo_var > > end module global_data > > I got "Error: This name does not have a type, and must have an explicit type. > [PETSC_NULL_CHARACTER]". Same for PETSC_NULL_INTEGER and PETSC_COMM_SELF. > > It was ok when I'm programming in fixed format. > > Thanks > > Satish Balay wrote: > > On Thu, 9 Aug 2007, Ben Tay wrote: > > > > > > > Hi, > > > > > > when I changed my global.F to global.f90, > > > > > > > Any perticular reason why you keep using .f90 suffix even though I've > > recommended using .F90 suffix [for preprocessed free form] a few > > times? > > > > > > > I was told that PETSC_COMM_SELF, PETSC_NULL_INTEGER and > > > PETSC_NULL_CHARACTER does not have a type. > > > > > > > Please send a test code that demonstrates this problem. > > > > Satish > > > > > > > > From zonexo at gmail.com Thu Aug 9 03:20:46 2007 From: zonexo at gmail.com (Ben Tay) Date: Thu, 09 Aug 2007 16:20:46 +0800 Subject: Programming in *.f90 free format with PETSc In-Reply-To: References: <46B6A4AC.4010308@gmail.com> <46B6D6C6.1090504@gmail.com> <804ab5d40708070126o3111c212gf3d386a7ee524a11@mail.gmail.com> <46BA5AAC.7020601@gmail.com> <46BAB80C.2030807@gmail.com> Message-ID: <46BACE5E.3090602@gmail.com> Hi Satish, I am sorry if I have made you angry. I may have missed out some important points which you tried to highlight. I was converting several of my .F fixed format files to .f90 (or .F90) free format and some files which don't need declaration of PETSc type variable worked while some don't. However, I must clarify that the .f90 or .F90 did not bother me after a while since in visual fortran or ifort, using the option -fpp enables the .f90 files to be preprocessed too. Of course, if .F90 was used, -fpp is not required. In my sample file shown just now, I did not have any include statments in my subroutine. They're only present in the module 's section. Checking your prev. email, you indeed mention that the PETSc includes files must be in each and every subroutine. However, doing this gave me more errors. Hence, I've followed another user (Paul T Bauman) 's recommendation which states that only preprocessed statements not inside the module needs to be placed inside the subroutine. With this, I only has 3 errors, which concerns PETSC_COMM_SELF, PETSC_NULL_INTEGER and PETSC_NULL_CHARACTER not having an explicit type. I figured out that using: MPI_Comm PETSC_COMM_SELF will eliminate 1 error, although it was not required before. However, what about the other 2? Should I defined them as integer or character and give them a value using parameter? What value should I give them? You mention this in your prev email: integer NORM_MAX parameter NORM_MAX=3 You also give a template to follow. I also tried to cut and paste and use it but it gave lots of error. I had used it in visual fortran : #define PETSC_AVOID_DECLARATIONS #include "include/finclude/petsc.h" #include "include/finclude/petscvec.h" #undef PETSC_AVOID_DECLARATIONS module foobar Vec abc contains subroutine xyz() use foobar implicit none #include "include/finclude/petsc.h" #include "include/finclude/petscvec.h" #include "include/finclude/petscvec.h90" Vec fbar end subroutine end module As said above, upon removing the include files in the subroutine and the "use foobar" statement, everything's ok. You can give it a try too. Lastly, I understand that you have been helping a lot of users and there's really a lot of stupid users around (I know I'm one of them ;-) ). Thank you for your patience. Satish Balay wrote: > On Thu, 9 Aug 2007, Ben Tay wrote: > > >> Hi, >> >> Guess I'm too used to typing .f90 ;-) .... I've changed it to .F90 before but >> perhaps at that time the error I got didn't disappear so I didn't bother after >> that. >> > > I'm sorry - but you can't keep silently discarding the sugestions we > make and keep reporting the same issues multiple times.. > > This is frustrating. > > >> I'm working in windows so I thought the capital letter doesn't really >> matter. >> > > I've indicated this before. Most compilers use .F90 for prerpocessed > free form. And you keep indicating this is what you require. [Most > compilers don't preprocess .f90 files] > > >> Moreover, .f90 also works with my ifort in linux. Is it really >> important? If so, I'll change all my .f90 to F90. Thanks for highlighting. >> >> Here's a sample code test.F90: >> > > I'll need a test code that can reproduce the problems you report. > > >> module global_data >> >> implicit none >> >> save >> >> #define PETSC_AVOID_DECLARATIONS >> #include "include/finclude/petsc.h" >> #include "include/finclude/petscvec.h" >> #include "include/finclude/petscmat.h" >> #include "include/finclude/petscksp.h" >> #include "include/finclude/petscpc.h" >> #undef PETSC_AVOID_DECLARATIONS >> >> integer :: size_x,size_y >> >> Mat A_mat ! /* sparse matrix */ >> >> !MPI_Comm PETSC_COMM_SELF - commented out will result in error >> >> contains >> >> subroutine allo_var >> > > Again you are ignoring the sample template I sent you. You need to > include PETSc include files in every subroutine. > > I'm sorry I can't repeat this anymore. > > Satish > > >> !allocate memory for variables >> >> integer :: status(2),ierr,k >> >> size_x=10;size_y=10 >> >> call PetscInitialize(PETSC_NULL_CHARACTER,ierr) >> >> call >> MatCreateSeqAIJ(PETSC_COMM_SELF,size_x*size_y,size_x*size_y,13,PETSC_NULL_INTEGER,A_mat,ierr) >> >> end subroutine allo_var >> >> end module global_data >> >> I got "Error: This name does not have a type, and must have an explicit type. >> [PETSC_NULL_CHARACTER]". Same for PETSC_NULL_INTEGER and PETSC_COMM_SELF. >> >> It was ok when I'm programming in fixed format. >> >> Thanks >> >> Satish Balay wrote: >> >>> On Thu, 9 Aug 2007, Ben Tay wrote: >>> >>> >>> >>>> Hi, >>>> >>>> when I changed my global.F to global.f90, >>>> >>>> >>> Any perticular reason why you keep using .f90 suffix even though I've >>> recommended using .F90 suffix [for preprocessed free form] a few >>> times? >>> >>> >>> >>>> I was told that PETSC_COMM_SELF, PETSC_NULL_INTEGER and >>>> PETSC_NULL_CHARACTER does not have a type. >>>> >>>> >>> Please send a test code that demonstrates this problem. >>> >>> Satish >>> >>> >>> >>> >> > > > From jwicks at cs.brown.edu Thu Aug 9 09:47:25 2007 From: jwicks at cs.brown.edu (John R. Wicks) Date: Thu, 9 Aug 2007 10:47:25 -0400 Subject: Problem with mpicxx In-Reply-To: <000101c7d83b$f9ac30b0$6b249480@jwickslptp> Message-ID: <000001c7da94$354381a0$7900000a@jwickslptp> I would like to define a class with a matrix as an member: class Foo { public: Mat A; }; I would expect that when an instance of Foo is created, A should be initialized, just as it would be if it were declared as ordinary variable in C: int main (int argc,char **args) { Mat A; ... However, when an instance of Foo is created, A is initialized to NULL. How can I get it to initialize properly? From knepley at gmail.com Thu Aug 9 10:09:55 2007 From: knepley at gmail.com (Matthew Knepley) Date: Thu, 9 Aug 2007 10:09:55 -0500 Subject: Problem with mpicxx In-Reply-To: <000001c7da94$354381a0$7900000a@jwickslptp> References: <000101c7d83b$f9ac30b0$6b249480@jwickslptp> <000001c7da94$354381a0$7900000a@jwickslptp> Message-ID: Mat is just a typedef for a pointer, so NULL initialization is correct. You should put a call to MatCreate() in the constructor if you want the object to be initialized. Thanks, Matt On 8/9/07, John R. Wicks wrote: > I would like to define a class with a matrix as an member: > > class Foo { > > public: > > Mat A; > }; > > I would expect that when an instance of Foo is created, A should be > initialized, just as it would be if it were declared as ordinary variable in > C: > int main (int argc,char **args) { > Mat A; > ... > > However, when an instance of Foo is created, A is initialized to NULL. How > can I get it to initialize properly? > > -- 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 From balay at mcs.anl.gov Thu Aug 9 10:50:04 2007 From: balay at mcs.anl.gov (Satish Balay) Date: Thu, 9 Aug 2007 10:50:04 -0500 (CDT) Subject: Programming in *.f90 free format with PETSc In-Reply-To: <46BACE5E.3090602@gmail.com> References: <46B6A4AC.4010308@gmail.com> <46B6D6C6.1090504@gmail.com> <804ab5d40708070126o3111c212gf3d386a7ee524a11@mail.gmail.com> <46BA5AAC.7020601@gmail.com> <46BAB80C.2030807@gmail.com> <46BACE5E.3090602@gmail.com> Message-ID: > However, doing this gave me more errors. Hence, I've followed > another If you get errors with the recommended model - you sould report the erros [not silently try something else - and then report erros with this something else] I can't help you anymore unless you can report problems with a reproduceable test code that I can comiile locally. Satish On Thu, 9 Aug 2007, Ben Tay wrote: > Hi Satish, > > I am sorry if I have made you angry. I may have missed out some important > points which you tried to highlight. I was converting several of my .F fixed > format files to .f90 (or .F90) free format and some files which don't need > declaration of PETSc type variable worked while some don't. > > However, I must clarify that the .f90 or .F90 did not bother me after a while > since in visual fortran or ifort, using the option -fpp enables the .f90 files > to be preprocessed too. Of course, if .F90 was used, -fpp is not required. > > In my sample file shown just now, I did not have any include statments in my > subroutine. They're only present in the module 's section. Checking your prev. > email, you indeed mention that the PETSc includes files must be in each and > every subroutine. However, doing this gave me more errors. Hence, I've > followed another user (Paul T Bauman) 's recommendation which states that only > preprocessed statements not inside the module needs to be placed inside the > subroutine. With this, I only has 3 errors, which concerns PETSC_COMM_SELF, > PETSC_NULL_INTEGER and PETSC_NULL_CHARACTER not having an explicit type. I > figured out that using: > > MPI_Comm PETSC_COMM_SELF > > > will eliminate 1 error, although it was not required before. However, what > about the other 2? Should I defined them as integer or character and give them > a value using parameter? What value should I give them? You mention this in > your prev email: > > integer NORM_MAX > parameter NORM_MAX=3 > > > You also give a template to follow. I also tried to cut and paste and use it > but it gave lots of error. I had used it in visual fortran : > > #define PETSC_AVOID_DECLARATIONS > #include "include/finclude/petsc.h" > #include "include/finclude/petscvec.h" > #undef PETSC_AVOID_DECLARATIONS > > module foobar > > Vec abc > > contains > subroutine xyz() > use foobar > implicit none > #include "include/finclude/petsc.h" > #include "include/finclude/petscvec.h" > #include "include/finclude/petscvec.h90" > > Vec fbar > > > end subroutine > end module > > As said above, upon removing the include files in the subroutine and the "use > foobar" statement, everything's ok. You can give it a try too. > > Lastly, I understand that you have been helping a lot of users and there's > really a lot of stupid users around (I know I'm one of them ;-) ). Thank you > for your patience. > > Satish Balay wrote: > > On Thu, 9 Aug 2007, Ben Tay wrote: > > > > > > > Hi, > > > > > > Guess I'm too used to typing .f90 ;-) .... I've changed it to .F90 before > > > but > > > perhaps at that time the error I got didn't disappear so I didn't bother > > > after > > > that. > > > > I'm sorry - but you can't keep silently discarding the sugestions we > > make and keep reporting the same issues multiple times.. > > > > This is frustrating. > > > > > > > I'm working in windows so I thought the capital letter doesn't really > > > matter. > > > > > > > I've indicated this before. Most compilers use .F90 for prerpocessed > > free form. And you keep indicating this is what you require. [Most > > compilers don't preprocess .f90 files] > > > > > > > Moreover, .f90 also works with my ifort in linux. Is it really > > > important? If so, I'll change all my .f90 to F90. Thanks for highlighting. > > > > > > Here's a sample code test.F90: > > > > > > > I'll need a test code that can reproduce the problems you report. > > > > > > > module global_data > > > > > > implicit none > > > > > > save > > > > > > #define PETSC_AVOID_DECLARATIONS > > > #include "include/finclude/petsc.h" > > > #include "include/finclude/petscvec.h" > > > #include "include/finclude/petscmat.h" > > > #include "include/finclude/petscksp.h" > > > #include "include/finclude/petscpc.h" > > > #undef PETSC_AVOID_DECLARATIONS > > > > > > integer :: size_x,size_y > > > > > > Mat A_mat ! /* sparse matrix */ > > > > > > !MPI_Comm PETSC_COMM_SELF - commented out will result in error > > > > > > contains > > > > > > subroutine allo_var > > > > > > > Again you are ignoring the sample template I sent you. You need to > > include PETSc include files in every subroutine. > > > > I'm sorry I can't repeat this anymore. > > > > Satish > > > > > > > !allocate memory for variables > > > > > > integer :: status(2),ierr,k > > > > > > size_x=10;size_y=10 > > > > > > call PetscInitialize(PETSC_NULL_CHARACTER,ierr) > > > > > > call > > > MatCreateSeqAIJ(PETSC_COMM_SELF,size_x*size_y,size_x*size_y,13,PETSC_NULL_INTEGER,A_mat,ierr) > > > > > > end subroutine allo_var > > > > > > end module global_data > > > > > > I got "Error: This name does not have a type, and must have an explicit > > > type. > > > [PETSC_NULL_CHARACTER]". Same for PETSC_NULL_INTEGER and PETSC_COMM_SELF. > > > > > > It was ok when I'm programming in fixed format. > > > > > > Thanks > > > > > > Satish Balay wrote: > > > > > > > On Thu, 9 Aug 2007, Ben Tay wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > when I changed my global.F to global.f90, > > > > > > > > > Any perticular reason why you keep using .f90 suffix even though I've > > > > recommended using .F90 suffix [for preprocessed free form] a few > > > > times? > > > > > > > > > > > > > I was told that PETSC_COMM_SELF, PETSC_NULL_INTEGER and > > > > > PETSC_NULL_CHARACTER does not have a type. > > > > > > > > > Please send a test code that demonstrates this problem. > > > > > > > > Satish > > > > > > > > > > > > > > > > > > > > > > > From zonexo at gmail.com Thu Aug 9 19:41:43 2007 From: zonexo at gmail.com (Ben Tay) Date: Fri, 10 Aug 2007 08:41:43 +0800 Subject: Programming in *.f90 free format with PETSc In-Reply-To: References: <46B6A4AC.4010308@gmail.com> <46B6D6C6.1090504@gmail.com> <804ab5d40708070126o3111c212gf3d386a7ee524a11@mail.gmail.com> <46BA5AAC.7020601@gmail.com> <46BAB80C.2030807@gmail.com> <46BACE5E.3090602@gmail.com> Message-ID: <46BBB447.9030707@gmail.com> Ok, I understand now. I just tested your recommended code on my school's linux server which uses ifort. It works w/o any error. Here's the code: #define PETSC_AVOID_DECLARATIONS #include "include/finclude/petsc.h" #include "include/finclude/petscvec.h" #undef PETSC_AVOID_DECLARATIONS module foobar Vec abc contains subroutine xyz() implicit none #include "include/finclude/petsc.h" #include "include/finclude/petscvec.h" Vec fbar integer ierr call PetscInitialize(PETSC_NULL_CHARACTER,ierr) end subroutine end module Everything is similar to your recommended format except the "use foobar" is removed. The strange thing is when I try to compile on my windows's visual fortran, it gives lots of error. The errors all point to mpif.h. Some errors are: d:\cygwin\codes\MPICH\SDK\include\mpif.h(1) : Error: Syntax error, found END-OF-STATEMENT when expecting one of: ( : % . = => C -^ d:\cygwin\codes\MPICH\SDK\include\mpif.h(2) : Error: Syntax error, found END-OF-STATEMENT when expecting one of: ( : % . = => C -^ d:\cygwin\codes\MPICH\SDK\include\mpif.h(3) : Error: Syntax error, found INTEGER_CONSTANT '1993' when expecting one of: ( % . = => C (C) 1993 by Argonne National Laboratory and Mississipi State University. -------^ My include directory uses d:\cygwin\codes\MPICH\SDK\include. So how should I deal with this mistake? I do all my code writing and basic debugging on the visual fortran and I only run my working code on linux. Hence, I did not try your recommendation on the linux. When I reduced the errors to just 3 (none explicit declaration of PETSC_NULL_CHARACTER etc), I thought I'm going in the right direction. But in fact I was on the wrong track. Thank you very much and sorry for the inconvenience. Satish Balay wrote: >> However, doing this gave me more errors. Hence, I've followed >> another >> > > If you get errors with the recommended model - you sould report the > erros [not silently try something else - and then report erros with > this something else] > > I can't help you anymore unless you can report problems with a > reproduceable test code that I can comiile locally. > > Satish > > On Thu, 9 Aug 2007, Ben Tay wrote: > > >> Hi Satish, >> >> I am sorry if I have made you angry. I may have missed out some important >> points which you tried to highlight. I was converting several of my .F fixed >> format files to .f90 (or .F90) free format and some files which don't need >> declaration of PETSc type variable worked while some don't. >> >> However, I must clarify that the .f90 or .F90 did not bother me after a while >> since in visual fortran or ifort, using the option -fpp enables the .f90 files >> to be preprocessed too. Of course, if .F90 was used, -fpp is not required. >> >> In my sample file shown just now, I did not have any include statments in my >> subroutine. They're only present in the module 's section. Checking your prev. >> email, you indeed mention that the PETSc includes files must be in each and >> every subroutine. However, doing this gave me more errors. Hence, I've >> followed another user (Paul T Bauman) 's recommendation which states that only >> preprocessed statements not inside the module needs to be placed inside the >> subroutine. With this, I only has 3 errors, which concerns PETSC_COMM_SELF, >> PETSC_NULL_INTEGER and PETSC_NULL_CHARACTER not having an explicit type. I >> figured out that using: >> >> MPI_Comm PETSC_COMM_SELF >> >> >> will eliminate 1 error, although it was not required before. However, what >> about the other 2? Should I defined them as integer or character and give them >> a value using parameter? What value should I give them? You mention this in >> your prev email: >> >> integer NORM_MAX >> parameter NORM_MAX=3 >> >> >> You also give a template to follow. I also tried to cut and paste and use it >> but it gave lots of error. I had used it in visual fortran : >> >> #define PETSC_AVOID_DECLARATIONS >> #include "include/finclude/petsc.h" >> #include "include/finclude/petscvec.h" >> #undef PETSC_AVOID_DECLARATIONS >> >> module foobar >> >> Vec abc >> >> contains >> subroutine xyz() >> use foobar >> implicit none >> #include "include/finclude/petsc.h" >> #include "include/finclude/petscvec.h" >> #include "include/finclude/petscvec.h90" >> >> Vec fbar >> >> >> end subroutine >> end module >> >> As said above, upon removing the include files in the subroutine and the "use >> foobar" statement, everything's ok. You can give it a try too. >> >> Lastly, I understand that you have been helping a lot of users and there's >> really a lot of stupid users around (I know I'm one of them ;-) ). Thank you >> for your patience. >> >> Satish Balay wrote: >> >>> On Thu, 9 Aug 2007, Ben Tay wrote: >>> >>> >>> >>>> Hi, >>>> >>>> Guess I'm too used to typing .f90 ;-) .... I've changed it to .F90 before >>>> but >>>> perhaps at that time the error I got didn't disappear so I didn't bother >>>> after >>>> that. >>>> >>> I'm sorry - but you can't keep silently discarding the sugestions we >>> make and keep reporting the same issues multiple times.. >>> >>> This is frustrating. >>> >>> >>> >>>> I'm working in windows so I thought the capital letter doesn't really >>>> matter. >>>> >>>> >>> I've indicated this before. Most compilers use .F90 for prerpocessed >>> free form. And you keep indicating this is what you require. [Most >>> compilers don't preprocess .f90 files] >>> >>> >>> >>>> Moreover, .f90 also works with my ifort in linux. Is it really >>>> important? If so, I'll change all my .f90 to F90. Thanks for highlighting. >>>> >>>> Here's a sample code test.F90: >>>> >>>> >>> I'll need a test code that can reproduce the problems you report. >>> >>> >>> >>>> module global_data >>>> >>>> implicit none >>>> >>>> save >>>> >>>> #define PETSC_AVOID_DECLARATIONS >>>> #include "include/finclude/petsc.h" >>>> #include "include/finclude/petscvec.h" >>>> #include "include/finclude/petscmat.h" >>>> #include "include/finclude/petscksp.h" >>>> #include "include/finclude/petscpc.h" >>>> #undef PETSC_AVOID_DECLARATIONS >>>> >>>> integer :: size_x,size_y >>>> >>>> Mat A_mat ! /* sparse matrix */ >>>> >>>> !MPI_Comm PETSC_COMM_SELF - commented out will result in error >>>> >>>> contains >>>> >>>> subroutine allo_var >>>> >>>> >>> Again you are ignoring the sample template I sent you. You need to >>> include PETSc include files in every subroutine. >>> >>> I'm sorry I can't repeat this anymore. >>> >>> Satish >>> >>> >>> >>>> !allocate memory for variables >>>> >>>> integer :: status(2),ierr,k >>>> >>>> size_x=10;size_y=10 >>>> >>>> call PetscInitialize(PETSC_NULL_CHARACTER,ierr) >>>> >>>> call >>>> MatCreateSeqAIJ(PETSC_COMM_SELF,size_x*size_y,size_x*size_y,13,PETSC_NULL_INTEGER,A_mat,ierr) >>>> >>>> end subroutine allo_var >>>> >>>> end module global_data >>>> >>>> I got "Error: This name does not have a type, and must have an explicit >>>> type. >>>> [PETSC_NULL_CHARACTER]". Same for PETSC_NULL_INTEGER and PETSC_COMM_SELF. >>>> >>>> It was ok when I'm programming in fixed format. >>>> >>>> Thanks >>>> >>>> Satish Balay wrote: >>>> >>>> >>>>> On Thu, 9 Aug 2007, Ben Tay wrote: >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> when I changed my global.F to global.f90, >>>>>> >>>>>> >>>>> Any perticular reason why you keep using .f90 suffix even though I've >>>>> recommended using .F90 suffix [for preprocessed free form] a few >>>>> times? >>>>> >>>>> >>>>> >>>>>> I was told that PETSC_COMM_SELF, PETSC_NULL_INTEGER and >>>>>> PETSC_NULL_CHARACTER does not have a type. >>>>>> >>>>>> >>>>> Please send a test code that demonstrates this problem. >>>>> >>>>> Satish >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > > > From balay at mcs.anl.gov Thu Aug 9 22:34:29 2007 From: balay at mcs.anl.gov (Satish Balay) Date: Thu, 9 Aug 2007 22:34:29 -0500 (CDT) Subject: Programming in *.f90 free format with PETSc In-Reply-To: <46BBB447.9030707@gmail.com> References: <46B6A4AC.4010308@gmail.com> <46B6D6C6.1090504@gmail.com> <804ab5d40708070126o3111c212gf3d386a7ee524a11@mail.gmail.com> <46BA5AAC.7020601@gmail.com> <46BAB80C.2030807@gmail.com> <46BACE5E.3090602@gmail.com> <46BBB447.9030707@gmail.com> Message-ID: On Fri, 10 Aug 2007, Ben Tay wrote: > The strange thing is when I try to compile on my windows's visual > fortran, it gives lots of error. The errors all point to mpif.h. Some errors > are: > > d:\cygwin\codes\MPICH\SDK\include\mpif.h(1) : Error: Syntax error, found > END-OF-STATEMENT when expecting one of: ( : % . = => > C > -^ > d:\cygwin\codes\MPICH\SDK\include\mpif.h(2) : Error: Syntax error, found > END-OF-STATEMENT when expecting one of: ( : % . = => > C > -^ > d:\cygwin\codes\MPICH\SDK\include\mpif.h(3) : Error: Syntax error, found > INTEGER_CONSTANT '1993' when expecting one of: ( % . = => > C (C) 1993 by Argonne National Laboratory and Mississipi State University. > -------^ Some f90/free-form compilers don't like 'C' for comments. They need '!' in the first columns. To fix this - you'll have to follow instructions from mpif.h >>>>>>>>> C It really is not possible to make a perfect include file that can C be used by both F77 and F90 compilers, but this is close. We have removed C continuation lines (allows free form input in F90); systems whose C Fortran compilers support ! instead of just C or * for comments can C globally replace a C in the first column with !; the resulting file C should work for both Fortran 77 and Fortran 90. C C If your Fortran compiler supports ! for comments, you can run this C through sed with C sed -e 's/^C/\!/g' <<<<<<<<<<<< Satish From zonexo at gmail.com Thu Aug 9 23:05:06 2007 From: zonexo at gmail.com (Ben Tay) Date: Fri, 10 Aug 2007 12:05:06 +0800 Subject: Programming in *.f90 free format with PETSc In-Reply-To: References: <46B6A4AC.4010308@gmail.com> <46B6D6C6.1090504@gmail.com> <804ab5d40708070126o3111c212gf3d386a7ee524a11@mail.gmail.com> <46BA5AAC.7020601@gmail.com> <46BAB80C.2030807@gmail.com> <46BACE5E.3090602@gmail.com> <46BBB447.9030707@gmail.com> Message-ID: <46BBE3F2.6010608@gmail.com> Thank you Satish. I followed what you recommended exactly and used sed -e 's/^C/\!/g' With the new mpif.h, I got the following error: global.i90 d:\cygwin\codes\MPICH\SDK\include\mpif.h(174) : Error: DEC$ ATTRIBUTES DLLIMPORT attribute can appear only in an interface-body. [MPIPRIV] !DEC$ ATTRIBUTES DLLIMPORT :: /MPIPRIV/ It points to this error in mpif.h ! Intel compiler import specification !MS$ATTRIBUTES DLLIMPORT :: /MPIPRIV/ ! Visual Fortran import specification !DEC$ ATTRIBUTES DLLIMPORT :: /MPIPRIV/ - in here COMMON /MPIPRIV/ MPI_BOTTOM,MPI_STATUS_IGNORE,MPI_STATUSES_IGNORE PARAMETER (MPI_MAX=100,MPI_MIN=101,MPI_SUM=102,MPI_PROD=103) PARAMETER (MPI_LAND=104,MPI_BAND=105,MPI_LOR=106,MPI_BOR=107) Hope you can help again. Thank you very much. Satish Balay wrote: > On Fri, 10 Aug 2007, Ben Tay wrote: > > >> The strange thing is when I try to compile on my windows's visual >> fortran, it gives lots of error. The errors all point to mpif.h. Some errors >> are: >> >> d:\cygwin\codes\MPICH\SDK\include\mpif.h(1) : Error: Syntax error, found >> END-OF-STATEMENT when expecting one of: ( : % . = => >> C >> -^ >> d:\cygwin\codes\MPICH\SDK\include\mpif.h(2) : Error: Syntax error, found >> END-OF-STATEMENT when expecting one of: ( : % . = => >> C >> -^ >> d:\cygwin\codes\MPICH\SDK\include\mpif.h(3) : Error: Syntax error, found >> INTEGER_CONSTANT '1993' when expecting one of: ( % . = => >> C (C) 1993 by Argonne National Laboratory and Mississipi State University. >> -------^ >> > > Some f90/free-form compilers don't like 'C' for comments. They need > '!' in the first columns. > > To fix this - you'll have to follow instructions from mpif.h > > > > C It really is not possible to make a perfect include file that can > C be used by both F77 and F90 compilers, but this is close. We have removed > C continuation lines (allows free form input in F90); systems whose > C Fortran compilers support ! instead of just C or * for comments can > C globally replace a C in the first column with !; the resulting file > C should work for both Fortran 77 and Fortran 90. > C > C If your Fortran compiler supports ! for comments, you can run this > C through sed with > C sed -e 's/^C/\!/g' > > <<<<<<<<<<<< > > Satish > > > From balay at mcs.anl.gov Fri Aug 10 00:24:28 2007 From: balay at mcs.anl.gov (Satish Balay) Date: Fri, 10 Aug 2007 00:24:28 -0500 (CDT) Subject: Programming in *.f90 free format with PETSc In-Reply-To: <46BBE3F2.6010608@gmail.com> References: <46B6A4AC.4010308@gmail.com> <46B6D6C6.1090504@gmail.com> <804ab5d40708070126o3111c212gf3d386a7ee524a11@mail.gmail.com> <46BA5AAC.7020601@gmail.com> <46BAB80C.2030807@gmail.com> <46BACE5E.3090602@gmail.com> <46BBB447.9030707@gmail.com> <46BBE3F2.6010608@gmail.com> Message-ID: Sorry - I don't know enough about these f90 intricacies with 'DEC$ ATTRIBUTES DLLIMPORT' Looks like you can't include mpif.h inside a module-subroutine. I'll have to check up on this tomorrow. Satish On Fri, 10 Aug 2007, Ben Tay wrote: > Thank you Satish. I followed what you recommended exactly and used > > sed -e 's/^C/\!/g' > > With the new mpif.h, I got the following error: > > global.i90 > d:\cygwin\codes\MPICH\SDK\include\mpif.h(174) : Error: DEC$ ATTRIBUTES > DLLIMPORT attribute can appear only in an interface-body. [MPIPRIV] > !DEC$ ATTRIBUTES DLLIMPORT :: /MPIPRIV/ > > It points to this error in mpif.h > > ! Intel compiler import specification > !MS$ATTRIBUTES DLLIMPORT :: /MPIPRIV/ > ! Visual Fortran import specification > !DEC$ ATTRIBUTES DLLIMPORT :: /MPIPRIV/ - in here > COMMON /MPIPRIV/ MPI_BOTTOM,MPI_STATUS_IGNORE,MPI_STATUSES_IGNORE > PARAMETER (MPI_MAX=100,MPI_MIN=101,MPI_SUM=102,MPI_PROD=103) > PARAMETER (MPI_LAND=104,MPI_BAND=105,MPI_LOR=106,MPI_BOR=107) > > Hope you can help again. Thank you very much. > > > Satish Balay wrote: > > On Fri, 10 Aug 2007, Ben Tay wrote: > > > > > > > The strange thing is when I try to compile on my windows's visual > > > fortran, it gives lots of error. The errors all point to mpif.h. Some > > > errors > > > are: > > > > > > d:\cygwin\codes\MPICH\SDK\include\mpif.h(1) : Error: Syntax error, found > > > END-OF-STATEMENT when expecting one of: ( : % . = => > > > C > > > -^ > > > d:\cygwin\codes\MPICH\SDK\include\mpif.h(2) : Error: Syntax error, found > > > END-OF-STATEMENT when expecting one of: ( : % . = => > > > C > > > -^ > > > d:\cygwin\codes\MPICH\SDK\include\mpif.h(3) : Error: Syntax error, found > > > INTEGER_CONSTANT '1993' when expecting one of: ( % . = => > > > C (C) 1993 by Argonne National Laboratory and Mississipi State > > > University. > > > -------^ > > > > > > > Some f90/free-form compilers don't like 'C' for comments. They need > > '!' in the first columns. > > > > To fix this - you'll have to follow instructions from mpif.h > > > > > > C It really is not possible to make a perfect include file that can > > C be used by both F77 and F90 compilers, but this is close. We have removed > > C continuation lines (allows free form input in F90); systems whose > > C Fortran compilers support ! instead of just C or * for comments can > > C globally replace a C in the first column with !; the resulting file > > C should work for both Fortran 77 and Fortran 90. > > C > > C If your Fortran compiler supports ! for comments, you can run this C > > through sed with > > C sed -e 's/^C/\!/g' > > > > <<<<<<<<<<<< > > > > Satish > > > > > > > > From balay at mcs.anl.gov Fri Aug 10 00:32:12 2007 From: balay at mcs.anl.gov (Satish Balay) Date: Fri, 10 Aug 2007 00:32:12 -0500 (CDT) Subject: Programming in *.f90 free format with PETSc In-Reply-To: References: <46B6A4AC.4010308@gmail.com> <46B6D6C6.1090504@gmail.com> <804ab5d40708070126o3111c212gf3d386a7ee524a11@mail.gmail.com> <46BA5AAC.7020601@gmail.com> <46BAB80C.2030807@gmail.com> <46BACE5E.3090602@gmail.com> <46BBB447.9030707@gmail.com> <46BBE3F2.6010608@gmail.com> Message-ID: For now, you can try the following alternative: remove the !MS and !DEC lines from mpif.h > > COMMON /MPIPRIV/ MPI_BOTTOM,MPI_STATUS_IGNORE,MPI_STATUSES_IGNORE I think this should be ok - as long as you don't use the above MPI flags in your code. Satish On Fri, 10 Aug 2007, Satish Balay wrote: > Sorry - I don't know enough about these f90 intricacies with > 'DEC$ ATTRIBUTES DLLIMPORT' > > Looks like you can't include mpif.h inside a module-subroutine. > > I'll have to check up on this tomorrow. > > Satish > > On Fri, 10 Aug 2007, Ben Tay wrote: > > > Thank you Satish. I followed what you recommended exactly and used > > > > sed -e 's/^C/\!/g' > > > > With the new mpif.h, I got the following error: > > > > global.i90 > > d:\cygwin\codes\MPICH\SDK\include\mpif.h(174) : Error: DEC$ ATTRIBUTES > > DLLIMPORT attribute can appear only in an interface-body. [MPIPRIV] > > !DEC$ ATTRIBUTES DLLIMPORT :: /MPIPRIV/ > > > > It points to this error in mpif.h > > > > ! Intel compiler import specification > > !MS$ATTRIBUTES DLLIMPORT :: /MPIPRIV/ > > ! Visual Fortran import specification > > !DEC$ ATTRIBUTES DLLIMPORT :: /MPIPRIV/ - in here > > COMMON /MPIPRIV/ MPI_BOTTOM,MPI_STATUS_IGNORE,MPI_STATUSES_IGNORE > > PARAMETER (MPI_MAX=100,MPI_MIN=101,MPI_SUM=102,MPI_PROD=103) > > PARAMETER (MPI_LAND=104,MPI_BAND=105,MPI_LOR=106,MPI_BOR=107) > > > > Hope you can help again. Thank you very much. > > > > > > Satish Balay wrote: > > > On Fri, 10 Aug 2007, Ben Tay wrote: > > > > > > > > > > The strange thing is when I try to compile on my windows's visual > > > > fortran, it gives lots of error. The errors all point to mpif.h. Some > > > > errors > > > > are: > > > > > > > > d:\cygwin\codes\MPICH\SDK\include\mpif.h(1) : Error: Syntax error, found > > > > END-OF-STATEMENT when expecting one of: ( : % . = => > > > > C > > > > -^ > > > > d:\cygwin\codes\MPICH\SDK\include\mpif.h(2) : Error: Syntax error, found > > > > END-OF-STATEMENT when expecting one of: ( : % . = => > > > > C > > > > -^ > > > > d:\cygwin\codes\MPICH\SDK\include\mpif.h(3) : Error: Syntax error, found > > > > INTEGER_CONSTANT '1993' when expecting one of: ( % . = => > > > > C (C) 1993 by Argonne National Laboratory and Mississipi State > > > > University. > > > > -------^ > > > > > > > > > > Some f90/free-form compilers don't like 'C' for comments. They need > > > '!' in the first columns. > > > > > > To fix this - you'll have to follow instructions from mpif.h > > > > > > > > > C It really is not possible to make a perfect include file that can > > > C be used by both F77 and F90 compilers, but this is close. We have removed > > > C continuation lines (allows free form input in F90); systems whose > > > C Fortran compilers support ! instead of just C or * for comments can > > > C globally replace a C in the first column with !; the resulting file > > > C should work for both Fortran 77 and Fortran 90. > > > C > > > C If your Fortran compiler supports ! for comments, you can run this C > > > through sed with > > > C sed -e 's/^C/\!/g' > > > > > > <<<<<<<<<<<< > > > > > > Satish > > > > > > > > > > > > > > > From zonexo at gmail.com Fri Aug 10 01:46:45 2007 From: zonexo at gmail.com (Ben Tay) Date: Fri, 10 Aug 2007 14:46:45 +0800 Subject: Programming in *.f90 free format with PETSc In-Reply-To: References: <46B6A4AC.4010308@gmail.com> <46B6D6C6.1090504@gmail.com> <804ab5d40708070126o3111c212gf3d386a7ee524a11@mail.gmail.com> <46BA5AAC.7020601@gmail.com> <46BAB80C.2030807@gmail.com> <46BACE5E.3090602@gmail.com> <46BBB447.9030707@gmail.com> <46BBE3F2.6010608@gmail.com> Message-ID: <46BC09D5.9070001@gmail.com> Thanks Satish. It worked. Satish Balay wrote: > For now, you can try the following alternative: remove the !MS and > !DEC lines from mpif.h > > >>> COMMON /MPIPRIV/ MPI_BOTTOM,MPI_STATUS_IGNORE,MPI_STATUSES_IGNORE >>> > > I think this should be ok - as long as you don't use the above MPI > flags in your code. > > Satish > > On Fri, 10 Aug 2007, Satish Balay wrote: > > >> Sorry - I don't know enough about these f90 intricacies with >> 'DEC$ ATTRIBUTES DLLIMPORT' >> >> Looks like you can't include mpif.h inside a module-subroutine. >> >> I'll have to check up on this tomorrow. >> >> Satish >> >> On Fri, 10 Aug 2007, Ben Tay wrote: >> >> >>> Thank you Satish. I followed what you recommended exactly and used >>> >>> sed -e 's/^C/\!/g' >>> >>> With the new mpif.h, I got the following error: >>> >>> global.i90 >>> d:\cygwin\codes\MPICH\SDK\include\mpif.h(174) : Error: DEC$ ATTRIBUTES >>> DLLIMPORT attribute can appear only in an interface-body. [MPIPRIV] >>> !DEC$ ATTRIBUTES DLLIMPORT :: /MPIPRIV/ >>> >>> It points to this error in mpif.h >>> >>> ! Intel compiler import specification >>> !MS$ATTRIBUTES DLLIMPORT :: /MPIPRIV/ >>> ! Visual Fortran import specification >>> !DEC$ ATTRIBUTES DLLIMPORT :: /MPIPRIV/ - in here >>> COMMON /MPIPRIV/ MPI_BOTTOM,MPI_STATUS_IGNORE,MPI_STATUSES_IGNORE >>> PARAMETER (MPI_MAX=100,MPI_MIN=101,MPI_SUM=102,MPI_PROD=103) >>> PARAMETER (MPI_LAND=104,MPI_BAND=105,MPI_LOR=106,MPI_BOR=107) >>> >>> Hope you can help again. Thank you very much. >>> >>> >>> Satish Balay wrote: >>> >>>> On Fri, 10 Aug 2007, Ben Tay wrote: >>>> >>>> >>>> >>>>> The strange thing is when I try to compile on my windows's visual >>>>> fortran, it gives lots of error. The errors all point to mpif.h. Some >>>>> errors >>>>> are: >>>>> >>>>> d:\cygwin\codes\MPICH\SDK\include\mpif.h(1) : Error: Syntax error, found >>>>> END-OF-STATEMENT when expecting one of: ( : % . = => >>>>> C >>>>> -^ >>>>> d:\cygwin\codes\MPICH\SDK\include\mpif.h(2) : Error: Syntax error, found >>>>> END-OF-STATEMENT when expecting one of: ( : % . = => >>>>> C >>>>> -^ >>>>> d:\cygwin\codes\MPICH\SDK\include\mpif.h(3) : Error: Syntax error, found >>>>> INTEGER_CONSTANT '1993' when expecting one of: ( % . = => >>>>> C (C) 1993 by Argonne National Laboratory and Mississipi State >>>>> University. >>>>> -------^ >>>>> >>>>> >>>> Some f90/free-form compilers don't like 'C' for comments. They need >>>> '!' in the first columns. >>>> >>>> To fix this - you'll have to follow instructions from mpif.h >>>> >>>> >>>> C It really is not possible to make a perfect include file that can >>>> C be used by both F77 and F90 compilers, but this is close. We have removed >>>> C continuation lines (allows free form input in F90); systems whose >>>> C Fortran compilers support ! instead of just C or * for comments can >>>> C globally replace a C in the first column with !; the resulting file >>>> C should work for both Fortran 77 and Fortran 90. >>>> C >>>> C If your Fortran compiler supports ! for comments, you can run this C >>>> through sed with >>>> C sed -e 's/^C/\!/g' >>>> >>>> <<<<<<<<<<<< >>>> >>>> Satish >>>> >>>> >>>> >>>> >>> >> > > > From jwicks at cs.brown.edu Fri Aug 10 05:40:46 2007 From: jwicks at cs.brown.edu (John R. Wicks) Date: Fri, 10 Aug 2007 06:40:46 -0400 Subject: Bug in documentation for SETERRQ In-Reply-To: <000001c7da94$354381a0$7900000a@jwickslptp> Message-ID: <000b01c7db3a$e9664bd0$6401a8c0@jwickslptp> SETERRQ is documented to not return a value: Synopsis: void SETERRQ(PetscErrorCode errorcode,char *message) but it is defined in petscerror.h in terms of a return statement: #define SETERRQ(n,s) {return PetscError(__LINE__,__FUNCT__,__FILE__,__SDIR__,n,1,s);} which causes a compilation error when it is called in a C++ constructor/destructor, for example. A truly void error check, such as: #define ckPetscErr(n, s) {if(0!=n) PetscError(__LINE__,__FUNCT__,__FILE__,__SDIR__,n,1,s);} or: #define ckPetscErr(stmnt, s) {PetscErrorCode ierr=stmnt;if(0!=ierr) PetscError(__LINE__,__FUNCT__,__FILE__,__SDIR__,ierr,1,s);} would be helpful. From knepley at gmail.com Fri Aug 10 17:46:59 2007 From: knepley at gmail.com (Matthew Knepley) Date: Fri, 10 Aug 2007 17:46:59 -0500 Subject: Bug in documentation for SETERRQ In-Reply-To: <000b01c7db3a$e9664bd0$6401a8c0@jwickslptp> References: <000001c7da94$354381a0$7900000a@jwickslptp> <000b01c7db3a$e9664bd0$6401a8c0@jwickslptp> Message-ID: On 8/10/07, John R. Wicks wrote: > SETERRQ is documented to not return a value: > Synopsis: > void SETERRQ(PetscErrorCode errorcode,char *message) I have corrected this documentation. > but it is defined in petscerror.h in terms of a return statement: > > #define SETERRQ(n,s) {return > PetscError(__LINE__,__FUNCT__,__FILE__,__SDIR__,n,1,s);} > > which causes a compilation error when it is called in a C++ > constructor/destructor, for example. > > A truly void error check, such as: This does not make sense, unfortunately. SETERRQ is a C exception and thus returns as a matter of definition. Thanks, Matt > #define ckPetscErr(n, s) {if(0!=n) > PetscError(__LINE__,__FUNCT__,__FILE__,__SDIR__,n,1,s);} > > or: > > #define ckPetscErr(stmnt, s) {PetscErrorCode ierr=stmnt;if(0!=ierr) > PetscError(__LINE__,__FUNCT__,__FILE__,__SDIR__,ierr,1,s);} > > would be helpful. > > -- 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 From bsmith at mcs.anl.gov Sat Aug 11 18:01:33 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Sat, 11 Aug 2007 18:01:33 -0500 (CDT) Subject: Bug in documentation for SETERRQ In-Reply-To: References: <000001c7da94$354381a0$7900000a@jwickslptp> <000b01c7db3a$e9664bd0$6401a8c0@jwickslptp> Message-ID: You can use SETERRA(); this is not a great solution but since it needs to call MPI_Abort(). You could also check error codes directly and trigger the appropriate C++ exception. Barry On Fri, 10 Aug 2007, Matthew Knepley wrote: > On 8/10/07, John R. Wicks wrote: > > SETERRQ is documented to not return a value: > > Synopsis: > > void SETERRQ(PetscErrorCode errorcode,char *message) > > I have corrected this documentation. > > > but it is defined in petscerror.h in terms of a return statement: > > > > #define SETERRQ(n,s) {return > > PetscError(__LINE__,__FUNCT__,__FILE__,__SDIR__,n,1,s);} > > > > which causes a compilation error when it is called in a C++ > > constructor/destructor, for example. > > > > A truly void error check, such as: > > This does not make sense, unfortunately. SETERRQ is a C exception > and thus returns as a matter of definition. > > Thanks, > > Matt > > > #define ckPetscErr(n, s) {if(0!=n) > > PetscError(__LINE__,__FUNCT__,__FILE__,__SDIR__,n,1,s);} > > > > or: > > > > #define ckPetscErr(stmnt, s) {PetscErrorCode ierr=stmnt;if(0!=ierr) > > PetscError(__LINE__,__FUNCT__,__FILE__,__SDIR__,ierr,1,s);} > > > > would be helpful. > > > > > > > From liangcanada at gmail.com Sun Aug 12 16:46:33 2007 From: liangcanada at gmail.com (Zhu Liang) Date: Mon, 13 Aug 2007 05:46:33 +0800 Subject: How can I use BICGStab on a matrix with zero entries on the diagonal Message-ID: <440307c0708121446j4b6458ddnd43f313b1d5ac2b9@mail.gmail.com> Dear petsc-users When I try to solve a linear equation Ax=b with BicgStab preconditioner, I got an error "Matrix is missing diagonal number". That is because I have zeros on the diagonal of the matrix. I am wondering if there is some simple method to avoid that? Best, Liang -------------- next part -------------- An HTML attachment was scrubbed... URL: From liangcanada at gmail.com Sun Aug 12 16:50:58 2007 From: liangcanada at gmail.com (Zhu Liang) Date: Mon, 13 Aug 2007 05:50:58 +0800 Subject: How can I use BICGStab on a matrix with zero entries on the diagonal In-Reply-To: <440307c0708121446j4b6458ddnd43f313b1d5ac2b9@mail.gmail.com> References: <440307c0708121446j4b6458ddnd43f313b1d5ac2b9@mail.gmail.com> Message-ID: <440307c0708121450s1f004807xce34cf21396c2a4f@mail.gmail.com> By the way, the block of my matrix is like : U , a A^T , 0 ---------- Forwarded message ---------- From: Zhu Liang Date: Aug 13, 2007 5:46 AM Subject: How can I use BICGStab on a matrix with zero entries on the diagonal To: petsc-users at mcs.anl.gov Dear petsc-users When I try to solve a linear equation Ax=b with BicgStab preconditioner, I got an error "Matrix is missing diagonal number". That is because I have zeros on the diagonal of the matrix. I am wondering if there is some simple method to avoid that? Best, Liang -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwicks at cs.brown.edu Sun Aug 12 18:57:26 2007 From: jwicks at cs.brown.edu (John R. Wicks) Date: Sun, 12 Aug 2007 19:57:26 -0400 Subject: Adding/subtracting vectors In-Reply-To: <440307c0708121450s1f004807xce34cf21396c2a4f@mail.gmail.com> Message-ID: <000701c7dd3c$899a3730$6401a8c0@jwickslptp> It seems that the only way to add two vectors is to use VecAXPY(x,1,y); likewise, to subtract one must call VecAXPY(x,-1,y). Are these routines optimized to recognize these special cases to avoid the extraneous scalar multiplications? From zonexo at gmail.com Sun Aug 12 19:04:29 2007 From: zonexo at gmail.com (Ben Tay) Date: Mon, 13 Aug 2007 08:04:29 +0800 Subject: Comparing between a PETSc matrix and a standard fortran array in compressed row format In-Reply-To: References: <46B2ADEF.4050806@gmail.com> <46B3EFBF.5070909@gmail.com> <46B43912.2050509@gmail.com> <46B5286F.5040002@gmail.com> <46B536DC.4000400@gmail.com> <46B673A5.7020206@gmail.com> Message-ID: <46BFA00D.8070103@gmail.com> Hi, I have installed the latest ver of PETSc to make sure it's not due to any bug. I only read in the matrix into PETSc just before the eqn is to be solved. Another way which I've done is to convert the matrix to a CSR format (verified to be correct) and use MatCreateSeqAIJWithArrays to read in the matrix. Unfortunately, the answer is still the same. Is there any other recommendation? Thanks Matthew Knepley wrote: > If > > 1) The matrix and rhs are identical > > 2) The matrix is nonsingular > > then the solution will be identical. Thus, the code has a bug somewhere. > I suggest > > 1) Read in the other matrix and rhs > > 2) Compare both matrices and rhs > > 3) Solve both systems > > 4) Check that the answer match > > Matt > > On 8/5/07, Ben Tay wrote: > >> Well, here's what I got: >> >> 0 KSP preconditioned resid norm 1.498836640002e+04 true resid norm >> 1.531062859147e+03 ||Ae||/||Ax|| 9.947622397959e-01 >> 1 KSP preconditioned resid norm 4.832736106865e-08 true resid norm >> 2.037181386899e-09 ||Ae||/||Ax|| 1.323597595746e-12 >> >> Looks like everything's ok.... right? >> >> Any other suggestion? >> >> Thanks. >> >> Barry Smith wrote: >> >>> Run with -ksp_type gmres -pc_type lu -ksp_monitor_true_residual -ksp_truemonitor >>> >>> At the bad iteration verify if the true residual is very small. >>> >>> Barry >>> >>> >>> On Sun, 5 Aug 2007, Ben Tay wrote: >>> >>> >>> >>>> Well, ya, they're the same ... that's why I don't know what's wrong. Is there >>>> any way to check on singularity? The iteration no. is only 8 for AMG and LU >>>> direct solver works. .. >>>> >>>> >>>> Thanks >>>> >>>> Barry Smith wrote: >>>> >>>> >>>>> At the "bad step" are the two matrices and right hand sides the same? >>>>> The the resulting solution vectors are different (a lot)? Is there any >>>>> reason to think the matrix is (nearly) singular at that point? >>>>> >>>>> Barry >>>>> >>>>> >>>>> >>>>> On Sun, 5 Aug 2007, Ben Tay wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> Now I'm comparing at every time step. The A matrix and rhs of the NSPCG >>>>>> and >>>>>> PETSc matrix are exactly the same, NORM is zero. The solutions given by >>>>>> both >>>>>> solvers are very similar for e.g. from 1-315 time step, and varying slowly >>>>>> since it is a oscillating body problem. Then strangely, at time=316, >>>>>> PETSc's >>>>>> answer suddenly differs by a great difference. e.g. p=0.3 to 50. I must >>>>>> also >>>>>> add that the flowfield at that time step still "looks ok". However, the >>>>>> large >>>>>> pressure change of the pressure poisson eqn caused the computation of the >>>>>> lift/drag coefficient to be erroneous. Moreover, after that, the pressure >>>>>> slowly "returns back" to the same answer such that of the NSPCG solver >>>>>> after a >>>>>> few time steps ... then after a while the sudden change happens again. In >>>>>> the >>>>>> end, I got a cl/cd vs time graph with lots of spikes. >>>>>> >>>>>> I hope that the thing can be solved because the NSPCG solver is much >>>>>> slower >>>>>> and it is not as stable. >>>>>> >>>>>> Thanks >>>>>> >>>>>> Barry Smith wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Ben, >>>>>>> >>>>>>> Are you comparing the two matrices at timestep 316? Also compare the >>>>>>> two right hand sides at 316. Are they similar, totally different?? >>>>>>> >>>>>>> Barry >>>>>>> >>>>>>> >>>>>>> On Sat, 4 Aug 2007, Ben Tay wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> After using MatAXPY, I used MatGetRowMaxAbs, VecAb and VecMax to get >>>>>>>> the >>>>>>>> row >>>>>>>> with max value, get the absolute of that value and print out the >>>>>>>> location/value. I managed to find some minor mistakes and corrected >>>>>>>> them >>>>>>>> so >>>>>>>> that the 2 matrix are identical. Unfortunately, the same thing still >>>>>>>> happens! >>>>>>>> >>>>>>>> I've checked for convergence and the iteration no. is 1 and 8 for >>>>>>>> direct >>>>>>>> solving and HYPRE's AMG respectively. So there's no convergence >>>>>>>> problem. >>>>>>>> I've >>>>>>>> also tried to change to the same pc/ksp as that of NSPCG, which is >>>>>>>> jacobi >>>>>>>> presconditioning + KSPBCGS but the same thing happens. >>>>>>>> >>>>>>>> Any idea what's happening? >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Barry Smith wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Unless the matrix values are huge then this is a big difference. >>>>>>>>> All >>>>>>>>> you >>>>>>>>> can do is print the difference matrix with ASCII MatView and >>>>>>>>> look for large entries. This will tell you the locations of the >>>>>>>>> trouble >>>>>>>>> entries. >>>>>>>>> >>>>>>>>> Barry >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sat, 4 Aug 2007, Ben Tay wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I realised that the matrix storage format of NSPCG is actually >>>>>>>>>> ITPACK >>>>>>>>>> storage >>>>>>>>>> format. Anyway, I tried to insert the values into a PETSc matrix, >>>>>>>>>> use >>>>>>>>>> MatAXPY >>>>>>>>>> with the scalar a = -1 and then use MatNorm on the output matrix. >>>>>>>>>> >>>>>>>>>> Using NORM_1, NORM_FROBENIUS and NORM_INFINITY >>>>>>>>>> <../Vec/NORM_FROBENIUS.html#NORM_FROBENIUS>, I got ~543, 3194 and >>>>>>>>>> 556 >>>>>>>>>> respectively. Does this mean that the matrix are different? How >>>>>>>>>> "much" >>>>>>>>>> different does that means? >>>>>>>>>> >>>>>>>>>> So what is the next step? Is there anyway to find out the location >>>>>>>>>> of >>>>>>>>>> the >>>>>>>>>> value which is different? >>>>>>>>>> >>>>>>>>>> This is my comparison subroutine: >>>>>>>>>> >>>>>>>>>> subroutine matrix_compare >>>>>>>>>> >>>>>>>>>> !compare big_A & PETSc matrix >>>>>>>>>> >>>>>>>>>> integer :: k,kk,II,JJ,ierr >>>>>>>>>> >>>>>>>>>> Vec xx_test,b_rhs_test >>>>>>>>>> Mat A_mat_test >>>>>>>>>> >>>>>>>>>> PetscScalar aa >>>>>>>>>> >>>>>>>>>> PetscReal nrm >>>>>>>>>> >>>>>>>>>> aa=-1. >>>>>>>>>> >>>>>>>>>> call >>>>>>>>>> MatCreateSeqAIJ(PETSC_COMM_SELF,total_k,total_k,10,PETSC_NULL_INTEGER,A_mat_test,ierr) >>>>>>>>>> >>>>>>>>>> call VecCreateSeq(PETSC_COMM_SELF,total_k,b_rhs_test,ierr) >>>>>>>>>> >>>>>>>>>> call VecDuplicate(b_rhs_test,xx_test,ierr) >>>>>>>>>> >>>>>>>>>> call VecAssemblyBegin(b_rhs_test,ierr) >>>>>>>>>> >>>>>>>>>> call VecAssemblyEnd(b_rhs_test,ierr) >>>>>>>>>> >>>>>>>>>> call VecAssemblyBegin(xx_test,ierr) >>>>>>>>>> >>>>>>>>>> call VecAssemblyEnd(xx_test,ierr) >>>>>>>>>> >>>>>>>>>> do k=1,total_k >>>>>>>>>> do kk=1,10 >>>>>>>>>> >>>>>>>>>> II=k-1 >>>>>>>>>> >>>>>>>>>> JJ=int_A(k,kk)-1 >>>>>>>>>> call >>>>>>>>>> MatSetValues(A_mat_test,1,II,1,JJ,big_A(k,kk),INSERT_VALUES,ierr) >>>>>>>>>> call VecSetValue(b_rhs_test,II,q_p(k),INSERT_VALUES,ierr) >>>>>>>>>> end do >>>>>>>>>> >>>>>>>>>> end do >>>>>>>>>> >>>>>>>>>> ! call MatCopy(A_mat,A_mat_test,DIFFERENT_NONZERO_PATTERN >>>>>>>>>> ,ierr) >>>>>>>>>> >>>>>>>>>> call MatAssemblyBegin(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) >>>>>>>>>> call MatAssemblyEnd(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) >>>>>>>>>> >>>>>>>>>> call MatAXPY(A_mat_test,aa,A_mat,SAME_NONZERO_PATTERN,ierr) >>>>>>>>>> >>>>>>>>>> call MatNorm(A_mat_test,NORM_INFINITY,nrm,ierr) >>>>>>>>>> >>>>>>>>>> print *, nrm >>>>>>>>>> >>>>>>>>>> end subroutine matrix_compare >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Barry Smith wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> You can use MatCreateSeqAIJWithArrays() to "convert" the NSPCG >>>>>>>>>>> matrix >>>>>>>>>>> into >>>>>>>>>>> PETSc format and then MatAXPY() to difference them and then >>>>>>>>>>> MatNorm() to >>>>>>>>>>> see >>>>>>>>>>> how large the result is. Make sure the PETSc or hypre solver >>>>>>>>>>> is >>>>>>>>>>> always >>>>>>>>>>> converging. Run with >>>>>>>>>>> -ksp_converged_reason and or -ksp_monitor. My guess is that the >>>>>>>>>>> matrix >>>>>>>>>>> is >>>>>>>>>>> becoming very ill-conditioned so the solvers with the default >>>>>>>>>>> options >>>>>>>>>>> are >>>>>>>>>>> failing. >>>>>>>>>>> >>>>>>>>>>> Barry >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Fri, 3 Aug 2007, Ben Tay wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I used 2 packages to solve my poisson eqn, which is part of my >>>>>>>>>>>> NS >>>>>>>>>>>> unsteady >>>>>>>>>>>> solver. One is the NSPCG solver package which uses the >>>>>>>>>>>> compressed >>>>>>>>>>>> row >>>>>>>>>>>> format >>>>>>>>>>>> to store the A matrix. The other is PETSc. I found that using >>>>>>>>>>>> both >>>>>>>>>>>> solvers >>>>>>>>>>>> gave me similar answers for a number of time step. However, >>>>>>>>>>>> after >>>>>>>>>>>> that, >>>>>>>>>>>> the >>>>>>>>>>>> answer will suddenly change drastically for the PETSc case. >>>>>>>>>>>> This >>>>>>>>>>>> does >>>>>>>>>>>> not >>>>>>>>>>>> happen for the NSPCG solver. >>>>>>>>>>>> >>>>>>>>>>>> For e.g. time step 1-315, oscillating airfoil case, pressure >>>>>>>>>>>> changes >>>>>>>>>>>> smoothly, >>>>>>>>>>>> similar answers in both cases >>>>>>>>>>>> >>>>>>>>>>>> at time=316, pressure changes from -3.22 to -3.2 for NSPCG, >>>>>>>>>>>> but >>>>>>>>>>>> pressure >>>>>>>>>>>> changes from -3.21 to -60.2 for PETSc >>>>>>>>>>>> >>>>>>>>>>>> This happens when I use HYPRE's AMG or PETSc's direct solver >>>>>>>>>>>> LU. >>>>>>>>>>>> >>>>>>>>>>>> I have been trying to find out what's the cause and I can't >>>>>>>>>>>> find >>>>>>>>>>>> the >>>>>>>>>>>> answer in >>>>>>>>>>>> debugging. I would like to compare the values of the matrix of >>>>>>>>>>>> the >>>>>>>>>>>> 2 >>>>>>>>>>>> different >>>>>>>>>>>> solvers and see if there's any difference. However, NSPCG's >>>>>>>>>>>> matrix >>>>>>>>>>>> is >>>>>>>>>>>> in >>>>>>>>>>>> compressed row format while PETSc's one is just an address and >>>>>>>>>>>> it >>>>>>>>>>>> can't be >>>>>>>>>>>> viewed easily. Moreover, it's a big matrix so it's not >>>>>>>>>>>> possible to >>>>>>>>>>>> check >>>>>>>>>>>> by >>>>>>>>>>>> inspection. I'm thinking of subtracting one matrix by the >>>>>>>>>>>> other >>>>>>>>>>>> and >>>>>>>>>>>> find >>>>>>>>>>>> if >>>>>>>>>>>> it's zero. What's the best way to solve this problem? Btw, I'm >>>>>>>>>>>> using >>>>>>>>>>>> fortran >>>>>>>>>>>> and there's no mpi >>>>>>>>>>>> >>>>>>>>>>>> Thank you. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >>> >> > > > From bsmith at mcs.anl.gov Sun Aug 12 21:06:59 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Sun, 12 Aug 2007 21:06:59 -0500 (CDT) Subject: Adding/subtracting vectors In-Reply-To: <000701c7dd3c$899a3730$6401a8c0@jwickslptp> References: <000701c7dd3c$899a3730$6401a8c0@jwickslptp> Message-ID: It checks for the 0 case. Otherwise it passes the operation directly onto BLAS and assumes that BLAS handles the special cases efficiently. Barry Here's the thing. Even if the BLAS implementation provided by the vector did not handle the special cases if we wrote a do/for loop directly to handle the special case it may still not be faster than then the BLAs since the BLAS may be tuned much better then the code the compiler can generate, plus the cost of AXPY is essentially the cost of the loads and stores not the multiply adds, eliminating the multiplies might not save you much. On Sun, 12 Aug 2007, John R. Wicks wrote: > It seems that the only way to add two vectors is to use VecAXPY(x,1,y); > likewise, to subtract one must call VecAXPY(x,-1,y). Are these routines > optimized to recognize these special cases to avoid the extraneous scalar > multiplications? > > From bsmith at mcs.anl.gov Sun Aug 12 21:09:16 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Sun, 12 Aug 2007 21:09:16 -0500 (CDT) Subject: How can I use BICGStab on a matrix with zero entries on the diagonal In-Reply-To: <440307c0708121450s1f004807xce34cf21396c2a4f@mail.gmail.com> References: <440307c0708121446j4b6458ddnd43f313b1d5ac2b9@mail.gmail.com> <440307c0708121450s1f004807xce34cf21396c2a4f@mail.gmail.com> Message-ID: It is not really the BiCGstab Krylov solver that it complaining; it is the default ILU or block Jacobi with ILU on the blocks that is complaining. You first need to make sure you insert 0 entries on the all the diagonal entries that are 0. BUT given the structure of your matrix you may want to think about solvers that specifically handle that type of matrix. Barry Stokes type solvers? On Mon, 13 Aug 2007, Zhu Liang wrote: > By the way, the block of my matrix is like : > > U , a > A^T , 0 > > > > ---------- Forwarded message ---------- > From: Zhu Liang > Date: Aug 13, 2007 5:46 AM > Subject: How can I use BICGStab on a matrix with zero entries on the > diagonal > To: petsc-users at mcs.anl.gov > > > Dear petsc-users > > When I try to solve a linear equation Ax=b with BicgStab preconditioner, I > got > an error "Matrix is missing diagonal number". That is because I have zeros > on > the diagonal of the matrix. > > I am wondering if there is some simple method to avoid that? > > Best, > Liang > From bsmith at mcs.anl.gov Sun Aug 12 21:12:50 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Sun, 12 Aug 2007 21:12:50 -0500 (CDT) Subject: Comparing between a PETSc matrix and a standard fortran array in compressed row format In-Reply-To: <46BFA00D.8070103@gmail.com> References: <46B2ADEF.4050806@gmail.com> <46B3EFBF.5070909@gmail.com> <46B43912.2050509@gmail.com> <46B5286F.5040002@gmail.com> <46B536DC.4000400@gmail.com> <46B673A5.7020206@gmail.com> <46BFA00D.8070103@gmail.com> Message-ID: On Mon, 13 Aug 2007, Ben Tay wrote: > Hi, > > I have installed the latest ver of PETSc to make sure it's not due to any bug. > I only read in the matrix into PETSc just before the eqn is to be solved. > Another way which I've done is to convert the matrix to a CSR format (verified > to be correct) and use MatCreateSeqAIJWithArrays to read in the matrix. > Unfortunately, the answer is still the same. Is there any other > recommendation? Ben, Are you running with -info and looking at what the line search does? (Are you using SNES?) does the line search fail? You'll need to see what NSPC does at this point. *) same rhs *) same matrix *) same solution (?) to some good number of digits NOW what does NSPCG do to update the Newton step and how and why is that update different then what PETSC does? Barry > > Thanks > > Matthew Knepley wrote: > > If > > > > 1) The matrix and rhs are identical > > > > 2) The matrix is nonsingular > > > > then the solution will be identical. Thus, the code has a bug somewhere. > > I suggest > > > > 1) Read in the other matrix and rhs > > > > 2) Compare both matrices and rhs > > > > 3) Solve both systems > > > > 4) Check that the answer match > > > > Matt > > > > On 8/5/07, Ben Tay wrote: > > > > > Well, here's what I got: > > > > > > 0 KSP preconditioned resid norm 1.498836640002e+04 true resid norm > > > 1.531062859147e+03 ||Ae||/||Ax|| 9.947622397959e-01 > > > 1 KSP preconditioned resid norm 4.832736106865e-08 true resid norm > > > 2.037181386899e-09 ||Ae||/||Ax|| 1.323597595746e-12 > > > > > > Looks like everything's ok.... right? > > > > > > Any other suggestion? > > > > > > Thanks. > > > > > > Barry Smith wrote: > > > > > > > Run with -ksp_type gmres -pc_type lu -ksp_monitor_true_residual > > > > -ksp_truemonitor > > > > > > > > At the bad iteration verify if the true residual is very small. > > > > > > > > Barry > > > > > > > > > > > > On Sun, 5 Aug 2007, Ben Tay wrote: > > > > > > > > > > > > > > > > > Well, ya, they're the same ... that's why I don't know what's wrong. > > > > > Is there > > > > > any way to check on singularity? The iteration no. is only 8 for AMG > > > > > and LU > > > > > direct solver works. .. > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Barry Smith wrote: > > > > > > > > > > > > > > > > At the "bad step" are the two matrices and right hand sides the > > > > > > same? > > > > > > The the resulting solution vectors are different (a lot)? Is there > > > > > > any > > > > > > reason to think the matrix is (nearly) singular at that point? > > > > > > > > > > > > Barry > > > > > > > > > > > > > > > > > > > > > > > > On Sun, 5 Aug 2007, Ben Tay wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > Now I'm comparing at every time step. The A matrix and rhs of the > > > > > > > NSPCG > > > > > > > and > > > > > > > PETSc matrix are exactly the same, NORM is zero. The solutions > > > > > > > given by > > > > > > > both > > > > > > > solvers are very similar for e.g. from 1-315 time step, and > > > > > > > varying slowly > > > > > > > since it is a oscillating body problem. Then strangely, at > > > > > > > time=316, > > > > > > > PETSc's > > > > > > > answer suddenly differs by a great difference. e.g. p=0.3 to 50. I > > > > > > > must > > > > > > > also > > > > > > > add that the flowfield at that time step still "looks ok". > > > > > > > However, the > > > > > > > large > > > > > > > pressure change of the pressure poisson eqn caused the computation > > > > > > > of the > > > > > > > lift/drag coefficient to be erroneous. Moreover, after that, the > > > > > > > pressure > > > > > > > slowly "returns back" to the same answer such that of the NSPCG > > > > > > > solver > > > > > > > after a > > > > > > > few time steps ... then after a while the sudden change happens > > > > > > > again. In > > > > > > > the > > > > > > > end, I got a cl/cd vs time graph with lots of spikes. > > > > > > > > > > > > > > I hope that the thing can be solved because the NSPCG solver is > > > > > > > much > > > > > > > slower > > > > > > > and it is not as stable. > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > Barry Smith wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ben, > > > > > > > > > > > > > > > > Are you comparing the two matrices at timestep 316? Also > > > > > > > > compare the > > > > > > > > two right hand sides at 316. Are they similar, totally > > > > > > > > different?? > > > > > > > > > > > > > > > > Barry > > > > > > > > > > > > > > > > > > > > > > > > On Sat, 4 Aug 2007, Ben Tay wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > After using MatAXPY, I used MatGetRowMaxAbs, VecAb and VecMax > > > > > > > > > to get > > > > > > > > > the > > > > > > > > > row > > > > > > > > > with max value, get the absolute of that value and print out > > > > > > > > > the > > > > > > > > > location/value. I managed to find some minor mistakes and > > > > > > > > > corrected > > > > > > > > > them > > > > > > > > > so > > > > > > > > > that the 2 matrix are identical. Unfortunately, the same thing > > > > > > > > > still > > > > > > > > > happens! > > > > > > > > > > > > > > > > > > I've checked for convergence and the iteration no. is 1 and 8 > > > > > > > > > for > > > > > > > > > direct > > > > > > > > > solving and HYPRE's AMG respectively. So there's no > > > > > > > > > convergence > > > > > > > > > problem. > > > > > > > > > I've > > > > > > > > > also tried to change to the same pc/ksp as that of NSPCG, > > > > > > > > > which is > > > > > > > > > jacobi > > > > > > > > > presconditioning + KSPBCGS but the same thing happens. > > > > > > > > > > > > > > > > > > Any idea what's happening? > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > Barry Smith wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Unless the matrix values are huge then this is a big > > > > > > > > > > difference. > > > > > > > > > > All > > > > > > > > > > you > > > > > > > > > > can do is print the difference matrix with ASCII MatView and > > > > > > > > > > look for large entries. This will tell you the locations of > > > > > > > > > > the > > > > > > > > > > trouble > > > > > > > > > > entries. > > > > > > > > > > > > > > > > > > > > Barry > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sat, 4 Aug 2007, Ben Tay wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > I realised that the matrix storage format of NSPCG is > > > > > > > > > > > actually > > > > > > > > > > > ITPACK > > > > > > > > > > > storage > > > > > > > > > > > format. Anyway, I tried to insert the values into a PETSc > > > > > > > > > > > matrix, > > > > > > > > > > > use > > > > > > > > > > > MatAXPY > > > > > > > > > > > with the scalar a = -1 and then use MatNorm on the output > > > > > > > > > > > matrix. > > > > > > > > > > > > > > > > > > > > > > Using NORM_1, NORM_FROBENIUS and NORM_INFINITY > > > > > > > > > > > <../Vec/NORM_FROBENIUS.html#NORM_FROBENIUS>, I got ~543, > > > > > > > > > > > 3194 and > > > > > > > > > > > 556 > > > > > > > > > > > respectively. Does this mean that the matrix are > > > > > > > > > > > different? How > > > > > > > > > > > "much" > > > > > > > > > > > different does that means? > > > > > > > > > > > > > > > > > > > > > > So what is the next step? Is there anyway to find out the > > > > > > > > > > > location > > > > > > > > > > > of > > > > > > > > > > > the > > > > > > > > > > > value which is different? > > > > > > > > > > > > > > > > > > > > > > This is my comparison subroutine: > > > > > > > > > > > > > > > > > > > > > > subroutine matrix_compare > > > > > > > > > > > > > > > > > > > > > > !compare big_A & PETSc matrix > > > > > > > > > > > > > > > > > > > > > > integer :: k,kk,II,JJ,ierr > > > > > > > > > > > > > > > > > > > > > > Vec xx_test,b_rhs_test > > > > > > > > > > > Mat A_mat_test > > > > > > > > > > > > > > > > > > > > > > PetscScalar aa > > > > > > > > > > > > > > > > > > > > > > PetscReal nrm > > > > > > > > > > > > > > > > > > > > > > aa=-1. > > > > > > > > > > > > > > > > > > > > > > call > > > > > > > > > > > MatCreateSeqAIJ(PETSC_COMM_SELF,total_k,total_k,10,PETSC_NULL_INTEGER,A_mat_test,ierr) > > > > > > > > > > > > > > > > > > > > > > call > > > > > > > > > > > VecCreateSeq(PETSC_COMM_SELF,total_k,b_rhs_test,ierr) > > > > > > > > > > > > > > > > > > > > > > call VecDuplicate(b_rhs_test,xx_test,ierr) > > > > > > > > > > > > > > > > > > > > > > call VecAssemblyBegin(b_rhs_test,ierr) > > > > > > > > > > > > > > > > > > > > > > call VecAssemblyEnd(b_rhs_test,ierr) > > > > > > > > > > > > > > > > > > > > > > call VecAssemblyBegin(xx_test,ierr) > > > > > > > > > > > > > > > > > > > > > > call VecAssemblyEnd(xx_test,ierr) > > > > > > > > > > > > > > > > > > > > > > do k=1,total_k > > > > > > > > > > > do kk=1,10 > > > > > > > > > > > > > > > > > > > > > > II=k-1 > > > > > > > > > > > > > > > > > > > > > > JJ=int_A(k,kk)-1 > > > > > > > > > > > call > > > > > > > > > > > MatSetValues(A_mat_test,1,II,1,JJ,big_A(k,kk),INSERT_VALUES,ierr) > > > > > > > > > > > call VecSetValue(b_rhs_test,II,q_p(k),INSERT_VALUES,ierr) > > > > > > > > > > > end do > > > > > > > > > > > > > > > > > > > > > > end do > > > > > > > > > > > > > > > > > > > > > > ! call > > > > > > > > > > > MatCopy(A_mat,A_mat_test,DIFFERENT_NONZERO_PATTERN > > > > > > > > > > > ,ierr) > > > > > > > > > > > > > > > > > > > > > > call > > > > > > > > > > > MatAssemblyBegin(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) > > > > > > > > > > > call > > > > > > > > > > > MatAssemblyEnd(A_mat_test,MAT_FINAL_ASSEMBLY,ierr) > > > > > > > > > > > > > > > > > > > > > > call > > > > > > > > > > > MatAXPY(A_mat_test,aa,A_mat,SAME_NONZERO_PATTERN,ierr) > > > > > > > > > > > > > > > > > > > > > > call MatNorm(A_mat_test,NORM_INFINITY,nrm,ierr) > > > > > > > > > > > > > > > > > > > > > > print *, nrm > > > > > > > > > > > > > > > > > > > > > > end subroutine matrix_compare > > > > > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barry Smith wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You can use MatCreateSeqAIJWithArrays() to "convert" > > > > > > > > > > > > the NSPCG > > > > > > > > > > > > matrix > > > > > > > > > > > > into > > > > > > > > > > > > PETSc format and then MatAXPY() to difference them and > > > > > > > > > > > > then > > > > > > > > > > > > MatNorm() to > > > > > > > > > > > > see > > > > > > > > > > > > how large the result is. Make sure the PETSc or hypre > > > > > > > > > > > > solver > > > > > > > > > > > > is > > > > > > > > > > > > always > > > > > > > > > > > > converging. Run with > > > > > > > > > > > > -ksp_converged_reason and or -ksp_monitor. My guess is > > > > > > > > > > > > that the > > > > > > > > > > > > matrix > > > > > > > > > > > > is > > > > > > > > > > > > becoming very ill-conditioned so the solvers with the > > > > > > > > > > > > default > > > > > > > > > > > > options > > > > > > > > > > > > are > > > > > > > > > > > > failing. > > > > > > > > > > > > > > > > > > > > > > > > Barry > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 3 Aug 2007, Ben Tay wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > I used 2 packages to solve my poisson eqn, which is > > > > > > > > > > > > > part of my > > > > > > > > > > > > > NS > > > > > > > > > > > > > unsteady > > > > > > > > > > > > > solver. One is the NSPCG solver package which uses the > > > > > > > > > > > > > compressed > > > > > > > > > > > > > row > > > > > > > > > > > > > format > > > > > > > > > > > > > to store the A matrix. The other is PETSc. I found > > > > > > > > > > > > > that using > > > > > > > > > > > > > both > > > > > > > > > > > > > solvers > > > > > > > > > > > > > gave me similar answers for a number of time step. > > > > > > > > > > > > > However, > > > > > > > > > > > > > after > > > > > > > > > > > > > that, > > > > > > > > > > > > > the > > > > > > > > > > > > > answer will suddenly change drastically for the PETSc > > > > > > > > > > > > > case. > > > > > > > > > > > > > This > > > > > > > > > > > > > does > > > > > > > > > > > > > not > > > > > > > > > > > > > happen for the NSPCG solver. > > > > > > > > > > > > > > > > > > > > > > > > > > For e.g. time step 1-315, oscillating airfoil case, > > > > > > > > > > > > > pressure > > > > > > > > > > > > > changes > > > > > > > > > > > > > smoothly, > > > > > > > > > > > > > similar answers in both cases > > > > > > > > > > > > > > > > > > > > > > > > > > at time=316, pressure changes from -3.22 to -3.2 for > > > > > > > > > > > > > NSPCG, > > > > > > > > > > > > > but > > > > > > > > > > > > > pressure > > > > > > > > > > > > > changes from -3.21 to -60.2 for PETSc > > > > > > > > > > > > > > > > > > > > > > > > > > This happens when I use HYPRE's AMG or PETSc's direct > > > > > > > > > > > > > solver > > > > > > > > > > > > > LU. > > > > > > > > > > > > > > > > > > > > > > > > > > I have been trying to find out what's the cause and I > > > > > > > > > > > > > can't > > > > > > > > > > > > > find > > > > > > > > > > > > > the > > > > > > > > > > > > > answer in > > > > > > > > > > > > > debugging. I would like to compare the values of the > > > > > > > > > > > > > matrix of > > > > > > > > > > > > > the > > > > > > > > > > > > > 2 > > > > > > > > > > > > > different > > > > > > > > > > > > > solvers and see if there's any difference. However, > > > > > > > > > > > > > NSPCG's > > > > > > > > > > > > > matrix > > > > > > > > > > > > > is > > > > > > > > > > > > > in > > > > > > > > > > > > > compressed row format while PETSc's one is just an > > > > > > > > > > > > > address and > > > > > > > > > > > > > it > > > > > > > > > > > > > can't be > > > > > > > > > > > > > viewed easily. Moreover, it's a big matrix so it's not > > > > > > > > > > > > > possible to > > > > > > > > > > > > > check > > > > > > > > > > > > > by > > > > > > > > > > > > > inspection. I'm thinking of subtracting one matrix by > > > > > > > > > > > > > the > > > > > > > > > > > > > other > > > > > > > > > > > > > and > > > > > > > > > > > > > find > > > > > > > > > > > > > if > > > > > > > > > > > > > it's zero. What's the best way to solve this problem? > > > > > > > > > > > > > Btw, I'm > > > > > > > > > > > > > using > > > > > > > > > > > > > fortran > > > > > > > > > > > > > and there's no mpi > > > > > > > > > > > > > > > > > > > > > > > > > > Thank you. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From liangcanada at gmail.com Sun Aug 12 21:29:55 2007 From: liangcanada at gmail.com (Zhu Liang) Date: Sun, 12 Aug 2007 19:29:55 -0700 Subject: How can I use BICGStab on a matrix with zero entries on the diagonal In-Reply-To: References: <440307c0708121446j4b6458ddnd43f313b1d5ac2b9@mail.gmail.com> <440307c0708121450s1f004807xce34cf21396c2a4f@mail.gmail.com> Message-ID: <440307c0708121929i27e78ca8g7a9522c046ad63a9@mail.gmail.com> Yes, you are right, I am trying to solve Oseen equation. I tried using preconditioner PCILU(1) which works well. But for PCILU(0) it did not work, as well as PCBJACOBI. I have tried to insert zero on the diagonal, but it still does not work. In your opinion, what is the best parallel solver and preconditioner for the Oseen equation ? Thanks for your reply. Liang On 8/12/07, Barry Smith wrote: > > > It is not really the BiCGstab Krylov solver that it complaining; > it is the default ILU or block Jacobi with ILU on the blocks that is > complaining. > > You first need to make sure you insert 0 entries on the all the diagonal > entries that are 0. BUT given the structure of your matrix you may want > to think about solvers that specifically handle that type of matrix. > > Barry > > Stokes type solvers? > > > On Mon, 13 Aug 2007, Zhu Liang wrote: > > > By the way, the block of my matrix is like : > > > > U , a > > A^T , 0 > > > > > > > > ---------- Forwarded message ---------- > > From: Zhu Liang > > Date: Aug 13, 2007 5:46 AM > > Subject: How can I use BICGStab on a matrix with zero entries on the > > diagonal > > To: petsc-users at mcs.anl.gov > > > > > > Dear petsc-users > > > > When I try to solve a linear equation Ax=b with BicgStab preconditioner, > I > > got > > an error "Matrix is missing diagonal number". That is because I have > zeros > > on > > the diagonal of the matrix. > > > > I am wondering if there is some simple method to avoid that? > > > > Best, > > Liang > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkoyama at berkeley.edu Mon Aug 13 15:25:54 2007 From: tkoyama at berkeley.edu (TsuyoshiKoyama(berkeley)) Date: Mon, 13 Aug 2007 22:25:54 +0200 Subject: Question regarding PCMG Message-ID: <006501c7dde8$288c4120$96d28481@FUMBOLT> Dear petsc-users, I am currently trying to use the PCMG object and had some questions with the preconditioner. --------------------------------------------------------- 1. In this multigrid preconditioner, the default KSP smoother seems to be GMRES. If one wanted to use the Gauss-Seidel iteration as a smoother what would one do? The solution that I thought feasible is to use the PCGauss-Seidel and set this into the KSP smoother, and set the Krylov solver type to KSPPreonly. Since we are using a Gauss-Seidel smoothing and in the case that we include post-smoothing, the smoother must be able to incorporate a nonzero initial guess. Thus one would think of setting the flag for KSPSetInitialGuessNonzero. Unfortunately the combination of, -KSPPreonly -KSPSetInitialGuessNonzero is rejected in /src/ksp/ksp/impls/preonly/preonly.c line:24. Here it advises one to use a Richardson but that is not what I would like. 2. In the setting of the coarse grid KSP smoother(solver) in PCMG, in the function PCSetUp_MG in file /src/ksp/pc/impls/mg/mg.c line:474 there is a setting that requires one to only be able to use lu, redundant, or cholesky as the solver in the case of preonly. This means that one would not again be able to use the type of solver that I have stated above, a Gauss-Seidel solver or any other user-specified stationary solver with KSPPreonly. --------------------------------------------------------- If you have any comments or tricks to get by this, it would be very helpful. Sincerely, -Tsuyoshi Koyama From w_subber at yahoo.com Mon Aug 13 16:25:26 2007 From: w_subber at yahoo.com (Waad Subber) Date: Mon, 13 Aug 2007 14:25:26 -0700 (PDT) Subject: calling PETSc from Fortan main routine Message-ID: <760323.81326.qm@web38209.mail.mud.yahoo.com> Hello Everyone, I am a new PETSc user; and I am wondering if any one can help me with the following issue. The issue is I want to write KSP solver with all the required objects in an external subroutine and then call it from my main program. I don't know if I can do that. What I mean is I have a main code consist of several subroutines and I want to change my solver with PETSc solver with keeping the same structure of my main program. Thanks :) Waad --------------------------------- Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From balay at mcs.anl.gov Mon Aug 13 16:37:46 2007 From: balay at mcs.anl.gov (Satish Balay) Date: Mon, 13 Aug 2007 16:37:46 -0500 (CDT) Subject: calling PETSc from Fortan main routine In-Reply-To: <760323.81326.qm@web38209.mail.mud.yahoo.com> References: <760323.81326.qm@web38209.mail.mud.yahoo.com> Message-ID: On Mon, 13 Aug 2007, Waad Subber wrote: > Hello Everyone, > > I am a new PETSc user; and I am wondering if any one can help me with the following issue. > > The issue is I want to write KSP solver with all the required objects in an external subroutine and then call it from my main program. I don't know if I can do that. > > What I mean is I have a main code consist of several subroutines and I want to change my solver with PETSc solver with keeping the same structure of my main program. > > Thanks :) It should work. The only thing you have to make sure is - PetscInitialize()/PetscFinalize() routines are called only once. Satish From w_subber at yahoo.com Mon Aug 13 16:50:01 2007 From: w_subber at yahoo.com (Waad Subber) Date: Mon, 13 Aug 2007 14:50:01 -0700 (PDT) Subject: calling PETSc from Fortan main routine In-Reply-To: Message-ID: <219592.29848.qm@web38201.mail.mud.yahoo.com> And what about the makefile how can I include my subroutines inside the petsc makefile Thanks Satish Balay wrote: On Mon, 13 Aug 2007, Waad Subber wrote: > Hello Everyone, > > I am a new PETSc user; and I am wondering if any one can help me with the following issue. > > The issue is I want to write KSP solver with all the required objects in an external subroutine and then call it from my main program. I don't know if I can do that. > > What I mean is I have a main code consist of several subroutines and I want to change my solver with PETSc solver with keeping the same structure of my main program. > > Thanks :) It should work. The only thing you have to make sure is - PetscInitialize()/PetscFinalize() routines are called only once. Satish --------------------------------- Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. -------------- next part -------------- An HTML attachment was scrubbed... URL: From balay at mcs.anl.gov Mon Aug 13 16:55:02 2007 From: balay at mcs.anl.gov (Satish Balay) Date: Mon, 13 Aug 2007 16:55:02 -0500 (CDT) Subject: calling PETSc from Fortan main routine In-Reply-To: <219592.29848.qm@web38201.mail.mud.yahoo.com> References: <219592.29848.qm@web38201.mail.mud.yahoo.com> Message-ID: On Mon, 13 Aug 2007, Waad Subber wrote: > And what about the makefile how can I include my subroutines inside the petsc makefile > > Thanks I'm ataching a minimal petsc makefile. You can add your stuff as OBJS = foo.o bar.o [and then replace ex1.o with $(OBJS)] Satish -------------- next part -------------- CFLAGS = FFLAGS = CPPFLAGS = FPPFLAGS = CLEANFILES = include ${PETSC_DIR}/conf/base ex1f: ex1f.o chkopts -${FLINKER} -o ex1f ex1f.o ${PETSC_LIB} ${RM} ex1f.o From knepley at gmail.com Mon Aug 13 18:11:19 2007 From: knepley at gmail.com (Matthew Knepley) Date: Mon, 13 Aug 2007 18:11:19 -0500 Subject: Question regarding PCMG In-Reply-To: <006501c7dde8$288c4120$96d28481@FUMBOLT> References: <006501c7dde8$288c4120$96d28481@FUMBOLT> Message-ID: On 8/13/07, TsuyoshiKoyama(berkeley) wrote: > Dear petsc-users, > > I am currently trying to use the PCMG object and > had some questions with the preconditioner. > > --------------------------------------------------------- > 1. In this multigrid preconditioner, the default KSP smoother seems > to be GMRES. If one wanted to use the Gauss-Seidel > iteration as a smoother what would one do? > > The solution that I thought feasible is to use the PCGauss-Seidel > and set this into the KSP smoother, and set the Krylov solver > type to KSPPreonly. Since we are using a Gauss-Seidel smoothing > and in the case that we include post-smoothing, the smoother must > be able to incorporate a nonzero initial guess. Thus one would think > of setting the flag for KSPSetInitialGuessNonzero. Unfortunately the > combination of, > > -KSPPreonly > -KSPSetInitialGuessNonzero > > is rejected in /src/ksp/ksp/impls/preonly/preonly.c line:24. Here it > advises one to use a Richardson but that is not what I would like. Actually, I believe Richardson is exactly what you want. It is just the simple update. > 2. In the setting of the coarse grid KSP smoother(solver) in PCMG, in the > function > PCSetUp_MG in file /src/ksp/pc/impls/mg/mg.c line:474 there is > a setting that requires one to only be able to use lu, redundant, or > cholesky as the solver in the case of preonly. This means that one would > not again be able to use the type of solver that I have stated above, > a Gauss-Seidel solver or any other user-specified stationary > solver with KSPPreonly. > --------------------------------------------------------- I do not really understand what you want here. Can you give me more explanation? The coarse problem by default is solved exactly. Thanks, Matt > If you have any comments or tricks to get by this, it would be very > helpful. > > Sincerely, > > -Tsuyoshi Koyama -- 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 From w_subber at yahoo.com Mon Aug 13 18:51:38 2007 From: w_subber at yahoo.com (Waad Subber) Date: Mon, 13 Aug 2007 16:51:38 -0700 (PDT) Subject: calling PETSc from Fortan main routine In-Reply-To: Message-ID: <337938.58368.qm@web38215.mail.mud.yahoo.com> Many Thanks to you :) Satish Balay wrote: On Mon, 13 Aug 2007, Waad Subber wrote: > And what about the makefile how can I include my subroutines inside the petsc makefile > > Thanks I'm ataching a minimal petsc makefile. You can add your stuff as OBJS = foo.o bar.o [and then replace ex1.o with $(OBJS)] SatishCFLAGS = FFLAGS = CPPFLAGS = FPPFLAGS = CLEANFILES = include ${PETSC_DIR}/conf/base ex1f: ex1f.o chkopts -${FLINKER} -o ex1f ex1f.o ${PETSC_LIB} ${RM} ex1f.o --------------------------------- Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkoyama at berkeley.edu Mon Aug 13 19:38:43 2007 From: tkoyama at berkeley.edu (TsuyoshiKoyama(berkeley)) Date: Tue, 14 Aug 2007 02:38:43 +0200 Subject: Question regarding PCMG References: <006501c7dde8$288c4120$96d28481@FUMBOLT> Message-ID: <009901c7de0b$7a2c0420$96d28481@FUMBOLT> Thank you very much for the quick response. Considering the first comment, after again looking at the Richardson KSP code I observe the following. Given the precondioned system, PAx = Pb the iteration is conducted as, x_{n+1} = x_{n} + scale*P(b-Ax_{n}) If one gives, NonZeroInitialGuess what happens is the following, 1) r = (b-A_x{initial guess}) 2) Do the following maxit times, x_{new} = x_{old} + scale*Pr r = b - x_{new} Thus if one sets the preconditioner Gauss-Seidel as P_{GS}, then one iteration produces the following value of x x_{result} = x_{initial guess} + scale*P_{GS}(b-Ax_{initial guess}) when one desires in a Gauss-Seidel smoother, x_{result} = x_{initial guess} + (L+D)^{-1}(b - Ux_{initial guess}) where, A = L(strict lower) + D+ U(strict upper) Does this mean that somehow Petsc internally modifies Amat in the PC object so that Amat = P, and PC_Apply multiplies by (L+D)^{-1}? Am I missing some detail or misunderstanding the behavior of PC? As for the second case, the reason I might not select a coarse solver is since I am trying to solve a Helmholtz equation and the coarse grid solve might not be correct enough to apply. Thus, you may just point out that the coarse grid should be large enough to resolve the so called low frequency error and that if you do so you should still be able to solve direct, but I was curious on testing different types of operations at the coarsest level. In both of the comments I know I can get around them by changing(commenting out) the corresponding source code lines(I assume that this effect will be minimal though I do not know how much) but I was wondering if some other people had made similar remarks or questions. Again, thank you very much. Sincerely, Tsuyoshi Koyama ----- Original Message ----- From: "Matthew Knepley" To: Sent: Tuesday, August 14, 2007 1:11 AM Subject: Re: Question regarding PCMG > On 8/13/07, TsuyoshiKoyama(berkeley) wrote: >> Dear petsc-users, >> >> I am currently trying to use the PCMG object and >> had some questions with the preconditioner. >> >> --------------------------------------------------------- >> 1. In this multigrid preconditioner, the default KSP smoother seems >> to be GMRES. If one wanted to use the Gauss-Seidel >> iteration as a smoother what would one do? >> >> The solution that I thought feasible is to use the PCGauss-Seidel >> and set this into the KSP smoother, and set the Krylov solver >> type to KSPPreonly. Since we are using a Gauss-Seidel smoothing >> and in the case that we include post-smoothing, the smoother must >> be able to incorporate a nonzero initial guess. Thus one would think >> of setting the flag for KSPSetInitialGuessNonzero. Unfortunately the >> combination of, >> >> -KSPPreonly >> -KSPSetInitialGuessNonzero >> >> is rejected in /src/ksp/ksp/impls/preonly/preonly.c line:24. Here it >> advises one to use a Richardson but that is not what I would like. > > Actually, I believe Richardson is exactly what you want. It is just the > simple > update. > >> 2. In the setting of the coarse grid KSP smoother(solver) in PCMG, in the >> function >> PCSetUp_MG in file /src/ksp/pc/impls/mg/mg.c line:474 there is >> a setting that requires one to only be able to use lu, redundant, or >> cholesky as the solver in the case of preonly. This means that one would >> not again be able to use the type of solver that I have stated above, >> a Gauss-Seidel solver or any other user-specified stationary >> solver with KSPPreonly. >> --------------------------------------------------------- > > I do not really understand what you want here. Can you give me more > explanation? > The coarse problem by default is solved exactly. > > Thanks, > > Matt > >> If you have any comments or tricks to get by this, it would be very >> helpful. >> >> Sincerely, >> >> -Tsuyoshi Koyama > -- > 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 > From tkoyama at berkeley.edu Mon Aug 13 20:08:32 2007 From: tkoyama at berkeley.edu (TsuyoshiKoyama(berkeley)) Date: Tue, 14 Aug 2007 03:08:32 +0200 Subject: Question regarding PCMG References: <006501c7dde8$288c4120$96d28481@FUMBOLT> <009901c7de0b$7a2c0420$96d28481@FUMBOLT> Message-ID: <00aa01c7de0f$a344f6b0$96d28481@FUMBOLT> Concerning the first I understand now.... The equation for Gauss-Seidel is exactly, > x_{result} = x_{initial guess} + (L+D)^{-1}(b - Ax_{initial guess}) So what the PC_{GS} does is to apply (L+D)^{-1} to a vector. This changes the form of my first question which I will restate in a following email. Sincerely, -Tsuyoshi Koyma ----- Original Message ----- From: "TsuyoshiKoyama(berkeley)" To: Sent: Tuesday, August 14, 2007 2:38 AM Subject: Re: Question regarding PCMG > Thank you very much for the quick response. Considering the first comment, > after again looking at the Richardson KSP code I observe the following. > Given the precondioned system, > > PAx = Pb > > the iteration is conducted as, > > x_{n+1} = x_{n} + scale*P(b-Ax_{n}) > > If one gives, NonZeroInitialGuess what happens is the following, > > 1) r = (b-A_x{initial guess}) > 2) Do the following maxit times, > > x_{new} = x_{old} + scale*Pr > r = b - x_{new} > > Thus if one sets the preconditioner Gauss-Seidel as P_{GS}, then one > iteration produces the following value of x > > x_{result} = x_{initial guess} + scale*P_{GS}(b-Ax_{initial guess}) > > when one desires in a Gauss-Seidel smoother, > > x_{result} = x_{initial guess} + (L+D)^{-1}(b - Ux_{initial guess}) > > where, A = L(strict lower) + D+ U(strict upper) > > Does this mean that somehow Petsc internally modifies Amat in the PC > object so that Amat = P, and PC_Apply multiplies by (L+D)^{-1}? Am > I missing some detail or misunderstanding the behavior of PC? > > As for the second case, the reason I might not select a coarse solver is > since I > am trying to solve a Helmholtz equation and the coarse grid solve might > not be > correct enough to apply. Thus, you may just point out that the coarse grid > should > be large enough to resolve the so called low frequency error and that if > you do so > you should still be able to solve direct, but I was curious on testing > different types > of operations at the coarsest level. > > In both of the comments I know I can get around them by > changing(commenting out) the corresponding source code lines(I assume that > this effect will be minimal though I do not > know how much) but I was wondering if some other people had made similar > remarks > or questions. > > Again, thank you very much. > > Sincerely, > > Tsuyoshi Koyama > > ----- Original Message ----- > From: "Matthew Knepley" > To: > Sent: Tuesday, August 14, 2007 1:11 AM > Subject: Re: Question regarding PCMG > > >> On 8/13/07, TsuyoshiKoyama(berkeley) wrote: >>> Dear petsc-users, >>> >>> I am currently trying to use the PCMG object and >>> had some questions with the preconditioner. >>> >>> --------------------------------------------------------- >>> 1. In this multigrid preconditioner, the default KSP smoother seems >>> to be GMRES. If one wanted to use the Gauss-Seidel >>> iteration as a smoother what would one do? >>> >>> The solution that I thought feasible is to use the PCGauss-Seidel >>> and set this into the KSP smoother, and set the Krylov solver >>> type to KSPPreonly. Since we are using a Gauss-Seidel smoothing >>> and in the case that we include post-smoothing, the smoother must >>> be able to incorporate a nonzero initial guess. Thus one would think >>> of setting the flag for KSPSetInitialGuessNonzero. Unfortunately the >>> combination of, >>> >>> -KSPPreonly >>> -KSPSetInitialGuessNonzero >>> >>> is rejected in /src/ksp/ksp/impls/preonly/preonly.c line:24. Here it >>> advises one to use a Richardson but that is not what I would like. >> >> Actually, I believe Richardson is exactly what you want. It is just the >> simple >> update. >> >>> 2. In the setting of the coarse grid KSP smoother(solver) in PCMG, in >>> the >>> function >>> PCSetUp_MG in file /src/ksp/pc/impls/mg/mg.c line:474 there is >>> a setting that requires one to only be able to use lu, redundant, or >>> cholesky as the solver in the case of preonly. This means that one would >>> not again be able to use the type of solver that I have stated above, >>> a Gauss-Seidel solver or any other user-specified stationary >>> solver with KSPPreonly. >>> --------------------------------------------------------- >> >> I do not really understand what you want here. Can you give me more >> explanation? >> The coarse problem by default is solved exactly. >> >> Thanks, >> >> Matt >> >>> If you have any comments or tricks to get by this, it would be very >>> helpful. >>> >>> Sincerely, >>> >>> -Tsuyoshi Koyama >> -- >> 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 >> > From zonexo at gmail.com Tue Aug 14 05:22:38 2007 From: zonexo at gmail.com (Ben Tay) Date: Tue, 14 Aug 2007 18:22:38 +0800 Subject: Error when solving eqns with PETSc Message-ID: <46C1826E.9010302@gmail.com> Hi, I am currently using the following way to solve my poisson eqn in global.F (global variables) implicit none save Mat A_mat Vec xx,b_rhs KSP ksp PC pc PCType ptype KSPType ksptype then they are initialized call PetscInitialize(PETSC_NULL_CHARACTER,ierr) call MatCreateSeqAIJ(PETSC_COMM_SELF,size_x*size_y,size_x*size_y,13,PETSC_NULL_INTEGER,A_mat,ierr) call VecCreateSeq(PETSC_COMM_SELF,size_x*size_y,b_rhs,ierr) call VecDuplicate(b_rhs,xx,ierr) call KSPCreate(PETSC_COMM_SELF,ksp,ierr) call VecAssemblyBegin(b_rhs,ierr) call VecAssemblyEnd(b_rhs,ierr) call VecAssemblyBegin(xx,ierr) call VecAssemblyEnd(xx,ierr) My original matrix is stored as ITPACK format so I used ellcsr from SPARSKIT to convert to CSR format and use call ellcsr(total_k,big_A,int_a,total_k,13,A_spar,ja_spar,ia_spar,nzmax,ierr) ... call MatCreateSeqAIJWithArrays(PETSC_COMM_SELF,Ntot,Ntot,ia_spar,ja_spar,A_spar,A_mat,ierr) call MatAssemblyBegin(A_mat,MAT_FINAL_ASSEMBLY,ierr) call MatAssemblyEnd(A_mat,MAT_FINAL_ASSEMBLY,ierr) to read into PETSc. Then read in the RHS as well do k=1,Ntot II=k-1 call VecSetValue(b_rhs,II,q_p(k),INSERT_VALUES,ierr) end do Finally the matrix is solved using call KSPSolve(ksp,b_rhs,xx,ierr). This works but the A_mat matrix is not changing with time. Hence I tried to call the above sentences only at the 1st time step. However I got this error when KSPSolve is called: [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/petsc-as/documentation/troubleshooting.html#Signal[0]PETSC ERROR: or try http://valgrind.org on linux or man libgmalloc on Apple to find memory corruption errors [0]PETSC ERROR: configure using --with-debugging=yes, recompile, link, and run [0]PETSC ERROR: to get more information on the crash. [0]PETSC ERROR: --------------------- Error Message ------------------------------------ [0]PETSC ERROR: Signal received! [0]PETSC ERROR: ------------------------------------------------------------------------ [0]PETSC ERROR: Petsc Release Version 2.3.3, Patch 4, Tue Aug 7 17:36:16 CDT 2007 HG revision: ee49636ddd90fb72d14b79fa8180225eb4257c59 [0]PETSC ERROR: See docs/changes/index.html for recent updates. [0]PETSC ERROR: See docs/faq.html for hints about trouble shooting. [0]PETSC ERROR: See docs/index.html for manual pages. [0]PETSC ERROR: ------------------------------------------------------------------------ [0]PETSC ERROR: ./a.out on a atlas3 named atlas3-c01 by g0306332 Tue Aug 14 18:13:09 2007 [0]PETSC ERROR: Libraries linked from /lsftmp/g0306332/petsc-2.3.3-p4/lib/atlas3 [0]PETSC ERROR: Configure run at Sat Aug 11 08:25:45 2007 [0]PETSC ERROR: Configure options --with-cc=icc --with-fc=ifort --with-x=0 --download-hypre=1 --download-mumps=1 --download-scalapack=1 --download-blacs=1 --with-debugging=0 --with-blas-lapack-dir=/opt/intel/cmkl/8.1.1/ --with-shared --with-mpi-dir=/lsftmp/g0306332/mpich2/ [0]PETSC ERROR: ------------------------------------------------------------------------ [0]PETSC ERROR: User provided function() line 0 in unknown directory unknown file [unset]: aborting job: application called MPI_Abort(MPI_COMM_WORLD, 59) - process 0 I thought I've delcared A_mat as a global variable so after filling up values using MatCreateSeqAIJWithArrays, MatAssemblyBegin, MatAssemblyEnd, I only need to update the RHS vector. It seems that I'm missing out something. From knepley at gmail.com Tue Aug 14 08:02:32 2007 From: knepley at gmail.com (Matthew Knepley) Date: Tue, 14 Aug 2007 08:02:32 -0500 Subject: Question regarding PCMG In-Reply-To: <009901c7de0b$7a2c0420$96d28481@FUMBOLT> References: <006501c7dde8$288c4120$96d28481@FUMBOLT> <009901c7de0b$7a2c0420$96d28481@FUMBOLT> Message-ID: On 8/13/07, TsuyoshiKoyama(berkeley) wrote: > As for the second case, the reason I might not select a coarse solver is > since I > am trying to solve a Helmholtz equation and the coarse grid solve might not > be > correct enough to apply. Thus, you may just point out that the coarse grid > should > be large enough to resolve the so called low frequency error and that if you > do so > you should still be able to solve direct, but I was curious on testing > different types > of operations at the coarsest level. The coarse solver can be set to anything you choose. You just extract the coarse KSP and set the type. Thanks, Matt -- 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 From knepley at gmail.com Tue Aug 14 08:09:04 2007 From: knepley at gmail.com (Matthew Knepley) Date: Tue, 14 Aug 2007 08:09:04 -0500 Subject: Error when solving eqns with PETSc In-Reply-To: <46C1826E.9010302@gmail.com> References: <46C1826E.9010302@gmail.com> Message-ID: Memory is being garbaged somewhere. I suggest using valgrind as it says in the error message. However, I also have a guess. Are you sure that the AIJ arrays that you provided to the constructor are using 0-offset numbering? I suspect that it would be 1-offset for both ia_spar and ja_spar which would cause problems. Matt On 8/14/07, Ben Tay wrote: > Hi, > > I am currently using the following way to solve my poisson eqn > > in global.F (global variables) > > implicit none > > save > > Mat A_mat > Vec xx,b_rhs > KSP ksp > PC pc > PCType ptype > KSPType ksptype > > then they are initialized > > call PetscInitialize(PETSC_NULL_CHARACTER,ierr) > call > MatCreateSeqAIJ(PETSC_COMM_SELF,size_x*size_y,size_x*size_y,13,PETSC_NULL_INTEGER,A_mat,ierr) > call VecCreateSeq(PETSC_COMM_SELF,size_x*size_y,b_rhs,ierr) > call VecDuplicate(b_rhs,xx,ierr) > call KSPCreate(PETSC_COMM_SELF,ksp,ierr) > call VecAssemblyBegin(b_rhs,ierr) > call VecAssemblyEnd(b_rhs,ierr) > call VecAssemblyBegin(xx,ierr) > call VecAssemblyEnd(xx,ierr) > > My original matrix is stored as ITPACK format so I used ellcsr from > SPARSKIT to convert to CSR format and use > > call > ellcsr(total_k,big_A,int_a,total_k,13,A_spar,ja_spar,ia_spar,nzmax,ierr) > ... > call > MatCreateSeqAIJWithArrays(PETSC_COMM_SELF,Ntot,Ntot,ia_spar,ja_spar,A_spar,A_mat,ierr) > call MatAssemblyBegin(A_mat,MAT_FINAL_ASSEMBLY,ierr) > call MatAssemblyEnd(A_mat,MAT_FINAL_ASSEMBLY,ierr) > > to read into PETSc. Then read in the RHS as well > > do k=1,Ntot > II=k-1 > call VecSetValue(b_rhs,II,q_p(k),INSERT_VALUES,ierr) > end do > > Finally the matrix is solved using > > call KSPSolve(ksp,b_rhs,xx,ierr). > > This works but the A_mat matrix is not changing with time. Hence I tried > to call the above sentences only at the 1st time step. However I got > this error when KSPSolve is called: > > [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/petsc-as/documentation/troubleshooting.html#Signal[0]PETSC > ERROR: or try http://valgrind.org on linux or man libgmalloc on Apple to > find memory corruption errors > [0]PETSC ERROR: configure using --with-debugging=yes, recompile, link, > and run > [0]PETSC ERROR: to get more information on the crash. > [0]PETSC ERROR: --------------------- Error Message > ------------------------------------ > [0]PETSC ERROR: Signal received! > [0]PETSC ERROR: > ------------------------------------------------------------------------ > [0]PETSC ERROR: Petsc Release Version 2.3.3, Patch 4, Tue Aug 7 > 17:36:16 CDT 2007 HG revision: ee49636ddd90fb72d14b79fa8180225eb4257c59 > [0]PETSC ERROR: See docs/changes/index.html for recent updates. > [0]PETSC ERROR: See docs/faq.html for hints about trouble shooting. > [0]PETSC ERROR: See docs/index.html for manual pages. > [0]PETSC ERROR: > ------------------------------------------------------------------------ > [0]PETSC ERROR: ./a.out on a atlas3 named atlas3-c01 by g0306332 Tue Aug > 14 18:13:09 2007 > [0]PETSC ERROR: Libraries linked from > /lsftmp/g0306332/petsc-2.3.3-p4/lib/atlas3 > [0]PETSC ERROR: Configure run at Sat Aug 11 08:25:45 2007 > [0]PETSC ERROR: Configure options --with-cc=icc --with-fc=ifort > --with-x=0 --download-hypre=1 --download-mumps=1 --download-scalapack=1 > --download-blacs=1 --with-debugging=0 > --with-blas-lapack-dir=/opt/intel/cmkl/8.1.1/ --with-shared > --with-mpi-dir=/lsftmp/g0306332/mpich2/ > [0]PETSC ERROR: > ------------------------------------------------------------------------ > [0]PETSC ERROR: User provided function() line 0 in unknown directory > unknown file > [unset]: aborting job: > application called MPI_Abort(MPI_COMM_WORLD, 59) - process 0 > > I thought I've delcared A_mat as a global variable so after filling up > values using MatCreateSeqAIJWithArrays, MatAssemblyBegin, > MatAssemblyEnd, I only need to update the RHS vector. It seems that I'm > missing out something. > > -- 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 From zonexo at gmail.com Tue Aug 14 10:07:39 2007 From: zonexo at gmail.com (Ben Tay) Date: Tue, 14 Aug 2007 23:07:39 +0800 Subject: Error when solving eqns with PETSc In-Reply-To: References: <46C1826E.9010302@gmail.com> Message-ID: <46C1C53B.2020804@gmail.com> Oh, I will check up valgrind since I've not used it b4. The original converter starts from 1 so I've done a -1 offset. If I call converter, MatCreateSeqAIJWithArrays, MatAssemblyBegin,MatAssemblyEnd at every time step, it works perfectly and the answers are very close with another solver. However, if I only called it once, the error appears the moment I try to call KSPSolve. One qn is if I declare A_mat as a global variable, once I finalise it with MatAssemblyBegin,MatAssemblyEnd, it should remain as global variable? I don't 've to do any more manipulation. I just 've to update the RHS vector and I can call KSPSolve to get the solution. Is that correct? Thanks Matthew Knepley wrote: > Memory is being garbaged somewhere. I suggest using valgrind as it says > in the error message. However, I also have a guess. Are you sure that the > AIJ arrays that you provided to the constructor are using 0-offset numbering? > I suspect that it would be 1-offset for both ia_spar and ja_spar which would > cause problems. > > Matt > > On 8/14/07, Ben Tay wrote: > >> Hi, >> >> I am currently using the following way to solve my poisson eqn >> >> in global.F (global variables) >> >> implicit none >> >> save >> >> Mat A_mat >> Vec xx,b_rhs >> KSP ksp >> PC pc >> PCType ptype >> KSPType ksptype >> >> then they are initialized >> >> call PetscInitialize(PETSC_NULL_CHARACTER,ierr) >> call >> MatCreateSeqAIJ(PETSC_COMM_SELF,size_x*size_y,size_x*size_y,13,PETSC_NULL_INTEGER,A_mat,ierr) >> call VecCreateSeq(PETSC_COMM_SELF,size_x*size_y,b_rhs,ierr) >> call VecDuplicate(b_rhs,xx,ierr) >> call KSPCreate(PETSC_COMM_SELF,ksp,ierr) >> call VecAssemblyBegin(b_rhs,ierr) >> call VecAssemblyEnd(b_rhs,ierr) >> call VecAssemblyBegin(xx,ierr) >> call VecAssemblyEnd(xx,ierr) >> >> My original matrix is stored as ITPACK format so I used ellcsr from >> SPARSKIT to convert to CSR format and use >> >> call >> ellcsr(total_k,big_A,int_a,total_k,13,A_spar,ja_spar,ia_spar,nzmax,ierr) >> ... >> call >> MatCreateSeqAIJWithArrays(PETSC_COMM_SELF,Ntot,Ntot,ia_spar,ja_spar,A_spar,A_mat,ierr) >> call MatAssemblyBegin(A_mat,MAT_FINAL_ASSEMBLY,ierr) >> call MatAssemblyEnd(A_mat,MAT_FINAL_ASSEMBLY,ierr) >> >> to read into PETSc. Then read in the RHS as well >> >> do k=1,Ntot >> II=k-1 >> call VecSetValue(b_rhs,II,q_p(k),INSERT_VALUES,ierr) >> end do >> >> Finally the matrix is solved using >> >> call KSPSolve(ksp,b_rhs,xx,ierr). >> >> This works but the A_mat matrix is not changing with time. Hence I tried >> to call the above sentences only at the 1st time step. However I got >> this error when KSPSolve is called: >> >> [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/petsc-as/documentation/troubleshooting.html#Signal[0]PETSC >> ERROR: or try http://valgrind.org on linux or man libgmalloc on Apple to >> find memory corruption errors >> [0]PETSC ERROR: configure using --with-debugging=yes, recompile, link, >> and run >> [0]PETSC ERROR: to get more information on the crash. >> [0]PETSC ERROR: --------------------- Error Message >> ------------------------------------ >> [0]PETSC ERROR: Signal received! >> [0]PETSC ERROR: >> ------------------------------------------------------------------------ >> [0]PETSC ERROR: Petsc Release Version 2.3.3, Patch 4, Tue Aug 7 >> 17:36:16 CDT 2007 HG revision: ee49636ddd90fb72d14b79fa8180225eb4257c59 >> [0]PETSC ERROR: See docs/changes/index.html for recent updates. >> [0]PETSC ERROR: See docs/faq.html for hints about trouble shooting. >> [0]PETSC ERROR: See docs/index.html for manual pages. >> [0]PETSC ERROR: >> ------------------------------------------------------------------------ >> [0]PETSC ERROR: ./a.out on a atlas3 named atlas3-c01 by g0306332 Tue Aug >> 14 18:13:09 2007 >> [0]PETSC ERROR: Libraries linked from >> /lsftmp/g0306332/petsc-2.3.3-p4/lib/atlas3 >> [0]PETSC ERROR: Configure run at Sat Aug 11 08:25:45 2007 >> [0]PETSC ERROR: Configure options --with-cc=icc --with-fc=ifort >> --with-x=0 --download-hypre=1 --download-mumps=1 --download-scalapack=1 >> --download-blacs=1 --with-debugging=0 >> --with-blas-lapack-dir=/opt/intel/cmkl/8.1.1/ --with-shared >> --with-mpi-dir=/lsftmp/g0306332/mpich2/ >> [0]PETSC ERROR: >> ------------------------------------------------------------------------ >> [0]PETSC ERROR: User provided function() line 0 in unknown directory >> unknown file >> [unset]: aborting job: >> application called MPI_Abort(MPI_COMM_WORLD, 59) - process 0 >> >> I thought I've delcared A_mat as a global variable so after filling up >> values using MatCreateSeqAIJWithArrays, MatAssemblyBegin, >> MatAssemblyEnd, I only need to update the RHS vector. It seems that I'm >> missing out something. >> >> >> > > > From knepley at gmail.com Tue Aug 14 10:15:53 2007 From: knepley at gmail.com (Matthew Knepley) Date: Tue, 14 Aug 2007 10:15:53 -0500 Subject: Error when solving eqns with PETSc In-Reply-To: <46C1C53B.2020804@gmail.com> References: <46C1826E.9010302@gmail.com> <46C1C53B.2020804@gmail.com> Message-ID: On 8/14/07, Ben Tay wrote: > Oh, I will check up valgrind since I've not used it b4. The original > converter starts from 1 so I've done a -1 offset. If I call converter, > MatCreateSeqAIJWithArrays, MatAssemblyBegin,MatAssemblyEnd at every time > step, it works perfectly and the answers are very close with another > solver. However, if I only called it once, the error appears the moment > I try to call KSPSolve. > > One qn is if I declare A_mat as a global variable, once I finalise it > with MatAssemblyBegin,MatAssemblyEnd, it should remain as global > variable? I don't 've to do any more manipulation. Are you sure you are not calling MatDestroy? Matt > I just 've to update the RHS vector and I can call KSPSolve to get the > solution. Is that correct? > > Thanks > > Matthew Knepley wrote: > > Memory is being garbaged somewhere. I suggest using valgrind as it says > > in the error message. However, I also have a guess. Are you sure that the > > AIJ arrays that you provided to the constructor are using 0-offset numbering? > > I suspect that it would be 1-offset for both ia_spar and ja_spar which would > > cause problems. > > > > Matt > > > > On 8/14/07, Ben Tay wrote: > > > >> Hi, > >> > >> I am currently using the following way to solve my poisson eqn > >> > >> in global.F (global variables) > >> > >> implicit none > >> > >> save > >> > >> Mat A_mat > >> Vec xx,b_rhs > >> KSP ksp > >> PC pc > >> PCType ptype > >> KSPType ksptype > >> > >> then they are initialized > >> > >> call PetscInitialize(PETSC_NULL_CHARACTER,ierr) > >> call > >> MatCreateSeqAIJ(PETSC_COMM_SELF,size_x*size_y,size_x*size_y,13,PETSC_NULL_INTEGER,A_mat,ierr) > >> call VecCreateSeq(PETSC_COMM_SELF,size_x*size_y,b_rhs,ierr) > >> call VecDuplicate(b_rhs,xx,ierr) > >> call KSPCreate(PETSC_COMM_SELF,ksp,ierr) > >> call VecAssemblyBegin(b_rhs,ierr) > >> call VecAssemblyEnd(b_rhs,ierr) > >> call VecAssemblyBegin(xx,ierr) > >> call VecAssemblyEnd(xx,ierr) > >> > >> My original matrix is stored as ITPACK format so I used ellcsr from > >> SPARSKIT to convert to CSR format and use > >> > >> call > >> ellcsr(total_k,big_A,int_a,total_k,13,A_spar,ja_spar,ia_spar,nzmax,ierr) > >> ... > >> call > >> MatCreateSeqAIJWithArrays(PETSC_COMM_SELF,Ntot,Ntot,ia_spar,ja_spar,A_spar,A_mat,ierr) > >> call MatAssemblyBegin(A_mat,MAT_FINAL_ASSEMBLY,ierr) > >> call MatAssemblyEnd(A_mat,MAT_FINAL_ASSEMBLY,ierr) > >> > >> to read into PETSc. Then read in the RHS as well > >> > >> do k=1,Ntot > >> II=k-1 > >> call VecSetValue(b_rhs,II,q_p(k),INSERT_VALUES,ierr) > >> end do > >> > >> Finally the matrix is solved using > >> > >> call KSPSolve(ksp,b_rhs,xx,ierr). > >> > >> This works but the A_mat matrix is not changing with time. Hence I tried > >> to call the above sentences only at the 1st time step. However I got > >> this error when KSPSolve is called: > >> > >> [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/petsc-as/documentation/troubleshooting.html#Signal[0]PETSC > >> ERROR: or try http://valgrind.org on linux or man libgmalloc on Apple to > >> find memory corruption errors > >> [0]PETSC ERROR: configure using --with-debugging=yes, recompile, link, > >> and run > >> [0]PETSC ERROR: to get more information on the crash. > >> [0]PETSC ERROR: --------------------- Error Message > >> ------------------------------------ > >> [0]PETSC ERROR: Signal received! > >> [0]PETSC ERROR: > >> ------------------------------------------------------------------------ > >> [0]PETSC ERROR: Petsc Release Version 2.3.3, Patch 4, Tue Aug 7 > >> 17:36:16 CDT 2007 HG revision: ee49636ddd90fb72d14b79fa8180225eb4257c59 > >> [0]PETSC ERROR: See docs/changes/index.html for recent updates. > >> [0]PETSC ERROR: See docs/faq.html for hints about trouble shooting. > >> [0]PETSC ERROR: See docs/index.html for manual pages. > >> [0]PETSC ERROR: > >> ------------------------------------------------------------------------ > >> [0]PETSC ERROR: ./a.out on a atlas3 named atlas3-c01 by g0306332 Tue Aug > >> 14 18:13:09 2007 > >> [0]PETSC ERROR: Libraries linked from > >> /lsftmp/g0306332/petsc-2.3.3-p4/lib/atlas3 > >> [0]PETSC ERROR: Configure run at Sat Aug 11 08:25:45 2007 > >> [0]PETSC ERROR: Configure options --with-cc=icc --with-fc=ifort > >> --with-x=0 --download-hypre=1 --download-mumps=1 --download-scalapack=1 > >> --download-blacs=1 --with-debugging=0 > >> --with-blas-lapack-dir=/opt/intel/cmkl/8.1.1/ --with-shared > >> --with-mpi-dir=/lsftmp/g0306332/mpich2/ > >> [0]PETSC ERROR: > >> ------------------------------------------------------------------------ > >> [0]PETSC ERROR: User provided function() line 0 in unknown directory > >> unknown file > >> [unset]: aborting job: > >> application called MPI_Abort(MPI_COMM_WORLD, 59) - process 0 > >> > >> I thought I've delcared A_mat as a global variable so after filling up > >> values using MatCreateSeqAIJWithArrays, MatAssemblyBegin, > >> MatAssemblyEnd, I only need to update the RHS vector. It seems that I'm > >> missing out something. > >> > >> > >> > > > > > > > > -- 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 From zonexo at gmail.com Tue Aug 14 10:35:06 2007 From: zonexo at gmail.com (Ben Tay) Date: Tue, 14 Aug 2007 23:35:06 +0800 Subject: Error when solving eqns with PETSc In-Reply-To: References: <46C1826E.9010302@gmail.com> <46C1C53B.2020804@gmail.com> Message-ID: <46C1CBAA.3020105@gmail.com> Well, I did call MatDestroy, but that's at the very last step when everything's over. It's ok. I'll give to figure out where the problem occurs. Thanks Matthew Knepley wrote: > On 8/14/07, Ben Tay wrote: > >> Oh, I will check up valgrind since I've not used it b4. The original >> converter starts from 1 so I've done a -1 offset. If I call converter, >> MatCreateSeqAIJWithArrays, MatAssemblyBegin,MatAssemblyEnd at every time >> step, it works perfectly and the answers are very close with another >> solver. However, if I only called it once, the error appears the moment >> I try to call KSPSolve. >> >> One qn is if I declare A_mat as a global variable, once I finalise it >> with MatAssemblyBegin,MatAssemblyEnd, it should remain as global >> variable? I don't 've to do any more manipulation. >> > > Are you sure you are not calling MatDestroy? > > Matt > > >> I just 've to update the RHS vector and I can call KSPSolve to get the >> solution. Is that correct? >> >> Thanks >> >> Matthew Knepley wrote: >> >>> Memory is being garbaged somewhere. I suggest using valgrind as it says >>> in the error message. However, I also have a guess. Are you sure that the >>> AIJ arrays that you provided to the constructor are using 0-offset numbering? >>> I suspect that it would be 1-offset for both ia_spar and ja_spar which would >>> cause problems. >>> >>> Matt >>> >>> On 8/14/07, Ben Tay wrote: >>> >>> >>>> Hi, >>>> >>>> I am currently using the following way to solve my poisson eqn >>>> >>>> in global.F (global variables) >>>> >>>> implicit none >>>> >>>> save >>>> >>>> Mat A_mat >>>> Vec xx,b_rhs >>>> KSP ksp >>>> PC pc >>>> PCType ptype >>>> KSPType ksptype >>>> >>>> then they are initialized >>>> >>>> call PetscInitialize(PETSC_NULL_CHARACTER,ierr) >>>> call >>>> MatCreateSeqAIJ(PETSC_COMM_SELF,size_x*size_y,size_x*size_y,13,PETSC_NULL_INTEGER,A_mat,ierr) >>>> call VecCreateSeq(PETSC_COMM_SELF,size_x*size_y,b_rhs,ierr) >>>> call VecDuplicate(b_rhs,xx,ierr) >>>> call KSPCreate(PETSC_COMM_SELF,ksp,ierr) >>>> call VecAssemblyBegin(b_rhs,ierr) >>>> call VecAssemblyEnd(b_rhs,ierr) >>>> call VecAssemblyBegin(xx,ierr) >>>> call VecAssemblyEnd(xx,ierr) >>>> >>>> My original matrix is stored as ITPACK format so I used ellcsr from >>>> SPARSKIT to convert to CSR format and use >>>> >>>> call >>>> ellcsr(total_k,big_A,int_a,total_k,13,A_spar,ja_spar,ia_spar,nzmax,ierr) >>>> ... >>>> call >>>> MatCreateSeqAIJWithArrays(PETSC_COMM_SELF,Ntot,Ntot,ia_spar,ja_spar,A_spar,A_mat,ierr) >>>> call MatAssemblyBegin(A_mat,MAT_FINAL_ASSEMBLY,ierr) >>>> call MatAssemblyEnd(A_mat,MAT_FINAL_ASSEMBLY,ierr) >>>> >>>> to read into PETSc. Then read in the RHS as well >>>> >>>> do k=1,Ntot >>>> II=k-1 >>>> call VecSetValue(b_rhs,II,q_p(k),INSERT_VALUES,ierr) >>>> end do >>>> >>>> Finally the matrix is solved using >>>> >>>> call KSPSolve(ksp,b_rhs,xx,ierr). >>>> >>>> This works but the A_mat matrix is not changing with time. Hence I tried >>>> to call the above sentences only at the 1st time step. However I got >>>> this error when KSPSolve is called: >>>> >>>> [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/petsc-as/documentation/troubleshooting.html#Signal[0]PETSC >>>> ERROR: or try http://valgrind.org on linux or man libgmalloc on Apple to >>>> find memory corruption errors >>>> [0]PETSC ERROR: configure using --with-debugging=yes, recompile, link, >>>> and run >>>> [0]PETSC ERROR: to get more information on the crash. >>>> [0]PETSC ERROR: --------------------- Error Message >>>> ------------------------------------ >>>> [0]PETSC ERROR: Signal received! >>>> [0]PETSC ERROR: >>>> ------------------------------------------------------------------------ >>>> [0]PETSC ERROR: Petsc Release Version 2.3.3, Patch 4, Tue Aug 7 >>>> 17:36:16 CDT 2007 HG revision: ee49636ddd90fb72d14b79fa8180225eb4257c59 >>>> [0]PETSC ERROR: See docs/changes/index.html for recent updates. >>>> [0]PETSC ERROR: See docs/faq.html for hints about trouble shooting. >>>> [0]PETSC ERROR: See docs/index.html for manual pages. >>>> [0]PETSC ERROR: >>>> ------------------------------------------------------------------------ >>>> [0]PETSC ERROR: ./a.out on a atlas3 named atlas3-c01 by g0306332 Tue Aug >>>> 14 18:13:09 2007 >>>> [0]PETSC ERROR: Libraries linked from >>>> /lsftmp/g0306332/petsc-2.3.3-p4/lib/atlas3 >>>> [0]PETSC ERROR: Configure run at Sat Aug 11 08:25:45 2007 >>>> [0]PETSC ERROR: Configure options --with-cc=icc --with-fc=ifort >>>> --with-x=0 --download-hypre=1 --download-mumps=1 --download-scalapack=1 >>>> --download-blacs=1 --with-debugging=0 >>>> --with-blas-lapack-dir=/opt/intel/cmkl/8.1.1/ --with-shared >>>> --with-mpi-dir=/lsftmp/g0306332/mpich2/ >>>> [0]PETSC ERROR: >>>> ------------------------------------------------------------------------ >>>> [0]PETSC ERROR: User provided function() line 0 in unknown directory >>>> unknown file >>>> [unset]: aborting job: >>>> application called MPI_Abort(MPI_COMM_WORLD, 59) - process 0 >>>> >>>> I thought I've delcared A_mat as a global variable so after filling up >>>> values using MatCreateSeqAIJWithArrays, MatAssemblyBegin, >>>> MatAssemblyEnd, I only need to update the RHS vector. It seems that I'm >>>> missing out something. >>>> >>>> >>>> >>>> >>> >>> >> > > > From tkoyama at berkeley.edu Tue Aug 14 10:59:30 2007 From: tkoyama at berkeley.edu (TsuyoshiKoyama(berkeley)) Date: Tue, 14 Aug 2007 17:59:30 +0200 Subject: Question regarding PCMG References: <006501c7dde8$288c4120$96d28481@FUMBOLT> <009901c7de0b$7a2c0420$96d28481@FUMBOLT> Message-ID: <002e01c7de8c$1b2892a0$e555384d@FUMBOLT> With regards to the first problem I had, I was misinterpreting how the function PCApply should work. I had assumed that you could pass in an initial vector x_init to the PCApply by calling PCApply(x, x_init) and have x_init rewritten by the result. Unfortunately this is not the correct way to do things in PETSc and I have figured out a way to use the KSPRichardson context for the stationary solver I have coded as my own PC object. For the second problem, the fix for the first problem will avoid it since I will no longer be trying to use the KSPPreonly but the KSPRichardson. Thank you very much for your help, Mr. Knepley! Sincerely, -Tsuyoshi Koyama ----- Original Message ----- From: "Matthew Knepley" To: Sent: Tuesday, August 14, 2007 3:02 PM Subject: Re: Question regarding PCMG > On 8/13/07, TsuyoshiKoyama(berkeley) wrote: >> As for the second case, the reason I might not select a coarse solver is >> since I >> am trying to solve a Helmholtz equation and the coarse grid solve might >> not >> be >> correct enough to apply. Thus, you may just point out that the coarse >> grid >> should >> be large enough to resolve the so called low frequency error and that if >> you >> do so >> you should still be able to solve direct, but I was curious on testing >> different types >> of operations at the coarsest level. > > The coarse solver can be set to anything you choose. You just extract the > coarse KSP and set the type. > > Thanks, > > Matt > > -- > 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 > From bsmith at mcs.anl.gov Tue Aug 14 12:24:53 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Tue, 14 Aug 2007 12:24:53 -0500 (CDT) Subject: Error when solving eqns with PETSc In-Reply-To: <46C1826E.9010302@gmail.com> References: <46C1826E.9010302@gmail.com> Message-ID: 1) there is not reason to call MatCreateSeqAIJ() at the beginning of the code. 2) MatCreateSeqAIJWithArrays() does NOT copy the array values passed in so if ia_spar,ja_spar,A_spar go out of scope the A_mat is garbage. 3) You can use VecPlaceArray() instead of the loop to set the vector values. Barry On Tue, 14 Aug 2007, Ben Tay wrote: > Hi, > > I am currently using the following way to solve my poisson eqn > > in global.F (global variables) > > implicit none > > save > > Mat A_mat > Vec xx,b_rhs > KSP ksp > PC pc > PCType ptype > KSPType ksptype > > then they are initialized > > call PetscInitialize(PETSC_NULL_CHARACTER,ierr) > call > MatCreateSeqAIJ(PETSC_COMM_SELF,size_x*size_y,size_x*size_y,13,PETSC_NULL_INTEGER,A_mat,ierr) > call VecCreateSeq(PETSC_COMM_SELF,size_x*size_y,b_rhs,ierr) > call VecDuplicate(b_rhs,xx,ierr) > call KSPCreate(PETSC_COMM_SELF,ksp,ierr) > call VecAssemblyBegin(b_rhs,ierr) > call VecAssemblyEnd(b_rhs,ierr) > call VecAssemblyBegin(xx,ierr) > call VecAssemblyEnd(xx,ierr) > > My original matrix is stored as ITPACK format so I used ellcsr from SPARSKIT > to convert to CSR format and use > > call ellcsr(total_k,big_A,int_a,total_k,13,A_spar,ja_spar,ia_spar,nzmax,ierr) > ... > call > MatCreateSeqAIJWithArrays(PETSC_COMM_SELF,Ntot,Ntot,ia_spar,ja_spar,A_spar,A_mat,ierr) > call MatAssemblyBegin(A_mat,MAT_FINAL_ASSEMBLY,ierr) > call MatAssemblyEnd(A_mat,MAT_FINAL_ASSEMBLY,ierr) > > to read into PETSc. Then read in the RHS as well > > do k=1,Ntot > II=k-1 > call VecSetValue(b_rhs,II,q_p(k),INSERT_VALUES,ierr) > end do > > Finally the matrix is solved using > > call KSPSolve(ksp,b_rhs,xx,ierr). > > This works but the A_mat matrix is not changing with time. Hence I tried to > call the above sentences only at the 1st time step. However I got this error > when KSPSolve is called: > > [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/petsc-as/documentation/troubleshooting.html#Signal[0]PETSC > ERROR: or try http://valgrind.org on linux or man libgmalloc on Apple to find > memory corruption errors > [0]PETSC ERROR: configure using --with-debugging=yes, recompile, link, and run > [0]PETSC ERROR: to get more information on the crash. > [0]PETSC ERROR: --------------------- Error Message > ------------------------------------ > [0]PETSC ERROR: Signal received! > [0]PETSC ERROR: > ------------------------------------------------------------------------ > [0]PETSC ERROR: Petsc Release Version 2.3.3, Patch 4, Tue Aug 7 17:36:16 CDT > 2007 HG revision: ee49636ddd90fb72d14b79fa8180225eb4257c59 > [0]PETSC ERROR: See docs/changes/index.html for recent updates. > [0]PETSC ERROR: See docs/faq.html for hints about trouble shooting. > [0]PETSC ERROR: See docs/index.html for manual pages. > [0]PETSC ERROR: > ------------------------------------------------------------------------ > [0]PETSC ERROR: ./a.out on a atlas3 named atlas3-c01 by g0306332 Tue Aug 14 > 18:13:09 2007 > [0]PETSC ERROR: Libraries linked from > /lsftmp/g0306332/petsc-2.3.3-p4/lib/atlas3 > [0]PETSC ERROR: Configure run at Sat Aug 11 08:25:45 2007 > [0]PETSC ERROR: Configure options --with-cc=icc --with-fc=ifort --with-x=0 > --download-hypre=1 --download-mumps=1 --download-scalapack=1 > --download-blacs=1 --with-debugging=0 > --with-blas-lapack-dir=/opt/intel/cmkl/8.1.1/ --with-shared > --with-mpi-dir=/lsftmp/g0306332/mpich2/ > [0]PETSC ERROR: > ------------------------------------------------------------------------ > [0]PETSC ERROR: User provided function() line 0 in unknown directory unknown > file > [unset]: aborting job: > application called MPI_Abort(MPI_COMM_WORLD, 59) - process 0 > > I thought I've delcared A_mat as a global variable so after filling up values > using MatCreateSeqAIJWithArrays, MatAssemblyBegin, MatAssemblyEnd, I only need > to update the RHS vector. It seems that I'm missing out something. > > From dalcinl at gmail.com Tue Aug 14 18:30:43 2007 From: dalcinl at gmail.com (Lisandro Dalcin) Date: Tue, 14 Aug 2007 20:30:43 -0300 Subject: PETSc 2.3.2/2.3.3 'forward' compatibility Message-ID: Dear PETSc users, Perhaps a small set of you know I'm actively developing PETSc for Python (petsc4py). Currently, petsc4py can be built and used with PETSc versions 2.3.2 / 2.3.3 / DEV. As you know, PETSc evolves fast and introduces backward incompatible interface changes in each release. I'm particularly happy with this, as the library is always getting better and better. However, I understand this is annoying for some users. In my particular case, it's easier for me for my own code to be always updated against petsc-dev repository. On the other side, I want petsc4py to be usable with previous PETSc releases, at least the latest official release. Because of all this, I have some compatibility C headers that I think could be usefull for any of you to be able to incrementally update your code in a source file by file basis, being also updated (as your time permits) against petsc-dev repo. That is, you can include these headers in some C source file, update it against petsc-dev interface, check that it compiles fine, and next include my compatibility headers (using macros PETSC_VERSION_XXX will make your like easier) to continue using your code in a production scenario with the latest (or second to latest) official PETSc release. The correct way to use those headers should be #if (PETSC_VERSION_MAJOR == 2 && \ PETSC_VERSION_MINOR == 3 && \ PETSC_VERSION_SUBMINOR == 2 && \ PETSC_VERSION_RELEASE == 1) #include "compat/232/petsc.h" #include "compat/232/petscvec.h" #include "compat/232/petscmat.h" #include "compat/232/petscksp.h" #include "compat/232/petscsnes.h" #include "compat/232/petscts.h" #endif Until now, all this hackery was usable only for my petsc4py needs. But today I factored-out all that code, in order to make it available to any one interested in using or needing something like this. The headers are available in petsc4py SVN at google code, just do $ svn co svn co http://petsc4py.googlecode.com/svn/trunk/petsc/lib/ext/compat or user your browser to navigate the SVN repo http://petsc4py.googlecode.com/svn/trunk/petsc/lib/ext/compat Not all things are expected to work. However, by using this I can build and use my Python wrappers with multiple PETSc versions. In case any of you is interested and want to make comments/suggestions/corrections/additions or even complaints, please mail me directly. Regards, -- Lisandro Dalc?n --------------- Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC) Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC) Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET) PTLC - G?emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 From timothy.stitt at ichec.ie Wed Aug 15 06:49:10 2007 From: timothy.stitt at ichec.ie (Dr. Timothy Stitt) Date: Wed, 15 Aug 2007 12:49:10 +0100 Subject: Sparse Matrix Inversion using PETSc Message-ID: <46C2E836.1090207@ichec.ie> Hi all, I am currently investigating the best way to perform the inversion of a large sparse matrix and came upon the idea of using PETSc as a framework for testing various strategies from direct to iterative methods on my sample matrices. In this setup for an NxN sparse matrix A I would have N rhs's representing the Identity matrix and then solve for X. I wanted to experiment with both parallel and serial strategies ranging from LU Decomposition using SuperLU, MUMPS etc. to iterative methods using GMRES etc. Am I right in thinking that all this can be done in PETSc by setting up a core framework and then varying the solver methods etc? I have looked over the sample KSP Solver codes although they only seem to suggest single vectors for x and b. Can this be changed to accept multiple vectors? Can anyone suggest a sample code that maybe demonstrates the sort of thing I want to achieve...if it is in fact possible. Thanks in advance for any assistance given, Regards, Tim. From aja2111 at columbia.edu Wed Aug 15 08:21:28 2007 From: aja2111 at columbia.edu (Aron Ahmadia) Date: Wed, 15 Aug 2007 09:21:28 -0400 Subject: Sparse Matrix Inversion using PETSc In-Reply-To: <46C2E836.1090207@ichec.ie> References: <46C2E836.1090207@ichec.ie> Message-ID: <37604ab40708150621u29f71147yfe3a7bd17789f671@mail.gmail.com> Dear Tim, It is possible to carry out the explicit inversion of a sparse matrix using the PETSc framework with the methodology you outlined below. I would encourage you to consider Cholesky/LU factorizations of the matrix, which occassionally result in sparser triangular solve times than an explicit inverse-matrix-vector multiply would. As for the correct way to do this, I would start with the fastest methods for multiple right hand sides and reasonably sized matrices, a direct method such as LU. I'm unaware of any functionality in PETSc for handling multiple right hand sides, but PETSc will keep the factorization from a previous direct solve, so A\b2 will be much faster than A\b1. I think the best bet is a naive for loop over each of the vectors to assemble the matrix piece by piece. The PETSc developers may have some more thoughts on this. Good luck, ~Aron On 8/15/07, Dr. Timothy Stitt wrote: > Hi all, > > I am currently investigating the best way to perform the inversion of a > large sparse matrix and came upon the idea of using PETSc as a framework > for testing various strategies from direct to iterative methods on my > sample matrices. In this setup for an NxN sparse matrix A I would have N > rhs's representing the Identity matrix and then solve for X. I wanted to > experiment with both parallel and serial strategies ranging from LU > Decomposition using SuperLU, MUMPS etc. to iterative methods using GMRES > etc. Am I right in thinking that all this can be done in PETSc by > setting up a core framework and then varying the solver methods etc? > > I have looked over the sample KSP Solver codes although they only seem > to suggest single vectors for x and b. Can this be changed to accept > multiple vectors? Can anyone suggest a sample code that maybe > demonstrates the sort of thing I want to achieve...if it is in fact > possible. > > Thanks in advance for any assistance given, > > Regards, > > Tim. > > From hzhang at mcs.anl.gov Wed Aug 15 09:54:48 2007 From: hzhang at mcs.anl.gov (Hong Zhang) Date: Wed, 15 Aug 2007 09:54:48 -0500 (CDT) Subject: Sparse Matrix Inversion using PETSc In-Reply-To: <37604ab40708150621u29f71147yfe3a7bd17789f671@mail.gmail.com> References: <46C2E836.1090207@ichec.ie> <37604ab40708150621u29f71147yfe3a7bd17789f671@mail.gmail.com> Message-ID: Tim, As suggested by Aron, you should do following: 1. MatLUFactorSymbolic(A,...,&Fact); MatLUFactorNumeric(A,&Fact); 2. for (i=0; i Dear Tim, > > It is possible to carry out the explicit inversion of a sparse matrix > using the PETSc framework with the methodology you outlined below. I > would encourage you to consider Cholesky/LU factorizations of the > matrix, which occassionally result in sparser triangular solve times > than an explicit inverse-matrix-vector multiply would. > > As for the correct way to do this, I would start with the fastest > methods for multiple right hand sides and reasonably sized matrices, a > direct method such as LU. I'm unaware of any functionality in PETSc > for handling multiple right hand sides, but PETSc will keep the > factorization from a previous direct solve, so A\b2 will be much > faster than A\b1. I think the best bet is a naive for loop over each > of the vectors to assemble the matrix piece by piece. > > The PETSc developers may have some more thoughts on this. > > Good luck, > ~Aron > > On 8/15/07, Dr. Timothy Stitt wrote: > > Hi all, > > > > I am currently investigating the best way to perform the inversion of a > > large sparse matrix and came upon the idea of using PETSc as a framework > > for testing various strategies from direct to iterative methods on my > > sample matrices. In this setup for an NxN sparse matrix A I would have N > > rhs's representing the Identity matrix and then solve for X. I wanted to > > experiment with both parallel and serial strategies ranging from LU > > Decomposition using SuperLU, MUMPS etc. to iterative methods using GMRES > > etc. Am I right in thinking that all this can be done in PETSc by > > setting up a core framework and then varying the solver methods etc? > > > > I have looked over the sample KSP Solver codes although they only seem > > to suggest single vectors for x and b. Can this be changed to accept > > multiple vectors? Can anyone suggest a sample code that maybe > > demonstrates the sort of thing I want to achieve...if it is in fact > > possible. > > > > Thanks in advance for any assistance given, > > > > Regards, > > > > Tim. > > > > > > From bsmith at mcs.anl.gov Wed Aug 15 11:50:06 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Wed, 15 Aug 2007 11:50:06 -0500 (CDT) Subject: Sparse Matrix Inversion using PETSc In-Reply-To: <46C2E836.1090207@ichec.ie> References: <46C2E836.1090207@ichec.ie> Message-ID: Tim, How large are you matrices? Barry On Wed, 15 Aug 2007, Dr. Timothy Stitt wrote: > Hi all, > > I am currently investigating the best way to perform the inversion of a large > sparse matrix and came upon the idea of using PETSc as a framework for testing > various strategies from direct to iterative methods on my sample matrices. In > this setup for an NxN sparse matrix A I would have N rhs's representing the > Identity matrix and then solve for X. I wanted to experiment with both > parallel and serial strategies ranging from LU Decomposition using SuperLU, > MUMPS etc. to iterative methods using GMRES etc. Am I right in thinking that > all this can be done in PETSc by setting up a core framework and then varying > the solver methods etc? > > I have looked over the sample KSP Solver codes although they only seem to > suggest single vectors for x and b. Can this be changed to accept multiple > vectors? Can anyone suggest a sample code that maybe demonstrates the sort of > thing I want to achieve...if it is in fact possible. > > Thanks in advance for any assistance given, > > Regards, > > Tim. > > From timothy.stitt at ichec.ie Wed Aug 15 13:27:09 2007 From: timothy.stitt at ichec.ie (Dr. Timothy Stitt) Date: Wed, 15 Aug 2007 19:27:09 +0100 Subject: Sparse Matrix Inversion using PETSc In-Reply-To: References: <46C2E836.1090207@ichec.ie> Message-ID: <46C3457D.9020906@ichec.ie> Firstly, many thanks to everyone who has replied with information. It has been very useful indeed. Much appreciated. Barry, in this case the sparse matrices would be of ~ order 5000x5000. They could grow in size but this is the sample matrices I am working with right now. We would love a scalable approach so we can deal with more interesting problems and hence larger sparse matrices. Hope that helps. Many thanks again. Tim. Barry Smith wrote: > Tim, > > How large are you matrices? > > Barry > > > On Wed, 15 Aug 2007, Dr. Timothy Stitt wrote: > > >> Hi all, >> >> I am currently investigating the best way to perform the inversion of a large >> sparse matrix and came upon the idea of using PETSc as a framework for testing >> various strategies from direct to iterative methods on my sample matrices. In >> this setup for an NxN sparse matrix A I would have N rhs's representing the >> Identity matrix and then solve for X. I wanted to experiment with both >> parallel and serial strategies ranging from LU Decomposition using SuperLU, >> MUMPS etc. to iterative methods using GMRES etc. Am I right in thinking that >> all this can be done in PETSc by setting up a core framework and then varying >> the solver methods etc? >> >> I have looked over the sample KSP Solver codes although they only seem to >> suggest single vectors for x and b. Can this be changed to accept multiple >> vectors? Can anyone suggest a sample code that maybe demonstrates the sort of >> thing I want to achieve...if it is in fact possible. >> >> Thanks in advance for any assistance given, >> >> Regards, >> >> Tim. >> >> >> > > From bsmith at mcs.anl.gov Wed Aug 15 16:01:12 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Wed, 15 Aug 2007 16:01:12 -0500 (CDT) Subject: Sparse Matrix Inversion using PETSc In-Reply-To: <46C3457D.9020906@ichec.ie> References: <46C2E836.1090207@ichec.ie> <46C3457D.9020906@ichec.ie> Message-ID: Tim, A dense matrix with 100,000 rows and columns requires 80 gigabytes to store the result. 1,000,000 rows and columns requires 8,000 gigabytes. With this range of sizes I wouldn't even consider iterative solvers and would only use direct solvers. I would divide MPI_COMM_WORLD into N subcommunicators of size n each and have each subcommunicator work on a collection of columns of the inverse. For matrix sizes of 5,000 to say 20,000? I'd make n be 1 and just use PETSc's native LU solver and use MatMatSolve() and not use KSP at all. For larger matrices you may be able to use an n of 2 to possibly as large as 8? Now my numerical analysis training :-) requires me to state the following. It is completely insane to compute the EXPLICIT inverse of large sparse matrices since they are dense. Please tell me what the inverses are used for and perhaps we can come up with an approach the does not require computing them. Barry On Wed, 15 Aug 2007, Dr. Timothy Stitt wrote: > Firstly, many thanks to everyone who has replied with information. It has been > very useful indeed. Much appreciated. > > Barry, in this case the sparse matrices would be of ~ order 5000x5000. They > could grow in size but this is the sample matrices I am working with right > now. We would love a scalable approach so we can deal with more interesting > problems and hence larger sparse matrices. Hope that helps. > > Many thanks again. > > Tim. > > Barry Smith wrote: > > Tim, > > > > How large are you matrices? > > > > Barry > > > > > > On Wed, 15 Aug 2007, Dr. Timothy Stitt wrote: > > > > > > > Hi all, > > > > > > I am currently investigating the best way to perform the inversion of a > > > large > > > sparse matrix and came upon the idea of using PETSc as a framework for > > > testing > > > various strategies from direct to iterative methods on my sample matrices. > > > In > > > this setup for an NxN sparse matrix A I would have N rhs's representing > > > the > > > Identity matrix and then solve for X. I wanted to experiment with both > > > parallel and serial strategies ranging from LU Decomposition using > > > SuperLU, > > > MUMPS etc. to iterative methods using GMRES etc. Am I right in thinking > > > that > > > all this can be done in PETSc by setting up a core framework and then > > > varying > > > the solver methods etc? > > > > > > I have looked over the sample KSP Solver codes although they only seem to > > > suggest single vectors for x and b. Can this be changed to accept multiple > > > vectors? Can anyone suggest a sample code that maybe demonstrates the sort > > > of > > > thing I want to achieve...if it is in fact possible. > > > > > > Thanks in advance for any assistance given, > > > > > > Regards, > > > > > > Tim. > > > > > > > > > > > > > > > From timothy.stitt at ichec.ie Wed Aug 15 16:23:50 2007 From: timothy.stitt at ichec.ie (Dr. Timothy Stitt) Date: Wed, 15 Aug 2007 22:23:50 +0100 Subject: Sparse Matrix Inversion using PETSc In-Reply-To: References: <46C2E836.1090207@ichec.ie> <46C3457D.9020906@ichec.ie> Message-ID: <46C36EE6.2070308@ichec.ie> Barry, The group I am working with are calculating what they call retarded Green's Functions of the form: G_r=(E-H)^(-1) where (E-H) is a matrix. Apparently they say there is no way to avoid this calculation. Tim. Barry Smith wrote: > Tim, > > A dense matrix with 100,000 rows and columns requires 80 gigabytes to store > the result. 1,000,000 rows and columns requires 8,000 gigabytes. > > With this range of sizes I wouldn't even consider iterative solvers and > would only use direct solvers. I would divide MPI_COMM_WORLD into N > subcommunicators of size n each and have each subcommunicator work on a > collection of columns of the inverse. For matrix sizes of 5,000 to say 20,000? > I'd make n be 1 and just use PETSc's native LU solver and use MatMatSolve() > and not use KSP at all. For larger matrices you may be able to use an n of 2 > to possibly as large as 8? > > Now my numerical analysis training :-) requires me to state the following. > It is completely insane to compute the EXPLICIT inverse of large sparse matrices > since they are dense. Please tell me what the inverses are used for and perhaps > we can come up with an approach the does not require computing them. > > Barry > > > > On Wed, 15 Aug 2007, Dr. Timothy Stitt wrote: > > >> Firstly, many thanks to everyone who has replied with information. It has been >> very useful indeed. Much appreciated. >> >> Barry, in this case the sparse matrices would be of ~ order 5000x5000. They >> could grow in size but this is the sample matrices I am working with right >> now. We would love a scalable approach so we can deal with more interesting >> problems and hence larger sparse matrices. Hope that helps. >> >> Many thanks again. >> >> Tim. >> >> Barry Smith wrote: >> >>> Tim, >>> >>> How large are you matrices? >>> >>> Barry >>> >>> >>> On Wed, 15 Aug 2007, Dr. Timothy Stitt wrote: >>> >>> >>> >>>> Hi all, >>>> >>>> I am currently investigating the best way to perform the inversion of a >>>> large >>>> sparse matrix and came upon the idea of using PETSc as a framework for >>>> testing >>>> various strategies from direct to iterative methods on my sample matrices. >>>> In >>>> this setup for an NxN sparse matrix A I would have N rhs's representing >>>> the >>>> Identity matrix and then solve for X. I wanted to experiment with both >>>> parallel and serial strategies ranging from LU Decomposition using >>>> SuperLU, >>>> MUMPS etc. to iterative methods using GMRES etc. Am I right in thinking >>>> that >>>> all this can be done in PETSc by setting up a core framework and then >>>> varying >>>> the solver methods etc? >>>> >>>> I have looked over the sample KSP Solver codes although they only seem to >>>> suggest single vectors for x and b. Can this be changed to accept multiple >>>> vectors? Can anyone suggest a sample code that maybe demonstrates the sort >>>> of >>>> thing I want to achieve...if it is in fact possible. >>>> >>>> Thanks in advance for any assistance given, >>>> >>>> Regards, >>>> >>>> Tim. >>>> >>>> >>>> >>>> >>> >>> >> > > From bsmith at mcs.anl.gov Wed Aug 15 16:29:33 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Wed, 15 Aug 2007 16:29:33 -0500 (CDT) Subject: Sparse Matrix Inversion using PETSc In-Reply-To: <46C36EE6.2070308@ichec.ie> References: <46C2E836.1090207@ichec.ie> <46C3457D.9020906@ichec.ie> <46C36EE6.2070308@ichec.ie> Message-ID: Tim, Do you know what the G_r is then used for? Thanks Barry On Wed, 15 Aug 2007, Dr. Timothy Stitt wrote: > Barry, > > The group I am working with are calculating what they call retarded Green's > Functions of the form: > > G_r=(E-H)^(-1) > > where (E-H) is a matrix. Apparently they say there is no way to avoid this > calculation. > > Tim. > > Barry Smith wrote: > > Tim, > > > > A dense matrix with 100,000 rows and columns requires 80 gigabytes to > > store > > the result. 1,000,000 rows and columns requires 8,000 gigabytes. > > With this range of sizes I wouldn't even consider iterative solvers and > > would only use direct solvers. I would divide MPI_COMM_WORLD into N > > subcommunicators of size n each and have each subcommunicator work on a > > collection of columns of the inverse. For matrix sizes of 5,000 to say > > 20,000? > > I'd make n be 1 and just use PETSc's native LU solver and use MatMatSolve() > > and not use KSP at all. For larger matrices you may be able to use an n of 2 > > to possibly as large as 8? > > > > Now my numerical analysis training :-) requires me to state the > > following. > > It is completely insane to compute the EXPLICIT inverse of large sparse > > matrices > > since they are dense. Please tell me what the inverses are used for and > > perhaps > > we can come up with an approach the does not require computing them. > > > > Barry > > > > > > > > On Wed, 15 Aug 2007, Dr. Timothy Stitt wrote: > > > > > > > Firstly, many thanks to everyone who has replied with information. It has > > > been > > > very useful indeed. Much appreciated. > > > > > > Barry, in this case the sparse matrices would be of ~ order 5000x5000. > > > They > > > could grow in size but this is the sample matrices I am working with right > > > now. We would love a scalable approach so we can deal with more > > > interesting > > > problems and hence larger sparse matrices. Hope that helps. > > > > > > Many thanks again. > > > > > > Tim. > > > > > > Barry Smith wrote: > > > > > > > Tim, > > > > > > > > How large are you matrices? > > > > > > > > Barry > > > > > > > > > > > > On Wed, 15 Aug 2007, Dr. Timothy Stitt wrote: > > > > > > > > > > > > > Hi all, > > > > > > > > > > I am currently investigating the best way to perform the inversion of > > > > > a > > > > > large > > > > > sparse matrix and came upon the idea of using PETSc as a framework for > > > > > testing > > > > > various strategies from direct to iterative methods on my sample > > > > > matrices. > > > > > In > > > > > this setup for an NxN sparse matrix A I would have N rhs's > > > > > representing > > > > > the > > > > > Identity matrix and then solve for X. I wanted to experiment with both > > > > > parallel and serial strategies ranging from LU Decomposition using > > > > > SuperLU, > > > > > MUMPS etc. to iterative methods using GMRES etc. Am I right in > > > > > thinking > > > > > that > > > > > all this can be done in PETSc by setting up a core framework and then > > > > > varying > > > > > the solver methods etc? > > > > > > > > > > I have looked over the sample KSP Solver codes although they only seem > > > > > to > > > > > suggest single vectors for x and b. Can this be changed to accept > > > > > multiple > > > > > vectors? Can anyone suggest a sample code that maybe demonstrates the > > > > > sort > > > > > of > > > > > thing I want to achieve...if it is in fact possible. > > > > > > > > > > Thanks in advance for any assistance given, > > > > > > > > > > Regards, > > > > > > > > > > Tim. > > > > > > > > > > > > > > > > > > > > > > > > > > > > From zonexo at gmail.com Wed Aug 15 20:46:28 2007 From: zonexo at gmail.com (Ben Tay) Date: Thu, 16 Aug 2007 09:46:28 +0800 Subject: Using -pctype mg -pcmgtype PC_MG_MULTIPLICATIVE Message-ID: <46C3AC74.6030805@gmail.com> Hi, I found that there's a multigrid option in the manual which can be used by adding -pctype mg -pcmgtype PC_MG_MULTIPLICATIVE. However, it seems that I am actually just using LU since with or without this option, I got exactly the same answer. Am I using multigrid the wrong way? Thanks From knepley at gmail.com Wed Aug 15 20:55:07 2007 From: knepley at gmail.com (Matthew Knepley) Date: Wed, 15 Aug 2007 20:55:07 -0500 Subject: Using -pctype mg -pcmgtype PC_MG_MULTIPLICATIVE In-Reply-To: <46C3AC74.6030805@gmail.com> References: <46C3AC74.6030805@gmail.com> Message-ID: The multigrid PC needs information about the grid and discretization. If you cannot provide this, use AMG through Hypre or ML. Or if you have a structured grid, consider using DMMG. Thanks, Matt On 8/15/07, Ben Tay wrote: > Hi, > > I found that there's a multigrid option in the manual which can be used > by adding -pctype mg -pcmgtype PC_MG_MULTIPLICATIVE. > > However, it seems that I am actually just using LU since with or without > this option, I got exactly the same answer. Am I using multigrid the > wrong way? > > Thanks > > -- 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 From hzhang at mcs.anl.gov Wed Aug 15 21:02:28 2007 From: hzhang at mcs.anl.gov (Hong Zhang) Date: Wed, 15 Aug 2007 21:02:28 -0500 (CDT) Subject: Using -pctype mg -pcmgtype PC_MG_MULTIPLICATIVE In-Reply-To: <46C3AC74.6030805@gmail.com> References: <46C3AC74.6030805@gmail.com> Message-ID: On Thu, 16 Aug 2007, Ben Tay wrote: > Hi, > > I found that there's a multigrid option in the manual which can be used > by adding -pctype mg -pcmgtype PC_MG_MULTIPLICATIVE. Should be '-pc_type mg -pc_mg_type MULTIPLICATIVE' Use '-ksp_view' or '-snes_view' to check which PC and parameters are being used. Hong > > However, it seems that I am actually just using LU since with or without > this option, I got exactly the same answer. Am I using multigrid the > wrong way? > > Thanks > > From zonexo at gmail.com Thu Aug 16 04:10:28 2007 From: zonexo at gmail.com (Ben Tay) Date: Thu, 16 Aug 2007 17:10:28 +0800 Subject: Using -pctype mg -pcmgtype PC_MG_MULTIPLICATIVE In-Reply-To: References: <46C3AC74.6030805@gmail.com> Message-ID: <46C41484.8050005@gmail.com> Hi, Can you tell me what's the option to download and use ML? Is it --download-ml=1? Also what is the option if I want to use ML? Thank you. Matthew Knepley wrote: > The multigrid PC needs information about the grid and discretization. If you > cannot provide this, use AMG through Hypre or ML. Or if you have a > structured grid, consider using DMMG. > > Thanks, > > Matt > > On 8/15/07, Ben Tay wrote: > >> Hi, >> >> I found that there's a multigrid option in the manual which can be used >> by adding -pctype mg -pcmgtype PC_MG_MULTIPLICATIVE. >> >> However, it seems that I am actually just using LU since with or without >> this option, I got exactly the same answer. Am I using multigrid the >> wrong way? >> >> Thanks >> >> >> > > > From zonexo at gmail.com Thu Aug 16 05:24:29 2007 From: zonexo at gmail.com (Ben Tay) Date: Thu, 16 Aug 2007 18:24:29 +0800 Subject: Using -pctype mg -pcmgtype PC_MG_MULTIPLICATIVE In-Reply-To: References: <46C3AC74.6030805@gmail.com> Message-ID: <46C425DD.6000904@gmail.com> Btw, is the file to download ftp://ftp.mcs.anl.gov/pub/petsc/externalpackages/ml-5.0.tar.gz? Thanks Matthew Knepley wrote: > The multigrid PC needs information about the grid and discretization. If you > cannot provide this, use AMG through Hypre or ML. Or if you have a > structured grid, consider using DMMG. > > Thanks, > > Matt > > On 8/15/07, Ben Tay wrote: > >> Hi, >> >> I found that there's a multigrid option in the manual which can be used >> by adding -pctype mg -pcmgtype PC_MG_MULTIPLICATIVE. >> >> However, it seems that I am actually just using LU since with or without >> this option, I got exactly the same answer. Am I using multigrid the >> wrong way? >> >> Thanks >> >> >> > > > From timothy.stitt at ichec.ie Thu Aug 16 07:29:38 2007 From: timothy.stitt at ichec.ie (Dr. Timothy Stitt) Date: Thu, 16 Aug 2007 13:29:38 +0100 Subject: Sparse Matrix Inversion using PETSc In-Reply-To: References: <46C2E836.1090207@ichec.ie> <46C3457D.9020906@ichec.ie> <46C36EE6.2070308@ichec.ie> Message-ID: <46C44332.4060101@ichec.ie> Barry, If it helps I was speaking to some of the project members and they mention that they actually only need the first M columns of the inverse. The equations can also be rewritten so that they only require the last M columns also or first/last M rows. I believe the retarded Green's Function forms an integral. For the integral in the real plane (which is repeated for thousands of energy points and hence requires thousands of inversions) they need only the first few columns as described above. I would be grateful if you could suggest a possible approach based on this extra information. I much appreciate your comments already. Thanks, Tim. Barry Smith wrote: > Tim, > > Do you know what the G_r is then used for? > > Thanks > > Barry > > > On Wed, 15 Aug 2007, Dr. Timothy Stitt wrote: > > >> Barry, >> >> The group I am working with are calculating what they call retarded Green's >> Functions of the form: >> >> G_r=(E-H)^(-1) >> >> where (E-H) is a matrix. Apparently they say there is no way to avoid this >> calculation. >> >> Tim. >> >> Barry Smith wrote: >> >>> Tim, >>> >>> A dense matrix with 100,000 rows and columns requires 80 gigabytes to >>> store >>> the result. 1,000,000 rows and columns requires 8,000 gigabytes. >>> With this range of sizes I wouldn't even consider iterative solvers and >>> would only use direct solvers. I would divide MPI_COMM_WORLD into N >>> subcommunicators of size n each and have each subcommunicator work on a >>> collection of columns of the inverse. For matrix sizes of 5,000 to say >>> 20,000? >>> I'd make n be 1 and just use PETSc's native LU solver and use MatMatSolve() >>> and not use KSP at all. For larger matrices you may be able to use an n of 2 >>> to possibly as large as 8? >>> >>> Now my numerical analysis training :-) requires me to state the >>> following. >>> It is completely insane to compute the EXPLICIT inverse of large sparse >>> matrices >>> since they are dense. Please tell me what the inverses are used for and >>> perhaps >>> we can come up with an approach the does not require computing them. >>> >>> Barry >>> >>> >>> >>> On Wed, 15 Aug 2007, Dr. Timothy Stitt wrote: >>> >>> >>> >>>> Firstly, many thanks to everyone who has replied with information. It has >>>> been >>>> very useful indeed. Much appreciated. >>>> >>>> Barry, in this case the sparse matrices would be of ~ order 5000x5000. >>>> They >>>> could grow in size but this is the sample matrices I am working with right >>>> now. We would love a scalable approach so we can deal with more >>>> interesting >>>> problems and hence larger sparse matrices. Hope that helps. >>>> >>>> Many thanks again. >>>> >>>> Tim. >>>> >>>> Barry Smith wrote: >>>> >>>> >>>>> Tim, >>>>> >>>>> How large are you matrices? >>>>> >>>>> Barry >>>>> >>>>> >>>>> On Wed, 15 Aug 2007, Dr. Timothy Stitt wrote: >>>>> >>>>> >>>>> >>>>>> Hi all, >>>>>> >>>>>> I am currently investigating the best way to perform the inversion of >>>>>> a >>>>>> large >>>>>> sparse matrix and came upon the idea of using PETSc as a framework for >>>>>> testing >>>>>> various strategies from direct to iterative methods on my sample >>>>>> matrices. >>>>>> In >>>>>> this setup for an NxN sparse matrix A I would have N rhs's >>>>>> representing >>>>>> the >>>>>> Identity matrix and then solve for X. I wanted to experiment with both >>>>>> parallel and serial strategies ranging from LU Decomposition using >>>>>> SuperLU, >>>>>> MUMPS etc. to iterative methods using GMRES etc. Am I right in >>>>>> thinking >>>>>> that >>>>>> all this can be done in PETSc by setting up a core framework and then >>>>>> varying >>>>>> the solver methods etc? >>>>>> >>>>>> I have looked over the sample KSP Solver codes although they only seem >>>>>> to >>>>>> suggest single vectors for x and b. Can this be changed to accept >>>>>> multiple >>>>>> vectors? Can anyone suggest a sample code that maybe demonstrates the >>>>>> sort >>>>>> of >>>>>> thing I want to achieve...if it is in fact possible. >>>>>> >>>>>> Thanks in advance for any assistance given, >>>>>> >>>>>> Regards, >>>>>> >>>>>> Tim. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > > -- Dr. Timothy Stitt HPC Application Consultant - ICHEC (www.ichec.ie) Dublin Institute for Advanced Studies 5 Merrion Square - Dublin 2 - Ireland +353-1-6621333 (tel) / +353-1-6621477 (fax) / +353-874195427 (mobile) From hzhang at mcs.anl.gov Thu Aug 16 08:54:19 2007 From: hzhang at mcs.anl.gov (Hong Zhang) Date: Thu, 16 Aug 2007 08:54:19 -0500 (CDT) Subject: Using -pctype mg -pcmgtype PC_MG_MULTIPLICATIVE In-Reply-To: <46C425DD.6000904@gmail.com> References: <46C3AC74.6030805@gmail.com> <46C425DD.6000904@gmail.com> Message-ID: On Thu, 16 Aug 2007, Ben Tay wrote: > Btw, is the file to download > ftp://ftp.mcs.anl.gov/pub/petsc/externalpackages/ml-5.0.tar.gz? Yes. You can simply use '--download-ml=1' during configuration. Run your program with '-help' to see all options for using ml. See ~petsc/src/ksp/ksp/examples/tests/ex26.c on how to use ML. Hong > > Thanks > > Matthew Knepley wrote: > > The multigrid PC needs information about the grid and discretization. If you > > cannot provide this, use AMG through Hypre or ML. Or if you have a > > structured grid, consider using DMMG. > > > > Thanks, > > > > Matt > > > > On 8/15/07, Ben Tay wrote: > > > >> Hi, > >> > >> I found that there's a multigrid option in the manual which can be used > >> by adding -pctype mg -pcmgtype PC_MG_MULTIPLICATIVE. > >> > >> However, it seems that I am actually just using LU since with or without > >> this option, I got exactly the same answer. Am I using multigrid the > >> wrong way? > >> > >> Thanks > >> > >> > >> > > > > > > > > From vishy at mail.rsise.anu.edu.au Thu Aug 16 06:00:26 2007 From: vishy at mail.rsise.anu.edu.au (S V N Vishwanathan) Date: Thu, 16 Aug 2007 21:00:26 +1000 Subject: PETSc 2.3.2/2.3.3 'forward' compatibility In-Reply-To: References: Message-ID: Hi! > Perhaps a small set of you know I'm actively developing PETSc for > Python (petsc4py). Currently, petsc4py can be built and used with > PETSc versions 2.3.2 / 2.3.3 / DEV. As you know, PETSc evolves fast > and introduces backward incompatible interface changes in each > release. I'm particularly happy with this, as the library is always > getting better and better. We would also like to take this opportunity to promote our python bindings for PETSc as a part of the Elefant (http://elefant.developer.nicta.com.au) project. Unlike other approaches which "hand-code" the bindings our process is completely automated and build on the fly from the latest and greatest PETSc sources. We are more than happy to contribute it back to the PETSc source tree if there is interest. vishy ----- Sale promotions don't. From bsmith at mcs.anl.gov Thu Aug 16 09:43:15 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Thu, 16 Aug 2007 09:43:15 -0500 (CDT) Subject: PETSc 2.3.2/2.3.3 'forward' compatibility In-Reply-To: References: Message-ID: With the next release we can likely try providing a --download- option for both of these packages (and other similar ones). Barry On Thu, 16 Aug 2007, S V N Vishwanathan wrote: > Hi! > > > Perhaps a small set of you know I'm actively developing PETSc for > > Python (petsc4py). Currently, petsc4py can be built and used with > > PETSc versions 2.3.2 / 2.3.3 / DEV. As you know, PETSc evolves fast > > and introduces backward incompatible interface changes in each > > release. I'm particularly happy with this, as the library is always > > getting better and better. > > We would also like to take this opportunity to promote our python > bindings for PETSc as a part of the Elefant > (http://elefant.developer.nicta.com.au) project. Unlike other approaches > which "hand-code" the bindings our process is completely automated and > build on the fly from the latest and greatest PETSc sources. We are more > than happy to contribute it back to the PETSc source tree if there is > interest. > > vishy > > > ----- > Sale promotions don't. > > From bsmith at mcs.anl.gov Thu Aug 16 09:46:28 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Thu, 16 Aug 2007 09:46:28 -0500 (CDT) Subject: Sparse Matrix Inversion using PETSc In-Reply-To: <46C44332.4060101@ichec.ie> References: <46C2E836.1090207@ichec.ie> <46C3457D.9020906@ichec.ie> <46C36EE6.2070308@ichec.ie> <46C44332.4060101@ichec.ie> Message-ID: Tim, Ok, this is a bit more reasonable :-) The proceedure I discussed previously is the same. Just use for the right hand side matrix a dense vector with M columns whose entries are the first M columns of the identity, then solve with it. Barry On Thu, 16 Aug 2007, Dr. Timothy Stitt wrote: > Barry, > > If it helps I was speaking to some of the project members and they mention > that they actually only need the first M columns of the inverse. The equations > can also be rewritten so that they only require the last M columns also or > first/last M rows. I believe the retarded Green's Function forms an integral. > For the integral in the real plane (which is repeated for thousands of energy > points and hence requires thousands of inversions) they need only the first > few columns as described above. > > I would be grateful if you could suggest a possible approach based on this > extra information. I much appreciate your comments already. > > Thanks, > > Tim. > > Barry Smith wrote: > > Tim, > > > > Do you know what the G_r is then used for? > > > > Thanks > > > > Barry > > > > > > On Wed, 15 Aug 2007, Dr. Timothy Stitt wrote: > > > > > > > Barry, > > > > > > The group I am working with are calculating what they call retarded > > > Green's > > > Functions of the form: > > > > > > G_r=(E-H)^(-1) > > > > > > where (E-H) is a matrix. Apparently they say there is no way to avoid this > > > calculation. > > > > > > Tim. > > > > > > Barry Smith wrote: > > > > > > > Tim, > > > > > > > > A dense matrix with 100,000 rows and columns requires 80 gigabytes > > > > to > > > > store > > > > the result. 1,000,000 rows and columns requires 8,000 gigabytes. With > > > > this range of sizes I wouldn't even consider iterative solvers and > > > > would only use direct solvers. I would divide MPI_COMM_WORLD into N > > > > subcommunicators of size n each and have each subcommunicator work on a > > > > collection of columns of the inverse. For matrix sizes of 5,000 to say > > > > 20,000? > > > > I'd make n be 1 and just use PETSc's native LU solver and use > > > > MatMatSolve() > > > > and not use KSP at all. For larger matrices you may be able to use an n > > > > of 2 > > > > to possibly as large as 8? > > > > > > > > Now my numerical analysis training :-) requires me to state the > > > > following. > > > > It is completely insane to compute the EXPLICIT inverse of large sparse > > > > matrices > > > > since they are dense. Please tell me what the inverses are used for and > > > > perhaps > > > > we can come up with an approach the does not require computing them. > > > > > > > > Barry > > > > > > > > > > > > > > > > On Wed, 15 Aug 2007, Dr. Timothy Stitt wrote: > > > > > > > > > > > > > Firstly, many thanks to everyone who has replied with information. It > > > > > has > > > > > been > > > > > very useful indeed. Much appreciated. > > > > > > > > > > Barry, in this case the sparse matrices would be of ~ order 5000x5000. > > > > > They > > > > > could grow in size but this is the sample matrices I am working with > > > > > right > > > > > now. We would love a scalable approach so we can deal with more > > > > > interesting > > > > > problems and hence larger sparse matrices. Hope that helps. > > > > > > > > > > Many thanks again. > > > > > > > > > > Tim. > > > > > > > > > > Barry Smith wrote: > > > > > > > > > > > Tim, > > > > > > > > > > > > How large are you matrices? > > > > > > > > > > > > Barry > > > > > > > > > > > > > > > > > > On Wed, 15 Aug 2007, Dr. Timothy Stitt wrote: > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > I am currently investigating the best way to perform the inversion > > > > > > > of > > > > > > > a > > > > > > > large > > > > > > > sparse matrix and came upon the idea of using PETSc as a framework > > > > > > > for > > > > > > > testing > > > > > > > various strategies from direct to iterative methods on my sample > > > > > > > matrices. > > > > > > > In > > > > > > > this setup for an NxN sparse matrix A I would have N rhs's > > > > > > > representing > > > > > > > the > > > > > > > Identity matrix and then solve for X. I wanted to experiment with > > > > > > > both > > > > > > > parallel and serial strategies ranging from LU Decomposition using > > > > > > > SuperLU, > > > > > > > MUMPS etc. to iterative methods using GMRES etc. Am I right in > > > > > > > thinking > > > > > > > that > > > > > > > all this can be done in PETSc by setting up a core framework and > > > > > > > then > > > > > > > varying > > > > > > > the solver methods etc? > > > > > > > > > > > > > > I have looked over the sample KSP Solver codes although they only > > > > > > > seem > > > > > > > to > > > > > > > suggest single vectors for x and b. Can this be changed to accept > > > > > > > multiple > > > > > > > vectors? Can anyone suggest a sample code that maybe demonstrates > > > > > > > the > > > > > > > sort > > > > > > > of > > > > > > > thing I want to achieve...if it is in fact possible. > > > > > > > > > > > > > > Thanks in advance for any assistance given, > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Tim. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From timothy.stitt at ichec.ie Thu Aug 16 10:55:10 2007 From: timothy.stitt at ichec.ie (Dr. Timothy Stitt) Date: Thu, 16 Aug 2007 16:55:10 +0100 Subject: Sparse Matrix Inversion using PETSc In-Reply-To: References: <46C2E836.1090207@ichec.ie> <46C3457D.9020906@ichec.ie> <46C36EE6.2070308@ichec.ie> <46C44332.4060101@ichec.ie> Message-ID: <46C4735E.4040507@ichec.ie> Perfect...thanks Barry. Barry Smith wrote: > Tim, > > Ok, this is a bit more reasonable :-) > > The proceedure I discussed previously is the same. Just > use for the right hand side matrix a dense vector with > M columns whose entries are the first M columns of the identity, > then solve with it. > > Barry > > > On Thu, 16 Aug 2007, Dr. Timothy Stitt wrote: > > >> Barry, >> >> If it helps I was speaking to some of the project members and they mention >> that they actually only need the first M columns of the inverse. The equations >> can also be rewritten so that they only require the last M columns also or >> first/last M rows. I believe the retarded Green's Function forms an integral. >> For the integral in the real plane (which is repeated for thousands of energy >> points and hence requires thousands of inversions) they need only the first >> few columns as described above. >> >> I would be grateful if you could suggest a possible approach based on this >> extra information. I much appreciate your comments already. >> >> Thanks, >> >> Tim. >> >> Barry Smith wrote: >> >>> Tim, >>> >>> Do you know what the G_r is then used for? >>> >>> Thanks >>> >>> Barry >>> >>> >>> On Wed, 15 Aug 2007, Dr. Timothy Stitt wrote: >>> >>> >>> >>>> Barry, >>>> >>>> The group I am working with are calculating what they call retarded >>>> Green's >>>> Functions of the form: >>>> >>>> G_r=(E-H)^(-1) >>>> >>>> where (E-H) is a matrix. Apparently they say there is no way to avoid this >>>> calculation. >>>> >>>> Tim. >>>> >>>> Barry Smith wrote: >>>> >>>> >>>>> Tim, >>>>> >>>>> A dense matrix with 100,000 rows and columns requires 80 gigabytes >>>>> to >>>>> store >>>>> the result. 1,000,000 rows and columns requires 8,000 gigabytes. With >>>>> this range of sizes I wouldn't even consider iterative solvers and >>>>> would only use direct solvers. I would divide MPI_COMM_WORLD into N >>>>> subcommunicators of size n each and have each subcommunicator work on a >>>>> collection of columns of the inverse. For matrix sizes of 5,000 to say >>>>> 20,000? >>>>> I'd make n be 1 and just use PETSc's native LU solver and use >>>>> MatMatSolve() >>>>> and not use KSP at all. For larger matrices you may be able to use an n >>>>> of 2 >>>>> to possibly as large as 8? >>>>> >>>>> Now my numerical analysis training :-) requires me to state the >>>>> following. >>>>> It is completely insane to compute the EXPLICIT inverse of large sparse >>>>> matrices >>>>> since they are dense. Please tell me what the inverses are used for and >>>>> perhaps >>>>> we can come up with an approach the does not require computing them. >>>>> >>>>> Barry >>>>> >>>>> >>>>> >>>>> On Wed, 15 Aug 2007, Dr. Timothy Stitt wrote: >>>>> >>>>> >>>>> >>>>>> Firstly, many thanks to everyone who has replied with information. It >>>>>> has >>>>>> been >>>>>> very useful indeed. Much appreciated. >>>>>> >>>>>> Barry, in this case the sparse matrices would be of ~ order 5000x5000. >>>>>> They >>>>>> could grow in size but this is the sample matrices I am working with >>>>>> right >>>>>> now. We would love a scalable approach so we can deal with more >>>>>> interesting >>>>>> problems and hence larger sparse matrices. Hope that helps. >>>>>> >>>>>> Many thanks again. >>>>>> >>>>>> Tim. >>>>>> >>>>>> Barry Smith wrote: >>>>>> >>>>>> >>>>>>> Tim, >>>>>>> >>>>>>> How large are you matrices? >>>>>>> >>>>>>> Barry >>>>>>> >>>>>>> >>>>>>> On Wed, 15 Aug 2007, Dr. Timothy Stitt wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I am currently investigating the best way to perform the inversion >>>>>>>> of >>>>>>>> a >>>>>>>> large >>>>>>>> sparse matrix and came upon the idea of using PETSc as a framework >>>>>>>> for >>>>>>>> testing >>>>>>>> various strategies from direct to iterative methods on my sample >>>>>>>> matrices. >>>>>>>> In >>>>>>>> this setup for an NxN sparse matrix A I would have N rhs's >>>>>>>> representing >>>>>>>> the >>>>>>>> Identity matrix and then solve for X. I wanted to experiment with >>>>>>>> both >>>>>>>> parallel and serial strategies ranging from LU Decomposition using >>>>>>>> SuperLU, >>>>>>>> MUMPS etc. to iterative methods using GMRES etc. Am I right in >>>>>>>> thinking >>>>>>>> that >>>>>>>> all this can be done in PETSc by setting up a core framework and >>>>>>>> then >>>>>>>> varying >>>>>>>> the solver methods etc? >>>>>>>> >>>>>>>> I have looked over the sample KSP Solver codes although they only >>>>>>>> seem >>>>>>>> to >>>>>>>> suggest single vectors for x and b. Can this be changed to accept >>>>>>>> multiple >>>>>>>> vectors? Can anyone suggest a sample code that maybe demonstrates >>>>>>>> the >>>>>>>> sort >>>>>>>> of >>>>>>>> thing I want to achieve...if it is in fact possible. >>>>>>>> >>>>>>>> Thanks in advance for any assistance given, >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Tim. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -- Dr. Timothy Stitt HPC Application Consultant - ICHEC (www.ichec.ie) Dublin Institute for Advanced Studies 5 Merrion Square - Dublin 2 - Ireland +353-1-6621333 (tel) / +353-1-6621477 (fax) / +353-874195427 (mobile) From zonexo at gmail.com Thu Aug 16 21:57:32 2007 From: zonexo at gmail.com (Ben Tay) Date: Fri, 17 Aug 2007 10:57:32 +0800 Subject: Using ML and options In-Reply-To: References: <46C3AC74.6030805@gmail.com> <46C425DD.6000904@gmail.com> Message-ID: <46C50E9C.8030007@gmail.com> Hi, I tried to test ml using "-pc_type ml" on my problem. It was working ok using LU or hypre/boomeramg. However I got the warning: Gen_Prolongator warning : max eigen <= 0.0 Gen_Prolongator warning : max eigen <= 0.0 Gen_Prolongator warning : max eigen <= 0.0 Gen_Prolongator warning : max eigen <= 0.0 Gen_Prolongator warning : max eigen <= 0.0 When I use hypre, I used "-pc_type hypre -pc_hypre_type boomeramg which gives good and fast result for solving my poisson eqn. Is there a recommendation for ml as well? Moreover, although I got answers from ml, my answer using ml differs from LU and hypre from the 3 sig. fig. When I run the example ex2f, I get different norms of error: LU: Norm of error 0.1192E-05 iterations 4 hypre: Norm of error < 1.e-12,iterations 1 ml: Norm of error 0.2098E-03 iterations 2 It seems that norm of error for ml is a bit too high. How can I make it lower? Thank you. Hong Zhang wrote: > On Thu, 16 Aug 2007, Ben Tay wrote: > > >> Btw, is the file to download >> ftp://ftp.mcs.anl.gov/pub/petsc/externalpackages/ml-5.0.tar.gz? >> > > Yes. You can simply use '--download-ml=1' during configuration. > > Run your program with '-help' to see all options for using ml. > See ~petsc/src/ksp/ksp/examples/tests/ex26.c on how to use ML. > > Hong > > >> Thanks >> >> Matthew Knepley wrote: >> >>> The multigrid PC needs information about the grid and discretization. If you >>> cannot provide this, use AMG through Hypre or ML. Or if you have a >>> structured grid, consider using DMMG. >>> >>> Thanks, >>> >>> Matt >>> >>> On 8/15/07, Ben Tay wrote: >>> >>> >>>> Hi, >>>> >>>> I found that there's a multigrid option in the manual which can be used >>>> by adding -pctype mg -pcmgtype PC_MG_MULTIPLICATIVE. >>>> >>>> However, it seems that I am actually just using LU since with or without >>>> this option, I got exactly the same answer. Am I using multigrid the >>>> wrong way? >>>> >>>> Thanks >>>> >>>> >>>> >>>> >>> >>> >> > > > From bsmith at mcs.anl.gov Thu Aug 16 22:02:54 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Thu, 16 Aug 2007 22:02:54 -0500 (CDT) Subject: Using ML and options In-Reply-To: <46C50E9C.8030007@gmail.com> References: <46C3AC74.6030805@gmail.com> <46C425DD.6000904@gmail.com> <46C50E9C.8030007@gmail.com> Message-ID: On Fri, 17 Aug 2007, Ben Tay wrote: > Hi, > > I tried to test ml using "-pc_type ml" on my problem. It was working ok using > LU or hypre/boomeramg. However I got the warning: > > Gen_Prolongator warning : max eigen <= 0.0 > Gen_Prolongator warning : max eigen <= 0.0 > Gen_Prolongator warning : max eigen <= 0.0 > Gen_Prolongator warning : max eigen <= 0.0 > Gen_Prolongator warning : max eigen <= 0.0 > > When I use hypre, I used "-pc_type hypre -pc_hypre_type boomeramg which gives > good and fast result for solving my poisson eqn. Is there a recommendation for > ml as well? > > Moreover, although I got answers from ml, my answer using ml differs from LU > and hypre from the 3 sig. fig. When I run the example ex2f, I get different > norms of error: > > LU: Norm of error 0.1192E-05 iterations 4 Huh? Why is this not 1.e-14, since LU is a direct solver, do you mean ILU? > > hypre: Norm of error < 1.e-12,iterations 1 > > ml: Norm of error 0.2098E-03 iterations 2 You may need to play around with the -ksp_rtol value or options in ml to (run with -pc_type ml -help to see ML options). Run with -ksp_monitor_true_residual and send us the results, We don't have a lot of experience with ML on real problems. Barry > > It seems that norm of error for ml is a bit too high. How can I make it lower? > > Thank you. > > > > Hong Zhang wrote: > > On Thu, 16 Aug 2007, Ben Tay wrote: > > > > > > > Btw, is the file to download > > > ftp://ftp.mcs.anl.gov/pub/petsc/externalpackages/ml-5.0.tar.gz? > > > > > > > Yes. You can simply use '--download-ml=1' during configuration. > > > > Run your program with '-help' to see all options for using ml. > > See ~petsc/src/ksp/ksp/examples/tests/ex26.c on how to use ML. > > > > Hong > > > > > > > Thanks > > > > > > Matthew Knepley wrote: > > > > > > > The multigrid PC needs information about the grid and discretization. If > > > > you > > > > cannot provide this, use AMG through Hypre or ML. Or if you have a > > > > structured grid, consider using DMMG. > > > > > > > > Thanks, > > > > > > > > Matt > > > > > > > > On 8/15/07, Ben Tay wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > I found that there's a multigrid option in the manual which can be > > > > > used > > > > > by adding -pctype mg -pcmgtype PC_MG_MULTIPLICATIVE. > > > > > > > > > > However, it seems that I am actually just using LU since with or > > > > > without > > > > > this option, I got exactly the same answer. Am I using multigrid the > > > > > wrong way? > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From bsmith at mcs.anl.gov Thu Aug 16 22:04:47 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Thu, 16 Aug 2007 22:04:47 -0500 (CDT) Subject: How can I use BICGStab on a matrix with zero entries on the diagonal In-Reply-To: <440307c0708121929i27e78ca8g7a9522c046ad63a9@mail.gmail.com> References: <440307c0708121446j4b6458ddnd43f313b1d5ac2b9@mail.gmail.com> <440307c0708121450s1f004807xce34cf21396c2a4f@mail.gmail.com> <440307c0708121929i27e78ca8g7a9522c046ad63a9@mail.gmail.com> Message-ID: On Sun, 12 Aug 2007, Zhu Liang wrote: > Yes, you are right, I am trying to solve Oseen equation. > > I tried using preconditioner PCILU(1) which works well. > But for PCILU(0) it did not work, as well as PCBJACOBI. > I have tried to insert zero on the diagonal, but it still does not work. > > In your opinion, what is the best parallel solver and preconditioner > for the Oseen equation ? Black box? I wish I did! Matt, when are we going to add a "general purpose" Stokes solver to PETSc? Does that question even make sense? Barry > > Thanks for your reply. > Liang > > On 8/12/07, Barry Smith wrote: > > > > > > It is not really the BiCGstab Krylov solver that it complaining; > > it is the default ILU or block Jacobi with ILU on the blocks that is > > complaining. > > > > You first need to make sure you insert 0 entries on the all the diagonal > > entries that are 0. BUT given the structure of your matrix you may want > > to think about solvers that specifically handle that type of matrix. > > > > Barry > > > > Stokes type solvers? > > > > > > On Mon, 13 Aug 2007, Zhu Liang wrote: > > > > > By the way, the block of my matrix is like : > > > > > > U , a > > > A^T , 0 > > > > > > > > > > > > ---------- Forwarded message ---------- > > > From: Zhu Liang > > > Date: Aug 13, 2007 5:46 AM > > > Subject: How can I use BICGStab on a matrix with zero entries on the > > > diagonal > > > To: petsc-users at mcs.anl.gov > > > > > > > > > Dear petsc-users > > > > > > When I try to solve a linear equation Ax=b with BicgStab preconditioner, > > I > > > got > > > an error "Matrix is missing diagonal number". That is because I have > > zeros > > > on > > > the diagonal of the matrix. > > > > > > I am wondering if there is some simple method to avoid that? > > > > > > Best, > > > Liang > > > > > > > > From hzhang at mcs.anl.gov Thu Aug 16 22:54:18 2007 From: hzhang at mcs.anl.gov (Hong Zhang) Date: Thu, 16 Aug 2007 22:54:18 -0500 (CDT) Subject: Using ML and options In-Reply-To: <46C50E9C.8030007@gmail.com> References: <46C3AC74.6030805@gmail.com> <46C425DD.6000904@gmail.com> <46C50E9C.8030007@gmail.com> Message-ID: Ben, > > I tried to test ml using "-pc_type ml" on my problem. It was working ok > using LU or hypre/boomeramg. However I got the warning: > > Gen_Prolongator warning : max eigen <= 0.0 > Gen_Prolongator warning : max eigen <= 0.0 > Gen_Prolongator warning : max eigen <= 0.0 > Gen_Prolongator warning : max eigen <= 0.0 > Gen_Prolongator warning : max eigen <= 0.0 I got the same warning on using ML for my application, which results in unacceptable computational result in my case. I've sent a request to ML developer for its interpretation yesterday. > When I use hypre, I used "-pc_type hypre -pc_hypre_type boomeramg which > gives good and fast result for solving my poisson eqn. Is there a > recommendation for ml as well? > > Moreover, although I got answers from ml, my answer using ml differs > from LU and hypre from the 3 sig. fig. When I run the example ex2f, I > get different norms of error: > > LU: Norm of error 0.1192E-05 iterations 4 > > hypre: Norm of error < 1.e-12,iterations 1 > > ml: Norm of error 0.2098E-03 iterations 2 You may test other available options (see -help), in particular, find out the smoother and MG cycle used by hypre and apply the same to ML. Good luck, Hong > > It seems that norm of error for ml is a bit too high. How can I make it > lower? > > Thank you. > > > > Hong Zhang wrote: > > On Thu, 16 Aug 2007, Ben Tay wrote: > > > > > >> Btw, is the file to download > >> ftp://ftp.mcs.anl.gov/pub/petsc/externalpackages/ml-5.0.tar.gz? > >> > > > > Yes. You can simply use '--download-ml=1' during configuration. > > > > Run your program with '-help' to see all options for using ml. > > See ~petsc/src/ksp/ksp/examples/tests/ex26.c on how to use ML. > > > > Hong > > > > > >> Thanks > >> > >> Matthew Knepley wrote: > >> > >>> The multigrid PC needs information about the grid and discretization. If you > >>> cannot provide this, use AMG through Hypre or ML. Or if you have a > >>> structured grid, consider using DMMG. > >>> > >>> Thanks, > >>> > >>> Matt > >>> > >>> On 8/15/07, Ben Tay wrote: > >>> > >>> > >>>> Hi, > >>>> > >>>> I found that there's a multigrid option in the manual which can be used > >>>> by adding -pctype mg -pcmgtype PC_MG_MULTIPLICATIVE. > >>>> > >>>> However, it seems that I am actually just using LU since with or without > >>>> this option, I got exactly the same answer. Am I using multigrid the > >>>> wrong way? > >>>> > >>>> Thanks > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >> > > > > > > > > From knepley at gmail.com Thu Aug 16 22:56:45 2007 From: knepley at gmail.com (Matthew Knepley) Date: Thu, 16 Aug 2007 22:56:45 -0500 Subject: How can I use BICGStab on a matrix with zero entries on the diagonal In-Reply-To: References: <440307c0708121446j4b6458ddnd43f313b1d5ac2b9@mail.gmail.com> <440307c0708121450s1f004807xce34cf21396c2a4f@mail.gmail.com> <440307c0708121929i27e78ca8g7a9522c046ad63a9@mail.gmail.com> Message-ID: On 8/16/07, Barry Smith wrote: > > > > On Sun, 12 Aug 2007, Zhu Liang wrote: > > > Yes, you are right, I am trying to solve Oseen equation. > > > > I tried using preconditioner PCILU(1) which works well. > > But for PCILU(0) it did not work, as well as PCBJACOBI. > > I have tried to insert zero on the diagonal, but it still does not work. > > > > In your opinion, what is the best parallel solver and preconditioner > > for the Oseen equation ? > > Black box? I wish I did! > > Matt, when are we going to add a "general purpose" Stokes solver to PETSc? > Does that question even make sense? It makes sense if we know more about the discretization and weak form. There are a few good ways to solve Stokes: block smoothers on an element-by-element basis, block triangular preconditioning by field, efficient projection onto the null space of B. These all require that we can slice up the unknowns correctly. Once people buy into my discretization framework, which will happen shortly after I finish coding it, we can start to get this going. I have a Stokes example now, without any of these nifty solvers :) They will get done this fall. Matt > Barry > > > > > Thanks for your reply. > > Liang > > > > On 8/12/07, Barry Smith wrote: > > > > > > > > > It is not really the BiCGstab Krylov solver that it complaining; > > > it is the default ILU or block Jacobi with ILU on the blocks that is > > > complaining. > > > > > > You first need to make sure you insert 0 entries on the all the diagonal > > > entries that are 0. BUT given the structure of your matrix you may want > > > to think about solvers that specifically handle that type of matrix. > > > > > > Barry > > > > > > Stokes type solvers? > > > > > > > > > On Mon, 13 Aug 2007, Zhu Liang wrote: > > > > > > > By the way, the block of my matrix is like : > > > > > > > > U , a > > > > A^T , 0 > > > > > > > > > > > > > > > > ---------- Forwarded message ---------- > > > > From: Zhu Liang > > > > Date: Aug 13, 2007 5:46 AM > > > > Subject: How can I use BICGStab on a matrix with zero entries on the > > > > diagonal > > > > To: petsc-users at mcs.anl.gov > > > > > > > > > > > > Dear petsc-users > > > > > > > > When I try to solve a linear equation Ax=b with BicgStab preconditioner, > > > I > > > > got > > > > an error "Matrix is missing diagonal number". That is because I have > > > zeros > > > > on > > > > the diagonal of the matrix. > > > > > > > > I am wondering if there is some simple method to avoid that? > > > > > > > > Best, > > > > Liang > > > > > > > > > > > > > > -- 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 From zonexo at gmail.com Thu Aug 16 23:03:28 2007 From: zonexo at gmail.com (Ben Tay) Date: Fri, 17 Aug 2007 12:03:28 +0800 Subject: Using ML and options In-Reply-To: References: <46C3AC74.6030805@gmail.com> <46C425DD.6000904@gmail.com> <46C50E9C.8030007@gmail.com> Message-ID: <46C51E10.9070406@gmail.com> Hi, Sorry I made a mistake. The ex2f uses default pc and ksp and hence it is actually using GMRES. I've tested some other options of ml like -pc_ml_CoarsenScheme, -pc_mg_cycles, -pc_ml_maxNlevels but the answer (if there's one) is much slower. Also, for the CoarsenScheme, if I use METIS, I also get the error msg: *ML*WRN* This function has been compiled without the configure *ML*WRN* option --with-ml_metis *ML*WRN* I will put all the nodes in the same aggregate, this time... *ML*WRN* (file ./Coarsen/ml_agg_METIS.c, line 954) Thanks Barry Smith wrote: > On Fri, 17 Aug 2007, Ben Tay wrote: > > >> Hi, >> >> I tried to test ml using "-pc_type ml" on my problem. It was working ok using >> LU or hypre/boomeramg. However I got the warning: >> >> Gen_Prolongator warning : max eigen <= 0.0 >> Gen_Prolongator warning : max eigen <= 0.0 >> Gen_Prolongator warning : max eigen <= 0.0 >> Gen_Prolongator warning : max eigen <= 0.0 >> Gen_Prolongator warning : max eigen <= 0.0 >> >> When I use hypre, I used "-pc_type hypre -pc_hypre_type boomeramg which gives >> good and fast result for solving my poisson eqn. Is there a recommendation for >> ml as well? >> >> Moreover, although I got answers from ml, my answer using ml differs from LU >> and hypre from the 3 sig. fig. When I run the example ex2f, I get different >> norms of error: >> >> LU: Norm of error 0.1192E-05 iterations 4 >> > > Huh? Why is this not 1.e-14, since LU is a direct solver, do you mean ILU? > > >> hypre: Norm of error < 1.e-12,iterations 1 >> >> ml: Norm of error 0.2098E-03 iterations 2 >> > > You may need to play around with the -ksp_rtol value or options > in ml to (run with -pc_type ml -help to see ML options). Run with > -ksp_monitor_true_residual and send us the results, We don't have > a lot of experience with ML on real problems. > > Barry > > >> It seems that norm of error for ml is a bit too high. How can I make it lower? >> >> Thank you. >> >> >> >> Hong Zhang wrote: >> >>> On Thu, 16 Aug 2007, Ben Tay wrote: >>> >>> >>> >>>> Btw, is the file to download >>>> ftp://ftp.mcs.anl.gov/pub/petsc/externalpackages/ml-5.0.tar.gz? >>>> >>>> >>> Yes. You can simply use '--download-ml=1' during configuration. >>> >>> Run your program with '-help' to see all options for using ml. >>> See ~petsc/src/ksp/ksp/examples/tests/ex26.c on how to use ML. >>> >>> Hong >>> >>> >>> >>>> Thanks >>>> >>>> Matthew Knepley wrote: >>>> >>>> >>>>> The multigrid PC needs information about the grid and discretization. If >>>>> you >>>>> cannot provide this, use AMG through Hypre or ML. Or if you have a >>>>> structured grid, consider using DMMG. >>>>> >>>>> Thanks, >>>>> >>>>> Matt >>>>> >>>>> On 8/15/07, Ben Tay wrote: >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> I found that there's a multigrid option in the manual which can be >>>>>> used >>>>>> by adding -pctype mg -pcmgtype PC_MG_MULTIPLICATIVE. >>>>>> >>>>>> However, it seems that I am actually just using LU since with or >>>>>> without >>>>>> this option, I got exactly the same answer. Am I using multigrid the >>>>>> wrong way? >>>>>> >>>>>> Thanks >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > > > From li76pan at yahoo.com Fri Aug 17 10:18:53 2007 From: li76pan at yahoo.com (li pan) Date: Fri, 17 Aug 2007 08:18:53 -0700 (PDT) Subject: mpiexec Message-ID: <790484.71738.qm@web36803.mail.mud.yahoo.com> dear all, I have a question about MPI. If I want to run the code with mpiexec, shall I compile it with mpicc first? For example, I compile ksp/examples/tutorials/ex1.c just wiht make ex1 and got following error when run the code: mpiexec -n 2 ./ex1 [cli_0]: aborting job: Fatal error in MPI_Bcast: Other MPI error, error stack: MPI_Bcast(791)............................: MPI_Bcast(buf=0xbfffc84c, count=1, MPI_INT, root=0, MPI_COMM_WORLD) failed MPIR_Bcast(220)...........................: MPIC_Send(48).............................: MPIC_Wait(321)............................: MPIDI_CH3_Progress_wait(199)..............: an error occurred while handling an event returned by MPIDU_Sock_Wait() MPIDI_CH3I_Progress_handle_sock_event(944): [ch3:sock] failed to connnect to remote process kvs_e0403_pc13_33149_43_0:1 MPIDU_Socki_handle_connect(806)...........: connection failure (set=0,sock=1,errno=111:(strerror() not found)) rank 0 in job 44 e0403-pc13_33149 caused collective abort of all ranks exit status of rank 0: return code 13 My mpdtrace showed all the hostnames I have. best regards pan ____________________________________________________________________________________ Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/ From balay at mcs.anl.gov Fri Aug 17 10:31:58 2007 From: balay at mcs.anl.gov (Satish Balay) Date: Fri, 17 Aug 2007 10:31:58 -0500 (CDT) Subject: mpiexec In-Reply-To: <790484.71738.qm@web36803.mail.mud.yahoo.com> References: <790484.71738.qm@web36803.mail.mud.yahoo.com> Message-ID: Ideally PETSc should be configured to use mpicc/etc wrappers. And 'make ex1' would be the right thing. This can be done by specifying --with-mpi-dir [which is equvalent to --with-cc=MPIDIR/bin/mpicc --with-fc=MPIDIR/bin/mpif90] To debug the current problem - you'll have to send us the relavent logs [configure.log make_log test_log etc..] at petsc-maint at mcs.anl.gov Satish On Fri, 17 Aug 2007, li pan wrote: > dear all, > I have a question about MPI. If I want to run the code > with mpiexec, shall I compile it with mpicc first? > For example, I compile ksp/examples/tutorials/ex1.c > just wiht make ex1 > and got following error when run the code: > mpiexec -n 2 ./ex1 > [cli_0]: aborting job: > Fatal error in MPI_Bcast: Other MPI error, error > stack: > MPI_Bcast(791)............................: > MPI_Bcast(buf=0xbfffc84c, count=1, MPI_INT, root=0, > MPI_COMM_WORLD) failed > MPIR_Bcast(220)...........................: > MPIC_Send(48).............................: > MPIC_Wait(321)............................: > MPIDI_CH3_Progress_wait(199)..............: an error > occurred while handling an event returned by > MPIDU_Sock_Wait() > MPIDI_CH3I_Progress_handle_sock_event(944): [ch3:sock] > failed to connnect to remote process > kvs_e0403_pc13_33149_43_0:1 > MPIDU_Socki_handle_connect(806)...........: connection > failure (set=0,sock=1,errno=111:(strerror() not > found)) > rank 0 in job 44 e0403-pc13_33149 caused collective > abort of all ranks > exit status of rank 0: return code 13 > > My mpdtrace showed all the hostnames I have. > > best regards > > pan > > > > > > ____________________________________________________________________________________ > Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. > http://autos.yahoo.com/green_center/ > > From bsmith at mcs.anl.gov Sat Aug 18 16:20:22 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Sat, 18 Aug 2007 16:20:22 -0500 (CDT) Subject: How can I use BICGStab on a matrix with zero entries on the diagonal In-Reply-To: References: <440307c0708121446j4b6458ddnd43f313b1d5ac2b9@mail.gmail.com> <440307c0708121450s1f004807xce34cf21396c2a4f@mail.gmail.com> <440307c0708121929i27e78ca8g7a9522c046ad63a9@mail.gmail.com> Message-ID: On Thu, 16 Aug 2007, Matthew Knepley wrote: > On 8/16/07, Barry Smith wrote: > > > > > > > > On Sun, 12 Aug 2007, Zhu Liang wrote: > > > > > Yes, you are right, I am trying to solve Oseen equation. > > > > > > I tried using preconditioner PCILU(1) which works well. > > > But for PCILU(0) it did not work, as well as PCBJACOBI. > > > I have tried to insert zero on the diagonal, but it still does not work. > > > > > > In your opinion, what is the best parallel solver and preconditioner > > > for the Oseen equation ? > > > > Black box? I wish I did! > > > > Matt, when are we going to add a "general purpose" Stokes solver to PETSc? > > Does that question even make sense? > > It makes sense if we know more about the discretization and weak form. There > are a few good ways to solve Stokes: block smoothers on an element-by-element > basis, block triangular preconditioning by field, efficient projection onto the > null space of B. > These all require that we can slice up the unknowns correctly. Please be specific here; do you mean more than just saying which values are in the lower block and which are not? > Once people buy into my discretization framework, which will happen shortly > after I finish coding it, we can start to get this going. I have a > Stokes example > now, without any of these nifty solvers :) They will get done this fall. > > Matt > > > Barry > > > > > > > > Thanks for your reply. > > > Liang > > > > > > On 8/12/07, Barry Smith wrote: > > > > > > > > > > > > It is not really the BiCGstab Krylov solver that it complaining; > > > > it is the default ILU or block Jacobi with ILU on the blocks that is > > > > complaining. > > > > > > > > You first need to make sure you insert 0 entries on the all the diagonal > > > > entries that are 0. BUT given the structure of your matrix you may want > > > > to think about solvers that specifically handle that type of matrix. > > > > > > > > Barry > > > > > > > > Stokes type solvers? > > > > > > > > > > > > On Mon, 13 Aug 2007, Zhu Liang wrote: > > > > > > > > > By the way, the block of my matrix is like : > > > > > > > > > > U , a > > > > > A^T , 0 > > > > > > > > > > > > > > > > > > > > ---------- Forwarded message ---------- > > > > > From: Zhu Liang > > > > > Date: Aug 13, 2007 5:46 AM > > > > > Subject: How can I use BICGStab on a matrix with zero entries on the > > > > > diagonal > > > > > To: petsc-users at mcs.anl.gov > > > > > > > > > > > > > > > Dear petsc-users > > > > > > > > > > When I try to solve a linear equation Ax=b with BicgStab preconditioner, > > > > I > > > > > got > > > > > an error "Matrix is missing diagonal number". That is because I have > > > > zeros > > > > > on > > > > > the diagonal of the matrix. > > > > > > > > > > I am wondering if there is some simple method to avoid that? > > > > > > > > > > Best, > > > > > Liang > > > > > > > > > > > > > > > > > > > > > > > From w_subber at yahoo.com Sun Aug 19 12:27:38 2007 From: w_subber at yahoo.com (Waad Subber) Date: Sun, 19 Aug 2007 10:27:38 -0700 (PDT) Subject: undefined reference to Message-ID: <707615.60455.qm@web38212.mail.mud.yahoo.com> Hello everyone I am calling a subroutine from my main program, and when I compile the code I get an error message (undefined reference to 'mvec_') referring to the call statement in the main program. I have defined the subroutine as external in the main program using (external mvec), but the problem still unsolved ..! The makefile looks like: OBJS= mvec.o CFLAGS = FFLAGS = CPPFLAGS = FPPFLAGS = include ${PETSC_DIR}/bmake/common/base all: $(OBJS) mvec.o: mvec.F mpif90 -c mvec.F exe: pro.o $(OBJS) -${FLINKER} -o exe pro.o $(OBJS) ${PETSC_LIB} ${RM} -f pro.o include ${PETSC_DIR}/bmake/common/test Can any one help me with this issue please ...! Thanks Waad --------------------------------- Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: makefile Type: application/octet-stream Size: 294 bytes Desc: 3428916206-makefile URL: From bsmith at mcs.anl.gov Sun Aug 19 13:11:55 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Sun, 19 Aug 2007 13:11:55 -0500 (CDT) Subject: undefined reference to In-Reply-To: <707615.60455.qm@web38212.mail.mud.yahoo.com> References: <707615.60455.qm@web38212.mail.mud.yahoo.com> Message-ID: Not sure what the problem is, but you should remove the lines > mvec.o: mvec.F > mpif90 -c mvec.F you do not need them. Please send ALL the output when you run make exe after the change. Barry On Sun, 19 Aug 2007, Waad Subber wrote: > Hello everyone > > I am calling a subroutine from my main program, and when I compile the code I get an error message (undefined reference to 'mvec_') referring to the call statement in the main program. I have defined the subroutine as external in the main program using (external mvec), but the problem still unsolved ..! > > The makefile looks like: > > OBJS= mvec.o > CFLAGS = > FFLAGS = > CPPFLAGS = > FPPFLAGS = > > > include ${PETSC_DIR}/bmake/common/base > > all: $(OBJS) > > mvec.o: mvec.F > mpif90 -c mvec.F > > exe: pro.o $(OBJS) > -${FLINKER} -o exe pro.o $(OBJS) ${PETSC_LIB} > ${RM} -f pro.o > > include ${PETSC_DIR}/bmake/common/test > > Can any one help me with this issue please ...! > > Thanks > > Waad > > > --------------------------------- > Park yourself in front of a world of choices in alternative vehicles. > Visit the Yahoo! Auto Green Center. From w_subber at yahoo.com Sun Aug 19 13:30:47 2007 From: w_subber at yahoo.com (Waad Subber) Date: Sun, 19 Aug 2007 11:30:47 -0700 (PDT) Subject: undefined reference to In-Reply-To: Message-ID: <989880.4108.qm@web38208.mail.mud.yahoo.com> Thanks for response I removed the lines and I got the following output after executing the make file: gfortran -c -fPIC -Wall -Wno-unused-variable -g -I/home/waad/soft/petsc-2.3.3-p4 -I/home/waad/soft/petsc-2.3.3-p4/bmake/linux-gnu-c-debug -I/home/waad/soft/petsc-2.3.3-p4/include -I/home/waad/mpich2-install/include -o pro.o pro.F gfortran -fPIC -Wall -Wno-unused-variable -g -o exe pro.o -Wl,-rpath,/home/waad/soft/petsc-2.3.3-p4/lib/linux-gnu-c-debug -L/home/waad/soft/petsc-2.3.3-p4/lib/linux-gnu-c-debug -lpetscts -lpetscsnes -lpetscksp -lpetscdm -lpetscmat -lpetscvec -lpetsc -L/usr/lib64 -lX11 -Wl,-rpath,/home/waad/mpich2-install/lib -L/home/waad/mpich2-install/lib -lmpich -lpthread -llapack -lblas -lm -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -Wl,-rpath,/lib/../lib64 -L/lib/../lib64 -Wl,-rpath,/usr/lib/../lib64 -L/usr/lib/../lib64 -ldl -lgcc_s -lgfortranbegin -lgfortran -lm -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -Wl,-rpath,/lib/../lib64 -Wl,-rpath,/usr/lib/../lib64 -lm -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -Wl,-rpath,/lib/../lib64 -L/lib/../lib64 -Wl,-rpath,/usr/lib/../lib64 -L/usr/lib/../lib64 -ldl -lgcc_s -ldl pro.o: In function `MAIN__': /home/waad/petsc_test/example1/solvetest/pro.F:38: undefined reference to `mvec_' collect2: ld returned 1 exit status make: [exe] Error 1 (ignored) /bin/rm -f -f pro.o Barry Smith wrote: Not sure what the problem is, but you should remove the lines > mvec.o: mvec.F > mpif90 -c mvec.F you do not need them. Please send ALL the output when you run make exe after the change. Barry On Sun, 19 Aug 2007, Waad Subber wrote: > Hello everyone > > I am calling a subroutine from my main program, and when I compile the code I get an error message (undefined reference to 'mvec_') referring to the call statement in the main program. I have defined the subroutine as external in the main program using (external mvec), but the problem still unsolved ..! > > The makefile looks like: > > OBJS= mvec.o > CFLAGS = > FFLAGS = > CPPFLAGS = > FPPFLAGS = > > > include ${PETSC_DIR}/bmake/common/base > > all: $(OBJS) > > mvec.o: mvec.F > mpif90 -c mvec.F > > exe: pro.o $(OBJS) > -${FLINKER} -o exe pro.o $(OBJS) ${PETSC_LIB} > ${RM} -f pro.o > > include ${PETSC_DIR}/bmake/common/test > > Can any one help me with this issue please ...! > > Thanks > > Waad > > > --------------------------------- > Park yourself in front of a world of choices in alternative vehicles. > Visit the Yahoo! Auto Green Center. --------------------------------- Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From balay at mcs.anl.gov Sun Aug 19 14:55:23 2007 From: balay at mcs.anl.gov (Satish Balay) Date: Sun, 19 Aug 2007 14:55:23 -0500 (CDT) Subject: undefined reference to In-Reply-To: <989880.4108.qm@web38208.mail.mud.yahoo.com> References: <989880.4108.qm@web38208.mail.mud.yahoo.com> Message-ID: What do you have for: nm -ao mvec.o Also - sugest using the attached makefile. Satish On Sun, 19 Aug 2007, Waad Subber wrote: > Thanks for response > I removed the lines and I got the following output after executing the make file: > > gfortran -c -fPIC -Wall -Wno-unused-variable -g -I/home/waad/soft/petsc-2.3.3-p4 -I/home/waad/soft/petsc-2.3.3-p4/bmake/linux-gnu-c-debug -I/home/waad/soft/petsc-2.3.3-p4/include -I/home/waad/mpich2-install/include -o pro.o pro.F > gfortran -fPIC -Wall -Wno-unused-variable -g -o exe pro.o -Wl,-rpath,/home/waad/soft/petsc-2.3.3-p4/lib/linux-gnu-c-debug -L/home/waad/soft/petsc-2.3.3-p4/lib/linux-gnu-c-debug -lpetscts -lpetscsnes -lpetscksp -lpetscdm -lpetscmat -lpetscvec -lpetsc -L/usr/lib64 -lX11 -Wl,-rpath,/home/waad/mpich2-install/lib -L/home/waad/mpich2-install/lib -lmpich -lpthread -llapack -lblas -lm -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -Wl,-rpath,/lib/../lib64 -L/lib/../lib64 -Wl,-rpath,/usr/lib/../lib64 -L/usr/lib/../lib64 -ldl -lgcc_s -lgfortranbegin -lgfortran -lm -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -Wl,-rpath,/lib/../lib64 -Wl,-rpath,/usr/lib/../lib64 -lm -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.1.2 > -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -Wl,-rpath,/lib/../lib64 -L/lib/../lib64 -Wl,-rpath,/usr/lib/../lib64 -L/usr/lib/../lib64 -ldl -lgcc_s -ldl > pro.o: In function `MAIN__': > /home/waad/petsc_test/example1/solvetest/pro.F:38: undefined reference to `mvec_' > collect2: ld returned 1 exit status > make: [exe] Error 1 (ignored) > /bin/rm -f -f pro.o > > > > Barry Smith wrote: > > Not sure what the problem is, but > you should remove the lines > > mvec.o: mvec.F > > mpif90 -c mvec.F > you do not need them. > > Please send ALL the output when you run make exe after the change. > > Barry > > > > On Sun, 19 Aug 2007, Waad Subber wrote: > > > Hello everyone > > > > I am calling a subroutine from my main program, and when I compile the code I get an error message (undefined reference to 'mvec_') referring to the call statement in the main program. I have defined the subroutine as external in the main program using (external mvec), but the problem still unsolved ..! > > > > The makefile looks like: > > > > OBJS= mvec.o > > CFLAGS = > > FFLAGS = > > CPPFLAGS = > > FPPFLAGS = > > > > > > include ${PETSC_DIR}/bmake/common/base > > > > all: $(OBJS) > > > > mvec.o: mvec.F > > mpif90 -c mvec.F > > > > exe: pro.o $(OBJS) > > -${FLINKER} -o exe pro.o $(OBJS) ${PETSC_LIB} > > ${RM} -f pro.o > > > > include ${PETSC_DIR}/bmake/common/test > > > > Can any one help me with this issue please ...! > > > > Thanks > > > > Waad > > > > > > --------------------------------- > > Park yourself in front of a world of choices in alternative vehicles. > > Visit the Yahoo! Auto Green Center. > > > > > --------------------------------- > Be a better Heartthrob. Get better relationship answers from someone who knows. > Yahoo! Answers - Check it out. From balay at mcs.anl.gov Sun Aug 19 14:56:42 2007 From: balay at mcs.anl.gov (Satish Balay) Date: Sun, 19 Aug 2007 14:56:42 -0500 (CDT) Subject: undefined reference to In-Reply-To: References: <989880.4108.qm@web38208.mail.mud.yahoo.com> Message-ID: sorry - forgot the attachment satish On Sun, 19 Aug 2007, Satish Balay wrote: > What do you have for: > > nm -ao mvec.o > > Also - sugest using the attached makefile. > > Satish > > > On Sun, 19 Aug 2007, Waad Subber wrote: > > > Thanks for response > > I removed the lines and I got the following output after executing the make file: > > > > gfortran -c -fPIC -Wall -Wno-unused-variable -g -I/home/waad/soft/petsc-2.3.3-p4 -I/home/waad/soft/petsc-2.3.3-p4/bmake/linux-gnu-c-debug -I/home/waad/soft/petsc-2.3.3-p4/include -I/home/waad/mpich2-install/include -o pro.o pro.F > > gfortran -fPIC -Wall -Wno-unused-variable -g -o exe pro.o -Wl,-rpath,/home/waad/soft/petsc-2.3.3-p4/lib/linux-gnu-c-debug -L/home/waad/soft/petsc-2.3.3-p4/lib/linux-gnu-c-debug -lpetscts -lpetscsnes -lpetscksp -lpetscdm -lpetscmat -lpetscvec -lpetsc -L/usr/lib64 -lX11 -Wl,-rpath,/home/waad/mpich2-install/lib -L/home/waad/mpich2-install/lib -lmpich -lpthread -llapack -lblas -lm -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -Wl,-rpath,/lib/../lib64 -L/lib/../lib64 -Wl,-rpath,/usr/lib/../lib64 -L/usr/lib/../lib64 -ldl -lgcc_s -lgfortranbegin -lgfortran -lm -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -Wl,-rpath,/lib/../lib64 -Wl,-rpath,/usr/lib/../lib64 -lm -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.1.2 > > -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -Wl,-rpath,/lib/../lib64 -L/lib/../lib64 -Wl,-rpath,/usr/lib/../lib64 -L/usr/lib/../lib64 -ldl -lgcc_s -ldl > > pro.o: In function `MAIN__': > > /home/waad/petsc_test/example1/solvetest/pro.F:38: undefined reference to `mvec_' > > collect2: ld returned 1 exit status > > make: [exe] Error 1 (ignored) > > /bin/rm -f -f pro.o > > > > > > > > Barry Smith wrote: > > > > Not sure what the problem is, but > > you should remove the lines > > > mvec.o: mvec.F > > > mpif90 -c mvec.F > > you do not need them. > > > > Please send ALL the output when you run make exe after the change. > > > > Barry > > > > > > > > On Sun, 19 Aug 2007, Waad Subber wrote: > > > > > Hello everyone > > > > > > I am calling a subroutine from my main program, and when I compile the code I get an error message (undefined reference to 'mvec_') referring to the call statement in the main program. I have defined the subroutine as external in the main program using (external mvec), but the problem still unsolved ..! > > > > > > The makefile looks like: > > > > > > OBJS= mvec.o > > > CFLAGS = > > > FFLAGS = > > > CPPFLAGS = > > > FPPFLAGS = > > > > > > > > > include ${PETSC_DIR}/bmake/common/base > > > > > > all: $(OBJS) > > > > > > mvec.o: mvec.F > > > mpif90 -c mvec.F > > > > > > exe: pro.o $(OBJS) > > > -${FLINKER} -o exe pro.o $(OBJS) ${PETSC_LIB} > > > ${RM} -f pro.o > > > > > > include ${PETSC_DIR}/bmake/common/test > > > > > > Can any one help me with this issue please ...! > > > > > > Thanks > > > > > > Waad > > > > > > > > > --------------------------------- > > > Park yourself in front of a world of choices in alternative vehicles. > > > Visit the Yahoo! Auto Green Center. > > > > > > > > > > --------------------------------- > > Be a better Heartthrob. Get better relationship answers from someone who knows. > > Yahoo! Answers - Check it out. > > -------------- next part -------------- CFLAGS = FFLAGS = CPPFLAGS = FPPFLAGS = CLEANFILES = exe include ${PETSC_DIR}/bmake/common/base OBJS = pro.o mvec.o all: exe exe: ${OBJS} -${FLINKER} -o exe ${OBJS} ${PETSC_LIB} include ${PETSC_DIR}/bmake/common/test From randy at geosystem.us Sun Aug 19 14:30:52 2007 From: randy at geosystem.us (Randall Mackie) Date: Sun, 19 Aug 2007 12:30:52 -0700 Subject: assembleVectorComplete Message-ID: <46C89A6C.4010002@geosystem.us> Normally, one uses ghosted values to compute a function on the locally owned part of the grid. I have a slightly different need where on the locally owned part of the grid, I want to compute some local quantities AS WELL as the ghost quantities, if that's where they wind up. Can I do the following: call VecGetArray(localVec....) set the values into the vector I want, including any ghost points that are necessary then call assembleVectorComplete(globalVec,localVec, INSERT_VALUES) ???? The alternate way I can see would be to zero out a global vector, then make calls to DALocalToGlobalBegin and DALocalToGlobalEnd, which ADDS in the ghost values. Thanks in advance. Randy -- Randall Mackie GSY-USA, Inc. PMB# 643 2261 Market St., San Francisco, CA 94114-1600 Tel (415) 469-8649 Fax (415) 469-5044 California Registered Geophysicist License No. GP 1034 From w_subber at yahoo.com Sun Aug 19 15:07:44 2007 From: w_subber at yahoo.com (Waad Subber) Date: Sun, 19 Aug 2007 13:07:44 -0700 (PDT) Subject: undefined reference to In-Reply-To: Message-ID: <644052.62933.qm@web38215.mail.mud.yahoo.com> The problem solved THANK YOU SO MUCH :) Waad Satish Balay wrote: sorry - forgot the attachment satish On Sun, 19 Aug 2007, Satish Balay wrote: > What do you have for: > > nm -ao mvec.o > > Also - sugest using the attached makefile. > > Satish > > > On Sun, 19 Aug 2007, Waad Subber wrote: > > > Thanks for response > > I removed the lines and I got the following output after executing the make file: > > > > gfortran -c -fPIC -Wall -Wno-unused-variable -g -I/home/waad/soft/petsc-2.3.3-p4 -I/home/waad/soft/petsc-2.3.3-p4/bmake/linux-gnu-c-debug -I/home/waad/soft/petsc-2.3.3-p4/include -I/home/waad/mpich2-install/include -o pro.o pro.F > > gfortran -fPIC -Wall -Wno-unused-variable -g -o exe pro.o -Wl,-rpath,/home/waad/soft/petsc-2.3.3-p4/lib/linux-gnu-c-debug -L/home/waad/soft/petsc-2.3.3-p4/lib/linux-gnu-c-debug -lpetscts -lpetscsnes -lpetscksp -lpetscdm -lpetscmat -lpetscvec -lpetsc -L/usr/lib64 -lX11 -Wl,-rpath,/home/waad/mpich2-install/lib -L/home/waad/mpich2-install/lib -lmpich -lpthread -llapack -lblas -lm -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -Wl,-rpath,/lib/../lib64 -L/lib/../lib64 -Wl,-rpath,/usr/lib/../lib64 -L/usr/lib/../lib64 -ldl -lgcc_s -lgfortranbegin -lgfortran -lm -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -Wl,-rpath,/lib/../lib64 -Wl,-rpath,/usr/lib/../lib64 -lm -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.1.2 > > -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -Wl,-rpath,/lib/../lib64 -L/lib/../lib64 -Wl,-rpath,/usr/lib/../lib64 -L/usr/lib/../lib64 -ldl -lgcc_s -ldl > > pro.o: In function `MAIN__': > > /home/waad/petsc_test/example1/solvetest/pro.F:38: undefined reference to `mvec_' > > collect2: ld returned 1 exit status > > make: [exe] Error 1 (ignored) > > /bin/rm -f -f pro.o > > > > > > > > Barry Smith wrote: > > > > Not sure what the problem is, but > > you should remove the lines > > > mvec.o: mvec.F > > > mpif90 -c mvec.F > > you do not need them. > > > > Please send ALL the output when you run make exe after the change. > > > > Barry > > > > > > > > On Sun, 19 Aug 2007, Waad Subber wrote: > > > > > Hello everyone > > > > > > I am calling a subroutine from my main program, and when I compile the code I get an error message (undefined reference to 'mvec_') referring to the call statement in the main program. I have defined the subroutine as external in the main program using (external mvec), but the problem still unsolved ..! > > > > > > The makefile looks like: > > > > > > OBJS= mvec.o > > > CFLAGS = > > > FFLAGS = > > > CPPFLAGS = > > > FPPFLAGS = > > > > > > > > > include ${PETSC_DIR}/bmake/common/base > > > > > > all: $(OBJS) > > > > > > mvec.o: mvec.F > > > mpif90 -c mvec.F > > > > > > exe: pro.o $(OBJS) > > > -${FLINKER} -o exe pro.o $(OBJS) ${PETSC_LIB} > > > ${RM} -f pro.o > > > > > > include ${PETSC_DIR}/bmake/common/test > > > > > > Can any one help me with this issue please ...! > > > > > > Thanks > > > > > > Waad > > > > > > > > > --------------------------------- > > > Park yourself in front of a world of choices in alternative vehicles. > > > Visit the Yahoo! Auto Green Center. > > > > > > > > > > --------------------------------- > > Be a better Heartthrob. Get better relationship answers from someone who knows. > > Yahoo! Answers - Check it out. > > CFLAGS = FFLAGS = CPPFLAGS = FPPFLAGS = CLEANFILES = exe include ${PETSC_DIR}/bmake/common/base OBJS = pro.o mvec.o all: exe exe: ${OBJS} -${FLINKER} -o exe ${OBJS} ${PETSC_LIB} include ${PETSC_DIR}/bmake/common/test --------------------------------- Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsmith at mcs.anl.gov Sun Aug 19 18:25:13 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Sun, 19 Aug 2007 18:25:13 -0500 (CDT) Subject: assembleVectorComplete In-Reply-To: <46C89A6C.4010002@geosystem.us> References: <46C89A6C.4010002@geosystem.us> Message-ID: Randy, It is not clear to me what you want. On Sun, 19 Aug 2007, Randall Mackie wrote: > Normally, one uses ghosted values to compute a function on the locally > owned part of the grid. I have a slightly different need where on the > locally owned part of the grid, I want to compute some local quantities > AS WELL as the ghost quantities, if that's where they wind up. > > Can I do the following: > > call VecGetArray(localVec....) > > set the values into the vector I want, including any ghost points that > are necessary > > then > > call assembleVectorComplete(globalVec,localVec, INSERT_VALUES) This function is for the mesh stuff, I do not think it is usable in this circumstance. > > ???? > > The alternate way I can see would be to zero out a global vector, > then make calls to DALocalToGlobalBegin and DALocalToGlobalEnd, > which ADDS in the ghost values. If you are doing finite elements then likely this is exactly what you want. Barry > > Thanks in advance. > > Randy > > From knepley at gmail.com Mon Aug 20 06:25:35 2007 From: knepley at gmail.com (Matthew Knepley) Date: Mon, 20 Aug 2007 06:25:35 -0500 Subject: How can I use BICGStab on a matrix with zero entries on the diagonal In-Reply-To: References: <440307c0708121446j4b6458ddnd43f313b1d5ac2b9@mail.gmail.com> <440307c0708121450s1f004807xce34cf21396c2a4f@mail.gmail.com> <440307c0708121929i27e78ca8g7a9522c046ad63a9@mail.gmail.com> Message-ID: On 8/18/07, Barry Smith wrote: > > > On Thu, 16 Aug 2007, Matthew Knepley wrote: > > > On 8/16/07, Barry Smith wrote: > > > > > > > > > > > > On Sun, 12 Aug 2007, Zhu Liang wrote: > > > > > > > Yes, you are right, I am trying to solve Oseen equation. > > > > > > > > I tried using preconditioner PCILU(1) which works well. > > > > But for PCILU(0) it did not work, as well as PCBJACOBI. > > > > I have tried to insert zero on the diagonal, but it still does not work. > > > > > > > > In your opinion, what is the best parallel solver and preconditioner > > > > for the Oseen equation ? > > > > > > Black box? I wish I did! > > > > > > Matt, when are we going to add a "general purpose" Stokes solver to PETSc? > > > Does that question even make sense? > > > > It makes sense if we know more about the discretization and weak form. There > > are a few good ways to solve Stokes: block smoothers on an element-by-element > > basis, block triangular preconditioning by field, efficient projection onto the > > null space of B. > > These all require that we can slice up the unknowns correctly. > > Please be specific here; do you mean more than just saying which values > are in the lower block and which are not? For the big block methods (Wathen, Silvester, Elman) we just need to separate entire fields. For block smoother (which avoid the small saddle), we need to do the same thing at the element level. Matt > > Once people buy into my discretization framework, which will happen shortly > > after I finish coding it, we can start to get this going. I have a > > Stokes example > > now, without any of these nifty solvers :) They will get done this fall. > > > > Matt > > > > > Barry > > > > > > > > > > > Thanks for your reply. > > > > Liang > > > > > > > > On 8/12/07, Barry Smith wrote: > > > > > > > > > > > > > > > It is not really the BiCGstab Krylov solver that it complaining; > > > > > it is the default ILU or block Jacobi with ILU on the blocks that is > > > > > complaining. > > > > > > > > > > You first need to make sure you insert 0 entries on the all the diagonal > > > > > entries that are 0. BUT given the structure of your matrix you may want > > > > > to think about solvers that specifically handle that type of matrix. > > > > > > > > > > Barry > > > > > > > > > > Stokes type solvers? > > > > > > > > > > > > > > > On Mon, 13 Aug 2007, Zhu Liang wrote: > > > > > > > > > > > By the way, the block of my matrix is like : > > > > > > > > > > > > U , a > > > > > > A^T , 0 > > > > > > > > > > > > > > > > > > > > > > > > ---------- Forwarded message ---------- > > > > > > From: Zhu Liang > > > > > > Date: Aug 13, 2007 5:46 AM > > > > > > Subject: How can I use BICGStab on a matrix with zero entries on the > > > > > > diagonal > > > > > > To: petsc-users at mcs.anl.gov > > > > > > > > > > > > > > > > > > Dear petsc-users > > > > > > > > > > > > When I try to solve a linear equation Ax=b with BicgStab preconditioner, > > > > > I > > > > > > got > > > > > > an error "Matrix is missing diagonal number". That is because I have > > > > > zeros > > > > > > on > > > > > > the diagonal of the matrix. > > > > > > > > > > > > I am wondering if there is some simple method to avoid that? > > > > > > > > > > > > Best, > > > > > > Liang > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- 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 From knepley at gmail.com Mon Aug 20 06:52:14 2007 From: knepley at gmail.com (Matthew Knepley) Date: Mon, 20 Aug 2007 06:52:14 -0500 Subject: assembleVectorComplete In-Reply-To: <46C89A6C.4010002@geosystem.us> References: <46C89A6C.4010002@geosystem.us> Message-ID: On 8/19/07, Randall Mackie wrote: > Normally, one uses ghosted values to compute a function on the locally > owned part of the grid. I have a slightly different need where on the > locally owned part of the grid, I want to compute some local quantities > AS WELL as the ghost quantities, if that's where they wind up. > > Can I do the following: > > call VecGetArray(localVec....) > > set the values into the vector I want, including any ghost points that > are necessary > > then > > call assembleVectorComplete(globalVec,localVec, INSERT_VALUES) This call only works if you are using the experimental Mesh object. > ???? > > The alternate way I can see would be to zero out a global vector, > then make calls to DALocalToGlobalBegin and DALocalToGlobalEnd, > which ADDS in the ghost values. This is in essence what you want. So, for the ghost values, how do you determine who computes the value? Addition makes sense in that both local and ghost contributions arise. So, if there is no local contribution, set it to zero, and then the ghost value just adds in. Thanks, Matt > Thanks in advance. > > Randy > > -- > Randall Mackie > GSY-USA, Inc. > PMB# 643 > 2261 Market St., > San Francisco, CA 94114-1600 > Tel (415) 469-8649 > Fax (415) 469-5044 > > California Registered Geophysicist > License No. GP 1034 > > -- 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 From gtg100n at mail.gatech.edu Mon Aug 20 15:25:37 2007 From: gtg100n at mail.gatech.edu (Alejandro Garzon) Date: Mon, 20 Aug 2007 16:25:37 -0400 Subject: petsc and matlab Message-ID: <1187641537.46c9f8c135de4@webmail.mail.gatech.edu> Hi, I wrote a code for solving a time dependent pde. In each time step I have to solve a linear system. I first wrote a prototype in matlab and then a C version using Petsc. To my surprise for some input parameters the matlab version runs faster than the Petsc code (on the same single processor). I did the performance comparison by timing 20 groups of 40 iterations. The times for Petsc and matlab are shown bellow group Petsc matlab 1 0.244981 1.110283 2 0.244995 1.112919 3 0.241305 1.113608 4 0.244542 1.114669 5 7.534417 1.112450 6 0.242212 1.115867 7 0.246327 1.111135 8 0.241105 1.113442 9 0.244468 1.111215 10 0.241113 1.111334 11 0.244541 1.112467 12 0.241400 1.113525 13 0.245020 1.114077 14 0.241303 1.113409 15 0.244380 1.116238 16 0.241372 1.109931 17 0.244108 1.100667 18 0.240419 1.096030 19 0.244337 1.096293 20 17.139999 1.097120 --------- -------- total 29.0523 22.1967 time As can be seen in the table, although in most of the groups the time spent by the Petsc code is lower than that of matlab (0.24 compared to 1.1) there are two groups (5 and 20) in the Petsc column that take a long time and make the total for the Petsc code bigger than that for matlab. In Petsc and matlab the method used is bicg and the relative residual is the same: 1e-8. The preconditioners are different, though. In petsc I used the default preconditioner and in matlab I used incomplete LU decomposition with drop tolerance. The code that solves the linear system in matlab is [L,U] = luinc(A,droptol); <---- this is done only once before the first iteration, droptol = 1e-12 x = bicg(A,b,relres,maxsteps,L,U); I know incomplete LU decomposition as a preconditioner is available in Petsc but in order to use it one must provide two arguments in addition to the drop tolerance and I didn't know what values to give to them. My question is this: what options should be chosen so that the preconditioner and method use by Petsc are the same as those shown in the two lines of matlab code above? (could you contact the authors of the matlab functions?) A comparison of the performace of Petsc and matlab makes sense only if they are using the exact same methods. Thanks. -- Alejandro From bsmith at mcs.anl.gov Mon Aug 20 15:37:46 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Mon, 20 Aug 2007 15:37:46 -0500 (CDT) Subject: petsc and matlab In-Reply-To: <1187641537.46c9f8c135de4@webmail.mail.gatech.edu> References: <1187641537.46c9f8c135de4@webmail.mail.gatech.edu> Message-ID: Is the matrix "A" the same for all groups (and the only thing different for each group is b)? Barry On Mon, 20 Aug 2007, Alejandro Garzon wrote: > Hi, I wrote a code for solving a time dependent pde. In each time step > I have to solve a linear system. I first wrote a prototype in matlab > and then a C version using Petsc. To my surprise for some input > parameters the matlab version runs faster than the Petsc code (on the > same single processor). I did > the performance comparison by timing 20 groups of 40 iterations. The > times for Petsc and matlab are shown bellow > > group Petsc matlab > > 1 0.244981 1.110283 > 2 0.244995 1.112919 > 3 0.241305 1.113608 > 4 0.244542 1.114669 > 5 7.534417 1.112450 > 6 0.242212 1.115867 > 7 0.246327 1.111135 > 8 0.241105 1.113442 > 9 0.244468 1.111215 > 10 0.241113 1.111334 > 11 0.244541 1.112467 > 12 0.241400 1.113525 > 13 0.245020 1.114077 > 14 0.241303 1.113409 > 15 0.244380 1.116238 > 16 0.241372 1.109931 > 17 0.244108 1.100667 > 18 0.240419 1.096030 > 19 0.244337 1.096293 > 20 17.139999 1.097120 > --------- -------- > total 29.0523 22.1967 > time > > As can be seen in the table, although in most of the groups the time > spent by the Petsc code is lower than that of matlab > (0.24 compared to 1.1) there are two groups (5 and 20) in the Petsc column that > take a long time and make the total for the Petsc code bigger than > that for matlab. > > In Petsc and matlab the method used is bicg and the relative residual > is the same: 1e-8. The preconditioners are different, though. In petsc > I used the default preconditioner and in matlab I used incomplete LU > decomposition with drop tolerance. The code that solves the linear > system in matlab is > > [L,U] = luinc(A,droptol); <---- this is done only once before the > first iteration, droptol = 1e-12 > > x = bicg(A,b,relres,maxsteps,L,U); > > I know incomplete LU decomposition as a preconditioner is available in > Petsc but in order to use it one must provide two arguments in > addition to the drop tolerance and I didn't know what values to give > to them. > > My question is this: what options should be chosen so that the > preconditioner and method use by Petsc are the same as those shown in > the two lines of matlab code above? (could you contact the authors of the > matlab functions?) A comparison of the performace of Petsc and matlab > makes sense only if they are using the exact same methods. > > > Thanks. > > -- > Alejandro > > > > > From gtg100n at mail.gatech.edu Tue Aug 21 07:19:05 2007 From: gtg100n at mail.gatech.edu (Alejandro Garzon) Date: Tue, 21 Aug 2007 08:19:05 -0400 Subject: petsc and matlab In-Reply-To: References: <1187641537.46c9f8c135de4@webmail.mail.gatech.edu> Message-ID: <1187698745.46cad8397378c@webmail.mail.gatech.edu> Yes, the "A" matrix is the same. -- Alejandro Quoting Barry Smith : > > Is the matrix "A" the same for all groups (and the only thing > different for each group is b)? > > Barry > > > On Mon, 20 Aug 2007, Alejandro Garzon wrote: > > > Hi, I wrote a code for solving a time dependent pde. In each time step > > I have to solve a linear system. I first wrote a prototype in matlab > > and then a C version using Petsc. To my surprise for some input > > parameters the matlab version runs faster than the Petsc code (on the > > same single processor). I did > > the performance comparison by timing 20 groups of 40 iterations. The > > times for Petsc and matlab are shown bellow > > > > group Petsc matlab > > > > 1 0.244981 1.110283 > > 2 0.244995 1.112919 > > 3 0.241305 1.113608 > > 4 0.244542 1.114669 > > 5 7.534417 1.112450 > > 6 0.242212 1.115867 > > 7 0.246327 1.111135 > > 8 0.241105 1.113442 > > 9 0.244468 1.111215 > > 10 0.241113 1.111334 > > 11 0.244541 1.112467 > > 12 0.241400 1.113525 > > 13 0.245020 1.114077 > > 14 0.241303 1.113409 > > 15 0.244380 1.116238 > > 16 0.241372 1.109931 > > 17 0.244108 1.100667 > > 18 0.240419 1.096030 > > 19 0.244337 1.096293 > > 20 17.139999 1.097120 > > --------- -------- > > total 29.0523 22.1967 > > time > > > > As can be seen in the table, although in most of the groups the time > > spent by the Petsc code is lower than that of matlab > > (0.24 compared to 1.1) there are two groups (5 and 20) in the Petsc column > that > > take a long time and make the total for the Petsc code bigger than > > that for matlab. > > > > In Petsc and matlab the method used is bicg and the relative residual > > is the same: 1e-8. The preconditioners are different, though. In petsc > > I used the default preconditioner and in matlab I used incomplete LU > > decomposition with drop tolerance. The code that solves the linear > > system in matlab is > > > > [L,U] = luinc(A,droptol); <---- this is done only once before the > > first iteration, droptol = 1e-12 > > > > x = bicg(A,b,relres,maxsteps,L,U); > > > > I know incomplete LU decomposition as a preconditioner is available in > > Petsc but in order to use it one must provide two arguments in > > addition to the drop tolerance and I didn't know what values to give > > to them. > > > > My question is this: what options should be chosen so that the > > preconditioner and method use by Petsc are the same as those shown in > > the two lines of matlab code above? (could you contact the authors of the > > matlab functions?) A comparison of the performace of Petsc and matlab > > makes sense only if they are using the exact same methods. > > > > > > Thanks. > > > > -- > > Alejandro > > > > > > > > > > > > From gtg100n at mail.gatech.edu Thu Aug 23 09:36:07 2007 From: gtg100n at mail.gatech.edu (Alejandro Garzon) Date: Thu, 23 Aug 2007 10:36:07 -0400 Subject: |x1-x2|<=? Message-ID: <1187879767.46cd9b5783a8b@webmail.mail.gatech.edu> Hi, I have found two aproximations x1 and x2 to the solution of a linear system A*x=b by two different methods with the same relative residual "e". That is |A*x1 - b| < e*|b| and |A*x2 - b| < e*|b|. For debugging purposes I want to know if an upper bound for |x1 - x2| can be derived from the two inequalities above. I have gone this far in trying to find it: From the triangle inequality |A*x1 - b -(A*x2 - b)| <= |A*x1 - b| + |A*x2 - b| = 2*e*|b|, eliminating the b's in the left hand side, |A*(x1-x2)| <= 2*e*|b|, Does anybody know if from here a condition of the form |x1-x2| <= ? can be derived? Thanks -- Alejandro From zonexo at gmail.com Thu Aug 23 10:38:31 2007 From: zonexo at gmail.com (Ben Tay) Date: Thu, 23 Aug 2007 23:38:31 +0800 Subject: Error during example compilation of test examples Message-ID: <46CDA9F7.1060202@gmail.com> Hi, I got this error while trying to compile the test example in src/ksp/ksp/example/tutorials/ex1f /codes/petsc-2.3.3-p4/bin/win32fe/win32fe f90 -c -threads -debug:full -fpp:-m -I/codes/petsc-2.3.3-p4 -I/codes/petsc-2.3.3-p4/bmake/win32 -I/codes/petsc-2.3.3 -p4/include -I/codes/petsc-2.3.3-p4/include/mpiuni -o ex1f.o ex1f.F ex1f.i d:\cygwin\CODES\PETSC-~2.3-P\include/finclude/petscmat.h(492) : Error: This name does not have a type, and must have an explicit type. [MATOP_IS_STRUCTURALLY_ SYMMETRIC] parameter(MATOP_IS_STRUCTURALLY_SYMMETRIC=87) ----------------^ make: [ex1f.o] Error 1 (ignored) Also here on ex5f: --------------Error detected during compile or link!----------------------- See http://www.mcs.anl.gov/petsc/petsc-2/documentation/troubleshooting.html /codes/petsc-2.3.3-p4/bin/win32fe/win32fe f90 -c -I/codes/petsc-2.3.3-p4/include /finclude -threads -debug:full -fpp:-m -I/codes/petsc-2.3.3-p4 -I/codes/petsc-2 .3.3-p4/bmake/win32 -I/codes/petsc-2.3.3-p4/include -I/codes/petsc-2.3.3-p4/incl ude/mpiuni -o ex5f.o ex5f.F ex5f.i d:\cygwin\CODES\PETSC-~2.3-P\include/finclude/petscmat.h(492) : Error: This name does not have a type, and must have an explicit type. [MATOP_IS_STRUCTURALLY_ SYMMETRIC] parameter(MATOP_IS_STRUCTURALLY_SYMMETRIC=87) ----------------^ d:\cygwin\CODES\PETSC-~2.3-P\include/finclude/petscmat.h(492) : Error: This name does not have a type, and must have an explicit type. [MATOP_IS_STRUCTURALLY_ SYMMETRIC] parameter(MATOP_IS_STRUCTURALLY_SYMMETRIC=87) ----------------^ d:\cygwin\CODES\PETSC-~2.3-P\include/finclude/petscmat.h(492) : Error: This name does not have a type, and must have an explicit type. [MATOP_IS_STRUCTURALLY_ SYMMETRIC] parameter(MATOP_IS_STRUCTURALLY_SYMMETRIC=87) ----------------^ d:\cygwin\CODES\PETSC-~2.3-P\include/finclude/petscmat.h(492) : Error: This name does not have a type, and must have an explicit type. [MATOP_IS_STRUCTURALLY_ SYMMETRIC] parameter(MATOP_IS_STRUCTURALLY_SYMMETRIC=87) ----------------^ d:\cygwin\CODES\PETSC-~2.3-P\include/finclude/petscmat.h(492) : Error: This name does not have a type, and must have an explicit type. [MATOP_IS_STRUCTURALLY_ SYMMETRIC] parameter(MATOP_IS_STRUCTURALLY_SYMMETRIC=87) ----------------^ make[3]: [ex5f.o] Error 1 (ignored) Hope you can help. Thanks. From balay at mcs.anl.gov Thu Aug 23 12:30:08 2007 From: balay at mcs.anl.gov (Satish Balay) Date: Thu, 23 Aug 2007 12:30:08 -0500 (CDT) Subject: Error during example compilation of test examples In-Reply-To: <46CDA9F7.1060202@gmail.com> References: <46CDA9F7.1060202@gmail.com> Message-ID: I can't reproduce this error. Can you verify that finclude/petscmat.h is unmodified? It should have the following 2 lines - so the variable is declared correctly. PetscEnum MATOP_IS_STRUCTURALLY_SYMMETRIC (Line:384) parameter(MATOP_IS_STRUCTURALLY_SYMMETRIC=87) (Line:492) Satish -------- balay at parth ~/petsc-2.3.3-p4/src/ksp/ksp/examples/tutorials $ make ex1f /home/balay/petsc-2.3.3-p4/bin/win32fe/win32fe f90 -c -threads -debug:full -fpp:-m -I/home/balay/petsc-2.3.3-p4 -I/home/balay/petsc-2.3.3-p4/bmake/cygwin-ms -I/home/balay/petsc-2.3.3-p4/include -I/cygdrive/c/Program\ Files/MPICH/SDK/include -o ex1f.o ex1f.F ex1f.i /home/balay/petsc-2.3.3-p4/bin/win32fe/win32fe f90 -threads -debug:full -fpp:-m -o ex1f ex1f.o -L/home/balay/petsc-2.3.3-p4/lib/cygwin-ms -L/home/balay/petsc-2.3.3-p4/lib/cygwin-ms -lpetscksp -lpetscdm -lpetscmat -lpetscvec -lpetsc /cygdrive/c/Program\ Files/MPICH/SDK/lib/mpich.lib /cygdrive/c/Program\ Files/Intel/MKL/ia32/lib/mkl_s_dll.lib Gdi32.lib User32.lib Advapi32.lib Kernel32.lib Ws2_32.lib output_name: h:\home\balay\PETSC-~1.3-P\src\ksp\ksp\examples\TUTORI~1\ex1f.exe outfile: /usr/bin/rm -f ex1f.o balay at parth ~/petsc-2.3.3-p4/src/ksp/ksp/examples/tutorials $ ./ex1f KSP Object: type: gmres GMRES: restart=30, using Classical (unmodified) Gram-Schmidt Orthogonalization with no iterative refinement GMRES: happy breakdown tolerance 1e-030 maximum iterations=10000, initial guess is zero tolerances: relative=1e-007, absolute=1e-050, divergence=10000 left preconditioning PC Object: type: jacobi linear system matrix = precond matrix: Matrix Object: type=seqaij, rows=10, cols=10 total: nonzeros=28, allocated nonzeros=50 not using I-node routines Norm of error < 1.e-12,Iterations = 5 balay at parth ~/petsc-2.3.3-p4/src/ksp/ksp/examples/tutorials $ On Thu, 23 Aug 2007, Ben Tay wrote: > Hi, > > I got this error while trying to compile the test example in > src/ksp/ksp/example/tutorials/ex1f > > /codes/petsc-2.3.3-p4/bin/win32fe/win32fe f90 -c -threads -debug:full -fpp:-m > -I/codes/petsc-2.3.3-p4 -I/codes/petsc-2.3.3-p4/bmake/win32 > -I/codes/petsc-2.3.3 > -p4/include -I/codes/petsc-2.3.3-p4/include/mpiuni -o ex1f.o ex1f.F > ex1f.i > d:\cygwin\CODES\PETSC-~2.3-P\include/finclude/petscmat.h(492) : Error: This > name > does not have a type, and must have an explicit type. > [MATOP_IS_STRUCTURALLY_ > SYMMETRIC] > parameter(MATOP_IS_STRUCTURALLY_SYMMETRIC=87) > ----------------^ > make: [ex1f.o] Error 1 (ignored) > > Also here on ex5f: > > --------------Error detected during compile or link!----------------------- > See http://www.mcs.anl.gov/petsc/petsc-2/documentation/troubleshooting.html > /codes/petsc-2.3.3-p4/bin/win32fe/win32fe f90 -c > -I/codes/petsc-2.3.3-p4/include > /finclude -threads -debug:full -fpp:-m -I/codes/petsc-2.3.3-p4 > -I/codes/petsc-2 > .3.3-p4/bmake/win32 -I/codes/petsc-2.3.3-p4/include > -I/codes/petsc-2.3.3-p4/incl > ude/mpiuni -o ex5f.o ex5f.F > ex5f.i > d:\cygwin\CODES\PETSC-~2.3-P\include/finclude/petscmat.h(492) : Error: This > name > does not have a type, and must have an explicit type. > [MATOP_IS_STRUCTURALLY_ > SYMMETRIC] > parameter(MATOP_IS_STRUCTURALLY_SYMMETRIC=87) > ----------------^ > d:\cygwin\CODES\PETSC-~2.3-P\include/finclude/petscmat.h(492) : Error: This > name > does not have a type, and must have an explicit type. > [MATOP_IS_STRUCTURALLY_ > SYMMETRIC] > parameter(MATOP_IS_STRUCTURALLY_SYMMETRIC=87) > ----------------^ > d:\cygwin\CODES\PETSC-~2.3-P\include/finclude/petscmat.h(492) : Error: This > name > does not have a type, and must have an explicit type. > [MATOP_IS_STRUCTURALLY_ > SYMMETRIC] > parameter(MATOP_IS_STRUCTURALLY_SYMMETRIC=87) > ----------------^ > d:\cygwin\CODES\PETSC-~2.3-P\include/finclude/petscmat.h(492) : Error: This > name > does not have a type, and must have an explicit type. > [MATOP_IS_STRUCTURALLY_ > SYMMETRIC] > parameter(MATOP_IS_STRUCTURALLY_SYMMETRIC=87) > ----------------^ > d:\cygwin\CODES\PETSC-~2.3-P\include/finclude/petscmat.h(492) : Error: This > name > does not have a type, and must have an explicit type. > [MATOP_IS_STRUCTURALLY_ > SYMMETRIC] > parameter(MATOP_IS_STRUCTURALLY_SYMMETRIC=87) > ----------------^ > make[3]: [ex5f.o] Error 1 (ignored) > > Hope you can help. Thanks. > > > From knepley at gmail.com Thu Aug 23 18:49:04 2007 From: knepley at gmail.com (Matthew Knepley) Date: Thu, 23 Aug 2007 18:49:04 -0500 Subject: |x1-x2|<=? In-Reply-To: <1187879767.46cd9b5783a8b@webmail.mail.gatech.edu> References: <1187879767.46cd9b5783a8b@webmail.mail.gatech.edu> Message-ID: On 8/23/07, Alejandro Garzon wrote: > Hi, I have found two aproximations x1 and x2 to the solution of a linear system > A*x=b by two different methods with the same relative residual "e". That is > |A*x1 - b| < e*|b| and |A*x2 - b| < e*|b|. For debugging purposes I want to know > if an upper bound for |x1 - x2| can be derived from the two inequalities above. > I have gone this far in trying to find it: > > From the triangle inequality > > |A*x1 - b -(A*x2 - b)| <= |A*x1 - b| + |A*x2 - b| = 2*e*|b|, > > eliminating the b's in the left hand side, > > |A*(x1-x2)| <= 2*e*|b|, > > Does anybody know if from here a condition of the form > > |x1-x2| <= ? > > can be derived? This is exactly the condition number blowup of residual into error: |e| \le |A^{-1} r| |e| \le |A^{-1}| |r| which looks like the condition number of A. Matt > Thanks > -- > Alejandro > > > > > -- 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 From david.knezevic at balliol.ox.ac.uk Fri Aug 24 05:34:23 2007 From: david.knezevic at balliol.ox.ac.uk (David Knezevic) Date: Fri, 24 Aug 2007 11:34:23 +0100 Subject: Implementing an ADI method in parallel Message-ID: <46CEB42F.5020305@balliol.ox.ac.uk> Hello, I was hoping to get some advice on whether the following is possible in PETSc: I want to implement an ADI-like method, in which I want to do multiple uniprocessor linear solves concurrently (each linear solve is quite small, but there are a lot of them). This isn't what PETSc is designed for I guess, since one would typically do one large solve with multiple processors, but I was wondering if there is a good way of implementing this kind of ADI-like method in PETSc? Or should I instead implement this kind of thing using a serial linear solver, and control the concurrent solves with MPI? I'd prefer to stick to PETSc if possible, since it has so much nice functionality bundled in it, and has a lot of the MPI stuff already taken care of... Thanks very much for the help. Regards, David Knezevic From hzhang at mcs.anl.gov Fri Aug 24 09:02:35 2007 From: hzhang at mcs.anl.gov (Hong Zhang) Date: Fri, 24 Aug 2007 09:02:35 -0500 (CDT) Subject: Implementing an ADI method in parallel In-Reply-To: <46CEB42F.5020305@balliol.ox.ac.uk> References: <46CEB42F.5020305@balliol.ox.ac.uk> Message-ID: David, We are developing a 2D Fast Poisson Solver to be included in PETSc, for which, we apply sequential FFTW in x-direction, and concurrently solve multiple tridiagonal systems in y-direction, a kind of ADI-like parallel direct linear solver. This solver is developed jointly with an petsc user for an application in the plasma simulation. Can you give us little more details about your application? Hong On Fri, 24 Aug 2007, David Knezevic wrote: > Hello, > > I was hoping to get some advice on whether the following is possible in > PETSc: I want to implement an ADI-like method, in which I want to do > multiple uniprocessor linear solves concurrently (each linear solve is > quite small, but there are a lot of them). > > This isn't what PETSc is designed for I guess, since one would typically > do one large solve with multiple processors, but I was wondering if > there is a good way of implementing this kind of ADI-like method in > PETSc? Or should I instead implement this kind of thing using a serial > linear solver, and control the concurrent solves with MPI? I'd prefer to > stick to PETSc if possible, since it has so much nice functionality > bundled in it, and has a lot of the MPI stuff already taken care of... > > Thanks very much for the help. > > Regards, > David Knezevic > > From knepley at gmail.com Fri Aug 24 11:21:33 2007 From: knepley at gmail.com (Matthew Knepley) Date: Fri, 24 Aug 2007 11:21:33 -0500 Subject: Implementing an ADI method in parallel In-Reply-To: <46CEB42F.5020305@balliol.ox.ac.uk> References: <46CEB42F.5020305@balliol.ox.ac.uk> Message-ID: You can easily setup concurrent solves by splitting the communicator. For example, if you divide the communicator into two groups using MPI_Comm_split() and then create two KSP objects, each with a subcommunicator obtained from the split, Then these two solves can run concurrently. Thanks, Matt On 8/24/07, David Knezevic wrote: > Hello, > > I was hoping to get some advice on whether the following is possible in > PETSc: I want to implement an ADI-like method, in which I want to do > multiple uniprocessor linear solves concurrently (each linear solve is > quite small, but there are a lot of them). > > This isn't what PETSc is designed for I guess, since one would typically > do one large solve with multiple processors, but I was wondering if > there is a good way of implementing this kind of ADI-like method in > PETSc? Or should I instead implement this kind of thing using a serial > linear solver, and control the concurrent solves with MPI? I'd prefer to > stick to PETSc if possible, since it has so much nice functionality > bundled in it, and has a lot of the MPI stuff already taken care of... > > Thanks very much for the help. > > Regards, > David Knezevic > > -- 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 From balay at mcs.anl.gov Fri Aug 24 11:40:27 2007 From: balay at mcs.anl.gov (Satish Balay) Date: Fri, 24 Aug 2007 11:40:27 -0500 (CDT) Subject: Implementing an ADI method in parallel In-Reply-To: References: <46CEB42F.5020305@balliol.ox.ac.uk> Message-ID: Or for uniproc solves - you can create as many solver objects as you need with MPI_COMM_SELF or PETSC_COMM_SELF, on each proc Satish On Fri, 24 Aug 2007, Matthew Knepley wrote: > You can easily setup concurrent solves by splitting the communicator. For > example, if you divide the communicator into two groups using MPI_Comm_split() > and then create two KSP objects, each with a subcommunicator obtained from > the split, Then these two solves can run concurrently. > > Thanks, > > Matt > > On 8/24/07, David Knezevic wrote: > > Hello, > > > > I was hoping to get some advice on whether the following is possible in > > PETSc: I want to implement an ADI-like method, in which I want to do > > multiple uniprocessor linear solves concurrently (each linear solve is > > quite small, but there are a lot of them). > > > > This isn't what PETSc is designed for I guess, since one would typically > > do one large solve with multiple processors, but I was wondering if > > there is a good way of implementing this kind of ADI-like method in > > PETSc? Or should I instead implement this kind of thing using a serial > > linear solver, and control the concurrent solves with MPI? I'd prefer to > > stick to PETSc if possible, since it has so much nice functionality > > bundled in it, and has a lot of the MPI stuff already taken care of... > > > > Thanks very much for the help. > > > > Regards, > > David Knezevic > > > > > > > From david.knezevic at balliol.ox.ac.uk Fri Aug 24 11:58:29 2007 From: david.knezevic at balliol.ox.ac.uk (David Knezevic) Date: Fri, 24 Aug 2007 17:58:29 +0100 Subject: Implementing an ADI method in parallel In-Reply-To: References: <46CEB42F.5020305@balliol.ox.ac.uk> Message-ID: <46CF0E35.8080908@balliol.ox.ac.uk> > > Or for uniproc solves - you can create as many solver objects > as you need with MPI_COMM_SELF or PETSC_COMM_SELF, on each proc > Yep, I realised that after I sent the original email. It's working great so far! Thanks! Cheers, David >> On 8/24/07, David Knezevic wrote: >> >>> Hello, >>> >>> I was hoping to get some advice on whether the following is possible in >>> PETSc: I want to implement an ADI-like method, in which I want to do >>> multiple uniprocessor linear solves concurrently (each linear solve is >>> quite small, but there are a lot of them). >>> >>> This isn't what PETSc is designed for I guess, since one would typically >>> do one large solve with multiple processors, but I was wondering if >>> there is a good way of implementing this kind of ADI-like method in >>> PETSc? Or should I instead implement this kind of thing using a serial >>> linear solver, and control the concurrent solves with MPI? I'd prefer to >>> stick to PETSc if possible, since it has so much nice functionality >>> bundled in it, and has a lot of the MPI stuff already taken care of... >>> >>> Thanks very much for the help. >>> >>> Regards, >>> David Knezevic >>> >>> >>> >> >> > > > From zonexo at gmail.com Fri Aug 24 22:19:47 2007 From: zonexo at gmail.com (Ben Tay) Date: Sat, 25 Aug 2007 11:19:47 +0800 Subject: Routine to convert matrix to CSR format Message-ID: <46CF9FD3.7030000@gmail.com> Hi, May I know if there's a routine which can convert a matrix initially created using MatCreateSeqAIJ to compressed row format (CSR) ? Then I would like to view it in my visual fortran debugger. In other words, the matrix is in standard array format, not Mat. Thanks From zonexo at gmail.com Fri Aug 24 22:37:17 2007 From: zonexo at gmail.com (Ben Tay) Date: Sat, 25 Aug 2007 11:37:17 +0800 Subject: Best way to find empty row in matrix Message-ID: <46CFA3ED.1080505@gmail.com> Hi, when KSPSolve is called, I got the following errors: Detected zero pivot in LU factorization Empty row in matrix! There's definitely some errors in the code, but I just can't detect it. PETSc does not tell me which row. How can I find out? Btw, I'm working in visual fortran Thank you From zonexo at gmail.com Fri Aug 24 23:09:05 2007 From: zonexo at gmail.com (Ben Tay) Date: Sat, 25 Aug 2007 12:09:05 +0800 Subject: Error during example compilation of test examples In-Reply-To: References: <46CDA9F7.1060202@gmail.com> Message-ID: <46CFAB61.8000901@gmail.com> Hi, I didn't touch the petscmat.h and I've verified that the 2 lines are there. Could it be some compilation error of PETSc? I can send in the configure.log if required. thanks. Satish Balay wrote: > I can't reproduce this error. Can you verify that finclude/petscmat.h > is unmodified? > > It should have the following 2 lines - so the variable is > declared correctly. > > PetscEnum MATOP_IS_STRUCTURALLY_SYMMETRIC (Line:384) > parameter(MATOP_IS_STRUCTURALLY_SYMMETRIC=87) (Line:492) > > Satish > > -------- > > balay at parth ~/petsc-2.3.3-p4/src/ksp/ksp/examples/tutorials > $ make ex1f > /home/balay/petsc-2.3.3-p4/bin/win32fe/win32fe f90 -c -threads -debug:full -fpp:-m -I/home/balay/petsc-2.3.3-p4 -I/home/balay/petsc-2.3.3-p4/bmake/cygwin-ms -I/home/balay/petsc-2.3.3-p4/include -I/cygdrive/c/Program\ Files/MPICH/SDK/include -o ex1f.o ex1f.F > ex1f.i > /home/balay/petsc-2.3.3-p4/bin/win32fe/win32fe f90 -threads -debug:full -fpp:-m -o ex1f ex1f.o -L/home/balay/petsc-2.3.3-p4/lib/cygwin-ms -L/home/balay/petsc-2.3.3-p4/lib/cygwin-ms -lpetscksp -lpetscdm -lpetscmat -lpetscvec -lpetsc /cygdrive/c/Program\ Files/MPICH/SDK/lib/mpich.lib /cygdrive/c/Program\ Files/Intel/MKL/ia32/lib/mkl_s_dll.lib Gdi32.lib User32.lib Advapi32.lib Kernel32.lib Ws2_32.lib > output_name: h:\home\balay\PETSC-~1.3-P\src\ksp\ksp\examples\TUTORI~1\ex1f.exe > outfile: > /usr/bin/rm -f ex1f.o > > balay at parth ~/petsc-2.3.3-p4/src/ksp/ksp/examples/tutorials > $ ./ex1f > KSP Object: > type: gmres > GMRES: restart=30, using Classical (unmodified) Gram-Schmidt Orthogonalization with no iterative refinement > GMRES: happy breakdown tolerance 1e-030 > maximum iterations=10000, initial guess is zero > tolerances: relative=1e-007, absolute=1e-050, divergence=10000 > left preconditioning > PC Object: > type: jacobi > linear system matrix = precond matrix: > Matrix Object: > type=seqaij, rows=10, cols=10 > total: nonzeros=28, allocated nonzeros=50 > not using I-node routines > Norm of error < 1.e-12,Iterations = 5 > > balay at parth ~/petsc-2.3.3-p4/src/ksp/ksp/examples/tutorials > $ > > > > On Thu, 23 Aug 2007, Ben Tay wrote: > > >> Hi, >> >> I got this error while trying to compile the test example in >> src/ksp/ksp/example/tutorials/ex1f >> >> /codes/petsc-2.3.3-p4/bin/win32fe/win32fe f90 -c -threads -debug:full -fpp:-m >> -I/codes/petsc-2.3.3-p4 -I/codes/petsc-2.3.3-p4/bmake/win32 >> -I/codes/petsc-2.3.3 >> -p4/include -I/codes/petsc-2.3.3-p4/include/mpiuni -o ex1f.o ex1f.F >> ex1f.i >> d:\cygwin\CODES\PETSC-~2.3-P\include/finclude/petscmat.h(492) : Error: This >> name >> does not have a type, and must have an explicit type. >> [MATOP_IS_STRUCTURALLY_ >> SYMMETRIC] >> parameter(MATOP_IS_STRUCTURALLY_SYMMETRIC=87) >> ----------------^ >> make: [ex1f.o] Error 1 (ignored) >> >> Also here on ex5f: >> >> --------------Error detected during compile or link!----------------------- >> See http://www.mcs.anl.gov/petsc/petsc-2/documentation/troubleshooting.html >> /codes/petsc-2.3.3-p4/bin/win32fe/win32fe f90 -c >> -I/codes/petsc-2.3.3-p4/include >> /finclude -threads -debug:full -fpp:-m -I/codes/petsc-2.3.3-p4 >> -I/codes/petsc-2 >> .3.3-p4/bmake/win32 -I/codes/petsc-2.3.3-p4/include >> -I/codes/petsc-2.3.3-p4/incl >> ude/mpiuni -o ex5f.o ex5f.F >> ex5f.i >> d:\cygwin\CODES\PETSC-~2.3-P\include/finclude/petscmat.h(492) : Error: This >> name >> does not have a type, and must have an explicit type. >> [MATOP_IS_STRUCTURALLY_ >> SYMMETRIC] >> parameter(MATOP_IS_STRUCTURALLY_SYMMETRIC=87) >> ----------------^ >> d:\cygwin\CODES\PETSC-~2.3-P\include/finclude/petscmat.h(492) : Error: This >> name >> does not have a type, and must have an explicit type. >> [MATOP_IS_STRUCTURALLY_ >> SYMMETRIC] >> parameter(MATOP_IS_STRUCTURALLY_SYMMETRIC=87) >> ----------------^ >> d:\cygwin\CODES\PETSC-~2.3-P\include/finclude/petscmat.h(492) : Error: This >> name >> does not have a type, and must have an explicit type. >> [MATOP_IS_STRUCTURALLY_ >> SYMMETRIC] >> parameter(MATOP_IS_STRUCTURALLY_SYMMETRIC=87) >> ----------------^ >> d:\cygwin\CODES\PETSC-~2.3-P\include/finclude/petscmat.h(492) : Error: This >> name >> does not have a type, and must have an explicit type. >> [MATOP_IS_STRUCTURALLY_ >> SYMMETRIC] >> parameter(MATOP_IS_STRUCTURALLY_SYMMETRIC=87) >> ----------------^ >> d:\cygwin\CODES\PETSC-~2.3-P\include/finclude/petscmat.h(492) : Error: This >> name >> does not have a type, and must have an explicit type. >> [MATOP_IS_STRUCTURALLY_ >> SYMMETRIC] >> parameter(MATOP_IS_STRUCTURALLY_SYMMETRIC=87) >> ----------------^ >> make[3]: [ex5f.o] Error 1 (ignored) >> >> Hope you can help. Thanks. >> >> >> >> > > > From hzhang at mcs.anl.gov Sat Aug 25 16:36:08 2007 From: hzhang at mcs.anl.gov (Hong Zhang) Date: Sat, 25 Aug 2007 16:36:08 -0500 (CDT) Subject: Routine to convert matrix to CSR format In-Reply-To: <46CF9FD3.7030000@gmail.com> References: <46CF9FD3.7030000@gmail.com> Message-ID: You can use MatGetRowIJ() (http://www-unix.mcs.anl.gov/petsc/petsc-as/snapshots/petsc-current/docs/manualpages/Mat/MatGetRowIJ.html) and MatGetArray() (http://www-unix.mcs.anl.gov/petsc/petsc-as/snapshots/petsc-current/docs/manualpages/Mat/MatGetArray.html#MatGetArray) Hong On Sat, 25 Aug 2007, Ben Tay wrote: > Hi, > > May I know if there's a routine which can convert a matrix initially > created using MatCreateSeqAIJ to compressed row format (CSR) ? Then I > would like to view it in my visual fortran debugger. In other words, the > matrix is in standard array format, not Mat. > > Thanks > > From hzhang at mcs.anl.gov Sat Aug 25 16:51:06 2007 From: hzhang at mcs.anl.gov (Hong Zhang) Date: Sat, 25 Aug 2007 16:51:06 -0500 (CDT) Subject: Best way to find empty row in matrix In-Reply-To: <46CFA3ED.1080505@gmail.com> References: <46CFA3ED.1080505@gmail.com> Message-ID: Your matrix might have an empty row. If your matrix indeed has an empty row, you need set val=0 to the diagonal entry. When petsc LU or ILU detects a zero, it should give an error of type [0]PETSC ERROR: Detected zero pivot in LU factorization see http://www.mcs.anl.gov/petsc/petsc-as/documentation/troubleshooting.html#ZeroPivot! [0]PETSC ERROR: Zero pivot row 1 value 0 tolerance 3e-12 * rowsum 3! When this happens, you can use '-pc_factor_shift_nonzero ' or '-pc_factor_shift_positive_definite' to add an artificial shift. Hong On Sat, 25 Aug 2007, Ben Tay wrote: > Hi, > > when KSPSolve is called, I got the following errors: > > Detected zero pivot in LU factorization > > Empty row in matrix! > > There's definitely some errors in the code, but I just can't detect it. > PETSc does not tell me which row. How can I find out? Btw, I'm working > in visual fortran > > Thank you > > From keita at cray.com Sun Aug 26 21:29:21 2007 From: keita at cray.com (Keita Teranishi) Date: Sun, 26 Aug 2007 21:29:21 -0500 Subject: Unable to download MUMPS Message-ID: <925346A443D4E340BEB20248BAFCDBDF0216C69B@CFEVS1-IP.americas.cray.com> Hi, I am getting the following error message when running confugre script. Is there any problem with the ftp server at ANL? Thanks, Keita Teranishi, Ph.D. Math Software Group Cray Inc. Email: keita at cray.com TESTING: configureLibrary from PETSc.packages.MUMPS(/cray/iss/tmp/Keita/petsc-2.3.3-p3/python/PETSc/package.py:296) ********************************************************************************* UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for details): --------------------------------------------------------------------------------------- Unable to download mumps from locations ['ftp://ftp.mcs.anl.gov/pub/petsc/externalpackages/MUMPS_4.7.3.tar.gz'] Failed to download ftp://ftp.mcs.anl.gov/pub/petsc/externalpackages/MUMPS_4.7.3.tar.gz Unable to download MUMPS You may be off the network. Connect to the internet and run config/configure.py again or put in the directory /cray/iss/tmp/Keita/petsc-2.3.3-p3/externalpackages the uncompressed, untared file obtained from ftp://ftp.mcs.anl.gov/pub/petsc/externalpackages/MUMPS_4.7.3.tar.gz ********************************************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From balay at mcs.anl.gov Sun Aug 26 21:44:27 2007 From: balay at mcs.anl.gov (Satish Balay) Date: Sun, 26 Aug 2007 21:44:27 -0500 (CDT) Subject: Unable to download MUMPS In-Reply-To: <925346A443D4E340BEB20248BAFCDBDF0216C69B@CFEVS1-IP.americas.cray.com> References: <925346A443D4E340BEB20248BAFCDBDF0216C69B@CFEVS1-IP.americas.cray.com> Message-ID: I'm able to obtain the file with wget - so the ftp server is functional. Can you try downloading the file with wget? Perhaps some firewall rules on your side prevents this download? Satish On Sun, 26 Aug 2007, Keita Teranishi wrote: > Hi, > > > > I am getting the following error message when running confugre script. Is there any problem with the ftp server at ANL? > > > > Thanks, > > > > Keita Teranishi, Ph.D. > > Math Software Group > > Cray Inc. > > Email: keita at cray.com > > > > TESTING: configureLibrary from PETSc.packages.MUMPS(/cray/iss/tmp/Keita/petsc-2.3.3-p3/python/PETSc/package.py:296) > > ********************************************************************************* > > UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for details): > > --------------------------------------------------------------------------------------- > > Unable to download mumps from locations ['ftp://ftp.mcs.anl.gov/pub/petsc/externalpackages/MUMPS_4.7.3.tar.gz'] > > Failed to download ftp://ftp.mcs.anl.gov/pub/petsc/externalpackages/MUMPS_4.7.3.tar.gz > > Unable to download MUMPS > > You may be off the network. Connect to the internet and run config/configure.py again > > or put in the directory /cray/iss/tmp/Keita/petsc-2.3.3-p3/externalpackages the uncompressed, untared file obtained > > from ftp://ftp.mcs.anl.gov/pub/petsc/externalpackages/MUMPS_4.7.3.tar.gz > > ********************************************************************************* > > From keita at cray.com Sun Aug 26 22:25:44 2007 From: keita at cray.com (Keita Teranishi) Date: Sun, 26 Aug 2007 22:25:44 -0500 Subject: Unable to download MUMPS In-Reply-To: References: <925346A443D4E340BEB20248BAFCDBDF0216C69B@CFEVS1-IP.americas.cray.com> Message-ID: <925346A443D4E340BEB20248BAFCDBDF0216C6AF@CFEVS1-IP.americas.cray.com> Satish, I was able to obtain the tar ball through wget. Thanks, Keita -----Original Message----- From: owner-petsc-users at mcs.anl.gov [mailto:owner-petsc-users at mcs.anl.gov] On Behalf Of Satish Balay Sent: Monday, August 27, 2007 11:44 AM To: petsc-users at mcs.anl.gov Subject: Re: Unable to download MUMPS I'm able to obtain the file with wget - so the ftp server is functional. Can you try downloading the file with wget? Perhaps some firewall rules on your side prevents this download? Satish On Sun, 26 Aug 2007, Keita Teranishi wrote: > Hi, > > > > I am getting the following error message when running confugre script. Is there any problem with the ftp server at ANL? > > > > Thanks, > > > > Keita Teranishi, Ph.D. > > Math Software Group > > Cray Inc. > > Email: keita at cray.com > > > > TESTING: configureLibrary from PETSc.packages.MUMPS(/cray/iss/tmp/Keita/petsc-2.3.3-p3/python/PETSc/package.py:296) > > ********************************************************************************* > > UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for details): > > --------------------------------------------------------------------------------------- > > Unable to download mumps from locations ['ftp://ftp.mcs.anl.gov/pub/petsc/externalpackages/MUMPS_4.7.3.tar.gz'] > > Failed to download ftp://ftp.mcs.anl.gov/pub/petsc/externalpackages/MUMPS_4.7.3.tar.gz > > Unable to download MUMPS > > You may be off the network. Connect to the internet and run config/configure.py again > > or put in the directory /cray/iss/tmp/Keita/petsc-2.3.3-p3/externalpackages the uncompressed, untared file obtained > > from ftp://ftp.mcs.anl.gov/pub/petsc/externalpackages/MUMPS_4.7.3.tar.gz > > ********************************************************************************* > > From keita at cray.com Mon Aug 27 00:02:00 2007 From: keita at cray.com (Keita Teranishi) Date: Mon, 27 Aug 2007 00:02:00 -0500 Subject: hypre and PETSc's FORTRAN Interface Message-ID: <925346A443D4E340BEB20248BAFCDBDF0216C6C4@CFEVS1-IP.americas.cray.com> Hi, I am trying to build petsc with FORTRAN interface and hypre together, but having a configure error message due to language compatibility between FORTRAN and C++. More precisely, the configure script complains that PETSc's FORTRAN interface cannot be linked to some C++ objects of hypre. I thought the latest version of hypre is implemented in C except some optional packages such as Babel. If this is right, we could use FOTRAN interface to use PETSc and hypre together. I would like to know how PETSc accesses to hypre. Thanks, Keita -------------- next part -------------- An HTML attachment was scrubbed... URL: From keita at cray.com Mon Aug 27 03:52:43 2007 From: keita at cray.com (Keita Teranishi) Date: Mon, 27 Aug 2007 03:52:43 -0500 Subject: hypre and PETSc's FORTRAN Interface (PLEASE IGNORE MY PREVIOUS EMAIL WITH SAME TITLE!) In-Reply-To: <925346A443D4E340BEB20248BAFCDBDF0216C6C4@CFEVS1-IP.americas.cray.com> References: <925346A443D4E340BEB20248BAFCDBDF0216C6C4@CFEVS1-IP.americas.cray.com> Message-ID: <925346A443D4E340BEB20248BAFCDBDF0216C6E2@CFEVS1-IP.americas.cray.com> Hi, Please ignore my previous email. I found the error was related to hypre's configure script (not PETSc). I found PETSc configure script disables Babel for installing hypre. Sorry, Keita ________________________________ From: owner-petsc-users at mcs.anl.gov [mailto:owner-petsc-users at mcs.anl.gov] On Behalf Of Keita Teranishi Sent: Monday, August 27, 2007 2:02 PM To: petsc-users at mcs.anl.gov Subject: hypre and PETSc's FORTRAN Interface Hi, I am trying to build petsc with FORTRAN interface and hypre together, but having a configure error message due to language compatibility between FORTRAN and C++. More precisely, the configure script complains that PETSc's FORTRAN interface cannot be linked to some C++ objects of hypre. I thought the latest version of hypre is implemented in C except some optional packages such as Babel. If this is right, we could use FOTRAN interface to use PETSc and hypre together. I would like to know how PETSc accesses to hypre. Thanks, Keita -------------- next part -------------- An HTML attachment was scrubbed... URL: From zonexo at gmail.com Mon Aug 27 06:19:06 2007 From: zonexo at gmail.com (Ben Tay) Date: Mon, 27 Aug 2007 19:19:06 +0800 Subject: Is this the correct way to use MatGetRow? Something wrong here Message-ID: <46D2B32A.1000704@gmail.com> Hi, I'm trying to view a particular row of a matrix. This 's what I do in my loops: real(8):: vector(64) II=36 impl_mat_i=4. call MatSetValue(A_mat_uv,II,II,impl_mat_i,ADD_VALUES,ierr) call MatAssemblyBegin(A_mat_uv,MAT_FINAL_ASSEMBLY,ierr) call MatAssemblyEnd(A_mat_uv,MAT_FINAL_ASSEMBLY,ierr) call MatGetRow(A_mat_uv,II,PETSC_NULL,PETSC_NULL,vector,ierr) call MatRestoreRow(A_mat_uv,II,PETSC_NULL,PETSC_NULL,vector,ierr) When I look at "vector" using visual fortran debugger, I saw many different values in it, but I only added 1 value in 1 location. However, just before I use MatSetValue, I also called MatGetRow. It was initially all zero. But, if I use call MatSetValue(A_mat_uv,II,*1*,impl_mat_i,ADD_VALUES,ierr) instead of II, I see only 4 in vector(1). What happening? Where did all the other values come from? Also, is this the best way to view a particular row of a matrix? I tried to use call MatGetValues(A_mat_uv,1,36,64,1,vector,ierr) to get 1 row of values from the 36th row.There are 64 columns in total. Seems like it's the wrong way. Can you please show me the correct way? Thank you. From balay at mcs.anl.gov Mon Aug 27 08:46:24 2007 From: balay at mcs.anl.gov (Satish Balay) Date: Mon, 27 Aug 2007 08:46:24 -0500 (CDT) Subject: hypre and PETSc's FORTRAN Interface (PLEASE IGNORE MY PREVIOUS EMAIL WITH SAME TITLE!) In-Reply-To: <925346A443D4E340BEB20248BAFCDBDF0216C6E2@CFEVS1-IP.americas.cray.com> References: <925346A443D4E340BEB20248BAFCDBDF0216C6C4@CFEVS1-IP.americas.cray.com> <925346A443D4E340BEB20248BAFCDBDF0216C6E2@CFEVS1-IP.americas.cray.com> Message-ID: If you download hypre tarball [from PETSc website] manually - its best to install it with PETSc configure - with the option: --download-hypre=/path-to/hypre.tar.gz Satish On Mon, 27 Aug 2007, Keita Teranishi wrote: > Hi, > > > > Please ignore my previous email. I found the error was related to hypre's configure script (not PETSc). I found PETSc configure script disables Babel for installing hypre. > > > > Sorry, > > > > Keita > > > > > > > > > > ________________________________ > > From: owner-petsc-users at mcs.anl.gov [mailto:owner-petsc-users at mcs.anl.gov] On Behalf Of Keita Teranishi > Sent: Monday, August 27, 2007 2:02 PM > To: petsc-users at mcs.anl.gov > Subject: hypre and PETSc's FORTRAN Interface > > > > Hi, > > > > I am trying to build petsc with FORTRAN interface and hypre together, but having a configure error message due to language compatibility between FORTRAN and C++. More precisely, the configure script complains that PETSc's FORTRAN interface cannot be linked to some C++ objects of hypre. I thought the latest version of hypre is implemented in C except some optional packages such as Babel. If this is right, we could use FOTRAN interface to use PETSc and hypre together. > > I would like to know how PETSc accesses to hypre. > > > > Thanks, > > > > Keita > > From hzhang at mcs.anl.gov Mon Aug 27 09:00:24 2007 From: hzhang at mcs.anl.gov (Hong Zhang) Date: Mon, 27 Aug 2007 09:00:24 -0500 (CDT) Subject: Is this the correct way to use MatGetRow? Something wrong here In-Reply-To: <46D2B32A.1000704@gmail.com> References: <46D2B32A.1000704@gmail.com> Message-ID: See ~petsc/src/mat/examples/tests/ex58f.F on how to use MatGetRow() from Fortran. Hong On Mon, 27 Aug 2007, Ben Tay wrote: > Hi, > > I'm trying to view a particular row of a matrix. This 's what I do in my > loops: > > real(8):: vector(64) > > II=36 > > impl_mat_i=4. > > call MatSetValue(A_mat_uv,II,II,impl_mat_i,ADD_VALUES,ierr) > > call MatAssemblyBegin(A_mat_uv,MAT_FINAL_ASSEMBLY,ierr) > > call MatAssemblyEnd(A_mat_uv,MAT_FINAL_ASSEMBLY,ierr) > > > call MatGetRow(A_mat_uv,II,PETSC_NULL,PETSC_NULL,vector,ierr) > > call MatRestoreRow(A_mat_uv,II,PETSC_NULL,PETSC_NULL,vector,ierr) > > When I look at "vector" using visual fortran debugger, I saw many > different values in it, but I only added 1 value in 1 location. However, > just before I use MatSetValue, I also called MatGetRow. It was initially > all zero. > > But, if I use call > MatSetValue(A_mat_uv,II,*1*,impl_mat_i,ADD_VALUES,ierr) instead of II, I > see only 4 in vector(1). > > What happening? Where did all the other values come from? Also, is this > the best way to view a particular row of a matrix? I tried to use > > call MatGetValues(A_mat_uv,1,36,64,1,vector,ierr) to get 1 row of values > from the 36th row.There are 64 columns in total. Seems like it's the > wrong way. Can you please show me the correct way? > > Thank you. > > From zonexo at gmail.com Mon Aug 27 09:51:57 2007 From: zonexo at gmail.com (Ben Tay) Date: Mon, 27 Aug 2007 22:51:57 +0800 Subject: Is this the correct way to use MatGetRow? Something wrong here In-Reply-To: References: <46D2B32A.1000704@gmail.com> Message-ID: <46D2E50D.6010808@gmail.com> Thanks Zhang Hong! I've got it working. Hong Zhang wrote: > See ~petsc/src/mat/examples/tests/ex58f.F on > how to use MatGetRow() from Fortran. > > Hong > > On Mon, 27 Aug 2007, Ben Tay wrote: > > >> Hi, >> >> I'm trying to view a particular row of a matrix. This 's what I do in my >> loops: >> >> real(8):: vector(64) >> >> II=36 >> >> impl_mat_i=4. >> >> call MatSetValue(A_mat_uv,II,II,impl_mat_i,ADD_VALUES,ierr) >> >> call MatAssemblyBegin(A_mat_uv,MAT_FINAL_ASSEMBLY,ierr) >> >> call MatAssemblyEnd(A_mat_uv,MAT_FINAL_ASSEMBLY,ierr) >> >> >> call MatGetRow(A_mat_uv,II,PETSC_NULL,PETSC_NULL,vector,ierr) >> >> call MatRestoreRow(A_mat_uv,II,PETSC_NULL,PETSC_NULL,vector,ierr) >> >> When I look at "vector" using visual fortran debugger, I saw many >> different values in it, but I only added 1 value in 1 location. However, >> just before I use MatSetValue, I also called MatGetRow. It was initially >> all zero. >> >> But, if I use call >> MatSetValue(A_mat_uv,II,*1*,impl_mat_i,ADD_VALUES,ierr) instead of II, I >> see only 4 in vector(1). >> >> What happening? Where did all the other values come from? Also, is this >> the best way to view a particular row of a matrix? I tried to use >> >> call MatGetValues(A_mat_uv,1,36,64,1,vector,ierr) to get 1 row of values >> from the 36th row.There are 64 columns in total. Seems like it's the >> wrong way. Can you please show me the correct way? >> >> Thank you. >> >> >> > > > From keita at cray.com Mon Aug 27 09:56:06 2007 From: keita at cray.com (Keita Teranishi) Date: Mon, 27 Aug 2007 09:56:06 -0500 Subject: hypre and PETSc's FORTRAN Interface (PLEASE IGNORE MY PREVIOUS EMAIL WITH SAME TITLE!) In-Reply-To: References: <925346A443D4E340BEB20248BAFCDBDF0216C6C4@CFEVS1-IP.americas.cray.com> <925346A443D4E340BEB20248BAFCDBDF0216C6E2@CFEVS1-IP.americas.cray.com> Message-ID: <925346A443D4E340BEB20248BAFCDBDF0216C865@CFEVS1-IP.americas.cray.com> Hi Satish, Our environment requires cross compiling, set by --with-batch option for PETSc's configure. However, it doesn't set the correct cross-compiling option for hypre's configure script (--host). I am wondering if this happen only for our environment... Thanks, Keita -----Original Message----- From: owner-petsc-users at mcs.anl.gov [mailto:owner-petsc-users at mcs.anl.gov] On Behalf Of Satish Balay Sent: Monday, August 27, 2007 10:46 PM To: petsc-users at mcs.anl.gov Subject: RE: hypre and PETSc's FORTRAN Interface (PLEASE IGNORE MY PREVIOUS EMAIL WITH SAME TITLE!) If you download hypre tarball [from PETSc website] manually - its best to install it with PETSc configure - with the option: --download-hypre=/path-to/hypre.tar.gz Satish On Mon, 27 Aug 2007, Keita Teranishi wrote: > Hi, > > > > Please ignore my previous email. I found the error was related to hypre's configure script (not PETSc). I found PETSc configure script disables Babel for installing hypre. > > > > Sorry, > > > > Keita > > > > > > > > > > ________________________________ > > From: owner-petsc-users at mcs.anl.gov [mailto:owner-petsc-users at mcs.anl.gov] On Behalf Of Keita Teranishi > Sent: Monday, August 27, 2007 2:02 PM > To: petsc-users at mcs.anl.gov > Subject: hypre and PETSc's FORTRAN Interface > > > > Hi, > > > > I am trying to build petsc with FORTRAN interface and hypre together, but having a configure error message due to language compatibility between FORTRAN and C++. More precisely, the configure script complains that PETSc's FORTRAN interface cannot be linked to some C++ objects of hypre. I thought the latest version of hypre is implemented in C except some optional packages such as Babel. If this is right, we could use FOTRAN interface to use PETSc and hypre together. > > I would like to know how PETSc accesses to hypre. > > > > Thanks, > > > > Keita > > From balay at mcs.anl.gov Mon Aug 27 09:59:21 2007 From: balay at mcs.anl.gov (Satish Balay) Date: Mon, 27 Aug 2007 09:59:21 -0500 (CDT) Subject: hypre and PETSc's FORTRAN Interface (PLEASE IGNORE MY PREVIOUS EMAIL WITH SAME TITLE!) In-Reply-To: <925346A443D4E340BEB20248BAFCDBDF0216C865@CFEVS1-IP.americas.cray.com> References: <925346A443D4E340BEB20248BAFCDBDF0216C6C4@CFEVS1-IP.americas.cray.com> <925346A443D4E340BEB20248BAFCDBDF0216C6E2@CFEVS1-IP.americas.cray.com> <925346A443D4E340BEB20248BAFCDBDF0216C865@CFEVS1-IP.americas.cray.com> Message-ID: We haven't explored cross compiling of external packages - so this support in PETSc configure is not there.. satish On Mon, 27 Aug 2007, Keita Teranishi wrote: > Hi Satish, > > Our environment requires cross compiling, set by --with-batch option for PETSc's configure. However, it doesn't set the correct cross-compiling option for hypre's configure script (--host). I am wondering if this happen only for our environment... > > Thanks, > > Keita > > -----Original Message----- > From: owner-petsc-users at mcs.anl.gov [mailto:owner-petsc-users at mcs.anl.gov] On Behalf Of Satish Balay > Sent: Monday, August 27, 2007 10:46 PM > To: petsc-users at mcs.anl.gov > Subject: RE: hypre and PETSc's FORTRAN Interface (PLEASE IGNORE MY PREVIOUS EMAIL WITH SAME TITLE!) > > If you download hypre tarball [from PETSc website] manually - its > best to install it with PETSc configure - with the option: > > --download-hypre=/path-to/hypre.tar.gz > > Satish > > On Mon, 27 Aug 2007, Keita Teranishi wrote: > > > Hi, > > > > > > > > Please ignore my previous email. I found the error was related to hypre's configure script (not PETSc). I found PETSc configure script disables Babel for installing hypre. > > > > > > > > Sorry, > > > > > > > > Keita > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > From: owner-petsc-users at mcs.anl.gov [mailto:owner-petsc-users at mcs.anl.gov] On Behalf Of Keita Teranishi > > Sent: Monday, August 27, 2007 2:02 PM > > To: petsc-users at mcs.anl.gov > > Subject: hypre and PETSc's FORTRAN Interface > > > > > > > > Hi, > > > > > > > > I am trying to build petsc with FORTRAN interface and hypre together, but having a configure error message due to language compatibility between FORTRAN and C++. More precisely, the configure script complains that PETSc's FORTRAN interface cannot be linked to some C++ objects of hypre. I thought the latest version of hypre is implemented in C except some optional packages such as Babel. If this is right, we could use FOTRAN interface to use PETSc and hypre together. > > > > I would like to know how PETSc accesses to hypre. > > > > > > > > Thanks, > > > > > > > > Keita > > > > > > From knepley at gmail.com Mon Aug 27 10:38:00 2007 From: knepley at gmail.com (Matthew Knepley) Date: Mon, 27 Aug 2007 10:38:00 -0500 Subject: hypre and PETSc's FORTRAN Interface In-Reply-To: <925346A443D4E340BEB20248BAFCDBDF0216C6C4@CFEVS1-IP.americas.cray.com> References: <925346A443D4E340BEB20248BAFCDBDF0216C6C4@CFEVS1-IP.americas.cray.com> Message-ID: This belongs on petsc-maint. Please send the configure.log, Thanks, Matt On 8/27/07, Keita Teranishi wrote: > > > > > Hi, > > > > I am trying to build petsc with FORTRAN interface and hypre together, but > having a configure error message due to language compatibility between > FORTRAN and C++. More precisely, the configure script complains that > PETSc's FORTRAN interface cannot be linked to some C++ objects of hypre. I > thought the latest version of hypre is implemented in C except some optional > packages such as Babel. If this is right, we could use FOTRAN interface to > use PETSc and hypre together. > > I would like to know how PETSc accesses to hypre. > > > > Thanks, > > > > Keita -- 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 From bsmith at mcs.anl.gov Mon Aug 27 12:22:32 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Mon, 27 Aug 2007 12:22:32 -0500 (CDT) Subject: hypre and PETSc's FORTRAN Interface (PLEASE IGNORE MY PREVIOUS EMAIL WITH SAME TITLE!) In-Reply-To: <925346A443D4E340BEB20248BAFCDBDF0216C865@CFEVS1-IP.americas.cray.com> References: <925346A443D4E340BEB20248BAFCDBDF0216C6C4@CFEVS1-IP.americas.cray.com> <925346A443D4E340BEB20248BAFCDBDF0216C6E2@CFEVS1-IP.americas.cray.com> <925346A443D4E340BEB20248BAFCDBDF0216C865@CFEVS1-IP.americas.cray.com> Message-ID: Keita, If you know the correct options with --host that are needed you can try adding them to python/PETSc/packages/hypre.py as additional arguments when --with-batch is on. We haven't done this ourselves because we are not familar with this feature of auto-conf. Please send us your results and we'll add them to petsc-dev. Thanks and take care, Barry On Mon, 27 Aug 2007, Keita Teranishi wrote: > Hi Satish, > > Our environment requires cross compiling, set by --with-batch option for PETSc's configure. However, it doesn't set the correct cross-compiling option for hypre's configure script (--host). I am wondering if this happen only for our environment... > > Thanks, > > Keita > > -----Original Message----- > From: owner-petsc-users at mcs.anl.gov [mailto:owner-petsc-users at mcs.anl.gov] On Behalf Of Satish Balay > Sent: Monday, August 27, 2007 10:46 PM > To: petsc-users at mcs.anl.gov > Subject: RE: hypre and PETSc's FORTRAN Interface (PLEASE IGNORE MY PREVIOUS EMAIL WITH SAME TITLE!) > > If you download hypre tarball [from PETSc website] manually - its > best to install it with PETSc configure - with the option: > > --download-hypre=/path-to/hypre.tar.gz > > Satish > > On Mon, 27 Aug 2007, Keita Teranishi wrote: > > > Hi, > > > > > > > > Please ignore my previous email. I found the error was related to hypre's configure script (not PETSc). I found PETSc configure script disables Babel for installing hypre. > > > > > > > > Sorry, > > > > > > > > Keita > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > From: owner-petsc-users at mcs.anl.gov [mailto:owner-petsc-users at mcs.anl.gov] On Behalf Of Keita Teranishi > > Sent: Monday, August 27, 2007 2:02 PM > > To: petsc-users at mcs.anl.gov > > Subject: hypre and PETSc's FORTRAN Interface > > > > > > > > Hi, > > > > > > > > I am trying to build petsc with FORTRAN interface and hypre together, but having a configure error message due to language compatibility between FORTRAN and C++. More precisely, the configure script complains that PETSc's FORTRAN interface cannot be linked to some C++ objects of hypre. I thought the latest version of hypre is implemented in C except some optional packages such as Babel. If this is right, we could use FOTRAN interface to use PETSc and hypre together. > > > > I would like to know how PETSc accesses to hypre. > > > > > > > > Thanks, > > > > > > > > Keita > > > > > > From gtg100n at mail.gatech.edu Tue Aug 28 08:45:14 2007 From: gtg100n at mail.gatech.edu (Alejandro Garzon) Date: Tue, 28 Aug 2007 09:45:14 -0400 Subject: using MatCreateSeqBDiag Message-ID: <1188308714.46d426ead8cf3@webmail.mail.gatech.edu> Hi, I'm trying to use MatCreateSeqBDiag. I wrote a small test program to see how this function works. The program creates a matrix A, prints it in matlab ascii format and in binary format, then creates a vector x, calculates A*x and puts the result in vector b. I have found the following inconsistencies: 1) While I intended the matrix to have real elements, it is printed in matlab ascii format as if all the elements were imaginary. The elements are correct except for an extra "i" to the right of all of them. 2) When printed in binary format, the matrix appears with all its elements set to zero. 3) The internal representation of the matrix seems to be Ok as a matrix-vector multiplication A*x gives the right result (without the i's). The source code and the output of the program are below. Can you take a look at it and tell me if the I haven't built the matrix in the right way or if it could be a bug in the MatView function when handling this matrix format ? Thanks. // ************** Source code program ********************* // This code is for checking the usage of MatCreateSeqBDiag #include #include #include"petscksp.h" int main(int argc,char **args) { Mat A; Vec x,b; PetscInt diag[9],ixm[10]; PetscScalar **diagv,*diagv1,vval[10]; int i; PetscViewer v; PetscErrorCode ierr; PetscInitialize(&argc,&args,(char *)0,(char *)0); // A 10x10 matrix with 2x2 blocks will be build. // Only blocks in the main diagonal will be filled. diag[0]=0; diagv=malloc(1*sizeof(PetscScalar*)); diagv1=malloc(20*sizeof(PetscScalar)); // The main block diagonal will contain the numbers from // 1 to 20 for(i=0;i<20;i++){ diagv1[i]=(i+1.0); } diagv[0]=diagv1; ierr=MatCreateSeqBDiag(PETSC_COMM_WORLD,10,10,1,2,diag,diagv,&A); CHKERRQ(ierr); ierr=MatAssemblyBegin(A,MAT_FINAL_ASSEMBLY);CHKERRQ(ierr); ierr=MatAssemblyEnd(A,MAT_FINAL_ASSEMBLY);CHKERRQ(ierr); // Printing matrix A to the stardard output in matlab ascii format. ierr=PetscViewerSetFormat(PETSC_VIEWER_STDOUT_WORLD, PETSC_VIEWER_ASCII_MATLAB);CHKERRQ(ierr); ierr=MatView(A,PETSC_VIEWER_STDOUT_WORLD);CHKERRQ(ierr); // Printing matrix A to binary file "binary_file" ierr=PetscViewerBinaryOpen(PETSC_COMM_WORLD,"binary_file", FILE_MODE_WRITE,&v);CHKERRQ(ierr); ierr=MatView(A,v);CHKERRQ(ierr); // Building vector with all elements equal to 1 ierr=VecCreate(PETSC_COMM_WORLD,&x);CHKERRQ(ierr); ierr=VecSetSizes(x,PETSC_DECIDE,10);CHKERRQ(ierr); ierr=VecSetFromOptions(x);CHKERRQ(ierr); for(i=0;i<10;i++){ ixm[i]=i; vval[i]=1; } ierr=VecSetValues(x,10,ixm,vval,INSERT_VALUES);CHKERRQ(ierr); ierr=VecAssemblyBegin(x);CHKERRQ(ierr); ierr=VecAssemblyEnd(x);CHKERRQ(ierr); // Printing vector x to standard output in matlab ascii format ierr=VecView(x,PETSC_VIEWER_STDOUT_WORLD);CHKERRQ(ierr); ierr=VecDuplicate(x,&b);CHKERRQ(ierr); // b = A*x ierr=MatMult(A,x,b);CHKERRQ(ierr); // Printing vector b to standard output in matlab ascii format ierr=VecView(b,PETSC_VIEWER_STDOUT_WORLD);CHKERRQ(ierr); PetscFinalize(); return 0; } // ****************** Program output ********************* % Size = 10 10 % Nonzeros = 20 zzz = zeros(20,3); zzz = [ 1 1 1.0000000000000000e+00i 1 2 3.0000000000000000e+00i 2 1 2.0000000000000000e+00i 2 2 4.0000000000000000e+00i 3 3 5.0000000000000000e+00i 3 4 7.0000000000000000e+00i 4 3 6.0000000000000000e+00i 4 4 8.0000000000000000e+00i 5 5 9.0000000000000000e+00i 5 6 1.1000000000000000e+01i 6 5 1.0000000000000000e+01i 6 6 1.2000000000000000e+01i 7 7 1.3000000000000000e+01i 7 8 1.5000000000000000e+01i 8 7 1.4000000000000000e+01i 8 8 1.6000000000000000e+01i 9 9 1.7000000000000000e+01i 9 10 1.9000000000000000e+01i 10 9 1.8000000000000000e+01i 10 10 2.0000000000000000e+01i ]; Mat_0 = spconvert(zzz); Vec_1 = [ 1.0000000000000000e+00 1.0000000000000000e+00 1.0000000000000000e+00 1.0000000000000000e+00 1.0000000000000000e+00 1.0000000000000000e+00 1.0000000000000000e+00 1.0000000000000000e+00 1.0000000000000000e+00 1.0000000000000000e+00 ]; Vec_2 = [ 4.0000000000000000e+00 6.0000000000000000e+00 1.2000000000000000e+01 1.4000000000000000e+01 2.0000000000000000e+01 2.2000000000000000e+01 2.8000000000000000e+01 3.0000000000000000e+01 3.6000000000000000e+01 3.8000000000000000e+01 ]; -- Alejandro From zonexo at gmail.com Tue Aug 28 09:52:02 2007 From: zonexo at gmail.com (Ben Tay) Date: Tue, 28 Aug 2007 22:52:02 +0800 Subject: Error using VecRestoreArrayF90 Message-ID: <46D43692.5000301@gmail.com> Hi, I tried to use VecRestoreArrayF90. It works on 1 code but failed on the other. The one which worked is a .F90 free format one while the one which failed is a .F fixed format one. The failed one is #define PETSC_AVOID_DECLARATIONS #include "include/finclude/petsc.h" #include "include/finclude/petscvec.h" #include "include/finclude/petscmat.h" #include "include/finclude/petscksp.h" #include "include/finclude/petscpc.h" #undef PETSC_AVOID_DECLARATIONS module petsc_sub implicit none contains subroutine petsc_solver_pois #include "include/finclude/petsc.h" #include "include/finclude/petscvec.h" #include "include/finclude/petscmat.h" #include "include/finclude/petscksp.h" #include "include/finclude/petscpc.h" #include "include/finclude/petscmat.h90" PetscScalar, pointer :: xx_v(:) ... solve using KSPSolve to get xx ... call VecGetArrayF90(xx,xx_v,ierr) !error at here pre=xx_v call VecRestoreArrayF90(xx,xx_v,ierr) The error msg is : [0]PETSC ERROR: ---------------------------------------------------------------- -------- [0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably m emory 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/petsc-as/documentation/troub leshooting.html#Signal[0]PETSC ERROR: or try http://valgrind.org on linux or man libgmalloc on Apple 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] F90Array1dCreate line 52 src/sys/f90-src/d:\cygwin\codes\PET SC-~1.3-P\src\sys\f90-src\f90_cwrap.c [0]PETSC ERROR: --------------------- Error Message ---------------------------- -------- [0]PETSC ERROR: Signal received! [0]PETSC ERROR: ---------------------------------------------------------------- It works if I use "call VecRestoreArray(xx,ppv,i_vec,ierr)". So what did I do wrong here? Thank you From balay at mcs.anl.gov Tue Aug 28 09:57:47 2007 From: balay at mcs.anl.gov (Satish Balay) Date: Tue, 28 Aug 2007 09:57:47 -0500 (CDT) Subject: Error using VecRestoreArrayF90 In-Reply-To: <46D43692.5000301@gmail.com> References: <46D43692.5000301@gmail.com> Message-ID: Perhaps the error is due to the missing include file? #include "include/finclude/petscvec.h90" Satish On Tue, 28 Aug 2007, Ben Tay wrote: > Hi, > > I tried to use VecRestoreArrayF90. It works on 1 code but failed on the other. > The one which worked is a .F90 free format one while the one which failed is a > .F fixed format one. The failed one is > > #define PETSC_AVOID_DECLARATIONS > #include "include/finclude/petsc.h" > #include "include/finclude/petscvec.h" > #include "include/finclude/petscmat.h" > #include "include/finclude/petscksp.h" > #include "include/finclude/petscpc.h" > #undef PETSC_AVOID_DECLARATIONS > > module petsc_sub > > implicit none > > contains > > subroutine petsc_solver_pois > > #include "include/finclude/petsc.h" > #include "include/finclude/petscvec.h" > #include "include/finclude/petscmat.h" > #include "include/finclude/petscksp.h" > #include "include/finclude/petscpc.h" > #include "include/finclude/petscmat.h90" > > PetscScalar, pointer :: xx_v(:) > > ... > > solve using KSPSolve to get xx > > ... > > call VecGetArrayF90(xx,xx_v,ierr) !error at here > > pre=xx_v > > call VecRestoreArrayF90(xx,xx_v,ierr) > The error msg is : > > [0]PETSC ERROR: > ---------------------------------------------------------------- > -------- > [0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably > m > emory 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/petsc-as/documentation/troub > leshooting.html#Signal[0]PETSC ERROR: or try http://valgrind.org on linux or > man > libgmalloc on Apple 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] F90Array1dCreate line 52 > src/sys/f90-src/d:\cygwin\codes\PET > SC-~1.3-P\src\sys\f90-src\f90_cwrap.c > [0]PETSC ERROR: --------------------- Error Message > ---------------------------- > -------- > [0]PETSC ERROR: Signal received! > [0]PETSC ERROR: > ---------------------------------------------------------------- > > It works if I use "call VecRestoreArray(xx,ppv,i_vec,ierr)". So what did I do > wrong here? > > Thank you > > From zonexo at gmail.com Tue Aug 28 10:12:27 2007 From: zonexo at gmail.com (Ben Tay) Date: Tue, 28 Aug 2007 23:12:27 +0800 Subject: Error using VecRestoreArrayF90 In-Reply-To: References: <46D43692.5000301@gmail.com> Message-ID: <46D43B5A.6020504@gmail.com> Ok, got it working. Thanks! Satish Balay wrote: > Perhaps the error is due to the missing include file? > > #include "include/finclude/petscvec.h90" > > Satish > > > On Tue, 28 Aug 2007, Ben Tay wrote: > > >> Hi, >> >> I tried to use VecRestoreArrayF90. It works on 1 code but failed on the other. >> The one which worked is a .F90 free format one while the one which failed is a >> .F fixed format one. The failed one is >> >> #define PETSC_AVOID_DECLARATIONS >> #include "include/finclude/petsc.h" >> #include "include/finclude/petscvec.h" >> #include "include/finclude/petscmat.h" >> #include "include/finclude/petscksp.h" >> #include "include/finclude/petscpc.h" >> #undef PETSC_AVOID_DECLARATIONS >> >> module petsc_sub >> >> implicit none >> >> contains >> >> subroutine petsc_solver_pois >> >> #include "include/finclude/petsc.h" >> #include "include/finclude/petscvec.h" >> #include "include/finclude/petscmat.h" >> #include "include/finclude/petscksp.h" >> #include "include/finclude/petscpc.h" >> #include "include/finclude/petscmat.h90" >> >> PetscScalar, pointer :: xx_v(:) >> >> ... >> >> solve using KSPSolve to get xx >> >> ... >> >> call VecGetArrayF90(xx,xx_v,ierr) !error at here >> >> pre=xx_v >> >> call VecRestoreArrayF90(xx,xx_v,ierr) >> The error msg is : >> >> [0]PETSC ERROR: >> ---------------------------------------------------------------- >> -------- >> [0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably >> m >> emory 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/petsc-as/documentation/troub >> leshooting.html#Signal[0]PETSC ERROR: or try http://valgrind.org on linux or >> man >> libgmalloc on Apple 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] F90Array1dCreate line 52 >> src/sys/f90-src/d:\cygwin\codes\PET >> SC-~1.3-P\src\sys\f90-src\f90_cwrap.c >> [0]PETSC ERROR: --------------------- Error Message >> ---------------------------- >> -------- >> [0]PETSC ERROR: Signal received! >> [0]PETSC ERROR: >> ---------------------------------------------------------------- >> >> It works if I use "call VecRestoreArray(xx,ppv,i_vec,ierr)". So what did I do >> wrong here? >> >> Thank you >> >> >> > > > From knepley at gmail.com Tue Aug 28 12:05:18 2007 From: knepley at gmail.com (Matthew Knepley) Date: Tue, 28 Aug 2007 12:05:18 -0500 Subject: using MatCreateSeqBDiag In-Reply-To: <1188308714.46d426ead8cf3@webmail.mail.gatech.edu> References: <1188308714.46d426ead8cf3@webmail.mail.gatech.edu> Message-ID: On 8/28/07, Alejandro Garzon wrote: > Hi, I'm trying to use MatCreateSeqBDiag. I wrote a small test program > to see how this function works. The program creates a matrix A, > prints it in matlab ascii format and in binary format, then creates a > vector x, calculates A*x and puts the result in vector b. > > I have found the following inconsistencies: > 1) While I intended the matrix to have real elements, it is printed in > matlab ascii format as if all the elements were imaginary. The > elements are correct except for an extra "i" to the right of all of > them. This was a cut&paste error. Fixed. > 2) When printed in binary format, the matrix appears with all its > elements set to zero. Fixed this now too. These fixes will appear in the next patch release. Hopefully before the end of the week. Thanks for reporting these, Matt > 3) The internal representation of the matrix seems to be Ok as a > matrix-vector multiplication A*x gives the right result (without the > i's). > > The source code and the output of the program are below. Can you take > a look at it and tell me if the I haven't built the matrix in the > right way or if it could be a bug in the MatView function when > handling this matrix format ? Thanks. > > // ************** Source code program ********************* > // This code is for checking the usage of MatCreateSeqBDiag > > #include > #include > #include"petscksp.h" > > int main(int argc,char **args) > { > Mat A; > Vec x,b; > PetscInt diag[9],ixm[10]; > PetscScalar **diagv,*diagv1,vval[10]; > int i; > PetscViewer v; > PetscErrorCode ierr; > > PetscInitialize(&argc,&args,(char *)0,(char *)0); > > // A 10x10 matrix with 2x2 blocks will be build. > // Only blocks in the main diagonal will be filled. > diag[0]=0; > diagv=malloc(1*sizeof(PetscScalar*)); > diagv1=malloc(20*sizeof(PetscScalar)); > > // The main block diagonal will contain the numbers from > // 1 to 20 > for(i=0;i<20;i++){ > diagv1[i]=(i+1.0); > } > > diagv[0]=diagv1; > > ierr=MatCreateSeqBDiag(PETSC_COMM_WORLD,10,10,1,2,diag,diagv,&A); > CHKERRQ(ierr); > ierr=MatAssemblyBegin(A,MAT_FINAL_ASSEMBLY);CHKERRQ(ierr); > ierr=MatAssemblyEnd(A,MAT_FINAL_ASSEMBLY);CHKERRQ(ierr); > > // Printing matrix A to the stardard output in matlab ascii format. > ierr=PetscViewerSetFormat(PETSC_VIEWER_STDOUT_WORLD, > PETSC_VIEWER_ASCII_MATLAB);CHKERRQ(ierr); > ierr=MatView(A,PETSC_VIEWER_STDOUT_WORLD);CHKERRQ(ierr); > > // Printing matrix A to binary file "binary_file" > ierr=PetscViewerBinaryOpen(PETSC_COMM_WORLD,"binary_file", > FILE_MODE_WRITE,&v);CHKERRQ(ierr); > ierr=MatView(A,v);CHKERRQ(ierr); > > // Building vector with all elements equal to 1 > ierr=VecCreate(PETSC_COMM_WORLD,&x);CHKERRQ(ierr); > ierr=VecSetSizes(x,PETSC_DECIDE,10);CHKERRQ(ierr); > ierr=VecSetFromOptions(x);CHKERRQ(ierr); > > for(i=0;i<10;i++){ > ixm[i]=i; > vval[i]=1; > } > > ierr=VecSetValues(x,10,ixm,vval,INSERT_VALUES);CHKERRQ(ierr); > ierr=VecAssemblyBegin(x);CHKERRQ(ierr); > ierr=VecAssemblyEnd(x);CHKERRQ(ierr); > > // Printing vector x to standard output in matlab ascii format > ierr=VecView(x,PETSC_VIEWER_STDOUT_WORLD);CHKERRQ(ierr); > > ierr=VecDuplicate(x,&b);CHKERRQ(ierr); > > // b = A*x > ierr=MatMult(A,x,b);CHKERRQ(ierr); > > // Printing vector b to standard output in matlab ascii format > ierr=VecView(b,PETSC_VIEWER_STDOUT_WORLD);CHKERRQ(ierr); > > PetscFinalize(); > > return 0; > } > > // ****************** Program output ********************* > % Size = 10 10 > % Nonzeros = 20 > zzz = zeros(20,3); > zzz = [ > 1 1 1.0000000000000000e+00i > 1 2 3.0000000000000000e+00i > 2 1 2.0000000000000000e+00i > 2 2 4.0000000000000000e+00i > 3 3 5.0000000000000000e+00i > 3 4 7.0000000000000000e+00i > 4 3 6.0000000000000000e+00i > 4 4 8.0000000000000000e+00i > 5 5 9.0000000000000000e+00i > 5 6 1.1000000000000000e+01i > 6 5 1.0000000000000000e+01i > 6 6 1.2000000000000000e+01i > 7 7 1.3000000000000000e+01i > 7 8 1.5000000000000000e+01i > 8 7 1.4000000000000000e+01i > 8 8 1.6000000000000000e+01i > 9 9 1.7000000000000000e+01i > 9 10 1.9000000000000000e+01i > 10 9 1.8000000000000000e+01i > 10 10 2.0000000000000000e+01i > ]; > Mat_0 = spconvert(zzz); > Vec_1 = [ > 1.0000000000000000e+00 > 1.0000000000000000e+00 > 1.0000000000000000e+00 > 1.0000000000000000e+00 > 1.0000000000000000e+00 > 1.0000000000000000e+00 > 1.0000000000000000e+00 > 1.0000000000000000e+00 > 1.0000000000000000e+00 > 1.0000000000000000e+00 > ]; > Vec_2 = [ > 4.0000000000000000e+00 > 6.0000000000000000e+00 > 1.2000000000000000e+01 > 1.4000000000000000e+01 > 2.0000000000000000e+01 > 2.2000000000000000e+01 > 2.8000000000000000e+01 > 3.0000000000000000e+01 > 3.6000000000000000e+01 > 3.8000000000000000e+01 > ]; > > -- > Alejandro > > > > > -- 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 From pbauman at ices.utexas.edu Tue Aug 28 18:55:18 2007 From: pbauman at ices.utexas.edu (Paul T. Bauman) Date: Tue, 28 Aug 2007 18:55:18 -0500 Subject: PetscPrintf/ifort 9.1 Message-ID: <46D4B5E6.7010602@ices.utexas.edu> Hello, Kind of a non-numerical question - sorry. I'm using PetscPrintf from Fortran using the following calling sequence (for example): call PetscPrintf(PETSC_COMM_WORLD, "=============================================== \n", ierr) call PetscPrintf(PETSC_COMM_WORLD, " Beginning of Program \n", ierr) call PetscPrintf(PETSC_COMM_WORLD, "=============================================== \n", ierr) On my mac laptop (PowerPC) with PETSc 2.3.2-p7 compiled with gcc 4.0.1 and g95, this prints as expected: =============================================== Beginning of Program =============================================== On a linux workstation (AMD Opteron) with PETSc 2.3.2-p7 compiled with icc, icxx, ifort 9.1, the "\n" is treated as a character and not treated as "move to new line" so the output is all on one line: =============================================== \n Beginning of Program \n=============================================== \n While not the end of the world, it is a bit annoying. Am I screwing up the calling sequence and just got lucky with g95? Or a bug (PETSc or Intel)? Thanks, Paul P.S. The reason why I care is because on any compiler I've used (other than Intel), write(*,*) prints out at different times and not in sequence with PETSc so all my output comes out after PETSc is done outputting. Using PetscPrintf, I can have everything print out in order. From knepley at gmail.com Tue Aug 28 19:05:20 2007 From: knepley at gmail.com (Matthew Knepley) Date: Tue, 28 Aug 2007 19:05:20 -0500 Subject: PetscPrintf/ifort 9.1 In-Reply-To: <46D4B5E6.7010602@ices.utexas.edu> References: <46D4B5E6.7010602@ices.utexas.edu> Message-ID: On 8/28/07, Paul T. Bauman wrote: > Hello, > > Kind of a non-numerical question - sorry. I'm using PetscPrintf from > Fortran using the following calling sequence (for example): > > call PetscPrintf(PETSC_COMM_WORLD, > "=============================================== \n", ierr) > call PetscPrintf(PETSC_COMM_WORLD, " Beginning of > Program \n", ierr) > call PetscPrintf(PETSC_COMM_WORLD, > "=============================================== \n", ierr) > > On my mac laptop (PowerPC) with PETSc 2.3.2-p7 compiled with gcc 4.0.1 > and g95, this prints as expected: > > =============================================== > Beginning of Program > =============================================== > > On a linux workstation (AMD Opteron) with PETSc 2.3.2-p7 compiled with > icc, icxx, ifort 9.1, the "\n" is treated as a character and not treated > as "move to new line" so the output is all on one line: > > =============================================== \n > Beginning of Program \n=============================================== \n This is much lower level than PETSc. It is in the C standard. There must be something else going on here. We do this EVERYWHERE in the code. For instance, why would the -ksp_monitor output work. This uses \n in exactly the same way. Matt > While not the end of the world, it is a bit annoying. Am I screwing up > the calling sequence and just got lucky with g95? Or a bug (PETSc or > Intel)? > > Thanks, > > Paul > > P.S. The reason why I care is because on any compiler I've used (other > than Intel), write(*,*) prints out at different times and not in > sequence with PETSc so all my output comes out after PETSc is done > outputting. Using PetscPrintf, I can have everything print out in order. > > -- 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 From leif at geodynamics.org Tue Aug 28 19:35:44 2007 From: leif at geodynamics.org (Leif Strand) Date: Tue, 28 Aug 2007 17:35:44 -0700 Subject: PetscPrintf/ifort 9.1 In-Reply-To: References: <46D4B5E6.7010602@ices.utexas.edu> Message-ID: <46D4BF60.5000804@geodynamics.org> Paul, The "\n" -> linefeed (012) translation is performed by the compiler. Only a C compiler would be expected to do this. So the key difference here is g95 vs. ifort. Consider the following program: program hello write (*,*) 'Hello,\nworld!' end program hello Compiled with g95, this produces the following output: $ ./hello Hello, world! $ But compiled with ifort, the escape sequence is interpreted literally: $ ./hello Hello,\nworld! $ I would assume the g95 behavior is non-standard. (Since I don't really know Fortran, I don't know how to tell a Fortran compiler to embed a newline...) --Leif Matthew Knepley wrote: > On 8/28/07, Paul T. Bauman wrote: >> Hello, >> >> Kind of a non-numerical question - sorry. I'm using PetscPrintf from >> Fortran using the following calling sequence (for example): >> >> call PetscPrintf(PETSC_COMM_WORLD, >> "=============================================== \n", ierr) >> call PetscPrintf(PETSC_COMM_WORLD, " Beginning of >> Program \n", ierr) >> call PetscPrintf(PETSC_COMM_WORLD, >> "=============================================== \n", ierr) >> >> On my mac laptop (PowerPC) with PETSc 2.3.2-p7 compiled with gcc 4.0.1 >> and g95, this prints as expected: >> >> =============================================== >> Beginning of Program >> =============================================== >> >> On a linux workstation (AMD Opteron) with PETSc 2.3.2-p7 compiled with >> icc, icxx, ifort 9.1, the "\n" is treated as a character and not treated >> as "move to new line" so the output is all on one line: >> >> =============================================== \n >> Beginning of Program \n=============================================== \n > > This is much lower level than PETSc. It is in the C standard. There > must be something > else going on here. We do this EVERYWHERE in the code. For instance, > why would the > -ksp_monitor output work. This uses \n in exactly the same way. > > Matt > >> While not the end of the world, it is a bit annoying. Am I screwing up >> the calling sequence and just got lucky with g95? Or a bug (PETSc or >> Intel)? >> >> Thanks, >> >> Paul >> >> P.S. The reason why I care is because on any compiler I've used (other >> than Intel), write(*,*) prints out at different times and not in >> sequence with PETSc so all my output comes out after PETSc is done >> outputting. Using PetscPrintf, I can have everything print out in order. >> >> > > From pbauman at ices.utexas.edu Tue Aug 28 21:18:29 2007 From: pbauman at ices.utexas.edu (Paul T. Bauman) Date: Tue, 28 Aug 2007 21:18:29 -0500 Subject: PetscPrintf/ifort 9.1 In-Reply-To: <46D4BF60.5000804@geodynamics.org> References: <46D4B5E6.7010602@ices.utexas.edu> <46D4BF60.5000804@geodynamics.org> Message-ID: <46D4D775.6000201@ices.utexas.edu> Leif Strand wrote: > Paul, > > The "\n" -> linefeed (012) translation is performed by the compiler. > Only a C compiler would be expected to do this. So the key difference > here is g95 vs. ifort. I understand the key difference is g95 vs. Intel - what I don't understand is why because I thought all I was doing was passing a character string to PetscPrintf and (I assumed) that PetscPrintf made appropriate C calls to print the message out. Hence, I assumed that the Fortran wrapper was doing something different between the two compilers. I thought perhaps this what was going on (and why I bothered to mail the list). So, what does the PetscPrintf call from FORTRAN do? > program hello > write (*,*) 'Hello,\nworld!' > end program hello > > Compiled with g95, this produces the following output: > > $ ./hello > Hello, > world! > $ That is strange (and not what a write(*,*) should do). Thanks for this example. > > But compiled with ifort, the escape sequence is interpreted literally: > > $ ./hello > Hello,\nworld! > $ > > I would assume the g95 behavior is non-standard. (Since I don't > really know Fortran, I don't know how to tell a Fortran compiler to > embed a newline...) > > --Leif > > > Matthew Knepley wrote: >> On 8/28/07, Paul T. Bauman wrote: >>> Hello, >>> >>> Kind of a non-numerical question - sorry. I'm using PetscPrintf from >>> Fortran using the following calling sequence (for example): >>> >>> call PetscPrintf(PETSC_COMM_WORLD, >>> "=============================================== \n", ierr) >>> call PetscPrintf(PETSC_COMM_WORLD, " Beginning of >>> Program \n", ierr) >>> call PetscPrintf(PETSC_COMM_WORLD, >>> "=============================================== \n", ierr) >>> >>> On my mac laptop (PowerPC) with PETSc 2.3.2-p7 compiled with gcc 4.0.1 >>> and g95, this prints as expected: >>> >>> =============================================== >>> Beginning of Program >>> =============================================== >>> >>> On a linux workstation (AMD Opteron) with PETSc 2.3.2-p7 compiled with >>> icc, icxx, ifort 9.1, the "\n" is treated as a character and not >>> treated >>> as "move to new line" so the output is all on one line: >>> >>> =============================================== \n >>> Beginning of Program >>> \n=============================================== \n >> >> This is much lower level than PETSc. It is in the C standard. There >> must be something >> else going on here. We do this EVERYWHERE in the code. For instance, >> why would the >> -ksp_monitor output work. This uses \n in exactly the same way. >> >> Matt Right, I understand it's C standard (and therefore wouldn't expect C to behave any differently), but what's going on in the FORTRAN call? It's just passing the character string to the C call and the string being interpreted the "C way"? I guess my solution then (considering my P.S.) is to us a C routine to do this? Paul >> >>> While not the end of the world, it is a bit annoying. Am I screwing up >>> the calling sequence and just got lucky with g95? Or a bug (PETSc or >>> Intel)? >>> >>> Thanks, >>> >>> Paul >>> >>> P.S. The reason why I care is because on any compiler I've used (other >>> than Intel), write(*,*) prints out at different times and not in >>> sequence with PETSc so all my output comes out after PETSc is done >>> outputting. Using PetscPrintf, I can have everything print out in >>> order. >>> >>> >> >> > From bsmith at mcs.anl.gov Tue Aug 28 22:37:22 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Tue, 28 Aug 2007 22:37:22 -0500 (CDT) Subject: PetscPrintf/ifort 9.1 In-Reply-To: <46D4B5E6.7010602@ices.utexas.edu> References: <46D4B5E6.7010602@ices.utexas.edu> Message-ID: Paul, I have pushed a fix to petsc-dev that resolves this problem. If you are not using petsc-dev you can simply replace the file src/sys/fileio/ftn-custom/zmprintf.c with the attached file then run make lib shared in that directory then relink your program. Barry On Tue, 28 Aug 2007, Paul T. Bauman wrote: > Hello, > > Kind of a non-numerical question - sorry. I'm using PetscPrintf from Fortran > using the following calling sequence (for example): > > call PetscPrintf(PETSC_COMM_WORLD, > "=============================================== \n", ierr) > call PetscPrintf(PETSC_COMM_WORLD, " Beginning of Program > \n", ierr) > call PetscPrintf(PETSC_COMM_WORLD, > "=============================================== \n", ierr) > > On my mac laptop (PowerPC) with PETSc 2.3.2-p7 compiled with gcc 4.0.1 and > g95, this prints as expected: > > =============================================== > Beginning of Program > =============================================== > > On a linux workstation (AMD Opteron) with PETSc 2.3.2-p7 compiled with icc, > icxx, ifort 9.1, the "\n" is treated as a character and not treated as "move > to new line" so the output is all on one line: > > =============================================== \n Beginning of > Program \n=============================================== \n > > While not the end of the world, it is a bit annoying. Am I screwing up the > calling sequence and just got lucky with g95? Or a bug (PETSc or Intel)? > > Thanks, > > Paul > > P.S. The reason why I care is because on any compiler I've used (other than > Intel), write(*,*) prints out at different times and not in sequence with > PETSc so all my output comes out after PETSc is done outputting. Using > PetscPrintf, I can have everything print out in order. > > -------------- next part -------------- #include "zpetsc.h" #include "petsc.h" #if defined(PETSC_HAVE_FORTRAN_CAPS) #define petscfprintf_ PETSCFPRINTF #define petscprintf_ PETSCPRINTF #define petscsynchronizedfprintf_ PETSCSYNCHRONIZEDFPRINTF #define petscsynchronizedprintf_ PETSCSYNCHRONIZEDPRINTF #elif !defined(PETSC_HAVE_FORTRAN_UNDERSCORE) #define petscfprintf_ petscfprintf #define petscprintf_ petscprintf #define petscsynchronizedfprintf_ petscsynchronizedfprintf #define petscsynchronizedprintf_ petscsynchronizedprintf #endif EXTERN_C_BEGIN static PetscErrorCode PetscFixSlashN(const char *in, char **out) { PetscErrorCode ierr; PetscInt i; size_t len; PetscFunctionBegin; ierr = PetscStrallocpy(in,out);CHKERRQ(ierr); ierr = PetscStrlen(*out,&len);CHKERRQ(ierr); for (i=0; i References: <46D4B5E6.7010602@ices.utexas.edu> Message-ID: <46D4EBC2.6040106@ices.utexas.edu> Awesome. Thanks so much. Barry Smith wrote: > Paul, > > I have pushed a fix to petsc-dev that resolves this problem. If you are > not using petsc-dev you can simply replace the file > src/sys/fileio/ftn-custom/zmprintf.c with the attached file then run > make lib shared > in that directory then relink your program. > > Barry > > > On Tue, 28 Aug 2007, Paul T. Bauman wrote: > > >> Hello, >> >> Kind of a non-numerical question - sorry. I'm using PetscPrintf from Fortran >> using the following calling sequence (for example): >> >> call PetscPrintf(PETSC_COMM_WORLD, >> "=============================================== \n", ierr) >> call PetscPrintf(PETSC_COMM_WORLD, " Beginning of Program >> \n", ierr) >> call PetscPrintf(PETSC_COMM_WORLD, >> "=============================================== \n", ierr) >> >> On my mac laptop (PowerPC) with PETSc 2.3.2-p7 compiled with gcc 4.0.1 and >> g95, this prints as expected: >> >> =============================================== >> Beginning of Program >> =============================================== >> >> On a linux workstation (AMD Opteron) with PETSc 2.3.2-p7 compiled with icc, >> icxx, ifort 9.1, the "\n" is treated as a character and not treated as "move >> to new line" so the output is all on one line: >> >> =============================================== \n Beginning of >> Program \n=============================================== \n >> >> While not the end of the world, it is a bit annoying. Am I screwing up the >> calling sequence and just got lucky with g95? Or a bug (PETSc or Intel)? >> >> Thanks, >> >> Paul >> >> P.S. The reason why I care is because on any compiler I've used (other than >> Intel), write(*,*) prints out at different times and not in sequence with >> PETSc so all my output comes out after PETSc is done outputting. Using >> PetscPrintf, I can have everything print out in order. >> >> From sanjay at ce.berkeley.edu Wed Aug 29 04:39:14 2007 From: sanjay at ce.berkeley.edu (Sanjay Govindjee) Date: Wed, 29 Aug 2007 11:39:14 +0200 Subject: PetscPrintf/ifort 9.1 In-Reply-To: <46D4B5E6.7010602@ices.utexas.edu> References: <46D4B5E6.7010602@ices.utexas.edu> Message-ID: <46D53EC2.1040009@ce.berkeley.edu> As a side note to this discussion, on some machines, a call to flush will "interleave" the output from write(*,*) with the PETSc output instead of buffering it until the end. -sanjay > > > P.S. The reason why I care is because on any compiler I've used (other > than Intel), write(*,*) prints out at different times and not in > sequence with PETSc so all my output comes out after PETSc is done > outputting. Using PetscPrintf, I can have everything print out in order. > From sdettrick at gmail.com Wed Aug 29 09:09:24 2007 From: sdettrick at gmail.com (Sean Dettrick) Date: Wed, 29 Aug 2007 10:09:24 -0400 Subject: c++ bindings, intel compiler, petsc.h conflict, petsc install? Message-ID: <44114ec40708290709g2bc0a2a6v360d46fa87fae717@mail.gmail.com> Hi, I have a C++ MPI code that uses the C++ MPI bindings and uses PETSc as a kind of plug-in. This was compiling and running nicely before on linux with petsc-2.3.0, GCC compilers and LAM MPI. But now I can't get my code to compile on linux with petsc-2.3.3-p4, 64 bit Intel compilers, and Intel MPI. If petsc.h is included before mpi.h, then there are compile time errors: the MPI namespace is not available, due to MPICH_SKIP_MPICXX in petsc.h (not present in 2.3.0). If mpi.h is included before petsc.h, then there are link time errors: undefined referenced to Petsc functions. Am I doing something wrong, or is this a well known thing? I wonder if it could be a configuration error? Because the intel mpi installation uses non-standard directory names for the 64 bit version - bin64, include64 etc, the configuration looks a little hairy: config/configure.py \ --with-petsc-arch=intel_MPI_64_static \ --with-fortran=0 \ --with-mpi-include=/opt/intel/mpi/3.0/include64 \ --with-mpi-lib=/opt/intel/mpi/3.0/lib64/libmpi.a \ --with-mpiexec=/opt/intel/mpi-rt/3.0/bin64/mpiexec \ --with-x=no \ --with-matlab=0 \ --with-shared=0 \ --with-cc=/opt/intel/mpi/3.0/bin64/mpiicc \ --with-cxx=/opt/intel/mpi/3.0/bin64/mpiicpc \ --CXXFLAGS=-I/opt/intel/mpi/3.0/include64 \ --CFLAGS=-I/opt/intel/mpi/3.0/include64 \ --LDFLAGS=-L/opt/intel/mpi/3.0/lib64 \ --download-c-blas-lapack=1 "make all test" indicated that the tests were passed. Any suggestions greatly appreciated! Thanks Sean Dettrick From bsmith at mcs.anl.gov Wed Aug 29 11:03:14 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Wed, 29 Aug 2007 11:03:14 -0500 (CDT) Subject: c++ bindings, intel compiler, petsc.h conflict, petsc install? In-Reply-To: <44114ec40708290709g2bc0a2a6v360d46fa87fae717@mail.gmail.com> References: <44114ec40708290709g2bc0a2a6v360d46fa87fae717@mail.gmail.com> Message-ID: Please send configure.log and make_log* to petsc-maint at mcs.anl.gov And all the output from your failed compile/link. On Wed, 29 Aug 2007, Sean Dettrick wrote: > Hi, > > I have a C++ MPI code that uses the C++ MPI bindings and uses PETSc as > a kind of plug-in. This was compiling and running nicely before on > linux with petsc-2.3.0, GCC compilers and LAM MPI. But now I can't > get my code to compile on linux with petsc-2.3.3-p4, 64 bit Intel > compilers, and Intel MPI. > > If petsc.h is included before mpi.h, then there are compile time > errors: the MPI namespace is not available, due to MPICH_SKIP_MPICXX > in petsc.h (not present in 2.3.0). > > If mpi.h is included before petsc.h, then there are link time errors: > undefined referenced to Petsc functions. > > Am I doing something wrong, or is this a well known thing? > > I wonder if it could be a configuration error? Because the intel mpi > installation uses non-standard directory names for the 64 bit version > - bin64, include64 etc, the configuration looks a little hairy: > > config/configure.py \ > --with-petsc-arch=intel_MPI_64_static \ > --with-fortran=0 \ > --with-mpi-include=/opt/intel/mpi/3.0/include64 \ > --with-mpi-lib=/opt/intel/mpi/3.0/lib64/libmpi.a \ > --with-mpiexec=/opt/intel/mpi-rt/3.0/bin64/mpiexec \ > --with-x=no \ > --with-matlab=0 \ > --with-shared=0 \ > --with-cc=/opt/intel/mpi/3.0/bin64/mpiicc \ > --with-cxx=/opt/intel/mpi/3.0/bin64/mpiicpc \ > --CXXFLAGS=-I/opt/intel/mpi/3.0/include64 \ > --CFLAGS=-I/opt/intel/mpi/3.0/include64 \ > --LDFLAGS=-L/opt/intel/mpi/3.0/lib64 \ > --download-c-blas-lapack=1 > > "make all test" indicated that the tests were passed. > > Any suggestions greatly appreciated! > > Thanks > Sean Dettrick > > From pbauman at ices.utexas.edu Wed Aug 29 11:31:39 2007 From: pbauman at ices.utexas.edu (Paul T. Bauman) Date: Wed, 29 Aug 2007 11:31:39 -0500 Subject: PetscPrintf/ifort 9.1 In-Reply-To: References: <46D4B5E6.7010602@ices.utexas.edu> Message-ID: <46D59F6B.9020701@ices.utexas.edu> Hi Barry, To preface, I sincerely appreciate your prompt response and willingness to produce quick fixes. However, it was pointed out to me in my office today (by someone who knows more about interfacing C and FORTRAN than I and who watches the petsc-users list) that the following code would have been the correct way for me to do this (I tested and it works on intel and g95): call PetscPrintf(PETSC_COMM_WORLD, "==============================================="//achar(10), ierr) call PetscPrintf(PETSC_COMM_WORLD, " Beginning of Program"//achar(10), ierr) call PetscPrintf(PETSC_COMM_WORLD, "==============================================="//achar(10), ierr) 'achar' is a FORTRAN intrinsic function that gets fed an integer and returns the corresponding ascii character from the ascii character set. In this case, 10 corresponds to the new line command and thus passes the correct format to the C call. I tested on the reverted version of zmprint.c and it works correctly (although it also works correctly with the patch you sent). I wanted to share out of the sake of proliferation of knowledge (and not to make you feel like I wasted your time). Thanks again for your efforts, especially to us lingering FORTRAN'ers. Hopefully this will clarify in the future if it ever comes up again. Sorry for the trouble. Paul Barry Smith wrote: > Paul, > > I have pushed a fix to petsc-dev that resolves this problem. If you are > not using petsc-dev you can simply replace the file > src/sys/fileio/ftn-custom/zmprintf.c with the attached file then run > make lib shared > in that directory then relink your program. > > Barry > > > On Tue, 28 Aug 2007, Paul T. Bauman wrote: > > >> Hello, >> >> Kind of a non-numerical question - sorry. I'm using PetscPrintf from Fortran >> using the following calling sequence (for example): >> >> call PetscPrintf(PETSC_COMM_WORLD, >> "=============================================== \n", ierr) >> call PetscPrintf(PETSC_COMM_WORLD, " Beginning of Program >> \n", ierr) >> call PetscPrintf(PETSC_COMM_WORLD, >> "=============================================== \n", ierr) >> >> On my mac laptop (PowerPC) with PETSc 2.3.2-p7 compiled with gcc 4.0.1 and >> g95, this prints as expected: >> >> =============================================== >> Beginning of Program >> =============================================== >> >> On a linux workstation (AMD Opteron) with PETSc 2.3.2-p7 compiled with icc, >> icxx, ifort 9.1, the "\n" is treated as a character and not treated as "move >> to new line" so the output is all on one line: >> >> =============================================== \n Beginning of >> Program \n=============================================== \n >> >> While not the end of the world, it is a bit annoying. Am I screwing up the >> calling sequence and just got lucky with g95? Or a bug (PETSc or Intel)? >> >> Thanks, >> >> Paul >> >> P.S. The reason why I care is because on any compiler I've used (other than >> Intel), write(*,*) prints out at different times and not in sequence with >> PETSc so all my output comes out after PETSc is done outputting. Using >> PetscPrintf, I can have everything print out in order. >> >> From stephan.kramer at imperial.ac.uk Wed Aug 29 12:06:13 2007 From: stephan.kramer at imperial.ac.uk (Stephan Kramer) Date: Wed, 29 Aug 2007 18:06:13 +0100 Subject: PetscPrintf/ifort 9.1 In-Reply-To: <46D59F6B.9020701@ices.utexas.edu> References: <46D4B5E6.7010602@ices.utexas.edu> <46D59F6B.9020701@ices.utexas.edu> Message-ID: <46D5A785.80609@imperial.ac.uk> Paul T. Bauman wrote: > Hi Barry, > > To preface, I sincerely appreciate your prompt response and > willingness to produce quick fixes. > > However, it was pointed out to me in my office today (by someone who > knows more about interfacing C and FORTRAN than I and who watches the > petsc-users list) that the following code would have been the correct > way for me to do this (I tested and it works on intel and g95): > > call PetscPrintf(PETSC_COMM_WORLD, > "==============================================="//achar(10), ierr) > call PetscPrintf(PETSC_COMM_WORLD, " Beginning of > Program"//achar(10), ierr) > call PetscPrintf(PETSC_COMM_WORLD, > "==============================================="//achar(10), ierr) > > 'achar' is a FORTRAN intrinsic function that gets fed an integer and > returns the corresponding ascii character from the ascii character > set. In this case, 10 corresponds to the new line command and thus > passes the correct format to the C call. I tested on the reverted > version of zmprint.c and it works correctly (although it also works > correctly with the patch you sent). While this may work for you, it is certainly not *the* correct way to do it. achar(10) corresponds to LF, whereas windows systems expect CR+LF (i.e. achar(13)//achar(10)), it may still work under windows as well though, depends on your terminal/ application you view the output with. The correct way in C is really to use \n (and in the above case I guess), and in fortran to use two separate write statements. Cheers Stephan > I wanted to share out of the sake of proliferation of knowledge (and > not to make you feel like I wasted your time). Thanks again for your > efforts, especially to us lingering FORTRAN'ers. Hopefully this will > clarify in the future if it ever comes up again. Sorry for the trouble. > > Paul > > Barry Smith wrote: >> Paul, >> >> I have pushed a fix to petsc-dev that resolves this problem. If >> you are >> not using petsc-dev you can simply replace the file >> src/sys/fileio/ftn-custom/zmprintf.c with the attached file then run >> make lib shared in that directory then relink your program. >> >> Barry >> >> >> On Tue, 28 Aug 2007, Paul T. Bauman wrote: >> >> >>> Hello, >>> >>> Kind of a non-numerical question - sorry. I'm using PetscPrintf >>> from Fortran >>> using the following calling sequence (for example): >>> >>> call PetscPrintf(PETSC_COMM_WORLD, >>> "=============================================== \n", ierr) >>> call PetscPrintf(PETSC_COMM_WORLD, " Beginning of >>> Program >>> \n", ierr) >>> call PetscPrintf(PETSC_COMM_WORLD, >>> "=============================================== \n", ierr) >>> >>> On my mac laptop (PowerPC) with PETSc 2.3.2-p7 compiled with gcc >>> 4.0.1 and >>> g95, this prints as expected: >>> >>> =============================================== >>> Beginning of Program >>> =============================================== >>> >>> On a linux workstation (AMD Opteron) with PETSc 2.3.2-p7 compiled >>> with icc, >>> icxx, ifort 9.1, the "\n" is treated as a character and not treated >>> as "move >>> to new line" so the output is all on one line: >>> >>> =============================================== \n >>> Beginning of >>> Program \n=============================================== \n >>> >>> While not the end of the world, it is a bit annoying. Am I screwing >>> up the >>> calling sequence and just got lucky with g95? Or a bug (PETSc or >>> Intel)? >>> >>> Thanks, >>> >>> Paul >>> >>> P.S. The reason why I care is because on any compiler I've used >>> (other than >>> Intel), write(*,*) prints out at different times and not in sequence >>> with >>> PETSc so all my output comes out after PETSc is done outputting. Using >>> PetscPrintf, I can have everything print out in order. >>> >>> > > From leif at geodynamics.org Wed Aug 29 13:18:40 2007 From: leif at geodynamics.org (Leif Strand) Date: Wed, 29 Aug 2007 11:18:40 -0700 Subject: PetscPrintf/ifort 9.1 In-Reply-To: <46D5A785.80609@imperial.ac.uk> References: <46D4B5E6.7010602@ices.utexas.edu> <46D59F6B.9020701@ices.utexas.edu> <46D5A785.80609@imperial.ac.uk> Message-ID: <46D5B880.7000803@geodynamics.org> Paul T. Bauman wrote: > achar(10) This is precisely the solution I was hoping someone would offer when I said I didn't know Fortran. Fortran users should be expected to express things in Fortran :-) IMHO, PETSc's behavior was correct before. I.e., it was correct to do nothing -- it was correct to simply print the string the user passed-in, with no translation. To do otherwise, PETSc would need a 'configure.py' test which checks to see whether the user's Fortran compiler already performs the "\n" -> LF translation at compile time (as G95 does), so that the translation doesn't get performed twice (consider "\\n")... it just gets messy. Better to do nothing. The only thing slightly fishy about "achar(10)" is that it does assume that PetscPrintf is implemented in C (see below). Stephan Kramer wrote: > While this may work for you, it is certainly not *the* correct way to do > it. achar(10) corresponds to LF, whereas windows systems > expect CR+LF (i.e. achar(13)//achar(10)), it may still work under > windows as well though, depends on your terminal/ application > you view the output with. The correct way in C is really to use \n (and > in the above case I guess), and in fortran to use two > separate write statements. It is fishy (as I said), but since PetscPrintf is implemented in C and ultimately calls vfprintf(), the correct thing will happen on all platforms. E.g., with VC++, the MSVCRT.DLL runtime will translate LF to CR,LF if the underlying "FILE" was opened in text mode. It is portable, because a C/C++ implementation has no choice but to do linefeed translation this way (i.e., at runtime). Consider: #include #include int main() { char buffer[42]; strcpy(buffer, "Hello,\nworld."); printf("%d %d\n", strlen(buffer), buffer[6]); puts(buffer); return 0; } This program will print 13 10 Hello, world. on all platforms (even Windows). (Note that the string has length 13, not 14: "\n" -> LF happened at compile time.) To summarize: A C/C++ compiler translates "\n" to LF at compile time (this transformation is applied to string literals). Therefore LF->CR+LF translation must happen at runtime on Windows (and it will happen even if the string came from Fortran code). What a Fortran compiler does with strings is implementation-dependent. G95 mimics what a C/C++ compiler would do by translating "\n" -> LF in string literals, but this is not standard Fortran. --Leif From bsmith at mcs.anl.gov Wed Aug 29 14:00:03 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Wed, 29 Aug 2007 14:00:03 -0500 (CDT) Subject: PetscPrintf/ifort 9.1 In-Reply-To: <46D59F6B.9020701@ices.utexas.edu> References: <46D4B5E6.7010602@ices.utexas.edu> <46D59F6B.9020701@ices.utexas.edu> Message-ID: Paul, Thanks. I'll add it to the FAQ Barry On Wed, 29 Aug 2007, Paul T. Bauman wrote: > Hi Barry, > > To preface, I sincerely appreciate your prompt response and willingness to > produce quick fixes. > > However, it was pointed out to me in my office today (by someone who knows > more about interfacing C and FORTRAN than I and who watches the petsc-users > list) that the following code would have been the correct way for me to do > this (I tested and it works on intel and g95): > > call PetscPrintf(PETSC_COMM_WORLD, > "==============================================="//achar(10), ierr) > call PetscPrintf(PETSC_COMM_WORLD, " Beginning of > Program"//achar(10), ierr) > call PetscPrintf(PETSC_COMM_WORLD, > "==============================================="//achar(10), ierr) > > 'achar' is a FORTRAN intrinsic function that gets fed an integer and returns > the corresponding ascii character from the ascii character set. In this case, > 10 corresponds to the new line command and thus passes the correct format to > the C call. I tested on the reverted version of zmprint.c and it works > correctly (although it also works correctly with the patch you sent). > > I wanted to share out of the sake of proliferation of knowledge (and not to > make you feel like I wasted your time). Thanks again for your efforts, > especially to us lingering FORTRAN'ers. Hopefully this will clarify in the > future if it ever comes up again. Sorry for the trouble. > > Paul > > Barry Smith wrote: > > Paul, > > > > I have pushed a fix to petsc-dev that resolves this problem. If you are > > not using petsc-dev you can simply replace the file > > src/sys/fileio/ftn-custom/zmprintf.c with the attached file then run make > > lib shared in that directory then relink your program. > > > > Barry > > > > > > On Tue, 28 Aug 2007, Paul T. Bauman wrote: > > > > > > > Hello, > > > > > > Kind of a non-numerical question - sorry. I'm using PetscPrintf from > > > Fortran > > > using the following calling sequence (for example): > > > > > > call PetscPrintf(PETSC_COMM_WORLD, > > > "=============================================== \n", ierr) > > > call PetscPrintf(PETSC_COMM_WORLD, " Beginning of > > > Program > > > \n", ierr) > > > call PetscPrintf(PETSC_COMM_WORLD, > > > "=============================================== \n", ierr) > > > > > > On my mac laptop (PowerPC) with PETSc 2.3.2-p7 compiled with gcc 4.0.1 and > > > g95, this prints as expected: > > > > > > =============================================== > > > Beginning of Program > > > =============================================== > > > > > > On a linux workstation (AMD Opteron) with PETSc 2.3.2-p7 compiled with > > > icc, > > > icxx, ifort 9.1, the "\n" is treated as a character and not treated as > > > "move > > > to new line" so the output is all on one line: > > > > > > =============================================== \n Beginning > > > of > > > Program \n=============================================== \n > > > > > > While not the end of the world, it is a bit annoying. Am I screwing up the > > > calling sequence and just got lucky with g95? Or a bug (PETSc or Intel)? > > > > > > Thanks, > > > > > > Paul > > > > > > P.S. The reason why I care is because on any compiler I've used (other > > > than > > > Intel), write(*,*) prints out at different times and not in sequence with > > > PETSc so all my output comes out after PETSc is done outputting. Using > > > PetscPrintf, I can have everything print out in order. > > > > > > > > From bsmith at mcs.anl.gov Wed Aug 29 14:02:09 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Wed, 29 Aug 2007 14:02:09 -0500 (CDT) Subject: PetscPrintf/ifort 9.1 In-Reply-To: <46D5B880.7000803@geodynamics.org> References: <46D4B5E6.7010602@ices.utexas.edu> <46D59F6B.9020701@ices.utexas.edu> <46D5A785.80609@imperial.ac.uk> <46D5B880.7000803@geodynamics.org> Message-ID: On Wed, 29 Aug 2007, Leif Strand wrote: > IMHO, PETSc's behavior was correct before. I.e., it was correct to do nothing > -- it was correct to simply print the string the user passed-in, with no > translation. To do otherwise, PETSc would need a 'configure.py' test which > checks to see whether the user's Fortran compiler already performs the "\n" -> > LF translation at compile time (as G95 does), so that the translation doesn't > get performed twice (consider "\\n")... it just gets messy. Better to do > nothing. Actually this is not a problem, as was pointed out before the C compiler replaces the \n with a single charactor (ASCII 10) so my simple search and replace will never see the STRING "\n" when the Fortran compiler is gfortran so nothing will be done twice. Barry > > The only thing slightly fishy about "achar(10)" is that it does assume that > PetscPrintf is implemented in C (see below). > > > Stephan Kramer wrote: > > While this may work for you, it is certainly not *the* correct way to do it. > > achar(10) corresponds to LF, whereas windows systems > > expect CR+LF (i.e. achar(13)//achar(10)), it may still work under windows as > > well though, depends on your terminal/ application > > you view the output with. The correct way in C is really to use \n (and in > > the above case I guess), and in fortran to use two > > separate write statements. > > It is fishy (as I said), but since PetscPrintf is implemented in C and > ultimately calls vfprintf(), the correct thing will happen on all platforms. > E.g., with VC++, the MSVCRT.DLL runtime will translate LF to CR,LF if the > underlying "FILE" was opened in text mode. > > It is portable, because a C/C++ implementation has no choice but to do > linefeed translation this way (i.e., at runtime). Consider: > > #include > #include > > int main() > { > char buffer[42]; > strcpy(buffer, "Hello,\nworld."); > printf("%d %d\n", strlen(buffer), buffer[6]); > puts(buffer); > return 0; > } > > This program will print > > 13 10 > Hello, > world. > > on all platforms (even Windows). (Note that the string has length 13, not 14: > "\n" -> LF happened at compile time.) > > To summarize: A C/C++ compiler translates "\n" to LF at compile time (this > transformation is applied to string literals). Therefore LF->CR+LF > translation must happen at runtime on Windows (and it will happen even if the > string came from Fortran code). What a Fortran compiler does with strings is > implementation-dependent. G95 mimics what a C/C++ compiler would do by > translating "\n" -> LF in string literals, but this is not standard Fortran. > > --Leif > > From leif at geodynamics.org Wed Aug 29 15:24:07 2007 From: leif at geodynamics.org (Leif Strand) Date: Wed, 29 Aug 2007 13:24:07 -0700 Subject: PetscPrintf/ifort 9.1 In-Reply-To: References: <46D4B5E6.7010602@ices.utexas.edu> <46D59F6B.9020701@ices.utexas.edu> <46D5A785.80609@imperial.ac.uk> <46D5B880.7000803@geodynamics.org> Message-ID: <46D5D5E7.90506@geodynamics.org> Barry Smith wrote: > On Wed, 29 Aug 2007, Leif Strand wrote: >> (consider "\\n") > Actually this is not a problem, as was pointed out before the C compiler > replaces the \n with a single charactor (ASCII 10) so my simple search and > replace will never see the STRING "\n" when the Fortran compiler is gfortran > so nothing will be done twice. Again, consider "\\n". With PetscFixSlashN(), you are trying to meet the expectations of C programmers. So, let's say I write the C-ish quasi-Fortran code, 'call PetscPrintf("\\no")'. As a C programmer, I might expect this to print: \no [Of course, if I had plenty of coffee this morning, I would know I was calling 'PetscPrintf' from Fortran, and therefore, I would not know what to expect in this case, but we've already covered that.] Intel's ifort will leave "\\n" as "\\n", so PetscFixSlashN() will see "\\n" at runtime. As of right now, PetscFixSlashN() code doesn't handle "\\" correctly, so it will munge it so that it becomes {'\\', '\n', 'o'} and will PETSc print \ o which is not what I intended. If you beef-up PetscFixSlashN() so that it handles escaped-backslashes ("\\"), you've "fixed" the 'ifort' case, but G95 is still broken. G95 will translate "\\no" to "\no" itself, at compile-time. So PetscFixSlashN() will see "\no" at runtime, and behave as if I had written "\no" in my code: [LF] o At runtime, you have no way of knowing whether the user's Fortran compiler did "\x" translation at compile-time, so you would need a 'configure.py' test to check this -- and even then, PETSc would screw up in non-trivial cases (what if the string was generated?). Better to do nothing than to have a half-baked implementation which satisfies users' faulty expectations. --Leif From bsmith at mcs.anl.gov Wed Aug 29 15:50:41 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Wed, 29 Aug 2007 15:50:41 -0500 (CDT) Subject: PetscPrintf/ifort 9.1 In-Reply-To: <46D5D5E7.90506@geodynamics.org> References: <46D4B5E6.7010602@ices.utexas.edu> <46D59F6B.9020701@ices.utexas.edu> <46D5A785.80609@imperial.ac.uk> <46D5B880.7000803@geodynamics.org> <46D5D5E7.90506@geodynamics.org> Message-ID: Leif, You obviously have thought about this more then me; I wasn't even considering supporting \\, etc. So yes, it could generate unexpected results. Since I cannot do it exactly right and general I will simply remove PetscPrintf() and friends from PETSc for Fortran. Barry On Wed, 29 Aug 2007, Leif Strand wrote: > Barry Smith wrote: > > On Wed, 29 Aug 2007, Leif Strand wrote: > > > (consider "\\n") > > > Actually this is not a problem, as was pointed out before the C compiler > > replaces the \n with a single charactor (ASCII 10) so my simple search and > > replace will never see the STRING "\n" when the Fortran compiler is gfortran > > so nothing will be done twice. > > Again, consider "\\n". With PetscFixSlashN(), you are trying to meet the > expectations of C programmers. So, let's say I write the C-ish quasi-Fortran > code, 'call PetscPrintf("\\no")'. As a C programmer, I might expect this to > print: > > \no > > [Of course, if I had plenty of coffee this morning, I would know I was calling > 'PetscPrintf' from Fortran, and therefore, I would not know what to expect in > this case, but we've already covered that.] > > Intel's ifort will leave "\\n" as "\\n", so PetscFixSlashN() will see "\\n" at > runtime. As of right now, PetscFixSlashN() code doesn't handle "\\" > correctly, so it will munge it so that it becomes {'\\', '\n', 'o'} and will > PETSc print > > \ > o > > which is not what I intended. > > If you beef-up PetscFixSlashN() so that it handles escaped-backslashes ("\\"), > you've "fixed" the 'ifort' case, but G95 is still broken. G95 will translate > "\\no" to "\no" itself, at compile-time. So PetscFixSlashN() will see "\no" > at runtime, and behave as if I had written "\no" in my code: > > [LF] > o > > At runtime, you have no way of knowing whether the user's Fortran compiler did > "\x" translation at compile-time, so you would need a 'configure.py' test to > check this -- and even then, PETSc would screw up in non-trivial cases (what > if the string was generated?). > > Better to do nothing than to have a half-baked implementation which satisfies > users' faulty expectations. > > --Leif > > From bsmith at mcs.anl.gov Wed Aug 29 15:52:47 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Wed, 29 Aug 2007 15:52:47 -0500 (CDT) Subject: PetscPrintf/ifort 9.1 In-Reply-To: References: <46D4B5E6.7010602@ices.utexas.edu> <46D59F6B.9020701@ices.utexas.edu> <46D5A785.80609@imperial.ac.uk> <46D5B880.7000803@geodynamics.org> <46D5D5E7.90506@geodynamics.org> Message-ID: Actually after thinking about this for a few minutes I realized my mistake in logic. Since I cannot make PETSc exactly right and general I will be bring down the server in a few minutes and start deleting all the PETSc files. Barry On Wed, 29 Aug 2007, Barry Smith wrote: > > Leif, > > You obviously have thought about this more then me; I wasn't even > considering supporting \\, etc. So yes, it could generate unexpected results. > > Since I cannot do it exactly right and general I will simply remove > PetscPrintf() and friends from PETSc for Fortran. > > Barry > > > On Wed, 29 Aug 2007, Leif Strand wrote: > > > Barry Smith wrote: > > > On Wed, 29 Aug 2007, Leif Strand wrote: > > > > (consider "\\n") > > > > > Actually this is not a problem, as was pointed out before the C compiler > > > replaces the \n with a single charactor (ASCII 10) so my simple search and > > > replace will never see the STRING "\n" when the Fortran compiler is gfortran > > > so nothing will be done twice. > > > > Again, consider "\\n". With PetscFixSlashN(), you are trying to meet the > > expectations of C programmers. So, let's say I write the C-ish quasi-Fortran > > code, 'call PetscPrintf("\\no")'. As a C programmer, I might expect this to > > print: > > > > \no > > > > [Of course, if I had plenty of coffee this morning, I would know I was calling > > 'PetscPrintf' from Fortran, and therefore, I would not know what to expect in > > this case, but we've already covered that.] > > > > Intel's ifort will leave "\\n" as "\\n", so PetscFixSlashN() will see "\\n" at > > runtime. As of right now, PetscFixSlashN() code doesn't handle "\\" > > correctly, so it will munge it so that it becomes {'\\', '\n', 'o'} and will > > PETSc print > > > > \ > > o > > > > which is not what I intended. > > > > If you beef-up PetscFixSlashN() so that it handles escaped-backslashes ("\\"), > > you've "fixed" the 'ifort' case, but G95 is still broken. G95 will translate > > "\\no" to "\no" itself, at compile-time. So PetscFixSlashN() will see "\no" > > at runtime, and behave as if I had written "\no" in my code: > > > > [LF] > > o > > > > At runtime, you have no way of knowing whether the user's Fortran compiler did > > "\x" translation at compile-time, so you would need a 'configure.py' test to > > check this -- and even then, PETSc would screw up in non-trivial cases (what > > if the string was generated?). > > > > Better to do nothing than to have a half-baked implementation which satisfies > > users' faulty expectations. > > > > --Leif > > > > > From gtg100n at mail.gatech.edu Thu Aug 30 12:51:46 2007 From: gtg100n at mail.gatech.edu (Alejandro Garzon) Date: Thu, 30 Aug 2007 13:51:46 -0400 Subject: how efficient is the block diagonal format? In-Reply-To: References: <1188308714.46d426ead8cf3@webmail.mail.gatech.edu> Message-ID: <1188496306.46d703b2e0f79@webmail.mail.gatech.edu> Hi, first of all thanks for your previous help. In section 3.1.1 of the user's manual it is said "Additional formats (such as block compressed row and block diagonal storage, which are generally much more efficient for problems with multiple degrees of freedom per node) are discussed below." I want to know if the efficiency refers to the assembly only or if more important it refers also to how the KSPSolve function will perform with this format. I did a trial and it seems KSPSolve performs at around the same speed with both the default and the block diagonal formats (is even a bit faster with the default format). Is this comparison highly problem dependent? Or could I be missing to use some option? My problem is a 1D pde with 2 variables (two degrees of freedom per node(?)) first and second derivatives terms and a block on the main diagonal mixing the two variables. Thanks. Alejandro. From bsmith at mcs.anl.gov Thu Aug 30 13:55:59 2007 From: bsmith at mcs.anl.gov (Barry Smith) Date: Thu, 30 Aug 2007 13:55:59 -0500 (CDT) Subject: how efficient is the block diagonal format? In-Reply-To: <1188496306.46d703b2e0f79@webmail.mail.gatech.edu> References: <1188308714.46d426ead8cf3@webmail.mail.gatech.edu> <1188496306.46d703b2e0f79@webmail.mail.gatech.edu> Message-ID: Alejandro, I would be surprised if either format was particularly much better than the other. Barry On Thu, 30 Aug 2007, Alejandro Garzon wrote: > > Hi, first of all thanks for your previous help. In section 3.1.1 of the user's > manual it is said "Additional formats (such as block compressed row and block > diagonal storage, which are generally much more efficient for problems with > multiple degrees of freedom per node) are discussed below." I want to know if > the efficiency refers to the assembly only or if more important it refers also > to how the KSPSolve function will perform with this format. I did a trial and it > seems KSPSolve performs at around the same speed with both the default and the > block diagonal formats (is even a bit faster with the default format). Is this > comparison highly problem dependent? Or could I be missing to use some option? > My problem is a 1D pde with 2 variables (two degrees of freedom per node(?)) > first and second derivatives terms and a block on the main diagonal mixing the > two variables. Thanks. > > Alejandro. > > From keita at cray.com Thu Aug 30 20:35:27 2007 From: keita at cray.com (Keita Teranishi) Date: Thu, 30 Aug 2007 20:35:27 -0500 Subject: Problem: complex precision in SuperLU and SUperLU_DIST Message-ID: <925346A443D4E340BEB20248BAFCDBDF0226882D@CFEVS1-IP.americas.cray.com> Hi, I saw a problem when building a complex (--with-scalar-type=complex) version of PETSc with SuperLU and SuperLU_DIST together. It seems that linking fails due to multiple function definitions by SuperLU and SuperLU_DIST as listed below: z_div z_abs1 z_exp d_cnjg d_imag I believe this would occur in any platforms, and this problem never occurs when building a real number (default) version. Thanks, Keita Teranishi, Ph.D. Math Software Group Cray Inc. Email: keita at cray.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From hzhang at mcs.anl.gov Thu Aug 30 21:32:09 2007 From: hzhang at mcs.anl.gov (Hong Zhang) Date: Thu, 30 Aug 2007 21:32:09 -0500 (CDT) Subject: Problem: complex precision in SuperLU and SUperLU_DIST In-Reply-To: <925346A443D4E340BEB20248BAFCDBDF0226882D@CFEVS1-IP.americas.cray.com> References: <925346A443D4E340BEB20248BAFCDBDF0226882D@CFEVS1-IP.americas.cray.com> Message-ID: Keita, Do you use petsc-dev? It seems we or superlu developer fixed this problem not long ago. Configure petsc-dev with '--with-scalar-type=complex --download-superlu=1 --download-superlu_dist=1' works fine on my linux machine. If you still have trouble, please send us the log file. Hong On Thu, 30 Aug 2007, Keita Teranishi wrote: > Hi, > > > > I saw a problem when building a complex (--with-scalar-type=complex) version of PETSc with SuperLU and SuperLU_DIST together. It seems that linking fails due to multiple function definitions by SuperLU and SuperLU_DIST as listed below: > > z_div > > z_abs1 > > z_exp > > d_cnjg > > d_imag > > > > I believe this would occur in any platforms, and this problem never occurs when building a real number (default) version. > > > > > > Thanks, > > > > Keita Teranishi, Ph.D. > > Math Software Group > > Cray Inc. > > Email: keita at cray.com > > > > From keita at cray.com Thu Aug 30 21:57:35 2007 From: keita at cray.com (Keita Teranishi) Date: Thu, 30 Aug 2007 21:57:35 -0500 Subject: Problem: complex precision in SuperLU and SUperLU_DIST In-Reply-To: References: <925346A443D4E340BEB20248BAFCDBDF0226882D@CFEVS1-IP.americas.cray.com> Message-ID: <925346A443D4E340BEB20248BAFCDBDF0226884F@CFEVS1-IP.americas.cray.com> Hi Hong, I used petsc-2.3.3-p3. Let me check if it works with petsc-dev. Thanks, Keita Teranishi, Ph.D. Math Software Group Cray Inc. Email: keita at cray.com -----Original Message----- From: owner-petsc-users at mcs.anl.gov [mailto:owner-petsc-users at mcs.anl.gov] On Behalf Of Hong Zhang Sent: Friday, August 31, 2007 11:32 AM To: petsc-users at mcs.anl.gov Subject: Re: Problem: complex precision in SuperLU and SUperLU_DIST Keita, Do you use petsc-dev? It seems we or superlu developer fixed this problem not long ago. Configure petsc-dev with '--with-scalar-type=complex --download-superlu=1 --download-superlu_dist=1' works fine on my linux machine. If you still have trouble, please send us the log file. Hong On Thu, 30 Aug 2007, Keita Teranishi wrote: > Hi, > > > > I saw a problem when building a complex (--with-scalar-type=complex) version of PETSc with SuperLU and SuperLU_DIST together. It seems that linking fails due to multiple function definitions by SuperLU and SuperLU_DIST as listed below: > > z_div > > z_abs1 > > z_exp > > d_cnjg > > d_imag > > > > I believe this would occur in any platforms, and this problem never occurs when building a real number (default) version. > > > > > > Thanks, > > > > Keita Teranishi, Ph.D. > > Math Software Group > > Cray Inc. > > Email: keita at cray.com > > > >