System Requirements, Features, Missing Features, and Bugs

Contents

• System requirements
• Features
• Missing Features
• Bugs

System requirements

• Fungimol has been tested on Linux Mandrake 6.1. The documentation that came with Linux Mandrake 6.1 says that Linux Mandrake 6.0 is equivalent to Red Hat 6.0, so that might be equivalent to Red Hat 6.1.
• The binary distribution is compiled to work with glibc (libc.so.6). If you don't have glibc, you'll have to download the source for Fungimol and compile it yourself.
• I'm using a 600 megahertz Pentium III. If your computer is slower, then the program will run slower. Most editing operations are quite fast, so they'll still be tolerable on a significantly slower computer. However, molecular dynamics simulations are inherently time-consuming; the simulation in the tutorial takes 10 minutes on my computer.
• X Windows is required, running at 16 bits per pixel TrueColor with a depth of 15 or 16 bits, or 32 bits per pixel TrueColor with a depth of 24 bits. To find out the bits per pixel and depth for your server, be sure you are running your X Windows server and give the command:

  xdpyinfo | grep depth | grep bits
  

  If you see any of these lines:

  depth 16, bits_per_pixel 16, scanline_pad 32
  depth 15, bits_per_pixel 16, scanline_pad 32
  depth 24, bits_per_pixel 32, scanline_pad 32
  

  then you can use Fungimol. Otherwise, you must reconfigure your X server before you can run Fungimol.
• A typical invocation of the program uses 22 MB of virtual memory. X Windows consumes another 38 MB of virtual memory, so you will probably want to have 64MB of physical memory total.

  I have successfully worked through the tutorial on a 32 MB 300 Mhz system. DesignAtoms are slower than I would like; on this machine I found myself stopping time when navigating through the scene because it sped up the animation.

• The UI requires use of the middle mouse button. Some mice have only two buttons. The XFree86 server can emulate a three button mouse by generating a logical middle button click when physically the left and right mouse buttons are pressed at the same time; it is feasible to work through the tutorial in this configuration. However, I once bought a a Logitech 3-button mouse for less than $20 that plugged in the same slot as my old Microsoft 2-button mouse and the middle button worked without any software changes, so buying a three button mouse might be a better solution.

Features

• can display and animate atomic structures.
• can read and write .pdb files (except see the caveats in the Missing Features section).
• comes with a working copy of Donald Brenner's hydrocarbon molecular dynamics code.
• can read and write .d files that are read and written by Brenner's hydrocarbon molecular dynamics code.
• can play movies of molecular dynamics simulations generated by Brenner's code.
• includes generic Linux joystick support, as well as specific support for a SpaceTec Space Orb 360.
• has a general plugin architecture, so that new commands, new classes of physical objects, new window systems, and new input devices can be added to the program without modifying it.
• has source code available subject to the GNU Library General Public License. Among other things, this permits creating and distributing proprietary plugins for Fungimol under some circumstances.

Missing Features

• There is no Microsoft Windows port yet.
• Not all of the features of .pdb files are supported. The connections among the atoms within an amino acid, as defined by ATOM records, are not added. Only HETATM and CONECT records are fully supported; ATOM records are treated like HETATM records and all other records are ignored.
• Only space filling and wire frame display of atoms is supported. No balls and sticks yet.
• Brenner's molecular dynamics code is not integrated at all. You manually give commands to write files, then run the molecular dynamics simulation in a separate process, and read the result. This prevents using the mouse to interact with a molecular dynamics simulation as it progresses. However, you can read partially generated movies as the simulation progresses, and you can use editing commands to position the movie in the scene graph or to make some of the atoms invisible so you can see the rest.
• 8 or 1 bit per pixel displays are not supported. If you have a computer that is new enough to run Fungimol but is nevertheless stuck at 8 bits per pixel, send me email and I'll give a higher priority to supporting an 8 bit pseudocolor display. I am not enthusiastic about supporting a monochrome display.
• You cannot undo changes, so save your scene often. You generally want to save it as a .pdb file, since the links will not be preserved in a .d file.
• There is no menu system. You can interact with the scene using the mouse, and using the keyboard essentially as a large collection of extra mouse buttons. Text-based commands are performed by interacting with the standard input and output of the Fungimol process, instead of with menus.
• There is no way to save the scene that saves all of the information in it. The best you can do with this version is save a .pdb file. This loses information about the different types of atoms in the scene; when you restore, they'll all be BoringAtom's.
• Some of the commands change the depth of the selected object. Because we use an orthographic projection, this is completely invisible unless the change in depth causes an object that was behind the selected object to be in front of it, or vice versa. We could provide better depth feedback by drawing the coordinate axes and drawing lines from the center of gravity of the selection to the coordinate planes.
• There is no way to save your edits to the configuration.
• When interpreting file names, Fungimol doesn't interpret ~ as the user's home directory. So if my home directory is /home/tim and I want to read ~/foo.pdb, I have to type the filename as /home/tim/foo.pdb. If the current directory is my home directory I can simply use the filename foo.pdb.

Bugs

• This is more of a design tradeoff than a bug, but in any case it is a feature to beware of: space is limited in extent. If any atom is out of bounds, it is likely to be deleted. The default boundary is 128 Angstroms from the origin in the X, Y, and Z directions.
• If you make a macro that includes more than one Action, and any of those Actions grab the mouse, then all of the Actions get all of the mouse events instead of just the Action that grabbed the mouse.
• If you make a macro with multiple commands, and the first deletes an object, then the second will see a null object in the scene. In normal circumstances, an Action will not see null objects in the scene unless it deletes some objects itself, and this should still be true when Actions are incorporated into macros. In other words, the Macro Action should tell the scene graph to garbage collect but it does not.
• The protocol for PhysicsObjects allows an implementation of laws of physics to determine what links extend from an object and what is at the other end of those links, but it does not allow following the links any further. Thus with the present interfaces you can't have torsional forces on bonds, since computing those forces requires considering four atoms where the first and last do not share links to any other atom.
• Applying the shift buttons to the mouse is not intuitive. One would like to be able to press the control button and the right mouse button, then release the control button while holding the right mouse button, then press the shift button while still holding the right mouse button, and at the end it should behave as though you are using the shifted right mouse button. Instead, it continues to behave as though the control key were down. To use shift right mouse after using control right mouse, you have to release the right mouse button and the control key before pressing the shift key. The same troublesome scenario applies when using the middle mouse button, or when changing from shift back to control.
• The buckygun in the tutorial leaks hydrogen. There are several possible explanations for this. Perhaps a 10,10 buckytube is not really a tight fit around a buckyball. Perhaps Brenner's dynamics program makes the buckyball too small. Perhaps it makes the buckytube too big. A literature search would narrow down the possibilities by telling me the correct diameters for the buckytube and the buckyball, but I haven't done that yet.
• Rotating the atoms in a movie as it is playing leads to the display of meaningless information. Translating all or part of a movie does what you might expect, as does changing the point of view and marking some of the atoms invisible.