Previous Section - WWW Site - Documentation - Tools

6. Extending can easily be extended in several ways:

  1. fix a bug
  2. make a tool method faster or cleaner
  3. add a new method or setting to a tool
  4. add a new tool
  5. add a generically useful script to the scripts dir
  6. add a script that does something interesting to the examples dir
  7. send a picture or movie you made with for the WWW page.

You might be able to do (2) because you're better with Python than we are! Note that generally, we've opted for simplicity versus speed in writing the tools, unless the operation is very costly. An example of something I'd like to speed up is the reading of large dump files in

Some of the ideas we've had for (3), but haven't gotten around to, are listed at the top of the src/*.py files as ToDo items.

If you think your addition will be useful to other users, email it to and it can be added to the distribution with an attribution to you, both in the source code and on the WWW site.

Here are ideas to consider when creating new tools or scripts:

(1) For tools, your *.py file should contain a Python class with the same name as the *.py file since it will be imported into with a statement like

from dump import dump 

(2) Your scripts can use methods from classes to make data analysis easier. E.g. scripts can be written that use the dump tool to read dump files, then use the iterator calls and vecs() method from to loop over snapshots and extract lists of particles for further computation. See the scripts and examples directories for examples of this.

(3) To flag an error in your script or tool and exit back to the prompt, use a line like:

raise StandardError,"error message" 

(4) Document your tool be defining the "oneline" and "docstr" variables at the top of the file. This is what will be printed when you type "? dump", for example.

(5) If you intend your tool to interact with other tools, you should follow the philosophy of having objects be passed as arguments to the tool methods. If you're creating a tool that is similar to an existing tool, but a different flavor (e.g. wrapping another plotting package in addition to MatLab or GnuPlot), then try to make the interface similar to the others so all the related tools can be used interchangeably.

(6) From the perspective, the difference between a script and a tool is as follows. A script typically does a specific operation (with or without arguments). E.g. process a dump file and compute a quantity. A tool version of the same operation would allow it to store internal state and persist, or to be packaged in a way that other tools or scripts can create instances of it and call its methods. From the Python perspective the code for the 2 cases may not look very different. The tool version might just be some Python variables and methods stuck inside a Python class, which is what a tool basically is.

(7) The various tools are mostly related to the "LAMMPS" molecular dynamics or ChemCell cell simulator packages. But of course you can write tools that have nothing to do with LAMMPS or ChemCell. If you think they will still be of general interest to users, you can send them to us to include in the distribution. Or you can keep the top-level file, throw away the LAMMPS and ChemCell tool files, build your own toolkit for whatever application you wish, and use or even distribute it yourself. That's the open-source philosophy.