Gleam User Guide:  Sources

How to use the current source infrastructure

Where the Sources Are:

In the FluxSvc package, under the /xml/ directory, there are a number of 
files, including user_library.xml, source_library.xml, and 
composite_library.xml.  Within these files, all the sources that FluxSvc 
(and therefore Gleam) can know about are defined.

The Default (already defined) sources:

Follows is a partial list of the already-defined sources in XML.  For a 
complete list, please see the current files themselves - each source is 
documented and explained within its own comment block.
default:  0.1 GeV gamma-rays coming from the vertical local direction.  Used 
for default tests.
all_gamma:  E^-1 spectrum from 18 MeV to 18 GeV and 0-90 degrees to weight all gammas
albedo_gamma:  Source that represents the Earth horizon albedo with Glast 
zenith pointing
chime:  The CHIME spectrum. angular dependence and rate are from the CHIME 
spectrum object
He:  The Helium spectrum. angular dependence and rate come from the 
HeSpectrum object.
albedo_electronpositron:  Source that represents the spalsh and re-entrant 
albedo electrons and positrons
diffuse:  diffuse extraglactic from 10 MeV: from APJ 494:523
diffuse-100mev:  Diffuse extraglactic from 100 MeV
crab-galactic:  the Crab, pulsed portion, with pointed observation, for 
photons above 100 MeV, based on Nolan APJ 409:697
electron:  galactic electron spectrum
normal_gamma:  E-1 spectrum from 18 MeV to 18 GeV and normal incidence
muons:  special source that mimics non-interacting cosmics.
backgndmix:  standard background mixture.

Type name particle energy(GeV) angles (system) Flux
particles/m^2/s
Comments
photons default gamma 0.1 0 (Glast)    
all_gamma gamma power_law emin="0.01778" emax="17.78" gamma="1" solid_angle mincos="0.99" maxcos="1.0"    
normal_gamma gamma power_law emin="0.01778" emax="17.78" gamma="1" solid_angle mincos="0.99" maxcos="1.0"    
gamma_1_gev_normal gamma 1 solid_angle mincos="0.99" maxcos="1.0"    
gamma_1_gev_30deg gamma 1 solid_angle mincos="0.866" maxcos="0.867"    
gamma_1_gev_60deg gamma 1 solid_angle mincos="0.4995" maxcos="0.5005"    
gamma_1_gev_uniform gamma 1      
gamma_100_gev_normal gamma 100 solid_angle mincos="0.99" maxcos="1.0"    
gamma_100_mev_uniform gamma 100 solid_angle mincos="0" maxcos="1.0"    
gamma_10_gev_uniform gamma 10 solid_angle mincos="0" maxcos="1.0"    
gamma_100_gev_uniform gamma 100 solid_angle mincos="0" maxcos="1.0"    
muons cosmic_muons mu+        
vertical_muons mu+        
clocks timetick - -     Special source that corresponds to a regular interval
background cremeavg p   solid_angle mincos="-0.4" maxcos="1.0"   SpectrumClass name="FILESpectrum" params="sources/glast_smin_flx.txt"
albedo_proton_max p        
albedo_proton_avg p        
albedo_electronpositronlow e+        
albedo_electronpositronhi e+        
albedo_electronpositronavglow e+        
albedo_electronpositronavghi e+        
albedo_gamma gamma power_law emin="0.010" gamma="2" solid_angle mincos="-0.405" maxcos="-0.395"   source that represents the Earth horizon albedo with Glast zenith pointing
Numbers are based on Thompson et al., JGR 86, 1265
Flux starts with total of 920/m/s at 115 degrees, extrapolated down to 10 MeV using
E^-2 spectrum and assuming isotropic in phi:
920/(2.*3.14159*0.01) = 1.464226713225e+004
albedo_electronpositron e+       source that represents the spalsh and re-entrant albedo electrons and positrons
Numbers are based on LAT-TD-00250-01 figure 10, multiplied by 2 for positrons and is
isotropic to include splash and re-entrant pieces and is blindly extrapolated down
to 10 MeV (worst case).
-3.2 index spectrum (best fit by eye) and assuming isotropic in phi:
= 994 particles/m^2/s/sr integrated above 20 MeV. Make them all positrons for worst case and simplicity.
backgndavgpdr (mixture)        
backgndmix (mixture)        <nestedSource sourceRef="albedo_proton_avg"/>
<nestedSource sourceRef="albedo_gamma"/>
albedo_electronpositronavg_total (mixture)        <nestedSource sourceRef="albedo_electronpositronavglow"/>
<nestedSource sourceRef="albedo_electronpositronavghi"/>
albedo_electronpositron_total (mixture)        <nestedSource sourceRef="albedo_electronpositronlow"/>
<nestedSource sourceRef="albedo_electronpositronhi"/>
galactic diffuse gamma        
diffuse-100mev gamma        
crab-pulsed-pointed gamma       the Crab, pulsed portion, with pointed observation, for photons above 100 MeV,
based on Nolan APJ 409:697
crab-galactic gamma        
           

How Gleam Knows where to look for Sources:

