SNTEMP (In)Frequently Asked Questions: Meteorological Issues

Q3. My study area covers a large change in elevation. I have tried to use the calibration factors in the job control file to adjust the met data for elevation zones, but am having trouble. Have you any suggestions?

A3. The moist-air lapse rate Theurer recommended (as default) was 2°F/1000’, or –0.00656°C/m (see page II-29+30 of IP#16). One test I have shows the variability of moist-air lapse rates with air pressure (read elevation) and air temperature. Representative rates vary between 3.5 and 4.3°C/km at 20°C. Thus, Theurer’s rate is high and more representative of temperatures at 0°C and at sea level. However, for the dry-air adiabatic lapse rate, which does not vary with temperature or pressure, other authors (e.g., Seytoux) have used 9.76°C/km, or –0.00976°C/m, which we found worked better for us at Shasta. You could experiment with this if you wish. Unfortunately, SNTEMP doesn’t make this as easy as just changing the lapse rate. You must do it as described on page III-83 using five different multiplicative factors, though you only need to use 2 I guess. You would use the lapse rate to calculate the scalar for air temperatures and let SNTEMP interpolate on elevation. [Added 12/2001]

Q23. I recently completed an SNTEMP model for a river near P…, Oregon. Unfortunately, I cannot find a source for percent sunshine or cloud cover data after July 1995 anywhere in this region (the percent sunshine variable was apparently dropped from those measured at the P…Airport); my client would like to conduct some model runs for 1996 and 1997 conditions in addition to earlier years we have already modeled.

There are many sites in this region where solar radiation data is available (i.e., AGRIMET stations). Can solar radiation data be used in any way when percent possible sunshine or cloud cover data is unavailable? I know that measured solar radiation at ground level can be optionally input to the SNTEMP meteorology data file. However, I’m not sure if solar radiation data can be used in lieu of percent possible sunshine data, especially if the solar radiation data is not recorded in the immediate vicinity of the river being modeled. How is solar radiation data placed in the meteorology data file used by SNTEMP?

A23. I am aware that it is a lot more difficult to get cloud cover data now. That’s too bad as it can be an important input. Unfortunately, ground-level solar radiation cannot be directly used "in lieu" of cloud cover. I have the following options to consider:

Q33. A colleague explained to me some time ago that the best way he knew for getting percent possible sun was to run the SSSOLAR model and back-calculate. Does this sound good to you? We have air temps, relative humidity, and solar energy from our weather station. The latter is in the range (10,000-15,000) so I haven’t gotten around to figuring out the units yet. Assuming this is a good route, should the dust and ground reflectivity be left at their default values unless there is some compelling reason to change them?

A33. I suppose there are really two or three ways to handle this growing problem, none very satisfactory.

Q34. We have a MET station on the D… River, which was installed in 1997. Here, for comparison, are its solar energy values for May-August, as compared to historical data from Redmond, OR.

There’s obviously a trend here… Redmond is at a very similar latitude, but is at a higher elevation (940 vs. 260 meters). Also, we’re comparing an average of 30 years of monthly data vs. weekly averages from 1 year. Still, this is a consistent 2-fold difference. Is there some type of unit other than KJ/M2 that could be in use here? Are there some local topographic conditions that could make this much difference (the Met stn is in the D… River canyon)? I am looking into these issues but would still value your opinion. Thanks.

A34. Certainly you need to know the units, watts, btus, langleys, joules, whatever. Assuming they are the same units, yes, the two factors you mentioned are relevant. One would expect that a higher elevation would receive more radiation. You could get an idea of how much simply from SSSOLAR. I doubt that that would explain the difference. Then the topography is relevant. Standard stations are likely to be on (or near) a level-plain condition, i.e., have little topography other than the curvature of the earth. If you are in a canyon or have significant topography, that would explain a lot. The final factor is maintenance. I don’t know much about this, but I have been told that those radiation units need a lot of attention. Dust, leaf litter, dew, etc. all occlude the crystal. Beware. [Added 12/2001]

Q35. Should the solar data come from a level-plain condition, or should the data come from a condition, which is near the "average" topographical condition of the river? In other works, should solar radiation be a "pure" number that is influenced only by latitude, altitude, etc., or is it meant to take into account topography?

A35. If you are putting ground level solar radiation into the model, it is my expectation that it should reflect lev3el-plain as best as possible. [Added 12/2001]

Q36. Should percent possible sun be a function of topography also? It seems as though if I back-calculate pct sun from SSSOLAR using our met station data, then it will be partially a function of topography.

A36. Percent possible sun should reflect cloud cover only, not topography. [Added 12/2001]

Q37. I was thinking maybe I could use the weekly data from our station as an INDEX of the solar radiation. So if the average value reported from Redmond for July was, say. 25000, and our weekly values were 12,000, 14000, 13000, and 15000, I could set up a proportion. So our highest weekly value would become 25000 (maybe more?), and the next highest would be (14000/15000) * 25000. Any reason why this wouldn’t work out?

Actually, maybe I should rig it so my weekly "corrected" values AVERAGE to the 25000, instead of having it as the maximum possible.

A37. I’d plot out whatever values you have to see that the relationship is, if any. If it looks like a constant proportion, go that route. If it looks like there is some ceiling, you might need to factor that in. Remember that the measured radiation in both locations can actually exceed clear-day values in some circumstances - - see IP#13 Figure 20.

And I agree, you can carry this too far. See what is good enough for your purposes. [Added 12/2001]

Q38. I just need to confirm something about the ground-level solar radiation as input to the SNTEMP model. An increasing number of people are deploying their own instrumentation to collect this data as it is becoming harder to find from weather station values (though it always was hard). My assumption is that the solar values you should enter into SNTEMP should be representative of level-plain collection, I.E., not influenced by (or at least corrected for) local topography. Then, SNTEMP will "adjust" those solar values for elevation, day length (latitude), and shading. This is partially borne out in Table VI, which shows the solar values differing by site. But what’s got me somewhat mystified is that the solar values given in Table VI do not seem to be a function of shading. My assumption is that the printed values reflect ground-level values for the elevation, humidity, etc., but not (yet) for shading.

A38. Solar radiation at the ground level for a level-plain is the extra-terrestrial solar radiation corrected for attenuation through the atmosphere. The extra-terrestrial radiation is a function of latitude and Julian day. Elevation only affects the optical air mass, which in turn affects only the attenuation through the atmosphere. Once the solar radiation at the ground level has been determined, then corrections for shade can be made. Topographic shade is determined first because it is not affected by the riparian vegetation (local shade). Topographic shade is a function of latitude, Julian day, and the altitude and azimuth of the surrounding topography (mountains, hills, canyons, etc.). Corrections for local (riparian vegetation) are made next and is affected by the topographic shade. Local shade is a function of azimuth, riparian vegetation geometry (tree height, offset, and density), and the stream width as well as the local sunrise/sunset times. The local sunrise/sunset times are a function of the topographic shade. The last correction considered is for the solar radiation penetrating the water. It is a function of the solar radiation angle only. It is also affected by the clarity of the water but it was assumed that whatever solar radiation passed through the water and was absorbed by the boundary was, in turn, converted immediately into heat and re-absorbed by the water by conduction. This correction can actually be made before correction for shade or after because arithmetically it makes no difference. [Some material from Fred Theurer]

Q40. On pp112-113, it is mentioned that Ground level solar radiation can be entered directly into the MET file. If you have this information, is it advisable to enter it? Under what circumstances? What are the advantages and disadvantages of entering it?

A40. All things being equal, yes. The idea is to make the input data as representative of the stream environment as you possibly can. Quality in = quality out. But, you must also match the assumptions of the model. As we have discussed, your "ground level" is not the level plain data and must be corrected, thus possibly introducing error. That’s why I’d recommend trying it both ways to see what works best. In the long run, it may be best to relocate your radiometer and supply local solar data. The model should be more accurate from that point on, at least with respect to that variable. However, this implies cost. If you get an acceptable calibration using remotely collected radiation data, why bother with an instrument? Back to your objectives…

Q41. On page 143, alternatives to the default adiabatic air temperature correction are discussed. Our meteorology station is in a canyon, so I suppose it is possible that the default correction could be in error. But how does one determine this? Have you had any experience dealing with non-default corrections?

A41. I have heard through the grapevine that some others have used the adiabatic temperature corrections to great advantage in what may be similar canyon situations. It’s a little tricky to figure out how to implement, but does seem to work in the sense of better calculations. I’ve never done it, and would be somewhat suspicious that it would "work" all year round. It would be best if you had multiple air temperature readings from different elevations to corroborate the adjustments that the model was providing (which may be found in some of the output tables). This would allow calibration of the air temperature correction "model" prior to running the water temperature model. This avoids calibration just to get things to fit without really knowing why. Nonetheless, if it helps better describe the system, why not? I should ask, do you have evidence that the air temperature correction is less than perfect?

Q52. I'd like to get your opinion on dust coefficients and ground reflectivity. From the manuals, there are some "rule of thumb" numbers for reflectivity that we can put in, plus a formula for distributing the values seasonally. There’s also the same for dust, but the values (Page II-13 of the user’s manual) are given for Washington DC, Madison WI, and Lincoln NE only. Plus these values in Table II-1 are in 2 columns labeled mp=1 and mp=2. Am I getting carried away here? Are there some good default values to put in? I don’t mind going through some calculations if it means a more defensible model.

A52. Playing with these coefficients really only makes sense if you have reliable solar radiation data. They are not very sensitive (or at least you should determine to what degree they are sensitive) and may be "calibrated" pretty much as described in IP#16. I’ve rarely thought it was necessary unless you really have a lot of time on your hands and just want to do it. But like I said, if your solar data is from a long way away, it’s probably better to calibrate with the solar data rather than these rather minor values. The values given in the tables should simply be used as guides depending on relative humidity and land use. They might explain a portion of the seasonal error component. [Added 12/2001]

Q128. This question has to do with the ground temperature variable in SSTEMP. In the Information Papers, it says to use mean annual air temperatures if no ground temperature data is available. I have been using mean monthly air temperatures or the daily air temperature instead, and my results during validation have been very close to the actual measured water temperatures. I suspect that if I use the mean annual air temperature, my results will not be as accurate. Is using the mean monthly or daily air temperatures a valid way to run the model.

A128. The rule of thumb in IP 13 & 16 is just that. It is always hoped that one might have some "on the ground" data from springs, seeps, well logs, or something to supply the model with more representative data. We do know that in many situations, ground water temperatures do change throughout the year, following a sort of sine wave but delayed with respect to air temperature. Mean monthly air temp values sounds like a reasonable approximation. I would not use dailys.

It could be that if you have only a small amount of ground water accretion, your model may be insensitive to ground temperature. Temperatures of lateral inflows may obviously follow air temperatures more closely. [Added 6/2002]

Q129. Here is my SSTEMP data set. This is a small stream located in C County, S state. The stream reach length is only 3 miles. There is a diversion dam at the top of the reach. I'm attempting to predict water temperatures in this reach under impaired flow conditions and under natural unimpaired conditions. I only have real temperature data for the summer months for a few years. I have been trying to validate the model using the year with the most accurate and complete data set. For each model run, I change the inflow and outflow, inflow temperature, air temperature, humidity, and ground temperature.

I have temperature data for 1966,1967,1968, and for 1996 and 1997. The mean daily water temperatures for the 1960's data were calculated from two measurements, the Max and Min daily water temperatures. The 1990's data and mean water temperatures were obtained from hobo temps that measured temperatures every 5 minutes. When I attempted to calibrate the model comparing these data sets (1990's vs. 1960's), the results were not very good, and it did not predict temperatures very well. I came to the conclusion that perhaps because the mean values were obtained in different manners, the data sets were not comparable and could not be used to calibrate each other. Is this correct?

A129. It is indeed possible that comparing data sets where the mean temperatures were calculated differently could be problematic for at least two reasons. First, such a change almost certainly implies a change in instrumentation. There is always error associated with our measurements even though we rarely acknowledge that error. Along with changes in instrumentation come changes in the representativeness of measurements, particularly meteorological values that come from stations that move every decade or so, or have urbanization or other systematic changes occurring in their locale.

Perhaps more to your specific question, however, is that there is a bias in computing a daily mean from daily max and min temperatures (both air and water) as opposed to the mean of 24 hourly measurements because the diurnal cycle is not symmetrical. This bias changes throughout the year, likely showing an underestimate in the summer and an overestimate otherwise. However, I do not know how truly general these results are nor can one necessarily predict the magnitude of the deviation without calculating it with on-site data. One paper I'm looking at show a maximum difference of maybe 0.6°F for air temperature. I am aware of two papers that discuss this phenomenon:

Arnold, C.Y. 1960. Maximum-minimum temperatures as a basis for computing heat units. Proc. Am. Soc. Hort. Sci. 76:682-692.

Byrd, G.P. 1985. An adjustment for the effects of observation time on mean temperature and degree-day computations. J. Climate and Applied Met. 24:869-874.

All this may impact how close you feel you can come during model calibration & validation. [Added 6/2002]

Q130. I noticed that when I increased the Percent Possible Sun variable, the predicted water temperature decreased. Why is this? It seems kind of counter intuitive.

A130. Your observation is a good one. I think this is covered in the help file and other places, but I don't remember for sure. Basically, the percent possible sun and solar radiation input values are not truly independent variables. When you increase the percent possible sun you are, in effect, reducing cloud cover. But if you make this change while leaving the solar radiation at X (whatever), the same solar energy is entering the water. So what you have really done then is decrease the radiation that would have been coming from the clouds. You will see this if you look at the heat flux values on the right side of the screen. Increasing the percent possible sun decreases the "atmos" flux because clouds are contributing less of their own radiation. Interesting huh? [Added 6/2002]

Q131. I am looking for the Cinquemani et al. 1978 publication for ground level solar radiation. Do you know if that is on a web site somewhere?

A131. I am not aware of it being on a Web site. It may be difficult to find; try a land grant university. If you can't find it, I could fax you the relevant pages for your area. [Added 6/2002]

Q132. Is the annual average annual air temperature used for anything other than the temperature of groundwater inflow? I am trying to calibrate my model for summertime conditions, and found that in order to get my temperatures high enough I had to increase the average annual air temp by a few degrees. But I wonder what else I may be fictionalizing by doing this. I know I can put in the GW inflow temp reach-by-reach if need be.

A132. Yes -- ground temperature as well as accretion temperature. [Added 6/2002]

Q133. Is the percent sun recommendation still to use solar rad data, and back-calculate it with SSSOLAR?

A133. I still think back calculating is the best alternative. You may use SSTEMP to do that. [Added 6/2002]

Q134. Is the annual average annual air temperature used for anything other than the temperature of groundwater inflow? I am trying to calibrate my model for summertime conditions, and found that in order to get my temperatures high enough I had to increase the average annual air temp by a few degrees. But I wonder what else I may be fictionalizing by doing this. I know I can put in the GW inflow temp reach-by-reach if need be.

A134. Yes -- ground temperature as well as accretion temperature. [Added 6/2002]

Q135. Here's another question on SSTEMP inputs. For air temp, humidity and wind speed, I have understood that these are generally based on regional data, modified perhaps to account for elevational differences between the met data site and the location of interest. Could these or should these inputs account for local microclimate conditions? My thought has to do with representing or possibly doing sensitivity analysis on the effects of buffers on local climate variables and hence stream temps. Any precedent for this?

A135. Absolutely! The better your data represents what's going on right at the air-water interface, the better the model should do at predicting temperatures. Regional temperatures are fine for a scoping-level analysis, and useful if you want to know direction and relative magnitude of change from some specific management action(s), but if you really want to be "exact", use the most "exact" data you can. [Added 6/2002]

Q136. Would you answer a couple SNTEMP questions? The "observed solar radiation at ground radiation" variable in the meteorology file is said to be optional. I have not found in the manuals what difference there is in output or predictive ability whether the variable is used or not. Is there any benefit to putting solar radiation data in the meteorology file (since I have that data)?

A136. SNTEMP will calculate what it thinks the ground level radiation will be given air temp, relative humidity, elevation, dust, etc. But if you have "real" measurements, it should always be best to enter that data. Then, at the top of Table 6 (I think) the program computes the ratio of what you enter to what the model would have used. If it is within 10% or so, you are probably ok; otherwise, you may have done something wrong. [Added 6/2002]

Q137. I would like to verify that the following is true:
In your class manual you state that solar radiation values for the last year in the meteorology file are applied to all years. This gives me the impression that, if you supply SNTEMP with solar radiation values, those values should not include the effect of clouds or dust in the sky. I assume that storms are covered with the "percent sunshine for the time period" value. Because measured values tend to include the effect of storms or dust, I'm thinking that, in general, the measured values should only be used to establish the values for the "percent sunshine for the time period" and should not appear in the meteorology file.

A137. Perhaps the class notes are not as clear as they could be. The ground-level solar values you enter for the last year are used to calculate the "fudge factors" for each time period shown at the top of Table 6. These factors are the ratio of the solar value the model calculates and the value you supplied. These factors are then applied in each year for each time period, respectively.

As an example, the model is calculating that there "should" be about X joules on day 1, but the input file says you measured 2X joules. So for day 1 of each simulation year, the model calculates solar radiation, given cloud cover etc., and multiplies by 2. Then, just to complete the picture, the model then applies shading to those calculated values. This means that supplied solar radiation should be ground level, unshaded values. [Added 6/2002]

Q226. Thanks for the quick response. I'm a little confused about the following statement, though:

"It might be wise to test your formulation by doing some selective "back calculations". By this I mean experiment with the % possible sun until you get the observed ground level solar radiation. See how well that matches your estimates."

How do I play with %sun in such a manner that I 'get the observed ground level solar radiation'? Solar radiation is an input that I supply, so how can it change? Are you referring to the heat flux results, and if so, to which one(s)? I assume it would be the solar heat flux, but I want to be certain that I understand what you are suggesting.

Also, if my approach to estimating percent possible sun is valid, may I respectfully point out that you specifically said in the FAQs that measured solar radiation cannot be used to estimate percent possible sun. Based on the number of questions on this point, it seems to be a headache for many people, and perhaps a revised response to the question might be in order? I’m probably getting ahead of myself here, since I have not run the model with these numbers yet. I'll let you know how it goes.

A226. I probably need a refresher on the FAQ myself! I searched quickly through the meteorological page and found this statement in A23:
"Unfortunately, ground-level solar radiation cannot be directly used "in lieu" of cloud cover." If it is this statement you are referring to, I do believe it is correct. If however I have made a mistake elsewhere, please let me know and I will fix it.

As to the Back Calculation issue, here's what I have in mind. Start up SSTEMP. By default it shows that for the combination of input variables, specifically the meteorological variables, and the estimated solar radiation is 565.410 Langleys/day. Let's say that you knew from your measured data, that it really should have been 550 l/d, but also knew that your percent possible sun was only an estimate (90%). Assuming that % sun was the only variable that was uncertain, you could by trial and error change the % sun value until you got very close to the 550 l/d that you measured. I just did that and derived a % sun value of 85.5%. This change resulted in a ground-level solar radiation value of 549.495 l/d. You could then compare the 85.5% with the value derived from your technique.

I believe the procedure described above is valid (albeit tedious) if and only if %sun was the only real uncertainty. The further you get from this ideal case, the more assumptions you are making. In fact, transferring solar radiation from off-site, where temperatures and humidities are different, is itself an assumption, but probably not a bad one and frankly you have few alternatives. And no one really knows what the dust coefficient and ground reflectivity should be -- they are just estimates. But I don't want to make a mountain out of a molehill. If you have good measured solar radiation data, you are miles ahead of most applications, and then % sun really matters very little unless you are trying to model very unusual circumstances - but then that is a tangent.

Q227. I have one additional question - The user's manual for the model states that input data for the "possible sun" variable can be obtained from the LCD. I checked the Western Regional Climate Center website and am not able to find cloud cover data for New Mexico. Do you know where I can find data for this variable? The New Mexico Climate Center (through NMSU) also does not have data for this variable. I would greatly appreciate any information you can provide.
This site provides possible sun for several western cities:
http://www.wrcc.dri.edu/htmlfiles/westcomp.ovc.html
I found this website (possible sun data) also:
http://www.ncdc.noaa.gov/oa/climate/online/ccd/avgsun.html

A227. Something like these data is certainly better than nothing at all. It appears that these values are, however, only for daylight. If you are willing to assume they also represent night time values, so much the better. Often folks are interested only in really hot days anyway when you might assume little or no cloud cover, but to make a tight fit to a long time series, you really need to estimate these values using the departure of solar radiation from maximum possible or use s/so as a calibration parameter (within a reasonable range). [Later – I realized that I often assume maximum temperatures on days with little cloud cover, but this may not in fact be true. I think it more likely that maximum water temperatures occur when both air temperature and solar radiation are high, but also when there is partial cloud cover that “traps” the heat in the atmosphere. Always look at your data!]

Q228. We are trying to model temperatures in parts of the X. River and found a NSW weather station at the local airport that has nice hourly data on everything, including cloud cover. Except---now that we made two long field trips to collect calibration data, we find out that the local station apparently quit collecting any kind of cloud or solar radiation data in about 1997. Do you know what kind of weather stations in general still collect cloud data or solar radiation data?

A228. Welcome to the imperfect world. I have been told that cloud cover data have been largely discontinued throughout the US. Many people, of course, have asked the same question and there are a variety of 'solutions' out there -- none perfect. Please see elsewhere in this FAQ. Also:
1. see http://www.wrcc.dri.edu/htmlfiles/westcomp.ovc.html
2. check agricultural experiment stations
3. come up with something entirely new -- you are bright ;)

