Please feel free to ask questions in the comments so I can make this as complete as possible:

Accessing the L2 machine:

you will need a stargw account, and usernames and passwords which I won't be posting here.  The path is:

rssh.rhic.bnl.gov -> stargw.starp.bnl.gov -> startrg.starp -> l2ana01.trg.bnl.local

It is important to note that this is a real time machine.  Don't do any heavy lifting on it, and DO NOT USE vi -- it has a weird failure state if the pipe to an external machine is lost, and will cause L2 to time out on triggers.  other text editors don't seem to be affected, but the number of processes running should be kept to a minimum during the run.

Locations:

setup files:  /home/developer/emc_setup

log files: /trgData

source code: /home/developer/developer_l2, other places.

The directory you will land in when you ssh is /home/developer , in which three scripts can be found:

setup_developer_level2 will take the currently used versions of the l2 software and copy them into developer_l2/ .

start_developer_level2 will kill the 'live' version of l2new and start the version in the developer_l2/ directory.

start_production_level2 will restore the 'live' version.

The workflow that I recommend is to run setup_developer_level2, then modify the code in that directory as needed.

L2algorithms are referenced in l2new.c both near the top, where they are declared, and a good deal further down in the event handling loop which will call them during the run when appropriate.  (searching is probably the best way to get there)

There is also code that controls the initialization of the various algorithms, algo_handler.c, that loads the algos with the appropriate parameters, either from run control directly, or more likely through a setup file.  (the particular version of the setup file is defined by run control)

There is one more header, l2Algorithm.h, that defines the offsets used for each algorithm when writing into the L2Result block that is saved with each event.  I strongly recommend that this header file be updated to include new definitions for the 2011 values, so that there is no confusion if/when this is added into CVS at the end of the run.

Two directories contain all of the L2 algorithm information -- alg_include and alg_lib.  When making changes to the L2 algorithms, these directories are created elsewhere and then imported to developer_l2 to replace the versions setup_developer_level2 will place there.

To modify and compile the L2 algorithms:

create a new directory in /home/developer, and copy the L2 algorithm directory strucutre from rcf to there.  It will be easiest if you copy over a currently working version of the makefile, test code, etc., which can be found in rcorliss/ .  

The work flow in here is to edit the algos, then from the onlineL2 directory compile them with 'make lib'.  This will update the contents of alg_include and alg_lib, which can then be copied over to developer_l2.  If you are having problems, it's possible one of the items in these directories has become stale somehow, in which case make clean, or make clean2 will remove them and allow them to be recompiled.

Once you've updated the contents of developer_l2 as desired, compile in that directory with 'make' (I believe).  You can then start_developer_level2 for testing purposes (do not do this when data is being taken!).  When testing is done, restart the real l2 with start_production_level2.

The log files can be found in /trgData.  All of the L2 logs end in .log and will have the run number as part of the filename.  Since this is where all log files are stored, you'll save a lot of pain by not typing 'ls' or 'll' without a search string.  Searching for a certain run number will be sufficient.

As I see it, the duties of L2 algo maintainer are:

1) Allocate the space in the L2Result array (64 ints) to the various algos by definig the offsets in the l2Algorithm.h header file, and making sure the proper offsets are referenced when the algorithms are declared in l2new.c .  Check the source code of all the algos being used to make sure they do not exceed the size they report.  (this can also be done by printing the contents of the L2Result)

2) Make sure the algos are not wasting resources -- they should not print anything to screen, etc.  You can check this by looking at timing plots produced alongside the log files.  These will show you how long each algo takes to make a decision.

3) Verify that all the algorithms 'work'.  This means they should be called at appropriate times and should return sensible values (not crash).  It isn't the maintainer's duty to make sure they do exactly what they're billed as doing - that's for the maintainer fo that particular algorithm.  This will entail checking that they appear correctly in l2new.c, are initialized properly in algo_handler.c, are attached correctly in run control and are defined with the correct setup.

4) Update the algorithms as requested, add new ones as requested.  Hopefully this won't come up, but there are many features and conventions that should be observed if new algos are desired.  I'll leave this for a later post.

To follow later:

1) what the algos do and how they interact

2) how to test them in multitest.c