Re: [petsc-dev] coding style

> On Aug 19, 2016, at 10:36 AM, Munson, Todd wrote: > > > 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 "co

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

>> 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 t

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 improve

Re: [petsc-dev] coding style

> On Aug 18, 2016, at 7:58 PM, Munson, Todd wrote: > > >>> 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. >>

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 con

Re: [petsc-dev] coding style

> On Aug 18, 2016, at 7:10 PM, Oxberry, Geoffrey Malcolm > wrote: > > >> On Aug 18, 2016, at 4:53 PM, Barry Smith wrote: >> >>> >>> On Aug 18, 2016, at 6:25 PM, Oxberry, Geoffrey Malcolm >>> wrote: >>> >>> cc-ing Patrick Farrell for the function space part of this discussion, >>> since

Re: [petsc-dev] coding style

> On Aug 18, 2016, at 4:52 PM, Munson, Todd wrote: > > >>> 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

Re: [petsc-dev] coding style

On Thu, Aug 18, 2016 at 7:10 PM, Oxberry, Geoffrey Malcolm < oxber...@llnl.gov> wrote: > > On Aug 18, 2016, at 4:53 PM, Barry Smith wrote: > > > On Aug 18, 2016, at 6:25 PM, Oxberry, Geoffrey Malcolm > wrote: > > cc-ing Patrick Farrell for the function space part of this discussion, > since he k

Re: [petsc-dev] coding style

On Aug 18, 2016, at 4:53 PM, Barry Smith mailto:bsm...@mcs.anl.gov>> wrote: On Aug 18, 2016, at 6:25 PM, Oxberry, Geoffrey Malcolm mailto:oxber...@llnl.gov>> wrote: cc-ing Patrick Farrell for the function space part of this discussion, since he knows more about it than I do, and can speak to

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, KNI

Re: [petsc-dev] coding style

> On Aug 18, 2016, at 6:25 PM, Oxberry, Geoffrey Malcolm > wrote: > > cc-ing Patrick Farrell for the function space part of this discussion, since > he knows more about it than I do, and can speak to his experience re: the > Riesz map pull request he made for LMVM. > >> On Aug 18, 2016, at 4

Re: [petsc-dev] coding style

cc-ing Patrick again, because I screwed up his e-mail address On Aug 18, 2016, at 4:25 PM, Oxberry, Geoffrey M. mailto:oxber...@llnl.gov>> wrote: cc-ing Patrick Farrell for the function space part of this discussion, since he knows more about it than I do, and can speak to his experience re: th

Re: [petsc-dev] coding style

cc-ing Patrick Farrell for the function space part of this discussion, since he knows more about it than I do, and can speak to his experience re: the Riesz map pull request he made for LMVM. > On Aug 18, 2016, at 4:01 PM, Munson, Todd wrote: > > >>> For now, I am not proposing interface chan

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 ar

Re: [petsc-dev] coding style

> On Aug 18, 2016, at 3:17 PM, Munson, Todd wrote: > > > 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

Re: [petsc-dev] coding style

Thank you; now I follow. > On Aug 18, 2016, at 2:59 PM, Munson, Todd wrote: > > > Exactly, its only for a quadratic programming solver, so the user > is claiming their model is quadratic and the solver > extracts the matrices. > > Todd. > >> On Aug 18, 2016, at 4:54 PM, Jed Brown wrote: >>

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

Exactly, its only for a quadratic programming solver, so the user is claiming their model is quadratic and the solver extracts the matrices. Todd. > On Aug 18, 2016, at 4:54 PM, Jed Brown wrote: > > "Oxberry, Geoffrey Malcolm" writes: > >> I realize this point was brought up earlier, but doe

Re: [petsc-dev] coding style

"Oxberry, Geoffrey Malcolm" writes: > I realize this point was brought up earlier, but doesn’t this > discussion still assume that evaluating g at zero is defined and makes > sense? Though I see the appeal in this design, I’m not sure it will > necessarily work in practice. For instance, we defin

Re: [petsc-dev] coding style

I realize this point was brought up earlier, but doesn’t this discussion still assume that evaluating g at zero is defined and makes sense? Though I see the appeal in this design, I’m not sure it will necessarily work in practice. For instance, we definitely have formulations that involve terms

Re: [petsc-dev] coding style

