SNTEMP (In)Frequently Asked Questions: Temporal Issues

Q10. Because the model is a daily model, but I have adapted it to a seven-day time step, does this mean that predicted temperatures are also daily averages for the seven day time period? I believe this is the correct way to state this, right? Theurer et al. (1984) used this terminology and provided results of average mean daily water temperatures for the time period evaluated (i.e., on a monthly basis). Therefore, it would be improper to state the model is a weekly model, but rather, a daily model using a weekly time-step.

A10. Average mean daily is the correct moniker. Mean daily because all inputs and outputs represent mean daily conditions; average because it represents mean daily condition for a averaging period ranging from one day up to whatever - - one week in your case. When used for a week, the inputs and outputs are also mathematically equivalent to mean weekly values, simply because the mean of means remains a mean. (Kind of like the rain in Spain falls mainly on the plain.) Thus, almost any way you say it is correct, but what you have above is probably the best way. I say this because what capture the extremes that occur within a week - - they get averaged out. Also, and perhaps more important, the reason what you have above is correct is that the theory and mathematics within SNTEMP actually simulate a 24-hour day. [Added 12/2001]

Q11. Could you explain how travel time screws things up. For example, if a release of 1200 cfs is released from the dam and has a travel time to W… of 1.5 days, how will this influence results of a daily average for a seven-day time period. Then, how would flows of 6,000 cfs or greater affect the results if the travel time is now 1 day, or if flows were at 300 cfs and travel time was 3 days? I know that I had written in the report that "it is desirable to have a time-step greater than or equal to the travel time of water", but if the travel time is much different from the time step, then don’t results become less reliable? As stated on page II-53, if the travel time from the upper most point of the downstream end of the network becomes significant (undefined) as compared to the time step, the results become less reliable. What is significant?? What are the likely results of simulations through the range of flows and travel tomes just mentioned?

A11. I must admit that this is probably the hardest concept to explain, perhaps because it is not really intuitive (and I don’t fully understand it myself). Let’s start this way. Suppose you have a parcel of water leaving the dam at Lewiston. The model will subject that water to a day’s worth of heat flux. So the parcel heads down the first reach and gets its portion of the 24-hour day’s flux, then the next reach, and so on, where the travel time within a reach is computed from the channel geometry (length and width) and mean daily flow rate. If the travel time through the system from top to bottom exactly equals one day, everything is fine and pretty easy to feel good about. But that set of conditions rarely happens. Further, the travel time varies anyway because tributaries are coming in with new water, traveling for different times, etc., all mathematically difficult to sort out. But we will ignore that for the moment.

What if the travel time is only 23 hours instead of 24? That means that the water hasn’t really gotten it’s fair share of flux, but at least it has all been within one day’s (or really one mean day’s) forcing conditions. In contrast, if it really takes 25 hours to get through the network, the same parcel of water should technically receive all of the first day’s flux and a portion of the next day’s flux. But the model has no look ahead capability and can’t do that. For this reason, Theurer cautions that the model may perform poorly if the travel time gets much longer than the averaging period, especially if conditions vary greatly from one time step to another - - like a hot day or week followed by a cold day or week. However, if forcing conditions really don’t change too much (one day or week pretty much looks like the next), you can probably squeak by without ever noticing much error.

My gut feeling is that if you plotted the model error as a function of flow (say with the EXERR program) you would see a U-shaped distribution with the minimum error at the downstream-most site corresponding to a 1-day travel time, with correspondingly more error when flows were lower and much more error when flows were higher. In your case, however, since your travel time is always less than one week, you should see less error on average at the higher flows. Unfortunately, that is always the case anyway, because more flow means more "inertia" due to thermal mass, so it would be difficult to sort out.

What about monitoring locations within the network less than one day’s travel time? Again, they get subjected to a mean day’s worth of heat flux so that’s the best you can do.

