[petsc-dev] coding style

Oxberry, Geoffrey Malcolm oxberry1 at llnl.gov
Thu Aug 18 15:30:54 CDT 2016 

On Aug 18, 2016, at 1:27 PM, Matthew Knepley <knepley at gmail.com<mailto:knepley at gmail.com>> wrote:

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

> On Aug 18, 2016, at 9:31 AM, Munson, Todd <tmunson at mcs.anl.gov<mailto: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.

Yes, based on what I know about FieldSplit, it would be better to make this decision a runtime decision.

Geoff


  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<mailto: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<mailto:petsc-dev-bounces at mcs.anl.gov> [petsc-dev-bounces at mcs.anl.gov<mailto:petsc-dev-bounces at mcs.anl.gov>] on behalf of Barry Smith [bsmith at mcs.anl.gov<mailto: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<mailto: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<mailto:bsmith at mcs.anl.gov>> wrote:
>>>>>>
>>>>>>
>>>>>>> On Aug 15, 2016, at 7:42 PM, Munson, Todd <tmunson at mcs.anl.gov<mailto: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<mailto:bsmith at mcs.anl.gov>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Todd,
>>>>>>>>
>>>>>>>>> On Aug 15, 2016, at 10:26 AM, Satish Balay <balay at mcs.anl.gov<mailto: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/26be4d44/attachment.html>

More information about the petsc-dev mailing list