Add the CF-compliant time variable in the test case

[wenshanw]

Added the CF-compliant time variable in the test case with the calendar attribute

[xylar]

@wenshanw, following up on our chat on Wednesday, here is how I would suggest setting the units of Time for now. Let's not worry about a different reference time than simulationStartTime for now. That will work.

I haven't figured out a way to replace an attribute. MPAS can add them or get them. We could obviously add this capability but it would be much easier to just not set the units attribute for Time in the registry and instead add it later.

Time is getting set up once at init in ocn_forward_mode_init and then once per time step in ocn_timestep, which seems right. We only need to set the units attribute for Time in ocn_forward_mode_init.

To do this, we would:

1. get simulationStartTime and convert the _ to spaces.
2. make a units string (character array) that is days since <simulationStartTime> where you put in the string from above. Presumably, this is something like write(units, '(a2)') 'days since ', simulationStartTime but as I said I'm not good with Fortran strings so you'll have to do some Googling and figure it out.
3. Add the attribute, which involves getting the TimeField and not just the pointer to the Time value.

      real (kind=RKIND), pointer :: Time
      type (field0DReal), pointer :: TimeField
...
      character (len=StrKIND) :: units

...

         ! do your magic to get units here
         call mpas_pool_get_Field(diagnosticsPool, 'Time', TimeField)
         call mpas_add_att(TimeField % attLists(1) % attList, 'units', units)

[xylar]

@wenshanw, I don't think we want these as general variables. They already exist in the time-series stats analysis member and I don't think they make sense anywhere else. All other output is a snapshot so there is no start and end time.

[wenshanw]

Sure, I will remove them in my next commit (I didn't intend to include them in this commit...)

[xylar]

Okay, sounds good. Just happened to see that and figured it might save you some time...

[mark-petersen]

@xylar and I spoke about this today. The main problem is that each stream needs to write Time and time_bnds with different values. I think a possible approach is to add it to the streams object itself. Here:

src/framework/mpas_io_streams_types.inc
 49    type MPAS_Stream_type
 50       logical :: isInitialized = .false.
 51       integer :: ioFormat
 52       integer :: ioDirection
 53       integer :: defaultPrecision = MPAS_IO_NATIVE_PRECISION
 54       logical :: clobberRecords = .false.
 55       ! When blockWrite is true, a stream only writes a single block.
 56       ! This option is really only useful for writing debugging streams out.
 57       logical :: blockWrite = .false.
 58       character(len=StrKIND) :: filename
 59       type (MPAS_IO_Handle_type) :: fileHandle
 60       type (att_list_type), pointer :: attList => null()
 61       type (field_list_type), pointer :: fieldList => null()
 62    end type MPAS_Stream_type

We could add
logical :: writeCFCompliantTime = .false.
real :: time_bnds(2)
real :: Time (need to think about that one - maybe use different name)

Uninterested cores could leave it default off. It could be specified in the stream file with

<stream name="timeSeriesStatsMonthlyRestart"
        TimeInFile="standard" or "CFCompliant" to turn it on

or something similar.

If it turned on, then write Time and time_bnds with the netcdf compliant format - that would be a change to mpas_io_streams.F.

Then in an analysis member we can access the stream associated with the AM, and set the time_bnds for that stream ourselves.

The fundamental issue this works around is that the variable time_bnds is not in those listed in the streams file for each stream, which would be a global variable. It is stream-by-stream, and we can access stream properties within MPAS routines.

[xylar]

time_bnds would be Time_bnds, just for clarity.

[xylar]

@mark-petersen, can you create a separate issue for discussing this so we can bring in Michael Duda and others that might be interested? I don't think they will want to discuss it in an ocean/develop PR.

[mark-petersen]

Yes. Give me a day, I'd like to experiment with the streams code so I can propose a good starting point.

[rljacob]

What is the status of this PR? We'd like this working for upcoming E3SM v2 simulations.

[xylar]

@rljacob, I'm afraid that is not going to be possible. This is another change that requires modification of the MPAS framework, and there isn't agreement among the developers yet about how this can be accomplished. We are working on it but the v2 deadline is impossible at this point.

[mark-petersen]

I agree that the V2 deadline is too short for framework changes. I do have two branches that make progress on this, and I will post more information today.

[xylar]

@mark-petersen, is this something you have time to pursue again? It would be great to get this fixed? Maybe we need to move over to E3SM with this work, though.

[xylar]

@mark-petersen, I'd like to have a chat with you about a process for revisiting this work and #677, now that we have moved to E3SM.

[mark-petersen]

see #665 (comment)