August 2018 - petsc-dev - mailman3.cels.anl.gov

any script to extract data from "-log_view"?
by Fande Kong 08 Aug '18

08 Aug '18

Hi all, If we are going to do a scaling study, can we automatically make a plot based on a bunch of output files (from -log_view)? It is a big pain to manually copy data if we have a lot of output files. Fande,

1 0

Re: [petsc-dev] Petsc 19 conflict calendar
by Matthew Knepley 07 Aug '18

07 Aug '18

On Tue, Aug 7, 2018 at 12:24 PM Tobin Isaac <tisaac(a)cc.gatech.edu> wrote: > > Hi all, > > If you subscribe to petsc-dev, you might be interested in getting in > on the ground floor of planning our Summer 2019 meeting in Atlanta. > > It would be good to get a list of conflicts for June-ish. We've just > found out, for instance, that the SC'19 PC meeting will be June 3--4. > > These can be for any reason, but if your conflict is due to another > conference you attend, could you highlight that so that nothing slips > under our radar? > > You can respond to this thread (your response will be public), or > you can send your response to me directly. > The Gene Golub Summer School (this year its on HPC for Data Analysis :), will be held June 17-28. I will go at least the first week. Thanks, Matt > Thanks, > Toby > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>

1 0

Petsc 19 conflict calendar
by Tobin Isaac 07 Aug '18

07 Aug '18

Hi all, If you subscribe to petsc-dev, you might be interested in getting in on the ground floor of planning our Summer 2019 meeting in Atlanta. It would be good to get a list of conflicts for June-ish. We've just found out, for instance, that the SC'19 PC meeting will be June 3--4. These can be for any reason, but if your conflict is due to another conference you attend, could you highlight that so that nothing slips under our radar? You can respond to this thread (your response will be public), or you can send your response to me directly. Thanks, Toby

1 0

Fwd: SC19 planning
by Tobin Isaac 07 Aug '18

07 Aug '18

-------- Original Message -------- From: "Richard (Rich) Vuduc" <richie(a)cc.gatech.edu> Sent: August 7, 2018 10:35:09 AM EDT To: Tobin Isaac <tisaac(a)gatech.edu> Cc: Edmond Chow <echow(a)cc.gatech.edu>, Srinivas Aluru <aluru(a)cc.gatech.edu> Subject: Fwd: SC19 planning Toby: The answer is June 3-4. -- Rich ---------- Forwarded message ---------- From: Michelle Strout <mstrout(a)cs.arizona.edu> Date: Tue, Aug 7, 2018 at 9:11 AM Subject: Re: SC19 planning To: "Richard (Rich) Vuduc" <richie(a)cc.gatech.edu> Hi Rich, The PC meeting will be June 3-4, 2019. Here are ALL the dates: *Initial submission: - March 1, 2019 Submissions open- Tuesday April 2, 2019 Abstracts submission deadline- Wednesday April 10, 2019 Full paper deadline (no extensions)Starting the review process: - Thursday April 11, 2019 Reviewer bidding closes- Saturday April 13, 2019 Review assignments to PCSecond submission: - May 11, 2019 Reviews sent- May 25, 2019 Resubmission deadline- June 3–4, 2019 Committee meeting- June 15, 2019 Author notifications sentFinal revision (for only a small number of papers) - July 12, 2019 Major revision deadline - August 9, 2019 Major revision notification- August 28, 2019 Final paper deadline* Michelle Strout Professor and Acting Department Head Department of Computer Science University of Arizona http://www.cs.arizona.edu/~mstrout On Mon, Aug 6, 2018 at 7:33 AM, Richard (Rich) Vuduc <richie(a)cc.gatech.edu> wrote: > Are the approximate dates of the SC19 PC meeting known? A colleague is > trying to plan a conference and wants to avoid potential conflicts. > > -- Rich > > ---------- Forwarded message ---------- > From: Tobin Isaac <tisaac(a)cc.gatech.edu> > Date: Mon, Aug 6, 2018 at 1:17 PM > Subject: SC19 planning > To: "Chow, Edmond T" <echow(a)cc.gatech.edu>, "Richard (Rich) Vuduc" < > richie(a)cc.gatech.edu>, Srinivas Aluru <saluru8(a)gatech.edu> > > > > Hi colleagues, > > I noticed that you were on the SC18 technical program this year. I'm > helping to plan a conference for next summer that unfortunately > conflicted with the review meeting this June. If you know when / by > whom the dates will be set for SC19, could you let me know? > > Thanks, > Toby > > >

1 0

Re: [petsc-dev] MatMult_Scatter : INSERT_VALUES?
by Dave May 03 Aug '18

03 Aug '18

Thanks Barry On Fri, 3 Aug 2018 at 20:08, Smith, Barry F. <bsmith(a)mcs.anl.gov> wrote: > > Hmm, I think the current code makes the most sense. > > In your case what if the two "from" values destined for the same "to" > location are different values, then your algorithm is ill-defined; Indeed - but I can ensure this won't occur. which of the two values "wins"? > > To get the effect you want I think you need to insure that two > different "from" locations are not destined for the same "to" location when > you create the scatter. Yeah ok > > Barry > > If you really need the effect you want and cannot fix the scatter you > could use a MATSHELL to mimic the MATSCATTER behavior except using the > INSERT_VALUES instead. Due to various reason of my DM implementation this is kind of awkward to do. Since I'd like to keep using the MatScatter API for consistency else where in the code base, I think Instead I'll just override the mat mult method for my special use case / DM implementation. Cheers, Dave > > > On Aug 3, 2018, at 3:09 AM, Dave May <dave.mayhem23(a)gmail.com> wrote: > > > > Hi, > > > > I am wondering why MatMult_Scatter() internally uses ADD_VALUES with > VecScatter{Begin,End} rather than INSERT_VALUES? > > > > In the event that the IS used by the scatter defines duplicate values in > the to[] array, e.g. two ranks define the same value of where to insert a > value, then the current implementation of MatMult_Scatter produces the > incorrect result. > > > > You could argue that the user defined IS is wrong in this case as it > contains duplicate to[] values. My particular use case of MatScatter > relates to defining an injection operator between two DMs. For this case, > I'd argue that that we should just be using INSERT_VALUES rather than > ADD_VALUES inside MatMult_Scatter. > > > > Thoughts? > > > > > > Cheers, > > Dave > >

1 0

Re: [petsc-dev] MatMult_Scatter : INSERT_VALUES?
by Smith, Barry F. 03 Aug '18

03 Aug '18

Hmm, I think the current code makes the most sense. In your case what if the two "from" values destined for the same "to" location are different values, then your algorithm is ill-defined; which of the two values "wins"? To get the effect you want I think you need to insure that two different "from" locations are not destined for the same "to" location when you create the scatter. Barry If you really need the effect you want and cannot fix the scatter you could use a MATSHELL to mimic the MATSCATTER behavior except using the INSERT_VALUES instead. > On Aug 3, 2018, at 3:09 AM, Dave May <dave.mayhem23(a)gmail.com> wrote: > > Hi, > > I am wondering why MatMult_Scatter() internally uses ADD_VALUES with VecScatter{Begin,End} rather than INSERT_VALUES? > > In the event that the IS used by the scatter defines duplicate values in the to[] array, e.g. two ranks define the same value of where to insert a value, then the current implementation of MatMult_Scatter produces the incorrect result. > > You could argue that the user defined IS is wrong in this case as it contains duplicate to[] values. My particular use case of MatScatter relates to defining an injection operator between two DMs. For this case, I'd argue that that we should just be using INSERT_VALUES rather than ADD_VALUES inside MatMult_Scatter. > > Thoughts? > > > Cheers, > Dave

1 0

MatMult_Scatter : INSERT_VALUES?
by Dave May 03 Aug '18

03 Aug '18

Hi, I am wondering why MatMult_Scatter() internally uses ADD_VALUES with VecScatter{Begin,End} rather than INSERT_VALUES? In the event that the IS used by the scatter defines duplicate values in the to[] array, e.g. two ranks define the same value of where to insert a value, then the current implementation of MatMult_Scatter produces the incorrect result. You could argue that the user defined IS is wrong in this case as it contains duplicate to[] values. My particular use case of MatScatter relates to defining an injection operator between two DMs. For this case, I'd argue that that we should just be using INSERT_VALUES rather than ADD_VALUES inside MatMult_Scatter. Thoughts? Cheers, Dave

1 0

Re: [petsc-dev] Compiling error with Hypre-2.11.2
by Smith, Barry F. 02 Aug '18

02 Aug '18

How come we don't have version checks as a matter of course for config/packages/xxx.py we constantly get email from people using the wrong version of external packages with obscure error messages wasting their time and hours. Better that hypre.py (and others) compare the version number and exit with a nice error message when incompatible. Barry We could have a field called say supportedversions = ['version1', 'version2',....] > On Aug 2, 2018, at 11:50 AM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > https://bitbucket.org/petsc/petsc/commits/e6de09342ce9c4562cc062ff2c1bac4bd… > > It is compatible with Hypre-2.14. For Hypre-2.11 - you would have to revert the above change. > > Satish > > On Thu, 2 Aug 2018, Antonio Trande wrote: > >> Hi all. >> >> Petsc-3.9.3 does not compile against Hypre-2.11.2: >> >> mpicc -c -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches >> -m64 -mtune=generic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 >> -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 >> -grecord-gcc-switches -m64 -mtune=generic -O3 -Wl,-z,now -fPIC >> -I/builddir/build/BUILD/petsc-3.9.3/buildopenmpi_dir/include >> -I/builddir/build/BUILD/petsc-3.9.3/buildopenmpi_dir/x86_64/include >> -I/usr/include/openmpi-x86_64 -I/usr/include/openmpi-x86_64/hypre >> -MMD -MP >> /builddir/build/BUILD/petsc-3.9.3/buildopenmpi_dir/src/mat/impls/composite/mcomposite.c >> -o x86_64/obj/mat/impls/composite/mcomposite.o >> /builddir/build/BUILD/petsc-3.9.3/buildopenmpi_dir/src/mat/impls/hypre/mhypre.c: >> In function 'hypre_array_destroy': >> /builddir/build/BUILD/petsc-3.9.3/buildopenmpi_dir/src/mat/impls/hypre/mhypre.c:1453:37: >> error: macro "hypre_TFree" passed 2 arguments, but takes just 1 >> hypre_TFree(ptr,HYPRE_MEMORY_HOST); >> ^ >> /builddir/build/BUILD/petsc-3.9.3/buildopenmpi_dir/src/mat/impls/hypre/mhypre.c:1453:4: >> error: 'hypre_TFree' undeclared (first use in this function) >> hypre_TFree(ptr,HYPRE_MEMORY_HOST); >> ^ >> /builddir/build/BUILD/petsc-3.9.3/buildopenmpi_dir/src/mat/impls/hypre/mhypre.c:1453:4: >> note: each undeclared identifier is reported only once for each function >> it appears in >> gmake[2]: *** [x86_64/obj/mat/impls/hypre/mhypre.o] Error 1 >> gmake[2]: *** Waiting for unfinished jobs.... >> gmake[2]: Leaving directory >> `/builddir/build/BUILD/petsc-3.9.3/buildopenmpi_dir' >> >> Full build log: >> https://koji.fedoraproject.org/koji/getfile?taskID=28789567&volume=DEFAULT&… >> >> Dependencies list: >> https://kojipkgs.fedoraproject.org//work/tasks/9567/28789567/root.log >> >

1 0

Re: [petsc-dev] Compiling error with Hypre-2.11.2
by Antonio 02 Aug '18

02 Aug '18

Thank you. Unfortunately, we still have old Hypre-2.11.2 available on EPEL7 repositories. On 02/08/2018 18:50, Satish Balay wrote: > https://bitbucket.org/petsc/petsc/commits/e6de09342ce9c4562cc062ff2c1bac4bd… > > It is compatible with Hypre-2.14. For Hypre-2.11 - you would have to revert the above change. > > Satish > > On Thu, 2 Aug 2018, Antonio Trande wrote: > >> Hi all. >> >> Petsc-3.9.3 does not compile against Hypre-2.11.2: >> >> mpicc -c -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches >> -m64 -mtune=generic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 >> -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 >> -grecord-gcc-switches -m64 -mtune=generic -O3 -Wl,-z,now -fPIC >> -I/builddir/build/BUILD/petsc-3.9.3/buildopenmpi_dir/include >> -I/builddir/build/BUILD/petsc-3.9.3/buildopenmpi_dir/x86_64/include >> -I/usr/include/openmpi-x86_64 -I/usr/include/openmpi-x86_64/hypre >> -MMD -MP >> /builddir/build/BUILD/petsc-3.9.3/buildopenmpi_dir/src/mat/impls/composite/mcomposite.c >> -o x86_64/obj/mat/impls/composite/mcomposite.o >> /builddir/build/BUILD/petsc-3.9.3/buildopenmpi_dir/src/mat/impls/hypre/mhypre.c: >> In function 'hypre_array_destroy': >> /builddir/build/BUILD/petsc-3.9.3/buildopenmpi_dir/src/mat/impls/hypre/mhypre.c:1453:37: >> error: macro "hypre_TFree" passed 2 arguments, but takes just 1 >> hypre_TFree(ptr,HYPRE_MEMORY_HOST); >> ^ >> /builddir/build/BUILD/petsc-3.9.3/buildopenmpi_dir/src/mat/impls/hypre/mhypre.c:1453:4: >> error: 'hypre_TFree' undeclared (first use in this function) >> hypre_TFree(ptr,HYPRE_MEMORY_HOST); >> ^ >> /builddir/build/BUILD/petsc-3.9.3/buildopenmpi_dir/src/mat/impls/hypre/mhypre.c:1453:4: >> note: each undeclared identifier is reported only once for each function >> it appears in >> gmake[2]: *** [x86_64/obj/mat/impls/hypre/mhypre.o] Error 1 >> gmake[2]: *** Waiting for unfinished jobs.... >> gmake[2]: Leaving directory >> `/builddir/build/BUILD/petsc-3.9.3/buildopenmpi_dir' >> >> Full build log: >> https://koji.fedoraproject.org/koji/getfile?taskID=28789567&volume=DEFAULT&… >> >> Dependencies list: >> https://kojipkgs.fedoraproject.org//work/tasks/9567/28789567/root.log >> > -- --- Antonio Trande Fedora Project mailto 'sagitter at fedoraproject dot org' GPG key: 0x5E212EE1D35568BE GPG key server: https://keys.fedoraproject.org/

1 0

Re: [petsc-dev] Compiling error with Hypre-2.11.2
by Satish Balay 02 Aug '18

02 Aug '18

https://bitbucket.org/petsc/petsc/commits/e6de09342ce9c4562cc062ff2c1bac4bd… It is compatible with Hypre-2.14. For Hypre-2.11 - you would have to revert the above change. Satish On Thu, 2 Aug 2018, Antonio Trande wrote: > Hi all. > > Petsc-3.9.3 does not compile against Hypre-2.11.2: > > mpicc -c -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches > -m64 -mtune=generic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 > -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 > -grecord-gcc-switches -m64 -mtune=generic -O3 -Wl,-z,now -fPIC > -I/builddir/build/BUILD/petsc-3.9.3/buildopenmpi_dir/include > -I/builddir/build/BUILD/petsc-3.9.3/buildopenmpi_dir/x86_64/include > -I/usr/include/openmpi-x86_64 -I/usr/include/openmpi-x86_64/hypre > -MMD -MP > /builddir/build/BUILD/petsc-3.9.3/buildopenmpi_dir/src/mat/impls/composite/mcomposite.c > -o x86_64/obj/mat/impls/composite/mcomposite.o > /builddir/build/BUILD/petsc-3.9.3/buildopenmpi_dir/src/mat/impls/hypre/mhypre.c: > In function 'hypre_array_destroy': > /builddir/build/BUILD/petsc-3.9.3/buildopenmpi_dir/src/mat/impls/hypre/mhypre.c:1453:37: > error: macro "hypre_TFree" passed 2 arguments, but takes just 1 > hypre_TFree(ptr,HYPRE_MEMORY_HOST); > ^ > /builddir/build/BUILD/petsc-3.9.3/buildopenmpi_dir/src/mat/impls/hypre/mhypre.c:1453:4: > error: 'hypre_TFree' undeclared (first use in this function) > hypre_TFree(ptr,HYPRE_MEMORY_HOST); > ^ > /builddir/build/BUILD/petsc-3.9.3/buildopenmpi_dir/src/mat/impls/hypre/mhypre.c:1453:4: > note: each undeclared identifier is reported only once for each function > it appears in > gmake[2]: *** [x86_64/obj/mat/impls/hypre/mhypre.o] Error 1 > gmake[2]: *** Waiting for unfinished jobs.... > gmake[2]: Leaving directory > `/builddir/build/BUILD/petsc-3.9.3/buildopenmpi_dir' > > Full build log: > https://koji.fedoraproject.org/koji/getfile?taskID=28789567&volume=DEFAULT&… > > Dependencies list: > https://kojipkgs.fedoraproject.org//work/tasks/9567/28789567/root.log >

1 0