That's good to know thanks. I have another question somewhat related. In that quadratic programming problem I have shown earlier, my K matrix is of global size *Ndof* by *Ndof* where *Ndof* is number of free dofs (for instance, if I have a 2x2 quadrilateral mesh and want to evaluate concentration at all the verticies, I will have nine total dofs but if I have Dirichlet constraints all along the boundary, only my center vertex is free so *Ndof* = 1. Thus when I simply call DMCreateMatrix(...) it would give me a 1x1 matrix.)
However, I want my M constraint matrix to be of size *Nele* by *Ndof* where *Nele* is the total number of elements. How would I create this matrix? Because ultimately, I am subjecting all of my free u's to *Nele* number of equality constraints, and if possible I want this M matrix to be compatible with the layout from Vec u. On Wed, Jul 30, 2014 at 2:03 PM, Matthew Knepley <[email protected]> wrote: > On Wed, Jul 30, 2014 at 2:53 PM, Justin Chang <[email protected]> wrote: > >> Hi, >> >> This might be a silly question, but I am developing a finite element code >> to solve the non-negative diffusion equation. I am using the DMPlex >> structure and plan on subjecting the problem to a bounded constraint >> optimization to ensure non-negative concentrations. Say for instance, I >> want to solve: >> >> min || K*u - F ||^2 >> subject to u >= 0 >> M*u = 0 >> >> Where K is the Jacobian, F the residual, u the concentration, and M some >> equality constraint matrix. I know how to do this via Tao, but my question >> is can Tao handle Mats and Vecs created via DMPlex? Because from the SNES >> and TS examples I have seen in ex12, ex62, and ex11, it seems there are >> solvers tailored to handle DMPlex created data structures. >> > > Yes, TAO can handle objects created by DMPlex since they are just Vec and > Mat structures. The additions > to ex12, ex62, and ex11 concern the callbacks from the solver to the > constructions routines for residual and > Jacobian. Right now, none of the callbacks are automatic for TAO so you > would have to code them yourself, > probably by just calling the routines from SNES or TS so it should not be > that hard. We are working to get > everything integrated as it is in the other solvers. > > Thanks, > > Matt > > >> Thanks, >> Justin >> > > > > -- > 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 >
