Revise location_index for IODA file in Trajectory sampler

[metdyn]

Types of change(s)

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Trivial change (affects only documentation or cleanup)
• Refactor (no functional changes, no api changes)

Checklist

• Tested this change with a run of GEOSgcm
• Ran the Unit Tests (make tests)

Description

location_index_ioda in Trajectory sampler is creating problems (found by @mjkagnes123), when the code is using the previously designed index mapping scheme. For the 29 IODA files (NPW platform), about 6 of them shows either missing points and/or extra points that does not belong to a single IODA file. This is because, we did not expect to see, e.g.,
aircraft.20190801T210000Z.nc4 contains time points: [20 points at 15 Z, mid, 20 points at 21 Z ]
aircraft.20190802T030000Z.nc4 contains time points: [10 points at 21 Z, mid, 20 points at 03 Z ]

Our time slice scheme follows the python convention and will create a file:
aircraft.jedi.20190802_0300z.nc4 contains time points: [30 points at 21 Z, mid, zero points at 03 Z].

In this case, we would not be able to recover the IODA location_index in aircraft.20190802T030000Z.nc4. In other words, we have extra points at lower bound and missing points at upper bound. This does not occur, if observation files does not contain exactly points at 21 Z or 03Z. This explains why we had the right location_index_ioda for about 60% of the NPW platforms (IODA files), but wrong index for the rest.

Now, location_index_ioda in Trajectory sampler is revised to allow for reading in a single observation input file, such as sondes.20190801T210000Z.nc4, then generate the sampled GEOVAL values along the trajectory (in time ordered sequence) and return an array index (location_index_ioda) mapping back to the location points in the input IODA file, with the exact number of points. This is controlled by setting jedi.use_NWP_1_file: .true. in HISTORY.rc.

Note, the default (use_NWP_1_file=0) is our standard method, using our designed PYTHON style for time slicing: [ T1 , T1 + Epoch), with T1=21Z, Epoch=6 hr, for example. Here we will analyze an expanded time window [T1 - Epoch, T1 + 2*Epoch).

Related Issue

[tclune]

1. Lots of unguarded output to console. If just for debugging and meant to be deleted later, just let me know. Otherwise add conditionals or delete.
2. I cannot be sure if use_NWP_1_file is meant as a control or as a counter. If the former then the values should be named constants rather than literals "0", "1". If the latter, then a better name would make this clear.

[metdyn]

1. Lots of unguarded output to console. If just for debugging and meant to be deleted later, just let me know. Otherwise add conditionals or delete.
2. I cannot be sure if use_NWP_1_file is meant as a control or as a counter. If the former then the values should be named constants rather than literals "0", "1". If the latter, then a better name would make this clear.

You are right. I removed these write statements, except the warning when the use_NWP_1_file: .true. is activated.