FULL_D0RECO V12.21 on the AXP
Ransom Stephens
April 16, 1996
FNALD0::STEPHENS
Here are a few notes to help you install FULL_D0RECO on your DEC AXP
machine
running openVMS V6.1. Basically the idea is to copy over what you'll need
from
my nodes where it's all been tested, debugged and otherwise beaten into
submission.
By the way, please send me an e-mail (FNALD0::STEPHENS) when you install
the
code so I can monitor how much use FULL_D0RECO on the AXP is used.
I. Building the PROD area:
--------------------------You need to have the logicals PROD$FULL_D0RECO and PROD$FULL_D0RECO$ROOT
in your LNM$D0 table. This is accomplished by including the line:
$ define inhibit_D0prod false
before
$ @d0$disk:[d0library]d0startup
which is in your SYSTARTUP_VMS.COM file in the SYSTEM account. You will
then
have a "top" area: PROD$FULL_D0RECO:[000000]. You also need a "new" area,
PROD$FULL_D0RECO$ROOT:[NEW], so execute
$ create/dir [.new]
from your PROD$FULL_D0RECO$ROOT:[000000] area.
II. Copying the relevant files from the UTA AXP cluster
------------------------------------------------------Now you can copy over everything you need to build a functioning
production RECO area. It's easiest to do this with DECnet. However it's
possible that your DECnet database may not have my node, UTALF1, included
on it. The way to tell is with the NCP command:
$ MC NCP SHO NODE UTALF1
If this doesn't show a DECnet address then you'll need to route through a
machine which does have UTALF1 in its database. A FNALD0 node which you
probably have set up and which has UTALF1 is D0UTA1 (2 or 3 also).
If you can access UTALF1 through DECnet, then set up
$ define uta_reco UTALF1::ALF1D2:[D0LIBRARY.D0PROD.D0PRODUCTION.FULL_D0RECO]
$ define uta_reco_new UTALF1::ALF1D2:[D0LIBRARY.D0PROD.D0PRODUCTION.FULL_D0RECO.NEW]
If you can't access UTALF1 you can route through D0UTA1 with
$ define uta_reco D0UTA1::UTALF1::ALF1D2:[D0LIBRARY.D0PROD.D0PRODUCTION.FULL_D0RECO]
$ define uta_reco_new D0UTA1::UTALF1::ALF1D2:[D0LIBRARY.D0PROD.D0PRODUCTION.FULL_D0RECO.NEW]
Then you can get what you need, where you need it, with
$
$
$
$
$
set def prod$full_d0reco$root:[new]
copy uta_reco_new:*.* *.*
set def prod$full_d0reco
copy uta_reco:*.RCP *.*
copy uta_reco:*.DAT *.*
This includes everything you should need including the executables and
consists
of about 120,000 blocks of disk space (so the copy will take a while).
You will not be able to link up your own executables since this process
doesn't include building all the production libraries, but you won't need
to anyway.
III. Getting started --- a test run
-----------------------------------To get started, there is a file of five geanted events in your
PROD$FULL_D0RECO$ROOT:[NEW] area: TEST.GEN, and a file which you can use
to submit a trial RECO job, RUN_RECO.COM. You can also use this file as
a template for other runs of RECO. If this fails we'll need to regroup
and figure out why. In this event, you should send me mail and we can
sort it out.
IV. Dealing with bugs in FULL_D0RECO
-----------------------------------In the event that you find a bug in FULL_D0RECO, i.e. the executable
crashes on a given event, you should
1) set the WRITE_E_FILE flag TRUE in D0RECO.RCP. This will write the
event to
disk.
2) check that FULL_D0RECO crashes on this single event.
3) E-mail me the log file from the run and the
disk:[directory]filename.dat
of the event so that I can copy it over and go through the debugger.
This should streamline the process of debugging.
V. Differences between VAX FULL_D0RECO and AXP FULL_D0RECO
---------------------------------------------------------For V12.21, the code running on the various platforms, including the AXP,
is all
the same. In verifying RECO, I compared almost 300 histograms run on 500
top
events. There were only the smallest descrepancies. The worst of
these had a few entries in the VAX histogram appearing in different bins
on the
AXP histogram. I am lead to believe, by the experts, that the observed
differences are attributable to round-off differences between the 32 bit
VAX and
the 64 bit AXP. The vast majority of histograms are identical on both
platforms. There are also some messages in the LOG files which differ.
Again,
the experts assure me that this is a result of the differing
architectures.