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

Wed Apr 26 17:20:13 CDT 2017

In The Hitchhiker's Guide to the Galaxy, Douglas Adams mentions an extremely dull planet, inhabited by a bunch of depressed humans and a certain breed of animals with sharp teeth which communicate with the humans by biting them very hard in the thighs. This is strikingly similar to UNIX, in which the kernel communicates with processes by sending paralyzing or deadly signals to them. Processes may intercept some of the signals, and try to adapt to the situation, but most of them don't.

> On Apr 26, 2017, at 5:17 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> 
> 
>  Another "solution" :-)
> 
> ./ex5 -help | (head  ; cat > /dev/null) 
> 
> 
>> On 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.  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/documentation/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
> 