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

Fwd: In March, you had 482 users visit your website (Google Analytics)
by Matthew Knepley 04 Apr '18

04 Apr '18

Good month. Matt ---------- Forwarded message ---------- From: Google Analytics <analytics-noreply(a)google.com> Date: Wed, Apr 4, 2018 at 5:21 AM Subject: In March, you had 482 users visit your website (Google Analytics) To: knepley(a)gmail.com Your Snapshot for March Want to get a monthly snapshot for more views? Edit your email preferences here <https://analytics.google.com/analytics/web/?utm_source=GA_Monthly_Snapshot&…>. [image: Google Analytics] Your Snapshot for March petsc.org UA-29486667-1 View: petsc.org 56661738 https://bitbucket.org March performance for your website <#m_210340058055480009_> vs. previous month *Users* 482 [image: Increase] 8.56% *Sessions* 1.6K [image: Increase] 32.29% *Bounce Rate* 44.13% [image: Increase] 7.54% *Average Session Duration* 00:04:45 [image: Increase] 56.8% How did you acquire your users this month? *Percent of Sessions by Channel* *Referral* 47.25% *Direct* 27.28% *All other sessions* 25.47% See my full report <https://analytics.google.com/analytics/web/?utm_source=GA_Monthly_Snapshot&…> Want to get a monthly snapshot for more views? Edit your email preferences here <https://analytics.google.com/analytics/web/?utm_source=GA_Monthly_Snapshot&…> . *Did you know…?* You can now ask questions on Analytics Intelligence, such as: "How many new visitors did I gain from organic search yesterday?" "How many weekly active users do we have on mobile?" "Compare bounce rate on mobile versus desktop." Try out Analytics Intelligence on mobile or desktop simply by clicking the [image: intelligence icon] icon. ASK A QUESTION <https://analytics.google.com/analytics/web/?openintelpanel=1&utm_source=GA_…> Download the Google Analytics Mobile App [image: Get it on Google Play] <https://www.google.com/appserve/mkt/p/AFIPhzWkSC9vSHjkRqTXsTlTCPt95mgmTtcFA…> [image: Download on the app store] <https://www.google.com/appserve/mkt/p/AFIPhzV5aDrtL-hU6rVdV6a1lA3uPry3Emr5e…> Values are captured at Pacific Time. Values are approximate, and only significant values may be shown. © 2018 Google LLC 1600 Amphitheatre Parkway, Mountain View, CA 94043 <https://maps.google.com/?q=1600+Amphitheatre+Parkway,+Mountain+View,+CA+940…> This email was sent to knepley(a)gmail.com because you indicated that you'd like to receive updates and tips about your Google Analytics account. If you don't want to receive such emails in the future, please unsubscribe here: https://www.google.com/appserve/mkt/optout/AFIPhzWtWfk_-2l5M- 5PCdRcTQeswQH0xLdsWw1CHk3xsJyXQDSIndwcr8f0L7d7qmUX?hl=en-US You can also change your preferences at your account's Google Analytics Email Communications page by logging into https://www.google.com/analytics/settings/my_account -- 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

Re: [petsc-dev] FAS indentation
by Dener, Alp 03 Apr '18

03 Apr '18

Hi Matt, Some notes about this issue: 1. Correction to my previous email: the XYZMonitor() routines were not touched/modified in this feature branch. I misspoke about that. We modified the XYZView() only, and indeed these are the ones that appear to have some different indentations in the output files. 2. I’m seeing incorrect tab levels in only two ex12 tests: ex12_tri_p1_adapt_0 and ex12_tri_p1_adapt_1. Turns out SNESReasonView() did not have the earlier tab level changes correctly propagated into it. I’ve attached a git format-patch that fixes this (I didn’t wanna push directly to next without approval). But the remaining tab level changes are consistent with the XYZView() changes we’ve made. So I would recommend updating the output files after applying the patch (again, I didn’t want to touch the outputs without your approval first). 3. Your first email on this mentioned FAS solver errors, but all the ex12_fas_% tests are passing for me locally. Can you confirm that these are working for you as well? If not, which test machine should I run this on to reproduce your errors? 4. I’ve got some number of the ex12 tests crashing on my machine. ex12_restart-b reports HDF5 errors, while ex12_mg_newton_coarse_0, ex12_mg_newton_coarse_1 and ex12_mg_newton_coarse_2 report “inconsistent data” with regards to dof mapping. These just might have to do with my local configuration but I still wanted to put it on your radar just in case. Thanks, — Alp Dener On April 3, 2018 at 6:24:42 PM, Matthew Knepley (knepley(a)gmail.com<mailto:[email protected]>) wrote: On Tue, Apr 3, 2018 at 7:16 PM, Dener, Alp <adener(a)anl.gov<mailto:[email protected]>> wrote: Sure thing! Matt, just to give you a bit of detail, the Monitor() calls to ASCII viewers were changed to respect the tab levels for the parent objects instead of manually pushing and popping tabs on the printouts. The code also tries to preserve the existing tab levels of the viewer though — that is, we first save the existing tab level, then indent monitor printouts from the root (0 tab) using the object’s tab level, and then set the viewer back to whatever tab level it was at before the monitor is called. So in theory, it shouldn’t be changing the behavior of the viewer outside of the monitor. It is entirely possible I introduced a bug somewhere and that’s what I’m going to look for right now, but in the meantime please let me know if there’s a use-case or a test I can use for debugging as well. The easiest thing to do is run all the SNES ex12 tests in next and look at the indentation errors. I am now pushing fixes for all other errors, so by the time you run there should be nothing else. Thanks, Matt Thanks, — Alp Dener On April 3, 2018 at 6:11:12 PM, Smith, Barry F. (bsmith(a)mcs.anl.gov<mailto:[email protected]>) wrote: Alp, Can you please take a look at this? Thanks Barry > On Apr 3, 2018, at 4:46 PM, Matthew Knepley <knepley(a)gmail.com<mailto:[email protected]>> wrote: > > The recent indentation fix (I think) has broken the FAS solver indentation. > > 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 > > https://www.cse.buffalo.edu/~knepley/ -- 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

Re: [petsc-dev] FAS indentation
by Dener, Alp 03 Apr '18

03 Apr '18

Sounds good. I already found one case of mishandled tabs just looking at the SNES default monitor, and I’ll make sure the rest don’t have the same bug. — Alp Dener On April 3, 2018 at 6:24:42 PM, Matthew Knepley (knepley(a)gmail.com<mailto:[email protected]>) wrote: On Tue, Apr 3, 2018 at 7:16 PM, Dener, Alp <adener(a)anl.gov<mailto:[email protected]>> wrote: Sure thing! Matt, just to give you a bit of detail, the Monitor() calls to ASCII viewers were changed to respect the tab levels for the parent objects instead of manually pushing and popping tabs on the printouts. The code also tries to preserve the existing tab levels of the viewer though — that is, we first save the existing tab level, then indent monitor printouts from the root (0 tab) using the object’s tab level, and then set the viewer back to whatever tab level it was at before the monitor is called. So in theory, it shouldn’t be changing the behavior of the viewer outside of the monitor. It is entirely possible I introduced a bug somewhere and that’s what I’m going to look for right now, but in the meantime please let me know if there’s a use-case or a test I can use for debugging as well. The easiest thing to do is run all the SNES ex12 tests in next and look at the indentation errors. I am now pushing fixes for all other errors, so by the time you run there should be nothing else. Thanks, Matt Thanks, — Alp Dener On April 3, 2018 at 6:11:12 PM, Smith, Barry F. (bsmith(a)mcs.anl.gov<mailto:[email protected]>) wrote: Alp, Can you please take a look at this? Thanks Barry > On Apr 3, 2018, at 4:46 PM, Matthew Knepley <knepley(a)gmail.com<mailto:[email protected]>> wrote: > > The recent indentation fix (I think) has broken the FAS solver indentation. > > 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 > > https://www.cse.buffalo.edu/~knepley/ -- 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

