Discussions of Enhancements in ZOOM Packages

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:

ErrorLogger 018: Exit Threshold

Liz Sexton Kennedy (for CDF) requests a way to avoid the core dumps produced by abort() when ELabort-level exceptions are issued. For certain familiar sorts of problems, the core files are using too much disk space in production running.

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
  logger->setExitThreshold (ELfatal);
With this setup, messages issued at ELfatal severity will exit(), while messages issued at ELabort severity abort() and core dump.

User comments are solicited.

PhysicsVectors 006: Additional information for each type of exception

Bill Tanenbaum (for CMS) requests information added to the various thrown exception classes. For example, ZMxTachyonic could provide the offending vector.

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.

PhysicsVectors 005: Removal of exit() in favor of exceptions in CLHEP

Bill Tanenbaum (for CMS) requests that all instaces where CLHEP Vector calls exit() be changed to throw exceptions.

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.


ErrorLogger 017: Space after integer types

Mark Fischler 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

  errlog.spaceAfterInts().

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.

ErrorLogger 016: Obtaining Module Name

Andrew Hamilton requests a way to query the ELadministrator to get a string indicating what it thinks the current module name is.

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

(Note that in current implementations, ELstring is an alias for std::string.)

Thus,

  // 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 setSubroutine().

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.


ErrorLogger 015: Changing/flushing ostream for a destination

Wolfgang Wagner requests a way to change the file used by an ELoutput destination, and to make sure the output is flushed.

Mark Fischler proposes the following addtional methods to ELdestControl:

The last of these methods gives a user the opportunity to invoke whatever methods of the ostream are desired. Of course, there are things one can do which would lead to trouble, for example, invoking close() on an ostream used by a destination which might still receive messages.

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:


Exceptions 006: rethink virtuallity

S. Snyder notes that about 15K of code is generated per ZMthrow_ of a distinct ZMexception. He suggests that 85% of that might be eliminated by emasculating the virtuallity of the class -- his comment:

...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
Mark Fischler (mf@fnal.gov), Walter Brown (wb@fnal.gov), John Marraffino (marafino@fnal.gov), Philippe Canal (pcanal@fnal.gov)


Parent Pages:

ZOOM Home Page - Fermilab at Work - Fermilab Home