# \[runtime\]\[\\]\[job\]batch system equivalent in cylc 8.3.4 **URL:** \ **Category:** Cylc Support\ **Created:** [November 6, 2024, 7:39pm UTC](https://cylc.discourse.group/t/runtime-task-name-job-batch-system-equivalent-in-cylc-8-3-4/1056 "2024-11-06T19:39:03Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![jtsu](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/jtsu/32/517_2.png) [@jtsu](https://cylc.discourse.group/u/jtsu)\ **Post date:** [November 6, 2024, 7:39pm UTC](https://cylc.discourse.group/t/runtime-task-name-job-batch-system-equivalent-in-cylc-8-3-4/1056/1 "2024-11-06T19:39:03Z")
Hello, I am trying to rewrite some old Cylc v7 suite.rc files into v8.3.4 format and I am having trouble understanding how to define platforms and job runners. In Cylc7, I had the following in a inc/platform.rc file that would then be included in the suite.rc and inherited by certain tasks to define if that task should run in the background vs the node: ```auto [runtime] [[BG_TASK]] [[[job]]] batch system = background ``` I went through the 8.x tutorial and see that `[[[job]]]` is gone now and has been replaced with the (I think) [platforms] utility in $HOME/.cylc/flow/8.3.4/global.cylc. So I wrote the following in my global.cylc file: ```auto [platforms] [[BG_TASK]] job runner = background ``` then in my flow.cylc file I have: ```auto [runtime] [[BACKGROUND_QUEUE]] init-script = "set -x" platform = BG_TASK ``` which can then be inherited by tasks that I want to run in the background. The jobs won’t submit. The only output I get from running the workflow is a job-activity.log file that says: ```auto [jobs-submit cmd] (init BG_TASK) [jobs-submit ret_code] 1 [jobs-submit err] REMOTE INIT FAILED [jobs-submit cmd] (remote init) [jobs-submit ret_code] 1 ``` My understanding was that you define custom named platforms in your global.cylc file which can then be referenced in your flow.cylc file using [runtime][]platform. Where did I go wrong here? ---
**Author:** ![hilary.j.oliver](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/hilary.j.oliver/32/4_2.png) [@hilary.j.oliver](https://cylc.discourse.group/u/hilary.j.oliver)\ **Post date:** [November 6, 2024, 9:43pm UTC](https://cylc.discourse.group/t/runtime-task-name-job-batch-system-equivalent-in-cylc-8-3-4/1056/2 "2024-11-06T21:43:11Z")
> [@jtsu](#): > > My understanding was that you define custom named platforms in your global.cylc file which can then be referenced in your flow.cylc file using [runtime]platform. That’s right. At a site with many Cylc users you’d expect platforms to be defined centrally, but if not you can do it in your user `global.cylc` file. > [@jtsu](#): > > The only output I get from running the workflow is a job-activity.log file that says: You’ll get more information from the scheduler log. Run your workflow again with `--no-detach` or use `cylc cat-log ` (or look in `~/cylc-run//log/scheduler/log`): ![image](https://global.discourse-cdn.com/free1/uploads/cylc1/original/1X/7dbca04880671834fdd100a7d041c6491ac4b657.png) So: Cylc could not connect to your platform because _“Unable to find valid host for BG\_TASK”_. You did not list any hosts in your platform definition, so Cylc tried the default (host-name = platform-name), which didn’t work. Take a look at the platforms documentation here: [Platform Configuration — Cylc 8.4.2 documentation](https://cylc.github.io/cylc-doc/stable/html/reference/config/writing-platform-configs.html#adminguide-platformconfigs) You need to define a list of hosts and an install target, as well as job runner. The minimal platform definition for local background jobs (which, by the way, is the default if you don’t specify a platform at all): ```ini # global.cylc [platforms] [[BG_TASK]] job runner = background hosts = localhost install target = localhost ``` ---
**Author:** ![jtsu](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/jtsu/32/517_2.png) [@jtsu](https://cylc.discourse.group/u/jtsu)\ **Post date:** [November 6, 2024, 11:00pm UTC](https://cylc.discourse.group/t/runtime-task-name-job-batch-system-equivalent-in-cylc-8-3-4/1056/3 "2024-11-06T23:00:42Z")
thanks for the response, that makes sense and thank you for linking the documentation associated with platform configuration. I am trying to think how to adapt this methodology to one of our suites where we include a multitude of platform files (i.e. HPC1\_include.rc, HPC2\_include.rc, HP3\_include.rc) that the user has to choose from based on what machine the user is running on. Each of these files will have a different version of, say, job runner (i.e. pbs vs slurm). Now that the definition of these platforms is delegated to the global.cylc file, it seems like the user would have to know to correctly change the specifications of their platforms in their global.cylc file prior to using our version controlled Cylc workflow. A workaround might be to use $CYLC\_SITE\_CONF\_PATH and hardwire that in flow.cylc[runtime][root] to be $CYLC\_WORKFLOW\_RUN\_DIR/etc. In $CYLC\_WORKFLOW\_RUN\_DIR/etc, I would have something like HPC1.cylc, HPC2.cylc, etc. and prior to installing the workflow, the user must symlink global.cylc to one of these files. Am I over thinking this? ---
**Author:** ![hilary.j.oliver](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/hilary.j.oliver/32/4_2.png) [@hilary.j.oliver](https://cylc.discourse.group/u/hilary.j.oliver)\ **Post date:** [November 6, 2024, 11:23pm UTC](https://cylc.discourse.group/t/runtime-task-name-job-batch-system-equivalent-in-cylc-8-3-4/1056/4 "2024-11-06T23:23:16Z")
You should not need to use CYLC\_SITE\_CONF\_PATH for this. You can define all the platforms in the same global.cylc, and just select the right ones as needed in workflow task definitions. Platform definitions can overlap - e.g. you could define a platform to run background jobs on one particular host of several that also appear in a platform with PBS as a job runner (note that platform hosts are where Cylc interacts with the job runner, not the compute notes managed by the job runner itself). I think you could keep the same set of `flow.cylc` include files, but just change their content to set the right platform name for the task family. ---
**Author:** ![jtsu](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/jtsu/32/517_2.png) [@jtsu](https://cylc.discourse.group/u/jtsu)\ **Post date:** [November 6, 2024, 11:41pm UTC](https://cylc.discourse.group/t/runtime-task-name-job-batch-system-equivalent-in-cylc-8-3-4/1056/5 "2024-11-06T23:41:38Z")
Is there anyway to do this without a global.cylc? I’d prefer everything needed to run the workflow to be self contained in one git clone checkout without the need for the user to go into their $HOME/.cylc/flow and change/create a file. ---
**Author:** ![hilary.j.oliver](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/hilary.j.oliver/32/4_2.png) [@hilary.j.oliver](https://cylc.discourse.group/u/hilary.j.oliver)\ **Post date:** [November 7, 2024, 12:14am UTC](https://cylc.discourse.group/t/runtime-task-name-job-batch-system-equivalent-in-cylc-8-3-4/1056/6 "2024-11-07T00:14:19Z")
No, we don’t support platform definitions inside a workflow configuration, because platforms are inherently not workflow-specific. Ideally, normal users shouldn’t even need to understand how to define platforms, they should just choose from the centrally-defined ones. If that has not been done (i.e., no central definitions), you can define your own platforms, but the principle is the same - all of your workflows should select from the same platforms, no need to redefine them in every workflow. Is it not feasible to have a central `global.cylc` for all users on your workflow scheduler host(s)? Note there’s likely to be other global config needed too, not just platforms. ---
**Author:** ![jtsu](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/jtsu/32/517_2.png) [@jtsu](https://cylc.discourse.group/u/jtsu)\ **Post date:** [November 7, 2024, 1:08am UTC](https://cylc.discourse.group/t/runtime-task-name-job-batch-system-equivalent-in-cylc-8-3-4/1056/7 "2024-11-07T01:08:14Z")
> [@hilary.j.oliver](#): > > Ideally, normal users shouldn’t even need to understand how to define platforms, they should just choose from the centrally-defined ones. Okay that makes sense. It seems like we will have to figure out a way to create a centrally-defined global.cylc for each of our HPC systems that all users can reference via the \*\_include.rc files included in the workflow checkout > [@hilary.j.oliver](#): > > Is it not feasible to have a central `global.cylc` for all users on your workflow scheduler host(s)? Our lab hasn’t made the full transition to using Cylc8 so there isn’t much of an infrastructure yet. There is no central global.cylc yet, but this seems like the direction our development should move in as we progress in this transition ---
**Author:** ![hilary.j.oliver](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/hilary.j.oliver/32/4_2.png) [@hilary.j.oliver](https://cylc.discourse.group/u/hilary.j.oliver)\ **Post date:** [November 7, 2024, 1:12am UTC](https://cylc.discourse.group/t/runtime-task-name-job-batch-system-equivalent-in-cylc-8-3-4/1056/8 "2024-11-07T01:12:25Z")
> [@jtsu](#): > > There is no central global.cylc yet, but this seems like the direction our development should move in Agreed! > [@jtsu](#): > > It seems like we will have to figure out a way to create a centrally-defined global.cylc for each of our HPC systems Note you only need a `global.cylc` on Cylc scheduler hosts, not on job platforms. Typically we have a small pool of scheduler hosts, but they’re all on the same shared filesystem, so that’s only one global config file. ---
**Author:** ![wxtim](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/wxtim/32/151_2.png) [@wxtim](https://cylc.discourse.group/u/wxtim)\ **Post date:** [November 7, 2024, 7:16am UTC](https://cylc.discourse.group/t/runtime-task-name-job-batch-system-equivalent-in-cylc-8-3-4/1056/9 "2024-11-07T07:16:21Z")
Slight aside (handy if you are upgrading from Cylc 7) - If you have the platform setup correct and you run a workflow in compatibility mode (i.e. use Cylc8 on a workflow defined in a `suite.rc`) Cylc will select a platform from the old settings if one can be found which matches. Locally we recommend the following steps when upgrading Cylc7 → Cylc8 ([see also docs on upgrading](https://cylc.github.io/cylc-doc/stable/html/7-to-8/summary.html#upgrading-to-cylc-8)): 1. Use Cylc 7 `cylc validate` to ensure that there are no upgrade warnings relating to Cylc 6 ⇒ 7 upgrades. If there are, fix them. 2. Use Cylc 8 `cylc validate` to fix anything compatibility mode cannot handle. 3. Try installing and running (`cylc vip`) the workflow (this is compatibility mode) and check that it works. 4. Move `suite.rc` ⇒ `flow.cylc`. 5. Re-run `cylc validate` and `cylc lint --ruleset 728`, and fix any further warnings. 6. Try running the workflow. ---
**Author:** ![jtsu](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/jtsu/32/517_2.png) [@jtsu](https://cylc.discourse.group/u/jtsu)\ **Post date:** [November 8, 2024, 12:55am UTC](https://cylc.discourse.group/t/runtime-task-name-job-batch-system-equivalent-in-cylc-8-3-4/1056/10 "2024-11-08T00:55:43Z")
> [@hilary.j.oliver](#): > > Note you only need a `global.cylc` on Cylc scheduler hosts, not on job platforms. Can you clarify the difference between scheduler hosts and job platforms? Is the scheduler host for BG\_TASK (as defined above in the previously discussed global.cylc) the localhost and is the job platform equivalent to the job runner (i.e. ‘background’)? > [@wxtim](#): > > Locally we recommend the following steps when upgrading Cylc7 → Cylc8 Thanks for the steps. I’ll probably use these when updating my big suite to a flow! ---
**Author:** ![hilary.j.oliver](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/hilary.j.oliver/32/4_2.png) [@hilary.j.oliver](https://cylc.discourse.group/u/hilary.j.oliver)\ **Post date:** [November 8, 2024, 7:53am UTC](https://cylc.discourse.group/t/runtime-task-name-job-batch-system-equivalent-in-cylc-8-3-4/1056/11 "2024-11-08T07:53:15Z")
> [@jtsu](#): > > Can you clarify the difference between scheduler hosts and job platforms? The _scheduler host_ is the server or VM where your Cylc scheduler runs, to manage your workflow. _Job platforms_ are where the scheduler submits jobs to run. The scheduler host - usually called _localhost_ (because most things in Cylc are relative to the scheduler) - is often also a job platform (in fact it is the default job platform, if you don’t specify one) if you need to run task jobs locally on the scheduler host. The `global.cylc` file configures how Cylc schedulers behave, including telling them what job platforms are available to submit jobs to - so it has to be readable by the scheduler on the scheduler host. You don’t need a `global.cylc` file on the job platforms (if you run local jobs on scheduler host the `global.cylc` file will of course happen to be there - but it’s not used by the jobs). > [@jtsu](#): > > Is the scheduler host for BG\_TASK (as defined above in the previously discussed global.cylc) the localhost and is the job platform equivalent to the job runner (i.e. ‘background’)? That doesn’t quite make sense. - `BG_TASK` is a job platform. A job platform does not “have” a scheduler host - that’s not a property of job platforms. A job platform is just where a scheduler, running on a scheduler host, can submit jobs. - the job platform is not equivalent to the job runner, but a job platform _has_ a job runner. E.g. on platform “HPC1” (say) you might have Slurm as a job runner. The “background” job runner is just how we tell Cylc to run jobs “in the background” - i.e. as a direct subprocess - rather than submitting them to a proper resource manage like Slurm or PBS. ---
**Author:** ![jtsu](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/jtsu/32/517_2.png) [@jtsu](https://cylc.discourse.group/u/jtsu)\ **Post date:** [November 13, 2024, 10:47pm UTC](https://cylc.discourse.group/t/runtime-task-name-job-batch-system-equivalent-in-cylc-8-3-4/1056/12 "2024-11-13T22:47:35Z")
Okay, it is becoming a bit more clear. Let me see if I understand. The scheduler host is essentially the machine that Cylc scheduler will run on and this is, by default, localhost. If the need arises, is this default changed in global.cylc[scheduler][run hosts]available? Is the scheduler host also where the Localhost is also a default defined job platform, but you can add in custom job platforms in global.cylc with different job submission settings (i.e. job runner). The global.cylc needs to be on localhost because the scheduler host will look for it there (unless otherwise specified, by what i am guessing is global.cylc[scheduler][run hosts]available). I have always had the global.cylc - or the global.rc in Cylc7 - on my login node without understanding why but this clears that up) Couple more questions regarding the global.cylc[platforms]: - When you said “the scheduler host… is often also a job platform”, are you referring to global.cylc[platforms]hosts? - In an example on how I run the suite, if I am running Cylc on the login node of an HPC and I want the suite to run by submitting via pbs to be run on the compute nodes, what would be my scheduler host and my job platform? - Is global.cylc[platforms]install target used by Cylc to define where the job.err/.out files will go? Are those files what the documentation refers to as “remote file installation”? > [@hilary.j.oliver](#): > > Ideally, normal users shouldn’t even need to understand how to define platforms, they should just choose from the centrally-defined ones. > > If that has not been done (i.e., no central definitions), you can define your own platforms, but the principle is the same - all of your workflows should select from the same platforms, no need to redefine them in every workflow. Is there a way I can check to see if there are central definition of job platforms? ---
**Author:** ![hilary.j.oliver](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/hilary.j.oliver/32/4_2.png) [@hilary.j.oliver](https://cylc.discourse.group/u/hilary.j.oliver)\ **Post date:** [November 13, 2024, 11:40pm UTC](https://cylc.discourse.group/t/runtime-task-name-job-batch-system-equivalent-in-cylc-8-3-4/1056/13 "2024-11-13T23:40:33Z")
> [@jtsu](#): > > The scheduler host is essentially the machine that Cylc scheduler will run on and this is, by default, localhost Yes. Also known as the “scheduler run host”, as per the global config “run hosts” settings. It is “by default, localhost” in the sense that if you run `cylc play` on the command line, it will by default start the scheduler locally. If a pool of “run hosts” are configured, it will start the scheduler on one of those instead. The name “localhost” is also used in some configuration settings to refer to the host that the scheduler is running on (because those settings configure the scheduler program, and the host it is running on is “localhost” as far as it is concerned). > [@jtsu](#): > > Localhost is also a default defined job platform, but you can add in custom job platforms in global.cylc with different job submission settings (i.e. job runner). Yes. > [@jtsu](#): > > The global.cylc needs to be on localhost because the scheduler host will look for it there (unless otherwise specified, by what i am guessing is global.cylc[scheduler][run hosts]available). Yes-ish. More specifically, the `global.cylc` file has to be on a filesystem that is visible from the scheduler run host. If you have a pool of run hosts, they all have to be on the same shared filesystem, so there’s still only one central `global.cylc` file. > [@jtsu](#): > > When you said “the scheduler host… is often also a job platform”, are you referring to global.cylc[platforms]hosts? Well, you can put explicit platform settings for localhost in `global.cylc` if you like, but note those settings have to be valid for all scheduler run hosts (again, these settings are interpreted by schedulers, so “localhost” refers to the scheduler host). However, my point there was really that we do often run jobs, as well as schedulers, on scheduler hosts. A single user installation on a laptop, for instance, likely runs everything on the same host (the laptop) and probably runs all jobs as simple background jobs (no PBS or Slurm). Even on an HPC cluster, the default if you do not specify a platform in a task definition is to run the job as a local background job - and that does not require any global.cylc “localhost” platform settings. > [@jtsu](#): > > In an example on how I run the suite, if I am running Cylc on the login node of an HPC and I want the suite to run by submitting via pbs to be run on the compute nodes, what would be my scheduler host and my job platform? The scheduler host (and therefore “localhost” in Cylc configs, is the login node. And you should define, in `global.cylc`, a job platform that specifies (a) pbs as the job runner; (b) localhost as the `install target`; and (c) `hosts = localhost`. The platform definition does not need to list compute nodes as hosts. It just lists the host(s) that Cylc can use to interact with the job runner - to submit, poll (query), or kill jobs. If your system has multiple login nodes from which you can interact with PBS, and other “interactive nodes” you can use for e.g. manual postprocessing work, it would probably be better to run the Cylc scheduler there (on an interactive node) and define a job platform that lists the multiple login nodes as hosts - that’s more robust as Cylc can continue to run and manage jobs even if one of the login nodes goes down. > [@jtsu](#): > > Is global.cylc[platforms]install target used by Cylc to define where the job.err/.out files will go? Are those files what the documentation refers to as “remote file installation”? No, an install target represents a filesystem, and is used to install workflow source files on job platforms. A platform may have multiple hosts, and multiple platforms might be on the same filesystem. Cylc only needs to install files once, for all the hosts that see the same filesystem. > **[Platform Configuration — Cylc 8.4.2 documentation](https://cylc.github.io/cylc-doc/stable/html/reference/config/writing-platform-configs.html#what-are-install-targets)** > [@jtsu](#): > > Is there a way I can check to see if there are central definition of job platforms? Yes! Just type `cylc config` in your terminal. It parses and prints the global config by default (i.e., if you don’t give it a specific workflow ID). It even has a special option to print just the platform definitions. See “Platform printing options” in `cylc config --help`. ---
**Author:** ![jtsu](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/jtsu/32/517_2.png) [@jtsu](https://cylc.discourse.group/u/jtsu)\ **Post date:** [November 14, 2024, 12:46am UTC](https://cylc.discourse.group/t/runtime-task-name-job-batch-system-equivalent-in-cylc-8-3-4/1056/14 "2024-11-14T00:46:42Z")
Thank you, this is all very helpful information. I 'll reply to this thread if I have further questions while I update my suites to Cylc 8 workflows ---
**Author:** ![wxtim](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/wxtim/32/151_2.png) [@wxtim](https://cylc.discourse.group/u/wxtim)\ **Post date:** [November 14, 2024, 7:57am UTC](https://cylc.discourse.group/t/runtime-task-name-job-batch-system-equivalent-in-cylc-8-3-4/1056/15 "2024-11-14T07:57:27Z")
From `cylc config --help` ```auto Platform printing options: --platform-names Print a list of platforms and platform group names from the configuration. --platforms Print platform and platform group configurations, including metadata. ```