NB(1): If you screw this up, you may make impossible to download SVT, impossible to emulate SVT offline, and perhaps even difficult to recover the history of what was downloaded into SVT as a function of time (which we have tracked in the hardware database since December 2001)
NB(2): A new script will be forthcoming that will make these instructions obsolete and will make the process much less error-prone. Until that script exists, this job must be done very carefully. Sorry about that.
Here's what Roberto, Alex, and I did, 2002-10-01, with Alex typing, to install Roberto's updated superstrip map for wedge 0, updated patterns for wedges 0 and 9, and updated layerMap for wedges 0 and 9.
Before you begin, explain to the CDF sci-co that you want to update SVT's patterns / fit constants / whatever, ask the sci-co and ace if you can borrow the SVT crates for half an hour, and then book all eight SVT crates in your own Run_Control. How to use Run_Control is beyond the scope of this document.
OK, here we go.
First log into b0dap30 or some other online Linux PC, set up the relevant software, and make sure you're in cdf_svt's home directory.
ksu cdf_svt setup -d svtvme setup fer cd
Then look what .mapset files may be lurking in cdf_svt's home, note that they are unimportant (or archive them somewhere else if they're important), blow them away to avoid confusion, and extract the latest .mapset file from the database.
ls -ltr *.mapset rm *.mapset mapset get cp offline_100030_20020927111044.mapset offline_100030_20021001000000.mapset
Note that in today's case, the latest .mapset file from the database was called offline_100030_20020927111044.mapset, and we are creating a new temporary file (not database entry) called offline_100030_20021001000000.mapset. You can see what's the latest, greatest by visiting http://www-cdfonline.fnal.gov/svt and following the 'map' link.
Now edit the new file (e.g. emacs -nw offline_100030_20021001000000.mapset) and make the following changes:
% diff offline_100030_20020927111044.mapset offline_100030_20021001000000.mapset < mapsetCrc 2144605579 > mapsetCrc 0 > # 2002-10-01 RC,AC,BA: changed w00 and w09 patterns < w00_layerMap X01X235|X0123X5|X0123X5|X0123X5|X0123X5|X0123X5 < w00_pattFile 20020927_w00.patt < w00_ssFile mixed_20020927_w00.ss > w00_layerMap X01X235|X0123X5|X0123X5|X0123X5|X0123X5|X01X235 > w00_pattFile 20020929_w00.patt > w00_ssFile mixed_20020929_w00.ss < w09_layerMap X0123X5|X0123X5|X0123X5|X012X35|X0123X5|X0123X5 < w09_pattFile 20020927_w09.patt > w09_layerMap X0123X5|X0123X5|X0123X5|X01X235|X0123X5|X0123X5 > w09_pattFile 20020930_w09.patt < w00_crcXTFAcrv 957766496 < w00_crcXTFAss 1804563856 ... %
Note that new files added to the database must have unique names, and existing files in the database should never, ever be changed (or else one can no longer emulate runs that used those files), so I like to encode the date in YYYYMMDD format into each (patt, ss, etc.) filename.
Now we need to run the crcmaps program to check that the code in svtsim_maps.c can properly read the files needed to configure each wedge. crcmaps also writes out a CRC of each RAM image to be downloaded into SVT, which will be compared with the actual VME board memory contents on each cold start. Before we can run crcmaps, we need to put the files into the ~cdf_svt/svtconf directory, where crcmaps (and the real cold start code) looks for them. Make sure you're not overwriting anything that's already in ~cdf_svt/svtconf (with cp -i).
cp -i offline_100030_20021001000000.mapset ~/svtconf cp -i 20020929_w00.patt ~/svtconf cp -i mixed_20020929_w00.ss ~/svtconf cp -i 20020930_w09.patt ~/svtconf
The following should run without crashing, and should print out a bunch of CRC values.
crcmaps offline_100030_20021001000000
Now run it again, capturing just the CRC files to the end of the temporary .mapset file (the one in cdf_svt's home directory):
crcmaps offline_100030_20021001000000 | grep crc >> offline_100030_20021001000000.mapset
Now remove the copy of the temporary .mapset file that lives in the ~cdf_svt/svtconf area:
rm ~/svtconf/offline_100030_20021001000000.mapset
Now stick the new patt,ss files (but not the mapset file) into the database so that the offline can see them:
cd ~/svtconf svtdb cdfonprd ashmansk 'pw' store 20020929_w00.patt svtdb cdfonprd ashmansk 'pw' store mixed_20020929_w00.ss svtdb cdfonprd ashmansk 'pw' store 20020930_w09.patt cd
Now commit the new .mapset file to the database, making it the default for future SVT cold starts.
cd mapset put offline_100030_20021001000000.mapset
Now clean up the .mapset, .patt, .ss, etc. files that you left in cdf_svt's home directory:
rm *.mapset rm 20020929_w00.patt rm mixed_20020929_w00.ss rm 20020930_w09.patt
Finally, do a cold start on all eight SVT crates from Run_Control, and make sure that it succeeds. It may take longer than usual if it has to program the Track Fitter flash memories. Then abort and do a second cold start, and see that it proceeds quickly as usual (on the order of ten seconds). Hooray, you have succeeded.
If there is lots of time before the next shot, you may want to replay fake hits through SVT for a while and make sure things seem to work properly.
You definitely want to make a note in both the SVT e-log and the shift e-log noting the update, and you probably want to make sure the person carrying the SVT pager will be easily reached when the next shot goes in. Look carefully at svtspymon's output during the first run with beam with the new constants. Check offline at the first opportunity that the mismatch rate between SVT and svtsim has not increased, so that you are confident that the database is correctly doing the book-keeping of what got loaded into SVT.
Until the easy-to-use script appears, you should call Bill at 630-854-6446 (24 hours, 7 days) if you have any questions about whether you know how to do this, or if you think something might have gotten screwed up in the database update. Eventually, the database writing tool will be smart enough to make it virtually impossible to screw up. Also, please don't give out the database password; eventually, I'll try to find a way that cdf_svt can write to the database without a password.
The instructions for updating the hwset are similar (a bit easier). Log in as cdf_svt, set up fer and svtvme, and do 'hwset get'. Then edit the file that is extracted from the database (e.g. vi 20021121151215.hwset) and then write a new version with 'hwset put 20021121151215.hwset', which will create a new file, new filename, new CRC, new database entry, etc. Then delete the temporary .hwset files from cdf_svt's home directory. Because the hwset file is self-contained (doesn't refer to other files), it is much less tricky to update than the mapset file.