NOTES FROM MEETING ON MC PRODUCTION M. Moulson 21-Oct-2002 ============================================================== Here are the notes from the meeting on MC production that took place on 21-Oct-2002. The notes make reference by title to my slides for the meeting, which are available at http://www.lnf.infn.it/kloe/private/mc/Presentations/ Slide 2: What to produce? ------------------------- The my proposal to produce 500 pb-1 of K_S -> all, K_L -> in a unified production campaign was the subject of some discussion. C. Bloise offered the alternative proposal to subdivide the production campaign by decay channel, at least for K_S -> pi0 pi0 and K_S -> pi+ pi-. The advantages of dividing up the production basically consist of logistical simplicity during the analysis phase, since there is smaller volume of MC DST's for each channel. (Note: if DST's are made according to the following proposal, the total volume for 500 pb-1 of K_S, K_L -> all is 1--2 TB, roughly equivalent in size to the dk0 DST data set.) The advantages of unified production are basically logistical simplicity during the production phase, since there are a smaller number of different types of jobs to handle. Additional advantages of diversified production are that different priorities and/or different levels of statistics can be assigned to individual generations. (Note that this can also be a disadvantage, in that it can open up the discussion to a lot of personal advocacy.) An additional advantage to unified production is that, since events occur in natural ratios in the same file, the results could be better suited for background studies (especially if there is unsuspected background from a particular channel for an analysis). In any case, the issue is far from resolved. People are requested to think about this for discussion at the next meeting. Slide 4: Upgrades to MC ----------------------- The purpose of this slide was to determine what work, if any, needs to be done on the MC before the production campaign begins. The work that needs to be done is grouped slightly differently from the manner illustrated on the slide. Initial state radiation: There are 3 items to consider. First, the form of the radiator needs to be changed. Second, in the current ISR simulator, only one beam can radiate at a time. These are easy to fix. Third, the ISR does not depend on the phi decay channel. In fact, in the simulation, root-s is chosen by sampling as the first step. Thus, the code will have to be arranged somewhat. The first two items will be fixed before the generation. As for the third item, the ISR will probably be simulated for the K0-K0 channel for the time being. This will allow the production campaign for K_S K_L to begin, while work on a new implementation of ISR in the MC continues. Person in charge: M. Antonelli. DC geometry review: The idea here is to conduct a comprehensive survey of potential problems related to the representation of the DC in the simulation. Potential areas of concern include: - Wire sag. There is less tension on the wires in the first ~10 layers due to a manufacturing problem. This layer dependence of the wire sag is not currently simulated, but probably should be. - Composition and thickness of DC walls, both inner and outer. This needs verification. - Any other geometry issues. People in charge: A. Antonelli, S. Dell'Agnello. EmC geometry review: A similar review needs to be performed for the calorimeter. Some known problems will probably be addressed during reconstruction instead of generation. For example: - Threshold simulation. - Decrease in efficiency near cracks between modules due to cut fibers. Person in charge: S. Miscetti Slides 5--6 on DST's -------------------- Not really a lot of discussion here; the proposal seems to have been accepted as a starting point. Clearly it needs to be worked up, so that we can get size estimates, etc. Person in charge of code development is M. Moulson. C. Bloise and S. Miscetti will take a look at the QCAL banks and make a proposal about how to treat them. Slides 7--8 on background insertion ----------------------------------- Not really a lot of discussion here either; this was just a summary of the current status. MC background is the subject of a separate series of meetings in any case. Note that there has been progress in the areas of event selection (S. Miscetti) and insertion coding (M. Moulson, V. Patera). Slide 9: Possible scheme for production --------------------------------------- This is probably not very self explanatory for web viewing. The idea is the following: There are two production modes, that which will be used at the start of generation, assuming that background is not yet available, and that which will be adopted once background becomes available. The black lines are steps that are performed always. The red dashed lines represent what needs to be done once background becomes available for files that have already been generated and reconstructed once. The blue dotted lines are steps performed after background becomes available for production of new files. Before background becomes available, the generated MC output is reconstructed (.mcr file) and DST's are made (.dst file). After background becomes available, the .mcr files created in the first step are re-reconstructed, introducing background (and whatever other features become available in the new MC reconstruction, such as calorimeter threshold simulation). The resulting .mcr files are probably not kept. The resulting .dst files replace those generated previously. After all previously reconstructed files are finished, the reconstruction follows new generation and .mcr files are kept, as in the first step. Slide 10: Allocation of computing resources ------------------------------------------- C. Bloise offered the following estimate of the CPU consumption for the KPM DST's: 40 CPU's can process an estimated 25 pb-1/day. Therefore, the CPU needs for the KPM DST's are not extreme. The time needed for MC production may be overestimated as well. C. Bloise reports that, in the limit of no losses in efficiency due to human downtime, the Sun machines themselves are capable of generating and processing up to 4 million events/day instead of 1 million. The discussion centered around how best to use the Sun machines. It is clear that, if we wanted to, we could perform both the KPM DST production and the MC production on the IBM machines. The KPM DST's pretty much have to be made on IBM's in order to protect against fluctuations in the event selection criteria (for technical reasons, event classification is part of KPM DST production, and the data were essentially all reconstructed on IBM machines.) Reconstruction of MC events on IBM machines may be desirable for the same reasons. On the other hand, the good performance, and indeed, the correct function of GEANFI on the IBM machines remains to be ascertained. Assuming that both the KPM DST's and the MC campaign can run on the IBM machines, there is concern about how to use the Sun machines. A related concern is that the Sun machines do not fall into disuse, since we may need them someday. One proposal is to move the users to the Sun machines, apart from perhaps one IBM machine to be used for development. The Sun machines could also be used for specialized MC production of small samples (e.g., signal events for comparatively rare channels). In this case, the configuration of the machines as far as user access is concerned may remain unchanged. The issue is not settled and needs additional discussion. A major point in this regard is testing the status of GEANFI on the IBM machines. Person in charge of this is S. Giovannella. NEXT MEETING AND SUMMARY OF ASSIGNED TASKS ------------------------------------------ The next meeting will be held on 30 Oct. At that time, status reports are expected from the following people: M. Antonelli: ISR in the MC A. Antonelli, S. Dell'Agnello: DC geometry review S. Miscetti, M. Palutan: EmC geometry review M. Moulson: Bank-reduction code for DST's I. Sfiligoi: DB modifications for DST's C. Bloise, S. Miscetti: QCAL banks for MC DST's M. Moulson, S. Miscetti, V. Patera: Background insertion S. Giovannella: GEANFI on IBM