the parameter file autm.param is created automatically with default values, if it does not exist. the parameter file defines which version of tempmap to use, the name of the abundance and atmosphere files (which have to be in the same directory as the tempmap input file), the reference speed, the load-average threshold, the check-again time (which determines how often the hosts are checked, instead of using the recorded values from the previous check), it contains parameters for day time, night time and weekend distinction, defines the mode of determining the maximum load-average level and some more.

for heavy tempmapping, you might want to add all available linux hosts to the host list. unfortunately, checking a large number of hosts requires a displeasingly high amount of time (about one minute per 50 hosts). there are several ways to work around this: the check frequency can be automatically reduced for night time and weekend use and increased for peak times. if you are about to submit just a small number of jobs, you can restrict the number of hosts checked with the --hosts option. therefore, it's a good idea to keep the fastest machines on the top of your host list. alternatively, you can use a quick and dirty synchronous checking mode, which sometimes produces errors (depending on your computer) but usually works fine with a synch_delay value of 0.2-0.4 (seconds; using sleep). if your sleep command does not understand floating point numbers, then use a synch_delay value larger than 1. a short delay is then looped synch_delay^2 times. (try 15 for a start.)
in the slow regular mode, bad computers are checked only one in six times (normally, bad computers stay bad anyway). in synchronous mode, the bad hosts are checked every time. if all checked or available (below the specified threshold) computers are already in use, autm exits. if a specific tempmap inputfile is currently being tempmapped, it will not be submitted again. (so feel free to enter autm *.in repeatedly    :-)
with the --watch option (preferably started in a different xterm), you can monitor the currently running tempmap jobs.

autm is always started from the directory where your current tempmap inputfiles are located. upon submission to a host, autm  prompts four numbers and a start message. the numbers are: [ current time / decision-maker value / expected run time / expected end time ]. when finished, another message is prompted including the effective run time, so it's better not to use this xterm otherwise, except for submitting further tempmap jobs. (set quiet in the parameter file to 1 if you want to avoid the end message.) nice level for the computations is 19, the lowest. it's strongly recommended to leave it at that value!
 

version 1.2: the most important changes are a number of internal improvements and bug fixes. new options: -k or --kill-synch kills all currently running synchronous checking processes; useful if a host is hung. killing the running tempmap jobs is now done with a capital -K or --kill-tempmap.  there is an additional, hidden -KK option that sends a kill-signal to all hosts in the hostlist file, no matter wheather tempmap is running there or not.    most useful: -r N or --maxtime N restricts the hostslist to hosts with a maximum expected runtime of N minutes. you can, alternatively, set this in the parameter file with the maximum_runtime parameter.    a dont_believe parameter was added that allows so set the threshold for runtime-record and -average determination. if a tempmap job is faster than this value (in seconds), it will not affect the record and average entry.

if your computer is a member of the linux netgroup and you want to access your tempmap files from the various hosts via your  /home directory, set the newly introduced netgroup parameter in the parameter file to 1. if the hosts access your working directory via  /net/yourcomputer, leave it at 0. it's recommended to use the first method if possible, as it is a smaler burden to the local network.
for synchronous checking it is necessary to add a little synch_delay between requests (otherwise your computers job table might overrun). this is typically achieved with a synch_delay value of 0.2 - 0.4 seconds. however, your computer's sleep command might not understand fraction numbers. in this case, any value larger than 1 will cause a value^2 loop delay. try 15.
 

Usage: autm [OPTION(s)] [InputFile(s)]

  -c, --check                force checking of hosts (printing long output)
  -n, --no-check             suppress checking of hosts
  -y, --synchron             synchronous checking mode (quick+dirty)
  +y, -Y, --no-synchron      regular checking mode (slow+safe; default)
  -h, --hosts N              restrict regular check to the first N hosts
  -a, --all-hosts            don't restrict number of hosts (default)
  -r, --maxtime N            restrict hosts to max. expected runtime of N min.
  -m, --maxloadavg-mode [N]  show or set max loadavg determination mode (1-3)
  -t, --time                 show time since/until check and exit
  -l, --list [N]             list computers from last check and exit
  -s, --sort                 sort hosts by their anticipated speed (default)
  +s, -S, --dont-sort        don't sort hosts (default for -l)
  -b, --buffer [N]           if all hosts used, wait (N min.) and try again
  -w, --watch [N]            monitor files currently being tempmapped (N in sec)
  -W, --watch-forever [N]    don't exit if no job is running
  -k, --kill-synch           kill all running synchronous checking processes
  -K, --kill-tempmap         kill all remote tempmap jobs
  -x, --no-exit              don't exit until all jobs finished
  -q, --quiet                decrease verbosity
  -d, --dry-run              tempmap simulation for 30 seconds
  -v, --version              prompt version and exit
  -h, --help                 print this help page and exit

this list of linux computers might be helpful. and here is my current autm.hostlist. my tempmap jobs typically run 8 minutes (reference_speed=500 seconds) on the fastest machines (tempmap version 3.2 with typically 10 spectra and 5-10 line blends). if yours is different, adjust the reference_speed parameter, and then you should probably do fine with this list. most likely, it's the best thing to copy this cleaned autm.hostlist to your ~/bin and let your computer determine your best speed values. you can add the appropriate hostkeys to your ~/.ssh/known_hosts file (otherwise you have to type yes for each host when accessing it for the first time).