March 2020 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Globsearch fails for me when running tests
by Scott Kruger 30 Mar '20

30 Mar '20

Sorry for the delay. Fixed in MR !2663. It turns out that the *read* for $(file <...) did not occur until gmake 4.2 so this bit me even on a (admittedly old) Linux dev box. To enable the widest range of usage, I keep a modified version of the current $(shell ...) usage, but have commented out the gmake >4.2 solution for people who want the truly scalable solution (e.g., globsearch='*'). The current fix should work until dm, or other package, gets to around 9K tests which seems to be when globsearch failed. The new solution uses an upgraded `config/query_tests.py` script so is similar to the query/queryval functionality. Scott On 3/28/20 10:34 AM, Satish Balay via petsc-dev wrote: > On Sat, 28 Mar 2020, Jed Brown wrote: > >> Matthew Knepley <knepley(a)gmail.com> writes: >> >>>>> IIRC, the $(file ...) function does not work with stock make in macOS. >>>> >>>> You're right; that is a make 4.0 feature. But developers who need >>>> globsearch should have the ability to evade Apple's anti-GNU smear. >>>> >>> >>> Do we really have to make things hard on Mac to use something I use every >>> day hundreds of times? >> >> Are you still using make-3.81? Do you also use an Apple Newton? >> >> You can still use search and searchin. >> >> Scott can implement globsearch to call Python that calls make print-test >> (listing tests on stdout) and returns the result on stdout. But it >> can't pass the list all the tests on the command line. >> > > Configure has been printing this warning for a very long time - but its easily ignored.. > > =============================================================================== > ***** WARNING: You have an older version of Gnu make, it will work, > but may not support all the parallel testing options. You can install the > latest Gnu make with your package manager, such as brew or macports, or use > the --download-make option to get the latest Gnu make ***** > =============================================================================== > > Satish > -- Tech-X Corporation kruger(a)txcorp.com 5621 Arapahoe Ave, Suite A Phone: (720) 974-1841 Boulder, CO 80303 Fax: (303) 448-7756

1 0

Fortran error
by Mark Adams 30 Mar '20

30 Mar '20

We are developing a Fortran interface for DMSwarm and I am getting these make error. I have compared the patterns with DMPlex and I can't see any difference. Does anyone have any ideas? Thanks, Mark

1 0

Re: [petsc-dev] PETSc 3.13 release
by Satish Balay 30 Mar '20

30 Mar '20

Sorry - this subject should have said: PETSc 3.13 release Satish On Mon, 30 Mar 2020, Satish Balay wrote: > > We are pleased to announce the release of PETSc version 3.13 at http://www.mcs.anl.gov/petsc > > The major changes and updates can be found at http://www.mcs.anl.gov/petsc/documentation/changes/313.html > > The final update to petsc-3.12 i.e petsc-3.12.5 is also available > > We recommend upgrading to PETSc 3.13 soon. As always, please report problems to petsc-maint(a)mcs.anl.gov and ask questions at petsc-users(a)mcs.anl.gov > > This release includes contributions from > > Alp Dener > Barry Smith > Betrie, Getnet > Brandon Whitchurch > Claas Abert > Fande Kong > Florian > Getnet Betrie > Hannah Morgan > Hansol Suh > Hong Zhang > Jacob Faibussowitsch > Jed Brown > Jeremy L Thompson > Jose Roman > Junchao Zhang > Klaus Zimmermann > Lawrence Mitchell > Lisandro Dalcin > marius > Martin Diehl > Matthew Knepley > Mr. Hong Zhang > Patrick Sanan > Peter Hill > Pierre Jolivet > Richard Tran Mills > Sajid Ali > Satish Balay > Scott Kruger > Scott MacLachlan > Shrirang Abhyankar > Stefano Zampini > Steve Benbow > Toby Isaac > Tyler Chen > Vaclav Hapla > Valeria Barra > > > and bug reports/patches/proposed improvements received from > > > "Abhyankar, Shrirang G" > Arash Mehraban > Barry Smith > Benjamin Bugeat > Brandon Denton > Cameron Smith > Carl Hall > Claudio Tomasi > "David, Cedric H (US 329F)" > Dipankar Dwivedi > Dmitry Melnichuk > Ed Bueler > Emmanuel Ayala > Eric Chamberland > Fande Kong > Frederic Vi > Gautam Bisht > Guangming Wang > Hong Zhang > Ivan Blagopoluchnyy > Jacob Faibussowitsch > James Ramsey > James Wright > Jan Grieï¿œer > Jaysaval, Piyoosh > Jed Brown > Jeremy Thompson > Jin Chen > jordic > Jose E. Roman > Junchao Zhang > Justin Herter > Kai Germaschewski > Lisandro Dalcin > Marius Buerkle > Mark Adams > Mark Lohry > Martin Diehl > Matthew Knepley > "McInnes, Lois Curfman" > Mehmet Sahin > Miguel Fosas de Pando > Miguel Salazar De Troya > mphysx team > "Nourgaliev, Robert Nr" > "Ofori-Opoku, Nana" > PAEZ ESPEJO Miguel-Angel EUROGICIEL INGENIERIE > Patrick Zulian > Paul T. Bauman > Philippe Billuart > Pierre Jolivet > Ramin Moghadasi > Randall Mackie > Richard Tran Mills > Sajid Ali > Sam Guo > Satish Balay > Scott Kruger > Sï¿œbastien Gilles > Thibaut Appel > Toby Isaac > Tomas Mondragon > Valeria Barra > Victor Eijkhout > Xiaodong Liu > > As always, thanks for your support, > > Satish, on behalf of PETSc team

