lamssi(7)

πŸŽ€ lamssi(7) β€” LAM SSI OVERVIEW πŸŽ€

okay bestie, pull up a chair (or like, a terminal, same thing) because we're doing lamssi(7) and honestly? it's giving ✨ infrastructure ✨. this is your intro to the LAM System Services Interface, aka SSI. let's get into it πŸ’…


🌸 NAME 🌸

lamssi β€” introduction to LAM System Services Interface (SSI)


πŸ’– DESCRIPTION πŸ’–

so the SSI in LAM/MPI is the whole vibe-check system that lets you select one (or more) system services interfaces at run-time. that's it, that's the pitch. run-time choices, no recompiling, iconic behavior fr fr 🫢


πŸ¦‹ OVERVIEW πŸ¦‹

LAM SSI instances are uniquely described in terms of "kinds" (also referred to as "types") and "modules". two little words, so much power 😭

  • The "kind" refers to which set of system services the SSI instance will apply to. For example, LAM currently has several kinds: boot, coll, cr and rpi.
  • The "module" refers to a specific SSI instance of a given kind. Each kind has o
yes, that sentence really does just stop at "Each kind has o" in the original. we don't gatekeep, we just report the lore exactly as it was handed to us πŸ’€

and now the kinds themselves, one by one:

  • boot modules are used to start the LAM run-time environment (i.e., they provide the back-end functionality to lamboot(1)). boot modules are discussed further in the lamssi_boot(7) man page.
  • coll modules provide back-end algorithms and functionality for the MPI collective communications. coll modules are described in lamssi_coll(7).
  • cr modules provide checkpoint/restart functionality for MPI jobs. See lamssi_cr(7) for details.
  • rpi modules provide back-end functionality for MPI point-to-point communications. rpi modules are detailed in lamssi_rpi(7).

✨ VERBOSE OPERATION ✨

you can force SSI modules to be verbose β€” main character energy, tell us everything β€” either by setting the LAM_SSI_ssi_verbose environment variable before invoking mpirun, or by using the -ssi command line switch to mpirun. for example:

mpirun -ssi ssi_verbose 1 C foo
Tell the SSI modules to be verbose, and default to sending their output to stderr.

The ssi_verbose kind is a "pseudo-kind" in that it is used to pass parameters to the main SSI meta-glue itself β€” not to any particular kind. It can take many different parameters to format where and how the verbose output will be sent (note that at least one parameter must be specified, even if it is an invalid parameter 😭). Any combination of the following parameters may follow the ssi_verbose kind (separated by commas):

  • syslog β€” Send the verbose output to the syslog.
  • syslogpri:<priority> β€” Set the syslog output priority to <priority>. Using this paramter implies the syslog parameter. The default priority is info (LOG_INFO). Valid <priority> values are: notice (LOG_NOTICE), info, and debug (LOG_DEBUG).
  • syslogid:<id> β€” Use the ID <id> for the syslog prefix.
  • stdout β€” Send the verbose output to stdout.
  • stderr β€” Send the verbose output to stderr.
  • file[:<filename>] β€” Send the verbose output to a file in the LAM per-user, per-node meta information directory (usually located in /tmp). If <filename> is specified, send the output to the file named lam-<filename>. If <filename> is not specified, send the output to the file named lam-ssi.txt.
  • fileappend β€” Append to the file when sending the verbose output (create the file if it does not exist). If this parameter is not given, if the file already exists, it will be overwritten. Using this parameter implies the file parameter.
  • level:vlevel β€” Indicate the specific verbosity level to be used. Although the specific meaning of the verbosity level is left up to individual SSI modules, generally negative numbers mean no verbose messages, 0 means a minimal set of messages, and positive numbers mean more messages (the greater the positive number, the more output messages will be generated). If left unspecified any any other ssi_verbose parameters are specified, the default level of 0 is used.

If multiple parameters are passed in ssi_verbose, the output will be directed as implied by all the parameters. If no valid parameters are passed (e.g., a single invalid parameter is passed), then output will be directed to stderr by default.

Also note that as with all SSI parameters, all of these values may be passed by setting the environment variable LAM_SSI_ssi_verbose before invoking mpirun. However, parameters passed through "-ssi ssi_verbose" will take precedence over environment variables. the command line is the louder bestie, periodt πŸ‘‘


🌈 EXAMPLES 🌈

1. ok so:

mpirun -ssi ssi_verbose 1 C foo

Since no valid parameters were passed, the verbose output will be sent to stderr.

2. and then the glow-up version:

mpirun -ssi ssi_verbose file:output.txt,syslogpri:notice C foo

Send the verbose output to both the file lam-output.txt in the LAM user meta directory as well as to the syslog with a priority of LOG_NOTICE. double the destinations, double the drama πŸŽ€


πŸ’œ SEE ALSO πŸ’œ

lamssi_boot(7), lamssi_coll(7), lamssi_cr(7), lamssi_rpi(7), mpirun(1), lamboot(1), recon(1), lamwipe(1), LAM User's Guide


and that's the whole page bestie!! πŸ¦‹ this one's from LAM 7.1.4, dated July, 2007 β€” vintage but still slaying, no cap πŸ’…πŸ’– go forth and be verbose, you've got this 🫢✨