>> >>> Todd. >>> >>> >>>> On Aug 16, 2016, at 4:32 PM, Oxberry, Geoffrey Malcolm >>>> mailto:oxber...@llnl.gov>> wrote: >>>> >>>> Definitely flags for linear problems would be helpful for TAO. Once there >>

Re: [petsc-dev] coding style

gt; >> > >> > >> > >>> > >>> The methods would then explicitly mention the type of optimization > problem > >>> with, for example, TAO_UCO_LMVM, TAO_BCO_TRON, and TAO_BQP_GPCG. > >>> > >>> Thoughts? > >>>

Re: [petsc-dev] coding style

>>> Thoughts? >>> >>> Todd. >>> >>> >>>> On Aug 16, 2016, at 4:32 PM, Oxberry, Geoffrey Malcolm >>>> wrote: >>>> >>>> Definitely flags for linear problems would be helpful for TAO. Once t

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 solved

Re: [petsc-dev] coding style

> On Aug 18, 2016, at 11:52 AM, Jed Brown wrote: > > Barry Smith writes: > >> Seems reasonable. Note for SNES we have something similar in that user can >> solve either F(x) = b or F(x) - b = 0 depending on if they provide the b >> explicitly. > > I'd just say that the algorithm should st

Re: [petsc-dev] coding style

"Munson, Todd" writes: > 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. Okay. > Maybe we should just keep things as they ex

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

Barry Smith writes: >Seems reasonable. Note for SNES we have something similar in that user can > solve either F(x) = b or F(x) - b = 0 depending on if they provide the b > explicitly. I'd just say that the algorithm should still work correctly if the user doesn't separate everything since

Re: [petsc-dev] coding style

_ >>> From: petsc-dev-boun...@mcs.anl.gov [petsc-dev-boun...@mcs.anl.gov] on >>> behalf of Barry Smith [bsm...@mcs.anl.gov] >>> Sent: Monday, August 15, 2016 6:18 PM >>> To: Munson, Todd >>> Cc: petsc-dev >>> Subject: Re: [petsc-dev] coding style

Re: [petsc-dev] coding style

es. >> >> The function being optimized is linear, quadratic, or general (another >> case is separable). >> >> The equality constraints are linear?, quadratic? general? or something >> else? >> >>The inequality constraints are simple bounds?

Re: [petsc-dev] coding style

general? or something > > else? > > > > The inequality constraints are simple bounds? linear? quadratic? > > general? something else? > > > > Is there a fourth (or even more) axis of problem properties? > > > >Is this level of categ

Re: [petsc-dev] coding style

> > Is there a fourth (or even more) axis of problem properties? > > > >Is this level of categories enough to organize the directories and > naming of TAO solvers? > > > > Barry > > > > > > > >> > >> The methods would t

Re: [petsc-dev] coding style

>> The methods would then explicitly mention the type of optimization problem >> with, for example, TAO_UCO_LMVM, TAO_BCO_TRON, and TAO_BQP_GPCG. >> >> Thoughts? >> >> Todd. >> >> >>> On Aug 16, 2016, at 4:32 PM, Oxberry, Geoffrey Malcolm

Re: [petsc-dev] coding style

ely 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-de

Re: [petsc-dev] coding style

r 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 >

Re: [petsc-dev] coding style

f optimization problem >> with, for example, TAO_UCO_LMVM, TAO_BCO_TRON, and TAO_BQP_GPCG. >> >> Thoughts? >> >> Todd. >> >> >>> On Aug 16, 2016, at 4:32 PM, Oxberry, Geoffrey Malcolm >>> wrote: >>> >>> Definitely fl

Re: [petsc-dev] coding style

