output at flexible time levels by guoqing-noaa · Pull Request #217 · ufs-community/MPAS-Model

guoqing-noaa · 2026-02-24T06:06:12Z

Introduce a new output_timelevels attribute for MPAS streams that enables variable output intervals.

With this capability, we may outoput every 15 minutes in the first hour, every hour in the first 3 days, every 3 hours for the next 4 days, and every 6 hours in the last 3 days.

We can also use this to only write out forecast files during a given period, such as: output_timelevels="6-12h"

Check the PR description below for details on how to specify the time levles.
Here is a quick example: output_timelevels="0-3-15m 4-72 75-168-3 174-240-6"

FYI, with this PR, we may write out mpasout files at "0 1 2 3 6 9 12", while history files at "4 5 7 8 11 13-99999" to avoid duplicate output of both mpasout and history files at the same time levels, which are almost the same.

This PR solves issue #214

Priority Reviewers

…ttribute Introduce a new `output_timelevels` attribute for MPAS streams that enables variable output intervals. With this capability, we may outoput every 15 minutes in the first hour, every hour in the first 3 days, every 3 hours for the next 4 days, and every 6 hours in the last 3 days. We can also use this to only write out forecast files during a given period, such as: output_timelevels="6-12h" Check the PR description for details on how to specify the time levles. Here is a quick example: output_timelevels="0-3-15m 4-72 75-168-3 174-240-6"

guoqing-noaa · 2026-02-24T06:09:02Z

`output_timelevels` Specification

The forecast output times are defined by a space-separated list of sections:

<section> [section] [section] ...

Each section expands into one or more forecast times.
The final output is the union of all expanded times.
Users need to make sure the times are in a ascending order.

1. Time String Format

A time_string represents a forecast time (offset from the initialization time).
It may be written in one of the following forms:

1.1 Integer Forms (Hours)

An integer with no suffix represents hours:

6     → 6 hours
12    → 12 hours
0     → 0 hours

1.2. Integer With Unit Descriptors

A duration may be written using unit suffixes:

h  → hours
m  → minutes
s  → seconds
D  → days

Examples:

1h30m   → 1 hour 30 minutes
45m     → 45 minutes
90s     → 90 seconds
6h15m   → 6 hours 15 minutes

2. Sequence Expansion (Range Expression)

A section may define a regularly spaced sequence using:
start-stop-step
This generates values beginning at start, incremented by step, and ending at stop (inclusive if exactly reached).
Examples:

0-1h-15m

expands to:

0 15m 30m 45m 1h

If -step is omitted, a default step of 1 hour is used:
7-12 means 7-12-1 and expands to 7 8 9 10 11 12

Note: Integer and unit-based forms may be freely mixed

3. The EBNF (Extended Backus-Naur Form) style grammar:

specification   = section , { SP , section } ;

section         = range
                | time_string ;

range           = time_string , "-" , time_string , [ "-" , time_string ] ;
                  (* start-stop[-step] *)

time_string     = integer
                | duration ;

duration        = duration_part , { duration_part } ;

duration_part   = integer , unit ;

unit            = "h" | "m" | "s" | "D" ;

integer         = digit , { digit } ;

digit           = "0" | "1" | "2" | "3" | "4"
                | "5" | "6" | "7" | "8" | "9" ;

SP              = " " , { " " } ;

guoqing-noaa · 2026-02-24T06:10:09Z

The following situations have been tested:
Note: extra spaces were intentionally added to test whether this PR can handle them corrently.

output_timelevels="0  1     "
output_timelevels="0h  1h   "

output_timelevels="0-1-15m 2-6-2"
output_timelevels="2-6-2"
output_timelevels="2-6-2   8-999"
output_timelevels="2-6h-2   8-999h"

output_timelevels="0m 15m  1h    1h3m"
output_timelevels="0s 30s 15m  1h    1h3m"
output_timelevels="0m 30s 15m  1h    1h3m"

guoqing-noaa · 2026-02-24T07:11:46Z

For a conus12km 12 hours forecasts, I tried different settings for the da_state stream (no changes on the history and diag outputs)

the output_interval="1:00:00" run took 606s
the output_timelevels="0-999" run took 609s
This 3s cost saves more time due to the skipping of mpasout output at hours 4-12:
the output_timelevels="0-3" run took 549s

SamuelTrahanNOAA

These code changes are overcomplicated and will be difficult to extend or maintain. Any significant changes to the functionality will require a complicated rewrite.

More specific overview comments:

Most of the parser code is a reimplementation of the Fortran standard split function. It would be better to call split.
Much of the time-related code reimplements the MPAS and ESMF alarm functionality. It would be better to extend the alarm functionality.
Parser errors aren't reported. If you type something wrong, you don't know what it was.
There are out-of-bounds array reads due to off-by-one errors.
The new syntax deviates from the MPAS days_HH:MM:SS time specification.
Unlike the rest of the MPAS I/O interface, this uses a cryptic string instead of XML tags. If you used XML tags, the parser code wouldn't be necessary at all.

src/framework/mpas_stream_manager.F

SamuelTrahanNOAA · 2026-02-24T19:31:31Z

The EBNF (Extended Backus-Naur Form) style grammar

If you want to use a parser generator, the original grammar specification should be in the repository, not the automatically-generated code.

guoqing-noaa · 2026-02-24T20:24:14Z

The EBNF (Extended Backus-Naur Form) style grammar

If you want to use a parser generator, the original grammar specification should be in the repository, not the automatically-generated code.

No, I don't intend to use a parser generator. I put EBNF there to make sure the overall timelevel specification logic is consistent and complete, and there are no hidden surprises.

guoqing-noaa · 2026-02-24T20:32:56Z

These code changes are overcomplicated and will be difficult to extend or maintain. Any significant changes to the functionality will require a complicated rewrite.

More specific overview comments:

Most of the parser code is a reimplementation of the Fortran standard split function. It would be better to call split.

Much of the time-related code reimplements the MPAS and ESMF alarm functionality. It would be better to extend the alarm functionality.

Parser errors aren't reported. If you type something wrong, you don't know what it was.

There are out-of-bounds array reads due to off-by-one errors.

The new syntax deviates from the MPAS days_HH:MM:SS time specification.

Unlike the rest of the MPAS I/O interface, this uses a cryptic string instead of XML tags. If you used XML tags, the parser code wouldn't be necessary at all.

@SamuelTrahanNOAA Thanks for the comments and discussions!

This is the first version to get things work. I also feel the implementation is kind of complicated and I would like to descope to meet our current needs only. My thought is to limit the timelevel specifications to only support minutes and hours (may also limit the output to have to start at 0h).

I intentionally try to avoid using the same time format HH:MM:SS used in output_interval.
start-stop[-step] is the most appropriate format after lots of considerations. It is more user friendly. start-stop is used in lots of industry applications (I just added the [-step] part)

SamuelTrahanNOAA · 2026-02-24T20:42:14Z

I put EBNF there to make sure the overall timelevel specification logic is consistent and complete, and there are no hidden surprises.

It is, indeed, a finely-polished EBNF with perfect indentation. However, it doesn't describe the code. Your read statement reads a real, not an integer.

SamuelTrahanNOAA · 2026-02-24T20:56:38Z

start-stop[-step] is the most appropriate format after lots of considerations. It is more user friendly. start-stop is used in lots of industry applications (I just added the [-step] part)

What is more user-friendly is splitting them into individual XML tags so it is clear what is going on. That would use the existing MPAS parsing code (eliminating the parser). Also, it'll be less confusing to experienced MPAS users.

<output_interval start="01:15:00" stop="02:30:00" step="00:15:00"/> <!-- every 15 minutes from 1:15 to 2:30 -->
<output_interval start="06:00:00"/> <!-- Only at hour 6 -->

I can see how your string would be easier to pass through the rrfs-workflow bash scripts, but bash limitations shouldn't take precedence over MPAS code consistency and quality.

SamuelTrahanNOAA · 2026-02-24T21:01:42Z

Can you please provide:

Documentation of what part of the code was AI-generated. (Via code comments, perhaps.)
Documentation of what part of the PR description and comments were AI-generated.
Explanation of how it was generated.
License restrictions the AI company placed on its generated code, description, and comments.

guoqing-noaa · 2026-02-24T21:05:09Z

@clark-evans I am sorry, this may not be ready for an official review yet. I should have put this in the draft mode since the beginning.

guoqing-noaa · 2026-02-24T21:06:10Z

<output_interval start="01:15:00" stop="02:30:00" step="00:15:00"/> <!-- every 15 minutes from 1:15 to 2:30 -->
<output_interval start="06:00:00"/> <!-- Only at hour 6 -->

This looks good. Does current MPAS code support this?

SamuelTrahanNOAA · 2026-02-24T21:07:49Z

This looks good. Does current MPAS code support this [xml alternative in Sam's prior comment]?

No. I'm suggesting it as an alternative implementation to your recursive descent parser.

guoqing-noaa · 2026-02-24T21:23:43Z

@SamuelTrahanNOAA Thanks for lots of great discussions! For the moment, this PR is mainly for a test/demo purpose.
Appreciate your specific comments so far. But we may pause further reviewing. This will NOT be the final implementation if moving forward. General discussions may continue if your are interested and have time to think about more on this.

I think my initial need is much simpler that the goal in this PR. We want to output mpasout files only at limited time levels (such as 01, 02 h (or including 0h if needed)).
My thought went much further than needed, mainly driven by my latest relevant work on the rrfs-workflow side.

For our current needs, I think NCAR Andy Stokely's changes may work. I will test that first. I was not aware of Andy's changes until 2 days ago.

SamuelTrahanNOAA · 2026-02-24T21:36:02Z

WRF was limited to start...step...end for each stream. We were able to work around that by having multiple output streams. (Recall that the operational models HRRR, HWRF, NAM, and RAP were all WRF-based, along with other quasi-operational models.)

dustinswales · 2026-03-10T17:39:21Z

@guoqing-noaa @SamuelTrahanNOAA
FWIW. To control output frequency for MPAS in the UFS we are using output_fh for native MPAS output, which could be configured to handle the need here.

For example, output_fh = 0.2 0.4 0.6 0.8 1 2 3 6 9 12, would provide output every 12min for the first hour, every hour for the next three hours, and every three hours for the remainder of the simulation.

guoqing-noaa · 2026-03-10T17:50:02Z

@guoqing-noaa @SamuelTrahanNOAA FWIW. To control output frequency for MPAS in the UFS we are using output_fh for native MPAS output, which could be configured to handle the need here.

For example, output_fh = 0.2 0.4 0.6 0.8 1 2 3 6 9 12, would provide output every 12min for the first hour, every hour for the next three hours, and every three hours for the remainder of the simulation.

@dustinswales It is good to know this capability in UFS.
A few questions:

MPAS will compute the output interval automatically and use the latest value if no more new intervals and so we don't need to specify all time levels to the end of the forecast, right?
But how output_fh handles the situation "every 15 minutes in the first hour, every hour in the first 3 days (to 72h), every 3 hours for the next 4 days (up to 168hours), and every 6 hours in the last 3 days (up to 240h)"?
UFS output will only consider weather simulation and not climate simulation which may cover many years?
UFS output skips all the src/framework part and does not use streams, right?

Thanks!

dustinswales · 2026-03-10T21:12:43Z

MPAS will compute the output interval automatically and use the latest value if no more new intervals and so we don't need to specify all time levels to the end of the forecast, right?
But how output_fh handles the situation "every 15 minutes in the first hour, every hour in the first 3 days (to 72h), every 3 hours for the next 4 days (up to 168hours), and every 6 hours in the last 3 days (up to 240h)"?

I believe output_fh would be just need to be really long in this case,output_fh: 0.25 0.50 0.75 1 2 3 4 5 .... 72 75 78 .... 168 174 180 ... 240. I'm sure we could find a way to distill this information if it become a pain.

UFS output will only consider weather simulation and not climate simulation which may cover many years?

This is mostly true.
Folks have run S2S experiments, ~months-to-year, but I expect that their output was on some regular interval that was straightforward to configure.

UFS output skips all the src/framework part and does not use streams, right?

This is going to be the biggest change for Standalone users when moving to inline MPAS.

We use the MPAS framework for native input/output, but we do not use the MPAS stream manager as is done in MPAS standalone.
Instead, we use the pieces from MPAS stream manager that we need, like MPAS_readstream and MPAS_writesteam, to read/write data to/from the MPAS streams. These streams are defined within the MPAS subdriver, in addition to the Registry.xml file.

SamuelTrahanNOAA · 2026-03-10T21:44:51Z

FYI: NOAA GSL doesn't do climate or seasonal research. Hence, the capability to output on multi-week timescales won't affect our work. It is a good question to ask, though, since others in NOAA do seasonal forecasts. I'd expect forecasts out to 90 days for some applications, just not ours. (I just wanted to clarify things since the word "climate" showed up in discussion.)

guoqing-noaa · 2026-03-13T18:26:36Z

I believe output_fh would be just need to be really long in this case,output_fh: 0.25 0.50 0.75 1 2 3 4 5 .... 72 75 78 .... 168 174 180 ... 240. I'm sure we could find a way to distill this information if it become a pain.

@dustinswales I think it is totally fine to enumerate all output hours inside the model. However, it will be very beneficial for users for specify this using a simplified interface, for example, output_fh="0-3-0.25 4-72-1 75-168-3 174-240-6".

guoqing-noaa · 2026-03-24T16:30:30Z

src/framework/mpas_stream_manager.F

+                   ! Use actual write time for filename (each output gets unique file)
+                   call mpas_get_time(writeTime, dateTimeString=time_string)
+                   call mpas_expand_string(time_string, blockID, stream % filename_template, temp_filename)
+               else if ( stream % filename_interval /= 'none' ) then


Lines 3342-3346: same as lines 3263-3267, but handle the situation when a stream has been created (and no need to start from scratch)

guoqing-noaa · 2026-03-24T16:40:45Z

src/framework/mpas_stream_manager.F

+              else
+                  call mpas_set_timeInterval(filename_interval, timeString=stream % filename_interval)
+                  call mpas_build_stream_filename(stream % referenceTime, filenameTime, filename_interval, stream % filename_template, blockID_local, test_filename, ierr=local_ierr)
+              end if


Lines 3777-3960: all these changes are in read_stream(...). It allows we read a stream correctly for an input/output stream with output_timelevels configured.

guoqing-noaa · 2026-03-24T16:42:10Z

src/framework/mpas_stream_manager.F

+               ! Use actual time for filename
+               call mpas_get_time(now_time, dateTimeString=when_string, ierr=err_local)
+               call mpas_expand_string(when_string, blockID_local, streamCursor % filename_template, filename)
+           else if ( streamCursor % filename_interval /= 'none' ) then


Lines 4191-4195: similar as before, now in mpas_get_stream_filename(...)

guoqing-noaa · 2026-03-24T16:43:28Z

src/framework/mpas_stream_manager.F

            ! Write output_interval to stream
            !
-            IF (stream %filename_interval(1:4) /= "none") THEN
+            IF (stream %filename_interval(1:4) /= "none" .and. stream %filename_interval /= "output") THEN


If we use output_timelevels, we don't have a fix output_interval, so skip writing output_interval to stream

guoqing-noaa · 2026-03-24T16:47:10Z

src/framework/mpas_stream_manager.F

+            ierr = 1
+        end if
+
+    end subroutine parse_all_timelevels!}}}


