[petsc-dev] coding style

[Matthew Knepley]

On Thu, Aug 18, 2016 at 3:25 PM, Oxberry, Geoffrey Malcolm <
oxberry1 at llnl.gov> wrote:

>
> > On Aug 18, 2016, at 9:31 AM, Munson, Todd <tmunson at mcs.anl.gov> wrote:
> >
> >
> > Here's the table.
> >
> > In my opinion, the important cases are:
> >
> >  Objective: linear, quadratic, general nonlinear.
> >
> >  Constraints: box (e.g. l <= x <= u), polyhedral (e.g. l <= Ax + b <= u),
> >    and general range (e.g. l <= F(x) <= u)
> >
> >  Variables: state, design
>
> Good to know. It seems like there will be at least eight vectors of
> duality multipliers (upper/lower bounds for box, upper/lower bounds for
> polyhedral inequality, upper/lower bounds for general range, polyhedral
> equality, general equality). Partitioning state and design constraints
> yields for dual multiplier vectors. Do you plan on allowing infinities in
> the bound constraints for variables without upper or lower bounds?
>
> These changes might also require changes to IPM and SQPTR to support this
> interface. My main stake in this discussion is adding features that ease
> implementation of new methods; implementing something like
> -tao_view_multipliers would be helpful for debugging primal-dual methods.
>
> >
> > I am not a huge fan of separating into equality constraints and range
> constraints,
> > but we can keep it.  Having only equality constraints does make the
> problem much
> > easier to solve; no need to identify an active set.
> >
> > The variable separation is needed for PDE constrained optimization.  We
> may want
> > to separate constraints into state constraints, design constraints, and
> > joint state/design constraints.  For now, I would only consider design
> > constraints.
>
> This separation applies to any basic/nonbasic partition of decision
> variables, correct? It is needed for reduced-space methods; it is not
> needed for full-space methods. You could shim the full-space method with a
> reduced-space interface as well; I believe ROL already has this sort of
> interface. I think there is a lot of interest in reduced-space methods if
> they are robust and admit a wider range of formulations. LCL right now is
> too limited for the types of problems we want to solve (PDE-constrained
> plus additional design constraints that are not box constraints), and so we
> have to add ad hoc penalization methods to enforce these additional design
> constraints. This case was the motivation for adding SQPTR as a full-space
> method, and more methods need to be added. I’m also concerned based on the
> feedback I got at the IMA workshop on Frontiers in PDE-Constrained
> Optimization that LCL might not be performant enough of an algorithm to
> publish case studies for our applications. I can give more detailed
> feedback off-list on this point.


If I understand this correctly, I would be against changing the interface
for Full-Space vs. Reduced Space solvers. This looks to me like the
same tradeoff we have in FieldSplit, and it should not be an interface
decision, but rather a runtime solver decision.

  Matt