We had a problem with this on the Klamath, 'solved' with some really crude translations of precipitation. But if you have neither solar nor cloud cover data, you could be in trouble unless you can rely on historical averages, or something like that.
Later, this person responded with:
Since you were so helpful to me, I'll tell you what eventually happened. We paid for hourly data from the Grand Junction airport, from NCDC. I’m attaching the documentation, which makes me wonder if cloudiness data disappeared with the conversion to automated observation stations. (See "NUMERICAL CODES LISTING FOR HOURLY OBSERVATIONS")

However these data do include an hourly variable for 'sky conditions'. Unfortunately they only refer to conditions below 12,000'. I decided that better than nothing was to convert sky conditions to an estimated cloud cover. I stripped off the first two alpha characters from the ‘sky conditions’ field, and used information in the documentation to make this lookup table that converts to cloud cover:

Sky code        CloudCover
BK                   0.75
CL                   0.00
FE                   0.13
OV                  1.00
SC                  0.44
VV                   0.10

This makes the data kind of discrete, but I suspect it is no longer the greatest uncertainty in my temperature model...

By the way, the data arrived with a lot of extra lines: more than one value that fell within the same hour. However, when I deleted all the lines that had missing values for temperature, humidity, etc., there remained one good line per hour. The observations also were not taken exactly on the hour, so you have to round the observation time off to the nearest hour. Only a few hours (maybe 10-20) were missing in all of 2003. So the data looked messy at first, but really were quite easy to clean up and use.

