Current expt time for running jobs in payu status by Qian-HuiChen · Pull Request #702 · payu-org/payu

Qian-HuiChen · 2026-03-12T03:11:22Z

In payu status, display current experiment time for running jobs, as:

  Job ID:            xxx.gadi-pbs
  Run ID:            xxx
  Stage:             model-run
  Total queue time:  0h 1m 4s
  Current Expt Time: 1901-02-20T00:00:00
  ::

This is implemented in models:

OM2
ESM1.6
MOM6
OM3
For other models, no current expt time will be displayed.

In payu status, display current model finish time for archived jobs, e.g.,

Job ID:            xxx.gadi-pbs
 Run ID:            xxx
 Stage:             archive
 Total queue time:  0h 0m 22s
 Model Finish Time: 1900-05-01T00:00:00
 ::

Closes #701 as part of #640.

codecov · 2026-03-12T22:26:12Z

Codecov Report

❌ Patch coverage is 94.07407% with 8 lines in your changes missing coverage. Please review.
✅ Project coverage is 64.04%. Comparing base (0c05697) to head (b50a431).

Files with missing lines	Patch %	Lines
payu/status.py	80.95%	4 Missing ⚠️
payu/models/access_esm1p6.py	75.00%	1 Missing ⚠️
payu/models/mom6.py	96.00%	1 Missing ⚠️
payu/models/um.py	96.15%	1 Missing ⚠️
payu/subcommands/status_cmd.py	83.33%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #702      +/-   ##
==========================================
+ Coverage   63.30%   64.04%   +0.74%     
==========================================
  Files          67       67              
  Lines        5426     5541     +115     
==========================================
+ Hits         3435     3549     +114     
- Misses       1991     1992       +1

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

…archived jobs.

Qian-HuiChen · 2026-03-15T21:59:14Z

Good morning @anton-seaice @blimlim @ezhilsabareesh8,
We are trying to display current model time (e.g., 1901-05-01T00:00:00) in payu status, which could be helpful during a long experiment run.

It will be highly appreciated if you could provide some feedback from a user perspective:

Is this information useful?
Is the current mode of presentation clear?
Any other feedback :)

Thanks!

jo-basevi · 2026-03-17T04:17:55Z

Thanks for adding this in! Great to have this implemented for so many model drivers.

I was testing running this branch with a pre-existing MOM6 configuration, and I am getting a warning when running payu status:

~/payu_development/payu_fork/payu/models/mom6.py:164: UserWarning: Could not find required files: /scratch/tm70/USER/mom6/work/mom6_double_gyre-expt-d9cb6783/input.nml or /scratch/tm70/USER/mom6/work/mom6_double_gyre-expt-d9cb6783/ocean.stats

As the run has completed, the work directory no longer exists so should change the code to only query the current run time only when the model is running.

The other initial thing I noticed was payu status --json also prints warnings before printing a json blob. In this case the output probably should only be json so it can still be machine readable.
UPDATE: Ok it's still possible to parse the json even with warnings as the warnings I think go to stderr. (e.g. payu status --json | jq '.experiment_uuid' seems to parse fine)

blimlim

Thanks @Qian-HuiChen, I've had a look through the changes and I think they're looking really good. Being able to query the run date like this would be very useful.

I've added a few small comments and questions throughout.

For the ESM1.6 implementation, all the relevant files (work/atmosphere/namelists, work/atmosphere/atm.fort6.pe0, and the suggested work/atmosphere/um.res.yaml) are all used and produced specifically by the UM submodel. Because of this, I'm wondering whether it could make sense to move the implementation of get_curr_exp_time from access_esm1p6.py to um.py, and then access it using the get_cur_expt_time_using_submodel method in ESM1.6?

test/models/test_access_om2.py

payu/models/mom6.py

blimlim · 2026-03-17T00:56:36Z

payu/models/access_esm1p6.py