>
> > In the future for stochastic problems, I would probably add a stochastic
> variable
> > type and some objective types (e.g. expectations) and constraints (e.g.
> chance or
> > probabilistic constraints).  That is further down the line though.
>
> Cool. Chance constraints are a thorny topic (can lead to nonconvex or
> ill-behaved formulations, according to the literature), but I think support
> for them is good.
>
> > ====
> >
> > For separability, you can go down a complete rabbit hole of composite,
> > composition, separable, partially separable, group partially
> > separable, and all kinds of other things.
>
> I suspect some of this functionality might be supported by structured
> matrix types plus algorithms for structured solves instead of changing, for
> instance, the nonlinear optimization interface.
>
> >
> > For TAO, I think we should keep it simple and restrict to structured
> > problems of the form:
> >
> >  f(x) = h(x) + g(F(x))
> >
> > where h() and g() are selected from a menu of functions we provide
> > (e.g. one-norm, p-norm, two-norm, weighted two-norm) with well-defined
> > parameters supplied by the user (e.g. the weights) if necessary.
>
> As long as common hazard functionals are in this menu of functions, I
> think this idea will work for stochastic programming.
>
> >
> > The user supplies F:R^n to R^m and derivatives.
> >
> > I think this covers the main TAO codes that use such structure.
> > OWLQL, BMRM and POUNDerS.  Its also rich enough for new
> > methods people may want to add (e.g. Pareto surfaces
> > for multi-objective optimization).
>
> I think so, once support for constrained optimization is lifted up from
> individual solvers and into the TAO interface.
>
> Geoff
>
> >
> > Todd.
> >
> >>  Before doing anything let's try to generate a table that includes all
> (most of?)  the cases.
> >>
> >>   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? linear? quadratic?
> general? something else?
> >>
> >>    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 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 <
> oxberry1 at 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.
> >>>>
> >>>> ________________________________________
> >>>> From: petsc-dev-bounces at mcs.anl.gov [petsc-dev-bounces at mcs.anl.gov]
> on behalf of Barry Smith [bsmith at 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 <tmunson at mcs.anl.gov>
> 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?
> >>>>> That might be cleaner for the users.
> >>>>
> >>>> It will be dependent on the solver how much of the matrix you need
> retain the parts you have modified.
> >>>>
> >>>> MatNest isn't the right thing here. I think you can do
> MatGetDiagonal() to keep the valid diagonal entries then MatDiagonalSet()
> to put back the valid entries.
> >>>>
> >>>> Barry
> >>>>
> >>>>
> >>>>>
> >>>>> Todd.
> >>>>>
> >>>>>> On Aug 15, 2016, at 7:55 PM, Barry Smith <bsmith at mcs.anl.gov>
> wrote:
> >>>>>>
> >>>>>>
> >>>>>>> On Aug 15, 2016, at 7:42 PM, Munson, Todd <tmunson at mcs.anl.gov>
> 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 Hessian/Jacobian matrix when they are
> >>>>>>> modified?  Were we adding a "dirty" bit or was I changing my code
> >>>>>>> to not modify those matrices?
> >>>>>>
> >>>>>> Changing email to petsc-dev since this is a general PETSc/TAO issue.
> >>>>>>
> >>>>>> This is why we don't wait months to fix something :-) I have
> completely forgot the context you are asking  about.
> >>>>>>
> >>>>>> I think the general issue comes up when a problem is linear and the
> user just wants to set and forget the matrices while when the problem is
> nonlinear the user needs to reset values into the matrix anyways so it is
> fine for you to change the matrix internally. Unless there is a way for the
> user to explicitly indicate the system is linear your code cannot know if
> it needs to make a copy of the matrix.
> >>>>>>
> >>>>>> In TS we have typedef enum {TS_LINEAR,TS_NONLINEAR} TSProblemType;
> and TSSetProblemType() that can be used to indicate if the matrices can be
> changed or not (though I don't think we use it in this way, we have an open
> issue https://bitbucket.org/petsc/petsc/issues/135/memory-
> optimization-for-ts
> >>>>>>
> >>>>>> I think you should start by having a flag that indicates if it is
> safe to modify the matrices associated with the TAO object and if not safe
> keep a backup copy.
> >>>>>>
> >>>>>> Barry
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> Todd.
> >>>>>>>
> >>>>>>>> On Aug 15, 2016, at 6:09 PM, Barry Smith <bsmith at mcs.anl.gov>
> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Todd,
> >>>>>>>>
> >>>>>>>>> On Aug 15, 2016, at 10:26 AM, Satish Balay <balay at mcs.anl.gov>
> wrote:
> >>>>>>>>>
> >>>>>>>>> Todd,
> >>>>>>>>>
> >>>>>>>>> Forwarding this to Barry.
> >>>>>>>>>
> >>>>>>>>> Satish
> >>>>>>>>>
> >>>>>>>>> On Mon, 15 Aug 2016, Munson, Todd wrote:
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I'm going through the developer documentation.  There seems to
> be
> >>>>>>>>>> a few things missing from the coding style.
> >>>>>>>>>>
> >>>>>>>>>> For example, in function prototypes, is it:
> >>>>>>>>>>
> >>>>>>>>>> PetscErrorCode MyFunction(char *,const int *,int);
> >>>>>>>>>>
> >>>>>>>>>> or
> >>>>>>>>>>
> >>>>>>>>>> PetscErrorCode MyFunction(char*,const int*,int)
> >>>>>>>>
> >>>>>>>> The second one because the preference is to not have unnecessary
> space.
> >>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Same thing in the definitions:
> >>>>>>>>>>
> >>>>>>>>>> PetscErrorCode MyFunction(char *c,const int *i,int j)
> >>>>>>>>>> {
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> or
> >>>>>>>>>>
> >>>>>>>>>> PetscErrorCode MyFunction(char* c,const int* i,int j)
> >>>>>>>>
> >>>>>>>> The * should always be attached to the variable.
> >>>>>>>>>> {
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> The same questions apply with * replaced by [].
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Next is in the types for variables.  Are pointers grouped
> >>>>>>>>>> separately or together with the type:
> >>>>>>>>>>
> >>>>>>>>>> int   *i,j,*k;
> >>>>>>>>>>
> >>>>>>>>>> or
> >>>>>>>>>>
> >>>>>>>>>> int   *i,*k;
> >>>>>>>>>> int   j;
> >>>>>>>>>>
> >>>>>>>>>> If grouped together, should they be ordered with pointers first
> >>>>>>>>>> and the others later?
> >>>>>>>>>>
> >>>>>>>>>> int   *i,*k,j;
> >>>>>>>>
> >>>>>>>> There is no preference on the above; the pointers do not have to
> be on their own line.
> >>>>>>>>>>
> >>>>>>>>>> On the next topic, do you use
> >>>>>>>>>>
> >>>>>>>>>> char    *blah;
> >>>>>>>>>>
> >>>>>>>>>> or
> >>>>>>>>>>
> >>>>>>>>>> char*   blah;
> >>>>>>>>>>
> >>>>>>>>>> when there is only one of them?
> >>>>>>>>
> >>>>>>>> * belongs on the variable
> >>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I have the same issues with the typedefs.  Sometimes there is
> >>>>>>>>>>
> >>>>>>>>>> typedef struct _EH* EH;
> >>>>>>>>>>
> >>>>>>>>>> and other times
> >>>>>>>>>>
> >>>>>>>>>> typedef struct _EH *EH;
> >>>>>>>>
> >>>>>>>> Here the * belongs as in the first case
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> My personal thought is to be consistent and use char * with a
> space
> >>>>>>>>>> everywhere, but you tell me.  I will then go and fix the
> developer
> >>>>>>>>>> documentation to be consistent with the style guide as a test of
> >>>>>>>>>> my branch management.
> >>>>>>>>>>
> >>>>>>>>>> Todd.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
>


-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20160818/a5f1602d/attachment.html>