Draft: TaoPD - Problem Description
TaoPD - Problem Description.
This newly introduced TaoPD
object represents frequently used primal objects in optimization.
This can be thought of as either regularization, closed-convex-set constraint, or a building-block for multiple-dispatch for proximal algorithms.
One can use TaoPD
object as either a regularizer to complement existing Tao
object. For such application, one can checkout src/tao/unconstrained/tutorials/cg_reg.c
. If one wants to use TaoPD
as a regularizer, one simply has to call TaoSetRegularizer(Tao, TaoPD)
.
Also, one can use two TaoPD
objects to solve a proximal algorithm - \min f(x) + g(x,y)
, via TaoApplyProximalMap()
function, where each functions, f,g
, are represented via individual TaoPD
objects. Examples can be seen in src/tao/unconstrained/tutorials/prox_ex.c
.
One can also solve proximal algorithm via TaoSolve()
, by setting TaoPD
terms into Tao
. In this case, the TaoType
would be TAOPROX
- which is merely a vessel to call TaoApplyProximalMap()
(Q: Is this feature needed? See discussion below)
To use TaoSolve()
for TAOPROX
, one first needs to call TaoSetTotalNumPD(Tao, PetscInt)
, and then set those two TaoPD
objects via TaoSetPDTerm(Tao, TaoPD, PetscInt)
, and then solve it.
Currently, L1, L2, and Simplex are implemented for TaoPD
.
Note: I am uncertain about how I create list of TaoPD
objects and store them. Currently, I have
struct _p_Tao{
...
PetscInt num_terms;
TaoPD *pds;
TaoPD reg;
}
and user has to call TaoSetTotalNumPD(Tao tao, PetscInt i)
first, which does PetscMalloc(i, &tao->pds);
, and then set TaoSetPDTerm(Tao tao, TaoPD pd, PetscInt i);
, which does `tao->pds[i] = pd'
Is this an acceptable Petsc-practice to initialize list of objects with unknown length??
The act of submitting a merge request will be understood as an affirmation of the Developer’s Certificate of Origin 1.1 at https://petsc.org/release/install/license/
See https://petsc.org/release/developers/integration/ for instructions on preparing and submitting a merge request. If the merge request is not from a fork, then you must
- List yourself as assignee
- List one or more reviewers
- Select labels including liking workflow::Review
For merge request from a fork
- make sure the fork is not
private
- gitlab MR process (pipelines, merge) breaks with it. - cc: one of the developers in the MR description who can shepherd the MR