Trying to build a suite.rc for an ensemble of runs, in the cylc section I have:
[cylc]
[[parameters]]
member = 1…6
[[parameter templates]]
casename = kensemble.%(member)03d
caseroot = /home/jedwards/scratch/kensemble.%(member)03d
and in the runtime section:
[[st_archive]]
script = cd %(caseroot)s; ./case.submit --job case.st_archive; ./xmlchange CONTINUE_RUN=TRUE
but this results in an error because %(caseroot)s is not expanded.
So then I tried:
But this results in a validation error:
ERROR - bad parameter environment template:
[set_external_workflow]MYDIR=%(caseroot)s # bad parameter
Illegal parameter environment template(s) detected
How can I start each member in the correct directory?
I found in the rose tutorial: {CYLC_TASK_PARAM_member}
which is an environment variable with the correct value so I can do:
cd /home/jedwards/scratch/kensemble.(printf “%03d” ${CYLC_TASK_PARAM_member})
but this doesn’t seem to work for [[parameter templates]] only for [[parameters]]
I would also like to expand a variable in the [[directives]] section.
Firstly, for context, the ‘parameter templates’ did not work because script settings have values which are translated to bash logic & parameters cannot be used directly there, only for non-scripting configuration.
Using ‘parameter environment templates’ is the right way to go, but I think the issue here (assuming you have ‘1..6’ in your actual suite definition rather than ‘1…6’ as you have typed here, as that contains an ellipsis unicode character which would invalidate the suite & could propagate down to cause the error you are seeing instead) is that you are setting your parameter environment templates to be equal to the parameter templates. These will be parsed separately, so that the PETs does not know about the PTs.
To add a bit to @sadie.bartholomew’s reply - I think (from your first example, at least) you might have misunderstood the purpose of suite parameters. They are only for parameterizing task names - i.e. to create a whole bunch of tasks from a single template. As such, during suite parsing, parameters are only detected and expanded where task names are expected - not universally. If you want a universal templating system, use Jinja2 (however, if all you want to do is parameterize tasks, then our built-in parameters are cleaner and easier). For convenience, we allow you define (in [parameter templates]) how the templates are expanded - but these should not look like directory paths, as they are expanded in task names. And additionally (also for convenience) the [parameter environment templates] section does let you define environment variables for task jobs by expanding the same parameters (this is the one exception to my point about expansion in task names only) - which is easier than using the automatically defined $CYLC_TASK_PARAM_… variables in your job scripting.
It may be worth playing around with a small example suite, to see exactly how parameters work (but just ask if it still isn’t clear!)
I think that I have it mostly figured out, but I’m still stuck trying to generate unique names for
the batch queueing system:
[[[directives]]]
-N = run.$CASEKEY
doesn’t pick up the environment variable
-N = run.%(member)03d
also doesn’t expand. This turns out to be a pretty important variable when you are running a large ensemble suite and need to know which member is associated with a given batch job.
Actually you never need to set the batch system job name, Cylc automatically sets it for you based on the unique task name (in the PBS case, our pbs.py module automatically sets the -N directive). For parameterized tasks, the task name is includes the expanded parameters - so you should be good to go now!
I’m still having problems with the same issue, the name generated by cylc is too long and is truncated by the PBS qstat command such that you cannot distinguish the ensemble member number. So I am back to trying to figure out how to edit the -N value to pbs.
By the way, all of the links in the forum to cylc documentation seem to be broken (404 not found).
Regarding the docs, both the documentation and the links in the website have been updated recently — there’s some release work in progress for the next Cylc 7 and Cylc 8 versions.
I tested the links now in Documentation | C Y L C and they are working for me. Hopefully they are OK for you too. You may need to update your bookmarks if the URL’s have changed (I normally access via the website, so can’t recall if the URL used to be different).
Ok I see you’re talking about direct links to internal user guide pages, from forum posts.
Apologies for the pain, but those have always been subject to breakage when new Cylc versions are released because we have only ever kept the latest doc version online on the cylc.org website. That’s why I try to remember to say “in the current online docs” when I give direct links.
And right now, we are about to make the first Cylc 8 beta release and an attendant Cylc 7 maintenance release.
We are aware of this problem though, and as we transition to Cylc 8 we are moving to a new automated online documentation build and deployment system that does support multiple versions at once (for the near future).
As an interim measure I probably can restore the most recent previous version though, by Monday…
[UPDATE]: on closer inspection, the example direct link you quoted actually points to the new cylc-doc site, and that link is (now) broken because we are still configuring the site to be ready for Cylc 8.
I have temporarily restored an old symlink to make that URL valid again, but generally the reality is posted URLs that point into the guts of an ever-evolving documentation site will probably have a use-by date (although in future we will keep multiple older versions up for some time, as I said above).
The job name generated by Cylc is <task-name>.<cycle-point>.<suite-name> - which is pretty much the minimum needed to distinguish one job from another in the PBS queues, if you have more than one suite running.
Cylc only uses Job ID, not Job Name, to manage the job (e.g. for job poll or kill) so truncation of job name by qstat won’t be a problem for Cylc. But if you want shorter job names for your own information (manual use of qstat) you have control over task and suite names - is it not sufficient to shorten those, to get around this (apparent) limitation of PBS?