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

Re: [petsc-dev] [Projects] CFP - 2025 Round 2 Small Development Grants CFP is open
by Jed Brown 21 Sep '25

21 Sep '25

Barry Smith <bsmith(a)petsc.dev> writes: > The most effective tools for "writing documentation, new tutorials, and refining material for hands-on in-person or virtual tutorials" revolve around LLMs. I disagree strongly with this depiction. It creates text that resembles documentation in form, but lacks communicative intent, and is often misleading or erroneous. If you're trying to trick a program manager into saying the task is complete, and you're confident you won't be held accountable if they correctly identify it as slop, this is your tool. Similarly if you're trying to make a sale to someone reviewing your website, but who doesn't yet know what problem they're solving and doesn't yet have well-formed questions. These uses are rooted in deception, and they sacrifice community trust for short-term claims of productivity. While it is true in principle that the output can be edited to be correct, holistic assessments show negligible or negative impact if one is accountable for maintaining quality standards. When software developers, reporters, or lawyers make proud assertions of how much more productive they are, it's very often followed by catastrophic failures (private keys in the repository, no encryption in the encrypt() function, deleted the customer database, books being reviewed do not exist, false quotes attributed to real people, fake court cases and mis-citation of real court cases in legal briefs even after being reviewed by four lawyers). Not to mention the products have immense negative externalities. I started using PETSc over 20 years ago because it was clear that PETSc was NOT merely going through the motions, but genuinely cared about solving real problems for real people. It always had rough edges, but the care was evident. > Ignoring those tools, simply because they have lots of bullshit hypre associated with them, will slow down our ability to improve the documentation, tutorials, and related materials. This inevitability narrative doesn't stand up to critical scrutiny, nor does the assumption that this speeds us up (if our goal is to foster a healthy community that provides trustworthy software and documentation to assist real people in solving real problems). I'm a co-author of this position paper examining this topic in the context of education. I'll refrain from flooding this thread with citations, but the paper discusses inevitability narratives and has extensive citations. https://urldefense.us/v3/__https://doi.org/10.5281/zenodo.17065099__;!!G_uC…

1 0

Re: [petsc-dev] [Projects] CFP - 2025 Round 2 Small Development Grants CFP is open
by Barry Smith 21 Sep '25

21 Sep '25

If "DOE has already shifted a large share of funds away from epistemically-sound basic research over to risky bets on LLMs." that funding is not available to PETSc developers. This makes it difficult for PETSc developers to compete for future DOE funding related to LLMs, as we cannot demonstrate much prior work due to the lack of funding from DOE to work with LLMs. The most effective tools for "writing documentation, new tutorials, and refining material for hands-on in-person or virtual tutorials" revolve around LLMs. Ignoring those tools, simply because they have lots of bullshit hypre associated with them, will slow down our ability to improve the documentation, tutorials, and related materials. > On Sep 21, 2025, at 8:36 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > I think we should apply for a topic that is *NOT* LLMs [1]. It could sponsor a stipend for a grad student to write documentation, to write new tutorials (maybe poll for which topics are in high demand), or to refine material for hands-on in-person or virtual tutorials. > > > [1]: DOE has already shifted a large share of funds away from epistemically-sound basic research over to risky bets on LLMs. If PETSc were to apply for that one thing, it would send a message that we don't think DOE has gone far enough. I think that's 100% backwards. > > Barry Smith <bsmith(a)petsc.dev <mailto:[email protected]>> writes: > >> We are eligible to apply for small grants for PETSc development under this program. Only one application is allowed per project. It can pay for access to resources (e.g. LLMs) or people's time with a 1099, so long as they are not already funded for similar work. >> >> Ideas? I am thinking of one focused on PETSc LLM agents for coding etc. >> >> Barry >> >> >>> Begin forwarded message: >>> >>> From: Arliss Collins <help(a)numfocus.org> >>> Subject: [Projects] CFP - 2025 Round 2 Small Development Grants CFP is open >>> Date: September 19, 2025 at 3:47:59 PM EDT >>> To: bsmith(a)petsc.dev >>> Reply-To: help(a)numfocus.org >>> Message-Id: <1758311278965.4a3368eb-b19f-40a1-a3ed-9043ac8a75a0(a)bf08x.hubspotemail.net> >>> >>> >>> Hello, Projects! >>> >>> NumFOCUS is pleased to invite proposals for our 2nd round of Small Development Grants for 2025! >>> >>> Reminder: Projects can submit a new proposal or re-submit a past proposal. >>> Apply Here: <https://urldefense.us/v3/__https://d4jbd104.na1.hubspotlinks.com/Ctc/OT*113… >small-development-grant-proposals <https://urldefense.us/v3/__https://d4jbd104.na1.hubspotlinks.com/Ctc/OT*113… > >>> >>> Timeline: >>> Deadline for Proposal Submission: October 17, 2025 >>> Projects will be Notified: November 21, 2025 (or sooner) >>> Available Funding: >>> Maximum $72,000 for allocation in Round 2. >>> Up to $10,000 maximum per project for 2025. >>> Eligibility: >>> Any NumFOCUS Fiscally Sponsored or Affiliated project may submit 1proposal on behalf of the project per grant cycle. >>> If you wish to solicit proposal ideas from your project community, the project leaders must organize their own review process to select the proposal that the leadership will put forward to NumFOCUS. >>> Proposed work must be achievable within the 12 months following the award. >>> The call is open to applicants from any nationality and can be performed at any university, institute, or business worldwide (US export laws permitting). >>> Funding Distribution: >>> For fiscally sponsored projects only, NumFOCUS can award the fund to the project in our accounting platform. The project would then submit invoices through the normal channels to pay the grant expenses. >>> NumFOCUS can set up an independent contractor agreement, a must for contractor time over $600 USD, with an individual or company. >>> You can see past successful proposals here: https://urldefense.us/v3/__https://numfocus.org/programs/small-development-… <https://urldefense.us/v3/__https://d4jbd104.na1.hubspotlinks.com/Ctc/OT*113… > >>> >>> Please feel free to reach out <mailto:[email protected]> if you have any questions. >>> >>> NumFOCUS, P.O. Box 90596, Austin, Texas 78709 >>> Unsubscribe <https://urldefense.us/v3/__https://hs-39929437.s.hubspotemail.net/hs/prefer… > Manage preferences <https://urldefense.us/v3/__https://hs-39929437.s.hubspotemail.net/hs/prefer… >

1 0

Re: [petsc-dev] Fwd: [Projects] CFP - 2025 Round 2 Small Development Grants CFP is open
by Jed Brown 21 Sep '25

21 Sep '25

I think we should apply for a topic that is *NOT* LLMs [1]. It could sponsor a stipend for a grad student to write documentation, to write new tutorials (maybe poll for which topics are in high demand), or to refine material for hands-on in-person or virtual tutorials. [1]: DOE has already shifted a large share of funds away from epistemically-sound basic research over to risky bets on LLMs. If PETSc were to apply for that one thing, it would send a message that we don't think DOE has gone far enough. I think that's 100% backwards. Barry Smith <bsmith(a)petsc.dev> writes: > We are eligible to apply for small grants for PETSc development under this program. Only one application is allowed per project. It can pay for access to resources (e.g. LLMs) or people's time with a 1099, so long as they are not already funded for similar work. > > Ideas? I am thinking of one focused on PETSc LLM agents for coding etc. > > Barry > > >> Begin forwarded message: >> >> From: Arliss Collins <help(a)numfocus.org> >> Subject: [Projects] CFP - 2025 Round 2 Small Development Grants CFP is open >> Date: September 19, 2025 at 3:47:59 PM EDT >> To: bsmith(a)petsc.dev >> Reply-To: help(a)numfocus.org >> Message-Id: <1758311278965.4a3368eb-b19f-40a1-a3ed-9043ac8a75a0(a)bf08x.hubspotemail.net> >> >> >> Hello, Projects! >> >> NumFOCUS is pleased to invite proposals for our 2nd round of Small Development Grants for 2025! >> >> Reminder: Projects can submit a new proposal or re-submit a past proposal. >> Apply Here: <https://urldefense.us/v3/__https://d4jbd104.na1.hubspotlinks.com/Ctc/OT*113… >small-development-grant-proposals <https://urldefense.us/v3/__https://d4jbd104.na1.hubspotlinks.com/Ctc/OT*113… > >> >> Timeline: >> Deadline for Proposal Submission: October 17, 2025 >> Projects will be Notified: November 21, 2025 (or sooner) >> Available Funding: >> Maximum $72,000 for allocation in Round 2. >> Up to $10,000 maximum per project for 2025. >> Eligibility: >> Any NumFOCUS Fiscally Sponsored or Affiliated project may submit 1proposal on behalf of the project per grant cycle. >> If you wish to solicit proposal ideas from your project community, the project leaders must organize their own review process to select the proposal that the leadership will put forward to NumFOCUS. >> Proposed work must be achievable within the 12 months following the award. >> The call is open to applicants from any nationality and can be performed at any university, institute, or business worldwide (US export laws permitting). >> Funding Distribution: >> For fiscally sponsored projects only, NumFOCUS can award the fund to the project in our accounting platform. The project would then submit invoices through the normal channels to pay the grant expenses. >> NumFOCUS can set up an independent contractor agreement, a must for contractor time over $600 USD, with an individual or company. >> You can see past successful proposals here: https://urldefense.us/v3/__https://numfocus.org/programs/small-development-… <https://urldefense.us/v3/__https://d4jbd104.na1.hubspotlinks.com/Ctc/OT*113… > >> >> Please feel free to reach out <mailto:[email protected]> if you have any questions. >> >> NumFOCUS, P.O. Box 90596, Austin, Texas 78709 >> Unsubscribe <https://urldefense.us/v3/__https://hs-39929437.s.hubspotemail.net/hs/prefer… > Manage preferences <https://urldefense.us/v3/__https://hs-39929437.s.hubspotemail.net/hs/prefer… >

1 0

Fwd: [Projects] CFP - 2025 Round 2 Small Development Grants CFP is open
by Barry Smith 21 Sep '25

21 Sep '25

We are eligible to apply for small grants for PETSc development under this program. Only one application is allowed per project. It can pay for access to resources (e.g. LLMs) or people's time with a 1099, so long as they are not already funded for similar work. Ideas? I am thinking of one focused on PETSc LLM agents for coding etc. Barry > Begin forwarded message: > > From: Arliss Collins <help(a)numfocus.org> > Subject: [Projects] CFP - 2025 Round 2 Small Development Grants CFP is open > Date: September 19, 2025 at 3:47:59 PM EDT > To: bsmith(a)petsc.dev > Reply-To: help(a)numfocus.org > Message-Id: <1758311278965.4a3368eb-b19f-40a1-a3ed-9043ac8a75a0(a)bf08x.hubspotemail.net> > > > Hello, Projects! > > NumFOCUS is pleased to invite proposals for our 2nd round of Small Development Grants for 2025! > > Reminder: Projects can submit a new proposal or re-submit a past proposal. > Apply Here: <https://urldefense.us/v3/__https://d4jbd104.na1.hubspotlinks.com/Ctc/OT*113… >small-development-grant-proposals <https://urldefense.us/v3/__https://d4jbd104.na1.hubspotlinks.com/Ctc/OT*113… > > > Timeline: > Deadline for Proposal Submission: October 17, 2025 > Projects will be Notified: November 21, 2025 (or sooner) > Available Funding: > Maximum $72,000 for allocation in Round 2. > Up to $10,000 maximum per project for 2025. > Eligibility: > Any NumFOCUS Fiscally Sponsored or Affiliated project may submit 1proposal on behalf of the project per grant cycle. > If you wish to solicit proposal ideas from your project community, the project leaders must organize their own review process to select the proposal that the leadership will put forward to NumFOCUS. > Proposed work must be achievable within the 12 months following the award. > The call is open to applicants from any nationality and can be performed at any university, institute, or business worldwide (US export laws permitting). > Funding Distribution: > For fiscally sponsored projects only, NumFOCUS can award the fund to the project in our accounting platform. The project would then submit invoices through the normal channels to pay the grant expenses. > NumFOCUS can set up an independent contractor agreement, a must for contractor time over $600 USD, with an individual or company. > You can see past successful proposals here: https://urldefense.us/v3/__https://numfocus.org/programs/small-development-… <https://urldefense.us/v3/__https://d4jbd104.na1.hubspotlinks.com/Ctc/OT*113… > > > Please feel free to reach out <mailto:[email protected]> if you have any questions. > > NumFOCUS, P.O. Box 90596, Austin, Texas 78709 > Unsubscribe <https://urldefense.us/v3/__https://hs-39929437.s.hubspotemail.net/hs/prefer… > Manage preferences <https://urldefense.us/v3/__https://hs-39929437.s.hubspotemail.net/hs/prefer… >