In the jobOptions file of Gleam (or one of the included jobOptions files), a 
line is declared as follows:

FluxSvc.source_lib += {"$(G4GENERATORROOT)/src/test/test_sources.xml"};

This line adds the named xml file to the list of files that Gleam can get 
sources from.  Note that the included file:
$(FLUXSVCROOT)/src/defaultOptions.txt
Also declares the file source_library.xml, so Gleam knows about it as well.

How Gleam knows which source to use:

In the JobOptions file of Gleam, the source that Gleam will use for the 
simulation is declared in the following line:

FluxAlg.source_name="muon_pencil_angle";

If it is desired, the source name can be changed to any source name that 
Gleam knows about (that is, any source name contained in an xml file that 
Gleam knows about).

Adding particle sources

Using Available Sources/Adding new sources in Gleam:

Within Gleam, sources are declared within XML files, in the FluxSvc package and elsewhere. It is quite possible to declare an xml file outside of the FluxSvc package, and send it to FluxSvc to be used, provided it conforms to the DTD file governing the form of the XML files stored in FluxSvc (the DTD is located at /xml/source.dtd in the FluxSvc package).  The external XML file must have the form:

<source_library title="descriptive name for GUI menu">

[SOURCE DECLARATION 1]

[SOURCE DECLARATION 2]

..........

</source_library>

The form of the source declarations will be discussed below.  Also, for the XML file to be inserted into the Gleam infrastructure for use, the line:

FluxSvc.source_lib += {"<pathname>/<filename.xml>"};

must be within the JobOptions file used. See the FluxSvc local jobOptions file for examples.

Adding a new source:

The XML interface, among other things, provides a way to encapsulate classes in the code as simple names, to simplify the process of calling them later.  Take the example of the XML element:

<source name="gamma_patch">
    <spectrum escale="GeV"> 
        <particle name="gamma"><energy e="0.1"/> </particle>
        <direction theta="0" phi="0" />
        <patch />
    </spectrum>
</source>

There are a lot of options available with which to construct a source like this in the XML.  Follows is a brief overview of the way sources can be  declared, and what the declarations mean:

 

Anatomy of an XML source

<source name="NAME" flux="###">

on this first line, we declare the name that the flux wil be called by, and (optionally) a total flux for that 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.)  The value of the flux defaults to 1 if it is not declared.

 

<spectrum escale=["MeV"|"GeV"]>

this line declares the spectrum element, and an energy scale for a declared energy (which comes later).  This has no default, and must be declared.

After this, three distinct attributes of the source get declared, how the type of particle and energy is declared, how the particle direction is declared, and how the point of origin for the particle is declared:

 

Type of Particle:

either a line like:

<SpectrumClass name="CHIMESpectrum">,

declaring the class (within the c++ code) to be used, or a line like:

<particle name="p">

declaring that particle attributes will be explicitly stated in XML, is used.

the SpectrumClass can take a string of information which will be fed into the class constructor of the class named, and the "particle" declaration will have either an energy or a power-law declared with their constituent parameters (as above).  If "particle" is declared, then an energy or energy scale must be specified within the particle, like so:

          <particle name="mu+"> <energy e="10"/> </particle>

  one of the following must then be declared in this way:

Tag Name Attributes (defaults) Description
energy e (0.1) explicit energy
power_law emin, emax , gamma (0.1 , 100 , 2) power law from emin to emax, with index gamma.

Note also that if "particle" is declared, a particle name must be given ("mu+" and "p" in he above examples), representing the type of incoming particles.  A partial list of available particles/names is as follows:

Type of Particle Name   Type of Particle Name
photon gamma   mu+ anti-muon
proton p   pi+ + pion
e- electron   pi- - pion
e+ positron   pi0 neutral pion
mu- muon      

 

Direction:

lines like:

    <solid_angle mincos="-0.405" maxcos="-0.395" theta="0" /> 

are declared, with one of the following types:  

Tag Name Attributes (defaults) Description
solid_angle mincos,maxcos,theta,phi (-0.4 , 1.0 , 0 , 0) the particle will come from some direction within the angles specified, in the zenith-local frame.
direction theta,phi (0 , 0) an explicit direction is given, in the zenith-local frame.
use_spectrum frame (earth) where the spectrum (code) Object is responsible for supplying the direction (2 numbers), interpreted either as earth (cos theta, phi) or galaxy (l,b), depending on the frame. Note that this tag can ONLY be used in conjunction with the SpectrumClass tag.
galactic_dir l , b (0 , 0) where an explicit direction is given in galactic coordinates (l,b)
celestial_dir ra, dec (0 , 0) where an explicit direction is given in celestial coordinates (ra,dec)
galactic_spread l , b, degreespread (0 , 0 , 10) an explicit direction is given in galactic coordinates, and a diffuse source will be projected about that direction with a given angular radius.

