finally migrated to 8.
having at least 2 issues:
how to fix this
The jobs are running as cylc-run/simple/run1/log/job directory is being populated.
OK. glad folks are creatures of habit.
found the global.rc for cylc7.
converted to cylc8 and copied to a location.
export CYLC_CONF_PATH and things are working.
- Client Timeout
Does increasing the timeout using --comms-timeout resolve the issue, or is something else going on?
- cylc tui simple
Note, if you are getting timeout issues with regular commands, it is likely that Tui will struggle to get data out of the workflow.
This command will open the Terminal user interface for a workflow called “simple”. If you haven’t installed a workflow with this name, there won’t be anything to display.
You can omit the workflow ID from this command to view all of your installed workflows, i.e. cylc tui.
When you expand a running workflow, Tui will list the cycles and tasks within it.
o;
the problem was that I didn/t have any global.rc for cylc8. this problem is resolved.
tui is great!
now the ongoing transition from Cylc 7 to Cylc 8 application logic.
in Cylc7 the application uses a method like:
cylc submit -s PROJECT_NAME=$PROJECT_NAME -s CYCLE_POINT=$ENV{CYLC_TASK_CYCLE_POINT} $SUITE_NAME cylc_task_run.$ENV{CYLC_TASK_CYCLE_POINT}
unfortunately,
(cylc8) bash-4.4$ cylc help submit
cylc submit has been removed
we then try:
cylc play -s PROJECT_NAME=“$PROJECT_NAME” -s DTG=“$DTG” -s SPW_FILE=“$SPW_FILE” -s CYCLE_POINT=“$CYLC_TASK_CYCLE_POINT”
-t cylc_ssi_run $SUITE_NAME
(cylc8) bash-4.4$ cylc validate $SUITE_NAME
Jinja2Error: ‘PROJECT_NAME’ is undefined
File wp1020/run4/flow.cylc
#!jinja2
[meta]
title = {{PROJECT_NAME}} ← UndefinedError
validate shows the same.
hints?
Why was “the application” (what is the application - a task in your workflow, or something else?) using cylc submit?
That command was for running single tasks outside of the workflow, i.e. without the scheduler.
We removed it at Cylc 8 because running individual tasks like this still pollutes the workflow run directory, which can potentially cause trouble when you actually come to run the workflow.
The only clear use case for the command was for testing tasks during development without bothering to start the scheduler. In fact you should be able to run task scripts (whatever they are) entirely without Cylc, or just start up the scheduler paused and (safely) trigger individual tasks.
I’m not entirely sure what you’re trying to do there as this bit in particular doesn’t seem to make sense for running a workflow: -s CYCLE_POINT=“$CYLC_TASK_CYCLE_POINT”
(the shell variable $CYLC_TASK_CYCLE_POINT is only defined inside task job scripts).
From a purely technical perspective, if your flow.cylc file contains Jinja2 variables then they must be defined whenever the file gets parsed - that goes for validation as well as for running the workflow - otherwise the template cannot be expanded to generate the raw flow.cylc config for the workflow.
So even for validation, you need to do something this:
$ cylc validate -s PROJECT_NAME=\"$PROJECT_NAME\" <workflow-id>
Note I’ve escaped the quotes to protect them from the shell - the Cylc 8 --set/-s options for Jinja2 variables distinguish string values from other values.
In fact if you don’t quote string values you’ll get a validation error.
$ cylc val . -s PROJECT="foo" # bad - unprotected quotes removed by the shell
InputError: Invalid template variable: foo
(note string values must be quoted)
$ cylc val . -s PROJECT=\"foo\" # good - quotes protected by escaping them
Valid for cylc-8.4.1
$ cylc val . -s 'PROJECT="foo"' # good - quotes protected by outer single quotes
Valid for cylc-8.4.1
$ cylc val . -s PROJECT=\"$PROJECT\" # good - (single quotes prevent env evaluation)
Valid for cylc-8.4.1
If you have many input variables, you might consider storing them in a file in the workflow source directory in Jinja2 format, and using the --set-file option; or even using the cylc-rose plugin that supports a rose-suite.conf file for that purpose.
thank you h;
the key to move along is: (note string values must be quoted);
validation withe quoted strings as suggested:
WARNING - graph items were automatically upgraded in “workflow definition”:
* (8.0.0) [scheduling][dependencies]graph → [scheduling][graph]X - for X in:
R1
Valid for cylc-8.4.1
the ‘play’ now shows:
INFO - Extracting job.sh to /wp1020/run4/.service/etc/job.sh
2025-03-19T13:00:55Z INFO - Workflow: wp1020/run4
with same WARNING as in ‘validate’ and ERROR shutdown:
2025-03-19T13:00:56Z ERROR - Workflow shutting down - PointParsingError: Incompatible value for <class ‘cylc.flow.cycling.iso8601.ISO8601Point’>: cylc_task_run: Invalid ISO 8601 date representation: cylc_task_run
the graph in flow.cylc is:
[[dependencies]]
[[[R1]]]
graph = "cylc_task_run"
while the task is:
[[cylc_task_run]]
script = """
run.pl -p {{PROJECT_NAME}} -d {{DTG}} -w {{SPW_FILE}}
"""
this worked in cylc7.
fwiw; the ‘application’ is a perl script, which in cylc7, submitted to fill a template and run a particular task (cylc_task_run.$ENV{CYLC_TASK_CYCLE_POINT}) in a prior programmatically written ninja2 suite.rc file.
so looks like I have some sleuthing.
thank ya/ll for moving everyone forward.
the WARNING in the validate is fixed with replacing the [[dependencies]] section with:
[[graph]]
R1 = "cylc_task_run"
the ERROR in the ‘play’ is fixed with omitting ‘-t cylc_task_run’: e.g.
cylc play -s PROJECT_NAME="$PROJECT_NAME" -s DTG="$DTG" -s SPW_FILE="$SPW_FILE" -s CYCLE_POINT="$CYLC_TASK_CYCLE_POINT" $SUITE_NAME
things are working behind cylc, e.g. job submitted to batch …