Q229. Do you have a good estimate handy for that area on dust coefficients (d)? In the manual, there are estimates for Washington DC, Madison and Lincoln only.

A229. As far as the dust coefficient goes, Information Paper13 sums it up. There is no place where you can get this data, as far as I know, and therefore it becomes a calibration parameter. However, as I always recommend, don't change this parameter value too much, especially on a daily basis, unless you have a good justification for doing so. Trying to calibrate too closely is likely just an exercise in futility that will not truly improve the predictive power of the model.

Q230. I have a question about the dust coefficient. In the SSTEMP documentation, the dust coefficient falls in the range of 4 and 13 (p. 9 of "Stream Segment temperature Model Version 2.0 revised August 2002").

In the example input data files for Green River for SNTEMP, the values fall in the range of 0.11 to 0.19. The self-study course page 100 refers the reader to "page II-13" for more information, but I can't find that page.
Is the dust coefficient a percent, so that the SNTEMP inputs are decimal values (rather than percent)? If so, why do the Green River coefficients exceed the range in the SSTEMP documentation (because it's a bleak desert?)

A230. SSTEMP and SNTEMP differ in important ways. SSTEMP characterizes fractional parameters as percentages where SNTEMP uses values between 0 and 1.

Information Paper 16 implies in the discussion (II-13), but do not know for sure, that Theurer 'calibrated' the dust coefficient to the Green River data set given what he had as solar radiation data. One might suppose, in retrospect, that a desert might have more 'dust' than other more thoroughly vegetated landscapes such as those that TVA had studied.

Most importantly, the dust coefficient (along with ground reflectivity) perhaps should be viewed with some distrust. In many ways, they are fudge factors that attempt to account for the scattering of short wave radiation. From my experience, they rarely are very sensitive, but may be useful in some applications.

Q231. I'm putting together a time period file for an SNTEMP model that I am using along a couple of local rivers to get daily stream temperatures from June to October. I am using Table II.1, and II.2 from Information Paper 16 to get some estimates of maximum and minimum annual dust coefficient and ground reflectivity values. I am then using equations II.19 and II.20 to get a distribution of these parameters over the time period of interest. But, using those equations I seem to be getting some weird numbers. For example, for reflectivity I am using a maximum value of 0.7(old snow) and a minimum of 0.29 (late summer vegetation), but when I substitute those numbers into equation II.20, about a quarter of the year has negative reflectivity. If I use equation II.19 for the dust coefficient, no values end up below zero, but there is a period of the year where the values drop below the minimum value I entered into the equation. I use MS Excel for this which operates by default in radian mode, so I tried it in degree mode and the values given by equations II.19 and II.20 seem to give more reasonable values but they increase through the year rather than following a sinusoidal cycle. Can you please make some comments on this?

A231. To the best of my recollection, you are the first person to have ever asked about doing this. I must admit that I have not tried this before, mostly because I always felt that (1) it was a bit artificial to distribute values that were merely guesses anyway, and (2) that seemed to be derived with parameters (like the day 213 and 244 in the equations) from unknown locations. That said, how can we address your question?

As best as I can tell, the two equations you reference in Information Paper 16 are simply wrong. The general form for these equations should be:

where x is the predicted value
                        M is the overall mean
                        A is half the overall amplitude
                        C is the phase adjustment coefficient, i.e., to adjust the time of maximum and minimum predictions

Thus, equation II(19), for example, should be rewritten as:

However, I caution that the 213 value (C) may or may not be right for your location. Unless you have a burning need to do this, I would ask what you are really gaining beyond using a fixed (but variable during calibration if necessary) value. There well may be a good reason, but make sure you can justify it!

Q232. Am I correct in assuming that the extraterrestrial radiation computational procedures for SSTEMP are identical to that of SNTEMP?

A232. To the best of my knowledge, the answer is yes. There is somewhat of a difference in implementation, however. In SSTEMP, if you don't know the solar radiation, it will estimate it for you. This is true in SNTEMP as well, but in SNTEMP, if you are running more than a single "year" simulation and you do supply ground level solar radiation, the program only looks at the last year's worth of data and uses the ratio of what it estimates and what you supply to adjust all the other years' estimates for each time period of the year. These ratios appear near the top of Table 6.

Q233. This may seem like a silly question but it occurred to me that since SNTEMP input files mandate strict character spacing, is it necessary to include blank spaces where either a default is preferred or if perhaps the value entry does not occupy the full character limits?

For example, the stream geometry file has spaces for ground temperature in field 57-64, and streambed thermal gradient in field 65-72. If these fields are left blank, a default is used. Is it necessary to include blank character spaces for fields 57-72, or can I just hit a carriage return after I enter the maximum stream shading (field 49-56)?

A233. Few questions are silly. It is true that SNTEMP is very picky on adhering to columnar fields. Including decimal points in your numbers reduces the visual problems, and generally solves most issues, but I can think of a few errors I have caused by not being careful. However, the issue you bring up is a good one and different. To the best of my knowledge, any field that is blank or that does not "exist" because you terminate the record with a carriage return, will be given the default value. Strictly speaking this is probably more of a FORTRAN compiler issue than an SNTEMP issue, but it works for the compiler we are using.

Q234. A quick question regarding ground reflectivity. Do you use values that describe the ground surrounding the river or do you use the value for the river itself? It seems like you’d use the value for water but your user’s manual includes values for other ground types.

A234. Ground reflectivity is meant to characterize the basin as a whole, not the water alone. Reflection from the water's surface is handled separately in the model.

Q235. I am gearing up to use the SNTEMP model and have been reading through the online course and other material available to help me get up to speed to use the model. It is being applied to the X. River for FERC relicensing studies. My question to you is to find out how important it is to have the % possible sun data…should we install a solar radiation meter at the site or can we rely on value taken from locations in the general vicinity.
I notice from the Information Paper 13 that stream temperature is relatively insensitive to percent possible sun. Can the model be run without this value? Thanks so much in advance for your help.
Follow-up – Thanks so much for answering my questions. I think I will try the back calculation approach. However I have one more question that perhaps you could give me some guidance on. Our source of solar radiation data is from a location about 10 miles away and slightly lower in elevation that our study site on the X. River. One thing to note is that there are some holes in the data (it is a remote station with the data relayed by satellite) which are equivalent to up to 25-30% of the days in the record for some of the months. Is it reasonable to use this data as input into the model (and/or to calculate the % cloud cover) or should we put the effort into setting up our own monitor for solar radiation at the site. Thanks once again for your help!

A235. If you can find percent possible sun in the vicinity, that should work fine, but it has become increasingly difficult to locate contemporary sources for this. Some agricultural experiment stations or irrigation management facilities may have this data, or something that you can use as a substitute. We have been trying to use other methods, some of which don't work very well. Look at some of the other FAQ responses for more.

Can you do without it? I would generally suggest that almost anything is better than nothing as long as you can justify it. But there is certainly nothing wrong with either (1) trying the model with and without data to see which works better, (2) or being inventive. I think it is good to have %sun because I feel that it results in a better simulation of daily maximum temperatures, but I cannot prove that.
Follow-up - I'm not sure I completely understand your question, but let me take a stab.

I'm not entirely sure what SNTEMP will do if you supply a partial data set for %sun. I suspect it will take the values you give it and use its own computation for the rest. (By the way, remember that SNTEMP only allows input for %sun for the last year of the simulation. If you have multiple years, the program will use those same input values for each year time step by time step. Sort of peculiar, but that's what it does.) Then, assuming what I said above is true, SNTEMP will print out a table of the ratio between what it "thinks" the solar radiation should be for each time step to the value you input. These ratios are printed at the top of Table 6. If there are missing values, the ratio printed will be 1.0.

I would look to see if the ratios the program prints are all generally between 0.9 and 1.1. This would mean that, given all the other meteorology and time of year information, that your %sun data (or estimates) agree with SNTEMP's estimates reasonably well. This should add confidence that all is well. If there are major disagreements, then you'd need to puzzle out why. The major reason is the units for %sun that can be confusing.

Now, I see that I didn't really answer your question about installing your own meteorological station. Personally, I rarely think it worthwhile unless you really need the accuracy that would come with it, since if you did put in a solar instrument, you might as well go ahead and get air, relative humidity, and wind speed. If this is likely to be a controversial project, installing your own station to -- at a minimum -- verify that the distant station's data can, or cannot, be translated to site, would be a good thing.

Q236. I am trying to generate daily values from 1984 through 2004 for the “percent sunshine for the time period” variable in the SNTEMP meteorology file.

I have daily “average sky cover” data from the X Airport from 1984 through 1996 and use it in the formula II(22) on page II-16 of the SNTEMP manual to get “percent sunshine for the time period”

Daily solar radiation data are available at a nearby weather station from 1987 through 2004. Is there a method for directly converting solar radiation to “percent sunshine for the time period”?

If not, is there a method for converting solar radiation to “cloud cover” or “actual sunshine duration on a cloudy day” so “percent sunshine for time period” can be calculated using formula II(22)?