lines 6037-6123: Parse the entire output_timelevels string into a timelevel_spec structure
This is a helper function and rewritten using mpas_split_string(...). I hope it is much easier to read now.

guoqing-noaa · 2026-03-24T16:49:18Z

src/framework/mpas_stream_manager.F

+            return
+        end if
+
+    end subroutine parse_time_string!}}}


lines 6126-6215: This is also a helper function.
Parses time strings like "1h30m", "45m", "6", "90s", "1d" into total minutes
Supported units: d/D (days), h (hours), m (minutes), s (seconds)
Plain integers without units are interpreted as hours

guoqing-noaa · 2026-03-24T16:50:50Z

src/framework/mpas_stream_manager.F

+                               'expected format is start-stop-step, but appears to be start-step-stop', MPAS_LOG_ERR)
+        end if
+
+    end subroutine parse_output_timelevel_spec!}}}


lines 6218-6341: This is also a helper function.
Parses a single segment using format: start, start-stop, or start-stop-step
Time strings can be integers (hours) or duration format (e.g., "1h30m", "45m")
Examples: "6", "0-3", "0-1h-15m", "1h30m-2h-15m"

guoqing-noaa · 2026-03-24T16:54:17Z

src/framework/mpas_stream_manager.F

+            ierr = MPAS_STREAM_MGR_ERROR  ! Signal no more output
+        end if
+
+    end subroutine get_output_interval_from_timelevels!}}}