+    def read_start_date(self, nl_path):
+        """Read the start date from the namelist file"""
+        try:
+            namelist = f90nml.read(nl_path)
+            model_basis_time = namelist.get('nlstcall', {}).get('model_basis_time', None)
+            if model_basis_time is None:
+                warnings.warn(f"model_basis_time not found in {nl_path}")
+                return None
+            return datetime(*model_basis_time)
+        except Exception as e:
+            warnings.warn(f"Could not read file {nl_path}: {e}")
+            return None


Apologies @Qian-HuiChen, I'm think my previous suggestion for reading the start date from the work/atmosphere/namelists file might not be the best one! It should work perfectly as is, but I'm thinking there might be existing methods which could be used to reduce duplication.

Each UM restart directory contains a calendar yaml file um.res.yaml, which holds a copy of the restart date (see /g/data/vk83/prerelease/configurations/inputs/access-esm1p6/modern/pre-industrial/restart/2026.02.20/atmosphere for an example).

I'd forgotten that we'd previously added a method to the um.py driver, get_restart_datetime which reads the date from this file, and uses it for the date-based restart pruning.

I'm wondering if it would make sense to reuse this method to get the start date, as it could be pointed to the copy of um.res.yaml in the atmosphere/work directory.

One issue is that the um.res.yaml is technically not required to run the model, and it's possible for it to be missing. This would nearly never be the case though, but there would have to be a safety check/warning in case it is missing.

Thanks for pointing this out! It is better to reuse the get_restart_datetime than writing a new one.
I have changed the code to read out the starting date from work/atmosphere/um.res.yaml.

payu/models/model.py

blimlim · 2026-03-17T04:48:27Z

payu/subcommands/status_cmd.py

        )

    if json_output:
        print(json.dumps(data, indent=4))


Should the current experiment time also be written to the json output, or would there not really be any uses for it?

I agree it will be good to have the current expt time here as well. I have added it in the latest commit.

If adding current experiment time to the json and the formatted display then it might make sense to add it in build_job_info() to reduce duplication and use status == model-run

While testing this out I just noticed that payu status --json also doesn't print out the model finish time after the run has completed:

pay======================================== Run: 0 Job ID: 163732205.gadi-pbs Run ID: cd891450d95f0b8454f880b80bbb9fed40c034b4 Stage: archive Total queue time: 0h 1m 27s Model Finish Time: 0001-01-06T00:00:00 Exit Status: 0 (Success) Model Exit Code: 0 (Success) Output Log: /home/565/sw6175/esm1.6/misc/gettime-test/pre-industrial.o163732205 Error Log: /home/565/sw6175/esm1.6/misc/gettime-test/pre-industrial.e163732205 Job File: /scratch/tm70/sw6175/access-esm/archive/gettime-test-dev-preindustrial+concentrations-d33399d8/payu_jobs/0/run/163732205.gadi-pbs.json ======================================== u(payu-env) [sw6175@gadi-login-01 gettime-test]$ payu status --json { "experiment_uuid": "d33399d8-053d-4eb6-aa5b-2b7e0ff783e5", "runs": { "0": { "run": [ { "job_id": "163732205.gadi-pbs", "run_id": "cd891450d95f0b8454f880b80bbb9fed40c034b4", "stage": "archive", "exit_status": 0, "model_exit_status": 0, "stdout_file": "/home/565/sw6175/esm1.6/misc/gettime-test/pre-industrial.o163732205", "stderr_file": "/home/565/sw6175/esm1.6/misc/gettime-test/pre-industrial.e163732205", "job_file": "/scratch/tm70/sw6175/access-esm/archive/gettime-test-dev-preindustrial+concentrations-d33399d8/payu_jobs/0/run/163732205.gadi-pbs.json", "start_time": "2026-03-23T16:23:21.697106" } ] } } }

I'm wondering whether it would also work to add the finish time in build_job_info(), though I don't think I properly understand yet how the finish time is set.

though I don't think I properly understand yet how the finish time is set.

model_finish_time is parsed from restart files by get_model_restart_datetimes() in experiment.py when stage is changed to archive.

