Plans for the PHENIX simulators' meeting

[MAGUIRC@ctrvax.vanderbilt.edu]

							July 13, 1994

Dear PHENIX simulation colleagues,

	On behalf of the simulation core group I would like to thank all those
who responded so well to the Simulation Status Report and Questionnaire
document.  A summary report of those responses is being prepared and will be
distributed at the end of the week.  A quick digest of some of the critical
items in the responses given here.  However, the main purpose of this message,
which is broken down into three sections below, is to preview the agenda for
the simulators' meeting at BNL (July 21-23, Room 2-160 reserved throughout). 
Also appended at the end is a recent message from Shaheen Tonse giving his
priorities on the necessary upgrades to the PISA/PISORP system. 

Best regards,
Charlie Maguire

P.S. A few of you (you know who you are) who have not yet responded to the
second request for SSR&Q answers will get a third request tomorrow.


  I. Quick digest of the questionnaire responses (more later this week):

	The most prevelant critique of the current simulation package was lack
of up-to-date documentation, and this is a well recognized fault.  As one
respondent remarked "obsolete documentation is worse than no documentation at
all".  In fact the PISA documents, starting from mid-1992, pre-date the use of
the WWW and we need to develop a good mechanism for keeping our documents
current. The same of course hold true for all PHENIX systems. 

	Most respondents were unfamiliar with the use of PISORP, and instead
their user event analysis routines were tacked on to the end of PISA (as in the
days of PISA 1.0), or else run as stand-alone programs using customized output
files from PISA.  It is clear that this situation needs to be corrected as it
is extremely wasteful to be periodically re-integrating one's evolving
stand-alone program back into PISORP.

	There were some pressing needs noted by some of the groups, and the
most time critical of these appeared to be in the Muon Arm subsystem.  The
simulation core is making a special effort to accommodate these users who are
spread over three institutions (GSU, LANL, and ORNL). 

  II. Outline of the simulators' meeting agenda (July 21-23 at BNL):

	The simulators' meeting by design will wrap-around Bruce Gibbard's RHIC
Computer Study Group meeting which will also be held in Bldg 510.  Bruce has
sent around a preview copy of his meeting's agenda as given below.  Based on
his draft agenda, we should get our own meeting started at 9 AM on Thursday
July 21, and continue until 12:30 PM.  We then should pick-up again at 4:00 PM
and go to 6:00 PM.  On Friday, we can meet for about one hour in the morning,
and at least 2 hours in the afternoon.  On Saturday, we can meet all day if
desired, but I would like to here from the participants about their travel
schedules.  The only constraint which I have heard so far is from John Sullivan
who must leave before the Saturday session.

	I envision our meeting's topics dividing as 2/3 + 1/3 in terms of
planning for the next releases of the second generations of PISA/PISORP +
planning for the third generation of these packages within the context of the
new integrated software environment applying to all of PHENIX computing.
Naturally these two issues are not mutually exclusive.  In terms of actual
presentations I see contributions from Shaheen/myself on the present status of
the core software, from the detector subsystem representatives on where their
simulation efforts are headed, from Hyon-Joo Kehayias on code maintenance
options, from Dave Whitehouse on the new software environment in PHENIX and the
current Requirements Audit project, from Soren Sorensen (THINC representative)
on event generators and their implementations, and from various others on what
the long-term future of the simulation packages and organizational structure
should look like.

	So far a number of persons have confirmed their presentations, but
there is still room in the schedule for other topics.  In general people should
realize that there is a slight difference between this meeting and say a
presentation at a TAC or DC review meeting.  While it will be all well and good
for people to brag about their hardware systems performances, the each speaker
should be emphasizing how other users can make use of the speaker's software.
They will be a high priority placed on specific simulation needs both for the
near and the long term, especially as to whether there is something wrong or
lacking in the current simulation systems which is impeding such specific
needs. 



    Date:     July 8, 1994
    From:     Bruce Gibbard
    To:       RHIC Computing Study Group
    Subject:  Draft Meeting Agenda

    Thursday, July 21, 2:00 - 3:30 pm, Orange Room, Bldg 510

        Reports Of Ongoing Activities

            STAR Status - 10 min
            PHENIX Status - 10 min
            BRAHMS Status - 5 min
            PHOBOS Status - 5 min
            RHIC Computing Operations - 10 min
            Oracle Status - 10 min
            Public Domain Software - 10 min

        Plan For Future Meetings

        Other



    Friday, July 22, 9:30 - 11:00 am, Orange Room, Bldg 510

        Updating the Plan/Report

            Structural and Philisophical Issues
            Experiment Needs
            Hardware Summary
            The Strawman Model
            Manpower Issues


    Friday, July 22, 1:30 - 3:00 pm, Orange Room, Bldg 510

        AFS
            Project Status
            Implications
            Discussion of Possible Plans

        Computer Security Issues

        Other



  III. Suggested priorities for upgrading the simulation packages

	Below is an unedited message from Shaheen regarding what he believes
are the important upgrades to be accomplished within the next several months or
sooner.  He and I have discussed these and we are in basic agreement on what
needs to be done.  In fact some of them are already done in my private versions
of PISA and PISORP.  My main concern is organizing the manpower and the task
monitoring to make sure that these jobs are succesfully concluded. Please
review this list and come up with you own additions or priority revisions.


							12th July 1994.

This is to give a break-down of tasks that need to be done for:
A) Pisa 2.04 (Aug. 94)  (with detail)
B) Pisorp 2.03 (Aug. 94) (with detail)
C) Pisa 3.00 (End 94) (less detail)
D) Pisorp 3.00 (End 94) (less detail)

I (ST) will put in what I think, after which CFM will modify, after
which we will modify based on what happens at the SIM meeting
21st-23rd July 94.

For each of the above, the tasks are split up into 3 categories which
should occur sequentially in time:
1) Code management tasks: 
 Setup of a new account (pisa) on tthe rhic
 cluster machines, so that we can move out of the "phenix" account
 which is getting a little crowded. I don't think this needs to be on
 disk /export1 (although it does have more space than /u1). 
2) Updating of the cmz code management tools, putting in new
  commands into the installation & compilation kumacs, and
   getting rid of obsloete commands. Geant
  user routines (gukine,gudigi etc) will be moved out of phnxcore.cmz
  and into their own cmz file. They will not be written to a ".a"
  file but instead will exist a ".o" files so that they will definitely
  be linked at link time (SGI/Ultrix problem).
3) Core programming. Porgramming of Pisa and Pisorp core subroitines
4) Sub-system programming. Porgramming of Pisa and Pisorp sub-system 
subroutines.

Items 1 and 2 are common to Pisa/Pisorp. They should be done first, 
probably by all 3 of us in consultation (HJK/CFM/ST). Item 3 for pisa 
and pisorp should be done next. I recommend that after 1 and 2 are done,then St 
and CFM copy Pisa 2.03/xx (I think xx=03 at the moent) 
set over to their computers, communicate as to who 
does what, and send correction files to HJK when they are ready. 
Item 4 should not be started unitl item 3 is 
done, to re-assure subsystem programmers that they are working in a stable 
environment. Then they can copy the Pisa2.03/zz and start working on their 
changes, sending correction files to HJK. 

(Priority level
assigned from 1 to 5 assigned to each item.) As expected, P1 items tend to
go into the early release. But based on the ease of the task some high 
priority items have been deferred and some low-priority items brought
forward.

A3) PISA 2.04 core

**New field map and access routine into Pisa & Pisorp. P1.

**Particle numbering. The Fluka particle codes defined in GPIONS
clashes with some of Pisa's numbers. The latter need to be used only
in symbolic form eg. (PARAMETER TRD_PHOTON=151)  P1. (Early release).

**Stop equivalencing holleriths and integers. Very machine dependent
and dangerous. P1.

**Option to write out Background event as a RZ file. Will 
be used for a source of background events, aceesible randomly
and quickly. Similar to what I
have done for geant866? In addition to Geant strucuteires the Pisa 
structures will be there too. A machine-independent RZ file will be 
kept on disk for users, containing simulated Pisa output. P1.

**Standard data file of 10 central Hijet and 10 central Venus events
kept at BNL for users who do not want to run 
Hijet/Venus. P3.

**Convention for the way zebra links are tested as being unused. Is
LINK=0 good enough. If so is it being used everywhere it should be? P3

**HIstogramns in Pisa? No private ones from core people. Leave a few
to monitor input Hijet/MC events. Maybe have a routine in GUKINE
called before the GSKINE call, which will fill particle kinematics
independently of the input MC being used. P4.

A4) Pisa sub-systems.

**Gverify has been set up at Cern and Pisa geometry was tested on it
November 1993 by me. Before a release, the gverify test should be
done. Since it is a test of geometry, the individual sub-det people
should be encouraged to use it on their own. P5.

**All the new code from various sub-detectors (EMCAL and Charlies 
tracking) needs to be put in. P1.


B3) PISORP 2.03 core

**New field map and access routine into Pisa & Pisorp. P1.

**Pisorp: Event merging: Is it being done correctly? If not fixit. P1

**Pisorp: Source of background events accessed randomly by an RZread
is needed, maybe 100 events or so?  Source of signal events would
happen the same way. P1.

**Convention for the way zebra links are tested as being unused. Is
LINK=0 good enough. If so is it being used everywhere it should be? P3

B4) Pisorp sub-systems

**All the new code in EMCAL and from Charlies tracking needs to be put
in. P1.







PISORP 3.00
Unlike Pisa3.00, Pisorp 3.00 might slowly change as people try out 
new algorithms etc. and want to make them publicly available.

**Look into the idea of having all the links in the link area hang off
one master link for that detector. The Pisa output/Pisorp input will be 
a lot easier then.     P5.



PISA 3.00

**The virtual volumes should go. They have servred theing: Too much old stuff carried around. Remove. 
Commons and code. One problem is the large number of 
commons in some sequences, eg. GUPHNX, which needs to 
be split into smaller sequnces. Here we will put smaller
sequnces into the larger sequnce, and let the core and sub-sys 
programmers change it at their convenience, since it will be 
backward compatible. Other things like code etc will have       
to be done more directoly, but this is mostly in the core 
routines anyway.      P2

**Standardize and support read-in of th event-generation montecarlos.
How much of BACole code can be used? Kuip stuff was good. 
Not necessarily egzebra for Venus. Make a provision to carry their information
forward through Pisa, to Pisorp and beyond. P2.

**Options for the detector cards need to be standardized. Make the
CVOLU_OPT array MEAN something. P3.

**Material/Mixture/Medium descriptions: Material & Mixture definitions
should be universal throughtout Pisa, but Media should be
subdetector-specific, so that fineness of tracking etc can be set by
each sub-detector group. Different for different detectors. Maybe even
compartmentalize MATMIXTMED into subroutines: MATMIXT for materials
and mixtures, and then
CRK_MED, ITR_MED etc. for the media. P3

**Geometrical input, eg. drift chamber parameters: Can we compile
a set of necessary parameters that will be sufficient for both Pisa
and Pisorp to use as a common set. (Is this being done well 
enough already?) This then goes into the PARA bank
and Pisorp will automatically use the correct geometry. Needs work
from sub-system programmers. P3. 


**Coding and naming conventions for subroutines/commons.
Already have CRK_??? etc. It was being suggested: PISA_CRK_???,
PORP_CRK_??? Not much trouble to do, but are we going to do it? P3

**Size of executable is getting large ("size pisa" returns ~40MB).
Solutions? Analysis control (CDF), CMZ "select" flag, large arrays in
digitization routines can be replaced by a common/scratch/, actually
already implemented, large Geant zebra banks, (GWEED), possibility of
Cern coming up with something like disk-resident data structures. P4




OTHER (DOCUMENTATION,Event Generators, Benchmarking, Code management, 
New event merging program, ?)

** Review how the WWW documentation is done and does it need
re-organizing. Ask in questionnaire whether used or not. P3

**Benchmarking. Something for HJK to do, keep track of pisa perfomance
on the different machines, for say a central Hijet event going through
ALL detectors. CPU/event, bank & store sizes, data file size. P5.

**Hijet/Venus: Are these being properly maintanied? P3.

**Merging of sub-events at a stage between Pisa and Pisorp. 
Can be done before 3.00 if at all. P2.

**Kuip CDF's : Use the kucompall.kumac file from geant866 to pull a
cdf out of a cmz file, "kuipc" it and "f77" it. Will be part of the 
distribution kumacs for the 2.04 release. P4.

**Investigate linking problem on SGI, Dec Ultrix, in which loading is
bad unless explicit .o files are used. This means we may have to
discontinue ue of large .a files, at least where routines that exist
in libgeant321.a are concerned. P1. 

**Standardize use of cmz "IF= " if we need to use it anywhere. (Don't
know if we do). May adopt it as a way to reduce executable size, eg
"IF=NO_CRK" , "IF="NO_ITR".     P4.

**The kumacs need to be updated. Cmz commands have changed, and so 
has Kuip in the
last 2 years. Also Vax/Vms versions of the kumacs are needed. P1.

** Does our cmz file directory structure need re-oraganizing?
Look into it. P4.




**Stay with Geant 3.15 for Pisa2.04 ? I use 3.21 at the moment for
E866. But I think we should stay with 3.15. Move to 3.22 (Sept
release) for the last release, Pisa 3.00.



**QUESTIONS: 
Before this, had you read/used the WWW Pisa documentation?
When did you last use the docs?
How would you rate them (1 to 5, 1=worst) and how could they be 
improved?
Have you ever used Pisa?
Are you actively using Pisa now?
Have you used it in the past 6 months?
                 in the past 12 months?
How have you used Pisa:
        To see effect of background on your detector?
        To see what hit multiplicities you expect?
        To determine the granularity needed for your detector?
        To put in resolution effects and see how wellyou can 
        reconstruct tracks?
Would you have use for simulation output made to look 
like Level One data?

Have you ever used Pisorp?
Are you actively using Pisorp now?
Have you used it in the past 6 months?
                 in the past 12 months?
In Pisorp the facility to merge events from different sources exists.
Would you use event merging? 
How would you use it:
        Signal event plus background event?
        Double the event size? 
        Signal plus signal merging?
        Multiple signal events added to a background event?

Currently Pisa/Pisorp are checked out and supported on 4 Unix 
platforms (IBM-Aix, Silicon Graphics Irix, DecStation 5000,
HP UX). Dec Alpha OSF/1 will be added to this shortly. Ability for
a code to run on this many unix machines about guarantees universal 
unix compatibility. 
What platforms have you run Pisa/Pisorp on?
What is the memory size on the machine?
                Less than 16MB
                16-32 MB
                32-64 MB
                More than 64MB
Do you anticipate being able to get your hands on a 64MB or more computer 
in the near future (~6 months) to run Pisa on it?