[petsc-users] nondeterministic behavior with ./program -help | head

Wed Apr 26 16:40:21 CDT 2017

On Wed, Apr 26, 2017 at 4:30 PM, Ed Bueler <elbueler at alaska.edu> wrote:

> > Is  ./ex5 -help -no_signal_handler  | head  good enough?
>
> Umm.  It eliminates the nondeterminism.
>

I do not think this is non-determinism. When head ends it generates a
SIGPIPE (by closing the pipe) to notify the application behind the pipe
that its done.
This is deterministic. You want PETSc to ignore SIGPIPE, which is bad in
general. Thus we want you to use an option to say so. You could always use
something
other than 'head' which eats the rest of the pipe input.

   Matt

> Should discovery of options for petsc user applications go via error
> messages?  (Or asking users to remember "-no_signal_handler" to avoid?)  I
> don't understand signal handling well-enough to recommend a better way ...
> maybe there is no better way for |head.
>
> The best alternative I can think of is if my codes supply the program name
> for the "const char man[]" argument of PetscOptionsXXX().  Then I can
> suggest this to users:
>
> ./program -help |grep program
>
> Is this a mis-use of the "man" argument?
>
> Ed
>
> PS  Amused to find "This routine should not be used from within a signal
> handler." in the man page for MPI_Abort(), which I reached by clicking on
> the call to MPI_Abort() in the view of PetscSignalHandlerDefault().  ;-)
>
>
> On Wed, Apr 26, 2017 at 12:55 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
>>
>> Is
>>
>> ./ex5 -help -no_signal_handler  | head
>>
>> good enough?
>>
>> Normally we won't want to turn off catching of PIPE errors  since it
>> might hide other errors.
>>
>> Barry
>>
>>
>>
>> > On Apr 26, 2017, at 3:31 PM, Ed Bueler <elbueler at alaska.edu> wrote:
>> >
>> > Dear Petsc --
>> >
>> > Copied at the bottom is the behavior I get for ex5.c in snes
>> examples/tutorials.  When I do
>> >
>> > $./ex5 -help |head
>> >
>> > I get a "Caught signal number 13 Broken Pipe" or just a version
>> string.  Randomly, one or the other.
>> >
>> > I know this has come up on petsc-users before:
>> >     http://lists.mcs.anl.gov/pipermail/petsc-users/2014-May/021848.html
>> > The claim was that the SIGPIPE error is standard behavior.
>> >
>> > My real issue (feature request?) is that when writing a petsc
>> application I want a rational help system.  Suppose "program.c" has options
>> with prefix "prg_".  The user doesn't know the prefix yet (I could have
>> used "prog_" as the prefix ...)  The petsc-canonical help system is (I
>> believe)
>> >
>> > ./program -help |grep prg_
>> >
>> > for program.c-specific options.  Works great if you know to look for
>> "prg_".  My plan for my applications is to put the prefix in the first line
>> or two of my help string, the user can discover the prefix by
>> >
>> > ./program -help |head
>> >
>> > and then use "-help |grep -prg_" and etc.
>> >
>> > So my question is:  Can petsc be set up to not generate an error
>> message when the help system is used in a correct way?  (I.e. catching
>> return codes when writing, or handling SIGPIPE differently?)  Or, on the
>> other hand, can someone suggest a better help system that irritates less?
>> >
>> > Thanks!
>> >
>> > Ed
>> >
>> > ~/petsc/src/snes/examples/tutorials[master*]$ ./ex5 -help |head
>> > Bratu nonlinear PDE in 2d.
>> > We solve the  Bratu (SFI - solid fuel ignition) problem in a 2D
>> rectangular
>> > domain, using distributed arrays (DMDAs) to partition the parallel grid.
>> > The command line options include:
>> >   -par <parameter>, where <parameter> indicates the problem's
>> nonlinearity
>> >      problem SFI:  <parameter> = Bratu parameter (0 <= par <= 6.81)
>> >
>> >   -m_par/n_par <parameter>, where <parameter> indicates an integer
>> >        that MMS3 will be evaluated with 2^m_par,
>> 2^n_par-----------------------------------------------------
>> ---------------------
>> > Petsc Development GIT revision: v3.7.6-3453-ge45481d470  GIT Date:
>> 2017-04-26 13:00:15 -0500
>> > [0]PETSC ERROR: ------------------------------
>> ------------------------------------------
>> > [0]PETSC ERROR: Caught signal number 13 Broken Pipe: Likely while
>> reading or writing to a socket
>> > [0]PETSC ERROR: Try option -start_in_debugger or
>> -on_error_attach_debugger
>> > [0]PETSC ERROR: or see http://www.mcs.anl.gov/petsc/d
>> ocumentation/faq.html#valgrind
>> > [0]PETSC ERROR: or try http://valgrind.org on GNU/linux and Apple Mac
>> OS X to find memory corruption errors
>> > [0]PETSC ERROR: likely location of problem given in stack below
>> > [0]PETSC ERROR: ---------------------  Stack Frames
>> ------------------------------------
>> > [0]PETSC ERROR: Note: The EXACT line numbers in the stack are not
>> available,
>> > [0]PETSC ERROR:       INSTEAD the line number of the start of the
>> function
>> > [0]PETSC ERROR:       is given.
>> > [0]PETSC ERROR: [0] PetscVFPrintfDefault line 240
>> /home/ed/petsc/src/sys/fileio/mprint.c
>> > [0]PETSC ERROR: [0] PetscHelpPrintfDefault line 622
>> /home/ed/petsc/src/sys/fileio/mprint.c
>> > [0]PETSC ERROR: [0] PetscOptionsBegin_Private line 29
>> /home/ed/petsc/src/sys/objects/aoptions.c
>> > [0]PETSC ERROR: [0] PetscObjectOptionsBegin_Private line 61
>> /home/ed/petsc/src/sys/objects/aoptions.c
>> > [0]PETSC ERROR: [0] PetscDSSetFromOptions line 218
>> /home/ed/petsc/src/dm/dt/interface/dtds.c
>> > [0]PETSC ERROR: [0] DMSetFromOptions line 747
>> /home/ed/petsc/src/dm/interface/dm.c
>> > [0]PETSC ERROR: --------------------- Error Message
>> --------------------------------------------------------------
>> > [0]PETSC ERROR: Signal received
>> > [0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html
>> for trouble shooting.
>> > [0]PETSC ERROR: Petsc Development GIT revision:
>> v3.7.6-3453-ge45481d470  GIT Date: 2017-04-26 13:00:15 -0500
>> > [0]PETSC ERROR: ./ex5 on a linux-c-dbg named bueler-leopard by ed Wed
>> Apr 26 11:22:07 2017
>> > [0]PETSC ERROR: Configure options --download-mpich --with-debugging=1
>> > [0]PETSC ERROR: #1 User provided function() line 0 in  unknown file
>> > application called MPI_Abort(MPI_COMM_WORLD, 59) - process 0
>> > [unset]: aborting job:
>> > application called MPI_Abort(MPI_COMM_WORLD, 59) - process 0
>> > ~/petsc/src/snes/examples/tutorials[master*]$ ./ex5 -help |head
>> > Bratu nonlinear PDE in 2d.
>> > We solve the  Bratu (SFI - solid fuel ignition) problem in a 2D
>> rectangular
>> > domain, using distributed arrays (DMDAs) to partition the parallel grid.
>> > The command line options include:
>> >   -par <parameter>, where <parameter> indicates the problem's
>> nonlinearity
>> >      problem SFI:  <parameter> = Bratu parameter (0 <= par <= 6.81)
>> >
>> >   -m_par/n_par <parameter>, where <parameter> indicates an integer
>> >        that MMS3 will be evaluated with 2^m_par,
>> 2^n_par-----------------------------------------------------
>> ---------------------
>> > Petsc Development GIT revision: v3.7.6-3453-ge45481d470  GIT Date:
>> 2017-04-26 13:00:15 -0500
>> > ~/petsc/src/snes/examples/tutorials[master*]$
>> >
>> >
>> > --
>> > Ed Bueler
>> > Dept of Math and Stat and Geophysical Institute
>> > University of Alaska Fairbanks
>> > Fairbanks, AK 99775-6660
>> > 301C Chapman
>>
>>
>
>
> --
> Ed Bueler
> Dept of Math and Stat and Geophysical Institute
> University of Alaska Fairbanks
> Fairbanks, AK 99775-6660
> 301C Chapman
>

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20170426/3540bb5f/attachment-0001.html>