By the way, remember that within a half-day’s travel time of a dam with constant release temperature the model may not do so well in predicting maximum temperatures. This is because the SNTEMP model doesn’t remember that there is a dam and it essentially looks upstream tracking maximum temperatures expecting that there is a maximum entering the first reach below the dam even though it is really a constant. [Added 12/2001]

Q12. During SNTEMP calibration, is it advisable to build a model for each season? Are all the seasonal differences already built in, so that fine-tuning with your measured water temps is all that is needed?

A12. In general, seasonal considerations are "built in" to SNTEMP - - at least in theory. Solar radiation is probably the single biggest temporal variant and, if not provided in the input data file, is simulated tolerably well. In addition, data filling (and smoothing) are handled with temporal variants in the regression model, so no need there. However, there are five potential reasons why seasonal models would be appropriate.

On the other hand, there is a single good reason for not making seasonal models - - simplicity. Only if you find that you cannot reduce your simulation error tightly enough to meet your objectives would I trouble making seasonal models. [Added 12/2001]

Q13. Your examples of meteorology and hydrology files [for the Upper Colorado River] have time periods that are a water year or two and a set of "normals". Do these need to match for all records? (i.e.: on a validation dataset for temperature, I have about two years worth of data and no long-terms; ditto for point source discharges).

A13. The "normals" are in the class data set because they served a purpose for the upper Colorado River. However, they need not be present for any individual application. They are "synthetic" in the sense that those values were never measured in the field, i.e., they are a "what if" type data set. If you do have a what-if, synthetic data set, yes, they must match for all years, but you need not have one. Most applications do have a set of one or more what-if data sets. [Added 12/2001]

Q14. Without good time of travel information, is it preferable to use a default for Manning’s or go with output from modeling? The latter numbers appear to be fairly high in my example dataset and the manual cautions about such output. Is there a practical upper limit on Manning’s n before the model begins boiling water?

A14. I would tend to use the default 0.035 for Manning’s in the absence of other info, but consultation with a hydrologist might be the best advice. If used as a calibration parameter, you need to be careful. As explained in the test (I hope) there are problems with Manning’s n immediately downstream of a dam or "major" tributary. In these geographic areas, you could be calibrating when the model simply won’t handle it. A practical range of Manning’s values is difficult for me, but I have heard of some small streams that are dominated either by large pools or lots of in-channel vegetation, or other things that cause the travel time to be long that may cause Manning’s n to approach 0.15. [Added 12/2001]

Q18. I have a couple questions as I head into this. A near as we can figure from average velocity measurements at a bunch of cross-sections, the travel time for the 160 km length is about 2 days. Given this information, I am guessing that weekly average temps are the way to go. Is that a correct guess?

A18. It depends on how fast flows change. You could probably squeak by on a one-day time step, but have to own up to increasing uncertainty during low-flow times. Unfortunately, these are probably of interest. So, why not a 2-day time step? If max temps are the issue, the shorter the time step, the better. [Added 12/2001]

Q31. If our model was calibrated with weekly data, does our simulation model have to use the same time step? Or, can we use monthly inputs after using weekly time steps for calibration?

A31. Within SNTEMP, you cannot literally change time steps in the same "run". But you could assemble a monthly data set. I’m not sure why you would want to do that if you already have a weekly model, but you could. Technically, the monthly predictions from a monthly model would be no better or worse that those derived from an aggregate of a weekly model. However, a weekly model would likely be much more useful in the long run. This is especially true near the equinox periods when the environment changes so very rapidly. In other words, June, July, and August may be all pretty much alike relatively speaking, but the first two weeks of October may be vastly different than the last two. [Added 12/2001]

Q58. My data go from week 21 of 1997 to week 21 of 1998, a total of 53 weeks. In the Time Period File, that would seem straightforward to keep track of, or is it? Since there are 364 days when you divide into blocks of 7, do you have to add a day in somewhere and have one 8-day period?

