MC Job Options issueshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues2021-04-01T14:20:41+02:00https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/138Check for multiple instances of TestHepMC (and TestLHE?)2021-04-01T14:20:41+02:00Christian GutschowCheck for multiple instances of TestHepMC (and TestLHE?)In general, the transform will create an instance of TestHepMC (and in the future also TestLHE) and run some checks as part of the job. For some setups the default thresholds used in these packages may be too strict and occasionally we g...In general, the transform will create an instance of TestHepMC (and in the future also TestLHE) and run some checks as part of the job. For some setups the default thresholds used in these packages may be too strict and occasionally we get JOs that try to loosen them a bit, which is usually fine.
We recently had a case (!1066) where a fresh instance of TestHepMC was created, and the threshold were tweaked on the new instance but not the one that the transform had already created, which was then causing issues down the line.
Could we catch this sort of thing in the CI? I imagine it would just be a case of checking for a line like
```
genSeq += TestHepMC()
```
and throwing an error?S1.2021Spyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/21Check in logParser that Gen_tf is run?2019-10-26T17:44:02+02:00Spyros ArgyropoulosCheck in logParser that Gen_tf is run?@ewelina @fsiegert @amoroso do we need to check that people run `Gen_tf.py` instead of `Generate_tf.py` in the logParser?
I have run a job and it seems impossible for me to understand from the output which one is use, so if we need to d...@ewelina @fsiegert @amoroso do we need to check that people run `Gen_tf.py` instead of `Generate_tf.py` in the logParser?
I have run a job and it seems impossible for me to understand from the output which one is use, so if we need to do so I suppose we must add a printout statement in `Gen_tf.py` but ewelinA might know how to spot this.
Of course if the pipeline is updated to run `Gen_tf.py` (#16) and the user used `Generate_tf.py` perhaps the job might fail, but then it might be hard to debug what's going on?
* [ ] When 21.6.11 is available check that the logParser catches this correctlyBetaSpyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/197check_jo_consistency failed2022-12-19T16:20:55+01:00Yiming Abulaiticheck_jo_consistency failedHi,
When I commit a second time after fix something in Control file, the consistency check failed.
The consistency is checking some other files that is not a part of my commits (I am trying to register 518405-518446 range).
But job is fa...Hi,
When I commit a second time after fix something in Control file, the consistency check failed.
The consistency is checking some other files that is not a part of my commits (I am trying to register 518405-518446 range).
But job is failed due to some errors related to 421xxx/421100/..
So How can I fix this?
Cheers,
Ablet
Error part:
OK: No generator full name is found
Generators used: ['Py8', 'EG']
ERROR: file /builds/atlas-physics/pmg/mcjoboptions/scripts/../421xxx/421100/mc.Py8EG_A14NNPDF23LO_Ztautau.py contains includes pointing to MC15JobOptions
Failed Job
https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/jobs/26543765Spyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/117Check number of files in gridpack2023-03-01T07:42:53+01:00Christian GutschowCheck number of files in gridpackThe number of files in a gridpack shouldn't exceed 80k, otherwise some grid sites will crash. This has happened a number of times recently, e.g. for the FxFx job where the gridpack contained several files per Feynman diagram. MadGraph co...The number of files in a gridpack shouldn't exceed 80k, otherwise some grid sites will crash. This has happened a number of times recently, e.g. for the FxFx job where the gridpack contained several files per Feynman diagram. MadGraph control cleans up logs and .o files in the latest release, but for older releases it would be good to have a dedicated pipeline step that throws an error if the number of files in the gridpack is larger than 80k. Probably something like `tar -ztvf *.tgz *.tar.gz` could work?S2.2020Spyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/69Checks for madgraph mode and integration time2022-02-18T15:51:06+01:00Spyros ArgyropoulosChecks for madgraph mode and integration time* if multicore mode then throw ERROR and print that they should use single core
* if integration time very long then ERROR and print that they should create a gridpack
https://prodtask-dev.cern.ch/prodtask/inputlist_with_request/26924...* if multicore mode then throw ERROR and print that they should use single core
* if integration time very long then ERROR and print that they should create a gridpack
https://prodtask-dev.cern.ch/prodtask/inputlist_with_request/26924/
https://its.cern.ch/jira/browse/ATLMCPROD-7731FutureHannes MildnerHannes Mildnerhttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/43Checks for madgraph mode and integration time2020-01-30T10:36:50+01:00Spyros ArgyropoulosChecks for madgraph mode and integration timeSee https://gitlab.cern.ch/atlas-physics/pmg/tools/logParser/issues/7See https://gitlab.cern.ch/atlas-physics/pmg/tools/logParser/issues/7S1.2020Spyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/86Check that external files are world-readable2020-03-12T17:18:40+01:00Christian GutschowCheck that external files are world-readableCan we implement a check that sym-linked files are world-readable with something like
```
"$(find "$filename" -perm -004)"
```
in case the cvmfs sync script cannot easily be patched? Not clear to me whether this is better done in the C...Can we implement a check that sym-linked files are world-readable with something like
```
"$(find "$filename" -perm -004)"
```
in case the cvmfs sync script cannot easily be patched? Not clear to me whether this is better done in the CI or as part of the commit script. If the latter is possible, perhaps that would be a good point to flag this up, but if people sneakily try to bypass the commit script, perhaps we should also check it in the CI?S1.2020Spyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/141check_unique_controlFile.sh fails when it shouldn't?2021-05-13T09:00:06+02:00Jeff Shahiniancheck_unique_controlFile.sh fails when it shouldn't?[check_unique_controlFile.sh](https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/blob/master/scripts/check_unique_controlFile.sh) is apparently a new part of the CI. I noticed that it fails even when given symlinks. For example, whe...[check_unique_controlFile.sh](https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/blob/master/scripts/check_unique_controlFile.sh) is apparently a new part of the CI. I noticed that it fails even when given symlinks. For example, when uploading JOs (with symlinks to one control file) that look like this:
```
$ ls -a *
100001:
myJO_1.py
myControlFile.py
100002:
myJO_2.py
myControlFile.py -> ../100001/myControlFile.py
```
The CI job fails and recommends that you use symlinks (even if you already are):
```
ERROR: Duplicate file(s) found:
./100xxx/100001/myControlFile.py
If the files have exactly the same content, please only keep one physical file replacing the rest with symbolic links.
If the files have differences consider renaming the files that you added.
You can check for differences with diff -w file1 file2
```
Perhaps we need to add ```-type f``` to [this line](https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/blob/master/scripts/check_unique_controlFile.sh#L23) as well?
Here's an example of a failing CI job:
https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/jobs/13818890
Tagging @sargyrop
Best,
JeffS1.2021Spyros 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/93CI addition to JO name check: no minus signs allowed2020-03-26T11:10:45+01:00Christian GutschowCI addition to JO name check: no minus signs allowedIt looks like the production system doesn't allow "-" in the JO name, can we get the CI to check this?It looks like the production system doesn't allow "-" in the JO name, can we get the CI to check this?S1.2020Spyros 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/28CI checks that evgenConfig.inputFilesPerJob is not too high for a grid node2019-09-14T20:35:15+02:00Spyros ArgyropoulosCI checks that evgenConfig.inputFilesPerJob is not too high for a grid nodeLimit: 100 -- but doen't that have to be different for LHE vs. EVNT input due to their file size and possibly different minevents? How to best take that into account, Misha and Dominic? Remember that we don't have access to the input dat...Limit: 100 -- but doen't that have to be different for LHE vs. EVNT input due to their file size and possibly different minevents? How to best take that into account, Misha and Dominic? Remember that we don't have access to the input dataset in the CI. Maybe for a start we use the limit of 100, which should be fine for LHE based requests. And for EVNT based requests we at least won't need more, so there are no false rejections from the CI.Spyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/56CI: check that mcgensvc has access to eos directories2019-12-17T18:43:15+01:00Spyros ArgyropoulosCI: check that mcgensvc has access to eos directoriesCurrently in `check_grid_file_atlcvmfs.sh` we are only checking if `atlcvmfs` has access.
We also need to check if `mcgensvc` has access, since we are using the `mcgensvc` credentials when copying `GRID` files in `run_athena.sh`, so if...Currently in `check_grid_file_atlcvmfs.sh` we are only checking if `atlcvmfs` has access.
We also need to check if `mcgensvc` has access, since we are using the `mcgensvc` credentials when copying `GRID` files in `run_athena.sh`, so if `mcgensvc` does not have access to the eos directory the job will fail.
* [x] Add check for mcgensvc in script
* [x] Add tags:cvmvfs to the check_grid_* jobsBetaSpyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/54CI: compare with origin/master instead of HEAD2019-12-21T15:10:24+01:00Spyros ArgyropoulosCI: compare with origin/master instead of HEADCurrently in many jobs we are comparing with `HEAD` instead of `origin/master` which is the target branch. In most cases this will need to change.
Actually we should do
`git diff origin/master...HEAD`
Currently in many jobs we are comparing with `HEAD` instead of `origin/master` which is the target branch. In most cases this will need to change.
Actually we should do
`git diff origin/master...HEAD`
BetaSpyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/20CI: diff filters checking HEAD instead of master2019-11-11T20:31:33+01:00Spyros ArgyropoulosCI: diff filters checking HEAD instead of masterThe git diff checks the HEAD instead of the master branch. This leads to unexpected failures as described in !13 (same thing happening in !49)
We also need a way to handle the fact that `only:changes` seems to work relevant to the branc...The git diff checks the HEAD instead of the master branch. This leads to unexpected failures as described in !13 (same thing happening in !49)
We also need a way to handle the fact that `only:changes` seems to work relevant to the branch from which a CI job is triggered. Apparently if a user makes multiple commits that will not change files for which a pipeline has previously failed, the corresponding jobs will not run at the final commit and we end up having a successful pipeline just because some jobs were omitted. This seems to have happened in !49BetaSpyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/171CI download to check for grid input LHEs with mc21_13p6TeV scope2022-05-10T07:28:54+02:00Jan KretzschmarCI download to check for grid input LHEs with mc21_13p6TeV scopeIn https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/merge_requests/1824 I hit the problem, that Grid input LHEs are always trying to be downloaded with mc15_13TeV or mc16_13TeV scope, I think the origin of this is here:
https://gi...In https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/merge_requests/1824 I hit the problem, that Grid input LHEs are always trying to be downloaded with mc15_13TeV or mc16_13TeV scope, I think the origin of this is here:
https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/blob/master/scripts/run_athena.sh#L115-138
First, it would probably be preferable, if we get the CME string from the CME value rather than fixing it to 13 TeV.
Second, we now also need to allow mc21
As shortest patch we could just keep extending the list of allowed scopes, here mc21_13p6TeV being the obvious one to add immediately.
Many thanks, Janhttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/1CI feature: check physics short for uniqueness2022-10-26T19:43:46+02:00Spyros ArgyropoulosCI feature: check physics short for uniqueness* [x] Check whether a file with the same physics short exists
* [x] Do we also need to check for similar filenames? The we should define what similar means => NO
* [x] Modify `check_physicsShort` to account for DSID
Currently there a...* [x] Check whether a file with the same physics short exists
* [x] Do we also need to check for similar filenames? The we should define what similar means => NO
* [x] Modify `check_physicsShort` to account for DSID
Currently there are no DSIDs in the example jO here.
https://its.cern.ch/jira/browse/ATLMCPROD-7100Spyros 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/72CI: how to check for modification of files2020-02-04T11:55:18+01:00Spyros ArgyropoulosCI: how to check for modification of filesShould we restrict `check_modified_file.sh` to only look for changes in `common` and DSID directories?
## Pros
* easier to use for developers (they don't have to commit with `[skip modfiles]`)
## Cons
* More unsafe (e.g. commit of jO...Should we restrict `check_modified_file.sh` to only look for changes in `common` and DSID directories?
## Pros
* easier to use for developers (they don't have to commit with `[skip modfiles]`)
## Cons
* More unsafe (e.g. commit of jO with high priority comes in with checks in scripts that have been commented out due to failures, gets merged in master and as a result the checks are disabled for everyone)S1.2020Spyros ArgyropoulosSpyros Argyropouloshttps://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/issues/169CI job to check if EVNTs have been obsoleted to run for modified jO2022-11-16T14:32:57+01:00Spyros ArgyropoulosCI job to check if EVNTs have been obsoleted to run for modified jO- if a jO is modified
- check if EVNT containers exist & have > 0 associated files, if so throw an error
e.g. https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/merge_requests/1795- if a jO is modified
- check if EVNT containers exist & have > 0 associated files, if so throw an error
e.g. https://gitlab.cern.ch/atlas-physics/pmg/mcjoboptions/-/merge_requests/1795Spyros ArgyropoulosSpyros Argyropoulos