Re: [petsc-dev] SNESVISetVariableBounds

I would argue that they should only be members for SNESVI. Todd. > On May 14, 2016, at 10:46 PM, Matthew Knepley wrote: > > If I call this on a regular SNES, like newtonls, I get a memory leak > because it defaults to the VI version, but SNESReset() only uses > the newtonls

Re: [petsc-dev] Is the website down?

Presumably. Argonne lost power during a thunderstorm and they are trying to bring the site back up. Todd. > On Jul 28, 2016, at 2:35 PM, Matthew Knepley wrote: > > Matt > > -- > What most experimenters take for granted before they begin their experiments > is infinitely

Re: [petsc-dev] changing matrices

> If you did this for the TAO user API then one could argue it should be done > for TS also. But I don't think it should be done for TS. > > Two reasons for not having a separate API for linear and nonlinear problems > is > 1) I may want to use a "nonlinear" ODE integrator (that is an

Re: [petsc-dev] coding style

TAO_BCO_TRON, and TAO_BQP_GPCG. >>> >>> Thoughts? >>> >>> Todd. >>> >>> >>>> On Aug 16, 2016, at 4:32 PM, Oxberry, Geoffrey Malcolm <oxber...@llnl.gov> >>>> wrote: >>>> >>>> Definitel

Re: [petsc-dev] coding style

te: > > Definitely flags for linear problems would be helpful for TAO. Once there is > an example up, I'd be happy to add that to the SQPTR pull request. > > > From: petsc-dev-boun...@mcs.anl.gov [petsc-dev-boun...@mcs.anl.gov] on behalf &g

Re: [petsc-dev] coding style

talk about > it to someone not at ANL. As someone who is interested in both contributing > to TAO and using it in research, this question is very interesting to me. > > Best, > Geoff > > From: Munson, Todd [tmun...@mcs.anl.gov] >

Re: [petsc-dev] coding style

outside the box and there is no guarantee that zero is within the box. Todd. > On Aug 18, 2016, at 9:00 AM, Matthew Knepley <knep...@gmail.com> wrote: > > On Thu, Aug 18, 2016 at 8:55 AM, Munson, Todd <tmun...@mcs.anl.gov> wrote: > > Just to add some more thoughts to this ar

Re: [petsc-dev] coding style

t of this particular comment that the user claims their > model is quadratic? Of course evaluating at 0 has no special meaning > for a general nonlinear model. > >>> On Aug 18, 2016, at 11:02 AM, Munson, Todd <tmun...@mcs.anl.gov> wrote: >>> >>>> >&

Re: [petsc-dev] coding style

>> Internally the solvers can do lots of stuff. Most interior point >> methods, for example, would convert any inequality constraints >> into equality constraints by adding slack variables and >> bounding the slacks. That way they only need bounds on >> variables. > > Yes; for instance,

Re: [petsc-dev] coding style

For now, I am not proposing interface changes, but rather answering the question of what types of problems do we need to support. We can discuss actual interfaces later. Note: you really only need one multiplier for the each of the constraints (maybe interior-point methods are different). The

Re: [petsc-dev] coding style