1 0

PETSc's grandchildren are now winning R and D 100 awards
by Barry Smith 16 Sep '25

16 Sep '25

PETSc's grandchildren are now winning R and D 100 awards Griffin: A Reactor Physics Tool for Multiphysics Modeling and Simulation of Advanced Nuclear Reactors, which is built on MOOSE, which is built on PETSc has won an R and D 100 award. https://urldefense.us/v3/__https://www.rdworldonline.com/revealing-the-2025… Announcing the 2025 R&D 100 Awards Winners rdworldonline.com

1 0

Re: [petsc-dev] ResQPASS in Petsc
by Jed Brown 10 Sep '25

10 Sep '25

Matthew Knepley <knepley(a)gmail.com> writes: >> We are developing novel subspace methods to deal with inequality bounds on >> the variables. >> ResQPASS, short for Residual Quadratic programming active set Subspace >> method, behaves asymptotically as a Krylov subspace. The paper is >> published in SISC and is available in https://urldefense.us/v3/__https://arxiv.org/abs/2302.13616__;!!G_uCfscf7eW… >> <https://urldefense.us/v3/__https://arxiv.org/abs/2302.13616__;!!G_uCfscf7eW…> >> . >> >> In the past we contributed several pipelined methods in KSP. But the >> current methods might also be of value for large scale optimization >> problems. We believe that the method will be very useful for contact >> problems and variational inequalities that model interacting mechanical >> systems. >> >> Who should I contact to discuss the best strategy to add the solver? >> > > That sounds great! I am currently working on variational inequalities for > frictional contact (for earthquake systems). I would be happy to help you > integrate these solvers. We are excited to test different formulations (the > LVPP people are also talking to us). Let me know how I can help. I agree this is useful. You can create an issue in the repository or make a new topic on the PETSc discord. https://urldefense.us/v3/__https://gitlab.com/petsc/petsc/-/issues/new__;!!…

1 0

Re: [petsc-dev] ResQPASS in Petsc
by Matthew Knepley 10 Sep '25

10 Sep '25