lines 6344-6441: this is also a helper function:
Given a pre-parsed timelevel_spec and current forecast hour, determines the appropriate output interval in minutes. It handles both the situations of itemized timelevels or time level ranges.

guoqing-noaa · 2026-03-24T16:55:20Z

src/framework/mpas_stream_manager.F

+            ierr = MPAS_STREAM_MGR_ERROR  ! No future ranges
+        end if
+
+    end subroutine get_next_timelevel_start!}}}


lines 6444-6502: a helper function again.
Given a time levels string and current forecast hour, finds the start hour of the next timelevel range (if any). Returns -1 if no future ranges exist.

guoqing-noaa · 2026-03-24T16:57:09Z

src/framework/mpas_stream_manager.F

+
+        if (present(ierr)) ierr = local_ierr
+
+    end subroutine update_variable_output_alarm!}}}


lines 6505-6597: This is the core function of this PR, update_variable_output_alarm
It updates a variable output alarm after it has rung by:

Checking if the stream uses output_timelevels (via timelevel_spec)

Calculating current forecast hour (current time - start time)

Getting the next interval from get_output_interval_from_timelevels

Removing the old alarm and creating a new one with the updated interval

guoqing-noaa · 2026-03-24T17:02:28Z

src/framework/mpas_stream_manager.F

+        ierr_c = 1
+    end if
+
+end subroutine stream_mgr_add_variable_output_alarm_c !}}}


lines 7022-7166: This part provides two functions stream_mgr_set_property_c and stream_mgr_add_variable_output_alarm_c for the xml_stream_parser.c‎ to use at the beginning time when read the streams.atmosphere XML file: decode the output_timelevles part, set the stream properties and create an initial alarm if output_timelevles is defined.

guoqing-noaa · 2026-03-24T17:10:10Z

src/framework/xml_stream_parser.c

+					*status = 1;
+					return;
+				}
+				snprintf(msgbuf, MSGSIZE, "        %-20s%s", "output alarm:", "variable (from output_timelevels)");


The changes on xml_stream_parser.c are more straightforward, most are copy and paste and then minor changes to match the output_timelevels situation. Feel free to add comments for any questions.

In a nutshell, this PR attaches to the main code base a new orphan island, which does not affect any existing capabilities if output_timelevels is not used. When output_timelevels is used, it enables the capability to output at flexible time levels.

SamuelTrahanNOAA

I wouldn't approve this for merge to the NCAR authoritative MPAS, but I am willing to approve it for merge to the GSL branch as a temporary workaround. GSL JEDI/MPAS data assimilation development needs this feature, and we can't stall much longer. This is our only available solution, it works, and the fork will probably still be manageable.

Note that the UFS MPAS has a totally different I/O subsystem, so it will replace this workaround eventually.

My objections are:

The overall length and complexity of the changes will make it harder to maintain the fork.
Using a custom string format necessitates an over-complicated parser since Fortran is ill-suited as a string processing language.
A string list instead of XML tags deviates from the MPAS design in a way that reduces flexibility and end-user understandability.
The implementation restricts the number of output time specifications to a fixed number rather than using proper data storage, such as a linked list.
Sending the output intervals from C to Fortran after the rest of the tag adds lots of code to send that information later. Had the output interval been sent at the same time as the other attributes, this would have been much shorter.

