cmsDriver feature request for WMCore

[khurtado]

We have the following issue:

dmwm/WMCore#10604

where we basically need to figure out what the physics type is from a pset. We basically support the following types for monitoring:

physics task types: ["GENSIM", "GEN", "DIGI", "RECO", "DIGIRECO", "MINIAOD"]

However, we have to guess this base on the campaign name and we have been told the cmsDriver --steps argument should help better to guess the physics type better. We think the ideal solution would be to have the physics type already as part of a commented out lien in the pset

E.g.: For this file
https://cmsweb.cern.ch/couchdb/reqmgr_config_cache/b5800d7a387fa74d27c957e2ddbd4853/configFile

to have an extra comment line at the end e.g.:

# Auto generated configuration file
# using: 
# Revision: 1.19 
# Source: /local/reps/CMSSW/CMSSW/Configuration/Applications/python/ConfigBuilder.py,v 
# with command line options: --python_filename PPS-Run3Winter22SIM-00018_1_cfg.py --eventcontent RAWSIM --customise Configuration/DataProcessing/Utils.addMonitoring --datatier GEN-SIM --fileout file:PPS-Run3Winter22SIM-00018.root --conditions 122X_mcRun3_2021_realistic_v9 --beamspot Run3RoundOptics25ns13TeVLowSigmaZ --step SIM --geometry DB:Extended --filein file:PPS-Run3Winter22pLHEGEN-00004.root --era Run3 --no_exec --mc -n 1511
import FWCore.ParameterSet.Config as cms
# physics_type = "GENSIM"

Would this be feasible?
This would allow us not to have to guess the physics type based on patterns from the campaign names (MCM patterns) or the --step argument in cmsDriver (since there is potential for this to have mistakes or get obsolete throughout the years).

Tagging @amaltaro

[cmsbuild]

A new Issue was created by @khurtado Kenyi Hurtado.

@Dr15Jones, @perrotta, @dpiparo, @rappoccio, @makortel, @smuzaffar can you please review it and eventually sign/assign? Thanks.

cms-bot commands are listed here

[makortel]

assign operations

[cmsbuild]

New categories assigned: operations

@fabiocos,@perrotta,@davidlange6,@rappoccio you have been requested to review this Pull request/Issue and eventually sign? Thanks

[makortel]

Let me tag @cms-sw/pdmv-l2 too as the question seems to be related how the workflows are defined

[amaltaro]

Thank you for creating this ticket, Kenyi.

I think it's important to mention that this list:

physics task types: ["GENSIM", "GEN", "DIGI", "RECO", "DIGIRECO", "MINIAOD"]

can actually be expanded/revisited to property categorize jobs executed in the grid.

[davidlange6]

Is it obvious that parsing cmsdriver outputs is the right solution? Eg, was adding a field to the JSON passed to request manager considered? In that way a once per campaign choice of task type could be used to populate this info. On Aug 2, 2023 11:52 AM, Alan Malta Rodrigues ***@***.***> wrote: Thank you for creating this ticket, Kenyi. I think it's important to mention that this list: physics task types: ["GENSIM", "GEN", "DIGI", "RECO", "DIGIRECO", "MINIAOD"] can actually be expanded/revisited to property categorize jobs executed in the grid. — Reply to this email directly, view it on GitHub<#42450 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABGPFQ57MSD4XJPRX24IKWTXTKHU3ANCNFSM6AAAAAA3BPRTZA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[kpedro88]

Where does this list of "physics task types" come from? I do not recall seeing such a list in CMSSW itself.

[amaltaro]

Is it obvious that parsing cmsdriver outputs is the right solution?

From the WM perspective, the ideal solution would indeed be to have it provided to the workflow high level description (JSON in ReqMgr2). However, this would require changes at the submitter side (McM, at least) in addition to having this feature only available in newer CMSSW releases, so potentially taking a couple of years to cover most of the central production workflows.

Loading and parsing the pickle file has its own extra cost, but we see it as a good intermediate step. So the fallback mechanism could be parsing the --steps of the cmsDriver command.

Where does this list of "physics task types" come from? I do not recall seeing such a list in CMSSW itself.

That is a good question! It might have been defined many years ago when we started running Condor Job Monitoring, likely involving many people to get the most meaningful payload characterization. If we deploy this in cmsDriver, then it's definitely a good moment to review it.

[kpedro88]

If the list of physics task types isn't defined in CMSSW, then why should it be incorporated into cmsRun configurations? Does the physics task type affect the job output at all? If not, it seems like CMSSW is not the right place to propagate this information.

[amaltaro]

The physics task type (and this naming can be modified as well) is actually what is executed by a cmsRun process loading a given PSet configuration. Given that the PSet configuration is created in CMSSW - by executing a cmsDriver command - to me it is natural that THAT is the source of this information, hence the best place to provide this information.

I just wanted to emphasize that we do not need - I think - to stick with the list provided above. However, we do want to characterize what each job is actually running in the grid computing. For instance, we know that DIGI can be I/O demanding (classic pileup), different than GEN only, etc. I believe we have much to learn from this, once it is all available in monitoring.

[kpedro88]

What you describe sounds like metadata to me. cmsRun seems to work perfectly fine without knowing about this information at all. Either it is the same as the contents of --step so no new info is needed, or it depends on external context and therefore should be tracked in McM or some other PdmV or WM tool.