MC Job Options issueshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues2020-01-15T13:14:35+01:00https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/60Fix behaviour of pipelines when [skip ci] is used2020-01-15T13:14:35+01:00Spyros ArgyropoulosFix behaviour of pipelines when [skip ci] is usedApparently there has been a change in the gitlab policy where, if we enforce that pipelines must succeed there must always be a CI job that runs successfully, so we might have to implement something like https://docs.gitlab.com/ee/user/p...Apparently there has been a change in the gitlab policy where, if we enforce that pipelines must succeed there must always be a CI job that runs successfully, so we might have to implement something like https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html (see Limitations).
https://gitlab.cern.ch/help/user/project/merge_requests/merge_when_pipeline_succeeds.md#only-allow-merge-requests-to-be-merged-if-the-pipeline-succeeds
Associated gitlab issues describing the policy change:
https://gitlab.com/gitlab-org/gitlab/issues/14791
https://gitlab.com/gitlab-org/gitlab-foss/issues/66271
Affects !180 see also !184BetaSpyros ArgyropoulosSpyros Argyropoulos2020-01-17https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/76Add dat files in DSID directories in whitelist2020-02-21T10:51:10+01:00Spyros ArgyropoulosAdd dat files in DSID directories in whitelistShould add `*.dat` in whitelistShould add `*.dat` in whitelistS1.2020Spyros ArgyropoulosSpyros Argyropoulos2020-02-15https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/79Recursive extraction of GRID links2020-02-24T10:11:18+01:00Spyros ArgyropoulosRecursive extraction of GRID linksThis is causing the failure in !256.
It seems that the scripts are for some reason not using enough steps to resolve
```
950xxx/950031/mc_13TeV.Sh_228_ttbar_AllHadronic_EnhMaxHTavrgTopPT.GRID.tar.gz -> ../../700xxx/700050/mc_13TeV.Sh_2...This is causing the failure in !256.
It seems that the scripts are for some reason not using enough steps to resolve
```
950xxx/950031/mc_13TeV.Sh_228_ttbar_AllHadronic_EnhMaxHTavrgTopPT.GRID.tar.gz -> ../../700xxx/700050/mc_13TeV.Sh_228_ttbar_AllHadronic_EnhMaxHTavrgTopPT.GRID.tar.gz
```
back to
```
/eos/user/c/cgutscho/mc/700047/mc_13TeV.Sh_228_ttbar_AllHadronic_EnhMaxHTavrgTopPT.GRID.tar.gz
```
By the way @cgutscho @fsiegert isn't this workflow problematic? You have multiple files pointing to `/eos/user/c/cgutscho/mc/700047/mc_13TeV.Sh_228_ttbar_AllHadronic_EnhMaxHTavrgTopPT.GRID.tar.gz`, which has already been transferred to cvmfs, so in principle Chris can decide to remove this file from his eos area and CI again would fail.S1.2020Spyros ArgyropoulosSpyros Argyropoulos2020-02-22https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/78commit script broken2020-02-22T16:06:55+01:00Christian Gutschowcommit script brokenLook like the recent MR !252 broke the commit script, since it's doesn't accept JOs and gridpacks apparently:
```
Checking jO consistency and DSID ranges ...
950xxx/950031/mc.Sh_228_ttbar_dilepton_FusingFragFix_valid.py in correct DSI...Look like the recent MR !252 broke the commit script, since it's doesn't accept JOs and gridpacks apparently:
```
Checking jO consistency and DSID ranges ...
950xxx/950031/mc.Sh_228_ttbar_dilepton_FusingFragFix_valid.py in correct DSID range
New DSID directory: 950xxx/950031 ...
OK: log.generate file found.
OK: log.generate file contains no errors
OK: CI job expected to last less than 1h - time estimate: 0.05 hours
Will now add files to git commit
File: log.generate cannot be added to the commit. Skipping.
File: log.generate.short cannot be added to the commit. Skipping.
File: mc_13TeV.Sh_228_ttbar_AllHadronic_EnhMaxHTavrgTopPT.GRID.tar.gz cannot be added to the commit. Skipping.
File: mc.Sh_228_ttbar_dilepton_FusingFragFix_valid.py cannot be added to the commit. Skipping.
Added: Sherpa_i
```
This was found in !256.S1.2020Spyros ArgyropoulosSpyros Argyropoulos2020-02-22https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/80Improve following of recursive links in eos and run_athena CI jobs2020-03-01T09:26:02+01:00Spyros ArgyropoulosImprove following of recursive links in eos and run_athena CI jobsSuggestion from Frank: use `readlink -f`
Need to see if this is accessible in the CI bash version or perhaps find a bash version where it is (if it's small enough).Suggestion from Frank: use `readlink -f`
Need to see if this is accessible in the CI bash version or perhaps find a bash version where it is (if it's small enough).S1.2020Spyros ArgyropoulosSpyros Argyropoulos2020-03-01https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/91Commit script: block usage of DSIDs that are already used in any remote branch2020-03-16T13:55:42+01:00Spyros ArgyropoulosCommit script: block usage of DSIDs that are already used in any remote branchCurrently the commit script only checks that a DSID is not used in remote branches **only if the DSID is outside the allowed range**.
We should extend this to cover all DSIDs, so that users who try to assign DSIDs themselves do not cr...Currently the commit script only checks that a DSID is not used in remote branches **only if the DSID is outside the allowed range**.
We should extend this to cover all DSIDs, so that users who try to assign DSIDs themselves do not create problems with other MRs.S1.2020Spyros ArgyropoulosSpyros Argyropoulos2020-03-15https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/99Throw error in CI if no `evgenConfig.nEventsPerJob` is used in the file2020-04-08T10:51:29+02:00Spyros ArgyropoulosThrow error in CI if no `evgenConfig.nEventsPerJob` is used in the filePerhaps better to incorporate into #98Perhaps better to incorporate into #98S1.2020Spyros ArgyropoulosSpyros Argyropoulos2020-04-05https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/109logParser fails in CI when run on MadGraph due to nevents check2020-05-17T14:24:09+02:00Spyros ArgyropouloslogParser fails in CI when run on MadGraph due to nevents checkAs seen in !412 when running a jO with:
```
evgenConfig.nEventsPerJob = 10000
nevents = runArgs.maxEvents1.2 if runArgs.maxEvents>0 else 1.1evgenConfig.nEventsPerJob
```
`logParser` fails with
```
ERROR: Increase nevents to be gener...As seen in !412 when running a jO with:
```
evgenConfig.nEventsPerJob = 10000
nevents = runArgs.maxEvents1.2 if runArgs.maxEvents>0 else 1.1evgenConfig.nEventsPerJob
```
`logParser` fails with
```
ERROR: Increase nevents to be generated in MG from 120 to 11000
```S1.2020Spyros ArgyropoulosSpyros Argyropoulos2020-05-16https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/120Allow runArgs to be referred to in JOs but not to be overwritten by JOs2020-08-22T13:08:09+02:00Christian GutschowAllow runArgs to be referred to in JOs but not to be overwritten by JOsSee !631 for an example.See !631 for an example.S2.2020Spyros ArgyropoulosSpyros Argyropoulos2020-08-14https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/122Bug: handling of jobs with external LHE file in logParser step2020-09-06T13:46:23+02:00Spyros ArgyropoulosBug: handling of jobs with external LHE file in logParser stepWhen external LHE files are used `log.generate.short` is added to the commit but `run_athena` just skips the job without producing any `log.generate_ci` file. Then the `check_logParser` job thinks this is a bug because if `log.generate.s...When external LHE files are used `log.generate.short` is added to the commit but `run_athena` just skips the job without producing any `log.generate_ci` file. Then the `check_logParser` job thinks this is a bug because if `log.generate.short` is present `log.generate_ci` should also be present as well at this point in the CI and complains see !652S2.2020Spyros ArgyropoulosSpyros Argyropoulos2020-09-04https://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/166Add checks for python2/3 compatibility of jO2022-04-21T17:21:24+02:00Spyros ArgyropoulosAdd checks for python2/3 compatibility of jOan example DSID is 830099: https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/blob/master/830xxx/830099/mc.H7EG_jetjet_72_Cluster_JZ1.py
R21: 21.6.85
R22: You can try 22.6.13 (later releases have issues with EvtGen_i — should be ...an example DSID is 830099: https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/blob/master/830xxx/830099/mc.H7EG_jetjet_72_Cluster_JZ1.py
R21: 21.6.85
R22: You can try 22.6.13 (later releases have issues with EvtGen_i — should be fixed soon).Spyros ArgyropoulosSpyros Argyropoulos2022-04-25https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/200Failures on grid coming from treatment of runArgs.jobConfig not caught in CI2023-02-02T07:45:25+01:00Spyros ArgyropoulosFailures on grid coming from treatment of runArgs.jobConfig not caught in CIOriginal file: https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/blob/9938e84d065b3b479dd57e063889896daa7ff9e7/521xxx/521163/MadGraphControl_TRSM_HHH.py#L21
Original MR: !2251
Pipeline passed: https://gitlab.cern.ch/atlas-physic...Original file: https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/blob/9938e84d065b3b479dd57e063889896daa7ff9e7/521xxx/521163/MadGraphControl_TRSM_HHH.py#L21
Original MR: !2251
Pipeline passed: https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/pipelines/5008939
https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/blob/9938e84d065b3b479dd57e063889896daa7ff9e7/521xxx/521163/MadGraphControl_TRSM_HHH.py#L21
This then failed on the grid: see ATLMCPROD-10348 example log: https://bigpanda.cern.ch//media/filebrowser/a8f96442-63a3-4574-aee8-53704fce19da/mc15_13TeV/tarball_PandaJob_5732336628_SiGNET/log.generate
Fix in: !2288
New file in: https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/blob/master/521xxx/521163/MadGraphControl_TRSM_HHH.py
Offending line seems to be:
```
f_list = os.listdir(runArgs.jobConfig[0])
```
where `runArgs.jobConfig[0]` on the grid seems to evaluate to `521163` while on the CI it would evaluate to `../521163`. Not clear from which level `Gen_tf.py` runs on the grid.
@mborodin could you point me to the code that executes `Gen_tf.py` on the grid?Spyros ArgyropoulosSpyros Argyropoulos2023-02-05https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/225logParser failed due to missing platform info2024-02-01T14:46:57+01:00Yang LiulogParser failed due to missing platform infoHi @sargyrop , as we discussed in [Fixing automatic determination of release for CI runs (!2861) · Merge requests · atlas-physics / pmg / MC Job Options · GitLab (cern.ch)](https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/merge_re...Hi @sargyrop , as we discussed in [Fixing automatic determination of release for CI runs (!2861) · Merge requests · atlas-physics / pmg / MC Job Options · GitLab (cern.ch)](https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/merge_requests/2861). It seems the added line to extract the platform info will cause problem for some of the jobs.
[Here](https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/pipelines/6821117) is one example.
Many thanks for your time to help.
Cheers
Yanghttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/223Block the usage of xAOD filters in HepMC3 releases2024-01-26T23:10:32+01:00Spyros ArgyropoulosBlock the usage of xAOD filters in HepMC3 releasesSee [this talk](https://indico.cern.ch/event/1372411/contributions/5770199/attachments/2788275/4861850/rel23_Jan2_24.pdf) for a description of the problem.
We want to block all jO that use HepMC3 (all r23.6 for the moment - to be fine t...See [this talk](https://indico.cern.ch/event/1372411/contributions/5770199/attachments/2788275/4861850/rel23_Jan2_24.pdf) for a description of the problem.
We want to block all jO that use HepMC3 (all r23.6 for the moment - to be fine tuned later) that use xAOD filters.Spyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/221CI has to run on AlamLinux9 environment2024-01-31T07:55:48+01:00Yiming AbulaitiCI has to run on AlamLinux9 environmentHi All,
The new release 23.6.20 is available only on the AlamLinux9 environment.
But GIT CI don't support AL9 yet.
So in order to test new JOs with 23.6.20 CI has to run on AL9.
Depends on https://gitlab.cern.ch/atlas/athena/-/merge_re...Hi All,
The new release 23.6.20 is available only on the AlamLinux9 environment.
But GIT CI don't support AL9 yet.
So in order to test new JOs with 23.6.20 CI has to run on AL9.
Depends on https://gitlab.cern.ch/atlas/athena/-/merge_requests/67225Spyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/220Query ProdSys instead of rucio when checking for registered files2023-11-09T15:57:22+01:00Spyros ArgyropoulosQuery ProdSys instead of rucio when checking for registered filesCurrently when `[skip modfiles]` is used `notify.sh` is checking on rucio if samples with a given DSID exist.
When a sample is obsoleted it apparently takes very long for the information to propagate so we should check if we can use Prod...Currently when `[skip modfiles]` is used `notify.sh` is checking on rucio if samples with a given DSID exist.
When a sample is obsoleted it apparently takes very long for the information to propagate so we should check if we can use ProdSys instead.Spyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/2185360 GeV shoudl be an allowed energy in the CI2023-10-20T11:15:28+02:00Jan Kretzschmar5360 GeV shoudl be an allowed energy in the CIhttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/merge_requests/2669
Run 3 HI and reference run energy will be 5360 GeV, so the CI should not fail with
"ERROR: unknown ecmEnergy: 5360.0"
Full log file also on lxplus in ~jkretz/pu...https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/merge_requests/2669
Run 3 HI and reference run energy will be 5360 GeV, so the CI should not fail with
"ERROR: unknown ecmEnergy: 5360.0"
Full log file also on lxplus in ~jkretz/public/log.generateSpyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/212Allow running `mc??_valid` input files2023-07-31T09:40:55+02:00Spyros ArgyropoulosAllow running `mc??_valid` input filesCurrently the CI cannot run on input files named like `mc15_valid.602232.Ph_ttj_MiNNLO_scale5_LHE.evgen.TXT.e8531/TXT.34045098._000002.tar.gz.1`
The `valid` replaces the COM energy so it is potentially a not well defined naming conventi...Currently the CI cannot run on input files named like `mc15_valid.602232.Ph_ttj_MiNNLO_scale5_LHE.evgen.TXT.e8531/TXT.34045098._000002.tar.gz.1`
The `valid` replaces the COM energy so it is potentially a not well defined naming convention, since the COM energy is taken automatically from `ecmEnergy` from `log.generate` which is [directly printed from the transform](https://gitlab.cern.ch/atlas/athena/-/blob/main/Generators/EvgenJobTransforms/share/skel.GENtoEVGEN.py#L105) - from the command line arguments.
One solution is to ignore the `ecmEnergy` completely if we see that the input filed is named as `mc??_valid` however I think that's problematic because an LHE should correspond to a given COM energy and we should not allow it to be used indepndently of the `ecmEnergy`.
@katharin @mgignac @dhirschSpyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/210Make some jo checks stricter?2024-02-18T07:23:36+01:00Spyros ArgyropoulosMake some jo checks stricter?```
runArgs.inputGeneratorFile = outputDS.replace('tar.gz', 'events')
```
passes the check since when running the jO outside the transform it leads to an undefined object.
Maybe we need another way to avoid such issues.```
runArgs.inputGeneratorFile = outputDS.replace('tar.gz', 'events')
```
passes the check since when running the jO outside the transform it leads to an undefined object.
Maybe we need another way to avoid such issues.Spyros ArgyropoulosSpyros Argyropoulos