whether it would also work to add the finish time in build_job_info()

Sounds good! I have implemented this in the latest commit. Now payu status --json should return something like:

{ "experiment_uuid": "eaxxxx7", "runs": { "5": { "run": [ { :: "stage": "archive", :: "start_time": "2026-03-27Txxx", "model_finish_time": "0012-02-11T00:00:00" } ] } } }

I also confirm that model_finish_time is not written twice in job file.

anton-seaice · 2026-03-18T00:52:23Z

payu/models/cesm_cmeps.py

+            if os.path.exists(log_path):
+                with open(log_path, 'r') as f:
+                    for line in reversed(f.readlines()):
+                        if line.startswith(" memory_write: model date"):


It looks like its currently hardcoded to write this every model day:

https://github.com/access-nri/cmeps/blob/988c698ed6973c9d3c3cd7a14f497468ba94519f/mediator/med_phases_profile_mod.F90#L96-L98

as long as

med_phases_profile

is run.

So this seems fairly robust that "memory_write: model date" would always be available

Thanks for checking this in the model code 👍

anton-seaice · 2026-03-18T01:55:36Z

payu/subcommands/status_cmd.py

-            metadata.setup()
+            expt = Experiment(lab, config_path=config_path)
+            expt.init_models()
+            cur_expt_time = expt.get_model_cur_expt_time()


I wonder if we skip get_model_cur_expt_time() this step if stage is payu setup:

e.g.

$ payu status /g/data/tm70/as2285/payu-dev/payu-dev/lib64/python3.11/site-packages/payu/models/cesm_cmeps.py:439: UserWarning: Log file /scratch/tm70/as2285/access-om3/work/1112-update-25km-topo/log/med.log does not exist or does not contain current model time. ======================================== Run: 0 Job ID: 163373011.gadi-pbs Stage: setup Job File: /scratch/tm70/as2285/access-om3/archive/1112-update-25km-topo/payu_jobs/0/run/163373011.gadi-pbs.json

shows a warning when it's the expected behaviour

or job is in the queue still

Yeah this could be deferred to a later point when we know the the current stage is "model-run"

Thanks for picking this up!
Following the suggestion from @jo-basevi , I have changed payu to run get_model_cur_expt_time() only during model-run stage in the latest commit.

anton-seaice · 2026-03-18T02:54:55Z

For OM3 - this appears to work ok.

It does take a while for the model to initialise and run the first day, is it unclear that the warning always gets returned during this initialisation"

$ payu status
/g/data/tm70/as2285/payu-dev/payu-dev/lib64/python3.11/site-packages/payu/models/cesm_cmeps.py:439: UserWarning: Log file /scratch/tm70/as2285/access-om3/work/1112-update-25km-topo-1028-MC_25km_jra_iaf+wombatlite-15d683d3/log/med.log does not exist or does not contain current model time.
========================================
Run: 0
  Job ID:            163380214.gadi-pbs
  Run ID:            e5ff7b27fa5b0fc7de126a8b8d10e19646b24b10
  Stage:             model-run
  Job File:          /scratch/tm70/as2285/access-om3/archive/1112-update-25km-topo-1028-MC_25km_jra_iaf+wombatlite-15d683d3/payu_jobs/0/run/163380214.gadi-pbs.json
========================================

jo-basevi

Just added a couple more comments.

I wonder if each get_cur_expt_time() model driver method could return a cftime.datetime object. It would catch if a valid date was parsed from the files correctly, and it would also store calendar information that could be used at a later point

As there may (?) be updates to models and their file contents in future, I wonder if we could add a optional command-line flag to silence warnings?

Another option to protect payu status erroring out in the future would be to have a higher level exception catch, e.g. something like:

try:
   current_model_time = self.model.get_cur_expt_time()
except Exception:
   warnings.warn("Unexpected error parsing current experiment time")

Could also raise Exceptions for FileNotFound, ValueErrors etc during parsing for current run time, and let those exceptions bubble up and then catch exceptions at a higher level and then display a warning of the error. The benefits of this is that you don't need to return and handle None values as much.

