Info for PLOP Contributors

 

 

PLOP is now under CVS control on my computers are UCSF.  If you haven't used CVS before, it is a version management system that makes it much easier for several people to work on the same code simultaneously.  It keeps track of who's changed what, and alerts you if 2 people have modified the same portion of the code, thus creating potential conflicts.  It cannot, by itself, keep track of why things have changed, or if incompatibilities have arisen for some other reason, so please document your changes carefully when it prompts you.  CVS also works best when changes are checked in frequently (i.e., each day).  For one thing, if you don't check in your changes frequently, it's unlikely that you will be able to document what you've done.  Also, if many different changes are checked in at once, it can be more difficult to pinpoint precisely when a bug was introduced. 

 

There are 2 basic scenarios:

  1. You want to make a bug fix in PLOP.  First, PLEASE don't just make the bug fix in your own personal copy of PLOP.  Check out PLOP from CVS (see below), make the change, and then check it back in, documenting what you have done.
  2. You are working on a major change/addition to PLOP.  It is of course not a good idea to just check in code that is likely to be unstable or buggy.  So the right thing to do is to create a "branch" in CVS.  This basically creates a version of the code that only you will modify, until you think it is stable.  That is, any code you check in will not affect the current executables, until we merge the changes you made back into the main branch of the program. 

 

If you have an account on thales:  You need to set the environment variable CVSROOT to /home/jacobson/cvs_plop.  To check out the code, you would then type "cvs checkout plop".  Note that this will create a "plop" directory that will contain the src/ and data/  directories, the Makefile, the loop_refine script, etc., all of which are under CVS control.  You can then make whatever changes you wish.  To check the changes back in, use the "cvs commit" command (I can show you how), which will then prompt you to document what you've done, for each file you have modified.  When you are done, you can use "cvs release plop" to essentially disconnect from CVS.  Note that, by default, the plop directory and all its contents will NOT be deleted.  However, any changes you make after "cvs release" cannot be checked back in.  The main value of the "cvs release" command is that it will let you know if files have been modified but not "commit"ed – it can be easy to forget what you've changed, and if you don't commit it, it could be lost. 

 

If you don't have an account on thales:  I have set up a new account called "plop" to allow access to the CVS.  Ask me for the password and how to get there.

 

A couple other requests.  Please try to adhere to Fortran 90 conventions as much as possible.  I have tried to remove "goto" and "continue" statements, and other obsolescent features left over from Fortran 77 such as numbered lines.  It will just make the code much easier to maintain.  Although it's nit-picky, please try to adhere to the same conventions for indentation and other formatting.  It's more than just a matter of having ugly code ... it can become very difficult to read if each section is formatted differently. 

 

I am trying to maintain the code such that it can be compiled either with or without dynamic memory allocation.  I do this by using the DYNAMIC compiler flag.  Then I declare arrays both dynamically and statically in the code using, e.g.,

 

#ifdef DYNAMIC

            integer, allocatable :: array(:)

#else

            integer array(mpoints)

#endif

 

and then

 

#ifdef DYNAMIC

            allocate(array(npoints))

#endif

 

The ability to compile the code without dynamic memory allocation is extremely valuable, because it enables the use of more powerful run-time bounds checking procedures.  It makes it easy to determine if a bug is due to memory problems or something else.

 

One other thing that we should really try to do is take advantage of the Fortran 90 "intent" statements, which make it MUCH easier for the compiler to find incompatibilities between subroutines and their statements that call them.