To address "The --help output needs to be made (much) better" I'd like
to suggest that --help and -h each give the same BRIEF summary of under
24-lines of 80-column text. Additionally implement --help=[topic] to
give more info on related groups of options. Of course, -h and --help
would list the valid "topic" values in their brief output.
Just my USD 0.02
-Paul
P.S. arguments is misspelled in the subject line :-)
On 4/21/2011 3:52 PM, Ralph Castain wrote:
Might help if you were to list those CLI params you believe to be removable
and/or those you propose to deprecate.
Just a quick glance: I don't see any options that are defunct, though we could
argue about how many people use them. So perhaps what we discussed - having a
short response for -h that lists the most commonly used ones, and a longer
response to --help that contains them all - might be more appropriate?
On Apr 21, 2011, at 9:51 AM, Jeff Squyres wrote:
WHAT: Deprecate a bunch of old mpirun CLI parameters, remove *most*
"single dash" long mpirun options, make "mpirun --help" much
more user friendly
WHY: `mpirun --help` is currently 232 lines of output. *Ouch*
Additionally, the Josh/Terry/Jeff affinity re-work will end up
creating new mpirun CLI options and deprecating the old ones.
WHEN: Maybe late in the 1.5 series (the new affinity stuff is
tentatively scheduled for late in the 1.5 series). 1.7 for
sure.
WHERE: Mostly in orte/tools/orterun/
TIMEOUT: ORNL face-to-face OMPI meeting (May 3)
-----
MORE DETAILS:
We simply have too many options to mpirun.
- Some could be removed
- Some should be removed
- Some should be deprecated (but still available)
- The --help output needs to be made (much) better
The new mapping/affinity options effectively replace a bunch of the
old options. The old mapping/affinity options should be deprecated in
favor of the new stuff.
Additionally, there are at least a few old orterun options that are
either only of interest to developers and/or have an MCA parameter
backing them (and are fairly uncommonly used such that the MCA param
could be used instead).
Finally, we have many options that are available via both "-foo" and
"--foo" (mostly for hysterical raisins). In most cases, the
single-dash version should be removed -- per GNU conventions, long
names should only be available via double-dash. There are a small
number of single-dash options that must be retained, however, for
compatibility with other MPI implementations and for mpiexec options
specifically listed in MPI-2.2:
-np, -host, -hostfile, -machinefile, -wd, -wdir, -path
I propose:
1. Remove all other single-dash long name options.
2. Make all deprecated options only available if the user
specifies --deprecated-options on the command line (or invokes mpirun
via mpirun.deprecated-options).
--> This allows users to keep their existing scripts that use
deprecated options, but with a glaring signal that "hey, this
option you're using may disappear in a future version!"
3. Revamp the --help output to show a short listing of the most common
options, and a note that a) the mpirun(1) man page offers much more
detail, and b) --help-all shows the original, exhaustive CLI option
listing.
Extra bonus points would be given for anyone who'd like to implement
an svn/hg-like "help" command, perhaps something like:
mpirun help machinefile
...help output specifically about the machinefile option...
I don't have time to do this last part, but it would be a great
usability feature.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