payu/telemetry.py

jo-basevi · 2026-03-18T02:40:05Z

payu/subcommands/status_cmd.py

-            metadata.setup()
+            expt = Experiment(lab, config_path=config_path)
+            expt.init_models()
+            cur_expt_time = expt.get_model_cur_expt_time()


Yeah this could be deferred to a later point when we know the the current stage is "model-run"

jo-basevi · 2026-03-18T02:43:57Z

payu/models/model.py

+    def get_cur_expt_time(self):
+        """For model not implemented experiment time calculate/read-out,
+        leaves a warning and returns None."""
+        print("Getting current experiment time is not yet implemented.")


Could leave this print statement out or change it to a warning?

After further consideration, I agree that a persistent warning is too intrusive, especially since payu status remains functional to display all other info, even if the experiment time isn't available.

In the latest commit, I have moved these messages to logger.debug(). This suppresses the 'noise' for standard users while ensuring the status output remains clean (see below). If a developer needs to troubleshoot why a specific model's time isn't fetched, they can simply run with the debug logging level enabled.

======================================== Run: 0 Job ID: 100000.gadi-pbs Run ID: aaaaa0000000 Stage: model-run Job File: /scratch/tm70/... ========================================

What do you think?

I think that could work. We don't have command-line flags currently that enables debug logging easily however. I think there was some talk about that in this issue: #673.
As this PR already has a number of changes, an option could be to use warnings now and then change it in a future PR?

Right. I change this back to a print statement. When I use warnings.warn, it includes the file path and line numbers in the output. I want to avoid these technical "noise" in payu status display, so I left it as a print statement.

payu/models/access_esm1p6.py

jo-basevi · 2026-03-18T03:04:02Z

payu/models/accessom2.py

+            warnings.warn(f"Log file {log_path} does not exist or does not contain current model time.")
+            return None
+
+        except KeyError as e:


What raises the KeyError here? If 'cur_exp-datetime' is in a string but not a top-level key in the json?

Could also guard against errors with json.loads(line) where line isn't valid json.

I was thinking if line cannot be parsed as json or 'cur_exp-datetime' is not the top key.
I changed it to:

if 'cur_exp-datetime' in line: line_json = json.loads(line) time_str = line_json.get('cur_exp-datetime', None) if time_str is not None: return cftime.datetime.strptime(time_str, '%Y-%m-%dT%H:%M:%S')

and let the error bubble up and then the top level will catch the error.

jo-basevi · 2026-03-18T03:20:48Z

payu/models/cesm_cmeps.py

+            warn(f"Log file {log_path} does not exist or does not contain current model time.")
+            return None
+
+        except KeyError as e:


Should this be an IndexError for line.split()[4]

You are right! It is good to correctly specify the error.

anton-seaice · 2026-03-18T22:09:35Z

As there may (?) be updates to models and their file contents in future, I wonder if we could add a optional command-line flag to silence warnings?

I also wondered if the whole change could be configured in config.yaml, e.g. the filename, the search string etc. But payu already has lots of configuration items hard coded in, so it seemed unnecessarily complicated !

…ur_expt_time to um; log error at debug level.

Qian-HuiChen · 2026-03-20T01:06:48Z

Thanks @jo-basevi for pointing out the exception handling. I totally agree that we should use try::except in the top level and let the error bubble up. In the latest commit, in status.py:

if run_info.get("stage") == "model-run":
    cur_expt_time = None
    try:
        cur_expt_time = expt.get_model_cur_expt_time()
    except (FileNotFoundError, IndexError, OSError, json.JSONDecodeError, UnboundLocalError) as e:
        logger.debug(f"Cannot parse current experiment time: {e}")
    except Exception as e:
        logger.warning(f"Unexpected error getting current experiment time: {e}")

    if cur_expt_time is not None:
        print(f"  {'Current Expt Time:':<18} {cur_expt_time.isoformat()}")

so it simplifies the code without returning a trillion amount of None.

I wonder if each get_cur_expt_time() model driver method could return a cftime.datetime object.

This is also a great idea. I have changed the driver to return cftime.datetime object and transform it into string right before the printing.

…signing.

jo-basevi

Thank you for adding in all those changes! Just added a few more comments.

jo-basevi · 2026-03-20T05:28:49Z

payu/models/accessom2.py

+import logging
+logger = logging.getLogger(__name__)

 from payu.models.model import Model



Suggested change

import logging

logger = logging.getLogger(__name__)

from payu.models.model import Model

import logging

from payu.models.model import Model

logger = logging.getLogger(__name__)

Just a small change to move setting the logger to after the imports. I think this applies to a couple other files

Sounds good! I have moved all logger to after the imports in the latest commit. Some of the model drivers now raise an error which will bubble up to get_model_cur_expt_time() in build_job_info(), so logger is no longer needed and removed in those.

jo-basevi · 2026-03-20T05:32:25Z

payu/models/accessom2.py

+                        return cftime.datetime.strptime(time_str, '%Y-%m-%dT%H:%M:%S')
+
+        logger.debug(f"cur_exp-datetime not found in {log_path}")
+        return None


If catching exceptions higher up, could raise a ValueError here instead?

That makes so much more sense. Thanks!

jo-basevi · 2026-03-20T05:33:44Z

payu/models/model.py

+        logger.debug("Current experiment time not implemented for this model.")
+        return None


could raise NotImplementedError("Current experiment time not implemented for this model.")?

Sounds good. I have improved this in the latest commit.

jo-basevi · 2026-03-20T05:43:10Z

payu/models/mom6.py

+            3: "proleptic_gregorian",
+            4: "noleap"
+        }
+        return cftime_calendars[calendar_int]


Could move this function to the mom_mixin.py class to keep the ocean_solo.res logic together? Then the CFTIME_CALENDARS can be a global variable used by both get_restart_datetime and get_calendar

Sounds good! It does make the code much cleaner.

jo-basevi · 2026-03-20T05:43:44Z

payu/models/mom6.py

+            logger.debug(f"date_init not found in {input_path}")
+            return None


Could raise another ValueError here?

Sounds good. Implemented in the latest commit.

jo-basevi · 2026-03-20T06:16:37Z

payu/subcommands/status_cmd.py

-                                config_path=config_path)
-            metadata.setup()
+            expt = Experiment(lab, config_path=config_path)
+            expt.init_models()


Suggested change

expt.init_models()

No need to run this as init_models() is already run as part of Experiment initialisation.

Oh I see. Thanks for pointing this out :)

jo-basevi · 2026-03-20T06:21:21Z

payu/subcommands/status_cmd.py

        )

    if json_output:
        print(json.dumps(data, indent=4))


If adding current experiment time to the json and the formatted display then it might make sense to add it in build_job_info() to reduce duplication and use status == model-run

jo-basevi · 2026-03-20T06:23:01Z

payu/telemetry.py

+            timings: Optional[dict[str, Any]] = None,
+            cur_expt_time: Optional[str] = None


Suggested change

timings: Optional[dict[str, Any]] = None,

cur_expt_time: Optional[str] = None

timings: Optional[dict[str, Any]] = None

This code can safely be removed now I think

jo-basevi · 2026-03-20T06:34:12Z

payu/models/model.py

+    def get_cur_expt_time(self):
+        """For model not implemented experiment time calculate/read-out,
+        leaves a warning and returns None."""
+        print("Getting current experiment time is not yet implemented.")


I think that could work. We don't have command-line flags currently that enables debug logging easily however. I think there was some talk about that in this issue: #673.
As this PR already has a number of changes, an option could be to use warnings now and then change it in a future PR?

jo-basevi · 2026-03-20T06:46:32Z

payu/status.py

+                cur_expt_time = None
+                try:
+                    cur_expt_time = expt.get_model_cur_expt_time()
+                except (FileNotFoundError, IndexError, OSError, json.JSONDecodeError, UnboundLocalError) as e:


What causes the UnboundLocalError?

There was somewhere that could potentially call cur_expt_time before assigning. But I think it has been changed now. I have removed UnboundLocalError in the lates commit.

…build_job_info; raise error and bubble up in build_job_info.

Qian-HuiChen · 2026-03-23T01:02:43Z

If adding current experiment time to the json and the formatted display then it might make sense to add it in build_job_info() to reduce duplication and use status == model-run

Thanks @jo-basevi. It sounds good! I have moved the calling of get_model_cur_expt_time into build_job_info().

blimlim

Thanks @Qian-HuiChen for putting in those changes, they're looking really good! I've just had another read through, and added some small comments

blimlim · 2026-03-23T04:19:48Z

payu/models/um.py

 import os
 import shutil
 import string
+import cftime


It looks like this one isn't directly being used!

Good catch! Thanks :)

blimlim · 2026-03-23T04:49:01Z

payu/models/um.py

+        """Get the current experiment time from file"""
+        log_path = os.path.join(self.expt.work_path, 'atmosphere', 'atm.fort6.pe0')
+
+        start_date = self.get_restart_datetime(self.expt.work_path + '/atmosphere')


Probably just being a bit pedantic here, but it could be worth consistently using os.path.join as with the log_path = line further above

Sounds good to keep it consistent.

blimlim · 2026-03-23T04:51:23Z

payu/models/model.py

+
+        Returns:
+        --------
+        Current experiment time in string (e.g., 1900-01-01T01:00:00)


With the latest changes, the docstring can be updated to specify that it returns a cftime.datetime rather than string

Good catch! Thanks :)

payu/models/access_esm1p6.py

blimlim · 2026-03-23T05:47:34Z

payu/subcommands/status_cmd.py

        )

    if json_output:
        print(json.dumps(data, indent=4))


While testing this out I just noticed that payu status --json also doesn't print out the model finish time after the run has completed:

pay======================================== Run: 0 Job ID: 163732205.gadi-pbs Run ID: cd891450d95f0b8454f880b80bbb9fed40c034b4 Stage: archive Total queue time: 0h 1m 27s Model Finish Time: 0001-01-06T00:00:00 Exit Status: 0 (Success) Model Exit Code: 0 (Success) Output Log: /home/565/sw6175/esm1.6/misc/gettime-test/pre-industrial.o163732205 Error Log: /home/565/sw6175/esm1.6/misc/gettime-test/pre-industrial.e163732205 Job File: /scratch/tm70/sw6175/access-esm/archive/gettime-test-dev-preindustrial+concentrations-d33399d8/payu_jobs/0/run/163732205.gadi-pbs.json ======================================== u(payu-env) [sw6175@gadi-login-01 gettime-test]$ payu status --json { "experiment_uuid": "d33399d8-053d-4eb6-aa5b-2b7e0ff783e5", "runs": { "0": { "run": [ { "job_id": "163732205.gadi-pbs", "run_id": "cd891450d95f0b8454f880b80bbb9fed40c034b4", "stage": "archive", "exit_status": 0, "model_exit_status": 0, "stdout_file": "/home/565/sw6175/esm1.6/misc/gettime-test/pre-industrial.o163732205", "stderr_file": "/home/565/sw6175/esm1.6/misc/gettime-test/pre-industrial.e163732205", "job_file": "/scratch/tm70/sw6175/access-esm/archive/gettime-test-dev-preindustrial+concentrations-d33399d8/payu_jobs/0/run/163732205.gadi-pbs.json", "start_time": "2026-03-23T16:23:21.697106" } ] } } }

I'm wondering whether it would also work to add the finish time in build_job_info(), though I don't think I properly understand yet how the finish time is set.

blimlim · 2026-03-23T22:47:08Z

test/models/test_mom6.py


 import pytest
 import f90nml
+import logging


I think this one might not be needed here

Good catch! Thanks :)

blimlim · 2026-03-23T23:07:46Z

