2010/01 new requirements and features for the embed/simu module

Related links

New requirements and features

Blue: done



  • Human readable requestID
    • Suggestion #1: use European style date + nn for an incremental number per day - format = YYYYMMDDnn
    • Suggestion #2: use YYYWWnn where WW is the result of %W (i.e. week numbre in year as used for the S&C and Grid meeting annoucement - shorter, still clear)
    • Either case would have the advantage of being compact enough to be remembered and self explanatory as per the date of the request
  • Add requestID back to the overview page and allow sorting by requestID
  • We need better filters / selectors. This could be a long list of features
    • Goal: we should be able to combine selectors i.e. individual selectors should be set in such a way that we could perform AND and NOT operations.
    • Use case:
      • Filter request type embedding AND pwg=Heavy Flavor
      • Filter all requests type AND NOT pwg=Spin
      • Filter out the status='closed'  [this should be a default]
    • Comment: we should have the ability to negate fields such as "not a closed requests" (assuming killed and closed are not showed by default). In this particular case, it may equate to a twisted logic "only opened requests in any state < N" (easier implementation should decide / functionalities owuld be the same)
    • Suggestion: Thunderbird like selectors would be appropriate?
  • Sorting: when sorting by priority, we have to make the 'closed' requests sorted in a different group and appear at the bottom.
    • Note: Perhaps there is a smarter way such as using groupings (group could be state and req.type, default grouping could be one for everything else than status=closed). But this idea may complicate the interface ... Groupings could however lead (or be consistent with) filters.
  • Addition of a 'cloning' feature (create from a past request and modify little)
    • Suggestions:
      • 'clone' reads from original node ID, copy to new node ID as default field filled.
      • A new request ID need to be generated.
      • Be careful of the 'requester' now auto-filled (it may change) hence the precedence for the logic.
      • Status of a cloned request should not be copied but reset to new
      • Priority should be reset to 0
      • ... there may be other field to watch for ...
  • Addition of sub-request feature(hence a master request)
    • ATTENTION: functional requirement should be restricted to similar requests. The feature should NOT become a way to sort un-related requests under the same flag and hence the same priority but a way to replicate a template and change only a few (to one) parameter)
    • Use case:
      • Two samples with two different event generators for comparisons
      • Multiple Pt bins (all the rest is the same apart perhaps for the number of events in each bin)
      • Change the decay mode, multiple samples
    • Functional requirement of a "master request":
      • All base parameters used for viewing the request summary should be copied to the master request (including priority)
      • A master request is considered closed whenever all sub-requests are done/closed. The status of the master request is is the least common denominator for all sub-requests
    • Suggested:
      • Approach #1: Generate a master request from a fully specified request, use cloning for adding more request of the same kind allowing (through a check box indicating which field would change) only a few fields modifications. As stated, number of events should always be modifiable.
      • Approach #2: Create a master request only filling a few field, indicates which one would change - initiate the cloning from the master request ensuring / validating the fields selected as changing for the sub-requests


  • The current requests were sorted by priorities in descending order whereas 100 is the lowest priority and 1 the highest. Sorting would need to be changed in descending order for EC priority.
  • I found several issues as I was parsing a few jobs:
    • Chain options contained &amp; (see for example You do not have access to view this node.
    • The same happens for detector setup which becomes unreadable (what happened?)
  • Change the default EC priority to 0


Presentation / information

  • Gaussian sigma xyz - small text in form under box says "Z" for all three field - should be corrected
  • There are no options to specify the Z vertex offset from Z=0. This should appear and be saved.
  • Several fields require an number input bit it is not at all clear what the units should be (please, review and add)
  • Similarly, an example input for each field would be helpful
  • "Number of events" accepted a number 160000 but not 160k. It is suggested to allow for "k" and "M" to be allowed.