[petsc-users] printing help

[Barry Smith]

On Jan 15, 2014, at 6:56 PM, Blaise A Bourdin <bourdin at lsu.edu> wrote:

> 
> On Jan 15, 2014, at 5:26 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> 
>> 
>> On Jan 15, 2014, at 4:32 PM, Jed Brown <jed at jedbrown.org> wrote:
>> 
>>> Barry Smith <bsmith at 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