A58. Using a weekly time step for portions of a year is no problem. You may make the duration of the time step whatever you want, and they need not all be the same length. If you want to go from a particular date to a particular date in a calendar year, you may have to "adjust" the duration of a "week" here or there. I’m not sure what would happen if you had 54 weeks, but I kind of think it would be no problem as you specify the Julian days for start and stop. However, I have never done this and I would keep a keen lookout for problems. It could be that the regression models would not work properly. If it were me, I’d be tempted to limit the run to 52 week just to be on the safe side. Call if this is not clear. [Added 12/2001]

Q59. The Job Control File, line 6, has fields for first and last time periods. But my 1997 data has 32 time periods (weeks) and my 1998 data has 21 time periods. Is this going to blow up? Do I have to have the same number of time periods in each year?

A59. NEVER use the first and last time period fields for anything other than ALL time periods. This is a bug in SNTEMP. You should have found note of this in the errata file. Better check this file and update your IP16 just in case. And yes, each "year" must have the same number of time periods if you are going to do a multi-year run. You can split into two runs, each with different number of weeks, but then you don’t get the full calibration statistics. Of you can combine, but then the model must do substantial filling for those weeks where you have no data. [Added 12/2001]

Q60. Let’s say I’m running weekly data from 1997, week 21 through 1998, week 20. I get to "week 52" in my *tme.dat file. 7 days would make it go through day 364. Should this last week be made 8 days long to go through day 365, or does it matter?

A60. There are no hard and fast rules on this - - sort of personal preference really. Most people probably ignore the very last day (and any leap year day) which has the advantage of being easy to explain and computationally identical. Personally, I prefer adding the last day to be "complete". In part this may hinge on whether you want o be synchronized with any other models or data formats, i.e., is it important to be in step with water year or calendar year boundaries? Do you need to link to a water budget or reservoir operations model?

Q61. After 1997, "week52", should the first week of 1998 be numbered "1" or "53" or does it matter?

A61. As far as SNTEMP goes, the name of the time period is strictly alphabetic and up to you. The only rule is for uniqueness. Therefore the answer is "It doesn’t matter." Again, I’d ask whether it is important to those who will inherit the model from you. [Added 12/2001]

Q65. I’m running weekly time steps on the River D… So am I right that the maximum temperature is just that: the highest predicted temperature (instantaneous) for that week? The 7-day average max, which is often asked for, is, as I understand it, not at all the same as the SNTEMP weekly max.

A65. My read on this is different from yours. SNTEMP works on any averaging interval down to one day. If the time step is one week, all inputs and all outputs represent a mean day for that averaging interval; therefore, SNTEMP’s output represents a mean day for that week. This applies both to the mean daily water temperature prediction as well as the maximum daily estimate in the sense that both ideally match their mean for the averaging period. So, no, the maximum temperature is not the highest (instantaneous) for the week, if your model is well calibrated for maximums. It is the 7-day average max. [Added 12/2001]

Q155. Below is a rehash of an old e-conversation we had regarding the D. River. I'm working on a different project now, on the H. River. It is a short (3-mile) bypass reach, where the travel time is short (can't be more than 3 hours). DEQ wants to know what effect the project has on maximum temperatures (7-day moving averages).

If I remember correctly, you said some time ago that running the model in a weekly time step, the max T output represents a 7-day average. This means that a set of 7-day moving averages could be generated by running the model 7 times, each with a different starting day. Does this sound right? Or do the very short reach and travel time require another approach or model?

A155. Wow. You mean I must remain consistent with something I said two or three years ago?

Seriously, I believe you are more or less correct in your assessment, but that's not the way I'd do it. I would recommend just running a DAILY model instead of a weekly model and then calculating the running average from those results. Here's why. First, composing a whole series of weekly models would be a data management nightmare whereas one long daily model would be pretty straightforward. Two, the weekly models are giving you a misleadingly rosy goodness of fit because weekly averaging masks the true peaks and valleys that are really happening out there.

I'd be just a bit leery about the 3-hour travel time. My experience (and intuition) lead me to believe that SNTEMP does best when the travel time is close to 24 hours and begins to do worse the more one deviates from that in either direction. But you won't know till you try, and calibrate, the model. There are many examples that deviate from the 24-hour rule of thumb and do just fine.