s 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 of Barry Smith [bs

Re: [petsc-dev] coding style

gust 16, 2016 4:09 PM > To: Oxberry, Geoffrey Malcolm > Cc: Smith, Barry F.; petsc-dev > Subject: Re: [petsc-dev] coding style > > Is there a reason to put flags into PETSc for linear or nonlinear equations? > In PETSc > there is a natural difference between linear (KSP) and no

Re: [petsc-dev] coding style

using it in research, this question is very interesting to me. Best, Geoff From: Munson, Todd [tmun...@mcs.anl.gov] Sent: Tuesday, August 16, 2016 4:09 PM To: Oxberry, Geoffrey Malcolm Cc: Smith, Barry F.; petsc-dev Subject: Re: [petsc-dev] coding styl

Re: [petsc-dev] coding style

ely 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 > of Barry

Re: [petsc-dev] coding style

[bsm...@mcs.anl.gov] Sent: Monday, August 15, 2016 6:18 PM To: Munson, Todd Cc: petsc-dev Subject: Re: [petsc-dev] coding style > On Aug 15, 2016, at 8:08 PM, Munson, Todd wrote: > > > Since we are only doing diagonal modifications to the matrix in > my case, should I simply create a matne

Re: [petsc-dev] coding style

> On Aug 15, 2016, at 8:08 PM, Munson, Todd wrote: > > > Since we are only doing diagonal modifications to the matrix in > my case, should I simply create a matnest in my part of the > code and apply the diagonal modification in the matnest > without directly modifying any of the matrices? > T

Re: [petsc-dev] coding style

Since we are only doing diagonal modifications to the matrix in my case, should I simply create a matnest in my part of the code and apply the diagonal modification in the matnest without directly modifying any of the matrices? That might be cleaner for the users. Todd. > On Aug 15, 2016, at 7:

Re: [petsc-dev] coding style

> On Aug 15, 2016, at 7:42 PM, Munson, Todd wrote: > > > Got it. I will get all the code fragments in the developer doc that > are not meant to be deliberately wrong fixed tomorrow; at least > that code will be compliant... :) > > Then its onto fixing bqpip. > > Was there a final say on the

[petsc-dev] Coding style and its violations...

On Thu, Jan 17, 2013 at 5:34 PM, Karl Rupp wrote: > Yes, for just stripping out comments without starting preprocessor magic > this seems to be a viable way: > http://stackoverflow.com/**questions/2394017/remove-** > comments-from-c-c-code

[petsc-dev] Coding style and its violations...

Hi, > Yes - looks like I need to send the whole thing through some filter > stripping out comments first. Looks like GCC can do that with > >gt; gcc -fpreprocessed -dD -E file.c > > > Uh, are you sure these are the options you want? -fpreprocessed assumes > the input has already been

[petsc-dev] Coding style and its violations...

On Thu, Jan 17, 2013 at 4:39 PM, Karl Rupp wrote: > Yes - looks like I need to send the whole thing through some filter > stripping out comments first. Looks like GCC can do that with > >gt; gcc -fpreprocessed -dD -E file.c > > Uh, are you sure these are the options you want? -fpreprocessed assu

[petsc-dev] Coding style and its violations...

Hi, > Many/most of these are not really violations, the guideline just isn't > written precisely enough. > http://krupp.iue.tuwien.ac.at/petsc-style/closing-bracket.txt Yeah, I also noticed that the style guide lacks some additional precision. I plan to eliminate the obvious violations first an

[petsc-dev] Coding style and its violations...

Hi Peter, > That's awesome! One brief note is that the fortran stubs generator > doesn't acquiesce to social shaming and as such its output should > probably be ignored. :) I haven't thought about coupling the thing with 'hg blame' ;-) The Fortran stubs in */ftn-auto/* are already ignored in mo

[petsc-dev] Coding style and its violations...

Cool. Many/most of these are not really violations, the guideline just isn't written precisely enough. http://krupp.iue.tuwien.ac.at/petsc-style/closing-bracket.txt A lot of these are in comments: http://krupp.iue.tuwien.ac.at/petsc-style/else-indentation.txt Use of // in comments is okay (/* do

[petsc-dev] Coding style and its violations...

That's awesome! One brief note is that the fortran stubs generator doesn't acquiesce to social shaming and as such its output should probably be ignored. :) - Peter On Thu, Jan 17, 2013 at 4:05 PM, Karl Rupp wrote: > Hello again, > > I've set up a couple of scripts checking for compliance wit

[petsc-dev] Coding style and its violations...

Hello again, I've set up a couple of scripts checking for compliance with the coding styles and started with the removal of tabs. There's also a little page set up for tracking the current progress (i.e. the work left to be done): http://krupp.iue.tuwien.ac.at/petsc-style/ The page is automat

[petsc-dev] Coding style and its violations...

Hi, >>> Some projects (e.g., moose) reject a noncompliant push. The >>> committer can then rewrite the patch locally before it is >>> published and resubmit. >>> >>> >>> IIRC, this is done server-side, but with a DVCS, that's too late (or >>> causes the "pusher" a

[petsc-dev] Coding style and its violations...

