April 2016 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Correct syntax for DMDA ownership ranges in petsc4py
by Chris Eldred 07 Apr '16

07 Apr '16

I think what happens on the 1st version is that the input list has len(3), and since the DMDA only has 1 dimension petsc4py throws the first ValueError. As far as I can tell, the code is expecting a list of lists: ie for each dimension it gets ranges[i] (where i is the index for the dimension) and casts it into an array. So I tried the 2nd version, which fails regardless of whether I use lists or tuples, and I don't understand why. -Chris On Thu, Apr 7, 2016 at 9:00 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > On Thu, Apr 7, 2016 at 1:52 PM, Chris Eldred <chris.eldred(a)gmail.com> wrote: >> >> Hey All, >> >> (I sent this to petsc-users a few days ago and didn't get any replies, >> figured I would try here as well...) >> >> Does anyone know the correct syntax for setting ownership ranges for >> DMDAs in petsc4py? For example, if I have a 1D DMDA with 20 vertices >> and 3 processes, and I want to distribute the vertices as [8,8,4], >> should the correct create call be: >> >> da = >> PETSc.DMDA().create(dim=1,dof=1,sizes=[20,],proc_sizes=[3,],boundary_type=[PETSc.DM.BoundaryType.PERIODIC,], >> stencil_type= PETSc.DMDA.StencilType.BOX, >> stencil_width=1,ownership_ranges=[8,8,4]) >> >> or >> >> da = >> PETSc.DMDA().create(dim=1,dof=1,sizes=[20,],proc_sizes=[3,],boundary_type=[PETSc.DM.BoundaryType.PERIODIC,], >> stencil_type= PETSc.DMDA.StencilType.BOX, >> stencil_width=1,ownership_ranges=[[8,8,4],]) >> >> For me, the 1st version fails with >> ValueError: number of dimensions 1 and number ownership ranges 3 >> (which I expected) >> but the 2nd version also fails with >> TypeError: Expected tuple, got list >> >> I have tried using tuples instead of lists and nothing changes. >> Creating without the ownership_ranges argument works fine as well. Is >> there something else I am missing? > > > Here is the code: > > > https://bitbucket.org/petsc/petsc4py/src/b234a50085607b793fce93d5dc46307c0d… > > I do not understand why the 1st version fails. > > Matt > >> >> Thanks in advance for any assistance! >> >> Regards, >> -Chris >> >> >> -- >> Chris Eldred >> Postdoctoral Fellow, LAGA, University of Paris 13 >> PhD, Atmospheric Science, Colorado State University, 2015 >> DOE Computational Science Graduate Fellow (Alumni) >> B.S. Applied Computational Physics, Carnegie Mellon University, 2009 >> chris.eldred(a)gmail.com > > > > > -- > 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 -- Chris Eldred Postdoctoral Fellow, LAGA, University of Paris 13 PhD, Atmospheric Science, Colorado State University, 2015 DOE Computational Science Graduate Fellow (Alumni) B.S. Applied Computational Physics, Carnegie Mellon University, 2009 chris.eldred(a)gmail.com

1 0

Re: [petsc-dev] Correct syntax for DMDA ownership ranges in petsc4py
by Matthew Knepley 07 Apr '16

07 Apr '16