1 0

PETSc 3.12 release
by Satish Balay 30 Mar '20

30 Mar '20

We are pleased to announce the release of PETSc version 3.13 at http://www.mcs.anl.gov/petsc The major changes and updates can be found at http://www.mcs.anl.gov/petsc/documentation/changes/313.html The final update to petsc-3.12 i.e petsc-3.12.5 is also available We recommend upgrading to PETSc 3.13 soon. As always, please report problems to petsc-maint(a)mcs.anl.gov and ask questions at petsc-users(a)mcs.anl.gov This release includes contributions from Alp Dener Barry Smith Betrie, Getnet Brandon Whitchurch Claas Abert Fande Kong Florian Getnet Betrie Hannah Morgan Hansol Suh Hong Zhang Jacob Faibussowitsch Jed Brown Jeremy L Thompson Jose Roman Junchao Zhang Klaus Zimmermann Lawrence Mitchell Lisandro Dalcin marius Martin Diehl Matthew Knepley Mr. Hong Zhang Patrick Sanan Peter Hill Pierre Jolivet Richard Tran Mills Sajid Ali Satish Balay Scott Kruger Scott MacLachlan Shrirang Abhyankar Stefano Zampini Steve Benbow Toby Isaac Tyler Chen Vaclav Hapla Valeria Barra and bug reports/patches/proposed improvements received from "Abhyankar, Shrirang G" Arash Mehraban Barry Smith Benjamin Bugeat Brandon Denton Cameron Smith Carl Hall Claudio Tomasi "David, Cedric H (US 329F)" Dipankar Dwivedi Dmitry Melnichuk Ed Bueler Emmanuel Ayala Eric Chamberland Fande Kong Frederic Vi Gautam Bisht Guangming Wang Hong Zhang Ivan Blagopoluchnyy Jacob Faibussowitsch James Ramsey James Wright Jan Grieï¿œer Jaysaval, Piyoosh Jed Brown Jeremy Thompson Jin Chen jordic Jose E. Roman Junchao Zhang Justin Herter Kai Germaschewski Lisandro Dalcin Marius Buerkle Mark Adams Mark Lohry Martin Diehl Matthew Knepley "McInnes, Lois Curfman" Mehmet Sahin Miguel Fosas de Pando Miguel Salazar De Troya mphysx team "Nourgaliev, Robert Nr" "Ofori-Opoku, Nana" PAEZ ESPEJO Miguel-Angel EUROGICIEL INGENIERIE Patrick Zulian Paul T. Bauman Philippe Billuart Pierre Jolivet Ramin Moghadasi Randall Mackie Richard Tran Mills Sajid Ali Sam Guo Satish Balay Scott Kruger Sï¿œbastien Gilles Thibaut Appel Toby Isaac Tomas Mondragon Valeria Barra Victor Eijkhout Xiaodong Liu As always, thanks for your support, Satish, on behalf of PETSc team

1 0

Re: [petsc-dev] petsc release plan for march/2020
by Satish Balay 29 Mar '20

29 Mar '20

An update, I'm ready to spin petsc-3.13.0 tarball with current master [using commits in balay/release-3.13-revert-to-dev] Once the tarball is ready - master and maint branches will be updated. Satish On Fri, 13 Mar 2020, Satish Balay via petsc-dev wrote: > All, > > We are to make a petsc release by the end of March. > > For this release [3.13], will work with the following dates: > > - feature freeze: March 27 say 5PM EST > - release: March 29 > > Merges after freeze should contain only fixes that would normally be acceptable to maint workflow. > > I've changed the current milestone 'v3.13' to 'master' and created a new one 'v3.13-release' > > If you are working on a MR with the goal of merging before release - its best to use 'v3.13-release' tag with the MR. > > And it would be good to avoid merging large changes at the last minute. And not have merge requests stuck in need of reviews, testing and other necessary tasks. > > And I would think the testing/CI resources would get stressed in this timeframe - so it would be good to use them judiciously if possible. > > - if there are failures in stage-2 or 3 - and its no longer necessary to complete all the jobs - one can 'cancel' the pipeline. > - if a fix needs to be tested - one can first test with only the failed jobs (if this is known) - before doing a full test pipeline. i.e: > - start pipeline > - immediately cancel the pipeline > - now toggle only the jobs that need to be run > - [on success of the selected jobs] if one wants to run the full pipeleine - click 'retry' - and the remaining canceled jobs should now get scheduled. > > thanks, > Satish >

