History and Technical Information

WXSIM is so unique that a first-time user will likely not realize just what it is supposed to, and can, do. Perhaps the best way to convey what the program is about and put it into proper context is to give a (fairly!) brief history of how and why I've developed it. In addition, some users will want to know some of the technical details, so that the program won't seem quite so much of a 'black box'.

First of all, I've been a 'weather nut' since the age of twelve, along with a strong interest in astronomy that started much earlier. Since I like to apply numbers to anything I'm interested in, I quickly became fascinated with temperature forecasting. During a typical day at home, I would interrupt other activities every half hour or so just to check the temperature, and at times I even mounted thermometers at school so I wouldn't miss anything. From all this I developed a good bit of skill at forecasting temperatures under a wide variety of conditions.

By the early-mid 1980's, I had earned B.S. and M.S. degrees in physics and had the mathematical tools to approach the problem more objectively. My very first effort was to model a diurnal temperature curve assuming incoming solar (mainly visible) energy proportional to the sine of the sun's angle above the horizon and outgoing terrestrial (infrared) radiation proportional to the fourth power of the surface temperature (Stefan-Boltzmann law). The model was iterative, meaning that the state of the model was updated frequently based on the most recent state, to produce a type of integration with respect to time. A programmable calculator was used at first, with the location assumed to be the equator at an equinox, with the sun up 12 hours and passing straight overhead.

Two constants, or 'tuneable parameters' had to be introduced here, in order to tell the temperature how much of a 'kick' to experience from a certain duration (i.e. an hour) of incoming or outgoing radiation. These constants (call the one for incoming radiation 'A' and the outgoing 'B') depend on a number of factors, such as the intensity(i.e. W/m^2) of the radiation, the specific heat capacity of the surface, and others. At first I assumed the location to be the equator at an equinox, with the sun up 12 hours and passing straight overhead. Making the ratio A/B large increased equilibrium temperatures. Making the product AxB large increased the diurnal range.

By adjusting A and B, I quickly got realistic temperatures and diurnal ranges (assuming clear skies for now), but the high temperatures were occuring too late in the afternoon. To get a realistic (i.e. 3PM) time for the high, I had to 'crank up' the product AxB which made too large a range.

I knew that other factors were at work, such as heat flow from beneath the surface. Since the rate of heat flow is proportional to the temperature difference between two bodies, I used a simple 'restoring force', pulling the temperature toward some pre-set value much like a spring. By adjusting the 'spring constant' (tightness) of this 'spring', I quickly got much more realistic curves.

But what pre-set value was appropriate? At first I was modeling only the equator, so the daily mean, seasonal mean, and annual mean temperatures were all the same and quite appropriate. By this time, though, I'd generalized the code (now on an Apple II, I think it was) to calculate sun angles at any time of day, any day of the year, anywhere in the world. To include seasonal effects and model something corresponding roughly to sub-surface temperature at various depths (or perhaps upper air temperatures, as yet not explicitly included), I used four 'normal' temperatures, and annual normal, a seasonal normal, a time-lagged seasonal normal that I found necessary to get seasonal effects in phase with reality, and one I called the 'air mass temperature' (which I found later corresponds quite closely with the average boundary layer temperature).

Next I wanted to include clouds, which radiate quite a bit of infrared and can block a lot of sunlight. I also needed a way to specify their temperatures. Besides, even clear air radiates quite a bit of IR, so I knew I'd need to include the atmosphere in general. At first I chose four layers, roughly equal by mass, but with the nearer-surface layers weighted a bit disproportionately as they have a more direct effect on the surface. I studied graphs of transmission of various wavelengths through the various gases in the atmosphere and came up with algorithms for computing the albedo and emissivity of atmospheres with various amounts of cloud cover and humidity.

At this point I knew I could include radiative transfer among layers to iterate their temperatures, but since this would require much more computing time on a program that was beginning to get rather slow, I decided to leave these fixed at some seasonal normal values, determined from the various 'normals' mentioned earlier and a standard lapse rate.

