FluxSvc Code Review July 16, 2002
Attendees: Sandhia Bansal, Joanne Bogart, Toby Burnett, Xin Chen, Jim Chiang, Seth Digel, Richard Dubois, Marco Frailis, Heather Kelly, Sean Robinson, Karl Young
Sean
provided a nice introduction tot he FluxSvc package:
http://d0.phys.washington.edu/~srobinsn/FluxSvc/
This document, or an updated version of this document should be moved to the
central SAS web server.
Included
in Sean's presentation was an introduction to the format for sources in the XML
files. One interesting point is when specifying the flux:
<source
name="NAME" flux="###">
the units depend upon the type of source:
Flux is defined to be in units of particles/sec/m^2/steradian for diffuse
sources, and particles/sec/m^2 for point sources (effectively integrating over
angular size of the source.)
Seth: When specifying the flux, can you also specify
the energy range? Or is it assumed to be integrated over all energies?
Sean: Assume it is integrated over all
energies. Typical usage involves determining when the next particle is to
arrive - used to choose among composite sources.
Toby: absolute flux is important for rate.
particle
is defined by the following entry:
<particle
name="p">
Richard: Is there a list of acceptable
particle names?
Toby: that list in now Geant4 dependent.
Sean agreed to locate the information and add it to to the documentation.
[Editor's Note: Should our list of particle names
be determined by an external library? What if we wanted to later use gismo
again?]
[Editor's Note2: Some documentation describing the set of standard sources available in the source library, outside of the XML file itself, would be invaluable.]
Sean provided an introduction to defining new spectrum
classes external to the FluxSvc package A relatively new method involves
the use of Gaudi Tools.
[Editor's Note: Can more documentation be
provided to show how to use the Tool interface?]
Sean continued to discuss Galactic Coordinate
Transformations:
http://d0.phys.washington.edu/~srobinsn/FluxSvc/FluxSvcDoc3.htm
Within the XML specification for a source, users can specify whether to use
the GLAST zenith pointing frame or Galaxy-Local coordinates.
When using galactic coordinates, a transformation is performed. Sean
mentioned that currently, the convention results in the x-axis pointing to the
east. He was wondering if that is acceptable?
Seth: x-axis orientation should be determined by
keeping the solar panels pointing towards the sun. Wondering about how the
coordinate transformation is done. How is the rotation handled over
precessional angle?
This code for galactic transformations will ultimately be moved to
another package.
Next Sean discussed the data that is ultimately put on the
TDS:
http://d0.phys.washington.edu/~srobinsn/FluxSvc/FluxSvcDoc4.htm
Heather - Is the time that is available in the EventHeader
the same time provided by the FluxSvc?
Later on we determined that FluxAlg::execute does put the time on the TDS:
SmartDataPtr<Event::EventHeader> header(eventSvc(), EventModel::EventHeader);
if(header) {
Event::EventHeader& h = header;
h.setTime(m_flux->time());
Among the to do items is the Diffuse Extragalactic
Background, which will be part of the new MapFlux package.
Seth -
has the galactic diffuse emission been added in yet?
Sean - Soon, working on it
Sean - Short answer is yes. The class has been
designed to allow for variation. There just needs to be an interface to
read in the data appropriately.
Karl
- Package owners should review the Code Documentation Guidelines available from
the Documentation Task Force Home Page. There are
many elements missing: link to release.notes, description of jobOptions
parameters, etc.
Traudl
- It would still be good if this description ("More Documentation ")
could become part of the mainpage.h, because then the class names become
clickable
Karl
- should have standard place for html pages linked into the mainpage.
Toby - these documents belong in the doc
directory of the package.
Marco
- The mainpage needs more detailed comments generally.
We then proceeded to a brief discussion between Toby and Karl about the Doxygen documentation on the SLAC Unix space. Currently only checkout packages have their Doxygen documentation automatically generated and stored on the site. Karl suggested that this could be extended for all packages - but that has not been our practice up to now.
[Editor's Note: Due to time constraints, we combined the documentation and code review for the individual classes.]
Sean stepped us through some selected classes.
ISpectrum
This is the classes from which all external Spectrum classes should derive.
Karl - is the energySrc method still
in use?
Sean - it is a relatively new method and is not
really being used yet.
FluxSvc
A Gaudi Service that is the interface between Gaudi and the Flux classes.
FluxMgr
Provides an interface to the XML source library file(s).
Passes the appropriate XML element to the FluxSource or CompositeSource - where
the parameters are extracted and used to setup the spectrum(s).
Flux
Is an interface to the older code that resided in the flux package.
The question has been raised as to whether this class and IFlux is still
required.
Heather: While it is an additional level of
indirection, it does keep the older flux code nicely separate from the Gaudi
code - if one day we wish to extract the flux classes for purposes outside of
Gaudi, it will be easy to do so.
Heather: What is the numSource( ) method for?
Sean: It can be used to identify what source
has been called. It is useful for debugging. It could also be used
if we desire to store the source type on the TDS.
Marco: What is the difference between current event
and current flux?
Sean: event is the EventSource pointer and
flux is the FluxSource pointer. EventSource is mostly an abstract class -
which FluxSource and CompositeSource are derived from. EventSource defines
the source itself. FluxSource provides the energy, direction, position,
etc.
Karl - Question about CLHEP usage,
the random number seed does not seem to be set in the FluxSvc package.
Where should it be set?
Toby: We should use the Gaudi Random Number
Service for this purpose.
Orbit
[Editor's Note: One of the few classes with a
detailed comment block.]
Accepts parameters through its constructor. This class is used by the GPS class.
Offline commentary:
Richard: Will the code keep GLAST properly oriented
towards the sun?
Toby: The Orbit code will rewritten in
the near future.
FluxAlg
A Gaudi algorithm that uses the FluxSvc to access details about an
event: energy, position, direction, particle type. Those details are
then stored on the TDS.
The first few lines in the execute routine allow the source
to be changed by some external routine:
if(m_fluxSvc->currentFlux() == m_flux){
m_flux->generate();
}else{
m_flux = m_fluxSvc->currentFlux();
m_flux->generate();
}
There is an ugly hack, to fix the inconsistency in how
Geant4 names protons and how our internal spectrums identify protons.
if( particleName=="p") particleName="proton";
ParticleProperty* prop = m_partSvc->find(particleName);
FluxSource
This is code that was originally in the flux package.
There are many set routines that were used for the command line interface of the
old glastsim. Now all parameters are set through the XML file.
FluxSource contains a Spectrum object, which handles setting up the specific
Spectrum(s) in use.
The interval method determines when the next event is to take place.
Marco: What does the setAcceptance( ) method do?
Sean: Sets the solidAngle to take into account for
the total rate.
Toby: The eventNumber( ) method is obsolete now, it was used with older versions of the simulation.
Richard: Do we record which
source produced an event in the Monte Carlo record?
Sean: We could put the numSource on the TDS.
Toby: Is there some place to store this in a ROOT Monte Carlo header?
Heather: It is certainly possible to update
the ROOT classes, in fact we should discuss the header structure and get it
finialize sooner rather than later. However, do we want to just store the
name of the source, or the specific spectrum that produced an event?
Richard: The spectrum that produced an
event.
Heather: So we could use the title provided
by each Spectrum class as an identifier?
Sean: We should use both numSource and title
to uniquely identify the spectrum, as the names could overlap.
[Editor's Note: The need to store the
spectrum will be addressed by the Data Structures Task Force.]
Offline Commentary:
Richard: Many private data members do not
adhere to our naming conventions.
[Editor's
Note: This is older code, which predates our coding conventions.
However, it does seem this code is here to stay, if that is true, some plan
should be put in place to update this class.]
Are there plans to replace the usage of
strstream with sstream?
Units
Heather, for Bill Atwood, via ICQ: Energy in the source libraries can be in either GeV or MeV - this seems dangerous. Why not standardize?
Sean: It can be open for discussion, I am willing to do whatever keeps people happy. Although, I've found that there is no way to keep everyone happy.
Heather, speaking for herself: Most importantly there should be one set of units as the output of FluxSvc, in this case MeV. However, it does seem dangerous to allow for a variety of units, forcing the code to do conversions in some instances and not others.
Traudl: It would also be good to mention what the (default) units are (I really would like that we could follow a CLHEP-like standard, then there is no doubt).
Sean will provide a finalized version of his HTML pages to be stored directly on the SLAC SAS web.
Sean will locate a current list of particle names.
Update the mainpage to conform to our standards. Provide a more basic summary of the package and how the pieces fit together.
Update all class headers to conform to our standard Doxygen header for class declarations.
All source files should be updated to include standard comment header as defined in the code documentation guidelines.
All methods should be updated with comments using our standard template:
// Purpose and Method:
// Input:
// Output:
H. Kelly Last Modified: 2004-08-04 15:39:19 -0700