I am in the final stages of retrofitting SIO into our baseline Gismo/GismoApps.
So now might be the time to set up an SIO punch list:
1) Pending Masako's confirmation, I believe that Gismo/GismoApps produce
identical -data- in ASCII and SIO format. On the other hand, I have made
no provision for SIO to produce the conventional ASCII file -header-
consisting of the complete geometry description used in the job. How
should this be handled?
a) I could simply write out the ASCII strings as SIO data.
b) I could write out the name of the file which the program read to
get it's geometry data (a little risky ... we have no formal method
defined to handle desciption file evolution).
c) We could ignore the problem. (Not good!)
I'm looking for a good idea here. Please remember that the solution
should be able to evolve to handle Joanne's XML files.
2) I am currently writing all floating point numbers as 'float'. Should
we go to 'double'? I note that the current asc2root converts everything
to 'float' so the extra precision would be lost there. What would JAS
prefer? Does it matter? (It could be argued that 'float' precision is
plenty for hit positions, direction cosines, energy,... . I start
getting uncomfortable when it comes to things like error matrices
where even small losses in precision can result in instabilities).
3) I have checked out a 100 event tt(bar) dataset and can confirm that the
baseline Gismo/GismoApps -never- produces calorimetry hits without
tracing their parentage back to the original showering particle. The
same is not true for tracking. There are still many central tracker
hits and even a few VXD hits appearing without a parent track. I presume
these are the result of shower albedo coming back into the tracking
devices. Is this how we want to handle this?
4) I have done nothing to introduce SIO into the fastMC chain.
5) As you can guess from the fact that I can ask Masako to check out Root
files produced from SIO files, I have a program S2R (SIO-to-Root) ready
to go. It currently sits in my private file space. I presume that it
should go into RootApps, but I'm a little leery of doing that yet because
things seem to be changing fast in there. What is the plan for RootApps?
Are we going to put it in DEC? (In which case I'd better ensure that DEC
learns how to generate shareables).
6) Anything I've forgotten?
Tony Waite.
|