clark-evans · 2026-04-06T04:27:50Z

@guoqing-noaa we'll provide a status update on this at the 4/6 RFS meeting.

Re: the changes to mpas_stream_manager.F, what do you think about potentially moving some or all of the new subroutines (I counted eight new subroutines) into a new, separate file that is linked in at compile time? I think the new parsing subroutines might be good candidates for this. This would be akin to mpas_sort.F, which separates out search and sort subroutines, and mpas_string_utils.F, which provides a couple of Fortran string utilities; both of these are in src/framework/.

guoqing-noaa · 2026-04-06T05:18:38Z

@guoqing-noaa we'll provide a status update on this at the 4/6 RFS meeting.

Re: the changes to mpas_stream_manager.F, what do you think about potentially moving some or all of the new subroutines (I counted eight new subroutines) into a new, separate file that is linked in at compile time? I think the new parsing subroutines might be good candidates for this. This would be akin to mpas_sort.F, which separates out search and sort subroutines, and mpas_string_utils.F, which provides a couple of Fortran string utilities; both of these are in src/framework/.

That's a good suggestion and doable. I will try to update it by the end of tomorrow. Thanks!

joeolson42

I admit this is an abbreviated review, but at a superficial glance, for a temporary solution, it looks OK.

guoqing-noaa · 2026-04-06T15:29:44Z

@clark-evans I moved 6 subroutines from mpas_stream_manager.F to a new file mpas_output_timelevels.F.

stream_mgr_add_variable_output_alarm_c and stream_mgr_set_property_c are not able to be moved. They use mpas_stream_manager and at the same time, mpas_stream_manger.F use mpas_output_timelevels. If moved, it will create a circular compilation dependency.

guoqing-noaa · 2026-04-06T15:37:56Z

I have tested the new updates and worked as expected for the previous test cases.

clark-evans · 2026-04-06T15:38:15Z

@clark-evans I moved 6 subroutines from mpas_stream_manager.F to a new file mpas_output_timelevels.F.

stream_mgr_add_variable_output_alarm_c and stream_mgr_set_property_c are not able to be moved. They use mpas_stream_manager and at the same time, mpas_stream_manger.F use mpas_output_timelevels. If moved, it will create a circular compilation dependency.

Thanks, @guoqing-noaa! I'll give it all a look-through today (hopefully).

clark-evans

I concur with @SamuelTrahanNOAA and @joeolson42 reviews. Moving most of the new functions to a new mpas_output_timelevels.F file is a big help for maintaining the code base, particularly if/when NCAR provides a suitable native implementation of this functionality. I'd like @dustinswales to review before merging, though.

dustinswales

@guoqing-noaa Thanks for this contribution!
This is quite complicated and there is a lot of code to review, so it would be good to add a new test, or extend an existing test(?), that exercises this functionality.
Going forward we should ensure that any new functionality developed is added to our testing harness, otherwise we won't know if it works, or if/when it breaks.

guoqing-noaa · 2026-04-07T15:12:35Z

@dustinswales Thanks for the great suggestion!
Can we add a test in a new PR? I need time to get familiar with the test structure in this repo and I don't think I can finish it in one week.
Can we merge this PR to facilitate upcoming SFE use if this capability does NO harm to any existing capability?
I'm creating an issue first to put this on the radar. Thanks!

dustinswales

@guoqing-noaa That works for me.
It's pretty straightforward, so maybe I can take a stab at it sometime this week.

guoqing-noaa · 2026-04-07T15:44:09Z

@guoqing-noaa That works for me. It's pretty straightforward, so maybe I can take a stab at it sometime this week.

@dustinswales Thanks a lot for being flexible!
It will be great if you can help with the test.

For information, in most of my tests, I used the following settings:

output_timelevels="1-3 5" for the output stream
output_timelevels="0m 15m 1h 2-999-2" for the diagnostics stream

I have a PR coming soon which will add a new stream attribute output_done_marker="yes" (default to no). I think we may combine them together in one test. Thanks!