On Wed, Sep 10, 2025 at 11:42 AM Wim Vanroose <wim(a)vanroo.se> wrote: > Dear, > > We are developing novel subspace methods to deal with inequality bounds on > the variables. > ResQPASS, short for Residual Quadratic programming active set Subspace > method, behaves asymptotically as a Krylov subspace. The paper is > published in SISC and is available in https://urldefense.us/v3/__https://arxiv.org/abs/2302.13616__;!!G_uCfscf7eW… > <https://urldefense.us/v3/__https://arxiv.org/abs/2302.13616__;!!G_uCfscf7eW…> > . > > In the past we contributed several pipelined methods in KSP. But the > current methods might also be of value for large scale optimization > problems. We believe that the method will be very useful for contact > problems and variational inequalities that model interacting mechanical > systems. > > Who should I contact to discuss the best strategy to add the solver? > That sounds great! I am currently working on variational inequalities for frictional contact (for earthquake systems). I would be happy to help you integrate these solvers. We are excited to test different formulations (the LVPP people are also talking to us). Let me know how I can help. Thanks, Matt > Wim Vanroose > -- 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uC… <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCf… >

1 0

ResQPASS in Petsc
by Wim Vanroose 10 Sep '25

10 Sep '25

Dear, We are developing novel subspace methods to deal with inequality bounds on the variables. ResQPASS, short for Residual Quadratic programming active set Subspace method, behaves asymptotically as a Krylov subspace. The paper is published in SISC and is available in https://urldefense.us/v3/__https://arxiv.org/abs/2302.13616__;!!G_uCfscf7eW… . In the past we contributed several pipelined methods in KSP. But the current methods might also be of value for large scale optimization problems. We believe that the method will be very useful for contact problems and variational inequalities that model interacting mechanical systems. Who should I contact to discuss the best strategy to add the solver? Wim Vanroose

1 0

Re: [petsc-dev] Expectations for lock usage in PETSc
by Barry Smith 08 Sep '25

08 Sep '25

Paul, See also https://urldefense.us/v3/__https://gitlab.com/petsc/petsc/-/issues/1809__;!… We wanted to have systematic use of read and write locks of Vec memory in PETSc to prevent programmer error of reading from or writing to Vec memory that someone else (not another thread, just another chunk of code) was supposed to have control over; so Rust-like. We found that just pushing locks on VecGetArrayXXX() and popping them on VecRestoreArrayXXX() opened a can of worms, and we decided it wasn't doable. This was unfortunate since a big advantage of having the locks in VecGetYYY() would be that, since we use the get/restore routines throughout PETSc, we would immediately have a lot of new Rust-like memory safety without needing to add extra lines of code to our code base manually. We instead adopted the VecLockReadPush/Pop(), VecLockWriteSet(), and VecSetErrorIfLocked(). To be useful, this requires manually adding these function calls at appropriate places throughout the code base. A bunch of VecLockReadPush/Pop() were added (frankly, because as Jed notes, they can be nested, so it is easy to know where one can safely put them). However, only one VecLockWriteSet() was ever added to the source code, as it is delicate exactly where it can be placed. It would be very cool if your code analysis tools could help us know where we are missing potential VecLockReadPush/Pop() and VecLockWriteSet() calls—allowing us to improve our simple PETSc/C Rust-like memory ownership model. Barry Here is an example of how VecLockReadPush/Pop() helps us find user errors. SNESComputeFunction() calls a user-provided function (callback) that they wish to find a zero of. It is obvious to us (but not to all users) that they should not change the values in the input vector, and some people did, resulting in buggy, confusing results. SNESComputeFunction() is a bit messy but here are the guts PetscCall(VecLockReadPush(x)); /* ensure domainerror is false prior to computefunction evaluation (may not have been reset) */ snes->domainerror = PETSC_FALSE; { void *ctx; SNESFunctionFn *computefunction; PetscCall(DMSNESGetFunction(dm, &computefunction, &ctx)); PetscCallBack("SNES callback function", (*computefunction)(snes, x, y, ctx)); } PetscCall(VecLockReadPop(x)); Now, if the user calls VecGetArray() or VecGetArrayWrite() on the input x or tries to change its values in other ways, the code immediately stops with a very helpful error message. > On Sep 8, 2025, at 7:18 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > Read locks can nest, but writable locks cannot. > > The code here could have called VecLockWriteSet(y, PETSC_TRUE) and then released it. Arguably that would be more correct, though it does require a matching line of code and the writable access does not outlive the function. It also would the x == y logic to be reworked because the simpler functions can't be called when a write lock is held. > > IMO, it would be great if the compiler could enforce that arguments are not aliased, but C doesn't provide a way to do that and forbidding it would have ripple effects. > > Satish Balay <balay.anl(a)fastmail.org> writes: > >> I see the initial change was at: >> >> https://urldefense.us/v3/__https://gitlab.com/petsc/petsc/-/commit/d9ca1df4… >> >> And then refined at: >> >> https://urldefense.us/v3/__https://gitlab.com/petsc/petsc/-/commit/8860a134… >> >> Satish >> >> On Mon, 8 Sep 2025, Hovland, Paul via petsc-dev wrote: >> >>> Dear PETSc developers: >>> >>> We have a question about the (expected) use of read and write locks in the PETSc implementation of vectors. If one looks at the implementation of VecAXPY in rvector.c (or, really, the implementation of VecAXPYAsync_Private, which is called by VexAXPY), it first calls >>> PetscCall(VecSetErrorIfLocked(y, 1)); >>> then calls >>> PetscCall(VecLockReadPush(x)); >>> then dispatches the AXPY method, followed by >>> PetscCall(VecLockReadPop(x)); >>> >>> We’re curious why it just checks whether y is locked but goes through the whole locking and unlocking process for x. It seems like one should either also lock y or one could simply check whether there is a write lock on x, without having to go through the whole push/pop sequence. >>> >>> Is it written this way because the easiest way to check whether x has a write lock on it (and throw an error if it does) is to call VecLockReadPush? Is this pattern a relic of when PETSc implemented locks differently? Is there some other reason for the “inconsistent” (to our minds) handling of x and y? >>> >>> Thanks, >>> >>> Paul & Steve >>>

1 0

Re: [petsc-dev] Expectations for lock usage in PETSc
by Jed Brown 08 Sep '25

08 Sep '25

Read locks can nest, but writable locks cannot. The code here could have called VecLockWriteSet(y, PETSC_TRUE) and then released it. Arguably that would be more correct, though it does require a matching line of code and the writable access does not outlive the function. It also would the x == y logic to be reworked because the simpler functions can't be called when a write lock is held. IMO, it would be great if the compiler could enforce that arguments are not aliased, but C doesn't provide a way to do that and forbidding it would have ripple effects. Satish Balay <balay.anl(a)fastmail.org> writes: > I see the initial change was at: > > https://urldefense.us/v3/__https://gitlab.com/petsc/petsc/-/commit/d9ca1df4… > > And then refined at: > > https://urldefense.us/v3/__https://gitlab.com/petsc/petsc/-/commit/8860a134… > > Satish > > On Mon, 8 Sep 2025, Hovland, Paul via petsc-dev wrote: > >> Dear PETSc developers: >> >> We have a question about the (expected) use of read and write locks in the PETSc implementation of vectors. If one looks at the implementation of VecAXPY in rvector.c (or, really, the implementation of VecAXPYAsync_Private, which is called by VexAXPY), it first calls >> PetscCall(VecSetErrorIfLocked(y, 1)); >> then calls >> PetscCall(VecLockReadPush(x)); >> then dispatches the AXPY method, followed by >> PetscCall(VecLockReadPop(x)); >> >> We’re curious why it just checks whether y is locked but goes through the whole locking and unlocking process for x. It seems like one should either also lock y or one could simply check whether there is a write lock on x, without having to go through the whole push/pop sequence. >> >> Is it written this way because the easiest way to check whether x has a write lock on it (and throw an error if it does) is to call VecLockReadPush? Is this pattern a relic of when PETSc implemented locks differently? Is there some other reason for the “inconsistent” (to our minds) handling of x and y? >> >> Thanks, >> >> Paul & Steve >>

1 0