> > This doesn't make sense to me. 2 issues you raise: > > 1 *intentionally* create a .petscrc. > > 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.
So I meant the do not create it as a RC file but just as a place to store a copy of the file. > 2. use $HOME as scratch and stage files from other machine or e-mail > [an extremely bad practice isrrespective of using petsc or not] - but > they'll *never* stage .bashrc from the other machine. > > With either of these claims the said user is using .petscrc [either on > current machine or the other machine from where he/she staged files > over] so your claim of 'Satish is the only .petscrc' user is false. > > Note: I don't believe the exception to .bashrc you claim. I know folks > usually copy their prefered .bashrc (or copy/paste whole chunks) to > any new machine accounts they get - instead of starting to configure > such a thing from scratch. > 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. 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. 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. 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. > Anyway - I think Jed's suggestion of adding the 'source' of any > used/unused options to -options_table/-log_summary is a good > compormise.. > > Satish > > > > > At this point is is not clear that we even need to get past (1). > > > > Mark > > > >