guoqing-noaa requested review from clark-evans and dustinswales as code owners February 24, 2026 06:06

guoqing-noaa changed the title ~~Enable variable output intervals via the output_timelevels stream attrbute~~ output at flexible time levels Feb 24, 2026

SamuelTrahanNOAA requested changes Feb 24, 2026

View reviewed changes

clark-evans requested review from AndersJensen-NOAA and joeolson42 February 24, 2026 21:02

guoqing-noaa marked this pull request as draft February 24, 2026 21:05

clark-evans mentioned this pull request Feb 25, 2026

Containerized CI + Cleanup testing #218

Merged

Merge branch 'gsl/develop' into flexible_timelevels4gsl

dea393e

Merge branch 'gsl/develop' into flexible_timelevels4gsl

18fb058

guoqing-noaa commented Mar 24, 2026

View reviewed changes

guoqing-noaa mentioned this pull request Mar 26, 2026

Add two new namelist options to control the hydrometeors to be included in the LBC files. #234

Merged

SamuelTrahanNOAA approved these changes Mar 26, 2026

View reviewed changes

Merge branch 'gsl/develop' into flexible_timelevels4gsl

ae43ebf

Merge branch 'gsl/develop' into flexible_timelevels4gsl

c79b641

joeolson42 approved these changes Apr 6, 2026

View reviewed changes

move 6 subroutines to mpas_output_timelevels.F

beeb723

clark-evans approved these changes Apr 7, 2026

View reviewed changes

dustinswales requested changes Apr 7, 2026

View reviewed changes

guoqing-noaa mentioned this pull request Apr 7, 2026

create a test for the flexible output_timelevels capability #241

Open

dustinswales self-requested a review April 7, 2026 15:22

dustinswales approved these changes Apr 7, 2026

View reviewed changes


		if (present(ierr)) ierr = local_ierr

		end subroutine update_variable_output_alarm!}}}

Conversation

guoqing-noaa commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Priority Reviewers

Uh oh!

guoqing-noaa commented Feb 24, 2026

output_timelevels Specification

1. Time String Format

1.1 Integer Forms (Hours)

1.2. Integer With Unit Descriptors

2. Sequence Expansion (Range Expression)

3. The EBNF (Extended Backus-Naur Form) style grammar:

Uh oh!

guoqing-noaa commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

guoqing-noaa commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SamuelTrahanNOAA left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

SamuelTrahanNOAA commented Feb 24, 2026

Uh oh!

guoqing-noaa commented Feb 24, 2026

Uh oh!

guoqing-noaa commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SamuelTrahanNOAA commented Feb 24, 2026

Uh oh!

SamuelTrahanNOAA commented Feb 24, 2026

Uh oh!

SamuelTrahanNOAA commented Feb 24, 2026

Uh oh!

guoqing-noaa commented Feb 24, 2026

Uh oh!

guoqing-noaa commented Feb 24, 2026

Uh oh!

SamuelTrahanNOAA commented Feb 24, 2026

Uh oh!

guoqing-noaa commented Feb 24, 2026

Uh oh!

SamuelTrahanNOAA commented Feb 24, 2026

Uh oh!

dustinswales commented Mar 10, 2026

Uh oh!

guoqing-noaa commented Mar 10, 2026

Uh oh!

dustinswales commented Mar 10, 2026

Uh oh!

SamuelTrahanNOAA commented Mar 10, 2026

Uh oh!

guoqing-noaa commented Mar 13, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

guoqing-noaa Mar 24, 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

guoqing-noaa commented Feb 24, 2026 •

edited

Loading

`output_timelevels` Specification

guoqing-noaa commented Feb 24, 2026 •

edited

Loading

guoqing-noaa commented Feb 24, 2026 •

edited

Loading

guoqing-noaa commented Feb 24, 2026 •

edited

Loading

guoqing-noaa Mar 24, 2026 •

edited

Loading

guoqing-noaa Mar 24, 2026 •

edited

Loading

guoqing-noaa commented Apr 7, 2026 •

edited

Loading