As reported by @dmf1998, Lobster doesn't do the right thing if you have multiple workflows in one project that use different CMSSW releases. In order to auto-detect the output or global tags used in the config of each workflow, Lobster attempts to load the pset, but it does it with whichever CMSSW release was used to start Lobster (e.g. where cmsenv was issued) instead of the one that the workflow needs. If the cmsRun config is not compatible with the release used to start Lobster, the auto-detection of global tag or output file fails and Lobster terminates. Fixing this bug is not straightforward, as Lobster would need to interpret each workflows pset in the appropriate release. Workaround is just to specify outputs and global tags explicitly. Because global tags are only needed for publishing, if you don't plan to publish, you can set globaltag = 'dummy' to avoid triggering global-tag auto-detection.
As reported by @dmf1998, Lobster doesn't do the right thing if you have multiple workflows in one project that use different CMSSW releases. In order to auto-detect the output or global tags used in the config of each workflow, Lobster attempts to load the pset, but it does it with whichever CMSSW release was used to start Lobster (e.g. where
cmsenv
was issued) instead of the one that the workflow needs. If thecmsRun
config is not compatible with the release used to start Lobster, the auto-detection of global tag or output file fails and Lobster terminates. Fixing this bug is not straightforward, as Lobster would need to interpret each workflows pset in the appropriate release. Workaround is just to specify outputs and global tags explicitly. Because global tags are only needed for publishing, if you don't plan to publish, you can setglobaltag = 'dummy'
to avoid triggering global-tag auto-detection.