Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

Contributing code steps

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.


New member
Hi, I have modified the WRF tslist code to enable it to work for idealized cases and was wondering what the process was for submitting code to WRF. The steps on the WRF homepage are outdated and say to email wrfhelp, which is now this forum. Is there a new process for this?

Hi Patrick,
Now that the wrfhelp email is no longer active, this is the correct place for you to be (and we will update the web page - thanks for pointing that out). Since this isn't a new physics scheme, the process should be pretty simple for you. You can just attach your modified files here, along with documentation describing what you did, how you tested it, and what may be necessary to do to initiate the usage of this option. It will also be useful to know from what version of WRF you modified the WRF code. Thank you for doing this!
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).


  • wrf_timeseries.F
    31.9 KB · Views: 88
  • wrf_tsin_PSH.F
    4.7 KB · Views: 83
  • Registry.EM_COMMON.txt
    368.4 KB · Views: 98
Thank you for all of that information, and for the files. I will review everything, run some tests, and be in touch. I'll let you know if there are any questions along the way. We don't put new features in any of the bug releases, so this would likely go in the major release next spring sometime. I will do my best to get this taken care of soon, but will certainly make sure it is done before the major release. Again, thank you. It is always very helpful to receive useful modifications from our WRF users.

Hi Pat,
Do you mind sending the tslist that you used to test (1) and (2), or both the lists, if you used 2 different lists for those, in addition to the namelists you used? I just want to make sure that I'm testing everything the way that you did. Thanks!
No problem - see attached. I had to add the ".txt" extension in order to upload; this extension should be removed before running.

I was finding that if you have both lat/lon and i/j values in the tslist, it will not work. So, I used different tslist files depending on the value of tslist_ij. If WRF is expecting lat/lon and gets i/j, then nothing will be read in.


  • namelist.input
    6.4 KB · Views: 89
  • tslist_ll.txt
    201 bytes · Views: 84
  • tslist_ij.txt
    330 bytes · Views: 89
Thank you for your quick responses, and for providing the files necessary for me to run. I tested everything and all seems to work properly. I have submitted a code modification request to our GitHub repository. You can follow along here:
Additionally, if you notice any errors in what I have stated in the description, please let me know. Thank you so much for contributing!
If you have some time, will you take a look at the comments that have been added to the GitHub pull request? One of our developers had some suggestions/questions. You can use the same link you were given above. Thank you!
Thanks for the comments / suggestions - I can work on implementing these next week. Do I just modify them and resubmit? Or what is the process to make these changes?
Yes, if you would just like to provide the updated code to me, I'll replace what we have before. It will help if you also provide a brief description of the changes you made. Thank you!
I have incorporated the changes recommended so that the code now:
1. determines if lat/lon or i,j should be used based on the header of the tslist file (no longer a namelist option). Ideal cases will only use i,j.
2. the previous tslist_interp is changed to tslist_unstagger_winds and the output is now the earth-relative winds for each.

The recommended coding logic changes have been included. The w-component wind speed is still output by default with these changes. I have done the same testing as before and the results have not changed.


  • wrf_tsin.F
    4.9 KB · Views: 89
  • wrf_timeseries.F
    31.6 KB · Views: 93
  • Registry.EM_COMMON.txt
    368.4 KB · Views: 95
Thank you so much for the modifications. I've submitted the modified files to the PR. I'll let you know if we have additional questions.
Hi Pat,
There are some additional questions on the GitHub PR now. Do you mind taking a look at those when you get time? You can see that I have commented on several and corrected things (some of those were just mistakes on my part). If you don't see a response from me (kkeene44), then it's still open for you to look at.

Just one question about the wrf_timeseries.F file, one in wrf_tsin.F, and then they would like you to update the run/README.tslist file to reflect the modifications. If you want to make any code changes, and want to work from the code we have already modified, you can do it by issuing (from a terminal window):
git clone

and then go into the new WRF/ directory and type
 git branch -a
(you should see this branch, called phawbecker_ideal_tslist). You can then checkout that branch, which will be up to date with both yours and our mods.
git checkout phawbecker_ideal_tslist
Hi Kelly,

Ok - I have gone through and deleted my initials where I found them (they just made it easy for me to jump to each of my changes anyways). I also updated the README.tslist file to include these changes. However, for the uppercase / lowercase comment - a discussion seems to be ongoing as to how to do this so should I wait to see what they have to say as the best way to implement it? Also, I have checked out the branch to make changes to the README.tslist file. Do you want me to submit it while we wait to hear what to do about the uppercase / lowercase stuff?

Thanks a lot,
Thanks for doing that! Yes, if you've made any changes, you can submit them. Let me know if you have any questions about how to do anything. And as for the ongoing conversation, yes, let's see how that plays out, and then address it in the future.

Great! I just committed the changes, but I'm not very seasoned with github - let me know if it didn't work properly (and/or let me know what I should do to commit things the right way).
I don't see any changes committed. For now, you can just attach the modified files here and I'll push them up to GitHub.

For future reference, though, this is a good starter instructional page that will hopefully help to explain a bit about the flow of things on GitHub:

There's a pretty steep learning curve for everyone, so don't worry if it doesn't make much sense at first. This page also refers to you making your own fork (whereas for this particular modification, you cloned my fork, so it will vary a little).

Got it - thanks for the info!

Please see the attached README.tslist and wrf_timeseries.F files for the changes. I had to add the "txt" extension to the README file in order to upload here.


  • wrf_timeseries.F
    31.5 KB · Views: 47
  • README.tslist.txt
    5 KB · Views: 47