Re: [petsc-dev] FAS indentation
by Matthew Knepley 03 Apr '18

03 Apr '18

On Tue, Apr 3, 2018 at 7:16 PM, Dener, Alp <adener(a)anl.gov> wrote: > Sure thing! > > Matt, just to give you a bit of detail, the Monitor() calls to ASCII > viewers were changed to respect the tab levels for the parent objects > instead of manually pushing and popping tabs on the printouts. The code > also tries to preserve the existing tab levels of the viewer though — that > is, we first save the existing tab level, then indent monitor printouts > from the root (0 tab) using the object’s tab level, and then set the viewer > back to whatever tab level it was at before the monitor is called. So in > theory, it shouldn’t be changing the behavior of the viewer outside of the > monitor. It is entirely possible I introduced a bug somewhere and that’s > what I’m going to look for right now, but in the meantime please let me > know if there’s a use-case or a test I can use for debugging as well. > The easiest thing to do is run all the SNES ex12 tests in next and look at the indentation errors. I am now pushing fixes for all other errors, so by the time you run there should be nothing else. Thanks, Matt > Thanks, > — > Alp Dener > > On April 3, 2018 at 6:11:12 PM, Smith, Barry F. (bsmith(a)mcs.anl.gov) > wrote: > > > Alp, > > Can you please take a look at this? > > Thanks > > Barry > > > > On Apr 3, 2018, at 4:46 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > > > The recent indentation fix (I think) has broken the FAS solver > indentation. > > > > 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 > > > > https://www.cse.buffalo.edu/~knepley/ > > -- 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

Re: [petsc-dev] FAS indentation
by Dener, Alp 03 Apr '18

03 Apr '18

Sure thing! Matt, just to give you a bit of detail, the Monitor() calls to ASCII viewers were changed to respect the tab levels for the parent objects instead of manually pushing and popping tabs on the printouts. The code also tries to preserve the existing tab levels of the viewer though — that is, we first save the existing tab level, then indent monitor printouts from the root (0 tab) using the object’s tab level, and then set the viewer back to whatever tab level it was at before the monitor is called. So in theory, it shouldn’t be changing the behavior of the viewer outside of the monitor. It is entirely possible I introduced a bug somewhere and that’s what I’m going to look for right now, but in the meantime please let me know if there’s a use-case or a test I can use for debugging as well. Thanks, — Alp Dener On April 3, 2018 at 6:11:12 PM, Smith, Barry F. (bsmith(a)mcs.anl.gov<mailto:[email protected]>) wrote: Alp, Can you please take a look at this? Thanks Barry > On Apr 3, 2018, at 4:46 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > The recent indentation fix (I think) has broken the FAS solver indentation. > > 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 > > https://www.cse.buffalo.edu/~knepley/

1 0

Re: [petsc-dev] FAS indentation
by Smith, Barry F. 03 Apr '18

03 Apr '18

Alp, Can you please take a look at this? Thanks Barry > On Apr 3, 2018, at 4:46 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > The recent indentation fix (I think) has broken the FAS solver indentation. > > 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 > > https://www.cse.buffalo.edu/~knepley/

1 0

FAS indentation
by Matthew Knepley 03 Apr '18

03 Apr '18

The recent indentation fix (I think) has broken the FAS solver indentation. 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 https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>

1 0

Re: [petsc-dev] [issue1595] Issues of limited number of MPI communicators when having many instances of hypre boomerAMG with Moose
by Derek Gaston 03 Apr '18

03 Apr '18

