IPS Development Workflow
The structure of the
ips tree in the Subversion repository is meant to provide an environment in which to both develop and build the IPS. Running the code takes place elsewhere, and uses a directory structure different from that of the Subversion repository.
Where is the Code?For development purposes, the
ipstree holds the component wrapper code, framework utilities, etc. as well as documentation and support files for this aspect of the IPS. The IPS also depends on large physics codes, which are used essentially unmodified from their standalone forms. The large physics codes are not kept in the
ipstree for a couple of reasons:
- As long as we're not making (substantive) changes to the physics codes in order to use them in the IPS, we don't want to force the code owners to change their established approaches.
- Many people will be using only a subset of the physics codes, and we don't want to force everyone to download lots more code than they actually need by putting all of them in the
Say you are working in a directory
MyIPS. The way you would want to setup your workspace is as follows:
- Check out the
ipstree, with a command like
svn co https://cswim.org/svn/cswim/ips/trunk ips
- Check out the physics programs you need in to the same directory (
MyIPS). The commands will vary depending on which version control tool and the repository location, but you should find everything you need listed here
Once you're done, your
MyIPS directory might contain the following directories:
For parallel development, you can simultaneously maintain several directories at the
MyIPS level, each with its own copy of the
ips tree and the appropriate physics codes, and they will not interfere with each other. (You could also do this one level down, but it might be a little trickier to get right.)
Configuring and Building the CodeIn order to satisfy dependencies within the
ipstree, you probably need to begin by configuring and building the physics codes. They should be configured to install into the
ipstree - executables into
ips/bin, libraries into
ips/lib, etc. If the code conforms to the usual GNU autconf conventions, you would configure it with
configure --prefix=../ips. (I realize that at present many of the physics codes are not setup with a notion of being "installed", or at least not so flexibly. This is one change we will want to make, it should not be very hard or intrusive to do.)
In the example above, you would configure and build the
cql3d directories, and install their products into
Configuring and building within the
ips tree should be straightforward. The default installation location will be the same as for the physics codes - into the
ips/lib, and other such directories (if you want to install somewhere else, the
ips configure system should take a
--prefix argument to specify this.) Each part of the
ips tree should build within its own subtree, and then a second
make install pass would put the final products into the "permanent" locations.
Where to do Development?Most code development will take place in the
ipstree, and more specifically within the part of the
ips/componentssubtree appropriate for whichever component you're working on.
Typically, you will want to follow a scheme of successive refinement. For example,
ips/components/rf might contain all of the wrapper code associated with all the different RF codes supported within IPS. It may be possible to share some code across specific components, while other code may be specific. So we might have
ips/components/rf/toric as subdirectories.
It is safe to put all IPS-related code somewhere in the
ips tree. However if you are doing something that is associated with a specific physics code, and may be useful for standalone users of the code too (i.e. outside of the IPS context), then you should consider adding it to the physics code's repository rather than the
Running the CodeThe directory and file structure of an executing IPS job is not associated with the Subversion repository structure.
The IPS should generally be run somewhere outside the
ips tree - typically on a high-performance filesystem attached to your target machine. You can use the executables, scripts, and libraries you've built with some simple changes to your shell environment, most of which can be automated.
Last modified 2010-10-28 13:39