[petsc-dev] related to compiling your source code

Mark Adams mfadams at lbl.gov
Wed Apr 15 15:02:01 CDT 2015

> 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
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20150415/7ea95b14/attachment.html>

More information about the petsc-dev mailing list