Write out valid time as a string in history files

[CoryMartin-NOAA]

Description

Currently, UFS write-grid component writes out valid time like so:

	double time(time) ;
		time:calendar = "JULIAN" ;
		time:calendar_type = "JULIAN" ;
		time:cartesian_axis = "T" ;
		time:long_name = "time" ;
		time:units = "hours since 2021-03-22 06:00:00" ;

This requires routines to compute the valid time using the value of time(t) and the unit string. These are in w3emc but is not a trivial thing to do without external libraries.

It would be nice to have something akin to the following added:

	char valid_time(time, nchars) ;
		valid_time:calendar = "JULIAN" ;
		valid_time:calendar_type = "JULIAN" ;
		valid_time:cartesian_axis = "T" ;
		valid_time:long_name = "valid time" ;
		valid_time:units = "ISO 8601 Date String" ;

So that one can easily grab: 2022-02-16T17:11:00Z
This will be useful for a few things, most notably 1) checking in FV3-JEDI that the valid time from a cubed-sphere history file is at the expected time and 2) having an easy variable for plotting model output.

Solution

Add a string representation of the model valid time to the history files.

Alternatives

Add an integer representation of the model valid time to the history files.

Related to

Adding cube-sphere history I/O to FV3-JEDI.

[DusanJovic-NOAA]

See these example files:

/scratch2/NCEPDEV/fv3-cam/Dusan.Jovic/ufs/valid_time/control_CubedSphereGrid/atmf000.nc
/scratch2/NCEPDEV/fv3-cam/Dusan.Jovic/ufs/valid_time/control_CubedSphereGrid/atmf006.nc
/scratch2/NCEPDEV/fv3-cam/Dusan.Jovic/ufs/valid_time/control_CubedSphereGrid/atmf012.nc
/scratch2/NCEPDEV/fv3-cam/Dusan.Jovic/ufs/valid_time/control_CubedSphereGrid/atmf024.nc
/scratch2/NCEPDEV/fv3-cam/Dusan.Jovic/ufs/valid_time/control_CubedSphereGrid/sfcf000.nc
/scratch2/NCEPDEV/fv3-cam/Dusan.Jovic/ufs/valid_time/control_CubedSphereGrid/sfcf006.nc
/scratch2/NCEPDEV/fv3-cam/Dusan.Jovic/ufs/valid_time/control_CubedSphereGrid/sfcf012.nc
/scratch2/NCEPDEV/fv3-cam/Dusan.Jovic/ufs/valid_time/control_CubedSphereGrid/sfcf024.nc

code is in this branch: https://github.com/DusanJovic-NOAA/fv3atm/tree/valid_time

[CoryMartin-NOAA]

@DusanJovic-NOAA thank you so much for a quick implementation, this is exactly what I was looking for!

Now I can remove a lot of julian day computations and just read the valid time string directly, this is perfect!

[DusanJovic-NOAA]

@CoryMartin-NOAA @aerorahul The unit attribute is not strictly correct, I think we should just use 'description' attribute for this variable. Also the name itself (valid_time) is a bit misleading. Variable 'time' is also valid time, it's just represented as number instead as text. so how about this:

	char time_iso(time, nchars) ;
		time_iso:long_name = "valid time" ;
		time_iso:description = "ISO 8601 Date String" ;

[CoryMartin-NOAA]

@DusanJovic-NOAA those changes work for me, you are right, both variables should give you the same time, it's just different formats/representations.

[DusanJovic-NOAA]

I updated the sample files (above) to use time_iso variable name. Please take a look.

[DusanJovic-NOAA]

I'm looking at the values of time and time_iso in the first (f000) history file, for example:

$ ncdump -t -v time,time_iso atmf000.nc     
netcdf atmf000 {
dimensions:
     . . .
data:

 time = "2021-03-22 06:12:0.000011" ;

 time_iso =
  "2021-03-22T06:12:00Z" ;
}

As you can see there's a slight difference, because this is not actually 00hr output but dt_atmos seconds after the initial time, which in this case is 720s or 12min. 720s when represented in decimal hours is 0.2hr, but 0.2 is not exactly representable as floating point number, it is actually:

 time = 0.200000002980232 ;

So, my suggestion is to store time as sesonds. @junwang-noaa

[CoryMartin-NOAA]

Another question is:
float soill4(time, tile, grid_yt, grid_xt) ;
There are soill1-soill4 variables. There are several others (soilt, soilw, etc.) Should they stay like this? or should it be an additional dimension? (the latter is what GEOS does)

[DusanJovic-NOAA]

I have no idea why these soil fields are written like they are now. @junwang-noaa

[climbfuji]

I don't know either, my guess would be that there were limitations in the past with hon many vertical dimensions could be in the file. It's a bad design, because for outputting RUC LSM data, you need 9 separate soilt, soilw, soilm variables (and there is extra code in FV3GFS_io.F90 to handle that).

[junwang-noaa]

@CoryMartin-NOAA Soil layers are the vertical dimension for those fields. I don't remember if fv3 has that axis information. We need to check if we need to add the soil layer dimension, then these fields can have a vertical dimension, rather than a 2D dimension

[CoryMartin-NOAA]

Thanks @junwang-noaa , if we could write these variables with a vertical dimension that would be great. That is what GEOS does and it would greatly simplify the I/O in FV3-JEDI.

[DusanJovic-NOAA]

@junwang-noaa Wouldn't that break downstream programs (upp)?

[aerorahul]

Isn't this for tiled cubed sphere output? Does UPP read tiled output already?

[DusanJovic-NOAA]

UPP does not read cubed sphere outputs, yet, but the same write routine, the same write FieldBundle, the same Fields in that bundle, the same attributes and dimensions of each field are used for all other output grid types/formats.

[DusanJovic-NOAA]

BTW, I suggest we open separate issue, this issue is for adding 'valid time' variable.

[CoryMartin-NOAA]

@DusanJovic-NOAA I will open a new issue related to the sfc fields.

[junwang-noaa]

@junwang-noaa Wouldn't that break downstream programs (upp)?

Yes, the upp interface needs to be changed if we make the soil_layer dimension change.