On Thu, Apr 7, 2016 at 1:52 PM, Chris Eldred <chris.eldred(a)gmail.com> wrote: > Hey All, > > (I sent this to petsc-users a few days ago and didn't get any replies, > figured I would try here as well...) > > Does anyone know the correct syntax for setting ownership ranges for > DMDAs in petsc4py? For example, if I have a 1D DMDA with 20 vertices > and 3 processes, and I want to distribute the vertices as [8,8,4], > should the correct create call be: > > da = > PETSc.DMDA().create(dim=1,dof=1,sizes=[20,],proc_sizes=[3,],boundary_type=[PETSc.DM.BoundaryType.PERIODIC,], > stencil_type= PETSc.DMDA.StencilType.BOX, > stencil_width=1,ownership_ranges=[8,8,4]) > > or > > da = > PETSc.DMDA().create(dim=1,dof=1,sizes=[20,],proc_sizes=[3,],boundary_type=[PETSc.DM.BoundaryType.PERIODIC,], > stencil_type= PETSc.DMDA.StencilType.BOX, > stencil_width=1,ownership_ranges=[[8,8,4],]) > > For me, the 1st version fails with > ValueError: number of dimensions 1 and number ownership ranges 3 > (which I expected) > but the 2nd version also fails with > TypeError: Expected tuple, got list > > I have tried using tuples instead of lists and nothing changes. > Creating without the ownership_ranges argument works fine as well. Is > there something else I am missing? > Here is the code: https://bitbucket.org/petsc/petsc4py/src/b234a50085607b793fce93d5dc46307c0d… I do not understand why the 1st version fails. Matt > Thanks in advance for any assistance! > > Regards, > -Chris > > > -- > Chris Eldred > Postdoctoral Fellow, LAGA, University of Paris 13 > PhD, Atmospheric Science, Colorado State University, 2015 > DOE Computational Science Graduate Fellow (Alumni) > B.S. Applied Computational Physics, Carnegie Mellon University, 2009 > chris.eldred(a)gmail.com > -- 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

1 0

Correct syntax for DMDA ownership ranges in petsc4py
by Chris Eldred 07 Apr '16

07 Apr '16

Hey All, (I sent this to petsc-users a few days ago and didn't get any replies, figured I would try here as well...) Does anyone know the correct syntax for setting ownership ranges for DMDAs in petsc4py? For example, if I have a 1D DMDA with 20 vertices and 3 processes, and I want to distribute the vertices as [8,8,4], should the correct create call be: da = PETSc.DMDA().create(dim=1,dof=1,sizes=[20,],proc_sizes=[3,],boundary_type=[PETSc.DM.BoundaryType.PERIODIC,], stencil_type= PETSc.DMDA.StencilType.BOX, stencil_width=1,ownership_ranges=[8,8,4]) or da = PETSc.DMDA().create(dim=1,dof=1,sizes=[20,],proc_sizes=[3,],boundary_type=[PETSc.DM.BoundaryType.PERIODIC,], stencil_type= PETSc.DMDA.StencilType.BOX, stencil_width=1,ownership_ranges=[[8,8,4],]) For me, the 1st version fails with ValueError: number of dimensions 1 and number ownership ranges 3 (which I expected) but the 2nd version also fails with TypeError: Expected tuple, got list I have tried using tuples instead of lists and nothing changes. Creating without the ownership_ranges argument works fine as well. Is there something else I am missing? Thanks in advance for any assistance! Regards, -Chris -- Chris Eldred Postdoctoral Fellow, LAGA, University of Paris 13 PhD, Atmospheric Science, Colorado State University, 2015 DOE Computational Science Graduate Fellow (Alumni) B.S. Applied Computational Physics, Carnegie Mellon University, 2009 chris.eldred(a)gmail.com

1 0

Need help with Fortran code/compiler issue
by Barry Smith 07 Apr '16

07 Apr '16

src/sys/classes/bag/f2003-src/fsrc/bagenum.F has the code fragment Subroutine PetscBagRegisterEnum(bag,addr,FArray,def,n,h,ierr) use,intrinsic :: iso_c_binding implicit none PetscBag bag character(*) n,h character(*) FArray(*) PetscEnum :: def PetscErrorCode,intent(out) :: ierr PetscReal addr(*) Type(C_Ptr),Dimension(:),Pointer :: CArray character(kind=c_char),pointer :: nullc => null() PetscInt :: i,Len Character(kind=C_char,len=256),Dimension(:),Pointer::list1 do i=1,256 if (len_trim(Farray(i)) .eq. 0) then Len = i-1 goto 100 endif if (len_trim(Farray(i)) .gt. 255) then ierr = PETSC_ERR_ARG_OUTOFRANGE return endif enddo ierr = PETSC_ERR_ARG_OUTOFRANGE return 100 continue Allocate(list1(Len),stat=ierr); Allocate(CArray(Len+1),stat=ierr) do i=1,Len list1(i) = trim(FArray(i))//C_NULL_CHAR enddo CArray = (/(c_loc(list1(i)),i=1,Len),c_loc(nullc)/) call PetscBagRegisterEnumPrivate(bag,addr,CArray,def,n,h,ierr) DeAllocate(CArray) DeAllocate(list1) End Subroutine which produces the following warning with one Fortran compiler: /Users/petsc/petsc.clone-4/src/sys/objects/f2003-src/fsrc/optionenum.F:35:0: CArray = (/(c_loc(list1(i)),i=1,Len),c_loc(nullc)/) ^ Warning: 'list1.data' may be used uninitialized in this function [-Wmaybe-uninitialized] Do any Fortran programmers know if the code is correct or if this is an incorrect warning from the compiler? Thanks Barry

1 0

Re: [petsc-dev] PETSc blame digest
by Jed Brown 07 Apr '16

07 Apr '16

Satish Balay <balay(a)mcs.anl.gov> writes: > Thanks for the patch. I can add it in. > > Wrt TSAdaptCheckStage() - there is one more warning - its associated > with lines Jed changed - so you didn't see this. Well, it's caused by his change and it does appear to change the semantics. When I wrote the code, scale_solve_failed was associated with a solver failing. With the change, it is associated with any reason that the stage is rejected. Does that make sense? If so, the name needs to be changed to reflect what it actually does. If not, we need a possibly-different scaling. Also, when we exceed ts->max_snes_failures, the user will now see one line saying the number of failures is greater than the max allowed followed by a line saying the step is being retried, and then it won't be retried. It's clearly a bug with Pierre's patch.

1 0

Re: [petsc-dev] PETSc blame digest
by Satish Balay 07 Apr '16

07 Apr '16

Thanks for the patch. I can add it in. Wrt TSAdaptCheckStage() - there is one more warning - its associated with lines Jed changed - so you didn't see this. CC arch-linux2-c-debug/obj/src/ts/adapt/interface/tsadapt.o /home/balay/petsc/src/ts/adapt/interface/tsadapt.c:639:7: warning: Value stored to 'new_dt' is never read new_dt = dt*adapt->scale_solve_failed; ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 warning generated. Perhaps the following fix? diff --git a/src/ts/adapt/interface/tsadapt.c b/src/ts/adapt/interface/tsadapt.c index 2193b98..5beecdd 100644 --- a/src/ts/adapt/interface/tsadapt.c +++ b/src/ts/adapt/interface/tsadapt.c @@ -635,8 +635,6 @@ PetscErrorCode TSAdaptCheckStage(TSAdapt adapt,TS ts,PetscReal t,Vec Y,PetscBool ierr = PetscViewerASCIIPrintf(adapt->monitor," TSAdapt '%s': step %3D stage rejected t=%-11g+%10.3e, nonlinear solve failures %D greater than current TS allowed\n",((PetscObject)adapt)->type_name,ts->steps,(double)ts->ptime,dt,ts->num_snes_failures);CHKERRQ(ierr); ierr = PetscViewerASCIISubtractTab(adapt->monitor,((PetscObject)adapt)->tablevel);CHKERRQ(ierr); } - } else { - new_dt = dt*adapt->scale_solve_failed; } } else { ierr = TSFunctionDomainError(ts,t,Y,accept);CHKERRQ(ierr); We just enabled this clang analyzer test - its showing quiet a few things - its giving a huge list of issues to go through.. Satish On Thu, 7 Apr 2016, Pierre Barbier de Reuille wrote: > Hey, > > I just received this blame: > http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/07/build_next_… > > I corrected it by initializing dt and new_dt to 0 in TSAdaptCheckStage. > Note that dt cannot be used before is properly initialized using the > TSGetTimeStep function. > > The result is in the branch > PierreBdR/initialized-dt-and-new_dt-in-tsadaptchec-1460047069883 > <https://bitbucket.org/PierreBdR/petsc-1/branch/PierreBdR/initialized-dt-and…> > (sorry for the name, I used the online editor for such a small > modification). > > Cheers, > > Pierre >

1 0

PETSc blame digest
by Pierre Barbier de Reuille 07 Apr '16

07 Apr '16

Hey, I just received this blame: http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/07/build_next_… I corrected it by initializing dt and new_dt to 0 in TSAdaptCheckStage. Note that dt cannot be used before is properly initialized using the TSGetTimeStep function. The result is in the branch PierreBdR/initialized-dt-and-new_dt-in-tsadaptchec-1460047069883 <https://bitbucket.org/PierreBdR/petsc-1/branch/PierreBdR/initialized-dt-and…> (sorry for the name, I used the online editor for such a small modification). Cheers, Pierre -- Dr. Barbier de Reuille, Pierre Institute of Plant Sciences University of Bern Altenbergrain 21, CH-3013 Bern, Switzerland

1 0

Re: [petsc-dev] [petsc-checkbuilds] PETSc blame digest (next) 2016-04-06
by Barry Smith 06 Apr '16

06 Apr '16

My fault. Will fix. > On Apr 6, 2016, at 9:00 AM, PETSc checkBuilds <petsc-checkbuilds(a)mcs.anl.gov> wrote: > > > > Dear PETSc developer, > > This email contains listings of contributions attributed to you by > `git blame` that caused compiler errors or warnings in PETSc automated > testing. Follow the links to see the full log files. Please attempt to fix > the issues promptly or let us know at petsc-dev(a)mcs.anl.gov if you are unable > to resolve the issues. > > Thanks, > The PETSc development team > > ---- > > warnings attributed to commit https://bitbucket.org/petsc/petsc/commits/943ccf5 > Vec IO: support large file sizes using local displacement > > src/vec/vec/impls/mpi/pdvec.c:424 > [http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/06/build_next_…] > /scratch/petsc/petsc.clone-4/src/vec/vec/impls/mpi/pdvec.c:424:10: warning: 'n' may be used uninitialized in this function [-Wuninitialized] > [http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/06/build_next_…] > /sandbox/petsc/petsc.clone/src/vec/vec/impls/mpi/pdvec.c:424:10: warning: 'n' may be used uninitialized in this function [-Wmaybe-uninitialized] > [http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/06/build_next_…] > C:\cygwin\home\sbalay\PETSC~1.CLO\src\vec\vec\impls\mpi\pdvec.c(424) : warning C4700: local variable 'n' used without having been initialized > > src/vec/vec/impls/mpi/pdvec.c:429 > [http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/04/06/build_next_…] > /sandbox/petsc/petsc.clone-4/src/vec/vec/impls/mpi/pdvec.c:429:10: warning: 'n' may be used uninitialized in this function [-Wmaybe-uninitialized] > > ---- > To opt-out from receiving these messages - send a request to petsc-dev(a)mcs.anl.gov.

1 0

Re: [petsc-dev] Support for complex scalars in VECCUDA
by Karl Rupp 05 Apr '16

05 Apr '16

Hi, merged to master here: https://bitbucket.org/petsc/petsc/commits/cc442fcaaa4aca6018ff5a2fdf6cd9e8c… Thanks! :-) Best regards, Karli On 04/05/2016 11:03 AM, Jose E. Roman wrote: > Hi Karl, > > We would like to add support for complex scalars in VECCUDA and MATAIJCUSPARSE. This is almost finished and we plan to create a new pull request for this. Is PR #421 ready to merge? > > Jose >

1 0

Re: [petsc-dev] Support for complex scalars in VECCUDA
by Karl Rupp 05 Apr '16

05 Apr '16

Hi Jose, > We would like to add support for complex scalars in VECCUDA and MATAIJCUSPARSE. This is almost finished and we plan to create a new pull request for this. Is PR #421 ready to merge? Yes, PR 421 looks good, there are no issues in the nightly tests. I'll merge it later today. Best regards, Karli

1 0