Inconsistent "invalid suite ID" error when running ACCESS-CM2

Earth System
,
1

I’m running some experiments with ACCESS-CM2 by copying suite corresponding to a piControl simulation that I ran on Gadi (u-dk158). As of a few weeks ago, whenever I try to copy this suite-ID I get this error:

Screenshot 2025-12-02 at 4.57.37 PM
Screenshot 2025-12-02 at 4.57.37 PM813×263 33.4 KB

If I log out of Gadi, log back in, reload cylc and re-authenticate mosrs, then sometimes I can copy the suite successfully, although sometimes the error persists. Has anyone else come across this before?

2

Hi @hrsdawson I’ll see if someone from access-nri can help you with this. Do you mind also sharing what modules you load and the order you load them? That might a source of the error.

3

Hi Edward, thanks for following up. I’m following the instructions here, so running;

module use /g/data/hr22/modulefiles
module load cylc7and then

mosrs-auth

This loads cylc7/24.03 and mosrs-setup/2.0.1. I’m not loading any other modules.

4

Hi Hannah

Could you try deactivating your conda environment and then trying again?

5

Hi @hrsdawson, We haven’t been able to reproduce your problem so it might be an auth issue or other issue with the modules. if @Paul.Gregory’s suggestion doesn’t help I suggest reaching out to NCI as they manage the modules in hr22.

6

Thanks both for your suggestions and sorry for my slow responses - I’m on a research voyage at the moment. Just to clarify, which conda environment do you mean? If I unload the cylc7 module and then reload it, then yes sometimes I am able to copy the suite successfully. So all-in-all this is not an urgent issue (with persistence I can get the suite copied), it’s just very perplexing to me that it works sometimes, and not others.

7

Hi Hannah

Your post above displayed your login prompt as

(base) (hd4873@gadi-login-05 roses]$ rosie copy u-dk158

and the (base) section indicates that you currently have your base conda environment activated.

Next time you have this issue, can you type conda deactivate at the command line (which will remove the base environment)?

Given that rosie relies on the cylc7 package (and its python libraries), I had a hunch that maybe your local conda environment is conflicting with the python libraries within cylc7.

If this turns out to be the case, you might want to set your local conda environment to not automatically activate.

Or alternatively, remove it altogether and just rely on the NRI supplied condapackages.

PS Whereabouts are you at the moment? Sailing around Antarctica?

8

Interesting, I didn’t realise my local conda environment was being activated! I’ve gone into my .bashrc file and I can see this code block (no idea if I added this - if I did it was years ago). If I comment this out, will this stop the local conda environment being activated when I log in?

# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$('/g/data/e14/hd4873/miniconda3/bin/conda' 'shell.bash' 'hook' 2> /dev/null)"
if [ $? -eq 0 ]; then
    eval "$__conda_setup"
else
    if [ -f "/g/data/e14/hd4873/miniconda3/etc/profile.d/conda.sh" ]; then
        . "/g/data/e14/hd4873/miniconda3/etc/profile.d/conda.sh"
    else
        export PATH="/g/data/e14/hd4873/miniconda3/bin:$PATH"
    fi
fi
unset __conda_setup

Yes - anchored off Casey station at the moment!

1 Like
9

Yes. If you comment that section out, it will no longer activate automatically when you log in.

PPS post pics! :smiley: