Skip to content

Run ACCESS-CM

Important for accessdev users!
If you are an accessdev user, make sure you are a member of hr22 and ki32 projects.
Then, refer to instructions on how to Set up persistent session worflow for ACCESS-CM, and how to port suites from accessdev.

Prerequisites

General prerequisites

Before running ACCESS-CM, you need to fulfil general prerequisites outlined in the First Steps section.

If you are unsure whether ACCESS-CM is the right choice for your experiment, take a look at the overview of ACCESS Models.

Model-specific prerequisites

  • MOSRS account
    The Met Office Science Repository Service (MOSRS) is a server run by the UK Met Office (UKMO) to support collaborative development with other partners organisations. MOSRS contains the source code and configurations for some model components in ACCESS-CM (e.g., the UM).
    To apply for a MOSRS account, please contact your local institutional sponsor.
  • Join the access, hr22, ki32, and ki32_mosrs projects at NCI
    To join these projects, request membership on the respective access, hr22 and ki32 and ki32_mosrs NCI project pages.
    To request membership for the ki32_mosrs subproject you need to be member of the ki32 project first.
    For more information on how to join specific NCI projects, refer to How to connect to a project.
  • Connection to an ARE VDI Desktop (optional)
    To run ACCESS-CM, start an Australian Research Environment (ARE) VDI Desktop session.
    If you are not familiar with ARE, check out the Getting Started on ARE section.

Set up an ARE VDI Desktop (optional)

To skip this step and instead run ACCESS-CM from Gadi login node, refer to instructions on how to Set up ACCESS-CM persistent session.

Launch ARE VDI Session

Go to the ARE VDI page and launch a session with the following entries:

  • Walltime (hours) → 2
    This is the amount of time the ARE VDI session will stay active for.
    ACCESS-CM does not run directly on ARE.
    This means that the ARE VDI session only needs to carry out setup steps as well as starting the run itself. All these tasks can be done within 2 hours.
  • Queue → normalbw
  • Compute Size → tiny (1 CPU)
    As mentioned above, the ARE VDI session is only needed for setup and startup tasks, which can be easily accomplished with 1 CPU.
  • Project → a project of which you are a member.
    The project must have allocated Service Units (SU) to run your simulation. Usually, but not always, this corresponds to your $PROJECT.
    For more information, refer to how to Join relevant NCI projects.
  • Storage → gdata/access+gdata/hh5+gdata/hr22+gdata/ki32 (minimum)
    This is a list of all project data storage (joined by + signs) needed for the ACCESS-CM simulation. In ARE, storage locations need to be explicitly defined to access data from within a VDI instance.
    Every ACCESS-CM simulation can be unique and input data can originate from various sources. Hence, if your simulation requires data stored in project folders other than access, hh5, hr22 or ki32, you need to add those projects to the storage path.
    For example, if your ACCESS-CM simulation requires data stored in /g/data/tm70 and /scratch/w40, your full storage path will be: gdata/access+gdata/hh5+gdata/hr22+gdata/ki32+gdata/tm70+scratch/w40

Launch the ARE session and, once it starts, click on Launch VDI Desktop. Launch ARE VDI session

Open the terminal in the VDI Desktop

Once the new tab opens, you will see a Desktop with a few folders on the left.
To open the terminal, click on the black terminal icon at the top of the window. You should now be connected to a Gadi computing node. Open ARE VDI terminal

Set up ACCESS-CM persistent session

To support the use of long-running processes, such as ACCESS model runs, NCI provides a service on Gadi called persistent sessions.

To run ACCESS-CM, you need to start a persistent session and set it as the target session for the model run.

Start a new persistent session

To start a new persistent session on Gadi, using either a login node or an ARE terminal instance, run the following command:

persistent-sessions start <name>

This will start a persistent session with the given name that runs under your default project.
If you want to assign a different project to the persistent session, use the option -p:

persistent-sessions start -p <project> <name>
While the project assigned to a persistent session does not have to be the same as the project used to run the ACCESS-CM configuration, it does need to have allocated Service Units (SU).
For more information, check how to Join relevant NCI projects.

persistent-sessions start <name> session <persistent-session-uuid> running - connect using  ssh <name>.<$USER>.<project>.ps.gadi.nci.org.au

To list all active persistent sessions run:

persistent-sessions list

persistent-sessions list              UUID  PROJECT   ADDRESS    CPUTIME MEMORY <persistent-session-uuid> <project> 10.9.0.62 00:00:05.213 30.5M

The label of a newly-created persistent session has the following format:
<name>.<$USER>.<project>.ps.gadi.nci.org.au.

Specify ACCESS-CM target persistent session

After starting the persistent session, it is essential to assign it to the ACCESS-CM run.
The easiest way to do this is to insert the persistent session label into the file ~/.persistent-sessions/cylc-session.
You can do it manually, or by running the following command:

cat > ~/.persistent-sessions/cylc-session <<< <name>.<$USER>.<project>.ps.gadi.nci.org.au

For example, if the user abc123 started a persistent session named cylc under the project xy00, the command will be:

cat > ~/.persistent-sessions/cylc-session <<< cylc.abc123.xy00.ps.gadi.nci.org.au cat ~/.persistent-sessions/cylc-session cylc.abc123.xy00.ps.gadi.nci.org.au

For more information on how to specify the target session, refer to Specify Target Session with Cylc7 Suites.

You can simultaneously submit multiple ACCESS-CM runs using the same persistent session without needing to start a new one. Hence, the process of specifying the target persistent session for ACCESS-CM should only need to be done once.
After specifying the ACCESS-CM target persistent session the first time, to run ACCESS-CM you just need to make sure to have an active persistent session named like the ACCESS-CM target persistent session.

Terminate a persistent session

To stop a persistent session, run:

persistent-sessions kill <persistent-session-uuid>
When you terminate a persistent session, any model running on that session will stop. Therefore, you should check whether you have any active model runs before terminating a persistent session.

Get ACCESS-CM suite

ACCESS-CM comprises the model components UM, MOM, CICE, CABLE and OASIS. These components, which have different model parameters, input data and computer-related information, need to be packaged together as a suite in order to run.
Each ACCESS-CM suite has a suite-ID in the format u-<suite-name>, where <suite-name> is a unique identifier.
For this example you can use u-cy339, which is a pre-industrial experiment suite.
Typically, an existing suite is copied and then edited as needed for a particular run.

Copy ACCESS-CM suite with Rosie

Rosie is an SVN repository wrapper with a set of options specific for ACCESS-CM suites.
To copy an existing suite on Gadi you need to follow three main steps:

  1. Get Cylc7 setup
    To get the Cylc7 setup required to run ACCESS-CM, execute the following commands: 
    module use /g/data/hr22/modulefiles
module load cylc7/23.09
    module use /g/data/hr22/modulefiles module load cylc7/23.09 Using the cylc session <name>.<$USER>.<project>.ps.gadi.nci.org.au Loading cylc7/23.09  Loading requirement: mosrs-setup/1.0.1
    2. Make sure to load Cylc version 23.09 (or later), as earlier versions do not support the persistent sessions workflow.
    Also, before loading the Cylc module, make sure to have started a persistent session and assigned it to the ACCESS-CM workflow. For more information about these steps, refer to instructions on how to Set up ACCESS-CM persistent session.
  2. MOSRS authentication
    To authenticate using your MOSRS credentials, run: 
    mosrs-auth
    mosrs-auth INFO: You need to enter your MOSRS credentials here so that GPG can cache your password. Please enter the MOSRS password for <MOSRS-username>: INFO: Checking your credentials using Subversion. Please wait. INFO: Successfully accessed Subversion with your credentials. INFO: Checking your credentials using rosie. Please wait. INFO: Successfully accessed rosie with your credentials.
  3. Copy a suite
    • Local-only copy
      To create a local copy of the <suite-ID> from the UKMO repository, run: 
      rosie checkout <suite-ID>
      rosie checkout <suite-ID> [INFO] create: /home/565/<$USER>/roses [INFO] <suite-ID>: local copy created at /home/565/<$USER>/roses/<suite-ID> This option is mostly used for testing and examining existing suites.
    • Remote and local copy
      Alternatively, to create a new copy of an existing <suite-ID> both locally and remotely in the UKMO repository, run: 
      rosie copy <suite-ID>
      rosie copy <suite-ID> Copy "<suite-ID>/trunk@<trunk-ID>" to "u-?????"? [y or n (default)] y [INFO] <new-suite-ID>: created at https://code.metoffice.gov.uk/svn/roses-u/<suite-n/a/m/e/> [INFO] <new-suite-ID>: copied items from <suite-ID>/trunk@<trunk-ID> [INFO] <suite-ID>: local copy created at /home/565/<$USER>/roses/<new-suite-ID> When a new suite is created in this way, a unique <suite-ID> is generated within the repository and populated with descriptive information about the suite and its initial configuration.

For additional rosie options, run:

rosie help


Suites are created in the user's home directory on Gadi under ~/roses/<suite-ID>. Each suite directory usually contains two subdirectories and three files:

  • app → directory containing the configuration files for various tasks within the suite.
  • meta → directory containing the GUI metadata.
  • rose-suite.conf → main suite configuration file.
  • rose-suite.info → suite information file.
  • suite.rc → Cylc control script file (Jinja2 language).
    • ls ~/roses/<suite-ID> app meta rose-suite.conf rose-suite.info suite.rc

Edit ACCESS-CM suite configuration

Rose

Rose is a configuration editor which can be used to view, edit, or run an ACCESS-CM suite.

To edit a suite configuration, run the following command from within the suite directory (e.g., ~/roses/<suite-ID>) to open the Rose GUI:

rose edit &
The & is optional. It allows the terminal prompt to remain active while running the Rose GUI as a separate process in the background.

cd ~/roses/<suite-ID> rose edit & [<N>] <PID> Rose GUI

Change NCI project

To ensure that your suite is run under the correct NCI project for which you are a member, edit the Compute project field in suite conf → Machine and Runtime Options, and click the Save button Save button.

For example, to run an ACCESS-CM suite under the tm70 project (ACCESS-NRI), enter tm70 in the Compute project field: Rose change project

To run ACCESS-CM, you need to be a member of a project with allocated Service Units (SU). For more information, check how to Join relevant NCI projects.

Change run length and cycling frequency

ACCESS-CM suites are often run in multiple steps, each one constituting a cycle. The job scheduler resubmits the suite every chosen Cycling frequency until the Total Run length is reached.

To modify these parameters, navigate to suite conf → Run Initialisation and Cycling, edit the respective fields (using ISO 8601 Duration format) and click the Save button Save button.

For example, to run a suite for a total of 50 years with a 1-year job resubmission, change Total Run length to P50Y and Cycling frequency to P1Y (the maximum Cycling frequency is currently two years): Rose change run length

Change wallclock time

The Wallclock time is the time requested by the PBS job to run a single cycle. If this time is insufficient for the suite to complete a cycle, your job will be terminated before completing the run. Hence, if you change the Cycling frequency, you may also need to change the Wallclock time accordingly. While the time required for a suite to complete a cycle depends on several factors, a good estimation is 4 hours per simulated year.

To modify the Wallclock time, edit the respective field in suite conf → Run Initialisation and Cycling (using ISO 8601 Duration format) and click the Save button Save button.

Run ACCESS-CM suite

ACCESS-CM suites run on Gadi through a PBS job submission.
When the suite runs, its configuration files are copied on Gadi inside /scratch/$PROJECT/$USER/cylc-run/<suite-ID> and a symbolic link to this directory is also created in the $USER's home directory under ~/cylc-run/<suite-ID>.
An ACCESS-CM suite comprises several tasks, such as checking out code repositories, compiling and building the different model components, running the model, etc. The workflow of these tasks is controlled by Cylc.

Cylc

Cylc (pronounced ‘silk’) is a workflow manager that automatically executes tasks according to the model's main cycle script suite.rc. Cylc controls how the job will be run and manages the time steps of each submodel. It also monitors all tasks, reporting any errors that may occur.

To run an ACCESS-CM suite run the following command from within the suite directory:

rose suite-run

After the initial tasks are executed, the Cylc GUI will open. You can now view and control the different tasks in the suite as they are run: cd ~/roses/<suite-ID> rose suite-run [INFO] export CYLC_VERSION=7.9.7 export ROSE_ORIG_HOST=<gadi-cpu>.gadi.nci.org.au [INFO] export ROSE_SITE=nci [INFO] export ROSE_VERSION=2019.01.7 [INFO] create: /home/565/<$USER>/cylc-run/<suite-ID> [INFO] create: log.<timestamp> [INFO] symlink: log.<timestamp> <= log [INFO] create: log/suite [INFO] create: log/rose-conf [INFO] symlink: rose-conf/<timestamp>-run.conf <= log/rose-suite-run.conf [INFO] symlink: rose-conf/<timestamp>-run.version <= log/rose-suite-run.version [INFO] create: meta [INFO] install: meta     source: /home/565/<$USER>/roses/<suite-ID>/meta [INFO] install: rose-suite.info     source: /home/565/<$USER>/roses/<suite-ID>/rose-suite.info [INFO] create: app [INFO] install: app     source: /home/565/<$USER>/roses/<suite-ID>/app [INFO] install: suite.rc [INFO] REGISTERED <suite-ID> -> /home/565/<$USER>/cylc-run/<suite-ID> [INFO] create: share [INFO] create: share/cycle [INFO] create: work [INFO] chdir: log/ [WARN] Using the cylc session <persistent-session-full-name> [WARN] [WARN] Loading cylc7/23.09 [WARN]  Loading requirement: mosrs-setup/1.0.1 [INFO]         ._. [INFO]         | |         The Cylc Suite Engine [7.9.7] [INFO] ._____._. ._| |_____.      Copyright (C) 2008-2019 NIWA [INFO] | .___| | | | | .___| & British Crown (Met Office) & Contributors. [INFO] | !___| !_! | | !___. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ [INFO] !_____!___. |_!_____! This program comes with ABSOLUTELY NO WARRANTY; [INFO]     .___! |      see cylc warranty.  It is free software, you [INFO]     !_____!       are welcome to redistribute it under certain [INFO] [INFO] *** listening on https://<persistent-session-full-name>:<port>/ *** [INFO] [INFO] To view suite server program contact information: [INFO] $ cylc get-suite-contact <suite-ID> [INFO] [INFO] Other ways to see if the suite is still running: [INFO] $ cylc scan -n '<suite-ID>' <persistent-session-full-name> [INFO] $ cylc ping -v --host=<persistent-session-full-name> <suite-ID> [INFO] $ ps -opid,args <PID> # on <persistent-session-full-name> Cylc GUI -->

After running the command rose suite-run, if you get an error similar to the following: 
[FAIL] Suite "<suite-ID>" appears to be running:
[FAIL] Contact info from: "/home/565/<$USER>/cylc-run/<suite-ID>/.service/contact"
[FAIL]    CYLC_SUITE_HOST=<persistent-session-full-name>
[FAIL]    CYLC_SUITE_OWNER=<$USER>
[FAIL]    CYLC_SUITE_PORT=<port>
[FAIL]    CYLC_SUITE_PROCESS=<PID> /g/data/hr22/apps/cylc7/bin/python -s /g/data/hr22/apps/cylc7/cylc_7.9.7/bin/cylc-run <suite-ID> --host=localhost
[FAIL] Try "cylc stop '<suite-ID>'" first?
you should run: 
rm /home/565/<$USER>/cylc-run/<suite-ID>/.service/contact
before running the rose suite-run command again.

You are done!!

If you do not get any errors, you can check the suite output files after the run is complete.
You can now close the Cylc GUI. To open it again, run the following command from within the suite directory: 

rose suite-gcontrol

Monitor ACCESS-CM runs

Check for errors

It is quite common, especially during the first few runs, to experience errors and job failures. Running an ACCESS-CM suite involves the execution of several tasks, and any of these tasks could fail. When a task fails, the suite is halted and a red icon appears next to the respective task name in the Cylc GUI.
To investigate the cause of a failure, we need to look at the logs job.err and job.out from the suite run. There are two main ways to do so:

  1. Using the Cylc GUI
    Right-click on the task that failed and click on View Job Logs (Viewer) → job.err or job.out.
    To access a specific task, click on the arrow next to the task to extend the drop-down menu with all the subtasks.
    Investigate Error GUI
  2. Through the suite directory
    The suite's log directories are stored in ~/cylc-run/<suite-ID> as log.<TIMESTAMP>, and the latest set of logs are also symlinked in the ~/cylc-run/<suite-ID>/log directory.
    The logs for the main job can be found in the ~/cylc-run/<suite-ID>/log/job directory.
    Logs are separated into simulation cycles according to their starting dates, and then differentiated by task. They are then further separated into "attempts" (consecutive failed/successful tasks), where NN is a symlink to the most recent attempt.

    In the example above, a failure occurred for the 09500101 simulation cycle (i.e. starting date \: 1st January 950) in the coupled task. Hence, the job.err and job.out files can be found in the ~/cylc-run/<suite-ID>/log/job/09500101/coupled/NN directory. cd ~/cylc-run/<suite-ID> ls app cylc-suite.db log log.20230530T051952Z meta rose-suite.info share suite.rc suite.rc.processed work cd log ls db job rose.conf rose-suite-run.conf rose-suite-run.locs rose-suite-run.log rose-suite-run.version suite suiterc cd job ls 09500101 cd 09500101 ls coupled fcm_make2_um fcm_make_um install_warm make2_mom make_mom fcm_make2_drivers fcm_make_drivers install_ancil make2_cice make_cice cd coupled ls 01 02 03 NN cd NN ls job job-activity.log job.err job.out job.status

Model Live Diagnostics

ACCESS-NRI developed the Model Live Diagnostics framework to check, monitor, visualise, and evaluate model behaviour and progress of ACCESS models currently running on Gadi.
For a complete documentation on how to use this framework, check the Model Diagnostics documentation.

Stop, restart and reload suites

In some cases, you may want to control the running state of a suite.
If your Cylc GUI has been closed and you are unsure whether your suite is still running, you can scan for active suites and reopen the GUI if desired.
To scan for active suites, run:

cylc scan

To reopen the Cylc GUI, run the following command from within the suite directory:

rose suite-gcontrol

cylc scan <suite-ID> <$USER>@<gadi-cpu>.nci.org.au:<port> cd ~/roses/<suite-ID> rose suite-gcontrol Cylc GUI

STOP a suite

To shutdown a suite in a safe manner, run the following command from within the suite directory:

rose suite-stop -y

Alternatively, you can directly kill the PBS job(s) connected to your run. To do so:

  1. Check the status of all your PBS jobs: 
    qstat -u $USER
  2. Delete any job related to your run: 
    qdel <job-ID>

RESTART a suite

There are two main ways to restart a suite:

  • SOFT restart
    To reinstall the suite and reopen Cylc in the same state it was prior to being stopped, run the following command from within the suite directory: 
    rose suite-run --restart
    You may need to manually trigger failed tasks from the Cylc GUI.
    cylc cd ~/roses/<suite-ID> rose suite-run --restart [INFO] export CYLC_VERSION=7.9.7 [INFO] export ROSE_ORIG_HOST=<gadi-cpu>.nci.org.au [INFO] export ROSE_SITE=nci [INFO] export ROSE_VERSION=2019.01.2 [INFO] delete: log/rose-suite-run.conf [INFO] symlink: rose-conf/<timestamp>-restart.conf <= log/rose-suite-run.conf [INFO] delete: log/rose-suite-run.version [INFO] symlink: rose-conf/<timestamp>-restart.version <= log/rose-suite-run.version [INFO] chdir: log/ [WARN] Using the cylc session <persistent-session-full-name> [WARN] [WARN] Loading cylc7/23.09 [WARN]  Loading requirement: mosrs-setup/1.0.1 [INFO]         ._. [INFO]         | |         The Cylc Suite Engine [7.9.7] [INFO] ._____._. ._| |_____.      Copyright (C) 2008-2019 NIWA [INFO] | .___| | | | | .___| & British Crown (Met Office) & Contributors. [INFO] | !___| !_! | | !___. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ [INFO] !_____!___. |_!_____! This program comes with ABSOLUTELY NO WARRANTY; [INFO]     .___! |      see `cylc warranty`.  It is free software, you [INFO]     !_____!       are welcome to redistribute it under certain [INFO] [INFO] *** listening on https://<persistent-session-full-name>:<port>/ *** [INFO] [INFO] To view suite server program contact information: [INFO] $ cylc get-suite-contact <suite-ID> [INFO] [INFO] Other ways to see if the suite is still running: [INFO] $ cylc scan -n '<suite-ID>' <persistent-session-full-name> [INFO] $ cylc ping -v --host=<persistent-session-full-name> <suite-ID> [INFO] $ ps -opid,args <PID> # on <persistent-session-full-name> Cylc GUI

  • HARD restart
    To overwrite any previous runs of the suite and start afresh, run the following command from within the suite directory: 
    rose suite-run --new
    WARNING!! This will overwrite all existing model output and logs for the same suite.

RELOAD a suite

In some cases the suite needs to be updated without necessarily having to stop it (e.g., after fixing a typo in a file). Updating an active suite is called a reload, where the suite is re-installed and Cylc is updated with the changes. This is similar to a SOFT restart, except new changes are installed, so you may need to manually trigger failed tasks from the Cylc GUI.

To reload a suite, run the following command from within the suite directory:

rose suite-run --reload

ACCESS-CM output files

