[petsc-dev] coding style
Munson, Todd
tmunson at mcs.anl.gov
Wed Aug 17 06:40:20 CDT 2016
I will go through the list more, but several are probably not relevant (e.g.
second-order cone and semidefinite) at this point. We probably do not want
to get into combinatorial either. My guiding principle is important
problems classes that build on PETSc linear algebra.
Todd.
> These are probably the most common cases. Separable is an interesting case, but then I’d argue based on the design principles you laid out above that if I know my problem is separable and I later add linking constraints or objectives, I should be able to call a generic nonlinear programming solver instead.
>
>> The equality constraints are linear?, quadratic? general? or something else?
>
> Linear is the main special case. I’m not aware of quadratic being an interesting special case for equality constraints.
>
>> The inequality constraints are simple bounds? linear? quadratic? general? something else?
>
> Types of constraints would probably be: bounds, linear, second-order cone, semidefinite, maybe quadratic, general. Again, depending on what you want to do for the separable case, you could subdivide these into separable constraints and linking constraints.
>
>> Is there a fourth (or even more) axis of problem properties?
>
> Binary or mixed-integer constraints are another possibility; I assume Sven and Stefan would have more to say about this area, given their EMWG white paper. There are some powerful heuristics for certain problem classes that are somewhat scalable.
>
> For optimization under uncertainty, there is robust optimization, as Todd mentioned, and also stochastic programming. Stochastic programming seems more tractable to me for more general cases of nonlinear programming, but there are certain robust optimization problems that are also tractable and useful. Stochastic programming is separable, but you may or may not want to have special support for different types of objective functions (e.g., mean, mean plus variance, conditional value at risk) or constraints (e.g., conditional value at risk again, chance constraints). Depending on how you go about solving the stochastic program, you might need to consider how to encode the probability measures, as in a stochastic collocation/polynomial chaos approach.
>
> For PDE-constrained optimization, there is the full-space/reduced-space axis (aka the SAND/NAND axis).
>
> There can also be many special cases for certain problem classes. In machine learning, first-order algorithms are good enough in many cases, and certain problem formulations occur often enough to have their own solver algorithms (least squares type problems, l1-regression, compressed sensing).
>
> The last axis I can think of is the single versus multiple processor axis for different algorithms, if you’re interested in having more efficient single-processor (or direct solver) variants of algorithms. The SQP solver I wrote for TAO is probably crap if you set the KSP to PREONLY and the PC to LU with any mat solver that can tolerate zeros on the diagonal. Specializations of those algorithms would be useful for smaller problems if you want that capability in TAO; I wouldn’t blame you if you said instead that users should just use an off-the-shelf solver instead. These sorts of specializations would also come up for linear programs, quadratic programs, and their mixed-integer counterparts, where many specializations are useful for the single processor case, and have unclear (or definitely zero) utility in multiprocessor, distributed-memory settings.
>
> Geoff
>
>>
>>
>> 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.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
More information about the petsc-dev
mailing list