Now the program was producing realistic temperature curves for seasonable weather under various sky conditions. I developed algorithms for computing the various normals so as to avoid having to enter them every time. I did realize, though, that the air mass temperature needed to vary with the air mass! The problem of how to determine an appropriate value was the next step.

I decided to let the program do a 'calibration run', starting from a normal temperature for the season at one of the two times of day when the temperature crosses the daily mean. I developed algorithms for these, and in my research found that they vary with wind speed and cloud cover (among other things), but typically occur around 10-10:30 AM and 8-9 PM. By letting the program run under the normal conditions until the intended start time, and then comparing the calibration run's temperature with the input initial conditions, a departure from normal was established, in turn helped determine the air mass temperature. Another approach I used as a back up was an input for the high and low temperatures in the last 24 hours, assuming some degree of persistence in the air mass temperature.

All the constants and algorithms discussed above have been part of the program since about 1983, and have been tuned and re-tuned countless times as I collected large amounts of data on temperature curves, climate and altitude effects, and much more. Meanwhile, I added more and more variables to the brew. A few of the more important examples will have to suffice here:

Wind speed:
Stronger winds mix the air better, causing both a sluggishness to respond to the radiative driving forces and a pull towards air mass temperature. In fact, I found I had to produce a careful balance of both effects to fit my collected data. In addition, temperature inversions can form at night with light winds. A rather involved routine is used to 'mix down' warm air from above at an appropriate time in the morning under such circumstances.

Dew point:
Formation of dew, fog, or frost releases latent heat that slows the cooling of the surface. The evaporation of this water in the morning temporarily slows the daily warm up. I've studied and tried quite hard, with rather good success, to model these effects.


Advection (of both temperature and dew point):
This is CRUCIAL for realistic temperature forecasting. I've developed a rather complex routine for this, using wind speed and upwind temperature and dew point profiles (derived by any of three different methods). The most advanced method involves the user inputting (or importing from a data file such as can be downloaded from the internet) actual data for upwind sites. Wind speed, sky condition, and even longitude (for time zone differences are taken into account). Generally, straight-line air trajectories are assumed, which is usually reasonable for the short term forecasts that are WXSIM's specialty.

Diurnal variations in temperature-related variables:
These include wind and low-level cloud cover. Wind speeds are usually stronger in the daytime, as mixing lets the surface 'feel' more of the usually-stronger winds higher up. At night, under temperature inversions, the wind may go calm even while significant winds blow aloft. WXSIM models these effects empirically, and even has an option to model sea breezes for coastal locations. Cumulus clouds may develop with daytime heating as air parcels rise. Low stratus can form in some conditions overnight, and then 'burn off' the next morning. Options to model diurnal variations in these types of clouds are available as well.

There are more such variables, but now back to the main story line!

Most of the initial work on everything discussed above was done on a Commodore 64, bless its slow soul! I finally got access to faster PC's in the early 90's and converted the code over to QBASIC. This afforded an opportunity for general improvements.

One such area (actually already well under way in the C64 version) was the inclusion of 'interrupt codes'- ways of injecting new information into the program as it runs. This feature is extremely important to operational use of the program, but may be overlooked by first-time users because it is very unique. To put this feature in context it is very important to understand more about the operational nature of WXSIM:

WXSIM is mainly a local model and is therefore generally ignorant of large-scale weather patterns (the advection routine being a partial exception). For this reason it can't - on it's own, anyway (more on this shortly!)- forecast 'weather' in the broader sense of the word. My first effort at addressing this was 'interrupt codes', which I have maintained as a 'legacy' feature, though it's vastly superceded by newer features.