>> For now, I am not proposing interface changes, but rather answering the >> question of what types of problems do we need to support. We can >> discuss actual interfaces later. >> >> Note: you really only need one multiplier for the each of the >> constraints (maybe interior-point methods

Re: [petsc-dev] simplification of solvers that utilize KSPNASH STCG or GLTR

I don't see any reason not to make the change. Todd. > On Aug 21, 2016, at 9:40 PM, Barry Smith wrote: > > > Todd, > >The TAO solvers that utilize KSPNASH STCG or GLTR have all this horribly > redundant unneeded code > > /* Solve the trust region subproblem

Re: [petsc-dev] coding style

>>> As far as I know, the only information needed in the Hilbert space approach >>> is matrices denoting inner products and norms. >> >> The norms are not a problem, especially just the norm you use to decide if >> you have "converged". The trickier issue is "the inner products", which >>

Re: [petsc-dev] coding style

>> I do not understand this. The developer API will be the same for all >> solvers. What a solver does internally to reformulate is its own >> problem. I am more worried about providing consistent >> information to the users. > > As far as I understand it, there is no API for developing

Re: [petsc-dev] coding style

> SQPTR needs some work. I wrote it over 14 days; mostly whatever time I could > spare at ICSP, plus three weekends. Right now, it’s written so that various > steps of the algorithm could be factored out and tested individually using a > handwritten test harness. The performance could be

Re: [petsc-dev] TAO method selection (was "coding style")

Hi! The only provable way to test for linearity of a function is using code analysis. A quick hack that should work okay is to evaluate the gradient at two (or more) random points and calculate the distance between the gradients. Note: this is not a good test for piecewise linear functions,

Re: [petsc-dev] coding style

>> Please do. I’m interested in contributing methods to TAO because I like >> using PETSc, it seems like the most expedient way to get a solver my project >> can use with features we need, and I have great respect for the software you >> guys put out. If there is anything I can do to expedite

Re: [petsc-dev] coding style

If the user supplied only a g(x) to a solver meant for quadratic problems, we would call grad[g(0)] [thanks Matt!] to get the linear term and hess[g(0)] to get the Hessian matrix. So that is possible as well. Maybe we should just keep things as they exist now and not add extra complications.

Re: [petsc-dev] coding style

> > People are free to use MatShell to create a "matrix" that is actually a > nonlinear operator. Solvers won't work properly if it's not, but that's > their problem. The quadratic programming solvers in our case will happily go and tell you it solved the problem...however, the problem it

Re: [petsc-dev] simplification of solvers that utilize KSPNASH STCG or GLTR

We are in agreement. I should not use double negatives. This change should be made. Todd. > On Aug 21, 2016, at 11:39 PM, Barry Smith <bsm...@mcs.anl.gov> wrote: > > >> On Aug 21, 2016, at 11:33 PM, Munson, Todd <tmun...@mcs.anl.gov> wrote: >> >>

Re: [petsc-dev] simplification of solvers that utilize KSPNASH STCG or GLTR

I will start making this simplification today in a new branch. Todd. > On Aug 22, 2016, at 6:18 AM, Munson, Todd <tmun...@mcs.anl.gov> wrote: > > > We are in agreement. I should not use double negatives. > > This change should be made. > > Todd. > >&

Re: [petsc-dev] fortran literals

I am confused by Blaise's statement. "selected_real_kind(5)" is well defined across compilers; it returns an integer value that can be used in the kind statements and selected real numbers with at least 5 digits of precision. With the exception of -1, -2, and -3 (plus -4 and -5 in Fortran

Re: [petsc-dev] fortran literals

Cool! For what its worth, that only works when PETSC_USE_FORTRANKIND is true. I'm not sure how many of the Petsc builds have this flag set. Any idea how to do the same thing in C? Todd. > On Sep 1, 2016, at 4:13 PM, Lisandro Dalcin wrote: > > > On 1 September 2016 at

Re: [petsc-dev] fortran literals

>> I'd like to be able to do something like the following in Fortran: >> >> PetscReal c >> >> c = PetscRealCast(5.78D0) >> >> where PetscRealCast is real() for single precision and dble() >> for double precision. Without the cast, you would get all >> kinds of warnings of the form

[petsc-dev] fortran literals

Dear petsc developers, Please do not get too mad at me... I have a C and Fortran test example that should be exactly the same problem. The numerical methods, however, produce different results. I traced this back to the literals used to define constants in the test Fortran problem. C

Re: [petsc-dev] fortran literals

The TS constants are weird in the code. Some of have enough digits for double, some for quad, and some for quad double. I suspect mathematica output some of the constants. Todd. > On Sep 1, 2016, at 10:29 PM, Jed Brown <j...@jedbrown.org> wrote: > > "Munson, Todd&q

[petsc-dev] quasi-newton approximations

One of the common concepts for TAO and SNES is the quasi-Newton approximations. SNES seems to only use them in SNESQN (for non-symmetric matrices) and TAO uses them in TAOLMVM and TAOBLMVM (for symmetric matrices). TOA also allows them to be used as a preconditioner for the Hessian-based

Re: [petsc-dev] quasi-newton approximations

used, I’m not sure it > makes sense anymore. > > Geoff > > From: <petsc-dev-boun...@mcs.anl.gov> on behalf of Matthew Knepley > <knep...@gmail.com> > Date: Tuesday, August 30, 2016 at 2:02 PM > To: "Munson, Todd" <tmun...@mcs.anl.gov> > Cc:

Re: [petsc-dev] quasi-newton approximations

30, 2016, at 9:26 PM, Oxberry, Geoffrey Malcolm <oxber...@llnl.gov> > wrote: > > > > On 8/30/16, 12:36 PM, "Munson, Todd" <tmun...@mcs.anl.gov> wrote: > >> >> For preconditioners, I use them as a default for unconstrained and bound >>

Re: [petsc-dev] exascale applications and PETSc usefulness

Geoff, How are they modeling and solving their PDEs? Todd. >> € Transforming Additive Manufacturing through Exascale Simulation >> (TrAMEx), John Turner (ORNL) with LLNL, LANL, NIST > > PETSc did not come up in TrAMEx meetings I was involved in, and I do not > believe it will be used. I

Re: [petsc-dev] need C++ expert help

The write statement return type is ssize_t. For whatever reason its a signed type because it can return -1 on error. I would suggest using the ssize_t type for both and changing the "!=" to a "<" which will abort if write either returns a negative or the number of bytes written is not

Re: [petsc-dev] Solving under determined systems

You can set up TAO to solve such a problem. However, your problem boils down to solving the linear system w - V*lambda = 0 V'*w = b Taking the Schur complement with respect to w, you get the system V'*V*lambda = b You then form and invert V'*V, which is a 5x5 matrix and

Re: [petsc-dev] fortran literals

Did we come to a conclusion on this? Is it worthwhile adding macros for C and Fortran literals to make sure they match the PetscScalar type along with the appropriate configure tests? Todd. > On Sep 3, 2016, at 3:18 PM, Lisandro Dalcin wrote: > > > On 2 September 2016

Re: [petsc-dev] coding style

. > On Aug 16, 2016, at 7:03 PM, Barry Smith <bsm...@mcs.anl.gov> wrote: > > >> On Aug 16, 2016, at 6:09 PM, Munson, Todd <tmun...@mcs.anl.gov> wrote: >> >> >> Is there a reason to put flags into PETSc for linear or nonlinear equations? >>

Re: [petsc-dev] coding style

ey Malcolm <oxber...@llnl.gov> >>> wrote: >>> >>> Definitely flags for linear problems would be helpful for TAO. Once there >>> is an example up, I'd be happy to add that to the SQPTR pull request. >>> >>> _________

Re: [petsc-dev] (no subject)

> On Sep 22, 2017, at 7:35 AM, Matthew Knepley wrote: > > On Fri, Sep 22, 2017 at 12:06 AM, Richard Tran Mills wrote: > Thanks for sharing this, Barry. I haven't had time to read their paper, but > it looks worth a read. > > Hong, since many

Re: [petsc-dev] Question about linesearch

Hi, I am not sure that this linesearch is implemented in PETSc itself. To implement it, you would need the ability to perform projections onto your feasible region, which is what I am assuming you mean by undershoot or overshoot. Once the projections are involved, however, there are lots of

[petsc-dev] ISGetIndices

I had a question. There is VecGetArrayRead and VecRestoreArrayRead. However, the sameconcept does not appear with IS. Is there a reason for not having ISGetIndicesRead and ISRestoreIndicesRead? Thanks, Todd.

Re: [petsc-dev] ISGetIndices

> On Nov 8, 2017, at 10:32 AM, Matthew Knepley <knep...@gmail.com> wrote: > > On Wed, Nov 8, 2017 at 11:21 AM, Munson, Todd <tmun...@mcs.anl.gov> wrote: > > I had a question. There is VecGetArrayRead and VecRestoreArrayRead. > However, the

Re: [petsc-dev] ISGetIndices

> We could consider this, but really IS is intended to be a static object, not > a dynamic one. > I think Jed's SegBuffer is supposed to be dynamic, and could underlie a > dynamic index > object. I could be wrong, but my recollection is that the initial reason for the index sets was the

Re: [petsc-dev] calling petsc from a mex file

> On May 8, 2018, at 1:02 PM, Smith, Barry F. <bsm...@mcs.anl.gov> wrote: > > > >> On May 8, 2018, at 12:30 PM, Munson, Todd <tmun...@mcs.anl.gov> wrote: >> >> >> Hi, >> >> I wonder if anyone has experience calling petsc

Re: [petsc-dev] calling petsc from a mex file

ot;. Todd. > On May 8, 2018, at 2:21 PM, Smith, Barry F. <bsm...@mcs.anl.gov> wrote: > > > Push the branch that does this or send me the code and I'll debug it. I now > have some vague memory about this behavior. > >Barry > > >> On May 8, 2018, at

Re: [petsc-dev] calling petsc from a mex file

get started, type one of these: helpwin, helpdesk, or demo. > For product information, visit www.mathworks.com. > >>> taopounders() >>> exit > ~/Src/petsc/src/tao/leastsquares/examples/matlab > (tmunson/tao-pounders-matlab-interface=) arch-matlab > > >> On

[petsc-dev] calling petsc from a mex file

Hi, I wonder if anyone has experience calling petsc from matlab using mex. I have the simplest possible mexFunction that just calls PetscInitialize() and PetscFinalize(). That part seems to work fine, but when I exit from matlab I get a segmentation violation and a petsc error message. I

Re: [petsc-dev] titan

oving accounts, such as > Satish's, so testing gets difficult. > >But yes, we want to support Titan so have users send > configure.log/make.log to petsc-ma...@mcs.anl.gov > >Barry > > > > On Jul 6, 2018, at 12:45 PM, Munson, Todd wrote: > > &

Re: [petsc-dev] MATLMVM

I would be happy with one matrix type and removing the convenience functions from the code. I am surprised that the dark lord did not mention it when he approved the pull request... Matt: the difference in the subtypes is that they are using different formulas that result in different

[petsc-dev] vector inner products

There is a bit of code in TAO that allows the user to change the norm to a matrix norm. This was introduced to get some mesh independent behavior in one example (tao/examples/tutorials/ex3.c). That norm, however, does not propagate down into the KSP methods and is only used for testing

Re: [petsc-dev] vector inner products

, then another > implementation that is based on passing in a matrix, maybe one based on > passing in a vector. Then each solver would have a XXXSetInnerProduct() > while defaulting to l2. > > Barry > > >> On Apr 12, 2018, at 12:21 PM, Munson, Todd <tmun...@mcs.a

Re: [petsc-dev] vector inner products

on discrete quantities is DM, so my first inclination is that >> any continuous interpretation of vectors, including inner products and >> norms, belongs in DM. >> >> "Munson, Todd" <tmun...@mcs.anl.gov> writes: >> >>> There is a bit of code

Re: [petsc-dev] vector inner products

supported only for the TAO quasi-Newton method? Todd. > On Apr 13, 2018, at 9:11 PM, Oxberry, Geoffrey Malcolm <oxber...@llnl.gov> > wrote: > > > > On 4/12/18, 15:06, "petsc-dev on behalf of Munson, Todd" > <petsc-dev-boun...@mcs.anl.gov on beh

Re: [petsc-dev] Target next PETSc/TAO release for March 30

The next milestone that includes a PETSc release is due on September 30, 2018. Consider yourself warned. :) Todd. > On Mar 23, 2018, at 12:21 PM, Jed Brown wrote: > > I think it's feasible, but are we ever going to have more than a week's > notice so that we can have a

