Requested: Olga, Manuel, Alex, Jamie, Maxim
Purpose: Review of all HF requests, current opened questions, priorities, policies, comunication channel understanding, opened questions.

Attendee: Jamie, Manuel, Maxim, Alex (Olga could not attend due topersonal matters)

The meeting started with a general procedure reminder as per the communication level between the embedding team and the PWGC /PWG. The general current (implicit) understanding is that the process will follow the steps as described:

• A PA makes a request within the PWG, the PA is approved by the PWGC to move along with making a formal request
• The Web interface is used to make a request. The PA is the contact person.
  • Note: The requests may be prioritized by the PAC or S&C leader depending on (respectively) physics priorities or technical feasibilities and optimization.
• Upon submission, the request is inspected by the embedding team.
  • Precision may be requested to the PA
  • The request is modified until it become comprehensive
• A sample is produced – QA is requested
• Feedback is provided, the full request is scheduled

Several area may need reshape as per the procedure.

1. The request page is ambiguous – an effort was started to reshape the interface (view [node:3206] for more information, tasks 49 to 51)
2. The communication is ambiguous
   1. often one Email is sent and no reminders (easer side) and no pro-active checks for follow-ups.
   2. S&C meeting status overview is generally not attended by PWG representatives.

As follow-ups of this discussion:

• The requirements for a new embedding request form will be sent to all PWG - We expect from the PWG a pro-active look at it and feedback what in the past was clear/not clear and what the requirements do address/do not address
• We assume that the new interface will allow later to send automated reminders to the PA via cron. A db back-end will be needed (implementation detail).
• We propose that the embedding coordinator would pro-actively send reminder (or delegate tasks to the embedding team consistent with moving the tasks along faster).
• We will assume that the PWGC are prime responsible for ensuring the requests are answered from the PWG side.

We discussed the requests from the PWGC as per what is on [node:3987] (comment 127). We inspected the first 9 requests keeping in mind the suggestions made as comment 126. The following was agreed upon:

• Request 7, 1154003633 is more trigger problematic and may need to be addressed at a later time embedding wise and will be put on hold.
• Request 8, 1154004721 should have a related paper coming out soon. We will keep it in.
• Requests 1 and 2 should be the highest priorities

Procedure and action items:

• An embedding request is best submitted related to an ongoing/incomplete analysis. PWG should proceed with a simulation request (much simpler and not requiring another dimension of data/mixed with simulation and hence, confusion with chain, timestamp etc...) and then move to embedding for semi-final results.
• The Vertex options VFMCE and VFFV aimed to consolidate the embedding framework.
  • VFFV: use a default vertex at (0,0,0) but is envisioned to be used to set the vertex to whatever appropriate value taken from an extrenal knowledge. Especially, the method StFixedVertexFinder::SetVertexPosition() - Possible use of this relates to the (hopefully) old way of doing embedding when an external file contains vertex information. This option could be used to set “a” vertex event by event.
    Method was implemented by Lee Barnby upon requirement request from the S&C project in May 2006.
  • VFMCE: This option was added to replace the StEvent vertex by the Monte-Carlo vertex. The implementation simply overwrites the vertex.
    Method was implemented by Jerome Lauret & Lee Barnby May 2006.
    Sti vertex constraint was fixed by Victor Perevoztchikov – Beware that the default vertex errors are 1 microns in all directions if set to null.

While we believe the vertex issue is very secondary to Xiaoyan's analysis, it was agreed that the vertex finder to be used is VFMCE, dropping any vertex from the data event and using the Monte Carlo vertex. This will be the case for all Cu+Cu and p+p embedding requests including 2006 data.
The code for FVMCE need backward propagation pending a bug tracking report to be submitted by Andrew Rose (chain and input file needed to debug).

Requested: Olga & Andrew
Purpose: Technical and Historical background & status update

Olga provided a list of all embedding requests and their status. We discussed especially the requests 1154004033, 1154004074, 1166698516 and 1166698601 (highlighted). The first two were discussed in August 2006 via Email as well as diverse lists and fora. For historical completeness, it was mentioned that neither of those requests were completely defined before a much later time. The first two were not until October 18th when the meaning of "good B-EMC data" was explained and sorted out. The same applies for the later two requests which were sorted out (same issue) on the 7th of January 2007.

Action item:

• Andrew will send Jerome the side related Emails in regard of feedback gathering and the run selection provided by the PAs.

   

 

On the technical/physics detail: there are no apparent technical detail at this stage, the code seems to be running. The default vertex finder (Minuit improved) relying on the B-EMC would likely be problematic and in fact, no vertex are currently reconstructed. This may be due to many issues (would need to trace and debug). The following options to be used were suggested as either:

1. VFFV Fixed vertex finder (0,0 TBC)
2. VFMCE Vertex finder used as within McEvent

The choice of one or the other depends on Physics objectives. Queried mid-2006, it was unclear what was the PA's perception nor needs related to the vertex.

Action items:

• Andrew will check the VF options and report (one job each or 10 events)
• The choice of VF will be sorted out the PWGC and the PAC on Thursday.

 

Some issues and concerns have been emitted as per the meaningfulnesses of the Upsilon embedding. The low number of upsilon and an analysis dominated by PID cuts and other analysis related error bars may indicate that a full embedding scheme could be an over-kill. Also, it is understood that the current

steps taken by the PA (going for pure simulation run for electron request) is out of 'alternate choice' rather than 'preferred choice' and it is agreed we would need to actively understand the request and its intent once again (and certainly "fully" understand it this time).

Action item:

• Will discuss this issues with PWGC on Thursday

The issue of priority relevance was raised. Shall the priorities remain as they are rather than being revisited for "post QM" reality?

Action item:

• Jerome will get back to Jamie and/or Alex & Manuel on this issue and get a new priority ordering out
• Jerome will set the meeting with the PWGC, PAC and Olga + Maxim if needed. It appears to first order that the requests would be back to an embedding request apart from the Upsilon to be discussed.

---

Here is the details of Heavy Flavor requests:

First, the easy ones:
1121704015 J/Psi Au+Au
1112996520 pi0 62 GeV Au+Au
1112996461 e 62 GeV Au+Au
→ all closed be convenor's request

1154003633 J/Psi embedding for pp2006
1154003721 Upsilon embedding for pp2006
→ have not tried yet, can't overcome pp2005 troubles

1154003879 electron embedding for Cu+Cu 2005
→ test sample done, QA done, production started

1154003931 pi0 embedding for Cu+Cu 2005
→ not yet done, but should not be a problem

1154003958 gamma embedding for Cu+Cu 2005
→ not yet done, but should not be a problem

1154004033 electron embedding for p+p 2005
1154004074 pi0 embedding for p+p 2005
→ those two have been attempted many times, failed for various reasons. The latest one - no primary vertex found in reconstruction

1166698660 J/Psi embedding in Au+Au with shifted vertex
→ Sample produced, never heard from PAs (done in a rush before QM), no QA

1166698180 Ds in d+Au
→ This request was turned into embedding just last week or so (was pure simulation before).

1166698516 J/Psi embedding in Cu+Cu
1166698601 Upsilon embedding in Cu+Cu events
→ those two could be done, but would be good to get some input back on QM J/psi sample.

1093385624 electron embedding for Au+Au 62 GeV
→ not done yet. ... could be very well approximated by other date available.