Section: User Commands (1)
Package: RenderMan Artist Tools
alfred - distributed execution/rendering dispatcher (also monitor, maitre_d, and nimby)
is a distributed task management tool, primarily intended for use with
Pixar's RenderMan Artists Tools to launch and track renderings.
The optional file argument specifies either a list of RIB files to
be rendered, or an alfred
or control script (these are typically generated by an application such as
see the accompanying detailed documentation).
The alfred executable can run in several modes, these are typically
transparent to the user, although their distinctions may be of interest
to administrators or developers. Typically the program is launched as
(e.g. from the command line or from the
This invocation calls fork(2) and becomes two independent
(communicating) processes, one of which is the graphical user-interface,
The other fork becomes the
which is the background process that actually launches and tracks the
specified tasks in the script. The dispatcher process only exits when
its queue of spooled jobs has been successfully processed. The monitor
(UI) can be closed down at any time, and restarted later without affecting
the dispatcher (launching alfred with no arguments just starts a UI).
The dispatcher fork also resets its process group ID [see
and therefore will continue executing after logout.
If a dispatcher is already running,
then newly launched alfreds will only
any specified scripts and then simply connect as monitors. If both a
monitor and dispatcher are already running, then additional alfreds
just spool their specified files to the running dispatcher and exit
(they also send a signal to the running monitor indicating that it
should raise to the front of the window stack).
It is also possible to connect an alfred monitor to a dispatcher
running on a remote machine, to check on the status of jobs there.
If alfred is launched in
mode, it becomes a network-wide daemon that arbitrates remote
server requests and enforces a priority scheme.
Finally, alfred can be launched in
mode (not-in-my-back-yard), in which case it contacts the system
maitre_d and requests a temporary block on the use of the invoking
workstation as a remote server (i.e. other alfred users on the network
are blocked from sending jobs to the system running nimby). In this
mode alfred produces a small desktop UI which indicates, and controls,
its server status.
print a brief summary of invocation options.
print version information (and exit).
start up in paused mode, to allow preference changes, etc.
If there are also job filename arguments specified later on
the command line, then only the newly spooled jobs will be paused,
otherwise all current jobs are paused.
if dispatcher is currently paused, resume dispatching.
explicitly start the dispatcher, rather than implicitly starting
a dispatcher (fork) when the first job is spooled or first UI is
dispatcher won't exit, even when there are no jobs on its queue
(used with the -dispatch option to keep a dispatcher running at
start the not-in-my-back-yard monitor, an interface
to the maitre_d which keeps jobs off the local host when it is idle.
start the (optional) network-wide server arbitration daemon
send the named files to the dispatcher for processing, but do not
start a monitor (i.e. spooling with no user-interface).
keep the alfred process in the foreground, usually it forks and
immediately returns control to the calling shell.
- -after date
delays the start of job processing until the given time; the job
is spooled and placed on the queue, but no processing occurs until
after the date specified; dates are of the form 'month day hour:minute'
or for times later on the same day 'hour:minute' (up until midnight).
Note that the date contains spaces and so must be quoted to appear
as a single argument to the shell. Hours should be given as for a
24-hour clock. For example to delay a job until
June 23 at 1:45PM, use: alfred -after '6 23 13:45' files...
- -log file
redirect log messages to the named file instead of the console.
- -geom xgeom
initial window placement geometry, in the form WxH+X+Y.
- -nbg xcolor
NIMBY-mode window background color,
as #rrggbb or
- -nrv xcolor
NIMBY-mode window reverse color, when jobs exist.
- -tags taglist
additional global/local limit tags which will be appended to the
tag list associated with each Cmd in the worklist.
- -service expr
additional remote server selection keys (as a logical expression)
which will be ANDed with the service expression
associated with each Cmd in the worklist.
- -pbias bias
specifies a positive or negative offset value,
which will be applied to the default per-Crew server priority
defined in the alfred.schedule file. The resulting value
is used by the maitre-d when deciding how to assign servers to
competing jobs from different users. Each dispatcher will tend to get
remote servers in proportion to their priority, relative to that of
other users. Note that this priority value only affects remote server
assignments in active jobs; the order in which jobs are processed is
determined by their position in their dispatcher's job queue. See the
discussion in the documentation for more details.
- -crews crewlist
specifies the list of Crews to be used when determining remote server
access; applies to users who are members of multiple crews but who want
a particular job to execute with a restricted set of server access
permissions. Crews listed here but which don't apply to the user are
ignored. If the list is empty, then the default list is derived from
explicitly attempt to acquire the unlimited-fanout dispatch license.
- -h [user@]host
connect as a monitor (only) to the dispatcher running for
This allows a local user-interface to a remote job queue. Authentication
is similar to rlogin(1) and hence local users must have login privileges
on the remote system. Access will be view-only unless the local user is
listed in the remote user's .rhosts file. If
is not specified, the local userid is used. Note: this option specifies
the identity (owner) of the dispatcher to locate on the remote system.
- -l login
(in conjunction with -h above) connect to remote system as the user
instead of using the local user name (the default).
- -n maxservers
attempt to bind at most
remote servers to each command which requests them (e.g. netrender).
The default is one server per command. This option is primarily intended
for use with RIB files named on the command line (e.g. bucket-parallel
- -n min,max
bind at least
and at most
remote servers to each command.
use prefixes of input filenames to construct a
processing hierarchy, for *.rib arguments
remove successfully rendered RIB files. Note: this applies only to RIB
files whose names are given as additional arguments to the same invocation
of alfred (e.g. alfred -rm *.rib).
prompts for the new wrangler-mode password.
Automatic Window Placement
The alfred UI windows tend to remember their placements from one
invocation to the next, which is generally considered a feature.
In most cases the window geometries are part of the information
stored in the ~/.pixarPrefs/alfred.prefs file; removing this file
will effectively reset all the preferences, including window placement.
It is often desirable to make the
user-interface (a small window containing a single push-button),
a part of a user's standard login desktop; if alfred receives
a save-yourself message from the window manager (as often happens
during a standard X11 logout), it arranges for its current location
to become part of the desktop re-invocation parameters; i.e. it'll
start in the same place when the user logs in next. Also, for
aesthetic reasons, it can be nice to have the nimby button displayed
without the usual window manager titlebars etc; to achieve this in the
typical X11 environment, place the following line in ~/.Xresources
(and remember, on default SGI systems you can bring up the window
manager control menu (move/resize/etc) by using Alt-Spacebar).
When alfred is invoked as
alfred -nametree *.rib
the RIB file names are analyzed to generate a hierarchy of
processing dependencies. For example, shadow map files might need
to be rendered before the final frame file which requires them.
The scheme uses a convention in which shared prefixes on filename
imply a depth in the hierarchy. Files whose names occur as
the leading portion of another (longer) filename are considered
to be above the longer-named file in the processing hierarchy.
In addition, alphabetical sorting is used to determine sibling orders.
Before name comparisons begin, any trailing ".rib" suffix is removed.
For example, the files: frame07.rib, frame07.shd.A.rib, frame07.shd.B.rib
would be placed into a worklist script such that shd.A and shd.B would
render (in parallel) before frame07.rib is rendered. This is because
the string "frame07" is the first part of each of the other two file
The alfred configuration and startup files are located in
(if the environment variable RATTREE isn't defined, the default value is
or for some files, $RMANTREE or /usr/local/prman).
the system-wide default settings for preferences and tunable parameters.
the system-wide definition of which remote servers are available to client
applications launched by alfred. This file also defines any user or
time-of-day access restrictions to the remote servers. Typically this
file is writable only by a production coordinator or whoever is organizing
this directory contains icons and data used by the program.
the text of balloon help messages, and the names used by the UI to
display tasks states (e.g. Blocked, Ready, Active, etc). Some sites
might want to modify this file to reflect the local environment
the default location of the spooling directory, holds spooled scripts, checkpoint versions of executing scripts, and other temporary files.
user-specific preference settings (in each home directory).
These are overrides for a subset of the parameters set in
each dispatcher records its process-id and UI communications port number
in this file; it serves as both a lock to prevent multiple dispatchers
from being started for each new job (per user), and as a place to record
the port used for spooling and UI updates.
each running UI records its process-id, this acts as a lock to prevent
multiple UI windows from being started for a single user (per local machine
per remote dispatcher).
recorded process-id of any alfred running in nimby mode.
Some diagnostic messages (from daemonized dispatchers or maitre_d's)
go to /dev/console, which is often not the same as
the shell window from which alfred was started.
combiner(1), netrender(1), alfserver(1), render(1),
David Laur & Dana Batali
- SEE ALSO
Pixar Animation Studios
(510) 752-3000 (voice)
(510) 752-3151 (fax)
Copyright © 1996-
Pixar. All rights reserved.
RenderMan® is a registered trademark of Pixar.