Closed DMWMBot closed 12 years ago
hufnagel: Whats wrong with /store/unmerged/WMAgentCommissioning12/Cosmics/ALCARECO/HcalCalHOCosmics-v1 ? That has always been the Tie0convention.
Change to force unmerged output is ok, but if you want to be picky this should only generally apply for all outputs if we use an event based splitting algorithm. If we use a lumi or file based algorithm, you would only need it on the ALCARECO output. As we cannot configure this selectively for different outputs for now, always forcing unmerged output is ok for now.
dballest: I see the lfns from the current data like: /pnfs/cms/WAX/11/store/data/Run2012A/AlCaPhiSym/ALCARECO/ALCARECOEcalCalPhiSym-v1/
Same in phedex.
/store/data/Run2012A/AlCaPhiSym/ALCARECO/ALCARECOEcalCalPhiSym-v1/000/190/663/8073EB4A-D982-E111-BCF0-003048F1182E.root
dballest: Sorry, just now I just see that it's different for datasets from AlCaPhiSym and others like Cosmics. Just a few have the ALCARECO as a prefix in the filter name.
But then in the wmagent we should make sure that ALCARECO appears in the right ones, but we only get the alcaProducer from the configuration. How could we know if it is needed to add the ALCARECO part? where does the T0 gets the ALCARECO part if we just put the alcaProducer name in the config?
hufnagel: There is an inconsistent behavior between Config.DP alcaSkim methods from different scenarios. Some scenarios (cosmics, pp) you pass in skims = ["skim1', "skim2"] and you get back configurations with filtername "skim1" and "skim2". Some scenarios (hcalnzs, Alca***) you pass in skims = ["skim3", "skim4"] and you get back configurations with filtername ALCARECOskim3 and ALCARECOskim4. The current Tie0reads the filtername from the configuration and uses that to build the LFN.
The WMAgent Tie0will build the LFN based on the information we pass to Config.DP, not based on what we get back (there are hard technical reasons this cannot be done another way). This means in the new system no LFN will contain the extra ALCARECO. I will follow up with the Alca team on this.
dballest: Thanks, then with the attached patch the spec should be ready (depends on #3619).
dballest: Found that AlcaSkims output was not being merged, Steve found that the problem is that as the Reco is Eventbased then the AlcaSkim must be WMBSMergeBySize to work properly.
Changed that in the patch.
dballest: Improved the unit test so that the Tier1PromptReco spec without promptSkims can be tested without integration with scram. Two tests are now inside Tier1PromptReco_t, one for the tier1PromptReco spec without skims and other with skims. Both work on the current version of the spec.
sfoulkes: (In 38993141e33d7e24849c11a5e87c1645c63ec762) Fix problems with ALCARECO handling in the Tier1PromptReco spec. Clean up it's unit test. Fixes #3620.
From: Diego Ballesteros dballest@fnal.gov Signed-off-by: Steve Foulkes sfoulkes@fnal.gov
AlcaSkims should be the only merged output for ALCARECO, so I added the forceUnmerged to the reco task and added the missing cleanup.
I see the filterName for alcaSkims is just the skimName (e.g. DtCalibCosmics) so the LFN once we include the filter name will be like /store/unmerged/WMAgentCommissioning12/Cosmics/ALCARECO/HcalCalHOCosmics-v1
I added a change to make it:
'/store/unmerged/WMAgentCommissioning12/Cosmics/ALCARECO/ALCARECOHcalCalHOCosmics-v1'
But will that affect the cmsRun config? The pickled arguments are still just the skim names, e.g.:
{{{ msRun1.application.section_('configuration') cmsRun1.application.configuration.function = 'alcaSkim' cmsRun1.application.configuration.pickledarguments = '(dp0 S'globalTag' p1 S'GR_PV29::All' p2 sS'skims' p3 (lp4 S'TkAlCosmics0T' p5 aS'MuAlGlobalCosmics' p6 aS'HcalCalHOCosmics' p7 as.' cmsRun1.application.configuration.section('arguments') cmsRun1.application.configuration.arguments.globalTag = 'GR_P_V29::All' cmsRun1.application.configuration.arguments.skims = ['TkAlCosmics0T', 'MuAlGlobalCosmics', 'HcalCalHOCosmics'] }}}
Unit test works. Dirk could you review it please?