When you say they want to know the effect the project has on maximum temperatures, does this include whatever upstream ponding there is? That too may influence maximum daily water temperatures. [Added 6/2002]

Q156. The travel time for my system is about 1.5 days during low flows. How do I set the averaging time in the model? I need to average over 2 days, but I am a little confused about the implementation.

A156. The averaging time is set in the time period file by the number of days in each time period (step) with the minimum being one day. If you wish to have a two-day model, you would simply establish two days per time step and name the period accordingly. Then, all of your input for flows and meteorology would need to be two day averages computed outside the model and entered as average values in the model.

I hesitate to encourage people to "break the rules" but 1.5 days really isn't much different from one day. I suspect, but cannot guarantee, that you will get acceptable results if you go ahead with a one-day model instead of a two-day model. This would save you the trouble of doing all the averaging. You could try some portion of your data and see if it works OK. Even a simple experiment with SSTEMP might show whether a one-day model or a two-day model really gives substantially different results. The kicker is whether anything changes much from day to day (flows, meteorology), but defining MUCH is hard to do. [Added 6/2002]

Q157. The year 2000 had 29 days in February. I don't think SNTEMP accounts for leap years? So I guess I should either just not predict temps for 2/29/00 or adjust the Julian dates accordingly for the rest of year 2000?

A157. SNTEMP can handle leap years, but every year simulated must have the same # of days, and really the model expects 365 days in calculating solar positions, etc.. Most people will choose to omit Feb 29.

Q264. If one is using a time period of one day, are the starting and ending Julian numbers the same? And is there a common naming scheme for daily time periods? Or is it as simple as:

A264. This is a common question and the answer is yes, the starting and ending numbers are the same. Your naming scheme looks just fine to me.

Q265. The travel time for my river varies from 30 to 50 hours depending on flow rate. So I assume that using a 2-day averaging period would be the best way to go - does this sound right?

A265. Yes, this is technically correct. However, if you will be modeling times for which there is little day-to-day variability in meteorology, I believe you could use a single day time step with no problem. The model will be slightly less reliable under those circumstances and would not work too well if there was large day-to-day variability.

Q266. Is it worth it at low flows to use a 1.5 day averaging period - is this even possible?

Q267. Assuming a 2 day averaging period and therefore using 2-day averages for water temperature, air temperature etc., what's the best way to calculate the average; standard every two days: ex: average of June 15 and 16, next average of June 17 and 18 or a rolling average ex. June 15 and 16, then the average of June 16 and 17?

Q268. Also I assume the minimum 1-day averaging period refers to the entire model not sub-reaches, is this right?

Q269. For example, if the travel time of 50 hours is from node H to E, the fact that travel time within a sub-reach is less than one day does not make it OK to use a one day averaging period. I guess my question is in trying to correlate travel time with averaging periods I have to consider the whole model not just parts of it, correct? I hope this makes some kind of sense.

A269. Yes, it is a good question. In fact, I believe I have no consistently correct answer to this question. Really, the travel time in both the sub-reach and the whole model must meet the constraint. I believe there is some scant evidence that the model works better if the total travel time almost exactly equals the averaging period, but I do not think I can prove this.

Q270. I'm currently going through Topic 9 of the IF 312 course material and am a little confused about the averaging period and the time-step for the model. Now say for example, I am interested in running the model for a three-month period and want daily maximum and minimum temperature output for that period. I understand that the closer the averaging period is to the time of flow from headwater section of the modeled system to the end-point the better. So, if the time of flow is say 3 days and therefore, indicate that the averaging period is three days, will the model give me temperature values in groups of three (i.e. will the output be three consecutive equal values for daily maximum, minimum, and average temperature)?

