When you are developing a new force field, it is not a good idea to deposit partially developed files in the official Yup package directory. You probably do not have the permission to do that anyway. This is not a barrier to developing your own Yammp code. The following is a suggestion on how to set things up. Most people have a place to store their own programs. In UNIX, this is usually a directory called "bin" that is located directory in your home directory. Your login resource files would have this directory added to your search path. Similarly, you may have a place to store your own libraries. For Python, you then need to define the environment variable PYTHONPATH to contain this directory. For example, if you have a directory called "lib" in your home directory (to hold library files) and a sub-directory called "python" to hold Python packages, how and where you define the appropriate variable depends on your shell. Shell File Definition Bourne-Shell (sh, bash, ...) ~/.bashrc export PYTHONPATH=~/lib/python C-Shell (csh, tcsh, ...) ~/.login setenv PYTHONPATH ~/lib/python Inside the directory defined for PYTHONPATH, you would create a package named something other than "Yup", for example "devYup". It is necessary to avoid the name "Yup" because you would need access to the Yup package. Remember that Python requires that each package directory and each sub-directory contains the file "__init__.py" which may be empty. This file marks the directory as being a part of the package. In your package directory, create two sub-directories named "Data" and "Models" (and add the file "__init__.py" to each). Create "Tools" if you are going to be developing utilities that can be generally used. In each of "Data" and "Model" create a sub-directory named for your model, for example "MyModel". lib python devYup __init__.py Data Models Tools __init__.py MyModel __init__.py MyModel __init__.py ... __init__.py source-of-constants __init__.py ... In Data/MyModel, create the file "source-of-constants" to hold your force field parameters. When you are happy with your data, compile it by going into that directory and typing the command "Yup.fpf". This creates several database files. You will be saving your force field assembly programs in Model/MyModel/. It is the custom to name the file containing the force field assembler program "FFA.py" and the analysis program "Analyzer.py". These files package routines that you want to present to the user. These routines may call other routines that you may not want the user to see; those you would place in other files with all lower-case names. it is not necessary to observe this custom. The important thing is that you can make use of local imports between these files. For example, if "FFA.py" imports from another file "consts.py" in the same sub-directory, the import statement in "FFA.py" would be something like: "from const import ..." instead of "from devYup.Models.MyModel.const import ...". The latter is correct but unnecessarily long. The local import is simpler and need not be changed when the files for your model is installed within the official Yup package. If your program needs to import objects from the Yup package, you would write a statement like: "from Yup.Tools.... import ...". This need not be changed when your model is installed in the final location. If you are also developing general-purpose tools (in MyYup/Tools/) you would be importing objects using statements like: "from devYup.Tools.... import ...". Such statements need to be changed when your tools and models are installed within the official Yup package. All the revisions will involve only the change of the word "devYup" to the word "Yup" in all import statements. One of the fundamental things that your force field has to do is to identify a default force field parameter library (devYup/Data/MyModel/ in this example). (Users should be able to override this and specify their own data source.) Yup.Tools.misc defines a function datasource() that accepts a string containing the model name and returns the absolute path to the appropriate data directory. For example, datasource('Worm') returns the path to Yup.Data.Worm in the official Yup package. This does not work for the data installed in your own package directory. One solution is to copy the module Yup.Tools.misc to your own devYup/Tools/ directory and edit the source for datasource() to reflect your own package name. Then, you can use the datasource() function (imported from your own devYup.Tools package directory). The happy outcome of this strategy is that when your model is installed within the official Yup package, all revisions are of the same kind: to revise all import statements containing the word "devYup" to "Yup".