1 0

Re: [petsc-dev] Mat assembly on GPUs ...
by Mark Adams 29 Mar '20

29 Mar '20

On Sun, Mar 29, 2020 at 7:51 PM Jed Brown <jed(a)jedbrown.org> wrote: > Mark Adams <mfadams(a)lbl.gov> writes: > > > On Sun, Mar 29, 2020 at 6:20 PM Jed Brown <jed(a)jedbrown.org> wrote: > > > >> We are interested in assembling point-block diagonals for use in > >> pbjacobi smoothing. This is much simpler than AIJ, > > > > > > Would the coloring/DD algo on the outside be the same, just with a > > different assembly kernel? > > In one mode, though we can also do analytic stuff on the inside to avoid > coloring (in which case we produce a bunch of elements or block-diagonal > blocks). > > > Or are you looking a fusing the element construction with assembly? That > > seems reasonable now that I think about it. > > > > It's the same coloring, right? > > > > And, do we have an appropriate coloring method now? > > Are you asking for a GPU-native coloring? No. And I am using p4est grids. > Does your nonzero pattern > change frequently? >

1 0

Re: [petsc-dev] Mat assembly on GPUs ...
by Jed Brown 29 Mar '20

29 Mar '20

Mark Adams <mfadams(a)lbl.gov> writes: > On Sun, Mar 29, 2020 at 6:20 PM Jed Brown <jed(a)jedbrown.org> wrote: > >> We are interested in assembling point-block diagonals for use in >> pbjacobi smoothing. This is much simpler than AIJ, > > > Would the coloring/DD algo on the outside be the same, just with a > different assembly kernel? In one mode, though we can also do analytic stuff on the inside to avoid coloring (in which case we produce a bunch of elements or block-diagonal blocks). > Or are you looking a fusing the element construction with assembly? That > seems reasonable now that I think about it. > > It's the same coloring, right? > > And, do we have an appropriate coloring method now? Are you asking for a GPU-native coloring? Does your nonzero pattern change frequently?

1 0

Re: [petsc-dev] Mat assembly on GPUs ...
by Mark Adams 29 Mar '20

29 Mar '20

On Sun, Mar 29, 2020 at 6:20 PM Jed Brown <jed(a)jedbrown.org> wrote: > We are interested in assembling point-block diagonals for use in > pbjacobi smoothing. This is much simpler than AIJ, Would the coloring/DD algo on the outside be the same, just with a different assembly kernel? Or are you looking a fusing the element construction with assembly? That seems reasonable now that I think about it. It's the same coloring, right? And, do we have an appropriate coloring method now? Thanks, Mark > but lots of people > will need AIJ so it's certainly worthwhile. > > Mark Adams <mfadams(a)lbl.gov> writes: > > > Is there any plans/interest in assembling AIJ matrices on GPUs? > > > > I have a somewhat strangely balanced FE operator and I have each thread > > block create one element matrix, one thread per integration point with an > > expensive computation at each integration point. Then I assemble the > > matrices on the CPU. > > > > I want to parallelize assembly on GPU machines, with coloring or DD I > > assume. Does anyone else care about this? > > > > Thanks, > > Mark >

1 0

Re: [petsc-dev] Mat assembly on GPUs ...
by Jed Brown 29 Mar '20

29 Mar '20

We are interested in assembling point-block diagonals for use in pbjacobi smoothing. This is much simpler than AIJ, but lots of people will need AIJ so it's certainly worthwhile. Mark Adams <mfadams(a)lbl.gov> writes: > Is there any plans/interest in assembling AIJ matrices on GPUs? > > I have a somewhat strangely balanced FE operator and I have each thread > block create one element matrix, one thread per integration point with an > expensive computation at each integration point. Then I assemble the > matrices on the CPU. > > I want to parallelize assembly on GPU machines, with coloring or DD I > assume. Does anyone else care about this? > > Thanks, > Mark

1 0

Mat assembly on GPUs ...
by Mark Adams 29 Mar '20

29 Mar '20

Is there any plans/interest in assembling AIJ matrices on GPUs? I have a somewhat strangely balanced FE operator and I have each thread block create one element matrix, one thread per integration point with an expensive computation at each integration point. Then I assemble the matrices on the CPU. I want to parallelize assembly on GPU machines, with coloring or DD I assume. Does anyone else care about this? Thanks, Mark

1 0