A270. Your interpretation is close, but if I understand you correctly, not quite right. You are indeed correct that the model seems to perform best when the averaging period is about the same as the time for water to flow entirely through the network, however it is defined. Let's say that is three days. Then it would be incumbent on you to run the model by setting it's time step to a 3-day period and averaging all of the model inputs for all the three-day periods you wish to simulate, for example, June 1-3, June 4-6, June 7-9, etc. Model output would then exactly mirror model input, i.e., the temperature prediction for the first time step would be the average mean daily temperature for June 1-3, and so on. I say average mean daily because that's what it is -- the average of the mean daily water temperature for the three days. In a way the model is giving you three equal days just like you said, but only as a single value. (The same is true for average mean daily maximum temperatures for each 3-day period.)

I believe there is an example in your files somewhat of a 2-week model for the Gunnison River. If you look at the input files for that model application, this might make more sense.

Q271. I want to make sure I have the time period thing right. I've been making an assumption and may not be doing it right. The travel time for my system at low flow is 2 days. That is the length I want to make my time period. So in the Time Period File, I have entered Julian day 238 to 239. BUT... then there's this thing described as "Number of points in the time period average". Number of what kind of points? You say "usually 1" but then your Upper Colorado River Basin example has "2". Then there's this thing in the Job File that is labeled "Number of time periods per year"; what do I do with this? Basically, if I want the time period to be two days, what entries do I need (is Julian day span enough?)? I have VERY limited data (so much so I'm not comfortable with the results but the boss wants something...) - basically two days worth. So that's all I want to simulate to check my calibration. Right now I have 1 "point in the time period average" and 1 "time periods per year". If the time period is two days, there should actually be 182.5 time periods per year (365 divided by 2) but when I try that, the program freaks out.

A271. I believe you have the time period Julian days correct to represent a 2-day travel time.

The "Number of points in the time period average" is indeed poorly explained. This is not actually relevant for anything much less than a month. Use 1 day.

"Number of time periods per year" in your case would be the number of 2-day time periods you are actually simulating, namely one. If, for example, you were modeling one month, it would be 15 time periods.

I agree with your hesitation about simulating only one 2-day period. Be very careful in interpreting the results.

Q272. I'm now on to a different stream system that has slightly better data. At least it covers a longer period of time. I started off simulating a 2-day time period with average monthly data but didn't figure that was worth anything. I parsed that down to weekly data and am simulating 4 weeks in Aug 2003. The only way I can get the data for each week to synchronize with my verification data is to modify the temperature calibration coefficient in the time file for each week (they are on the order of 0, 1.01, 1.04, and 1.07). Does this seem plausible? Or is this due to the time step still being too big? If this is the way to go, if I then break this down into daily time periods, would I need to calibrate each day in a similar manner?

A272. If I understand you correctly, I do not recommend this approach. To do this would seem to require a rationale for why you needed to 'consistently' increase (air?) temperatures through the month. If there is a rationale, then great, otherwise, I’d recommend one and only one calibration coefficient for all four weeks and accept the (hopefully minor) discrepancies. Don't get enamored with extreme accuracy, regardless of the time step. After all, it is only a model.

Q273. If the time step should represent the travel time over the set distance, and the program will only look at the data for the particular set of Julian days that you specify, why have months of data in the data file that aren't figured in?

A273. I do not understand your question. All input data will be simulated. The model will not run a subset either through time or space.

Q274. If you are just trying to simulate a representative day in say August, is it better to use a monthly average set of data? Why would you ever use monthly averages, like you do in your example?

A274. I suppose I should probably delete the monthly example, because so few people do this anymore. When Theurer put together the upper Colorado example, he faced two issues. First, there were long travel times, though not on the order of a month. The biggest issue was a lack of good quality data. Much data was either missing or grab sample only. To get 'representative' data, he averaged over a month. Now that good data are (or can be) readily acquired, most people simulate at a daily time step, though there are many examples of multi-day models due to travel time constraints. I don't know if I mentioned to you that I occasionally recommend relaxing the travel time constraint if flows and meteorology are largely uniform through the period simulated.