Formula II(22):
Percent possible sunshine = S/So = 1-(cloud cover)5/3
S = actual sunshine duration on a cloudy day (hours)
So = sunrise to sunset duration at the specified site (hours), which can be found in output Table VI

A236. Basically, you are on the right track. Use midnight to midnight for the sky cover and convert using the formula you cited. You can try including observed solar radiation to see if it improves the model, but I doubt that it will on a day-to-day basis. However, it MAY reduce your overall model bias. If so, this will be a good justification for tinkering with the Global solar calibration coefficient. Ultimately, as you suggest, I doubt that using one year of solar data that is applied to 20 years would be a good idea.

Is there a method for directly converting solar radiation into percent sun? No. One thing I have considered, but have not had the time for, is a reverse calibration method that would, in essence, run SSTEMP to figure out (more or less by trial and error) what the percent sun would have had to be given that I had good solar radiation (and everything else!). Not perfect, but you could do this with a set of representative days throughout the season you are modeling and see if it might help you develop a regression of some sort.

Averaging the minimum and maximum humidity is perhaps the best that you can do. If you are able to find hourly or 4x daily, you might be able to see if there is some consistent bias in averaging only the two values.

All of these uncertainties just provide justification for calibration. Just recognize that you will likely have somewhat larger day-to-day error (and even occasionally quite large single-day error), but the model will likely do very well overall in capturing the seasonal trends and have a very high r-square. If single-day error turns out to be an issue relative to your objectives (and the demands of others), you may have to tinker with some of the more suspect daily values for model inputs that have higher uncertainty (like percent sun and humidity). Do so with caution; there is such a thing as over-calibrating your model -- but no perfect answer for when to stop.