Though hardly anybody uses the interrupt codes anymore, here's an example: It's a clear evening with light winds, but the official forecast, the big computer models, and satellite pictures all suggest increasing clouds after midnight and then rain by morning. You could start WXSIM with the actual initial conditions and set it to run slowly. When the model time reaches the point when you think clouds should increase, a couple of keystrokes or mouse clicks will increase the clouds. The previously falling temperature 'inside' the program will perhaps level off or even rise as infrared radiation shines down from the clouds. When you think it's time, another keystroke or click starts precip of the desired intensity. Quickly WXSIM responds with faliing temperature and rising dew point until, if you make it rain enough, the air becomes saturated and the temperature and dew point largely stabilize. WXSIM also makes the decision as to whether any preicipitation you inject will be rain, sleet, snow, etc. There are over 50 such interrupts; you can even model the effects of solar eclipses!

By the time I had all of the above in the program, the importance of modeling upper air temperatures was becoming more obvious. I changed to a five layer model, making these new levels correspond rather closely to 5 of the 'mandatory' levels used in RAOB soundings and upper air plots. I analyzed hundreds of soundings (mainly for my area but many others around the world as well) to improve my algorithms for relating upper air temperatures (including their somewhat small diurnal variation) to surface temperature. In the process, I developed code for calculating heights of various pressure levels, thicknesses, and related parameters.

About the same time, I got Internet access and FINALLY had regular access to real-time upper air data. I made these temperatures and dew points part of the data input, though keeping the option to use the algorithms I'd spent so much time developing. In fact, you can input these initial conditions and then the older algorithms work with them to produce forecast values of upper air temperatures, which are in turn used in calculating new surface conditions, which then effect small changes in the upper air conditions, etc., in a finely tuned balance.

I actually 'marketed' this DOS based version on a small scale (several hundred downloads of the shareware version and about 15 full registrations). While I got less feedback than I would have liked, that that I did get was quite positive. A few of these users were very helpful in providing feedback that helped the program grow I was especially flattered that a couple of them were professional forecasters who found WXSIM to be very useful, especially for short-term temperature forecasting.

The DOS version was rapidly becoming 'archaic' as more and more users expected the convenience of Windows-based software. I decided in mid-1996 to make the change over to the Windows environment, via Visual Basic (first 2.0 and later 6.0). This, combined with the growing availablity of surface, upper air, and model forecast data on the internet, led me to create the 'Interrupt Planner', a graphical interface that can display imported model data, allow manual modification of this data, or let you enter your own program interrupts in advance.

A HUGE improvement came in 2003, when I developed the companion program (using Visual Basic.Net) WXSIMATE. This program downloads various types of surface, upper air, and forecast model data from a variety of (free) web sites, including specially prepared data interpolated for your exact location (if you're registered user) from NOAA's GFS model. It also can import data from a large variety of home weather stations, via four widely used software packages: Weather Display, WeatherLink, Virtual Weather Station, and Cumulus. WXSIMATE prepares files from these data, ready to be ingested into WXSIM, to automatically populate not only initial data, but also the Interrupt Planner, using external model data (NGM and/or GFS).

In 2006, I finally produced what many users had long been requesting - a hands-off, automatic way to run the program. This has proven very useful to many people, especially owners of home weather stations who upload data and forecast to their web pages. I use this mode myself for most forecasts now, but still believe manual interaction with the program produces the best results. I think there will always be a role for each of these approaches.

In more recent years, I've added two separate ways for the program to "learn" from its "mistakes" and correct several kinds of forecast biases (in temperature and humidity). One of these works via the companion data analysis and display program wret.exe, which can in turn by automatically operated by the optional tool autolearn.exe. This analyzes past forecasts, usually a few months' worth - plus some from the same season the previous year - and compares these to what actually happened (via your home weather station). It creates the bias correction factors for use in WXSIM. Also, I developed a tool called WXSIM-Lite, which modifies GFS forecast data according to your site characteristics, and also has a self-teaching tool much like the one in wret.exe. The resulting forecasts can then be blended in with WXSIM's native one, to produce even better results!

The above is only a brief overview of what the program is and how it has come to be. I've collected and analyzed a great deal of data over the years and have run the program thousands of times, developing scores or hundreds of routines for dealing with new problems as they came up. The many constants in the program have been adjusted and re-adjusted frequently in light of new information. I'd be glad to answer questions if anyone would like to know more.