All ACCESS-CM output files, together with work files, are available on Gadi inside /scratch/$PROJECT/$USER/cylc-run/<suite-ID>. They are also symlinked in ~/cylc-run/<suite-ID>.
While the suite is running, files are moved between the share and work directories.
At the end of each cycle, model output data and restart files are moved to /scratch/$PROJECT/$USER/archive/<suite-name>.
This directory contains two subdirectories:

  • history
  • restart

Output data

/scratch/$PROJECT/$USER/archive/<suite-name>/history is the directory containing the model output data, which is grouped according to each model component:

  • atm → atmosphere (UM)
  • cpl → coupler (OASIS3-MCT)
  • ocn → ocean (MOM)
  • ice → ice (CICE)

For the atmospheric output data, the files are typically a UM fieldsfile or netCDF file, formatted as <suite-name>a.p<output-stream-identifier><year><month-string>.

For the u-cy339 suite in this example, the atm directory contains: cd /scratch/<$PROJECT>/<$USER>/archive ls cy339 <other-suite-name> <other-suite-name> cd cy339 ls history restart ls history/atm cy339a.pd0950apr.nc cy339a.pd0950aug.nc cy339a.pd0950dec.nc cy339a.pd0950feb.nc cy339a.pd0950jan.nc cy339a.pd0950jul.nc cy339a.pd0950jun.nc cy339a.pd0950mar.nc cy339a.pd0950may.nc cy339a.pd0950nov.nc cy339a.pd0950oct.nc cy339a.pd0950sep.nc cy339a.pd0951apr.nc cy339a.pd0951aug.nc cy339a.pd0951dec.nc cy339a.pm0950apr.nc cy339a.pm0950aug.nc cy339a.pm0950dec.nc cy339a.pm0950feb.nc cy339a.pm0950jan.nc cy339a.pm0950jul.nc cy339a.pm0950jun.nc cy339a.pm0950mar.nc cy339a.pm0950may.nc cy339a.pm0950nov.nc cy339a.pm0950oct.nc cy339a.pm0950sep.nc cy339a.pm0951apr.nc cy339a.pm0951aug.nc cy339a.pm0951dec.nc netCDF

Restart files

The restart files can be found in the /scratch/$PROJECT/$USER/archive/<suite-name>/restart directory, where they are categorised according to model components (similar to the history folder above).
The atmospheric restart files, which are UM fieldsfiles, are formatted as <suite-name>a.da<year><month><day>_00.

For the u-cy339 suite in this example, the atm directory contains: ls /scratch/<$PROJECT>/<$USER>/archive/cy339/restart/atm cy339a.da09500201_00 cy339a.da09510101_00 cy339.xhist-09500131 cy339.xhist-09501231

Files formatted as <suite-name>a.xhist-<year><month><day> contain metadata information.

Port suites from accessdev

accessdev was the server used for ACCESS-CM run submission workflow before the update to persistent sessions.
If you have a suite that was running on accessdev, you can run it using persistent sessions by carrying out the following steps:

  1. Initialisation step
    To set the correct SSH configuration for Cylc, some SSH keys need to be created in the ~/.ssh directory.
    To create the required SSH keys, run the following command: 
    /g/data/hr22/bin/gadi-cylc-setup-ps -y
    You only need to run this initialisation step once.
  2. Set host to localhost
    To enable Cylc to submit PBS jobs directly from the persistent session, the suite configuration should have its host set as localhost.
    You can manually set all occurrences of host to localhost in the suite configuration files.
    Alternatively, you can run the following command in the suite folder: 
    grep -rl --exclude-dir=.svn "host\s*=" . | xargs sed -i 's/\(host\s*=\s*\).*/\1localhost/g'
  3. Add gdata/hr22 and gdata/ki32 in the PBS storage directives
    As the persistent sessions workflow uses files in the hr22 and ki32 project folders on Gadi, the respective folders need to be added to the storage directive in the suite configuration files.
    You can do this manually or run the following command from within the suite directory: 
    grep -rl --exclude-dir=.svn "\-l\s*storage\s*=" . | xargs sed -i '/\-l\s*storage\s*=\s*.*gdata\/hr22.*/! s/\(\-l\s*storage\s*=\s*.*\)/\1+gdata\/hr22/g ; /\-l\s*storage\s*=\s*.*gdata\/ki32.*/! s/\(\-l\s*storage\s*=\s*.*\)/\1+gdata\/ki32/g'
Some suites might not be ported this way.
If you have a suite that was running on accessdev and, even after following the steps above, the run submission fails, consider getting help on the Hive Forum.


References
Last update: April 25, 2024