Q275. I spoke with you last summer regarding a hydroelectric project in Alaska. We collected instream temperature data for four months during the summer of
2002. To run the model using these temperatures for validation points, can I only use the time period that we collected data? I have some monthly and daily data for other inputs. Do I have to select one time period for all input files?

A275. You can actually run the model with a variety of time steps, some monthly, some weekly, and some daily. You do this by naming the time steps and defining the appropriate Julian days in the time period file. All other files must match, i.e., the flows would have to be aggregated to match the various time steps. Note that the time steps must be identical for each year simulated if you have more than one year of data, and, it could get somewhat confusing all in all, so I recommend proceeding with care. If you find that this is not what you really want to do, it is usually easy to delete certain times from your files.

Q276. I am trying to conceptualize how SNTEMP handles the routing in a stream network I am modeling. The travel time for the entire network along the main channel is 24 hours. I am using a 1-day time step. I am comparing predicted mean daily temperatures to observed mean daily temperatures at 5 nodes intermediate along the distance of the main channel. My Manning's n values vary along the length of the network for the calibrated model.

My question has to do with understanding the travel time through individual nodes. I am fully aware that steady state conditions apply within each time step (1-day in this case). How does the model allocate the proportion of a time step that a parcel of water spends in each upstream node in the network?

I have good calibration at 5 of 6 V nodes in the network. My model does a good job of predicting temperatures at a V node on the mainstem located 1 km downstream of a coldwater release reservoir, which is at the head of the network. I have good calibration at 10 km downstream and at the lower end of the network, which is 19 km from the head.

My calibration is not as good at a V node located 2.5 km downstream of the network head; a modeled tributary that is warm relative to the mainstem joins the network at 1.5 km below the network head. The model over-predicts mean daily temperatures during the peak of the heating season at the one problem V node. I think the reason is that the predicted temperature is a combination of the warm tributary flow and the mainstem flow that is still influenced by the cold water reservoir. The travel time down to the problem V node is less than the 1-day time step, so I think the model over-predicts temperature since it is "blind" to the reservoir at this point even though the upstream V node (also affected by the reservoir) is well calibrated. In other words, it is time step issue and good calibration at this intermediate V node may not be possible without factoring an unreasonably narrow channel.

I'm curious on your thoughts on what condition the model is using for a node that is located at a travel time distance from the network head that is less than the time step.

A276. Your question is a good one because the answer (as I understand it at least) is somewhat counterintuitive -- and a bit of a mystery to me at least.

Perhaps the best way to internalize the process from SNTEMP's point of view is to remember that everything remains the same all day long. You allude to this in terms of the steady state of the system. Because the model knows the discharge, mean channel width, length, and slope of each reach, it can compute the mean channel velocity from Manning's equation. This, in effect, provides the "exposure time" for water in the reach. Then, heat flux is computed for that area of stream (length X width), but in a way that continues to assume that everything remains the same all day long. Velocity is, however, important in predicting maximum daily water temperatures, as you know. I wish I could explain it better, but I cannot.

Now, about your problem. I believe you correctly identified a suspicion in the model's lack of knowledge about the upstream reservoir, but that would only affect the maximum daily water temperature predictions, not the mean daily predictions. (By the way, I don't think it fair to characterize the Manning's n adjustment as unduly constricting the stream width. It really affects only travel time and depth.) If the model is predicting well at V nodes both above and below the problem node, I would be more tempted to believe that the error is caused by other factor(s). What could they be?

You say that the intervening tributary is modeled. Do you have any verification data for that tributary? Could inaccuracy in modeling tributary temperatures alone account for the error downstream? Is the error (predicted minus simulated, or vice versa) a nice sine function with time? Any evidence that the error varies with tributary (or mainstem) discharge? In effect, I'm suggesting that you run an EXERR-like analysis on the misbehaving V node. Alternately, is there anything different about the "thermal reach" immediately above the V node thermister? Have you modeled shade? If so, you might double-check the shading and geometry parameters. This is where width does make a difference. Any evidence for springs or seeps possibly affecting the temperatures right at the thermister? I know this is grasping at straws, but it makes sense to review the situation thoroughly. If nothing surfaces, you may have to live with the problem.

For what it is worth, I believe there is some reason to believe that SNTEMP (and SSTEMP for that matter) do best when the whole system represents about one day's (or one time step's) travel time. If this is really true, and if so why, remain unclear to me. All in all, the problem you described does not sound like a travel time issue to me.
Later - Since I responded to you on this issue, I happened to be talking with someone about a similar issue and thought he had a good perspective. I am pasting an item in here that responds to a reviewer of his work:

"Rules of thumb for goodness-of-fit (validation) statistics for SNTEMP are just that. The "goodness" of the statistics will reflect the temporal and spatial resolution of the model domain, the quality of the input data, the appropriateness of the heat flux and transport model to the conditions being simulated, and the quality of the data to which one compares. The rules-of-thumb given in Information Paper 13 represent good goals to shoot for, goals that can be achieved in many cases. However, there well may be reasons why these goals cannot be achieved in other cases. The investigator has pointed out a very good reason why statistics computed at locations where temperatures are changing the most rapidly in the river may not be well predicted at some nodes. That is, given normal input data quality issues, it may be more difficult for a model to predict the river's temperature at locations where thermal change is the greatest. It is theoretically possible to improve model fit at these locations given better data or a more detailed, yet realistic, calibration. Regardless, do not lose sight of the objective of temperature modeling, which in many cases is characterizing the macrohabitat through biologically relevant portions of the river. Exactly what goodness-of-fit is needed will depend greatly on the nature of the thermal criteria to be applied and the risks one is willing to assume."

Basically, this person illustrated his situation with a set of graphs showing that monitoring locations along the stream where temperatures are intermediate between release temperatures and "equilibrium" temperatures are likely to have the greatest error. After temperatures have reached or are near equilibrium, it doesn't matter much in that they will all be close.

Q277. If the travel time for a river reach that was going to be modeled is two days and the desired output from the model is daily maximum temperatures would it be reasonable to divide the reach in half and run two SNTEMP models in series, taking the output from the first model and using it as input into the second model?

Follow-up - The project area I am working on is a 100 mile section of the X. River. The travel time for the 100 mile section is roughly 7 days. The agency we are working with has a series of locations along the 100 mile section where they would like to simulate daily maximum temperatures for April through October for a “representative” low flow year and test scenarios for reservoir releases at the beginning of the section. They then want to count the number of days in the simulation period where a given maximum temperature is exceeded at each location (and use the count in a rating index for fish habitat).

As an approach I thought I would put seven SNTEMP models in series. I have a computer program that cuts the simulated temperatures out of the SNTEMP output file and pastes them into the hydrology input file and then runs the 7 models sequentially. At present we are missing daily values for some of our inflows from irrigation channels but hopefully the data will be collected in the near future. I just wanted to run this by you to see if it was a “reasonable” approach.

A277. We have often talked about doing this for the very reason you mention, but in practice, I am unaware of anyone who has actually done so. In contrast, most people either adjust the averaging interval to two days, or live with the violation of the travel time assumption. I think it depends on your objectives. If you are trying to be super-accurate, I suppose you could serialize the models. But normally (if there is such a thing) the focus is on hot periods. During these hot periods, tomorrow is usually very much like today. When (and if) that is true, a single-day averaging interval will still work well.
Follow-up - Again, I believe your approach is reasonable. But I wonder if SNTEMP is really the best model for this situation. Though I am no expert, it might be wise to at least consider a sub-daily model that can do routing, perhaps like HEC-5Q or CE-QUAL-W2. On the other hand, if SNTEMP provides satisfactory results, then who's to complain?

Q278. Also (You probably get tired of explaining this one) - if the desire is to model only one day, should the length of study reach be at least equal to (Length of day * Velocity) OR (Length of solar day * Velocity)?

A278. All inputs are 24-hour averages. Therefore it is a 24-hour day that establishes the theoretical study area length. In practice, people violate this all the time with only minor consequences.