On Jan 15, 2014, at 6:56 PM, Blaise A Bourdin <bour...@lsu.edu> wrote:
> > On Jan 15, 2014, at 5:26 PM, Barry Smith <bsm...@mcs.anl.gov> wrote: > >> >> On Jan 15, 2014, at 4:32 PM, Jed Brown <j...@jedbrown.org> wrote: >> >>> Barry Smith <bsm...@mcs.anl.gov> writes: >>>> To change this we would need to introduce a way of tracking >>>> alreadyprinted per class and per prefix instead of per object. It >>>> is unlikely we will change this. We recommend not using >>>> VecSetFromOptions() and MatSetFromOptions() in real applications >>> >>> We really have to do something about the repeated Vec and Mat help when >>> there is no prefix. This is by far the most important case. >> >> Hmm, do we even want people calling VecSetFromOptions() and >> MatSetFromOptions()? Especially for more than 1 or 2 “master” items which >> will have different prefixes anyways. I don’t think we want calls to >> VecSetFromOptions() and MatSetFromOptions() from within other PETSc classes >> (except for possible a single master item) that is controlled from for >> example a DM. > > That makes a lot of sense, but when Vecs are created from a Mat or a DM, the > call to VecSetFromOptions serves a purpose. In particular, it does the call > to VecSetType. How do I get the VecType from a DM? DMSet/GetMatType() and DMSet/GetVecType() -dm_mat_type -dm_vec_type note that these will only print one message for each dm. Note also that if you have a SNES, KSP, PC, or Mat lying around it is better call KSPGetVecs() or MatGetVecs() instead of using VecCreate() since the KSP or Mat make sure to provide the Vec with the right layout. > > Blaise > > -- > Department of Mathematics and Center for Computation & Technology > Louisiana State University, Baton Rouge, LA 70803, USA > Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 > http://www.math.lsu.edu/~bourdin
