How do you use a variable defined in [[[environment]]] in the [[[directives]]] section?

Cylc Cylc Support
1

hey,

i want to use a number from a variable in the [[[directives]]] section of a task family which is defined in [[[environment]]] section.

this doesn’t work…

image

and gives this error…

Jinja2Error: 'TOTAL_MPI_TASKS' is undefined
File /scale_wlg_persistent/filesets/home/williamsjh/roses/u-cy821/flow.cylc
              execution time limit = PT6M
          inherit = UMRUN_ENV
          [[[directives]]]
              --ntasks={{TOTAL_MPI_TASKS}}      <-- UndefinedError

i tried removing the { ... } but this then just gives this in the job script!..

#SBATCH --ntasks=TOTAL_MPI_TASKS

any tips?

thanks

2

The problem is, your TOTAL_MPI_TASKS is not defined as a Jinaj2 variable, it’s just a plain Cylc config item. So Jinja2 does not know about it when you try to print it out for the --ntasks bit.

Just as assign it to a Jinja2 variable, and and have Jinja2 print it to the file in both places,e.g.:

{% set NTASKS = 36 }}
...
       --ntasks = {{NTASKS}}
...
       TOTAL_MPI_TASKS = {{NTASKS}}

(Remember Jinja2 is a template processor. All the Jinja2 code in your flow.cylc has to “process out” first thing, to generate the actual valid Cylc workflow configuration. )

1 Like
3

aha got it, thanks! could i also do something like the CORES_PER_NUMA_REGION definition in this? this is from a different task family…

image
image905×182 5.95 KB

4

If I understand your question, yes.

You can use Jinja2 to programmatically generate any text and print it anywhere in the file - so long as the resulting file (with Jinja2 processed out) is valid Cylc syntax.

1 Like
5

Oh, hang on, I just saw that the value of CORES_PER_NUMA_REGION is a shell expression.

This is very different to Jinja2 code. Jinja2 code gets processed at start-up, when the flow.cylc is parsed.

Shell expressions are not processed at all by Cylc. They are printed verbatim to the job file, to be evaluated in the job environment at job run time!

If the final values you need are available at start-up (when flow.cylc is parsed) it’s probably better to use Jinja2, then you don’t have to wait till that particular job runs to find out if you got it wrong because the job environment is not what you thought.

1 Like
6

ok cool, i think i get it! as this workflow progresses (it’s a beta climate LFRic one) there’ll be more stuff in the rose-suite.conf file to prevent having to do this anyway!

all the best,

j

1 Like