Photo CD Demo 1

home *** CD-ROM | disk | FTP | other *** search

/ Photo CD Demo 1 / Demo.bin / cellsim / v2_5 / doc / cell.doc next >

Wrap

Text File | 1990-02-26 | 44.8 KB | 1,132 lines

Documentation for Cellsim v2.5 February 17, 1990 **************************************** NOTE This file mainly discusses the SunView part of Cellsim. The Connection Machine is mentioned only when describing the various CM menus in the SunView tool. For information on the CM side of Cellsim, read the "CM.doc" file. **************************************** SUMMARY The Cellsim package is a cellular automaton simulator which runs on Sun-3, Sun-4 and Sparc workstations (and possibly Sun-2's), with either color or monochrome display. In the current version, Cellsim allows the user to choose up to 256 states per cell, up to a 512 x 512 array of cells, and a choice of various types of neighborhoods. It also lets you attach to a Connection Machine through the network, which gives you very fast CA updates. **************************************** USING THE SIMULATOR **************************************** COMMAND LINE OPTIONS The simulator may be invoked with a number of different options. The following command line options are available: B Run in black & white mode. b<number> Sets the array size to <number>, where <number> is 64, 128, 256, or 512. (Default is 64.) v<number> Sets the neighborhood type to von-Neumann (5-neighbor, 2-d), and sets the number of states per cell: <number> may be 2, 4, 8, 16, or 256. (Default is 8.) m<number> Similar to v, but sets neighborhood type to Moore (9-neighbor, 2-d); <number> may be 2, 4, 8, or 256. M<number> Similar to v and m, but uses the Margolus neighborhood (4 spatial neighbors, 2-d, and 1 phase neighbor); <number> may be 2, 4, 8, 16, or 256. l<number> Similar to v, but sets neighborhood type to linear (1-d). By default this includes one cell on each side of the current cell, but this may be altered using the `r' option below; <number> may be 2, 4, 8, 16, or 256. r<number> Sets the radius of the 1-d neighborhood. <number> may be 1, 2, or 3; the default is 1. This option is ignored if the neighborhood is not linear. P<number> When this option is invoked, the program will set up a socket connection to receiving port <number>, and send an array of state counters to the receiving program at each time step. (Sample programs which utilize this feature can be found in the "socket" directory.) H<name> Used with P if the desired port is on a different host than the host on which "cell" is running. <name> is the name of the desired host. C<name> Specify the name of a Connection Machine front-end (CMFE). This hostname will be used when you select the "Connect" item from the "CM" menu. p<number> The port-number to use when connecting to the CMFE. The options may appear in any order. Also, any or all options may be omitted on the command line. In addition, Sunview frame arguments can be passed in through the command line to set such things as the position of the window; see Sunview documentation for more details. Note that since Cellsim uses a colormap with 256 entries, frame-color arguments will have unusual and/or unpredictable results. COMMAND LINE EXAMPLES: The following assume that you have changed the name of the binary version you wish to run from "cell.sun3" (Sun-3 binary) or "cell.sun4" (Sun-4/Sparc binary) to "cell". cell This will set up a 64x64, 2D cellular array with 8 states per cell using the von Neumann 5-cell neighborhood. This is the default simulator and is equivalent to typing "cell v8 b64". cell b256 m256 B This will set up a 256x256, 2D cellular array with 256 states per cell using the Moore 9-cell neighborhood, and run in black & white mode. cell b128 l4 r3 Hhawk P1200 This will set up a length 128, 1D cellular array with 4 states per cell using a linear neighborhood of radius 3. The simulator will use a 128x128 display, displaying a time trace in the vertical direction, and will send state counts to port #1200 on machine `hawk'. cell M4 b128 Ccmfe.lanl.gov This will set up a 128x128 2D array, using the Margolus neighborhood with 256 states per cell, and will try to connect to the CMFE host "cmfe.lanl.gov" if you select "Connect" from the "CM" menu. **************************************** SIMULATOR COMMANDS The following commands are available. Each section below corresponds to a button on the control panel. Each button in turn has a pullright menu which may contain several items; the items, if they exist, are listed separately in that section. Also, several of the commands require input. There are two different methods used to obtain the parameters: - Some of the items will prompt you for the necessary input. Examples of this are loading and saving files (Images, Lookup Tables, etc). - Other items do not prompt you for parameters, unless you first click on the "Set" button. This is so that, after you have set the parameters once, you may then re-select that item later and use the same values for the parameters as last time. Items that require you to use the "Set" button to set their parameters are marked with a '*'. Mouse button usage in the control panel: - Click the LEFT mouse button over a button in order to select the FIRST item in that button's menu. The first item in the menu is usually the most commonly used item. - Click the RIGHT mouse button over a button in order to display the popup menu, to select an item (release the right mouse button over the item you want). - Click the MIDDLE mouse button over a button to re-select the last item that you selected (using the RIGHT mouse button) from that menu. Run: Run the automaton. << NOTE! This command will not work until you have loaded a specific transition function or object file! See the description of the "Rule" menu below. >> For all except the last 3 items, this command is terminated by pressing the left mouse button, anywhere in the CA window; all other input to the CA is ignored. The run will stop and display an appropriate message if an undefined neighborhood is encountered. Menu Options: Run ----------- run continuously, displaying every step. Skip* --------- prompt for integer N, then run displaying every Nth step. N may be 0, in which case no display occurs; this is the fastest run mode available. Bounded* ------ prompt for integer b, then run one step at a time, stopping after b steps. Skip/Bounded* - combination of Skip and Bounded. Run/local ----- run the rule locally (on the Sun), when attached to the CM. (When attached to the CM, the "Run" item will run the rule on the CM. "Run/local" lets you run things locally instead, without having to detach from the CM). Screenful ----- gives one screenful of display, then stops (mainly intended for use in 1-d mode). Step ---------- do a single step of the automaton. If undefined neighborhoods are encountered, they are displayed and the user is given an opportunity to define them. Skip* ---------- prompt for integer n, then do n steps and stop. Will stop and display error message if an undefined neighborhood is found. Defaults: Alter some default parameter or behavior of Cellsim. The first four items under this menu ("image", "Rules", "Cmap", and "CM") each pop up a new window, which has various items in it to allow you to adjust the behavior of Cellsim. When one of these new windows pops up, you can actually leave the window open off to the side somewhere, or click on the "Done" button near the bottom of the pop-up window to hide it again. The four popup windows, and the items they contain are as follows: - "Image" : Defaults related to loading/saving images "Save in:" toggles whether to save images in the current working directory (the default when invoking Cellsim), or to save them in the "Image-dir" directory. "Save:" toggles whether or not to save images in compressed form. The default is to save them compressed. "Image-dir:" this text-item holds the name of the Image-directory. When loading images, if a file can't be found in the current working directory, the Image-dir will be searched as well. Also, images will be saved in the Image-dir, if you've enabled it as described above. "Auto-change:" Whether or not to automatically change the current image-size upon loading an image, based on the filename extension of that image. Recommended filename extensions are discussed later on in this file. For example, when auto-change is enabled (the default), then if you load "heat.64x" the image-size will be set to 64, regardless of what it is right now. If the image-size was already 64, it wouldn't be changed. Note that changing the image-size clears out all buffers and the current image. If you'll be working with image-files that don't have the suggested filename extensions, then you should disable auto-change. "Done" clicking on this button erases the Image-defaults popup window. - "Rule" : Defaults related to loading/saving rules "Save in:" whether to save lookup tables (LTs) in the current working directory or the Table-directory. "Save:" whether to save LTs in compressed format or not (the default is to save them in compressed form). "Table-dir:" the value of the Table-directory. When loading LTs, if the file cannot be found in the current directory, it will be looked for in the Table-dir. You can also have Cellsim save LTs in the Table-dir, as mentioned above. "Fcn-dir:" when 256-state update-function files (".o", or object-code files) cannot be found in the current directory, they will be looked for in this directory. Since you can't save ".o" files from within Cellsim, the value of Fcn-dir is only used when loading rules. "Auto change:" whether or not to automatically change neighborhoods/number of states when loading a rule. For example, if auto-change is enabled, then when you load "life.m2", Cellsim will automatically switch into the 2-state Moore neighborhood, if it's not in that configuration already. Note that change neighborhoods and/or number of states has the following effects: - the lookup-table is cleared - the current image is AND'ed with a mask so that the image will have legal values. That is, if you switch from a 4-state into a 2-state neighborhood, all the cells will be AND'ed with a mask so their values will all be 0 or 1. "Done" clicking on this button will erase the Rule-defaults popup window. - "Cmap" : defaults related to loading/saving colormaps "Save in:" whether to save colormaps in the current working directory or in the Cmap-directory "Save:" whether or not to save colormaps in compressed form (true by default). "Cmap-dir:" the value of the Cmap-dir. When loading a colormap, this directory will be searched when a colormap can't be found in the current directory. You can also have Cellsim save any colormaps in the Cmap-dir, as mentioned above. - "CM" : defaults related to using the Connection Machine "CMFE host:" the hostname or number of the Connection Machine Front End (CMFE) to attach to. This is an address of the form "cmfe.your.edu" or "128.129.130.131". "CMFE port:" the port number to connect to on the CMFE. By default, Cellsim uses port # 12700. You can change that, but you must also tell the daemon on the CMFE to use a different port if you decide to change it. "Run delay:" Miracle of miracles, we have a computer that sometimes runs too fast! Sometimes, when you're watching something run on the CM's Frame Buffer (CMFB), it's too fast to really see what's happening. This slider controls a delay between time-steps; if you increase the value, things will run more slowly. On a Sun front-end, this value is the number of microseconds to pause between steps. On a Vax front-end, there isn't a microsecond ("usleep") routine in the C library; I haven't yet written my own, so for now the Vax will spin in a loop for an amount of time proportional to this value. But the value won't necessarily be the number of microseconds, on a Vax front-end. "Display on:" This item has 2 sub-items which you can toggle: "CM Frame-buffer" and "Sun display". These toggle whether or not to use the specified display when running stuff on the CM. If you disable the Sun display, then you won't see images on the Sun after you've run unless you explicitly "Get image" from the "CM" menu in the control-panel. When you've enabled the Sun display, the various run commands will pretty much behave as they usually do, except when it comes time to display an image, the CM will have to send it to the Sun through the socket, which is generally **very** slow. Usually, you should only send very few images (e.g. every 100 or 500 or 1000 frames), by using the "skip" command. "Skip" and "Skip/bound" tend to be the most common methods of running when using a CM remotely, where you don't have access to the frame-buffer. Note that the "Run" command behaves differently than usual when you've enabled the Sun display and are running on the CM. Rather than displaying every frame, the CM will run without displaying anything on the Sun (but it will display frames on the CMFB, if enabled), until you click the left mouse button to stop running. At that time, the final image will be sent back to the Sun to be displayed. You can enable either, both, or neither of the two displays. "Image-dir:" When you try to load an image from the CMFE disk into the CM, first the directory which the daemon was started in will be searched, and then the "Image-dir" will be searched. Note that this is a *different* Image-dir than the one used to search for local images; this one is used when loading images directly into CM memory. "Fcn-dir:" Similary for loading CM C/Paris computed-function files. "LT-dir:" And for loading lookup-tables into CM memory. "Zoom factor:" This is the magnification level, if you are using the CMFB. (It has no effect if you are not using a CMFB). When you move the slider, the image gets larger or smaller in real-time. (The CMFB has hardware to do zooming, so it doesn't get slower when it gets bigger, unlike the Sun). "X pan: and "Y pan:" These are translational offsets for the image on the CMFB. Note that they work backward from the way you might expect. Increasing the X pan, for example, shifts the image to the *left*, and increasing the Y pan shifts the image ???. (This is the way the CMFB software works, I didn't implement it that way). "Done" clicking on the "done" button will remove the CM-defaults popup window. There are also three "normal" menu-items in the "Defaults" menu (that is, they don't bring up popup windows). They are: Change nhood / #states --- This allows you to enter a neighborhood specification string in the same form as the command-line arguments, e.g. "v8" or "l256r2" and so on. Note that changing the neighorhood or # of states clears the lookup-table, and applies each cell in the current image to an "AND" mask, to make sure each cell's value is in the new legal range. Change image-size ---- change the size of the image, which you will be prompted for. Currently, valid image-sizes are 64, 128, 256, and 512. When the image-size is changed, the current image is cleared, as well as all of the buffers!! Don't forget that; if you have an image in a buffer that you want to keep, first save it to a file, and then after changing sizes, load/resize it again. Change working directory ---- this allows you to change the current working directory from within Cellsim. Image: Manipulate the current array of cells in various ways. Note that some of these commands also involve the image array, a backup array which is used during automaton steps to store the previous generation. Menu Options: Load ---------- load the current array from a disk file. Save ---------- save the current array to a disk file. If enabled, images will be saved in compressed format. Load/Resize --- load current array, from a file of a different size than the current array size. Also prompts for an offset, which is the position in the larger array corresponding to the origin of the smaller array; the default is to center the smaller array. Save/Resize --- analogous to Load/Resize. Save/Raster --- save the current array into a file in Sun raster format. The image can then be printed using one of the various public-domain Sun raster -> PostScript conversion programs available. Note that when Cellsim is being run in color, the raster will have the current colormap as its colormap; you will have to run the image through the "rasfilter8to1 (1)" program (see the man-page) if you want to print it on a monochrome printer. If you dump the image while running Cellsim in black & white mode, then the current "colormap" (texture settings) will be used. Also, when you dump the image in black & white mode, the saved image will be magnified by the same amount as the current image; this is because the textures look different at different magnifications, as part of the textures get "chopped off" at low magnifications. In color, the current magnification has no effect on the dumped raster file. Load/CAM6 ----- load an image that is in CAM6 format. Save/CAM6 ----- save the current array to a file in CAM6 format. Enter* --------- clear array and accept a row of sites from the keyboard which will be centered as the initial configuration. Clear --------- clear the current array. Swap ---------- exchange the current and image arrays. Copy ---------- copy the current array into the image array. Invert -------- invert the current array (bitwise inversion). Rules: Items related to the lookup-table/update-function Menu Options: Load ---------- load in a rule (an LT or obj-code file). Save ---------- save the LT to a disk file (you cannot save computed-function rules from Cellsim). The LT will be saved in compressed form, if that option is currently enabled. Clear --------- set all LT values to "undefined" (no effect when using 256 states). Alter --------- alter an individual value in the LT. Symmetry ------ set or unset transition rule symmetry. If enabled, all rules entered by the user through Learn, Alter, or "undefined neighborhood" (but NOT through loading transition files) are assumed to be rotation- symmetric. Enabled by default. Generate ------ for use with 1-d, 2-state, r=1 neighborhoods. Given a decimal integer from 0 to 255, will generate the corresponding transition rule according to Wolfram's numbering scheme. For instance, rule number 56 (binary 00110110) would be: nhood: 111 110 101 100 011 010 001 000 result: 0 0 1 1 0 1 1 0 Lambda* ------- Use the lambda parameter, as described in Chris Langton's article "Studying Artificial Life with Cellular Automata" (Physica 22D, 1986), and generate a lookup-table based on that setting. Lambda is essentially a parameter which describes how "full" the table is; it is the percentage of entries in the table which are non-zero. Thus, if you set lambda to 20, a random lookup table will be generated, in which 20% of the table entries are non-zero, or 20% of the possible neighborhoods will go to a non-zero state. This corresponds to a lambda value of 0.20 in Langton's article. Some of the most interesting behavior occurs when lambda is between 20 and 30; this is when the table is full enough that a random initial configuration often will not settle down to a fixed value, yet not so full that the array would stay very random. When the table is generated, the current value of the "symmetry" flag (which you can toggle from the Trans menu) is examined; thus, you can generate symmetric or non-symmetric tables with lambda. Lambda step* -- "Step" through the lambda parameter space. This requires a parameter n, which can be positive or negative. If n is positive, then n transitions in the LT that currently go to zero will be replaced by non-zero transitions (the new state to go to is picked at random, evenly distributed among the non-zero states). If n is negative, then n transitions that currently go to non-zero values will be replaced by zero transitions. Rho* ---------- Similar to lambda, but more generalized. Instead of entering just one parameter, you enter S-1 of them, where S is the number of states per cell. For example, if you are running with the "v4" neighborhood, and select "rho set", you will be prompted to enter 3 percentages. If you enter "20 10 12" for example, then a random lookup table will be constructed in which 20% of the entries go to state 1, 10% of the entries go to state 2, 12% of the entries go to state 3, and the remaining 58% will go to state 0. Rho also looks at the symmetry flag when constructing the lookup table. Edit parm1 ---- Alter the value of the global "parm1" parameter which gets passed to your update-function when using 256 states. Edit parm2 ---- Similar to parm1, but for the second parameter. Buffer: Manipulate image buffers in various ways. Image buffers are extra memory arrays which can store an array for future use. Currently there are nine buffers available, numbered 1 through 9. The "image array" (described in Image above) is also available to these commands as buffer 0. Menu Options: Load ---------- load the current array from the given buffer. Save ---------- copy the current array into the given buffer. Swap ---------- exchange the current array and the given buffer. Xor, Or, And -- perform a bitwise operation between the current array and the given buffer, and let the result be the new current array. Clear: Clear out the 'current' displayed array, or set the time-value to zero. Menu Options: Array --------- Clear out the 'current' displayed array. Zero time ----- Set the current "time" value to zero. Learn: Derive transition rules from a sequence of images by running the CA in `reverse', using the images to derive rules rather than using the rules to derive images. This function is invoked as follows: 1. Construct a `before' array, and Copy it into the `image' array. (See options for Image command above.) 2. Construct an `after' array, and leave it in the `current' array. 3. Invoke the Learn command. This procedure will derive the necessary transitions such that one step of the automaton will change the `before' array into the `after' array. If this involves redefining a previously defined transition, a prompt will appear offering the user a choice as to whether the change should be made. At the end of this command, the `after' array will be copied into the image array. The `before' array is destroyed. This is so that one may perform several Learn commands in succession solely by altering the `current' array and invoking Learn. Note that the Learn command does not work when you are using 256 states (computed-function updating); "Learn" has no meaning except when using lookup-tables for updating. Set: Set a parameter when calling some other function. Simply click the "Set" button before selecting another item (such as "Skip" under the "Run" menu) that requires you to set a parameter. Zoom: Changes the magnification of the displayed image. The size of the display is determined by the `zoom factor' Z, which means that each cell is displayed as a square of Z pixels on a side. Note that a smaller zoom factor will give faster running speed, but at the expense of making other functions - such as display editing - more difficult. Menu Options: Toggle -------- if display is full-size, set zoom factor directly to 1; otherwise set to full size. Magnify ------- prompt for an integer z which becomes the new zoom factor. Closeup: Enter or exit closeup mode. When in closeup mode, the center 32x32 of the array is magnified to take up the entire window. Particularly useful when editing larger arrays. Note that while in closeup mode, Zoom:Toggle is allowed but Zoom:Magnify is not. In 1-D mode, an area on the bottom row of the array is magnified, so that you can see the current generation. Zoom in/Zoom out: Adjusts the current magnification. Zoom in will increase the magnification by one, unless it is currently at the maximum. Zoom out will descrease the magnification by one, unless it is already at the minimum (1). Draw: Various functions useful for generating images, such as random images, lines, and circles. Menu Options: Quick random -- randomize entire array, with an equal number of cells of each value. So for example, using a 4-state neighborhood, 25% of the cells get value 0, 25% get value 1, and so on. General random* -- this is a much more general random-image generator. You will be prompted for the origin of the rectangle to change (enter x and y coordinate), the size of the rectangle to change (width and height), the percentage of cells to change, and the minimum and maximum values to set the affected cells to. For example, if you enter "5 10" for origin, "20 33" for size, "12" for percent, and "2 5" for min/max values, then a 20x33 rectangle of cells, with its upper-left corner at (5,10) will be affected. 12% of the cells will be set to a random value between 2 and 5, inclusive. Note that the other 88% of the cells will NOT be changed (they will not be zeroed out). As another example: if you want to change 20% of the cells in a 64x64 array to a value of 2, use an origin of "0 0", size of "64 64", percentage of "20", and min/max values of "2 2". Color: Allows various manipulations of the color map. Colormap items in this program are stored as 6-digit hex values, consisting of 2 digits each for red, green, and blue components (in that order). Note that in black & white mode, textures are used instead of colors. The colormap items are used as indices into the array of textures. For example, if entry 2 in the colormap table has a value of 5, then cells with a value of 2 will be displayed using texture #5. Also note that currently, in black & white mode, when the image is being displayed at a magnification level of 1, all non-zero cells are displayed using black, while cells of value zero are displayed as white (unless you are running suntools in inverse mode, in which case the situation is reversed); this is to increase the speed of the simulation. The colormap has no effect on this. At magnifications greater than 1, the colormap has the effect described above. This only applies when running in black & white mode; in color, the colormap is used at all magnifications. Menu Options: Load - load a previously saved colormap from a file. Save - save the current colormap to a file. Alter - alter an entry in the current colormap. Planes: Allows various bitplane manipulations. All of these commands (except for Reset) prompt for a plane mask, which should be in hexadecimal, the bits of which specify the planes to be affected. For instance, a mask of 2 (0010) denotes plane 1 only; a mask of 4B (01001011) denotes planes 0, 1, 3, and 6; and so forth. Menu Options: Reset - reset display to show all bitplanes. Display - display only those bitplanes in the given mask. Clear - clear the given planes. Invert - invert the given planes. CM: Connection Machine routines See the "CM.doc" file for more information about using Cellsim with a Connection Machine. Menu Options: Connect to CM - Connect to the Connection Machine Front End (CMFE). There must be a daemon process running on that CMFE, waiting to accept connections and to attach to the CM. Send image ---- Send the local image (in the 'current' array) to the CM. Get image ----- Get the image currently on the CM, and bring it to the Sun as the 'current' array. Send LT ------- Send Lookup Table to CM (not valid when using 256 states). Send cmap ----- Send colormap to the CM, to be used when displaying images on the CM frame-buffer Disconnect ---- Detach from the CM, and disconnect from the CMFE. The daemon on the CMFE will resume waiting for a client. Load remote image -- Load an image into the CM array, from the CMFE disk. (The image will not be sent to the Sun unless you explicity request it). Load remote Rule --- Load an LT or object-code file from the CMFE disk, into memory on the CM. Clear CM array ------ Clear out the array on the CM CM quick random ---- Quick random, which executes on the CM instead of on the Sun. CM general random* -- General random for the CM. Sequence: Construct and invoke user-defined sequences of actions You can construct commonly-used sequences of commands. For example if you want to experiment with lambda, you may want to construct many different LT's, all with lambda=20, then generate a random image, and run for 1000 time-steps. You could do the following to simplify this task: 1. Use "Set" "Rules/Lambda" to set the lambda parameter 2. Use "Set" "Run/Bound" to set the parameter indicating how many steps to run, say 1000. 3. Click "Set" and then one of the "Sequence" items, say "Sequence 2". This begins defining the sequence. Everything you do now will be added to the sequence. 4. Click "Rules/Lambda" to generate a new LT using the current lambda parameter. 5. Click "Draw/quick random" to generate a random image. 6. Click "Run/bounded" to run for 1000 time-steps. 7. Finally, select "sequence 2" again, to finish defining your sequence. Now, you can just select the "Sequence 2" item to execute everything you taught it, namely "lambda -- draw/quick-random -- run/bounded". Note that if you try to do things like "Image/Load" to load an image within a sequence, the image-load function prompts you for a filename. Therefore, every time you call your sequence, you will be prompted for the filename. There are 5 user-definable sequences. Quit: Terminates execution of the program. Up, Down, Left, Right: Shift the image in the specified direction. The distance shifted is initially 1, but can be reset using the Shift button. Shift: Prompts for the shift distance to be used with the direction buttons above. **************************************** ENVIRONMENT VARIABLES AND DEFAULT DIRECTORIES Depending on who compiled the version of Cellsim you are running, it may look in certain default directories for files it cannot find in the current directory. Typically, these defaults will be the directories containing images, transition tables or update rules, and colormaps that are supplied with Cellsim. However, you may wish to change these defaults, or disable them. This can be done by setting environment variables before invoking Cellsim. There are four environment variables that can be used: IMAGE_DIR -- Directory in which images will be looked for TABLE_DIR -- Transition-table files will be looked for here FCN_DIR -- Update-functions (".o" files) will be looked for here CMAP_DIR -- Directory to search for colormaps For example, if you enter "setenv IMAGE_DIR /home/users/joe/Images" before invoking Cellsim, and then try to load the image "picture.64x", and Cellsim cannot find that image file in the current directory, it will then try to load the image in from "/home/users/joe/Images/picture.64x". Thus, if you have some directories in which you keep your transition tables, images, and colormaps, you can avoid having to type pathnames by setting the appropriate environment variables. They would typically be set in your .login file, although you can do it manually. Note that default-directory searching can be disabled, by setting the environment variables to null values. For example, if you execute "setenv IMAGE_DIR", then if an image cannot be found in the current directory, it will not be looked for anywhere else. **************************************** NEIGHBORHOOD ENCODING Some of the commands will print out a neighborhood, or ask the user to enter one. When this happens, the neighbors should be in the following order, depending on the neighborhood type in use (c = center, l = left, r = right, t = top, b = bottom): VonNeumann: c, t, r, b, l (clockwise order) Moore: c, tl, t, tr, r, br, b, bl, l (also clockwise) linear: left-to-right order, regardless of radius Margolus: c, ccw, opp, cw, phase (counterclockwise) **************************************** DISPLAY EDITING In addition to the above commands, the user may inspect and alter the displayed image directly using the mouse. The functions associated with the mouse buttons depend on the current `mode', which can be changed by clicking the panel item labeled "Mode". Three modes are available: Edit: Allows general editing of the displayed `current' array. Mouse button functions: Left ----- Sets the cell under the cursor to a nonzero state. The new state is shown by the color of the cursor, and can be changed by keyboard or menu as described below. Middle --- Erases the cell under the cursor, i.e. sets its state to zero. Right ---- Displays a menu of all nonzero states, and allows the user to select a new state for insertions. Note that when using 256 states, the right button has no effect, as the menu would be too large to be very useful. Keyboard - If a key corresponding to a valid nonzero state is pressed, this state becomes the new state for insertions. When using 256 states, 2 keypresses are required to set the new state, in hexadecimal. For example, hitting "c8" will set the state to hexadecimal c8 (200 decimal). Only a single keypress is required to set the color when using less than 256 states. Probe: Allows inspection and alteration of the transition function. Note that none of the probe functions work when using 256 states per cell. (This will hopefully be changed in the next release). Mouse button functions: Left ----- Displays the states of the cell under the cursor and its neighbors, and shows the next state for that cell according to the current transition table. Right ---- Just like the left button, but also displays a menu with the option `Alter'. Selecting this option allows the user to alter the corresponding entry in the transition table. Plane Edit: Allows editing of a single bitplane at a time. Mouse button functions: Left ----- Sets the bit in the cell under the cursor in the plane currently being edited. Middle --- Clears the bit in the current cell and plane. Right ---- Displays a menu of all planes in use, and allows the user to select a new plane to edit. Keyboard - If the number of a valid plane is pressed, that plane becomes the current editing plane. In any mode, whenever the cursor is in the display area, the cursor position (in terms of array cells) and the state of the cell under the cursor will be displayed in the upper portion of the control panel. **************************************** AUTOMATIC TERMINATION OF RUNS You can have Cellsim automatically stop running, under certain simple conditions. Namely, you can have Cellsim stop running when the array becomes empty, or when there is no change in the array between time-steps (e.g. the dynamics have settled down to a fixed image). You can enable either of these stopping conditions with the "Stop on:" cycle in the control panel. The three possible values are "never", "no change", and "all zero" (where "never" means do not automatically terminate running). **************************************** DIFFERENCES FOR 1-D MODE Since the program was originally designed to handle 2-d arrays, some of the commands have slightly different effects when running in 1-d mode. Major differences include: - The `current' array is considered to be the bottom line of the display (rather than the entire display as in 2-d mode). The remaining lines of the display are used to keep a time history of the 1D array. - The Step and Skip commands shift the time history up one step and place the next generation in the bottom line. - The Screenful command moves the bottom array to the top and does as many steps as will fit on one screen, leaving the final generation on the bottom line. - The Run commands (Run, Skip, Bounded, Skip/Bounded) are implemented by doing repeated Screenfuls, rather than repeated Steps. They are otherwise identical to their 2-d mode functions. - The Load, Save, Load/Resize, Save/Resize, and Enter commands affect only the bottom line of the display. (Because of this, files Saved in 1-d mode give unexpected results when Loaded in 2-d mode, and vice-versa.) - The Learn command, rather than deriving rules to generate the `current' array from the `image' array, derives rules to generate the bottom line of the display from the second-to-bottom line. **************************************** FILE NAME CONVENTIONS To demonstrate the operation of this program, several example image and transition files are included. The filename suffixes are assigned according to the following conventions: ".64", ".128", ".256": 1-d arrays of the indicated size ".64x", ".128x", ".256x": 2-d arrays of the indicated size (meant to suggest 64x64, etc.) ".v2", ".v4", ".v8", ".v16": transition rules for the VonNeumann neighborhood, with 2, 4, 8, and 16 states per cell respectively ".m2", ".m4": transition rules for the Moore neighborhood, with 2 and 4 states per cell respectively ".l2", ".l4", ".l8", ".l16": transition rules for the linear neighborhood, with 2, 4, 8, and 16 states per cell respectively. By themselves, these denote rules of radius 1; larger radii can be denoted by adding "r2" and "r3", for example, ".l8r2" for a radius 2 neighborhood with 8 states per cell. ".M2", ".M4", ".M8", ".M16" transitions rules for the Margolus neighborhood, with 2, 4, 8, or 16 states per cell. ".m256.sun3.o", ".m256.sun4.o", ".v256.sun3.o", .l256.sun4.o", ".l256r2.sun3.o", and so on object-files which contain an update-function for the neighorhood specified in the extension. The ".m256" are for moore neighborhood, and so on. Note that the ".sun3" or ".sun4" part of the extension is not necessary if you are only going to be using Cellsim on one particular Sun model, e.g. ".m256.o" is a valid extension. ".cmap": colormap files with 16 entries (standard colormaps from the previous versions of Cellsim). ".cmap.256": colormap files with 256 entries We recommend that users adhere to these conventions when creating their own files, for three reasons: first, to make it easier to keep track of which files go with which options; second, to facilitate the exchange of transition and image files between users at different sites; third, because if you use these conventions, Cellsim will automatically switch into the proper neighborhood and/or image size when loading a file, if necessary. **************************************** SAMPLE FILES Some sample rules and images are supplied with Cellsim. See the file "sample.files" for a partial list of these. We would like to strongly encourage Cellsim users to submit any interesting rules they discover, and any images that accompany them. We would like to collect a user-contributed library of rules/images to be distributed with later versions of Cellsim. Images and lookup-tables are most easily submitted by compressing them, running them through "uuencode", and then mailing them. Rule source-code can just be directly mailed. Rules and images should be sent to the addresses listed below. **************************************** AUTHORS The SunView version of Cellsim 1.0 was written by Charles Ferenbaugh. It was adapted from an earlier Apollo version written by Chris Langton. The changes to bring Cellsim to V1.5 and V2.0 were done by Dave Hiebeler. Please send any comments on this code to Chris Langton (cgl@LANL.GOV), or Dave Hiebeler (hiebeler@heretic.lanl.gov). **************************************** GOALS This simulator was developed to serve as a reasonably general, window-based tool for experimenting with simple cellular automata. We hope that by putting this tool in the public domain, we can provide a means by which researchers at a wide variety of sites can experiment with interesting CA rules and images, and swap the results among sites. This simulator will not fill everybody's needs, nor was it intended to. It was intended to provide what we consider to be the minimum necessary functionality to do useful research with cellular automata. By providing the source code as well, we hope that researchers will expand upon this basic software platform by adding other functions, features, and/or speed-hacks. We have tried to produce code which is reasonably modular and well documented so that users should be able to modify the simulator to suit their own needs with minimal trouble. In the interest of maintaining compatability between versions, we would request that anybody who adds a major feature to the simulator send us a copy rather than distributing it themselves. We will make every attempt to integrate any and all improvements - with appropriate credit given - into future versions, but we would like to do so in a manner which is consistent with our own future developmental plans. Again, modifications should be sent to cgl@LANL.GOV or hiebeler@heretic.lanl.gov. **************************************** BUGS While in `Run' mode, the program does not respond to SunView frame commands such as Close, Move, etc. However, other windows can still be used while the program is running an automaton. Also, if the window is hidden and then re-exposed while in Run mode, it will not be redrawn completely until the Run is stopped. Transition files are not checked when they are loaded; thus if an improper file is loaded, it may cause an invalid state to appear on the screen which could cause segmentation faults during subsequent lookups. The speed of updating the display on the Sun is pretty poor when the image is magnified. The display plane-mask does not work in B&W mode (it has no effect). "Learn" is not implemented for the Margolus neighborhood. The "Probe" functions do not work when using 256 states (computed-function updating). The fact that menus and popup windows don't use the colormap is terribly annoying. The CM run-delay needs to be implemented better on Vax front-ends. Right now, how long it delays depends on the speed of the Vax. What is needed is an implementation of the "usleep" routine of Suns. Cellsim should warn you if you change the lookup-table or image, and try to run on the CM without sending the changed LT or image. The "stop on" feature doesn't yet work with the Connection Machine. **************************************** /* * * Cellsim copyright 1989, 1990 by Chris Langton and Dave Hiebeler * (cgl@lanl.gov, hiebeler@heretic.lanl.gov) * * This package may be freely distributed, as long as you don't: * - remove this notice * - try to make money by doing so * - prevent others from copying it freely * - distribute modified versions without clearly documenting your changes * and notifying us * * Please contact either of the authors listed above if you have questions * or feel an exception to any of the above restrictions is in order. * * If you make changes to the code, or have suggestions for changes, * let us know! If we use your suggestion, you will receive full credit * of course. */ /***** * Cellsim history: * * Cellsim was originally written on Apollo workstations by Chris Langton. * * Sun versions: * * - version 1.0 * by C. Ferenbaugh and C. Langton * released 09/02/88 * * - version 1.5 * by Dave Hiebeler and C. Langton May - June 1989 * released 07/03/89 * * - version 2.0 * by Dave Hiebeler and C. Langton July - August 1989 * never officially released (unofficially released 09/08/89) * * - version 2.5 * by Dave Hiebeler and C. Langton September '89 - February 1990 * released 02/26/90 *****/