<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">
<br>
</div></div>This doesn't make sense to me. 2 issues you raise:<br>
<br>
1 *intentionally* create a .petscrc.<br>
<br></blockquote><div><br></div><div>I was not clear.  People put a .petscrc file temporarily in their home directory, not thinking that it will be used by PETSc, but just as a place to store the file. I never use a non-default PETSc parameter all of the time (like malloc_dubeg) so don't use a ~/.petscrc file. FORTRAN users can not, or do not, use command line arguments so the .petscrc file is large and has all arguments.<br><br></div><div>So I meant the do not create it as a RC file but just as a place to store a copy of the file.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2. use $HOME as scratch and stage files from other machine or e-mail<br>
[an extremely bad practice isrrespective of using petsc or not] - but<br>
they'll *never* stage .bashrc from the other machine.<br>
<br>
With either of these claims the said user is using .petscrc [either on<br>
current machine or the other machine from where he/she staged files<br>
over] so your claim of 'Satish is the only .petscrc' user is false.<br>
<br>
Note: I don't believe the exception to .bashrc you claim. I know folks<br>
usually copy their prefered .bashrc (or copy/paste whole chunks) to<br>
any new machine accounts they get - instead of starting to configure<br>
such a thing from scratch.<br></blockquote><div><br></div><div>Yes, you may copy a whole .bashrc file to a new machine, if there is no .bashrc file provided, but you know what you are doing because a .bashrc file *only* lives in $HOME.<br><br></div><div>On the other hand me and my users use .petscrc file *only* for command line stuff that we must do with files.  So a .petscrc file *never* lives in $HOME except as a scratch space.<br><br></div><div>You and I have different work flows.  You looks at it as a .xxxrc file and we look at it as command line parameter file.  We just use these files in very different ways and your ~/.petscrc is catastrophic for us.<br><br>If I am in the minority and the catastrophic failure mode of having unknown PETSc parameters sucked in does not out weigh the inconvenience of users moving away from ~/.petscrc then that is fine -- I just want you to know that this bites us badly sometimes and I suspect that I am not the only one.  Again, if I am the only one I can suck it up, I just want you to know that I am sad.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Anyway - I think Jed's suggestion of adding the 'source' of any<br>
used/unused options to -options_table/-log_summary is a good<br>
compormise..<br>
<span class=""><font color="#888888"><br>
Satish<br>
</font></span><div class=""><div class="h5"><br>
><br>
> At this point is is not clear that we even need to get past (1).<br>
><br>
> Mark<br>
><br>
<br>
</div></div></blockquote></div><br></div></div>