 |
Conversion to Gaudi Version 11
and the GlastRelease system
|
Current status:
01/17/2003 10:19:06 -0800
- External; We have created a new "container" package,
IExternal,
to contain the interface packages. It currently contains all the external
packages needed by Gaudi v11r4, and our interface to Gaudi itself. Since it is a
container, the CMTPATH needs only to point to the folder containing the
package, so if it is in the same folder as CMT itself, nothing has to be done
to expose its packages, which must be used with the requirements file
statement
use ROOT v2* IExternal
for example. The contained packages are also under IExternal in
cvs, and so are new copies of some, like ROOT. One checks out the lot with the
cmt command,
cmt co -R IExternal
but note that IExternal cannot already exist.
The following table has a list of the packages contained by IExternal, and the
reference paths on Windows (glast-ts) or Linux (SLAC)
| Package Name |
Package
Version |
native
version |
Path to libs/includes |
| Windows |
Linux |
| AIDA |
v3r221p0 |
2.2.1 |
AIDA/2.2.1 |
AIDA/2.2.1 |
| CLHEP |
v2r1800p1 |
1.8.0.0 |
CLHEP/1.8.0.0 |
CLHEP/1.8.0.0 |
| HTL |
v2r1311p1 |
1.3.1.1 |
HTL/1.3.2.1 |
HTL/1.3.2.1 |
| ROOT |
v2r30309p0 |
v3.03.09 |
ROOT/v3.03.09 |
ROOT/v3.03.09 |
| Geant4Runtime |
v2r41p0 |
4.1.p01 |
geant4/v.1.p01 |
geant4/v.1.p01 |
| XML |
v3r152p2 |
c1_5_2 |
xerces-c1_5_2-win32 |
xerces/1.5.2 |
| cfitsio |
v1r2410p0 |
v2410 |
cfitsio_v2410 |
[not installed] |
| GaudiInterface |
v0r114p0 |
v11r4 |
gaudi/v11r4 |
gaudi/v11r4 |
- Gaudi v11r4 This is now external, but organized as CMT packages as
before. We put them under $GLAST_EXT/gaudi/v11r4. The binaries are in the
usual place for CMT packages, $CMTCONFIG folders in each package. This is
explicit in the interface package GaudiInterface.
It is built with the same external policy and external interface packages as
the rest of Glast software. The CMT path must then have the following
components to build it: $CMTCONFIG/gaudi/v11r4 of course,
and the folder IExternal itself. The latter gives the Gaudi requirements files
direct access to the interface packages. (An alternate strategy would be to
change the Gaudi requirements files to correspond to Glast policy.)
Since users should not have to build it, it is available pre-built for Win32
and Win32Debug, in the glast windows
zip area,
and in the SLAC
ftp area
-
GaudiInterface This is a new package contained by IExternal,
with the minimal interface to access all of the separate binaries and includes
in Gaudi. For now, it is pretty simple, with includes to GaudiKernel, and
binaries for GaudiSvc, GaudiTools, GaudiAlg, GaudiAud, and RootCnvSvc.
Glast packages using Gaudi facilities need only the statement
use GaudiInterface * IExternal
- GlastRelease. This package specifies the Glast packages,
including IExternal
- SLAC Linux (noric) setup
In your .csrhrc, you should have the following
lines:
setenv GLASTROOT /afs/slac.stanford.edu/g/glast
source ${GLASTROOT}/ground/scripts/group.cshrc
setenv CMTCONFIG rh72_gcc2953
setenv GLAST_EXT /afs/slac.stanford.edu/g/glast/ground/externalPackages/rh72_gcc2953 |
Then, in a folder which is in the CMTPATH, (see
glastpack help on setting that up), enter the commands
cmt co -R GlastRelease
cd Gleam/v*/cmt
cmt broadcast gmake
source setup.sh
../$CMTCONFIG/test_Gleam.exe |
Note that this gets the HEAD of GlastRelease, and all TAGGED packages that it and IExternal reference.
To get a particular version of GlastRelease, put " -r v0r3" in the cmt co
command.
-
Windows setup
The packages needed to build Gleam are specified in
GlastRelase are all installed on glast-ts: the externals in the d:\extlib area,
GlastRelease in d:\ground.
Just set your CMTPATH to d:\ground\GlastRelease_v0r3.
If you want to make modifications, you should check out individual packages in
your own area, and prepend that to your CMTPATH.
TODO:
- Make branch tags (Gleam_v4r1) of all files in Gleam v4r1.
Chronological log follows:
17 Nov 2002, T. Burnett
Gaudi installation
After a study of the new
Gaudi v11r1 release I decided to initially deal with only the subset of
packages that we currently use:
ExternalLibs v4r0p1
ROOT v2r30309p0
CLHEP v2r1800p0
HTL v2r1311p0
AIDA v3r22p0
GaudiPolicy v5r7
GaudiKernel v13r1
RootHistCnv v8r1p1
GaudiTools v6r1
GaudiAlg v6r3
GaudiAud v6r1
GaudiSvc v10r0p1
Where Gaudi is a container package, AIDA, CLHEP, HTL, and ROOT are
external interface packages. None of these packages depend on ROOT, but will use
this one for our code as well.
Gaudi package notes:
- ExternalLibs: cut out all LHCb/ATLAS stuff to depend on GLAST_EXT
only. We will use the nice "native_version" scheme.
- HTL: The distribution copy is crazy! Modify it to depend on 1.3.1.1
since 1.3.2.1 is not released.
- ROOT: it now has a document for running rootcint that might be the
same as ours. It does not put links to the libraries in the WIN32 tag, I don't
understand this, but we can accomplish that with our RootPolicy.
- GaudiPolicy: Comment out the global pattern RuleChecker; put in a
macro to set CMTBIN for Win32, needed for our vcmt environment.
I've put the current test version source into a zip file, mingaudi_v11r1.zip, for temporary
safe-keeping. [Added later: just get source from Gaudi.] It is not clear that we should maintain this code as separate
packages in our repository. The external libs, including ROOT, but not G4 or
Xerces, are in another zip file for windows:
extlib_win32_v11.zip .
Gleam migration
Initially, updates of Glast packages under development (like CalRecon,
TkrRecon, etc.) to the repository should be backward compatible, so as to not
disturb current development which assumes Gaudi v9.
- GlastPolicy:
- override cppdebugflags so the proper Win32Debug settings are used.
(A puzzle.)
- Change the GlastMain.cxx and TestGlastMain.cxx to avoid tests for
failure that do not compile.
- GlastSvc:
- Remove a failure test in src/EventSelector/EventCnvSvc.cpp that does not
compile. This code is very much a LHCb legacy, needs to be redone.
- Some evidence from a crash that std::string should not be declared as a
property: switch to StringProperty.
- Modify all requirements files to remove specific versions for Gaudi
packages.
- RootPolicy: override ROOT_linkopts for Win32 for clients to link
the libs.
- Recon: general cleanup to remove Geant4 dependence (which is not
migrated yet).
18 Nov 2002, T. Burnett
Gleam, cont.
- Geant4/Geant4Runtime: convert to 4.1.po1, already in the SLAC ftp
site. Although build with CLHEP 1.7.5.0, seems to work fine with 1.8.0.0.
Rename the root directory from the tar file to the version. Define
native_version in Geant4Runtime. (Could the "export" stuff from the the CMT be
useful here? Maybe it would solve the problem that Geant4Runtime was invented
by Joanne?
- G4Generator: no changes needed, other than versions in the
requirements file
- merit: depends on ROOT, needed to get the libraries. Put in
RootPolicy.
- Gleam: remove all explicit version identifiers. Will use the new
GlastRelease package to define dependencies. Allows to prune the list.
21 Nov 2002, T. Burnett
- IExternal: New proposed container package for external libs, as
advocated by Traudl
package IExternal
# container package for external interface packages
use AIDA v3r22p0 IExternal
use CLHEP v2r1800p0 IExternal
use HTL v2r1311p0 IExternal
use ROOT v2r30309p0 IExternal
use ExternalLibs v4r0p1 IExternal
This puts the external interface packages just below this package. There are
then two modes to access these packages:
- Via IExternal, assuming it is in the CMT path, via "use AIDA * IExternal"
for example.
- Directly if the CMT path includes IExternal itself: this allow us to build
Gaudi without modifying the Gaudi requirements files, and to make a gradual
transition.
- GaudiInterface: The Gaudi interface
package GaudiInterface
macro GaudiInterface_native_version v11r1
# test interface package for Gaudi 11 external
# note that the root is above the version id
macro gaudi_root "$(GAUDIINTERFACEROOT)/.."
use GlastPolicy
# clients need access to the shareables defined by these guys
use HTL * IExternal
use CLHEP * IExternal
### GaudiKernel ####
include_dirs "$(gaudi_root)/GaudiKernel/v13r1"
macro GaudiKernel_linkopts "$(gaudi_root)/GaudiKernel/v13r1/$(BINDIR)/GaudiKernel.lib"
macro GaudiInterface_linkopts "$(GaudiKernel_linkopts)"
path_append LD_LIBRARY_PATH "$(gaudi_root)/GaudiKernel\v13r1\$(BINDIR)"
### GaudiSvc ######
set GaudiSvcShr '$(gaudi_root)\GaudiSvc\v10r0p1/$(BINDIR)/GaudiSvc'
### GaudiAud ######
set GaudiAudShr '$(gaudi_root)\GaudiAud\v6r1/$(BINDIR)/GaudiAud'
### GaudiAlg ######
path_append LD_LIBRARY_PATH '$(gaudi_root)\GaudiAlg\v6r3/$(BINDIR)'
Note that it is at the moment only supporting Windows.
Also note the initial macro gaudi_root that provides a pointer to the
actual location of the Gaudi packages, in this case just below GaudiInterface.
This would be a convenient way to distribute the code, I think. Again there are
two possibilites:
- Access to Gaudi via GaudiInterface: it is in the CMTPATH, and a
simple use is sufficient to provide access to the parts of Gaudi that
we currently use. Of the Gleam set of packages, only GuiSvc and
Event really need to specify the connection to Gaudi: all others use one
or the other.
- Direct access, if CMTPATH includes GaudiInterface itself. This allows
inclusion and rebuilding of the Gaudi packages.
This system including both packages and those below it, can be downloaded as
a zip file from my web site:
http://d0.phys.washington.edu/~burnett/glast/gaudi_v11
November 23, 2002
Following comments from Michael Kuss
Ok, we are converging.
Gleam compiles and links, but doesn't run
(yet). But chronological:
I checked out Gleam v4.
I downloaded your zip and extracted it into the packages root dir.
I removed all previous Gaudi, external libs packages, and the EXTLIB. I
also removed XMLEXT (see later).
In the requirements, in packages which need an extlib, I included "use
IExternal", in packages which need an (old) Gaudi package, I included a
"use GaudiInterface".
Exception: in GlastPolicy, I replaced "use GaudiPolicy" by "use
GaudiPolicy * GaudiInterfaces" . If I would haved used GaudiInterface
directly, I would have had a circular reference, because GaudiInterface
references GlastPolicy. Is that intended, or should it be GaudiPolicy?
Before, I also tried e.g. "use ROOT * IExternal", but then some needed env
variables are not defined. I don't know if it is intended or not, but it
makes sense and forces the user not to worry about which lib he actually
needs.
For IExternal/ROOT, I had to add ROOT_libs in the linkopts, and also more
libs (I usually use root-config and add all of them, cannot hurt).
I thought it makes sense, so I added to IExternal the XERCES package of
Gaudi. Nothing else to do but to add it to the IExternal requirements.
I
also put "use ExternalLibs" first for a cleaner build (and show uses).
We
also should consider to add Geant4 here, I didn't do it, but more later.
Several packages of us still require patches, most of them minor.
However, we got new ones, i.e. CalUtil and GlastDigi (from the Bari digi
alg). It's not important now, I will summarize monday and notify the
package owners (after checking against the HEAD). Btw, Joanne always
immediately updated xmlUtil, and we now have v2r8p6, but you still have
v2r8p3 in Gleam v4.
And I just remember, Gleam also doesn't build with egcs, because Tracy
blew something in Event. Separate mail.
In GlastPolicy, I added -DG4USE_STD_NAMESPACE, otherwise Geant4 doesn't
build. Also -DDEFECT_STRING_STREAM (or similar) got removed.
Ok, with these changes one can essentially go. Some programs don't link,
because they don't find
GaudiInterface/v0/../GaudiKernel/v13r1/Linux-i686/GaudiKernel.lib . I
haven't understood what should happen here. Should be there a link to
the
installed Gaudi lib?
I made this link by hand, to the shared lib (I had the static one before,
and wondered for 3 hours why FluxDisplayTest.exe, and also Gleam, didn't
link).
After a while, there is Gleam. If I try to run it, I get:
[kuss@pcglast00
cmt]$ ../Linux-i686/Gleam.exe
Error: class,struct,union or type __gnu_cxx not defined FILE: LINE:0
Error: class,struct,union or type __gnu_cxx not defined FILE: LINE:0
Error: no such template iterator<iterator_traits<unsigned
int*>::iterator_category,iterator_traits<unsigned
int*>::value_type,iterator_traits<unsigned
int*>::difference_type,iterator_traits<unsigned
int*>::pointer,iterator_traits<unsigned int*>::reference> FILE: LINE:0
Error: no such template iterator<iterator_traits<unsigned
int*>::iterator_category,iterator_traits<unsigned
int*>::value_type,iterator_traits<unsigned
int*>::difference_type,iterator_traits<unsigned
int*>::pointer,iterator_traits<unsigned int*>::reference> FILE: LINE:0
Error: class,struct,union or type __gnu_cxx not defined FILE: LINE:0
Error: class,struct,union or type __gnu_cxx not defined FILE: LINE:0
Error: class,struct,union or type __gnu_cxx not defined FILE: LINE:0
Error: class,struct,union or type __gnu_cxx not defined FILE: LINE:0
Error: class,struct,union or type __gnu_cxx not defined FILE: LINE:0
Error: class,struct,union or type __gnu_cxx not defined FILE: LINE:0
Error: class,struct,union or type __gnu_cxx not defined FILE: LINE:0
Starting Glast-Gaudi job with job options file
/data00b/users/kuss/myGlast/packages/gcc32/Gleam/v100/Gleam/v4/src/jobOptions.tx
t
/data00b/users/kuss/myGlast/packages/gcc32/Gleam/v100/GaudiInterface/v0/..\Gaudi
Svc\v10r0p1/Linux-i686/GaudiSvc.so:
cannot open shared object file: No such file or directory
Gaudi::Bootstrap: Not found DLL GaudiSvc
Well, same weird stuff as I have seen before. The GaudiSvc, of course,
is
trivial, I just fix the path and make a link to the lib. But I'm tired
now.
Some comments:
It's not could to define the path to the external Geant4 two times.
IExternal should also contain geant4, and runtime and the other reference
this one and get the env variables.
Why are some extlibs duplicate in GaudiInterface and IExternal? I
understand the notion of not messing with Gaudi to much. I hope it is
clear to the user that the extlibs within GaudiInterface are not to be
used by other stuff.
But there might be conflicts. E.g., I had to modify the ROOT_libs in
IExternal/ROOT. What happens if I use both GaudiInterface and IExternal,
which ROOT wins? I think we shoud try to remove the extlibs from
GaudiInterface. We could rename IExternal into ExternalLibs, then maybe
editing is minimal.
I haven't understood why the sources/includes have to be in the packages.
I tought we plan to treat Gaudi like any other extlib. I.e., in a
multiuser environment the system manager has to install the Gaudi stuff
into GLAST_EXT, like any other stuff. I thought purpose of the packages
contained by GaudiInterface is to supply other packages with the env
variables to access the libs and includes.
I'm puzzled about the rh61_gcc2952 tag. Though completely wrong, I like
it, because it says (if right) on which system you are using which
compiler. Moreover, with afs up, my PC is i386_linux24, without
Linux-i686. What for sure doesn't help is to redefine the tag in
GlastPolicy, so I prefer to have it removed there. Now, that we might
run
with two different compilers for a while (also on windows), it would be
best to convince cmt to create a tag representing the compiler. To make
it fail proof, this would have to be at run time. In contrast to now,
where you define it once for your session. If you think it's worth the
trouble, I volunteer to look into it.
Toby's comments:
- IExternal
- I've now checked in the new container package IExternal, and imported
appropriately-modified versions of the Gaudi interface packages ROOT, HTL,
CLHEP, and AIDA. Also ExternalLibs. After importing the latter, I
realized that they should be under IExternal in the repository, so I copied
the repository entries. (So now these 5 are duplicated, sorry.)
Now the cmt command,
cmt co -R IExternal
checks out IExternal and the packages below it. This is not supported by
vcmt or glastpack, a user for now must type this command in by hand.
- I agree that we should treat Gaudi as an external package itself, with
GaudiInterface under IExternal. Thus it has GaudiInterface and GaudiPolicy
as well, and the Gaudi packages, with binaries, sit under $GLAST_EXT/gaudi/v11r1.
I want to keep the CMT structure there, so that it can be easily built.
- Building Gaudi: CMT can be used to build Gaudi if the CMTPATH has
the following components: $GLAST_EXT/gaudi/v11r1; (IExternal); (root of
IExternal).
- Gleam v5
- tags - See cmt's setup.sh, which uses the uname command to
set CMTCONFIG, if it is not already set? Then there are a bunch of tag
statements at the end of GaudiPolicy. I certainly need help with all this, to
decide what to use, and how to set it.
29 November 2002
IExternal
Added Geant4, Geant4Interface, and XMLEXT to IExternal. The req. file
is now:
package IExternal
# $Header: /nfs/slac/g/glast/ground/cvs/IExternal/cmt/requirements,v 1.4
2002/11/29 21:25:26 burnett Exp $
# container package for external interface packages
use AIDA v3r22p0 IExternal
use CLHEP v2r1800p0 IExternal
use HTL v2r1311p0 IExternal
use ROOT v2r30309p0 IExternal
use ExternalLibs v4r0p1 IExternal
use GaudiInterface v0r111p0 IExternal
use GaudiPolicy v5r7 IExternal
# Glast Geant stuff
use Geant4 v2r41p0 IExternal
use Geant4Runtime v2r41p0 IExternal
# Glast path to xerces
use XMLEXT v3r152p0 IExternal
GlastRelease
After a lot of pain trying to maintain a zip file with modified versions of
all the packages, for myself and especially Michael and Johann, I decided that
it was foolish not use use cvs. Thus we now have, as of ~11AM PST on 28
November, temporary copies of all the packages needed by Gleam,
namely
AcdDigi/ CalUtil/ FluxSvc/ Gleam/ RootPolicy/ astro/ facilities/ idents/
xml/
AcdRecon/ G4Generator/ GuiSvc/ TkrDigi/ cmt/ geometry/ mcRootData/
xmlGeoDbs/
CalDigi/ Event/ GlastPolicy/ Recon/ TkrRecon/ detModel/ geomrep/ merit/
xmlUtil/
CalRecon/ FluxDisplay/ GlastSvc/ RootIo/ Trigger/ digiRootData/ gui/
reconRootData/
in a new folder GlastRelease. The intention would be to copy them back,
or have package authors merge the changes, when the dust has settled. For now,
GlastRelease can serve as a container, perhaps a prototype for the eventual
release package.
They have now been modified to take external packages into account,
specifically Geant4 and Xerces.
After a lot of effort, I have all the above copies tagged.
To check out the lot: in a folder that is in the CMTPATH:
cmt co -R IExternal
cmt co -R GlastRelease
This gets the head versions of IExternal and GlastRelease, but tagged,
sticky-tag versions of the referenced packages. At the moment, all these are the
head, and (mostly) only differ in the requirements files from when they were
copied over. To modify such a package, remember to "cvs update -A" before
checking in.
Another thing to be very careful about: applying a rtag *must* give the cvs
path, that is, GlastRelease/<package>..
Finally, do not apply cvs commands directly to the container package. No rtag,
no checkout! Those can be applied only to the cmt folder.
14 December 2002 - Toby
- vsnet: submitted code to CMT to enhance CMT, applied to v1r12p20021129.
Described here
- CMT v1r12p20021129: the modified version submitted to our cvs.
- New gaudi release, v11r4. Download to glast, build with vc6 and vc7. As a
result of fixes to visual studio files, no longer necessary to disable the use
of the -no_auto_imports feature. [But this is hidden with our GaudiInterface
anyway.] For the moment, we only use:
GaudiKernel v13r2
GaudiSvc v10r1p2
GaudiAud v6r1
GaudiAlg v6r3p1
GaudiTools v6r1
RootHistCnv v8r1p2
- Discovered that we were not using a crucial macro to build Gaudi with
visual studio. Fixed in the CMT described above.
21 December 2002 - Toby
An update on the SLAC situation: thanks to Alex, there is a new set of externals at
GLAST_EXT=/afs/slac.stanford.edu/g/glast/ground/externalPackages/rh72_gcc2952
including Gaudi v11r4, but needing Linux-i686 for binary path. Thus I've updated GaudiInterface
to include the following macro definition:
macro
GaudiInterface_tag "$(tag)" \
SLAC_UNIX "Linux-i686"
|
The consequence is that the setup env vars are expected to be:
CMTBASE=/afs/slac.stanford.edu/g/glast/applications/CMT
CMTBIN=Linux
CMTCONFIG=rh72_gcc2952
CMTEXTRATAGS=
CMTROOT=/afs/slac.stanford.edu/g/glast/applications/CMT/v1r12p20020606
CMTSITE=SLAC_UNIX
CMTVERSION=v1r12p20020606
GLAST_EXT=/afs/slac.stanford.edu/g/glast/ground/externalPackages/rh72_gcc2952 |
The boldface ones need to be set explicitly by the user: the others are set
by the line,
| source ${GLASTROOT}/ground/scripts/group.cshrc |
In a user's .cshrc.
And the resulting CMT tags, on a noric are:
Linux (from uname)
i386-linux (from HOSTTYPE)
rh72_gcc2952 (from CMTCONFIG) package GaudiPolicy implies [Linux redhat72
gcc-2.95.2]
SLAC_UNIX (from CMTSITE)
Default (from Default)
gcc-2.95.2 (from package GaudiPolicy)
redhat72 (from package GaudiPolicy)
|
Note that the tag gcc-2.95.2 does not seem to be used anywhere. We actually
use g++ to perform compilation, which, at a noric at least, is at /usr/bin, and
invokes version gcc version 2.95.3 20010315 (release).
A demonstration is available: I wrote a script somewhat equivalent to
glastpack,
doit.bash. Like the overnight builds, the idea was to start with a
clean slate, define everything explicitly, check out fresh copies of everything.
But in addition, it tries to document the status of everything. The output is
here.
07 January 2003 - Toby
Alex has updated the compiler, modifications for tags checked into IExternal/GaudiPolicy.
Verify this with new
doit.bash
and log file.
11 January 2003 - Toby
Discovered that CMT v1r12p20021129 is not yet installed at SLAC. Hope that we
don't depend on the patches.
SLAC build fails here:
In file included from ../src/CalCalibMap.h:7,
from ../src/CalPedMap.cxx:1:
../src/CalXtalCalib.h:41: default argument given for parameter 2 of `const CalibData * CalXtalCalib::getRangeCalib(short unsigned int, idents::CalXtalId::XtalFace = idents::CalXtalId::POS) const'
../src/CalXtalCalib.h:20: after previous specification in `const CalibData * CalXtalCalib::getRangeCalib(short unsigned int, idents::CalXtalId::XtalFace = idents::CalXtalId::POS) const'
../src/CalXtalCalib.h:67: default argument given for parameter 3 of `void CalXtalCalib::addElement(CalibElement *, unsigned int, idents::CalXtalId::XtalFace = idents::CalXtalId::POS)'
../src/CalXtalCalib.h:26: after previous specification in `void CalXtalCalib::addElement(CalibElement *, unsigned int, idents::CalXtalId::XtalFace = idents::CalXtalId::POS)'
In file included from ../src/CalPedMap.cxx:1:
../src/CalCalibMap.h:63: default argument given for parameter 4 of `void CalCalibMap::addElement(CalibElement *, idents::CalXtalId, unsigned int, idents::CalXtalId::XtalFace = idents::CalXtalId::POS)'
../src/CalCalibMap.h:27: after previous specification in `void CalCalibMap::addElement(CalibElement *, idents::CalXtalId, unsigned int, idents::CalXtalId::XtalFace = idents::CalXtalId::POS)'
gmake[3]: *** [../rh72_gcc2953/CalPedMap.o] Error 1
gmake[2]: *** [CalRecon] Error 2
gmake[1]: *** [common_target] Error 2
gmake: *** [all] Error 2 |
This would be fixed by not specifying the default parameters in the function
definitions, I think.
Windows vc6 builds ok, but fails execution of test_Gleam:
ToolSvc ERROR Factory for Tool
LinearConvertAdc not found
CalDigiAlg ERROR Unable to create LinearConvertAdc
Digitization ERROR Unable to initialize Algorithm CalDigiAlg
|
This is fixed by specifying CalUtil in the list of DLL's in the default job
options.
Last Updated:
2003-01-17 10:19:06 -0800