Each of these options has its own set of attributes given in the DTD and reflected in the XML (for instance, a "frame" attribute within the "use_spectrum" tag allows for the spectrum class to return a galactic direction in the form (l,b), rather than the standard direction format.

 

Point of Origin:

In addition to the direction in which the particle is moving, we must also specify a location at which it "enters into existence", in the sense of originating within the simulation. Specifying this, we can specify a "launch point", in a line like the following:

Tag Name Attributes [defaults] Description
none (no tag given) N/A A random point is chosen  in a disk perpendicular to the incoming direction, the launch point is then back a distance equal to the radius of the disk along the incoming direciton.  The center of the disk is at the coordinate origin. The size is 6m^2, currently not written out.
launch_point x , y , z
[0 , 0 , 1000]
explicit point, in the LAT-local frame (units in millimeters)
patch xmin,xmax,ymin,ymax,zmin,zmax
 [-100,100,
  -100,100,
1000,1000]
a box within which launch points are generated uniformly in the ranges
xmin<x<xmax, ymin<y<ymax, zmin<z<zmax(units in millimeters)

 

Composite Sources:

In addition to declaring single sources,the XML also allows for the creation of a composite source, based on the source names already in the xml file:

 

<source name="source_mix">
   <nestedSource sourceRef="albedo_proton" />
   <nestedSource sourceRef="anothersource" />
    .......................
</source>

 

In the above case, one would use the name "source_mix" in the JobOptions file as the name of the "desired spectrum" in order to have all the referenced spectrums work together.  The CompositeSource infrastructure essentially creates all of the included sources, and decides, for each following event, which source has created the particle, based on how long each source reports the next particle to take to arrive.

 

Adding a new Spectrum Class:

Beyond the usage of XML to create and use new sources, it may occasionally be important to actually create new classes which represent sources in the code itself, for purposes not covered by the current scheme.  To this end, a discussion of the method for adding Spectrums is presented:

 

External to FluxSvc (shareable through a package); using  the "Tool" structure:

In order to preserve the virtuality of the include files from FluxSvc, Spectrums external to FluxSvc should inherit from the ISpectrum class.  A succinct way of handling external spectrum creation  is to have the following lines included in a Gaudi "tool"  which performs the task of insertion upon its initialization, and then define the appropriate dll files to declare that tool at run time.    More or less, the dll files merely declare the presence of the tool, and the cxx file wherein the relevant code is contained initializes the sources.  This pattern has been used now (as of July 2002) in both the GRB and BFEMflux packages, and they provide excellent examples.

In BFEMflux, presently, a file called RegisterBFEMFlux.cxx holds the declarations:

class RegisterBFEMflux : public AlgTool, virtual public IRegisterSource {
public:
    RegisterBFEMflux( const std::string& type, const std::string& name, const     IInterface* parent);
    virtual ~RegisterBFEMflux() { }
    /// implement to define sources: will be called from FluxSvc
    StatusCode registerMe(IFluxSvc* );
};

Note the registerMe function - it is used to actually declare the spectrums, as below:

// Standard Constructor
RegisterBFEMflux::RegisterBFEMflux(const std::string& type,
    const std::string& name,const IInterface* parent)
: AlgTool( type, name, parent ) {
    // Declare additional interface
    declareInterface<IRegisterSource>(this);
}

StatusCode RegisterBFEMflux::registerMe(IFluxSvc* fsvc){
MsgStream log(msgSvc(), name());
    log << MSG::INFO << "Register BFEMflux Spectrum..." << endreq;
    static RemoteSpectrumFactory<CrProton> BFEMfactory(fsvc);
    static RemoteSpectrumFactory<CrElectron> BFEMfactory2(fsvc);
    return StatusCode::SUCCESS;
}

These lines of code take the pointer to the Flux Service (fsvc) and the type of ISpectrum (CrProton), and insert the class into the SpectrumFactoryTable to be called later.  This is an important point - code called at run time MUST be responsible for inserting the created spectrum into the SpectrumFactoryTable of FluxSvc, so that it can be called later.

then, dll files are declared with the names [packagename]_dll.cxx and [packagename]_load.cxx, with content like the following:

BFEMflux_dll.cxx, which contains only:

#include "GaudiKernel/LoadFactoryEntries.h"
LOAD_FACTORY_ENTRIES(BFEMflux);

and BFEMflux_load.cxx, which contains:

#include "GaudiKernel/DeclareFactoryEntries.h"
DECLARE_FACTORY_ENTRIES(BFEMflux) {
    DECLARE_TOOL( RegisterBFEMflux );
}

The important thing to note here is that the tool (in this case, RegisterBFEMFlux) has been declared in the <packagename>_load.cxx file.  Thus, upon Gaudi initialization, all the declared tools (now including BFEMflux) will get initialized, at which point, in turn, the desired spectrums will get added to the SpectrumFactoryTable in FluxSvc. Now, in the jobOptions file of a Gaudi simulation, all that must be declared is the appropriate dll file, like so:

......
ApplicationMgr.DLLs += { "BFEMflux" };
......

and then the associated spectrums can be called. Note that, as before, user xml files can also be passed to FluxSvc, so that user-defined sources can be used. In this way, the external sources can be shared across packages, basically by just including the packages containing them.


S. Robinson:  Last Modified:  2002-12-16 13:01:28 -0800