You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The job config scripts generated by this framework currently transfer the local environment to the batch machines, e.g. from send_lhep8.pyhere.
This causes issues with newer key4hep stack versions, which have an internal consistency check and will no longer execute the setup script when the respective environment variable is already set see code here.
First issue arises from unset commands also written to the job scripts from e.g. send_lhep8.pyhere, leaving the library paths missing since sourcing the key4hep stack again afterwards now does nothing.
Another issue is that the submitted jobs will then always use the key4hep release set in init.sh (so the latest), rather than the custom ones specified in the respective config/param (for newer releases, after the implementation of the internal check, in the past this is only worked because no such check was done by key4hep).
Suggested easiest solution would be to not transfer the environment and set up from scratch on the batch node, unless there are usecases where this will not work.
The text was updated successfully, but these errors were encountered:
PR#218 will fix this for FCC-hh productions by not transferring the environment in this case, while the behaviour for FCC-ee productions will be unchanged.
The job config scripts generated by this framework currently transfer the local environment to the batch machines, e.g. from
send_lhep8.py
here.This causes issues with newer
key4hep
stack versions, which have an internal consistency check and will no longer execute the setup script when the respective environment variable is already set see code here.First issue arises from
unset
commands also written to the job scripts from e.g.send_lhep8.py
here, leaving the library paths missing since sourcing the key4hep stack again afterwards now does nothing.Another issue is that the submitted jobs will then always use the
key4hep
release set ininit.sh
(so the latest), rather than the custom ones specified in the respectiveconfig/param
(for newer releases, after the implementation of the internal check, in the past this is only worked because no such check was done bykey4hep
).Suggested easiest solution would be to not transfer the environment and set up from scratch on the batch node, unless there are usecases where this will not work.
The text was updated successfully, but these errors were encountered: