Infrastructure Notes


Those doing active research in the AI group should have accounts and home directories on the AI group machines.  This AI home directory will be different than your CS dept student home directory on agate (if you have one). Be sure to set up email forwarding if you need to.  We use NIS to coordinate passwd and group info across the AI machines, so if you want to change your password, use yppasswd, and if you want to change your shell, use ypchsh. If we need to reboot a machine to install a patch and you are logged in, we will try to contact you, so please make sure your location and phone number are updated using the ypchfn command.

 

Group stuff is available in /home/aifs2/group.   If you accidentally delete a file, check out /home/aisnaps to retrieve a backup copy.  Snapshots are taken every 12 hours (noon and midnight) and kept for various lengths of time.

 

If you need to lookup someone's phone number to contact them, try "group/bin/finger <loginid>".

 

If you are having trouble setting up public key login for SSH, try this fix.

 

Robotics is covered on its own page.

 

AI group machines

 

All are running 64-bit Ubuntu.

 

Please check system activity with the `top' command before starting experiments.  If someone else is running a job, please use a different machine.  The simplest way to run experiments across multiple machines is just to have a seperate terminal, emacs, and ocaml toplevel for each machine. If you find a better way, please post it!

 

Desktops

For all development, general use, and quick pilot experiments.  Although desktops are usually assigned to specific people, they are still a shared resource - you may ssh into any desktop and use it, as long as you do not interfere in any way with the main interactive user.  This means using at most half the RAM, using at most half the cores, and using the nice -n 19 command for long-running jobs to ensure that your process only uses spare cycles.  If the main user installs patches and wants to reboot, they should try to reach you first (you have your current cell number updated using ypchfn, right?), but if they can't reach you, they will reboot anyway.  If a "spare" desktop is listed, you should probably prefer that one for remote login, since it is less likely to get rebooted.

 

If you have an AI desktop, please be sure to keep your machine up-to-date with the latest Ubuntu patches, and check for other users before rebooting! 

 

Inactive:

 

Not ours:

 

 

Compute servers

Only for running heavy experiments.  Not for random login. It is important to run only one program at a time on each machine in order to get accurate CPU time measurements, even on a multi-core system.

To use them, see slurm

 

Multicore compute servers: please use only if you need multiple cores for a single program, lots of disk, or more RAM than an aiX machine.

 

Service servers

Not for general login use.

File servers:

spare:

Retired

 

 

IDA* performance versus SPEC int 2006 base benchmark

 

 

 

CS dept servers

 

General-purpose research compute servers

Using these machines for real experiments is discouraged unless you are very careful, since CPU timing can get thrown off by other users' jobs.  Also, they use a separate filesystem.

All are running 64-bit Fedora.

ccluster@cs is the mailing list for coordinating their use. Send email before any long-running batches or periods of heavy use.

 

Other servers

Not for heavy experiments!

 

Random 32-bit desktops: hickory, cherry, oak, chert?

 

CIS servers

 

Working at CIS is discouraged since they have a separate filesystem. 

See here for more info on the public-use CIS servers.

 

 

Code

We've got a lot of domains and solvers already implemented, so chances are if you want to do work on a specific problem, you can start working pretty quickly

 

Domains:
Directory Domain Name Condition

antic-grocery

 Anticipatory Grocery Planner Unknown
dyn_robot Dynamic Robot Path Planning Unknown
grid Gridword Pathfinding Working
msa Multiple Sequence Alignment Broken
tiles Sliding Tile Puzzle Working
topspin Topspin Game Unknown
tplan Temporal Planning Working
tsp Travelling Salesman Problem Working

 

Solvers:

There are many, many heuristic search algorithms which all have different strengths and weaknesses.  We have the following on hand:

Algorithm Directory Condition
A* shortest_path Working
Iterative Deepening A* bounded_depth Working
Greedy Search shortest_path Working
Speedy Search shortest_path Working
A* epsilon bugsy Working
weighted A* shortest_path Working
Dynamically Weighted A* shortest_path Working
Optimistic Search george Needs Optimizing
Alpha A* shortest_path Needs Optimizing
A epsilon shortest_path Needs Optimizing
Anytime Heuristic Search bugsy Working
Anytime Repairing A* bugsy Unknown
BUGSY bugsy Unknown
Clamped Adaptive Search george Working

 

 

Problems

Domains and solvers aren't interesting without problems to solve.

Domain Directory Description
Grid uniform Grids with Uniform Obstacle Distribution
Grid uniform_region Grids where a rectangular sub-region has uniformly distributed obstacles
Grid lines Grids with lines drawn across them
Grid game Grids from popular real time strategy and roleplaying games
Grid benchmark Large Uniform Obstacle Grids, used for benchmarking machines
MSA morphed  
MSA real Real Sequences
Tiles huge Really Big Sliding Tile Problems
Tiles korf All 100 instances from Korf's paper on IDA*
Tiles korf_25_easy The 25 Easiest instances of the Korf instances
Tiles korf_easy  
Tiles Random Randomly Generated Problems
Temporal Planning blocksworld Stack and unstack blocks on a table
Temporal Planning logistics Shipping things between places, making sure they arrive on time.
Temporal Planning rovers Mission planning for rovers
Temporal Planning satellite Mission planning for a satellite
Temporal Planning zenotravel Travel using many means of conveyance
Travelling Salesman pkhard Instances similar to those used in Pearl and Kim's paper
Travelling Salesman usquare Going from A to B and B to A have the same cost.