MC Job Options issueshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues2021-05-18T11:32:21+02:00https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/142Follow-up from "LO EFT samples for 4top"2021-05-18T11:32:21+02:00Spyros ArgyropoulosFollow-up from "LO EFT samples for 4top"The following discussions from !1161 should be addressed:
> This shouldn't be part of a JobOption. The first part was fixed properly in 21.6.60 and the second part is obviously gonna cause problems. `ATHENA_PROC_NUMBER` is set to 8 ...The following discussions from !1161 should be addressed:
> This shouldn't be part of a JobOption. The first part was fixed properly in 21.6.60 and the second part is obviously gonna cause problems. `ATHENA_PROC_NUMBER` is set to 8 because the machine has 8 cores, it shouldn't be set to 80 in the JOs.
Should we add the following checks/changes:
- if ATHENA_PROC_NUMBER > 1 and release < 21.2.60 => ERROR
- if ATHENA_PROC_NUMBER > 1 => run only 1 event in CI
- change the way we check whether the jO changes ATHENA_PROC_NUMBER - this would only be safe to catch in the transform btw, but until it is implemented there we could change the check to not use anywhere ATHENA_PROC_NUMBER (not even printing it), so e.g. look in the jO and if there is an uncommented line with "ATHENA_PROC_NUMBER" in it then give error
@cgutschoS1.2021Spyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/143Follow-up from ATLMCPROD-93322021-06-07T14:15:29+02:00Spyros ArgyropoulosFollow-up from ATLMCPROD-9332The following discussion from !1198 should be addressed:
- [ ] @cgutscho started a [discussion](https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/merge_requests/1198#note_4542318): (+5 comments)
> Hi @sargyrop - this might b...The following discussion from !1198 should be addressed:
- [ ] @cgutscho started a [discussion](https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/merge_requests/1198#note_4542318): (+5 comments)
> Hi @sargyrop - this might be a long shot, but do you think this is something we can catch in the CI? e.g. if there's a variable in MadGraph JOs that has `gridpack` or `grid_pack` in the name and it's still set to `True`, we put out a warning ... ?
>
> Cheers,
> Chris
Make logParser fail if the info in Chris's message below appearsS1.2021https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/144Pipelines failing when only links are included?2021-06-21T16:50:31+02:00Spyros ArgyropoulosPipelines failing when only links are included?The following discussion from !1225 should be addressed:
- [ ] @jshahini started a [discussion](https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/merge_requests/1225#note_4588898): (+1 comment)
> Hi @cgutscho
>
> I...The following discussion from !1225 should be addressed:
- [ ] @jshahini started a [discussion](https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/merge_requests/1225#note_4588898): (+1 comment)
> Hi @cgutscho
>
> Indeed it is a duplicate, but this is by design in order to clear the CI. To give some context, these JOs are for a SUSY grid expansion.
>
> I originally tried to upload everything using only symlinks to that control file, but the CI pipelines were failing, claiming that the jobs couldn't find ```MadGraphControl_SimplifiedModel_GG_directRPVLQD.py```
>
> So I duplicated the control file you pointed to and included it in this MR so that the pipelines would succeed. After the MR gets accepted, I was going to make another one where I change all the control files to be symlinks to ```/502xxx/502416/MadGraphControl_SimplifiedModel_GG_directRPVLQD.py```. That way, there would be no duplicated control files floating around.
>
> I realize this is remarkably convoluted, so I'm more than happy to hear other ideas about preparing the JOs for grid expansions in R21.
>
> Cheers,
> Jeff
Failed pipeline: https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/pipelines/2741834
![Screenshot_2021-06-21_at_14.50.38](/uploads/1b1ebf50941d6c15803a23b2ad2bcd32/Screenshot_2021-06-21_at_14.50.38.png)S1.2021Spyros ArgyropoulosSpyros Argyropoulos2021-06-27https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/145Powheg-specific check needs adjusting2021-07-22T12:24:42+02:00Christian GutschowPowheg-specific check needs adjustingSeen in !1257: If the process is bb4l, i.e. it includes `PowhegControl/PowhegControl_bblvlv_Common.py`, then it won't need to include the Main31 include as well, which is what the logParser is currently checking.
cc @jkretzSeen in !1257: If the process is bb4l, i.e. it includes `PowhegControl/PowhegControl_bblvlv_Common.py`, then it won't need to include the Main31 include as well, which is what the logParser is currently checking.
cc @jkretzhttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/147Support for 7-digit DSIDs2022-04-01T15:44:37+02:00Christian GutschowSupport for 7-digit DSIDsDraft proposal discussed in [GIT meeting](https://indico.cern.ch/event/1061701/#23-support-for-7-digit-dsids-i):
* Stick to current repo, look into sparse checkouts in case response time becomes unsatisfactory
* keep 6-digit structure ...Draft proposal discussed in [GIT meeting](https://indico.cern.ch/event/1061701/#23-support-for-7-digit-dsids-i):
* Stick to current repo, look into sparse checkouts in case response time becomes unsatisfactory
* keep 6-digit structure as is, group 7-digits in millions, then in thousands
* Retain grouping by generator (?) for 7-digits (`15xxxxx` Madgraph, `16xxxxx` Powheg etc.)
* can use `10xxxxx` - `14xxxxx` for large BSM scans for instance
* keep using 6-digits for now, but introduce simple mechanism to disable 6-digit booking altogether at some pointChristian GutschowChristian Gutschowhttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/148use unweighted filter efficiency to calculate number of required input events2021-08-02T12:04:37+02:00Jan Kretzschmaruse unweighted filter efficiency to calculate number of required input eventsIn !1289 I had the issue, that the commit script appears to use the "weighted filter efficiency" to compute the number or needed input events as opposed to the "unweighted" one. This is not correct, take the example (attached) of highly-...In !1289 I had the issue, that the commit script appears to use the "weighted filter efficiency" to compute the number or needed input events as opposed to the "unweighted" one. This is not correct, take the example (attached) of highly-weighted input events, where the filter is removing preferrentially high-weight events, thus we get
Filter Efficiency = 0.570255 [10000 / 17536]
Weighted Filter Efficiency = 0.014686 [26912615882800.000000 / 1832511495909600.000000]
The relevant number to see if the job runs is the unweighted number, as this really tells us how many events need to pass.
[log.generate.gz](/uploads/b16f899af8781a4312d63c03ce12cf79/log.generate.gz)
Maybe a separate issue: it appears there is a blanket 10% safety applied. Note while I have not correctly calculated the right number, this can be both to little and too much and a safety of 4*sqrt[target output events]/[filter eff] would probably be better (this would be ~4sigma)
Example 1: number of output events is 10000, so "4sigma" would be ~400 events, or just 4%
Example 2: number of output events is 50, so "4sigma" would be ~14 events, or 14%Spyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/149NLHE check not working well in CI2022-03-12T09:33:06+01:00Christian GutschowNLHE check not working well in CIAs seen in !1304.
Maybe this check could be based on the extrapolated number of events?
> For a sufficiently large `nEventsPerJob` the 10% is more conservative than 4 sigma, so no harm done, albeit a bit more inefficient. For low `nEve...As seen in !1304.
Maybe this check could be based on the extrapolated number of events?
> For a sufficiently large `nEventsPerJob` the 10% is more conservative than 4 sigma, so no harm done, albeit a bit more inefficient. For low `nEventsPerJob` 4sigma is more conservative and people would probably anyway notice this in their local runs and choose a larger margin (e.g. factors of 25 rather than 1.1). So arguably the 4sigma thing is probably not needed in practice, provided people actually test their setups locally...
Maybe @jkretz should indicate what his preference is for the long run, but at the moment this new rule is causing the CI to crash frequently for no good reason, so we need to patch somehow.
Another option is to remove the 4sigma rule and go back to the previous check with 10% extra events, or that we have the 4sigma rule only for jobs that have a small number of requested output events (although it's actually impossible to know if people just test with a low number of events)https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/150Make CI job that sends email to conveners2021-09-30T13:43:46+02:00Spyros ArgyropoulosMake CI job that sends email to conveners- when commit message contains [skip modfiles]
- also when files are actually modified ? (we probably want this as well - some people add skip modfiles when there's no reason to)- when commit message contains [skip modfiles]
- also when files are actually modified ? (we probably want this as well - some people add skip modfiles when there's no reason to)Spyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/151Support for multiple tarballs with different COM energy2021-10-12T15:31:16+02:00Christian GutschowSupport for multiple tarballs with different COM energyThis should not have crashed:
Job [#16844556](https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/jobs/16844556) failed for 9efbabb68119e3a4a2bf19113c4d8f3ffeb2b9e9:
It used to be working, so not sure what's changed?This should not have crashed:
Job [#16844556](https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/jobs/16844556) failed for 9efbabb68119e3a4a2bf19113c4d8f3ffeb2b9e9:
It used to be working, so not sure what's changed?Spyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/152Skip the check for 10% extra LHE events in case of LHE-only jobs2021-11-10T11:51:30+01:00Jan KretzschmarSkip the check for 10% extra LHE events in case of LHE-only jobsHi,
In preparing some LHE-only jobs with MG (e.g. https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/merge_requests/1462) I hit the issue that this check https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/blob/master/scripts/lo...Hi,
In preparing some LHE-only jobs with MG (e.g. https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/merge_requests/1462) I hit the issue that this check https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/blob/master/scripts/logParser.py#L307-316 demands "10% more" LHE events. Obviously, in an LHE-only job this can never be passed, as the number of events requested is the number of events in the LHE file. Can this check be disabled? I guess the condition would be sth like "--outputTXTFile" present and "--outputEVNTFile" absent.
Looking at this again, I wonder if skipping this check in case of externally supplied LHE files actually makes sense as stated in the comment `# This check only makes sense if no external LHE inputs are used` - you'd normally want this to be checked also in this case?
Thanks, Jan
PS: for the above MR I circumvented the issue by hacking logParser locally to remove these lines(!)Spyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/153Do not throw warning from dummy CI job if a jO has not been committed2021-12-08T11:47:38+01:00Spyros ArgyropoulosDo not throw warning from dummy CI job if a jO has not been committedSpyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/154CI cannot deal with integration grids for several ECM being present2021-11-16T21:10:54+01:00Jan KretzschmarCI cannot deal with integration grids for several ECM being presentI'm trying to commit new jO that come with integration grids. https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/merge_requests/1485
As we want to run it at different sqrt(s) value, we need several of those. the Gen_tf.py transform ...I'm trying to commit new jO that come with integration grids. https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/merge_requests/1485
As we want to run it at different sqrt(s) value, we need several of those. the Gen_tf.py transform works this out correctly.
However, the CI bails on trying to copy the GRID file, because it expects just a single file https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/blob/master/scripts/run_athena.sh#L136
Probably the best solution would be to copy the right file for the srt(s) value in question that would be sth like `mc_${sqrts}TeV.*.GRID.tar.gz` instead of `*.GRID.tar.gz`.
And ${sqrts} should be either an integer like 5,7,8,13,14 or 8p16 or 13p6 for special values.Spyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/155MR not being linked on JIRAs2021-12-03T14:57:38+01:00Matthew GignacMR not being linked on JIRAsIn some recent requests, it was noticed that the MRs are not being linked on JIRA. For example see: https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/merge_requests/1510In some recent requests, it was noticed that the MRs are not being linked on JIRA. For example see: https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/merge_requests/1510Spyros ArgyropoulosSpyros Argyropoulos2021-12-05https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/156commit_new_dsid.sh replace correct symbolic links2022-02-20T19:39:51+01:00Yiming Abulaiticommit_new_dsid.sh replace correct symbolic linksDear,
The commit_new_dsid.sh script replaces the DSID path in the symbolic event if the symbolic link is correct.
for example, my symbolic link is "../../510xxx/510250/file". When the script copy 100xx/* to DSID directory the "../../510...Dear,
The commit_new_dsid.sh script replaces the DSID path in the symbolic event if the symbolic link is correct.
for example, my symbolic link is "../../510xxx/510250/file". When the script copy 100xx/* to DSID directory the "../../510xxx/510250/" is replaced by the first new DSID (for example "../../511xxx/511424/").
Is it possible to let commit_new_dsid.sh keep the symbolic links when it is in 500xx-999xx range?
Cheers,
AbletSpyros ArgyropoulosSpyros Argyropoulos2022-02-20https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/157logParser.py didn't grep inputGeneratorFile2022-03-02T09:41:23+01:00Yiming AbulaitilogParser.py didn't grep inputGeneratorFileHi
---- This is for LHE files as inputs -----
Bellow is the content of log.generate.short, this log file is generated with 21.6.75
---------
- estimated CPU for CI job = 0.00 hrs
- using release = AthGeneration-21.6.75
- ecmEnergy = ...Hi
---- This is for LHE files as inputs -----
Bellow is the content of log.generate.short, this log file is generated with 21.6.75
---------
- estimated CPU for CI job = 0.00 hrs
- using release = AthGeneration-21.6.75
- ecmEnergy = 13000.0
- inputGeneratorFile = 09:20:14 Py:Gen_tf INFO inputGeneratorFile = TXT.440365._000001.tar.gz
- randomSeed = 1234
- EVNT to EVNT = False
- LHEonly = False
---------------
The inputGeneratorFile field is messed up here.
But the logParser.py works fine with old releases like 21.6.56. The reason is that athena print out changed in new release (this is what I observed):
Print out from 21.6.56:
--> 16:06:18 Py:Gen_tf INFO inputGeneratorFile used TXT.440329._000001.tar.gz
Print out from 21.6.75:
--> 09:09:41 Py:Gen_tf INFO inputGeneratorFile = TXT.440363._000001.tar.gz
You can see the changed from "used" to "=".
The line [L159](https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/blob/master/scripts/logParser.py#L159) has to check both "used" and "=" to accommodate changes made in athena.
Cheers,
AbletSpyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/158Handle purple list in logParser2022-05-05T16:15:51+02:00Spyros ArgyropoulosHandle purple list in logParserTBD if this is something that we can catch and report e.g. in the parser
See !1673TBD if this is something that we can catch and report e.g. in the parser
See !1673Spyros ArgyropoulosSpyros Argyropoulos2022-04-01https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/159Allow run_athena to run 13p6 TeV2022-05-10T11:04:58+02:00Spyros ArgyropoulosAllow run_athena to run 13p6 TeVCurrently only `mc15_13TeV` and `mc16_13TeV` external LHE files are handled in run_athena. Should be extended to `mc16_13p6TeV` and `mc21_13p6TeV`.
Check if we can automate this so that we don't need to hard-code things as done now.Currently only `mc15_13TeV` and `mc16_13TeV` external LHE files are handled in run_athena. Should be extended to `mc16_13p6TeV` and `mc21_13p6TeV`.
Check if we can automate this so that we don't need to hard-code things as done now.Spyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/160check_unique_controlFile too loose2022-04-10T13:51:04+02:00Spyros Argyropouloscheck_unique_controlFile too looseI notice in !1694 that due to mistakes in previous MRs there are spurious errors, check https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/jobs/20185882
This is because https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/blob/...I notice in !1694 that due to mistakes in previous MRs there are spurious errors, check https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/jobs/20185882
This is because https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/blob/master/507xxx/507035/MadGraphControl_Py8EG_2HDMa_monoH_common.py is a file rather than a link.
This means that all the future MRs that will point to this control file (and it's almost certain we'll have more) will all have the same spurious errors.
In fact this is going to happen for all files that should be links and weren't so the situation is going to become worse with time. I would therefore propose to make the test stricter, i.e. we should not allow two physical files with the same name and the same content. If the content is different then the name should be adjusted. And we should not allow the CI job to fail.
Is there any objection @jkretz @mgignac @cgutscho ?Spyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/161logParser expects randomSeed arg even for E2E jobs2022-03-25T14:51:01+01:00Jan KretzschmarlogParser expects randomSeed arg even for E2E jobsHi,
in https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/merge_requests/1725 I think I 'discovered' an issue that the logParser requires the argument 'randomSeed' to be present also for EVNT-to-EVNT (afterburner filtering) jobs. T...Hi,
in https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/merge_requests/1725 I think I 'discovered' an issue that the logParser requires the argument 'randomSeed' to be present also for EVNT-to-EVNT (afterburner filtering) jobs. The problem is: even if you give the argument, it is not printed to the log file. Not sure if this is an issue of the transform, but in any case these jobs are not really supposed to need ranfdom numbers in most case.
Thanks, JanSpyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/162Job Failed #208263692022-04-04T13:40:29+02:00Christian GutschowJob Failed #20826369Job [#20826369](https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/jobs/20826369) failed for 06fa2b7f0bbd6b1dd30f9dd4e073b3b2206ff634:Job [#20826369](https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/jobs/20826369) failed for 06fa2b7f0bbd6b1dd30f9dd4e073b3b2206ff634: