(1) DISK names and policies
=======================
The new VAXGS disk names are:
WSGS02$DKA0:[MACROSCRA.user] = DISK$SCRAUSA0:[user] on node WSGS02
WSGS02$DKA100:[MACROSCRA.user] = DISK$SCRAUSA1:[user] on node WSGS02
$1$DKD100:[MACROSCRA.user] = DISK$SCRAUSA3:[user] on node AXPGS0
$1$DKD200:[MACROSCRA.user] = DISK$SCRAUSA4:[user] on node AXPGS0
$1$DKD300:[MACROSCRA.user] = DISK$SCRAUSA5:[user] on node AXPGS0
These disks are made available in order to make the MACRO RUN data
monitoring at Gran Sasso more manageable. We certainly DO NOT WANT
these disks to be underused; however, whatever has to do with MONITORING
the MACRO detector will have the FIRST PRIORITY. In any case, if you use a
big fraction of the disk space you must alert us of your plans or risk
instant deletion of all your files if the space will be needed. No specific
USER/QUOTA scheme is established for any of these disks. If you need to
gain access to any of this area please send me an e-mail with a disk
quota number you think you need.
General disk cleanups will be performed when disks are 95% full. A week's
notice will be given on such occasion by posting news on VAXGS MACRO.GENERAL
NEWS folder and the macro-general@cithe502.cithep.caltech.edu mail
distribution list. Currently, NO BACKUP of these disks is performed.
Backups are expected to start taking place ASAP.
The UNIX (rsgs02) disk names are (I remind you that a relevant mailing
to the macro-general list was already posted back in Aug.96):
/macrous1
/macrous2
/macrous3
/macrous4
All the unix disks come with no USER/QUOTA limitation. Same policies
though apply.
(2) MACRO data runs kept on VAXGS
=============================
These can be found (RAW format) in:
DISK$SCRAUSA3:[MACRODATA]
DISK$SCRAUSA4:[MACRODATA]
DISK$SCRAUSA5:[MACRODATA]
This is in order to facilitate central monitoring of the MACRO detector.
There is way more CPU power available on VAXGS compared to VXMACB, something
that makes running any sort of monitor/analysis/DST program faster.
Moreover running code with local data files makes things easier as they
are not subject to the rather flaky VXMACB-VAXGS connection.
In addition, MACRO RUNs that need to be examined more carefully because
of any sort of problem, may stay there for as long as it is needed.
If you need to ftp/copy any MACRO RUN please grap it from the above areas
AND NOT from VXMACB directly. Although not fully established, excessive
network accessing of VXMACB/A may lead to MACRO RUN crashes.
Once every hour between 07:00 and 22:00 an automated job copies
from VXMACB the latest MACRO RUN to one of the above areas. MACRO RUNs
stay there until everyone who has notified me that he/she runs any sort
of post-run jobs has done do. Please notify me if you want to run any
post-run jobs and you want to make sure that MACRO RUN files are not
deleted from that area before you process them.
(3) Calibration-related files
=========================
The vast majority of calibration related stuff are handled through
the MACROCAL account and point to DISK$SCRAUSA4:[MACROCAL]
A number of subdirectories in this area are used to facilate all the
calibration-related work: (a) all MACRO calibration runs are now stored
separately and it we expect to make a separate DLT tape with all them,
(b) all TRK/CAL files produced automatically by BMON at the end of each
run (on VXMACB) and used to produce all calibration constants are
automatically copied once a day to VAXGS and archived periodically on tape,
(c) a short ntuple profile for each calibration run is kept for quick
calibration quality check and easy histograming (accompanying kumacs
in order to have a quick look at these ntuples may also be found in
the same area).
(4) RUN-BY-RUN data checks
======================
This is our primary tool for looking at the current state of the MACRO
detector. There are three offline analysis jobs that run automatically
at the end of each run and have as a primary goal to check if there's
anything wrong in our MACRO data. This includes my general
MACRO/scintillator checking job that creates a family of files for each
run in DISK$SCRAUSA3:[EXTENDED_LGB.V3_2]. Ed Kearns' WFD-checking job
creates output in DISK$SCRAUSA3:[EXTENDED_LGB.KWFD].
Chuck Lane's cSPAM system's checks are also performed automatically on
a daily basis. General MACRO/scintillator and WFD-related summary files
are all stored and archived in order to be always available for problem
debugging and run checking for data analysis.
PLEASE if you have any piece of code that can be used to check the
quality of the MACRO data, we would like to make it part of this automated
run-by-run processing. We would like to set up a central data processing
mechanism here at Gran Sasso that starts with prompt identification of
any problem with MACRO.
(5) DST production mechanisms
=========================
With more disk space available we would like to have a collaboration-wide
useful DST production mechanism. Although a unix-based DST mechanism will
soon be under way, we would like to benefit from every (both in unix and
vms) effort put so far toward this direction by every MACRO collaborator.
I have made an attempt to come up with a DST scheme that will select
classes of events for which the WFD data will be desirable (see Frascati
meeting transparencies). The so-called "RARE PARTICLE" DST are still
need to have their LIP and upward going muon section refined.
You may find such DSTs (nominally up to 2-3 days old -- after that I
copy them to tape) in the following areas:
DISK$SCRAUSA3:[RAREDSTS]
DISK$SCRAUSA4:[RAREDSTS]
DISK$SCRAUSA5:[RAREDSTS]
If you have already some DST production scheme that you think can be of
interest to other members of our collaboration, please let us know.
This is the best time to collect the input from all members of our
collaboration.