On Tue, Jan 15, 2013 at 3:43 PM, Karl Rupp wrote: > Yeah, that was my intention. We can certainly provide instructions to set > a commit-hook, but it's the user's responsibility to set this up. configure can add it to .hg/hgrc if the commit hook is portable enough. Users would then have to expl

[petsc-dev] Coding style and its violations...

On Jan 15, 2013, at 3:43 PM, Karl Rupp wrote: > Hi, > >>Some projects (e.g., moose) reject a noncompliant push. The >>committer can then rewrite the patch locally before it is >>published and resubmit. >> >> >>IIRC, this is done server-side, but with a DVCS, that'

[petsc-dev] Coding style and its violations...

Hi, > Some projects (e.g., moose) reject a noncompliant push. The > committer can then rewrite the patch locally before it is > published and resubmit. > > > IIRC, this is done server-side, but with a DVCS, that's too late (or > causes the "pusher" a lot more troub

[petsc-dev] Coding style and its violations...

On Tue, Jan 15, 2013 at 3:39 PM, Karl Rupp wrote: > The problem is that uncrustify is exactly the PETSc style so we >> can't do that comparison automatically. Otherwise we would just run >> uncrustify on all pushes. >> > > I'm afraid I don't understand the first sentence. I'm pretty sure

[petsc-dev] Coding style and its violations...

On 01/15/2013 02:51 PM, Jed Brown wrote: > On Tue, Jan 15, 2013 at 2:47 PM, Barry Smith > wrote: > > Yes. Jed is too in love with Git to ever do this so you have to. > > > What does this have to do with choice of VCS? They all support commit hooks. Oh, Jed, yo

[petsc-dev] Coding style and its violations...

Hi, >> (...) >> So we have a style guide that is partially respected, partially ignored. >> Some things are pretty hard to check automatically, while others are rather >> simple. So let's pick >> "No tabs are allowed in any of the source code." >> as an example and run >> >> $petsc-dev/src> fi

[petsc-dev] Coding style and its violations...

On Tue, Jan 15, 2013 at 3:17 PM, Dmitry Karpeev wrote: > The upside is that setting the check server-side you ensure it is run. > Otherwise you have to rely on each committer to configure it locally. If you limit the people who can push directly, then you see this stuff in pull requests, where

[petsc-dev] Coding style and its violations...

On Tue, Jan 15, 2013 at 2:59 PM, Jed Brown wrote: > On Tue, Jan 15, 2013 at 2:55 PM, Dmitry Karpeev wrote: > >> Some projects (e.g., moose) reject a noncompliant push. The committer >> can then rewrite the patch locally before it is published and resubmit. > > > IIRC, this is done server-side, b

[petsc-dev] Coding style and its violations...

On Tue, Jan 15, 2013 at 2:55 PM, Dmitry Karpeev wrote: > Some projects (e.g., moose) reject a noncompliant push. The committer can > then rewrite the patch locally before it is published and resubmit. IIRC, this is done server-side, but with a DVCS, that's too late (or causes the "pusher" a lo

[petsc-dev] Coding style and its violations...

On Tue, Jan 15, 2013 at 2:51 PM, Jed Brown wrote: > On Tue, Jan 15, 2013 at 2:47 PM, Barry Smith wrote: > >> Yes. Jed is too in love with Git to ever do this so you have to. >> > > What does this have to do with choice of VCS? They all support commit > hooks. > > >> > >> > - Add nightly tests o

[petsc-dev] Coding style and its violations...

On Tue, Jan 15, 2013 at 2:47 PM, Barry Smith wrote: > Yes. Jed is too in love with Git to ever do this so you have to. > What does this have to do with choice of VCS? They all support commit hooks. > > > > - Add nightly tests on the source tree. We can compare the output of a > properly confi

[petsc-dev] Coding style and its violations...

On Jan 15, 2013, at 2:42 PM, Karl Rupp wrote: > Dear all, > > quoting a recent commit: > > > BarryFSmith committed 16 hours ago (raw commit) > > > > silly code formatting problems; some people still need to read the > > style guide > > So we have a style guide that is partially respected, par

[petsc-dev] Coding style and its violations...

Dear all, quoting a recent commit: > BarryFSmith committed 16 hours ago (raw commit) > > silly code formatting problems; some people still need to read the > style guide So we have a style guide that is partially respected, partially ignored. Some things are pretty hard to check automatical