Thank you very much for the info!
The changes that I made to the tslist code were tested in both v3.9 and v4.0. The changes are as follows:
1. Modify the read process to work with idealized cases: use i/j instead of lat/lon in the tslist file
2. Use either i/j or lat/lon for real cases (new namelist variable – tslist_ij = .true.)
3. Output w on cell centers
4. Output u, v on cell centers (new namelist variable – tslist_interp = .true.)
Note: I have added my initials (PSH) next to the parts of code that were changed but they can be removed if these changes are accepted.
For (1) I modified the wrf_tsin.F file such that if map_proj == 0, then tslist will read in integers (instead of floats) and assign that to grid%itsloc and grid%jtsloc. This makes is such that if it is an idealized case, tslist will expect i,j coordinates instead of lat,lon.
Else, for (2), if a real case is being run and tslist_ij = .true., then tslist again expects i,j coordinates. If false, tslist operates as it currently does.
Then, for both (1) and (2), in wrf_timeseries.F, the same if/then/else statements is utilized where ts_rx and ts_ry are defined so that if it is ideal (map_proj == 0) or if tslist_ij is true in a real case, then ts_rx and ts_ry are set to itsloc and jtsloc, respectively. Else, latlon_to_ij is called for real cases with tslist expecting lat/lon.
In (3), I copied the process for ts_v_profile and simply changed it to read in and output w. This required adding ts_w_profile to the registry, adding "WW" to the list of variables to be output, and change the loop that goes over the variables to expand from 5 to 6 (so that w is included in the output). I made sure to output w on cell centers so that it would be at the same heights (and same output size) as the other variables.
Lastly, since having all variables at the same locations is desirable for my work, I added another flag to the registry, tslist_interp, that is read into wrf_timeseries.F in the subroutine calc_ts such that if true, u and v are interpolated to cell centers. If false, tslist performs as it currently does.
To test (1), I ran em_quarter_ss with a tslist specifying several grid indices and ran the standard run for 2 hours outputting the full 3D field at every time step. I then compared the tslist output to the full 3D solution at that location in a time-height plot and took the difference. I found that at each location, the differences could be attributed to roundoff error (O(10E-6)) and differences were not structured in any physical arrangement. Further, I ran again with lat/lon specified in tslist and confirmed that no output was produced.
To test (2) I ran a small idealized case study with i,j specified in tslist and tslist_ij = .true. in the namelist. I used the same method as for (1) and confirmed that the output is at the expected locations. I then kept the tslist the same, but set tslist_ij =.false. and confirmed that no output was produced. Finally, I modified tslist to include several lines of lat/lon values and confirmed that they were produced at the correct locations.
(3) was confirmed by the inclusion of a XXX.d0Y.WW file with appropriate header and values that match with the 3D output.
Lastly, (4) was confirmed as above where the 3D field was unstaggered (tslist_interp = .true.) and then the differences were shown to again be extremely small (10E-6) and unorganized.
By modifying these three files (attached), all that needs to be added to the workflow is the inclusion of the two namelist variables, "tslist_ij" and "tslist_interp" in the &domains portion of the namelist (where the current tslist variables are). If they are not included, the default for both is false and tslist operates as normal (tested and verified).