Most recent update: 2 December 2004
This page presents discussion about proposed enhancements to ZOOM packages which are in "product" status (no longer beta releases).
There is currently a proposal for upgrading the CLHEP Random package with regard to saving and restoring random distributions and engines. It can be found here.
Users are highly encouraged to make their opinions known by e-mail to zoom-support.
More details, and discusion of older proposals, can be found in the FeatureLog files for each package.
The following proposed enhancements are currently being disucssed:
Mark Fischler proposes a second threshold: setExitThreshold(s) says that if you encounter an error with severity at least s, terminate by using exit(s) as opposed to abort().
Done in the suggested way, this change is easy and non-obtrusive, and it meets the flexibility needs of CDF (who can change the severity of the several known problem-errors to ELfatal, and set the exit threshold to ELfatal.)
The rules used to decide whether to abort or exit, when encountering an error message of severity s, will be as follows:
A typical setup would be:
logger->setAboutThreshold (ELabort); // not really needed; this is default
With this setup, messages issued at ELfatal severity will
exit(), while messages issued at ELabort severity abort() and core dump.
User comments are solicited.
Mark Fischler estimates that each type of exception would involve individual coding, and that there will be some effort needed to see that the ZOOM Exceptions form and the CLHEP form can take the same throwing syntax.
The total implementation time is estimated as 6 days, and this is not fully a safe change, as the code changing is not at all localized. For now, we will wait a while; if any particular type of exception could benefit hugely from adding a piece of info, we could perhaps do it on a one-at-a-time basis.
User comments are solicited.
CMS production was stymied when Geant4 formed boosts from vectors provided by a generator whic (due to imperfect physics approximations) sometimes provided tachyonic vectors. The problem was that the LorentzRotation ctor was calling exit(); had it been throwing, CMS could catch that and move to the next event.
If the ZOOM version was in use, they could set the code to handle the situation, or they could catch the exception. The CLHEP version exit() was harder to recover from.
Mark Fischler has implemented this enhancement:
This enhancement has been tested and checked in.
noticed that after an integer is streamed to the errlog,
unless a hex format is requested or the int is the last item in the message,
no space is inserted after that
integer -- e.g.
5next item instead of
5 next item. This is annoying
and not consistent with other data types.
However, in order not to affect existing outputs of test and validation programs, we should keep the default the way it is, and provide an option fro the framework like
This would be an easy change to make, restricted to the ErrorLog class. ELtsErrorLog already does things in the suggested way.
This enhancement is implemented (March 18, 2004) and checked in to cvs.
Mark Fischler notes that the appropriate thing to query may be the ErrorLogger instance, not the ELadministrator. With that caveat, it seems this is a straightforword and low-risk enhancement.
The syntax will be
// The framework provided this code an ErrorLog called errlog
std::string currentModule = errlog.moduleName();
These methods are in no way magic: They only return the same information
that some other portion of the program has supplied via setModule() or
This enhancement is implemented (June 23, 2003) and checked in to cvs.
Unfortunately, it was subsequently learned that this feature does not accomplish what the requesting user needed -- learning what module was currently active, with NO access to an established errlog. The only way the ErrorLogger package deals with module names is by some ErrorLog being set up with a module name.
This feature may still be useful for others who are in the situation of having access to the relevant ErrorLog and wanting to know the module name.
Mark Fischler proposes the following addtional methods to ELdestControl:
Upon further reflection, the ostream() method is useless, misleading, and opens up a trap for the user. The intended principle use would be to allow the user to influence the formatting of the output ostream (for example, to select a non-default precision for output of doubles). But in fact, such formatting does not affect the content of the message, each item of which has been put into string form before reaching an destination.
Obtaining ostream still would allow a user to learn what stream had been opened so as to insert her own content; but that same can be accomplished by constructing the ELoutput from an ofstream in the first place. Since the benefits are so small, and the potential for confusion (with formatting) and traps is large, I am eliminating this proposed method.
This enhancement is implemented, tested and checked in to cvs (June 25, 2003).
The following methods are provided:
...What takes up the bulk of the space in the object file (at about 13k/exception) are the virtual functions generated for each exception, plus the vtab and tid information. At some point, it may be worth thinking about whether we really need to define the full set of virtual functions for every exception. For example, it appears that I can remove all of the virtual functions except for classInfo() without changing the behavior for the cases that I actually end up using.
Mark Fischler and Walter Brown are not confident that this can be done without potentially breaking other people's code which MAY take advatnage of the virtual methods. The code size gain is so large that it is probably worth looking into this, but we would have to come up with some SAFE way of doing it.
At this point, we would like to table this suggested enhancement, and see if in the long run it is worth the time and risk.
If other users feel this is of high priority, please let us know.
Discussion of the following enhancements, previously appearing on this page, has closed for reasons indicated:
Fermilab Physics Class Library Task Force