Re: [petsc-dev] TaoTerminationReason - TaoConvergedReason

I am not sure that VecGetSubVec and MatGetSubMat are needed. These should only be used for the active-set methods (I hope) and there should be native PETSc equivalents used by the PETSc active-set variational inequality solvers, for example. Todd. On Feb 18, 2014, at 9:22 AM, Jed Brown

Re: [petsc-dev] [mpich-discuss] turning off MPI abort messages

Sounds like someone needs to look up the definition of customer support. On Feb 21, 2014, at 1:20 PM, Jeff Hammond jeff.scie...@gmail.com wrote: Aron told me that I should have said we look forward to your patch earlier instead of causing you guys to go apoplectic over my different

Re: [petsc-dev] Mac OS X El Capitan does not propagate DYLD_LIBRARY_PATH from parent process

Can you create a copy of the /usr/bin/env executable in your home directory and call that? I wonder if its based on the directory where the executable resides. /usr is "protected". Todd. > On Oct 7, 2015, at 4:36 PM, Jed Brown wrote: > > Satish Balay

Re: [petsc-dev] Mac OS X El Capitan does not propagate DYLD_LIBRARY_PATH from parent process

Satish can you try it from an account that does not have admin privileges? Todd. > On Oct 7, 2015, at 4:08 PM, Jed Brown wrote: > > Satish Balay writes: > >> And it works fine from C code. > > Yes, but /usr/bin/python is also C code, so how does the OS