Firstly, thank you, everyone, for taking time to talk about this issue! We definitely appreciate it. Jed has this right - we would ideally not want to setup and teardown the preconditioner for each solve every iteration. For VERY large solves (10k+ simultaneous solves) using this method we have no choice - and have done exactly what has been suggested: setup-solve-teardown for each one in serial. But that's an extreme case where we can't fit all of the matrices in memory at the same time. For the "normal" runs (10-1000 solves) that's not the case. Derek On Tue, Apr 3, 2018 at 4:37 PM Jed Brown <jed(a)jedbrown.org> wrote: > This is likely in the context of a preconditioner for a composite solve, > so the many BoomerAMG solvers will persist. They all get set up and > then applied in sequence to the many scalar systems at each iteration of > an outer method. > > If hypre doesn't want to dup its communicators internally, then PETSc > will dup a communicator for hypre, attach it to the outer communicator, > and look for it each time a new hypre object is created. It's easy for > PETSc (we've done this for PETSc since the early days), but a headache > for other libraries. > > "Li, Ruipeng" <li50(a)llnl.gov> writes: > > > Hi, Fande, > > > > "For instance, if an application has multiple fields and each field will > be solved by a HYPRE solver, then we end up with multiple hypre solves. > The multiple hypre solves are not run simultaneously, instead, it will be > run one-by-one. If we assign the same communicator to the multiple hypre > solves, any potential tag conflict?" > > > > In this scenario, is just the solve phase of BoomerAMG one after > another, or also the setup of AMG? Since BoomerAMG takes the communicator > from the A matrix, if the entire hypre solve (setup + solve) is serial, > there should be no conflicts. > > > > -Ruipeng > > > > . -- .- .. .-.. / ..-. .-. --- -- / .-. ..- .. .--. . -. --. / .-.. .. > > Ruipeng Li > > Center for Applied Scientific Computing > > Lawrence Livermore National Laboratory > > P.O. Box 808, L-561 > > Livermore, CA 94551 > > phone - (925) 422-6037, email - li50(a)llnl.gov > > > > > > ________________________________________ > > From: Kong, Fande <fande.kong(a)inl.gov> > > Sent: Tuesday, April 3, 2018 1:34 PM > > To: hypre-support > > Cc: Barry Smith; Derek Gaston; Li, Ruipeng; Osei-Kuffuor, Daniel; For > users of the development version of PETSc; Schroder, Jacob B.; > tzanio(a)llnl.gov; umyang(a)llnl.gov; Wang, Lu > > Subject: Re: [issue1595] Issues of limited number of MPI communicators > when having many instances of hypre boomerAMG with Moose > > > > > > > > On Tue, Apr 3, 2018 at 2:12 PM, Rob Falgout hypre Tracker < > hypre-support(a)llnl.gov<mailto:[email protected]>> wrote: > > > > Rob Falgout <rfalgout(a)llnl.gov<mailto:[email protected]>> added the > comment: > > > > Hi Barry, > > > > Can you explain the scenario where multiple hypre solves would be > working in parallel with the same communicator? Thanks! > > > > Hi Rob, > > > > For instance, if an application has multiple fields and each field will > be solved by a HYPRE solver, then we end up with multiple hypre solves. > The multiple hypre solves are not run simultaneously, instead, it will be > run one-by-one. If we assign the same communicator to the multiple hypre > solves, any potential tag conflict? > > > > Fande, > > > > > > > > -Rob > > > > ____________________________________________ > > hypre Issue Tracker <hypre-support(a)llnl.gov<mailto: > hypre-support(a)llnl.gov>> > > < > https://urldefense.proofpoint.com/v2/url?u=http-3A__cascb1.llnl.gov_hypre_i… > > > > ____________________________________________ >

1 0

[issue1595] Issues of limited number of MPI communicators when having many instances of hypre boomerAMG with Moose
by Rob Falgout hypre Tracker 03 Apr '18

03 Apr '18