test/models/test_mom6.py

+        cur_expt_time = expt.get_model_cur_expt_time()
+
+
+def test_read_start_date(caplog):


Just wanted to check if the caplog fixture is required here, and similarly for test_read_timestep

Yeah it was used in previous versions but the new tests didn't use caplog anymore. I removed them now.

blimlim · 2026-03-23T23:29:21Z

test/models/test_um.py

 import cftime
 import yaml
+import f90nml
+import logging


It looks like these two aren't currently being used

Good catch! Thanks :)

blimlim · 2026-03-23T23:29:52Z

test/models/test_um.py

    parsed_run_dt = expt.model.get_restart_datetime(restart_path)
    assert parsed_run_dt == date
+
+def test_convert_timestep(caplog):


It looks like caplog isn't currently being used here and could be removed from the test

Good catch! Thanks :)

blimlim · 2026-03-23T23:52:49Z

payu/models/access_esm1p6.py

+    def get_cur_expt_time(self):
+        """ Use UM submodel to get the current experiment time."""
+        model_types = ['um']
+        return self.get_cur_expt_time_using_submodel(model_types)
+


Probably not super important as people will be moving to ESM1.6, however since ESM1.5 also uses the UM, it would be simple to add this feature to it. I think it would just involve copying these lines into access.py

I have implemented this in access-esm1.5 in the latest commit.

Qian-HuiChen requested a review from jo-basevi March 12, 2026 03:11

Qian-HuiChen added 2 commits March 13, 2026 09:33

Display current expt time for running jobs and model finish time for …

479d029

…archived jobs.

Update the test for access.py

2896232

Qian-HuiChen force-pushed the 701-model-run-time branch from 7d79a8a to 2896232 Compare March 12, 2026 22:34

Qian-HuiChen requested review from anton-seaice and blimlim March 15, 2026 21:46

blimlim reviewed Mar 17, 2026

View reviewed changes

anton-seaice reviewed Mar 18, 2026

View reviewed changes

anton-seaice mentioned this pull request Mar 18, 2026

Monitoring a simulation ACCESS-NRI/access-om3-configs#514

Open

jo-basevi reviewed Mar 18, 2026

View reviewed changes

Use a higher level exception; return cftime object; move ESM1p6 get_c…

75761ba

…ur_expt_time to um; log error at debug level.

Qian-HuiChen added 3 commits March 20, 2026 12:11

Import logger; handle error in possibly using cur_expt_time before as…

6d091b8

…signing.

Update pytest for OM3 handling error

df1f039

MOM6: use timestamps in ocean.stats to calculate the current model time.

f3c1025

jo-basevi reviewed Mar 20, 2026

View reviewed changes

Tidy up some part of the code: moving get_model_cur_expt_time inside …

669493e

…build_job_info; raise error and bubble up in build_job_info.

blimlim reviewed Mar 24, 2026

View reviewed changes

Clean up some imports; add model_finis_time to status --json.

b50a431

		logger.debug("Current experiment time not implemented for this model.")
		return None

		logger.debug(f"date_init not found in {input_path}")
		return None

		timings: Optional[dict[str, Any]] = None,
		cur_expt_time: Optional[str] = None

		cur_expt_time = expt.get_model_cur_expt_time()


		def test_read_start_date(caplog):

Conversation

Qian-HuiChen commented Mar 12, 2026

Uh oh!

codecov bot commented Mar 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Qian-HuiChen commented Mar 15, 2026

Uh oh!

jo-basevi commented Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

blimlim left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anton-seaice Mar 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anton-seaice commented Mar 18, 2026

Uh oh!

jo-basevi left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anton-seaice commented Mar 18, 2026

Uh oh!

Qian-HuiChen commented Mar 20, 2026

Uh oh!

jo-basevi left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

codecov bot commented Mar 12, 2026 •

edited

Loading

jo-basevi commented Mar 17, 2026 •

edited

Loading

anton-seaice Mar 18, 2026 •

edited

Loading