Re: [petsc-dev] Tao unusable from complex??

e are other > issues that I'm not considering? > > Il giorno Mer 12 Dic 2018, 18:46 Munson, Todd ha > scritto: > > Yes; the optimization problems do not make sense if the objective function is > from C^n to C, as there is not a natural ordering for complex numbers. If > your object

Re: [petsc-dev] Tao unusable from complex??

Yes; the optimization problems do not make sense if the objective function is from C^n to C, as there is not a natural ordering for complex numbers. If your objective is from C^n to R (and the constraints are from C^n to R^m), then the problem can be well defined. Then we need to get into

Re: [petsc-dev] [tao-comments #390396] TAO for GPU?

Hi, Let me include the pets-dev team in the discussion. TAO uses the PETSc matrices, vectors, and linear solvers our operations. Some of the operations already have GPU implementations. In terms of the unconstrained solvers, the Newton methods are based on the linear conjugate gradient

Re: [petsc-dev] How long?

One question from me would be, will any of the exascale machines support Julia when they are delivered? Todd. > On Mar 11, 2019, at 9:28 PM, Smith, Barry F. via petsc-dev > wrote: > > > PETSc source code is becoming an unmaintainable, unextendable monstrosity. > How long until Julia is

Re: [petsc-dev] How long?

Barry F. via petsc-dev >> wrote: >> >> >> There is no particular reason they shouldn't. >> >> In fact, we should ask for an uplift to prepare Julia for exascale if >> someone hasn't already ;) >> >> Barry >> >> >>> On Mar 11, 2019, at 9:35 PM,