Rob Falgout <rfalgout(a)llnl.gov> added the comment: Is somebody actually having a problem with communicator conflicts right now? I thought the reason for this thread was to reduce the number of communicators because of limits in MPI implementations. Somebody has to reduce the Comm_create() and Comm_dup() calls. We responded with one way to reduce the create() calls in BoomerAMG, but now you are asking us to put them back in by calling dup()? I'm confused about what we are trying to achieve here now. The reason I suggested that the user be responsible for calling dup() is twofold: 1) I don't think it is common for users to run hypre in parallel with other user code where both are using the same communicator (I'm not sure how this could even work without deadlocking since hypre calls are collective); 2) Making libraries lower down on the call stack be responsible for calling dup() seems less scalable than the other way around and more likely to increase the number of communicators used. Anyway, I'm still confused about what we are trying to achieve so maybe somebody can try to summarize again? -Rob ____________________________________________ hypre Issue Tracker <hypre-support(a)llnl.gov> <http://cascb1.llnl.gov/hypre/issue1595> ____________________________________________

1 0

Re: [petsc-dev] [issue1595] Issues of limited number of MPI communicators when having many instances of hypre boomerAMG with Moose
by Jed Brown 03 Apr '18

03 Apr '18

This is likely in the context of a preconditioner for a composite solve, so the many BoomerAMG solvers will persist. They all get set up and then applied in sequence to the many scalar systems at each iteration of an outer method. If hypre doesn't want to dup its communicators internally, then PETSc will dup a communicator for hypre, attach it to the outer communicator, and look for it each time a new hypre object is created. It's easy for PETSc (we've done this for PETSc since the early days), but a headache for other libraries. "Li, Ruipeng" <li50(a)llnl.gov> writes: > Hi, Fande, > > "For instance, if an application has multiple fields and each field will be solved by a HYPRE solver, then we end up with multiple hypre solves. The multiple hypre solves are not run simultaneously, instead, it will be run one-by-one. If we assign the same communicator to the multiple hypre solves, any potential tag conflict?" > > In this scenario, is just the solve phase of BoomerAMG one after another, or also the setup of AMG? Since BoomerAMG takes the communicator from the A matrix, if the entire hypre solve (setup + solve) is serial, there should be no conflicts. > > -Ruipeng > > . -- .- .. .-.. / ..-. .-. --- -- / .-. ..- .. .--. . -. --. / .-.. .. > Ruipeng Li > Center for Applied Scientific Computing > Lawrence Livermore National Laboratory > P.O. Box 808, L-561 > Livermore, CA 94551 > phone - (925) 422-6037, email - li50(a)llnl.gov > > > ________________________________________ > From: Kong, Fande <fande.kong(a)inl.gov> > Sent: Tuesday, April 3, 2018 1:34 PM > To: hypre-support > Cc: Barry Smith; Derek Gaston; Li, Ruipeng; Osei-Kuffuor, Daniel; For users of the development version of PETSc; Schroder, Jacob B.; tzanio(a)llnl.gov; umyang(a)llnl.gov; Wang, Lu > Subject: Re: [issue1595] Issues of limited number of MPI communicators when having many instances of hypre boomerAMG with Moose > > > > On Tue, Apr 3, 2018 at 2:12 PM, Rob Falgout hypre Tracker <hypre-support(a)llnl.gov<mailto:[email protected]>> wrote: > > Rob Falgout <rfalgout(a)llnl.gov<mailto:[email protected]>> added the comment: > > Hi Barry, > > Can you explain the scenario where multiple hypre solves would be working in parallel with the same communicator? Thanks! > > Hi Rob, > > For instance, if an application has multiple fields and each field will be solved by a HYPRE solver, then we end up with multiple hypre solves. The multiple hypre solves are not run simultaneously, instead, it will be run one-by-one. If we assign the same communicator to the multiple hypre solves, any potential tag conflict? > > Fande, > > > > -Rob > > ____________________________________________ > hypre Issue Tracker <hypre-support(a)llnl.gov<mailto:[email protected]>> > <https://urldefense.proofpoint.com/v2/url?u=http-3A__cascb1.llnl.gov_hypre_i…> > ____________________________________________

1 0