Opened 10 months ago

Closed 9 months ago

#3308 closed help (answered)

Automate config editing and suite running by Python scripts

Reported by: s1895566 Owned by: um_support
Component: Rose/Cylc Keywords:
Cc: Platform: NEXCS
UM Version:

Description

I need to run the same suite for a short period of timesteps multiple times (in parallel or in series, doesn't matter), each time with a different initial condition (i.e. AINITIAL filename).

Is there a way to automate the config editing, suite running, and dumping by writing Python scripts (or bash)? Thanks!

Change History (12)

comment:1 Changed 10 months ago by dcase

Do you mean like running ensembles? You can do this with cylc variables. If you have a look at suite u-bd149 in roses then this may be what you're after? (This is a coupled UM run- but the cylc framework could run other things).

Dave

comment:2 Changed 10 months ago by s1895566

No. I would like to run my suite for a few timesteps with many different initial states. Thanks.

comment:3 Changed 10 months ago by dcase

The suite that I suggested (although was run on ARCHER) perturbs the initial state many times, then runs it, so sounds like what you are doing. You can replace the script which applies the perturbation to be one that does something of your choosing.

If I were you I would look at taking the Cylc commands from here as the structure of your suite (with appropriate variables as needed), and in this way you can automate things.

One slight caveat to note is that whilst Cylc has parameterisation (see https://metomi.github.io/rose/2019.01.2/html/tutorial/cylc/runtime/configuration-consolidation/parameters.html) you may not have all options available if your version of cylc is older. It may be a bit fiddly to cut suites up and remember to alter all required variables, so take care.

comment:4 Changed 10 months ago by dcase

Have you had much success looking into your problem? If there is a reason why using cylc variables, as in this suite, will not work then feel free to ask. Otherwise, could I shut this ticket?

If you give your suite a go and find problems, you can open another ticket with those details.

Thanks,
Dave

comment:5 Changed 10 months ago by s1895566

Can I trigger a "rose suite-run"-like action using Python then? Thanks.

comment:6 Changed 10 months ago by dcase

Eden,

I'm assuming here that you want to run the UM many times from different starting points. If so you would be better calling your python script (to perturb the start) many times from one cylc suite, rather than using python to start many cylc suites (which would then be competing with each other for resources in an uncontrolled manner).

If you look at the suite I suggested, the parameters section allows you to define variables:

[cylc]
    [[parameters]]
        ensemble = {{ range(ENSEMBLE_SIZE) | join(', ') }}

and then in the graph, you would have:
'recon => your_alteration<ensemble> => coupled<ensemble>'

so you could define some number of ensembles (rename this variable if appropriate) and then you would run your_alteration which does whatever you want it to do, as it will run your python script. Finally you would run your simulation from this altered starting point. The recon is run once, but the alteration and running of the simulation (a coupled job here, but could be atmosphere only if you'd prefer) are both run ENSEMBLE_SIZE times.

If what I'm describing sounds like what you'd like to do, then I would start from a suite which works, and use this as the basis for your suite.

Dave

comment:7 Changed 10 months ago by s1895566

This is not what I'm trying to achieve. I would like to run the suite with many initial states (at different times) that are very different from one another, not just a perturbed one.

I figured I could change config of AINITIAL filenames using Python scripts, and I wonder if I could trigger "rose suite-run" from Python with some kind of API.

comment:8 Changed 10 months ago by dcase

The suite that I've showed you runs many coupled jobs with different starting points. The app was called perturb, because all of these starting conditions are only a little different from each other, but you can use the same set-up to run with starting conditions that are completely different if you'd like to.
In fact, if you can pre-generate your start dumps then all you will need to do is copy them to the correct place at the point where I was generating a new one with the perturb script.

There are definite advantages to using this suite though. If you look at the coupled job:

    [[coupled<ensemble>]]
        inherit = None, COUPLED
        [[[environment]]]
            ASTART = $ROSE_DATA/$RUNID.astart_${CYLC_TASK_PARAM_ensemble}
            DATAM = $ROSE_DATA/{{DATAM}}/ensemble_${CYLC_TASK_PARAM_ensemble}

you can see how to define input files and output directories for your runs. You can make your files and label them all $RUNID.astart_1, $RUNID.astart_2, $RUNID.astart_3 etc, and point ASTART to be the correct one.

If you wanted to run many different suites you would probably end repeating work, hitting resource problems, and still needing to point your simulation to the correct start dump.

If you have further questions about this, please ask. If you are trying to do something else, please tell me "I want to run X UM simulations, and I want to generate my start dumps in manner Y" so that I can see what X and Y are.

Thanks

comment:9 Changed 9 months ago by s1895566

Hi Dave,

So I was able to write a Python script that runs the same suite iteratively (in series) with various AINITIAL files. Is it possible to run the same suite with slightly various config in parallel by modifying some unique identifier locally? Say modifying the suite name locally as u-bv465-01, u-bv465-02 etc.. Thanks!

Eden

comment:10 Changed 9 months ago by s1895566

Hi, would appreciate if you could help with that. Thanks!

comment:11 Changed 9 months ago by ros

Hi Eden,

rose suite-run --name=NAME may be what you're after.

cylc could have managed this all for you.

Cheers,
Ros.

comment:12 Changed 9 months ago by grenville

  • Resolution set to answered
  • Status changed from new to closed

activity appears to spill into #3332

Note: See TracTickets for help on using tickets.