Re: [petsc-dev] Fwd: [ECP-PIs] Updates on the planned Aurora and Frontier exascale systems

Plus no mention of MPI. I wonder if that is an oversight or if we should ditch MPI as well... Todd. > On May 7, 2019, at 10:25 AM, Smith, Barry F. via petsc-dev > wrote: > > PETSc developers, > > Note that this machine will apparently not support either of our two > current GPU

Re: [petsc-dev] First call to cudaMalloc or cudaFree is very slow on summit

There are some side effects when loading shared libraries, such as initializations of static variables, etc. Is something like that happening? Another place is the initial runtime library that gets linked (libcrt0 maybe?). I think some MPI compilers insert their own version. Todd. > On

Re: [petsc-dev] pull request tutorial October 15 at 2pm central

Hi all, I forgot to send a reminder earlier. Our next tutorial will be October 15 at 2pm central. Barry will be leading a tutorial on pull requests from preparing the request to what happens during the review and after the pull request is accepted. Please email Barry directly if you have

[petsc-dev] pull request tutorial October 15 at 2pm central

Hi, Thank you to Patrick for giving his tutorial on sphinx. The slides should soon be available at: https://docs.petsc.org/en/latest/developers/documentation/#sphinx-documentation Our next tutorial will be October 15 at 2pm central. Barry will be leading a tutorial on pull requests from

[petsc-dev] sphinx tutorial October 1 at 2pm central

Hi all, Patrick Sanan will be giving a tutorial on sphinx for the petsc developers on October 1 at 2pm central. The information to join the call is below. This is timely as the petsc documentation is being moved to use sphinx. Hope to see those interested at the tutorial. Thanks, Todd.

Re: [petsc-dev] sphinx tutorial October 1 at 2pm central

Hi all, A reminder that Patrick Sanan will be giving a tutorial on sphinx for the petsc developers today, October 1 at 2pm central. The information to join the call is below. This is timely as the petsc documentation is being moved to use sphinx. Hope to see those interested at the

[petsc-dev] Test Harness Tutorial on October 29 at 2pm Central

Dear all, A reminder that our next PETSc tutorial will be by Scott Kruger who will be talking about the test harness, which will occur on October 29 at 2pm central. Please email Scott directly if you have questions that you would like him to address in the tutorial. The information for the

Re: [petsc-dev] TAOPDIPM

Hi Pierre, I would say the answer to that question is "no, its not expected". We will look into fixing it. It seems like the default tolerances are being set to zero and the result is an inability to satisfy the constraints or gradient of the Lagrangian to that small of a tolerance.

[petsc-dev] no PETSc biweekly meetings for November 12 and 24

Hi all, Due to supercomputing workshops and many conflicts, including Thanksgiving, we will be cancelling the normal biweekly meeting for Thursday November 12 and 24. Our next meeting will be December 10 at 2pm central. Thanks, Todd.

[petsc-dev] Test Harness Tutorial on October 29 at 2pm Central

Dear all, Our next PETSc tutorial will be by Scott Kruger who will be talking about the test harness, which will occur on October 29 at 2pm central. Please email Scott directly if you have questions that you would like him to address in the tutorial. The information for the call is below.

Re: [petsc-dev] Kokkos/Crusher perforance

I want to note that crusher is early access hardware, so we should expect performance to not be great right now. Doing what we can to help identify the performance issues and keeping OLCF informed would be the best. Note that we cannot make any of the preliminary results publicly available

Re: [petsc-dev] have requests for MR review indicate time expected to complete

I guess one could use tags to indicate the complexity of the review? I personally would like a weekly digest of MRs that I have been requested to review with clickable links. The dashboard would also be helpful. All the best, Todd. From: petsc-dev on behalf of Matthew Knepley Date:

[petsc-dev] Postdoc Openings at Argonne

Hi all, We are seeking postdoctoral candidates to work at Argonne on research and development efforts in the areas of robust and efficient algebraic solvers, time integrators, numerical optimizers, or related technologies in the PETSc/TAO library that target exascale supercomputers and other