[petsc-users] nondeterministic behavior with ./program -help | head
Jed Brown
jed at jedbrown.org
Wed Apr 26 18:39:45 CDT 2017
Barry Smith <bsmith at mcs.anl.gov> writes:
>> On Apr 26, 2017, at 5:44 PM, Jed Brown <jed at jedbrown.org> wrote:
>>
>> PETSc is the only package I know for which "./app -help" does everything
>> that "./app" would do, with extra output. It is an unfortunate
>> consequence of extensibility that we can't exit immediately. What if we
>> had a function the user could call to exit early and cleanly after all
>> options have been processed? Maybe something like:
>>
>> PetscInitialize
>> ...
>> if (PetscHelpActive()) {
>> TSSetDuration(ts,1,PETSC_DEFAULT);
>> PetscExitSilently();
>> }
>>
>> where PetscExitSilently doesn't print -malloc or -log_view or the like.
>
> Yuck!
This isn't something we would use in examples, but is something some
applications might prefer. I agree it's not elegant, but don't know how
else to get anything like normal behavior (perhaps that's okay).
>> We should probably also have "-help snes,ksp_fieldsplit" that would only
>> print help for options with those prefixes.
>
> This would be useful.
>>
>> Barry Smith <bsmith at mcs.anl.gov> writes:
>>
>>> Ed
>>>
>>> I think want you want is something like
>>>
>>> ./program -intro
>>>
>>> that causes the help message to PetscInitialize() to be printed and then have the program end.
>>>
>>> We can add this, -intro is not a great name, any idea for a better name?
>>>
>>> Barry
>>>
>>>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20170426/9c6872ab/attachment.pgp>
More information about the petsc-users
mailing list