NOTES ON WXSIM VERSION 2017, Build 1.2
              (c) Copyright Thomas J. Ehrensperger 2017
==================================================================================

NOTE: The following revision history takes up most of this document.  If you are a
user, you may want to scroll down past it, especially to the section on GETTING
HELP.  Note: a new version of the WXSIM Quick Start Guide (wxsimquickstart.pdf) is
now included in this download package, and can be found in your main WXSIM folder
(usually c:\wxsim).

==================================================================================

CHANGES SINCE 2017 Build 1.1:

The solar eclipse form was changed so that the actual month, day, and year of the
eclipse are entered instead of the previous method of giving the number of days into
the forecast.  This way, the form does not need to be updated daily as it was before
for an approaching eclipse.

The eclipse data is now stored in an external file called ecdata.txt, so that if
the program is closed it can still “remember” the eclipse on boot-up.  Also, a third
button for accessing this form was added, to the Auto Run and Other Settings form
(it is also accessible from the Interrupt Planner and from tab 1 under Preferences).


CHANGES SINCE 2017 Build 1.0:

Data types were added in the cty.fdt file to enable more versatility with wind speed
forecasts for wind turbines (typically between 40 and 80 meters above the surface).
The wind behavior can now be made even more site-specific than before (allowing for
a range of surface roughness and inversion-proneness) and also can now supply winds
at two heights (one half that of the other, customized one).  Note that this feature
is available only if it was included in the customization.

wret.exe can now handle a change in file names in CumulusMX, where (at elast under
Spanish settings) a period now appears after the month abbreviation.  WXSIMATE and
WXSIM-Lite also had changes allowing for this.  In each case the name change is
auto-detected, so no user action is required.

ADDITIONAL NOTE: Occasionally users may encounter Permission Denied (VB error number
70) errors, which shut down the program.  I declined to attempt anticipating all such
errors in my error trapping code, out of concern about interfering with other error
trapping routines.  The cause is usually very simple: a WXSIM file is being used by
another process, which CAN be another program in the suite (i.e. WXSIMATE), if that
programs gets stalled somehow or is scheduled to run overlapping with WXSIM.  Another
cause of the problem could be if the user has opened a file such as latest.csv or
latestturbine.csv for viewing in Excel, and left that open.  Being alert to these
possibilities will likely prevent the error from ever appearing, or at least make it
fairly easy to fix if it ever does.


CHANGES SINCE 2016 Build 1.2:

Added the ability to customize shadowing by mountains, and effects of sloped terrain
in general (on solar radiation)

Fixed a bug which on rare occasions caused the date to revert to the start date
during the forecast (I think only one user ever reported this, but I was able to
reproduce and fix the problem)

Added an option (under Start/Auto run and Other Settings) to omit humidity (dew
point) bias and WXSIM-Lite corrections, which keeping all the temeprature stuff.
This was mainly motivated by one user whose station's hygrometer totally failed, but
I've seen other questionable humidity data in users' files before, so this may have
some wider application.

Created WRETMATE, a companion program (openable either alone or via buttons in
wret.exe, autolearn.exe, or wxsimlite.exe) which allows you to easily manage the
large number of old forecast (.wxf) files which can acculate over time and potentially
make WXSIM-Lite or WRET/Autolearn rather slow in completing their analyses for bias
corrections (“learning”).  This new program allows you to (reversibly quarantine
archived forecasts that are too old or have non-standard names.  It also lets you
randomly cull the list of forecasts down by a percentage of your choice (i.e. if you
were making forecasts every hour, you could trim the analysis set down to, say, an
average of 5 per day, for quicker processing).


(Note: Version 2016, Build 1.3 was experimental and not officially distributed).


CHANGES SINCE 2016 Build 1.1:

A new bug (a division by zero error) had resulted from fix #3 in Build 1.1 (below),
for users having selected the (mostly used in Canada) humidex option.  This has now
been fixed.

Protection was added against older version’s customized files producing an invalid
property value error in the GFS upper air temperature bias settng when used with the
new version.  I had not actually had reports of this, but ran across it while
experimenting with older files to find the problem in #1.


CHANGES SINCE 2016 Build 1.0:

In WXSIM, there were sporadic reports of "No READY or GFS data found".  In some cases, 
at least, this was actually not "true"; data WERE found, but were judged to be 
"unbelievable".  Specifically, every now and then GFS reports a relative humidity 
lower than 1%.  I did have a filter to reject anything that low or lower, but have now 
eased up on the restriction, so WXSIM will "believe" values as low as 0.01%.  These 
very low RH's seem to happen only in upper levels of the atmosphere, so they really 
won't hurt the surface forecast, anyway.

In wret.exe, a couple of people recently reported an error #9 (subscript out of range).
I found this to be because these users had 10,000 or more forecasts archived!  I had not 
considered that large of a number when dimensioning arrays (up to 9999), but in fact
people running close to 20 forecasts a day for a year and half can indeed collect that
many! That's frankly too many for wret.exe/autolearn to use anyway, so the oldest
forecasts (.wxf) should be placed in another folder for safekeeping.  However, I don't
want users to ever have to see the error, so I've "pre-empted" it, by checking the
number of forecasts before the error gets a chance to occur.  Now a message box appears,
instructing the user to get the number down under 10,000 by moving the older forecasts
to another folder.

Protections were added in the functions calculating dew point from vapor pressure, and
dew point from temperature and relative humidity, in order to handle entered or imported
relative humidity values of zero.


CHANGES SINCE 2015 Build 2.1:

A bug, which reversed the sign of ‘residual’ corrections to minimum temperatures
when using WXSIM-Lite, was corrected.  The errors were usually only a few tenths
of a degree, but in rare cases could be large enough to make the ‘minimum’ higher
than the lowest output temperature.

Modifications were made to the way WXSIM uses learned bias corrections from cor.txt
(i.e. created via autolearn.exe) along with WXSIM-Lite data, so that out-of-range
values are not only limited, but the values to be written into .wxf files are made
so that they would not have led to limit exceedence in the first place.

WXSIM now modifies ingested WXSIM-Lite data by taking the values from fdata.txt and
applying a climatological filter, to weakly trend GFS-derived temperatures and dew
points toward seasonal normals.

Changes were made in wret.exe to modify values from previously used correction
factors if these were determined using earlier versions of WXSIM.  This is because
a study of about 20 sites’ correction factors with and without autolearn showed
biases due to items 1 through 3, above.

wret.exe was changed to allow incorporation of learned bias corrections from the
same season as present, from one and two years ago, as analyzed by autolearn using
correc.txt.  These data are also adjusted if they come from periods when an earlier
version of WXSIM was used with WXSIM-Lite (i.e. before this current release date).

The checks for lines of bad GFS data, for both home site and advection, were made
much more robust to shield against implausible (and often error-producing) values
being imported into WXSIM.  These bad values have been very rare – usually only one
error in 81 lines of data if they happen at all – and are almost never on consecutive
lines, so the algorithms here replace bad values with ones interpolated from before
and after the line with errors.  One error in a line is deemed reason enough to
replace ther whole line.

An error message in wret.exe, which could result from a corrupt .wxf file, was
enhanced with instructions about how to correct the problem.

An option (during customization, so this will not affect existing jobs, unless
I custom add the feature to your cty.fdt file) has been added to model the effect
of sloped terrain, so that solar energy absorbed by the surface takes this into
account.  Along with this, shading from mountains (usually just after sunrise or
before sunset) is enabled, with two “mountains” (and “eastern” one and a “western”
one) specifiable.  WXSIM tracks solar altitude and azimuth, and can now “eclipse”
the sun at the appropriate times.

More information was added to a number of error and irregularity messages
(especially the ones reported by wxerr.exe after a WXSIM run completes), in order
to help the user diagnose the problem.

Information was added to the prompt which appears when the DST (Daylight
Saving Time) box is changed.  This prompt offers the opportunity to make the
similar settings in wret.exe and wxsimate.exe the same as in wxsim.exe.  However,
this change takes effect only if those programs are closed, as the prompt now
indicates.  (This setting can be changed independently in all three programs anyway).


CHANGES SINCE 2015 Build 2.0:

Options for customization were added to enable automatic elevation-based adjustment
for the ‘home’ METAR and (separately) SYNOP sites’ imported temperature and dew
point values.  This does not affect customers who ordered before October 24, 2015
and will not often be used in customizations.  The purpose of these additions is to
enabled users in mountainous areas, *without* home weather stations, to get useful
initial surface conditions from METAR or SYNOP import.


CHANGES SINCE 2015 Build 1.3:

A safeguard was added (actually, it had been accidentally disabled in some earlier
version) to avoid forecast errors which could result from use of a too-small set of
historical data when using the learning routine (in autolearn or wret) in conjunction
with WXSIM-Lite.

The enhanced nocturnal decoupling routine (mainly useful for medium-large islands,
such as New Zealand) has been modified, making it slightly stronger (hence colder
nighttime lows in clear, calm conditions) but also phasing it in and out with the
seasons, as it is needed primarily in winter.

A warning message was added, if WXSIM imports local station data showing more than 30
inches (762 mm) of precipitation in the last 30 days, which is a likely consequence
of choosing inches as the units in Weather Display or Cumuls log files, when in fact
they are being recorded in millimeters, in WXSIMATE.

wret.exe can now function with autolearn via WXSIMPRO (theoptional multi-site
controller program), so that separate learned bias correction factors can be
automatically determined for each site.


CHANGES SINCE 2015 Build 1.2:

Air density at turbine height was added as a variable to latestturbine.csv (a file
produced only for sites customized for wind turbine predictions).


CHANGES SINCE 2015 (Build 1.1):

Better error trapping was added to prevent users from attempting forecast runs using
WXSIM-Lite data, if WXSIM-Lite has not yet been used to produce a forecast.

A very rare error, which could produce an ‘Invalid property value’ error at the very
end of a forecast run, has been addressed and probably corrected (according to
initial tests from the users reporting the error).  This resulted from occasional
spurious attempts to open the advection form at or near the end of a forecast run.
While the exact cause of this has not been identified, the protection consists of
having the form unload itself if activated after 98% of the forecast run is complete.
A log file called adv_activate_error_log is now created to document occasions on which
this protection is called upon, even when the error is successfully avoided.

The default bias corrections to GFS data on the 4th tab under Preferences/Settings have
been changed to neutral values, presuming that the new 0.25 degree GFS data has no
known temperature, cloudiness, or precipitation biases.

The data retrieval program, wret.exe, now has a more informative message when it traps
errors due to misplaced data in log files (such as from Weather Display).


CHANGES SINCE 12.12.1:

First, a new naming convention has been adopted, using build numbers and major release
years, starting with 2015 being released just prior to that year.

Most importantly, WXSIM has been modified to use data from the new companion program,
WXSIM-Lite.  That program (included in the WXSIM installation and upgrade packages)
makes forecasts using a different approach, in which GFS (and later perhaps additional
model data) is downloaded, adjusted and interpolated in various ways, and then saved
for later comparison to actual data from a personal weather station.  WXSIM-Lite can
then analyze the results to build a sophisticated set of bias corrections to apply to
future forecasts, somewhat like WXSIM’s own ‘learning’ routine.  Months of testing
have shown WXSIM-Lite’s temperature forecasts to be generally more accurate - by about
15 percent, and maybe more for some sites - than WXSIM’s own forecasts.  However,
data also suggest that WXSIM’s forecasts have indepent value, especially for short
term and nighttime forecasts, so the potential exists for mixing of WXSIM and WXSIM-Lite
forecasts to produce forecasts better than either alone (though only a bit better than
WXSIM-Lite’s forecasts).  This new version of WXSIM allows WXSIM-Lite’s temperature and
dew point forecasts to influence WXSIM’s output to a user-specificied extent.  This is
almost sure to produce the biggest single improvement in WXSIM’s accuracy in many years.
It is possible (and advantantageous) to use WXSIM’s own learning feature concurrently
with incorporation of WXSIM’Lite’s data.  Information is stored in WXSIM’s forecasts
to indicate the extent to which WXSIM-Lite’s data was mixed in, and this
information is carefully taken into account in later use of learned bias corrections.
In other words, both programs can ‘learn’ at the same time without conflict or any
need of second-guessing on the part of the user.

IMPORTANT NOTES: The ability to mix in WXSIM-Lite data is available in WXSIM’s
professional mode only.  Also, the current plan is for WXSIM-Lite’s special data to
become subscription only (at a very low rate, but enough to cover server and ongoing
development costs) at a later date, perhaps in late February, 2015.  Meanwhile, the
data are temporarily free of charge.

The Auto Run form under the Start menu item has been expanded and organized (and
renamed as ‘Auto Run and Other Settings’), and now includes access to the form for
mixing in WXSIM-Lite data and also control over end-of-forecast settings formerly
accessible only (and perhaps inconveniently) on the Output form.

A new option to alter the appearance of WXSIM’s main programs has been added (button
on the new ‘Auto Run and Other Settings’ form).  This allows use of ‘XP and later
Windows Styles’, if you are using Windows 7 or later (it actually causes some bad
display of option buttons in XP itself).  You can toggle back and forth between the
style options to see what you like best.

Various cosmetic and informational changes were made, including a new color scheme
for WXSIM’s Data Entry form.

Potential use of imported GFS data has been expanded to include up to 9 days of data
(the maximum length of a WXSIM forecast), instead of the previous 7.5 day maximum.
This will become relevant when the GFS data downloaded by WXSIMATE is changed over to
the upcoming 0.25 degree resolution version.  The implementation date of this is
uncertain as of this writing, but hopefully will be done by sometime in February, 2015.

Wording of the convective bulletins about ‘Showers unlikely’ and ‘Showers very
unlikely’ has been changed by adding the word ‘Convective’, so that contradictory
looking text about showers being unlikely while (stable) rain is forecast will no
longer appear.

The autolearn.exe program has been updated to version 2.0, which allows graphs of the
history from correc.txt

The Daylight Saving Time setting (always a pain in the past, I know) is a bit simpler
now.  When you change the check box in WXSIM, it should make the same change in
wret.exe and wxsimate.exe as well (that does not work in reverse, though).  I do have
a "warning" system in place, which looks for evidence that the setting does not go
with the computer's clock.  It's still a bit complicated, though, because there are
reasons (at least for me) to alter the setting (for example, in wret.exe, if I'm
analyzing old forecasts from another season).  So, the change is not made
automatically.  However, it should warn you (at least the first time DST status
changes) and you can now make the change globally.

A small bug was fixed: at the beginning of the forecast, the advection routine was
displaying (though apparently not actually using) a "normal" temperature (for the time
and date), instead of the actual temperature, as the "home" temperature, against which
actual upwind temperatures are compared to generate an advection profile. This has
been corrected so that the actual temperature at the time is displayed.


CHANGES SINCE 12.12:

The ability to forecast wind speeds at specified heights above the ground, for use
in forecasting wind turbine power output, was added.  This additional data is
displayed, along with other relevant data, in a new output file called
latestturbine.csv.  This feature is not generally available to all users, but is
something I can customize specifically for the site, based on turbine height,
surface roughness, and (optionally) past wind history.

Warnings and measures have been added to wret.exe to prevent users from trying to
use ‘combined’ data in the analysis for learned bias corrections.  The purpose of
the ‘Combine’ box on the comparison to actuals graph is to allow display of
hourly-averaged data, not to develop correction factors.

A bug in wret.exe, which could cause an ‘Invalid procedure call’ error, has been
corrected.

Another bug in wret.exe, which occasionally and mistakenly caused rejection of data
(for developing learned bias corrections) has been corrected.  This was a simply
typographical error in a variable name in my code.

wret.exe now is able to circumvent a problem involving reading of WeatherLink data.
It seems that occasionally, the first couple days of the month (for one user, anyway)
have some garbled data, either due to the .wlk files themselves, or perhaps to
WXSIMATE's interpretation of that data (which is binary "gobble-dee-gook").  It now
skips over such stuff until it find reliable data and uses only that.  This affects
the autolearn and Auto Select routines, but again, only if you are using WeatherLink.

wxsim.exe has a change which should have no effect whatsoever on any existing
customization.  This is a customizable feature controlling the extent of mixing in
light winds under strong inversions, primarily in arctic regions.  Generally, the
problem (based on data from a site in Yukon, Canada) was that such mixing was too
weak, and this change makes it possible for me to strengthn it, if needed, in
customizing.

An erroneous message telling the user to uncheck the ‘Run optional DOS batch file’
(when it was in fact not checked) in WXSIM has been corrected.  Actually, I am not
sure if this bug was present in the official version 12.12, or if it was only in a
beta version since then.  Either way, it is now corrected.

A rarely occurring, but longstanding (several years!) error #6 (‘overflow’) in both
wxsim.exe and wret.exe has been solved.  This error occurred when the ‘Shell’
command was called to open another program (such as wxsim.exe opening wret.exe at
the end of a forecast).  I finally discovered that it was a case of my having
declared the ‘task number’ to be an integer, but occasionally, on some computers,
the system would assign a number bigger than 32767, which is the highest integer
allowed.  I have now declared this variable as ‘double precision’, which should
totally sove this problem. 


CHANGES SINCE 12.11:

Version 12.12 was completed February 5, 2014 and has the following changes relative
to Version 12.11 (described below):

A more sophisticated treatment of the learned bias corrections has been implemented.
This modifies the “slope bias correction” in such a way that there is a smooth tail-
off in the effect when departures from normal temperature are greater than the
average amount of departure from normal in the analysis.  Something like this
existed in previous version, but the function was discontinuous in slope and did not
reduce the bias sufficiently.  This one reduces it to about a third of the “learned”
value when departures are more than about twice the average amount of departure.
Also, a very thorough statistical analysis of thousands of forecasts, combined with
studies using randomly generated data in Excel, suggested that extending small
sample sizes of data to a larger range of conditions presents a problem: part of the
error in error versus forecast departure from normal is an artifact of using
(necessarily) the forecast departure as a basis, instead of the actual departure as
a basis.  Essentially, a too-warm forecast also tends to be an “above normal”
forecast.  I have now standardized the slope to be defined as appropriate when
standard deviation of departure from normal is twice the standard deviation of the
error itself.  Outside this range, the slope is altered towards being a bit more
“extreme” (allowing greater departures from normal).  I believe this change will
allow better transition between seasons, for instance by anticipating the
possibility of larger temperature excursions in the fall, after a monotonous summer.

Changes were made in wret.exe to the plots of error versus date and versus departure
from normal, to increase readability and reflect the changes listed in (1), above.

Bitmap plots, named errdate.bmp and errdep.bmp, are now made when the plots
mentioned in (2) above are viewed, or when autolearn.exe completes its run of
wret.exe.

The default “distance ratio” on the advection form was reduced from 1.15 to 1.1,
as this now appears to make more accurate fits for upwind advection profiles.

An occasional overflow error (Visual Basic error number 6) resulting from the use of
the Cint function in Visual Basic, with values over 32,767, was corrected by using
Int(x+.5) instead.  This error may have existed for a long time, but the change in
the distance ration from 1.15 to 1.1 may have made it more likely to show up.

A routine intended to better model mixing out of morning temperature inversions was
found to have bad effects (a brief dip in temperature around noon) on cloudy days
with light winds, mainly in winter at high latitudes.  This has been corrected by
phasing the effect out as cloud cover increases.

Changes were made to hopefully avert a rare printer error in cases when no printing
was requested.

Changes were made to slightly reduce the diurnal temperature range and also the rate
of air mass modification in colder than normal weather.  This was based on careful
study and re-running of forecasts of historical data, mainly during arctic air
outbreaks.

A sort of climatological filtering has been applied when GFS model data is being
used, so that temperatures past about 2 days into the forecast are trended slightly
towards normal.  This “correction” is actually only about half the theoretically
optimum value, so as to preserve some of the underlying run-to-run variability, but
still tone down unrealistic extremes which crop up at times.  The treatment is
season and location specific, by taking into consideration typical standard
deviation of error in GFS data along with typical standard deviation of actual
temperature.

Maximum daily snow depth was added (to the existing average daily snow depth) in
the Supplemental Dat section in the scrolling text output and in latest.txt.

Internal changes were made in the main forecast module to allow room for the
additional code.

The learned bias corrections displayed under Preferences/Settings in WXSIM are now
in familiar units (i.e. degrees F or C) instead of the cryptic raw values diplayed
in previous versions.

A failure to clear out old data had sometimes caused brief (only in the first three
hours or less of the forecast) excursions, mainly in barometric pressure, when using
GFS data.  This has been corrected.

A very slight increase in the weighting of the “clear thickness maxiumum” (an
estimate of clear sky maximum temperature based on the thickness of the lowest 130
millibars or so of the atmosphere) was made, so that daily maximum temperatures
will be constrained slightly (a couple of tenths of a degree, typically) closer to
this figure.


CHANGES SINCE 12.10.2:

An oversight in wret.exe caused (only for users of Cumulus) the ‘Comparison to Actuals’,
as well as the learning routines (through Auto Select or autolearn.exe) to jump back to
January, 2013 after December 31, 2013, instead of proceeding to January, 2014.  This
has been corrected.  Since the change involves only wret.exe and the official release
was just yesterday, I am simply repackaging the installer with this change, rather than
renaming the entire version.

Options for sea surface temperature on the Diurnal Breeze form were made more simple
and explicit.  There are now option buttons for either using default sea temperatures
or user-entered ones.  These settings take effect as soon as the OK button is pressed,
and are saved for future runs until changed.

The default (climatological) sea temperature now changes with each day of the
forecast, rather than retaining the value from the first day. 

A typographical error in a warning about far-from-normal sea surface temperatures
was corrected: “10.8” Celsius was changed to “6” Celsius.

Messages about missing local calibration data (from localcal.txt) are now deferred
to the auxiliary external messaging program (wxerr.exe) so that they will not
interrupt auto runs.

The ‘Offset’ and ‘Range’ factors in WXSIM were previously simply stored values which
the user needed to keep consistent with ‘Dep’ and ‘Rng’ in wret.exe (which are used
in developing learned bias correction factors through Auto Select or autolearn.exe).
They were not – and still are not – used in any way in generating a forecast, but
are written into latest.wxf as a record of the user’s intent in wret.exe at the time
of the forecast.  Changes have been made so that the values shown are read, both at
forecast time and when the form is opened, from wret.exe’s initialization file,
retini.txt.  Also, the boxes displaying the two values in WXSIM are now disabled
for user modification, since they need to be enetered in wret.exe to be used.

An unused form (gfsadj, whose functions were incorporated into the tabbed form under
Preferences/Settings several versions ago) was deleted to reduce program size.

Error trapping was improved in wret.exe to avoid crashes when latest.wxf is not found.

Changes were made in the auto select (“learning”) routine of wret.exe to avoid a
“file already open” error that was reported by two users.

Error trapping was improved in wret.exe’s comparison to actuals and learning
routines, by displaying the last line read from a potentially faulty weather
station software log file in the error message.  This allows the user to quickly
find and correct the problem in the log file.  The example motivating this change
was a case of a few dates being out of order in a Weather Display log file, which
caused a ‘Subscript out of range’ error in wret.exe.

Minor cosmetic changes were made in wret.exe.

Appropriate changes were made to WXSIM’s blue-text help file. 

A bug which allowed the year to remain the same in .csv files, when January 1 is
reached, was fixed.  The change also applies to other routines which are functions
of the year, such as climate and solar forcings.

A bug similar to that above, involving the UTC time stamp in the lastret.txt file,
was fixed in wret.exe.  This also now has correct output across the change to the
new year.

In wret.exe, bitmap graphics are now automatically produced for the error as
function of date and of departure from normal graphs when these are displayed.
Also, these are briefly displayed, closed, and graphics created auto,atically by
autolearn.exe when that program is used.

Small wording changes were made in the output of wret.exe’s auto select learning
routine.

Small changes were made in the advection form’s output for quality of the curvature
fit.  Previously, erroneous values for “Spd” and “%” were briefly shown (but not
actually used in the final fit).  Also, the advection site map now shows the number
of sites actually used for the fit rather than the total number found.  

On the data import form, the number of sites found for advection was sometimes shown
too large by one (when MOS runs out and the program defaults to GFS).  This has been
corrected.

A warning message now appears in WXSIM if the status of the DST (Daylight Saving Time)
box does not match the status derived from internal data for the computer (derived
from a comparison of the GMT system time and the adjusted time on the computer’s clock,
considering WXSIM’s time zone information for the site).  This message occurs only at
start-up of WXSIM (as an internal message box) or in auto run at the end of a forecast
(as an external message box which does not interfere with the forecast).  There may be
some users who run forecasts for sites outside of the computer’s time zone.  To
accommodate this, there is an option to prevent the message from appearing after the
first time.

A possible fix to a problem involving a rare problem of failing to get fresh GFS data
on the first run of the day has been implemented.  Actually, the code for this fix
existed in the last two versions, but was probably ineffective because a variable had
not been declared globally; now it has. 

Small cosmetic changes were made to a couple of forms.


CHANGES SINCE 12.10.1:

One or more causes of an occasional error 52 (bad file name or number) were corrected.
As of this writing, such an error is being reported by only one user, with the cause
seemingly something very system-dependent.  If such an error is still encountered,
two possible workarounds are UNchecking ‘Minimize forms’, CHECKING ‘Omit log files’
(both these on the Auto Run form), or (an almost certain fix) having WXSIM close
after auto runs, and be reopened by a third-party scheduler.

Wording was improved to be more instructive in the case of messages about not not
having imported model data.

A bug which often caused failure to use local station data in the calibration run
was corrected.  A separate, but related error was fixed in WXSIMATE as of version
5.3.2, completely correcting this type of error (which had only very minor effects
on most forecasts).

Autolearn.exe has been updated (now version 1.2) to improve clarity of use and avoid
common user mistakes in connection with wret.exe, which also had small improvements
in wording.

wret.exe now formats correc.txt properly even with regional and language settings
using commas as decimal separators (previously older data was split awkwardly into
multiple lines).


CHANGES SINCE 12.10:

A new program called AutoLearn has been added to the WXSIM suite. It allows scheduling
 of automated "learning" runs (for use in WXSIM's Professional Mode) by wret.exe, and
changes were made in wret.exe to accommodate this. AutoLearn is actually a separate
program, with a registration fee for full-featured use. In demo mode, it has a fixed
10 day analysis period, which is too short for optimal results, but can still give
users a good look at how it works. Note that this is for convenience only, as manual
use of the AutoSelect feature in wret.exe accomplishes the same task. 

WXSIM's response to the learned bias correction factors has been fine-tuned. Testing
revealed that, under normal use (including GFS and FOUS data and advection), the
overall temperature correction and the "slope" parameter supplied only just over half
the needed correction on the first try, so that a period of time two or three times
the analysis period (which is often months) would be needed for essentially full
response, by which time short-term and even seasonal effects would be largely blurred
out. The range and dew point factors were fairly well-tuned already, but all four
parameters have now been carefully adjusted to yield full response on the first use,
with or without GFS, FOUS, or advection data.

The range of allowed values in the 'slope' correction factor (which influences the
'pull' towards climatological normal temperatures) has been expanded to +/- 40%
(instead of the previous 25%), in light of data which showed these more extrme
settings are sometimes needed. However, this usually occurs in rather monotonous
weather with few air mass changes, and extrapolation to more extreme temperature
events may not be warranted. For this reason, the slope factor now contains
information about the range of departures from normal in the anaylsis, and WXSIM uses
this to reduce the effect to no more than +/-20% for temperatures well outside this
range, smoothly transitioning to this figure with increasing departure from normal.

Minor informational and cosmetic changes were made in both WXSIM and wret.exe. These
include parenthetical information in WXSIM's File menu that retrieving data means
opening wret.exe, and that the Cull/Append routine is seldom used. In wret.exe,
departure from normal is now shown to be an 80%/20% mix of forecast and actual values
(in that order, and as they have been for some time) and instead of average forecast
and actual departure from normal, the mean values for the cooler and warmer halves of
this 80:20 mix are shown.

Clicking the 'Cumulus' option on the Comparison to Actuals form now enables entry of
text, regardless of prior choice (previously, it was necessary to have checked Weather
Display first - an oversight in the implementation of Cumulus use for this.

It was found that, under certain scheduling conditions, auto run could generate
messages that the data were over 24 hours old, on the first run of the day. This also
significantly impacted the accuracy of those forecasts. Changes have now been made so
that this error should no longer occur (though the message should still appear if the
data actually ARE over 24 hours old).

I discovered (in studying Finnish users' data) an odd shape to the diurnal temperature
curve in the May-July period. The temperature would rise quickly in the morning, then
warm almost linearly until a somewhat too-late high temperature (about an hour or two
later than reality). I traced this to an oversight in a very old routine which estimates
the times of day when the temperature should be near the daily mean, as these figures
help inform the onset of mixing with daytime heating. I apparently had not tested this
at these latitudes near the solstice, so the problem has been there a long time! This
has now been fixed. The change to wxsim.exe is significant if you live more than 45
degrees from the equator and are having daylight exceeding 15 hours, the difference
being very minor until you reach about 60 degrees latitude, but very important near
and north of the arctic circle.

There is now a trap set for errors at the end of an auto run run, at the point where
WXSIM attempts to boot wret.exe to make graphics and the lastret.txt file. Such errors
have been elusive as they seem to be sensitive to other processes on the computer,
because rebooting would sometimes prevent the problems (which tended to be intermittent
anyway). It should catch any error #6 (overflow) errors and just act like nothing
happened (which I think will be OK). It might catch others, too, with a message, and
then hopefully keep going. This error may have also led to bad .wxf files and errors
in wret.exe. Incidentally, such errors were the reason for the 'Ext boot' option
(check box near the 'Graphic' check box on the Output form). This option remains, just
in case it's still ever needed.

A change was made which should prevent a certain 'file already open' error.

The document 'Evaluating Temperature Forecast Accuracy in WXSIM'(written on July 6, so
that some of the screen shots are very slightly outdated) was made part of the standard
WXSIM distribution package.


CHANGES SINCE 12.9:

The sea breeze routine's warning system for abnormal sea surface temperatures has been
changed so that only discrepancies larger than 6 Celsius degrees (10.8 Fahrensheit
degrees) will trigger a message that actually interrupts program execution. Discrepanices 
greater than 3 Celsius degrees (5.4 Fahrenheit degrees), but no more than 6 C will now
trigger only an external message which does not interrupt the program. Discrepancies
larger than 1.5 degrees will be recorded in the file seatempanomalies.txt.

Sea level equivalent water temperature, and also normal default values for water
temperature and its sea level equivalent are now displayed on the diurnal breeze form.

Small informational and cosmetic changes were made to the Save Data form.

Internal changes were made regarding the reading of registration codes.

A bug in the soil data routine, which sometimes caused it to fail to read station data
(especially when less than four depths are used and blanks instead of "999" were entered
in WXSIMATE) was corrected. Slight changes in the extrapolation of moisture to non-
measured depths were made also.

A message was added to WXSIM's Soil Data Entry form to prevent users from checking more
than 5 agricultural output variables (though all variables are saved for later viewing
in wret.exe). 

Changes were made to the way in which layer relative humidities from NAM FOUS data
(North American users only) are interpreted as cloud cover. In particular, extensive
research showed that, with steep lapse rates (such as in summer), higher relative
humidities are needed to produce overcast conditions (perhaps because areas of downdrafts
produce clearer patches) in levels 2 and 3. The main effect of this change is that some
overcast or mostly cloudy summer forecasts will now be mostly or partly cloudy instead.

It was found that - when FOUS and READY or GFS data were used together - the averaging
was (inappropriately) somewhat dependent on the time interval (a function of the output
interval and the number if iterations per interval). Changes were made in the way FOUS
influences cloud cover and precipitation, so that these discrepancies are reduced to a
trivial level, especially if the time interval is kept to 10 minutes or (preferably)
less. This occurs, for example, with an output interval of 30 minutes and 3 iterations
per interval (while 6 would be better, for a 5 minute interval).

An internal typographical error in WXSIM, which could have (but probably never did)
affected sunset times in unusual circumstances, was corrected.

Comparison to actuals is now avaiable in wret.exe for Cumulus. This also makes it
possible to use (in professional mode) the "learning" routine with Cumulus.

Informational changes (an extra decimal place, number of forecasts analyzed, time to
complete the run, etc.) were made to the Auto Select results in wret.exe.

Major improvements were made to wret.exe's Comparison to Actuals and Auto Select routines.
A wealth of statistical data is (optionally) displayed, both graphically and as text on
the comparison graphs. These include not only net and mean absolute errors, but
root-mean-square errors and standard deviation of error, as averages over periods ranging
from a day to 30 minutes.

More information was added to the Auto Select output in wret.exe, such as indicators of
four different types of reasons for data rejection, and user input regarding criteria for
rejection. Also, message boxes have been added for guidance in the use of this routine.

A UTC date/time stamp was added to the end of each line of data in lastret.txt (produced
by wret.exe), mainly to help developers of php scripts for displaying WXSIM forecast data
graphically.

Minor formatting changes were made to lastret.txt's output, including a one decimal place
(instead of a whole number) for sea level pressure in millibars (hectopascals) and an
extra space in front of lifting condensation level if its value reaches or exceeds 10,000
(this should happen only if using feet as units).

Error handling has been improved in wret.exe, so that when it encounters a corrupt forecast
file (caused by improper closure of WXSIM - by the user, due to an error, or due to a power
outage), it advises the user of the reason for the error and gives instructions for how to
remedy it (previously it just gave an error message and crashed the program).

Very minor cosmetic and informational changes (i.e. punctuation and spelling) were made
to both wret.exe and wxsim.exe.

CHANGES SINCE 12.8.11:

A protection has been added to handle the possibility of the site specified in 
custinit.txt not having corresponding METAR code and name with any site in cty.fdt.  
Previously, error messages such as “Dew point cannot exceed temperature” may have 
appeared in such cases (which would be extremely rare, indicating probably file 
corruption).

The messages “Dew point cannot exceed temperature” and “Unrealistic barometric 
pressure” are now skipped in auto run mode, while the dew point is quietly set to 
the temperature and the barometric pressure to the world-wide sea level mean.  These 
changes also occur even if the messages do appear (in manual mode).

The routine for writing the latest.csv file was inappropriately combining weather
types 1 and 2 and writing this as type 1 (while correctly writing type 2).  This has
been corrected.

A check on program startup (upon loading site data) has been added to see if the 
computer uses commas as a decimal separator.  If so, the setting ‘Use semicolons for 
.csv files’ defaults to true (checked, on the Auto Run form) in order to avoid errors 
in the writing of the .csv files

The function for calculating distance to the sun was fine-tuned, yielding a slightly
smaller difference between perihelion and aphelion and a shift of a bit less than a
day.  The maximum effect on solar radiation is at the surface is no more than as 3
watts per square meter, and resulting temperature effects in the program are on the
order of a tenth of a degree.  The main reason for the change was to make solar
radiation outputs as accurate as possible.  Also, I did a fresh study of the solar
radiation model, and found that the only changes appropriate were the above.

A carefully devised function for the 11 year solar irradiance cycle was constructed,
including an assumption that over the next cycle or two, the sun may enter a
relatively quiet phase, perhaps approaching that of the Dalton minimum in the early
1800’s.  The peak-to-valley variation of about 1 watt per square meter is assumed to
decrease to about 0.7 w/m^2, with a drop in the average by about 1 W/m^2.  I assumed
(with little basis, other than comparison to the Dalton and Maunder minima) that this
dip may last about 50 years.  Actually, direct effects of this on temperature are
trivial (on the order of a tenth of a degree) compared to other sources of error. 
I mainly included it in case it is of further interest later.

The “use global warming” option has been updated, based on a recent (last 12 years or
more) leveling-off of the previously rising global mean temperature.  This “flat”
stretch is documented in both the NASA GISTEMP and Hadley Center HADCRUT data.  It
may be partially explained by recent small decreases in solar activity, both as part
of the normal cycle and changes in the cycle itself.  To incorporate this, I applied
the solar cycle model described in (6), and also applied a gentle concave up curvature
whereas earlier I had it linear.  It still produces about 3 Celsius degrees of warming
between 1965 and 2100, but with only a slight rise before 2020.

This is really an addition to WXSIMATE, not WXSIM per se, but is relevant enough to
mention here: WXSIMATE can now read data from the program Cumulus, by Sandaysoft, in
addition to the previous set of software packages with which it is compatible: Davis
WeatherLink, Brian Hamilton’s Weather Display, Ambient’s Virtual Weather Station, and
Quimisur (a Spanish company).  At this time, the use of Cumulus is limited in three
ways: (1) the “compare to actuals” tool in wret.exe is not functional for Cumulus,
(2) the associated “learning” routine are not functional in wret.exe, and (3) soil
temperature and moisture data are not read.  (2) and (3) are features of WXSIM’s
professional mode and therefore do not affect use in standard mode.  So, standard mode
is very nearly full-featured for use with Cumulus.  I may add some or all of these
features in the future, but do not have any current goals for when this might get done.

Reports from high-latitude users (i.e. Finland) indicated that WXSIM was reducing snow
depth too rapidly in sub-freezing weather.  Investigation, backed by research such as
in this study: http://www.igsoc.org:8080/annals/26/igs_annals_vol26_year1998_pg125-130.pdf
Showed that the main problem was not melting or sublimation, but overly rapid compaction
of the snow under its own weight.  Changes were made to generally reduce this rate, and
also make it temperature dependent (slower compaction at lower temperatures).

A change was made which should fix the occasionally reported ‘forgetting’ of the 'RAOB'
and ‘READY or GFS’ check box settings on the data import form (assuming the problem
found was the only cause).  When unrecognized and not corrected, this problem led to
messages about no model data being found, and the resulting forecasts were generally poor.

A variety of messages which previously interrupted program execution, awaiting a user
response, have now been handed over to a new, small program (included in the WXSIM upgrade
and demonstration packages) dedicated to their display.  This allows WXSIM to continue and
complete the forecast and yet assures that the users knows about the problem(s), which are
usually about missing data.  The messages are also displayed in a text file called msglog.txt.

A program called trimlog.exe has been included in the package (but not given a Desktop icon
at this point).  This is a tool for users of the Weather Display program who may find import
into WXSIMATE to be slow.  Trimlog can run on its own scheduler to produce much smaller
versions of the Weather Display log files, allowing import time to be cut by a factor of
almost 10.


CHANGES SINCE 12.8.10:

The ‘suspicious initial wind data’ message in auto run now appears only under more
extreme conditions, 32 mile per hour discrepancy as opposed to 16, though values
over 16 are still reduced to 16 before use.

A limit was placed on the lapse rate between levels 3 (approximately 700 mb, for
most sites) and 4 (500 mb), to keep it a bit short of the dry adiabatic lapse rate.
The value used is slightly dependent on surface elevation and is based on
considerable research of historical RAOB soundings.  Also, a bug in a beta release
of this version has been corrected in the final one here.

For sites with actual (not adjusted to sea level) surface pressures below 970 mb,
the Total Totals Index (TT) has been modified by mixing it with an alternate
definition (called HLTT or High Level Total Totals) in which 700 mb replaced the
original 850 mb in the formula.  The K, KO, and Showalter indices are modified
similarly but indirectly, based on the change between TTI and HLTT. This indirect
method was used because, while I did have some data correlating TT, HLTT, and
convective threat, I did not have separate data correlating 700 mb version of the
other indices with such threats.  The new indices are equal to the old ones with
surface pressure above 970 mb, and gradually transition to the high level versions
as a surface pressure of 850 mb is reached.  This change was made because some
moderate to high elevation sites were getting overly aggressive convective indices.

The ‘reduce superadiabatic’ routine was modified to have less effect for surface
pressures below 970 mb (that is for higher elevation sites).  When the previous
version was used for these sites, high temperatures became somewhat too warm and
the air too unstable.  The effect now transitions gradually from its original
value for surface pressures above 970 mb, to half that around 945 mb, to very
small but non-zero values at much lower pressures. 

The READY/GFS bias correction (top of tab 4 under Preferences/Settings) has been
modified so that, while the initial temperature correction is the same as before
(with a given setting), the trend part is reduced to 0.67 of its original value.
This was done to correct a tendency, in long range (over a week) forecasts for
too-large of a drift to occur.  For instance, while an input positive value of,
say 0.5, would produce only a modest temperature for the first few days, later
in the forecast the change would become too large.  The change shouldproduce more
consistent day-to-day temperatures (aside from a multitude of other effects, of
course).

A bug, which could produce a ‘file already open’ error after a message about GFS
data being for the wrong site, has been fixed (the message can still appear, but
hopefully not the error that could follow it).

Many new avenues of communication have been opened between WXSIM and the optional
multi-site controller program, WXSIMPRO.  One example is a short file called
wxsimopen.txt, which should consist of the number 1 if WXSIM is open, and 0 if it
is not.  Also, WXSIMPRO can now optionally have WXSIM default to climatological
normal sea surface temperatures instead of retaining values from an earlier run.
Messages related to this in both programs have had wording changes.  Most of these
changes are not visible when not using WXSIMPRO.

A change was made in the Retirevel program (wret.exe) to enable the Auto Select
routine to successfully bridge across from one month to another (previously, for
VWS data, forecasts spanning months were rejected from the analysis).  Months were
already bridged successfully for Weather Display and WeatherLink data, at least.


CHANGES SINCE 12.8.9:

A bug, which could occasionally cause an 'invalid property value' error, has been
fixed.  This error would occur if WXSIMATE somehow (perhaps through some kind of
interruption) failed to finish writing the localcal.txt file.  It is still possible
WXSIMATE may do this, but there is only a trivial loss of data which would have no
perceptible effect on WXSIM's forecast.  Now WXSIM should be able to handle this
situation without error or interruption.


CHANGES SINCE 12.8.8:

The wret.exe module’s ‘Auto Select’ routine for determining learned bias
correction factors has been improved in two ways.  First, a careful study of the
effect of corrections motivated a change in how the ‘tendency towards normal’
factor is determined.  These factors should now be slightly more conservative,
and accurate, than before.  Second, the heavier weighting of more recent data is
now an option (the ‘Weight recent more’ box must be checked for this), with the
default being to weight all data equally.  The equal weighting is a bit ‘safer’,
but unseasonal spells may still call for the heavier recent weighting.

A few places in wret.exe allowed values to be printed in lastret.txt with enough
digits to run columns together (an earlier attempt to correct this still left
loopholes where the figures 100.0 and 10.0 could appear).  This has been corrected.

Minor changes were made to the help file, such as noting that the NGM model is no
longer in production (as of 2009)


CHANGES SINCE 12.8.7:

Version 12.8.8 was completed July 19, 2011 (with wret.exe updated August 12) and
has the following change relative to Version 12.8.7  (described below):

The default value (and only value in standard mode) for the minimum level 1-3 sky 
cover necessary to allow external-model-based precipitation was changed from the 
previous 40% to 20%.

The minimum 12-hour precipitation probabilities for “possible” and “likely” thunder 
have been changed from 15% and 25%, to 10% and 20%, respectively, thus making 
appearance of thunder slightly more likely in the plain text output.  This would be 
most noticeable for precipation probabilities between 10 and 15%, where the former 
'Precipitation showery or intermittent' wording will change to 'Scattered 
thundershowers possible'.

In wret.exe, the number of decimal places for precipitation rate and total 
precipitation has been reduced in the case of large numbers (i.e. 100 mm or more)
which would run into other columns if the original decimal places were retained.

In wret.exe, horizontal visibility’s units are now dependent on the temperature unit
choice instead of the previous thickness unit choice.  When Fahrenheit is in use,
visibility units are now miles; with Celsius, they are in kilometers.  Also, if the
visibility (in either unit system) has a value less than 10, one decimal place will
be displayed.  (Previously it was a whole number in all cases).

In wret.exe, you may now check up to 15 temperature items and 15 ‘other data’ items.
As before, only the first 5 of each will be displayed on the screen, but the entire
set will appear in lastret.txt.  Also, some minor formatting changes were made in
lastret.txt, to remove some of the excess spaces when fewer than the maximum number
of items are selected.

In wret.exe, two new temperature values were added: the maximum and minimum 
temperatures from which daily max and min values are obtained.  Around the time of
the maximum, the difference between the new max value and the most likely 1.5 meter
temperature (the main forecast value) is an indication of the amplitude of the
largest short-term fluctuations likely (though the new min value at the time of the
max is less meaningful, and often a bit warmer than the lowest temperature due to
short-term fluctuations).  Around the time of the daily minimum, the difference
between the new min value and the ‘main’ temperature indicates fluctuation amplitude,
with the max value a bit less meaningful.  In short, these are simply values from
which daily max and min temperatures can be extracted.

In both WXSIM and wret.exe, the upper end of the convective sensitivity adjustment
has been extended to +2 instead of the previous +1.

In both WXSIM and wret.exe, minor cosmetic changes and changes to the help file were
made.

In both WXSIM and wret.exe, summaries at the end of the text display now show 24-hour
max and min temperatures to the nearest tenth of a degree, instead of the previous
whole degree.  This should not be understood as a claim of higher accuracy, but the
decimal places might be interesting for comparisons or identifying trends in the
program’s behavior.
In wret.exe, after the message that too many temperatures (or ‘other data’) options
are checked, the program will automatixcally uncheck the last item you check, thus
preventing errors that would occur if you proceeded without heeding the message.

(This item was actually present in 12.8.7, but I forgot to list it below).  A check
box on the Auto Run form allows you to have the date listed along with the day of the
week in the plain text output.
 
Numerous improvements and additions were made to the agricultural module.  Soil moisture
is now reported in soil moisture tension as well as percent by volume, with these being
functions of each other as well as of soil type.  Both soil moisture and temperature can
now be imported (via WXSIMATE Version 5.0) from either WeatherLink (for up to 5 depths)
or Weather Display (for one depth, and possibly more in some later version), and this
can work in auto mode as well as manually.  Irrigation can now be planned on the Interrupt
Planner, and this, along with soil moisture tension, can be plotted in wret.exe as well as
output in WXSIM itself.

Several small cosmetic, organizational, and wording changes were made in wret.exe.

An occasionally encountered bug producing a “division by zero “ error has been corrected.
This problem most likely occurred only if local calibration data was being used, and
required a rather special set of circumstances, so that it was sporadic in nature.

In addition to the changes listed in (12), the algorithm for the default soil moisture (as
a function of location, season, and recent precipitation) has been improved considerably.

In wret.exe, a bug - which caused text and lastret.txt display of all soil moistures
to be that at depth 1 – has been corrected.

Bugs which could cause division by zero or invalid property value problems were fixed.
These were associated with interpretation of local station calibration data in localcal.txt.

Output format of certain variables to lastret.exe in wret.exe, such as severe weather
indices, was changed so that values of -10 or more negative are rounded off to whole
numbers, so that columns of data won’t run together.


CHANGES SINCE 12.8.6:

The results of a recent careful study on thunderstorm activity as a function of 
various stability parameters (especially the K and Total Totals indices) using  
many U.S. surface and upper air sites’ historical data (spanning up to 25 years),
combined with information from two large studies in Europe (Germany and the
Netherlands) was used to substantially improve WXSIM’s convective bulletins.  A
very thorough description of this improved algorithm is now included in this manual.

Slight changes were made in the wording of convective bulletins.  Also, the
following plain text convective output now consists of:

 " Precipitation showery or intermittent.”
 " Scattered showers possible."
 " Scattered thundershowers possible."
 " Scattered thunderstorms likely."
 " Scattered thunderstorms likely, some possibly severe."
 " Thunderstorms very likely, some possibly severe."
 " Thunderstorms very likely, some severe."
 " Severe thunderstorms likely, with possible tornados."

These were removed:
" Thunderstorms likely, some severe."
" High risk of severe thunderstorms and possible tornados."

The plain text convective bulletins now take into account thresholds of 12 hour
probability of precipitation.  This helps screen out occasional contradictory
information (such as thunderstorms “likely” when rain chances are below 20%),
though it may cause some inconsistency with the scrolling convective bulletins,
most likely in that a few convective bulletins may be more aggressive than the
final plain text output.  If this is found to occur frequently, a small downward
adjustment in the convective sensitivity may be in order, since the final plain
text forecast incorporates a bit more information than do the bulletins.

The automatic level 2 cloud cover minimum of 60% during precipitation has been
reduced to 45%.  This could increase temperatures very slightly on afternoons with
light shower activity, but a recommended slight change in the GFS temperature and
cloud cover bias (see #6, below) may just about exactly cancel this out on average.

A major review and readjustment of the routines for finding heights and thick-
nesses of the various pressure levels was conducted.  The changes made include
updating the virtual temperature calculation to an official published equation
(previously it was a fairly good, empirical one I had developed), including level 3
and 4 relative humidity values (values up through level 2 were already incorporated,
but above that default values had been used), establishing new ways of averaging
the limited temperature data to best characterize layer average values, and
(importantly) removing an altitude-based correction to the acceleration due to
gravity, so it is now a constant 9.80665 m/s/s, as appears to be standard for the
geopotential (as opposed to geometric) heights that are standard in imported model
data.

A thorough review of GFS temperature verification results, from this site:

http://www.emc.ncep.noaa.gov/gmb/STATS_vsdb/

strongly suggests that a cold bias which existed a few years ago has been largely
corrected.  For this reason, the default value for the upper level temperature
bias correction has been changed from 0.5 to 0 (professional version users will
need to change this manually, but the change will be automatic for standard
version users).  Also, verification results from about 1200 forecasts over the
last year here in Atlanta suggest that GFS biases in cloud cover and precipitation
(a previous year of data had suggested the model was too cloudy and wet) have also
largely disappeared, so the bias correction setting for cloud cover, precipitation
intensity, and precipitation intensity skew have been changed from the previous -3,
 90, and 2, to -1, 95, and 1, respectively.  This will generally increase cloud
cover by about 4% and precipitation by about 5%.  Professional mode users should
consider their own accumulated experience as local effects can be important here.

More thorough data on 700 mb relative humidity in WXSIM was made accessible to
wret.exe.

The forest effect on snow cover was increased somewhat.

A bug in wret.exe that caused values of UV index to be too high was corrected.  

In light of new data, the UV index algorithms in WXSIM was revised generally
downward by about 7 or 8 percent, and the elevation effect part of this was
improved also.

The UV index algorithm used for display on the main Data Entry form of WXSIM was
found not to be consistent with the one used in the output.  These two instances
of UV index now share a common algorithm.

An option was added in wret.exe to include a numerical convective parameter in the
lastret.txt file (created when ‘View Text’ is selected).

The default dew point depressions, as functions of layer cloud cover, were changed
for levels 2 through 5.  In particular, cloud cover of less than 10% now gives dew
point depressions tending towards 14, 18, 16, and 15 degrees Celsius for levels 2
through 5 respectively.  This was based on averages of all soundings from Athens,
Georgia, for days with less than 10% average total cloud cover, over a 6 year
period.

A new setting was added to the Local Data Import form, allowing specification of a
minimum sun altitude (default 10 degrees) for using estimated cloud and haze data
from WXSIMATE.  This is useful because low sun angles yield relatively unreliable
solar-radiation-based cloud and haze estimates.  The setting specifically refers
to sun altitude 30 minutes before the forecast initialization time, because the
default time span used in WXSIMATE (for collecting solar radiation data for this
purpose) is the hour leading up to the forecast time.

A new setting on tab 4 of the Preferences/Settings form allows specification of a
threshold value for combined level 1 through 3 cloud cover (in percent), below
which precipitation will not be forecast, even if present in FOUS data or on the
Interrupt Planner.  This is probably most useful in cases where the orographic
downslope effect is in use; the reduced cloud cover in such cases may well be
accompanied by an elimination of precipitation.  The default value (and only
value for standard mode) is now 40%.  If precipitation was previously supposed to
be forecast at a certain time, a small increase in cloud cover may be observed in
the forecast as a vestige of what would otherwise have been precipitation.

The ‘Reduce superadiabatic’ feature was modified by weakening the effect slightly,
so that even with it active, the near-surface temperature lapse rate will be
allowed to exceed dry adiabatic by a slight amount – and by slightly more than
before.

The ‘enhanced maritime effect’ was expanded to include a reduction in the cooling
effect of precipitation, considering the fact that the nearby or surrounding sea
is not made any more wet by rain falling on it, and thus removing a component of
evaporative cooling that would exist for an inland site.

A protection was added against a very rarely encountered report of freezing rain
with temperatures well above freezing.


CHANGES SINCE 12.8.5:

A protection in wret.exe, against trying ‘comparison to actuals’ or ‘auto select’
when more than 5 items are checked in either the ‘temperature and thicknesses’ or
the ‘other data’ section, has been changed to allow up to 10 items, which is the
maximum anyway (5 of which would show only in lastret.exe).  Previously, if such a
run was attempted with more than 5 items checked, the program simply did nothing.
Now it will complete the requested task.

A safeguard was added in wret.exe against a ‘division by zero’ error during an
‘auto select’ run, in the rare case that the average departures from normal of the
warmer and colder halves of the data points are identical.  Now such an occurrence
will simply generate a slope of zero for the temperature error as a function of
departure from normal.

A new feature was added to Preferences/Settings, allowing the user to specify a
description the density of forest (especially evergreen) in the surrounding area,
for modification of the effect of snow cover.  Some consideration had been given
to this already, in the form of a ground cover parameter included in the
customization.  However, this appears not to have been sufficient for describing
situations such as dense fir forest in high northern latitudes, where the dark
trees considerably mitigate the cooling effect of the otherwise high albedo
(reflectance) snow cover.  Any setting entered by the user is saved on exit.

A small problem with snow:water ratio as used during the calibration run was
corrected (it had defaulted to a value of 2 in most cases).  This change will have
only a very small effect on forecasts.


CHANGES SINCE 12.8.4:

A sophisticated and carefully researched new algorithm replaces the former one for
estimating wind gusts.  The new routine takes into account the user’s choice of
definition of gusts (i.e. higest wind in a 10 minute period, versus highest in a
60 minute period) and allows adjustment of gust factors by the user, who can also
specify the lowest speed wind gust to be reported in the plain text output.

A caption, just under the site information on the Data Entry form, now displays
whether professional mode is OFF or ON, and whether auto run is OFF or ON.

A bug, which caused small errors in the drawing of the upwind direction (thick
arrow and dotted curve) on the advection sites map, has been corrected.  This would
mainly have been noticed in manual mode (or in auto run if you were watching very
closely) and different flow curvatures were being tried.  It did not affect auto
run forecasts, but could have influenced user decisions when experimenting with
flow curvature choices manually.

A bug, which could cause the program to get into an endless loop of saying
“Calibration Run” if the cor.txt file was corrupt, has been fixed.  Now, such
corrupt files (how it got corrupted is yet to be determined) will be identified as
such, the user will be notified by a message box, and the run will be allowed to
complete, using default correction factors of 0, 1, 0, and 0.  At the same time, a
more centralized error trapping method was instituted, to hopefully make identifying
any future run time errors easier.

A protection was added to guard against unrealistic wind values that could result
if either the localcal.txt or localdat.txt files were somehow corrupted during or
after an import of local station data using WXSIMATE.  This protection was added in
response to the only reported case of the problem, which produced a brief period of
abnormally strong winds.

A bug, which could cause an ‘invalid property value’ error if the Stop AM Rain
refinement was chosen, has been fixed.  The error probably appeared mainly in the
winter season, and this is a summer season feature, which is probably why the bug
took so long to show up.  Note that this feature boots up with default times, except
in auto run, where the settings are remembered from the last run.

Wind chill wording was changed to include both the lowest and highest values of each
12 hour forecast period (when colder than a threshold of -3 C), with the term
“ranging from … to”.

The snow remembering routine was changed to avoid errors which could occur with
certain Windows regional settings which use decimal separators other than periods.
If the old format is encountered, a message will alert the user to this fact, with
instructions to temporarily disable the routine to let a new forecast run, at which
point it can be re-enabled.

Wind gusts over 1 and 10 minute and 1 and 6 hour periods were added to the display
options in the retrieval module (wret.exe).

A bug (which may have existed for many years) involving wind chill in wret.exe was
corrected.  This bug had caused erroneous graphical and text display of wind chill
values when wind speed units were other than miles per hour.

Now up to 10 items from the temperature-related options, and also 10 from the ‘other’
data options, can be chosen in wret.exe.  Only 5 from each group can be displayed as
text or plots, but the others will appear in the lastret.txt file.  If you do choose
more than 5, the program will decide which 5 to display, as currently there is no
mechanism for making this specification.

Choices for data to display in wret.exe have been rearranged into more logical
grouping.

Protection in the form of a message box (manual mode only) and reasonable default
values was added for extreme wind speeds from potential misinterpretation of METAR
or other ingested wind data.

Megajoules per square meter were added (to Watt x hours per square meter and Langleys)
as an option (under Preferences/Solar Energy Units) for output total daily solar
radiation.  A similar addition was made to wret.exe (the retrieval module).

Precipitation and total solar radiation units were added to the hard copy printouts
available for Plots in wret.exe.


CHANGES SINCE 12.8.3:

A bug, discovered in the ‘snow remembering’ routine just introduced, has been fixed.

The formatting of the snow depth box on the snow/ice entry form has been changed to
round off to the nearest hundredth (this change prompted by the appearance of decimal
values in this form in some cases after use of the ‘snow remembering’ routine).


CHANGES SINCE 12.8.2:

Further testing of item #7 for 12.8.2, below showed errors in the normal diurnal
range of some sites.  This turned out to be due to mathematical errors out in about
the 12th digit, perhaps due to to the precision and type of the variables involved.
Normally such a problem would be trivial, but a condition (whether or not the
variable’s value was exactly zero) that had been set made the effect much larger.
This has been corrected with a protection against the resulting extreme values.
Now both old customizations and future ones should function properly.


CHANGES SINCE 12.8.1:

The tolerance for triggering a message about sea surface temperature being out of
range was increased from 2 Celsius degrees (3.6 Fahrenheit degrees) to 3 C (5.4 F).

A typo (“Relativelymild”) in the plain text output was corrected.  Also, freezing
rain wording for metric units had “above ground” added, for consistency with imperial
units.

Wind chill during the daytime periods in the plain text forecast was changed to
reflect the *warmest* value during the day, with wording such as “Wind chill colder
than …”.

The (somewhat rarely used) READY data turns out to have changed format slightly at
some point, which led to WXSIM omitting precipitation while parsing.  This has been
corrected, and simultaneously, arrays have been expanded to handle the 3-hourly READY
data out to 192 (instead of the previous 180) hours.

A bug (starting with Version 12.8.1), which kept wret.exe from recognizing old
correction factors in forecasts, has been corrected.

Start and ending times for the forecast run itself were added to the latest.txt
(and archived versions) file.

A parameter has been added for future customizations that will permit slightly better
matching of some sites’ climatological diurnal temperature ranges (thus affecting
displayed normal max and min temperatures).

A bug (discovered as I was testing (7), above), which allowed inaccuracies of perhaps
a degree or two in the displayed normal max and min temperatures (by not fully
determining the normal diurnal range as intended) has been corrected.  This has
virtually no effect on forecasts and had only a very slight effect on the quality of
some customizations.  Earlier customizations affected by this will now show more
accurate climatological temperature data.

Top layer (the top one centimeter) soil temperatures are now initialized more accurately 
due to improved interpolation and extrapolation algorithms.

A new parameter, called ‘Base insulating effect’, has been added to the soil data form.
The need for this arose as I did additional testing on both summer and winter soil
temperatures in various scenarios, using data from the Soil Climate Analysis System (SCAN).
This appears needed to represent thermal effects (mostly simple insulation, I believe)
apparently due to grass turf ground cover.  It should probably be set to zero for truly
bare ground, but otherwise, values around 2 seem about right for a wide range of conditions.

A option to ‘Initialze with previously forecast snow cover’ (on the first ‘tab’ of the
Preferences/Settings form) has been added.  This allows WXSIM to start a new forecast
using the snow cover from the last forecast run, specific to the date and time of the
new forecast.  You can still override this by entering the new snow cover directly,
but this feature will be very useful if you must be away from the computer during a
series of forecasts where snow is accumulating and/or melting.  In this case, the
snow/ice cover refinement does not need to be active (hightlighted red), though is may be. 


CHANGES SINCE 12.8:

The interface for many of the settings was considerably rearranged, by creating
a new form, under a new item called ‘Settings’ (under Preferences on the main menu
bar).  On this form is a combination of the former text width form, the minimum UV
and precip form, the fog and frost options form, and the model bias form.  Some
items from the Interrupt Planner were also duplicated for easy access, especially
for users doing mainly auto runs.

Sliders were added (to the form in (1), above - professional mode only) to control
the strength of the ‘allow decoupling’ and ‘additional maritime effect’.

Site and date specific temperature variation data has been added to this new form.

The ability to specify upslope, downslope, and lake-effect directions for wind has
been added.  These features, available only in professional mode, can alter cloud cover
and precipitation amounts derived from imported model data in order to model effects
on a scale smaller than that of the model (mainly GFS) data.  Proper use of this feature
will require study on the part of the user over time, and controls are provided to allow
the user to tweak these settings based on accumulated experience.

Optional wind and temperature descriptors have been added for the plain text output.
The wind part is fairly straightforward (“breezy” for >12 mph, “windy” for >17, and
'very windy' for >25).  The temperature part is very sophisticated, taking into account
not only actual temperature, but also wind chill values and number of standard
deviations from normal specific to the site and date.

Wording rules for precipitation in the plain text output have been changed so that
probablilities or amounts will not be mentioned unless there is a specific reference
to precipitation or at least a chance of convection in the forecast.

Changes were made to wxsim.exe which now allow use of newly created (using wret.exe
bias correction factors without having to restart WXSIM.

Changes were made in wret.exe so that, if the “learning” option is turned off in
WXSIM, the effective correction factors for those forecasts will be considered to be
the default values.

Protections (in the form of message boxes) were added to wret.exe so that users are
much less likely to take an incorrect sequence of actions which might have led to
an error.

A bug, which could occasionally carry over precipitation from the end of one forecast
to the first line of text of the next, has been corrected.

A possible 'Invalid property value' error when using imported precipitation data has
been averted.

An oversight which on rare occasions could allow METAR reports of runway condition to
be misread as temperature and dew point (possibly leading to 'dew point cannot exceed
temperature' message) has been fixed.

Another METAR import bug which could also very rarely lead to a dew point being read as
a barometric pressure (hence triggering an 'unrealistc barometric pressure' message)
has been fixed.


CHANGES SINCE 12.7.5:

Version 12.8 was completed on November 30, 2010 and has the following changes
relative to Version 12.7.5 (described below):

A new suite of calculations of agricultural interest, such as soil temperature and
moisture, and evapotranspiration, was implemented, and is available in professional
mode.  A new menu item in the main program was added to accommodate user defined
choices of output.  These new output variables (23 in all) can also be viewed as
plots or text in the retrieval module (wret.exe).  Further refinements and features
can be expected in upcoming versions.

A message box which was new to Version 12.7.5, but which I forgot to document below,
was causing problems for some users.  This message was intended to detect if another
version of WXSIM was open, and alert the user to that fact.  In some cases, the
message appeared inappropriately and interfered with auto runs.  This “new” feature
has now been removed, as it may have caused more problems than it avoided.

Two problems with temperature forecasts for island, coastal, or near coastal areas
were addressed (a typical, but not unique problem region being New Zealand).  One is
that of too-high maximum temperature forecasts, mainly in spring.  The other is that
of too-warm minimum temperature forecasts on calm clear nights, just about any time
of year, but perhaps most prominently in winter.  The first problem was identified as
an inappropriate lack of marine influence when winds were from the “inland” direction,
especially when water is not too far in the direction (as on an island).  The solution
is an optional sea-breeze-like influence (but without modification of wind), which can
operate either with or without the existing sea breeze routine (the effects are roughly
additive).  The other problem was addressed by increasing the effects of the existing
‘allow decoupling’ routine (check box on the Interrupt Planner), using an additional
component to the routine which specifically increases diurnal temperature range.  Both
of these routines are influences by a new input on the form reached by selecting ‘Min
UV and Precip, Sea Breeze, and Advection item under parameters.  This new item lets you
define a distance to the far side of an island or peninsula, up to 100 miles (161 km)
distant.

A significant problem with the “learning” routine (‘auto select’) in wret.exe was
discovered and corrected.  This was actually making forecasts *worse* for some users. 
It manifested in the slope of the error versus departure from normal line.  The earlier
“correction” was exactly backwards, and either made too-extreme forecasts more extreme,
or too-moderate forecasts even more moderate (in terms of departure from normal seasonal
mean temperature).  One indication of the problem was frequent appearance of a message
that the slope correction was ‘out of range’ and would be ‘limited’ (which is a good
thing, as the limitation kept the problem from getting too far out of hand.

A number of cosmetic and display changes were made in wret.exe, including the addition
of mean temperature of a forecast period on the graph showing temperature errors versus
day of forecast.  Also, the “proposed” line on the graph of temperature error versus
departure from normal now has a more clear meaning.  It now shows the correction that
will be made in practice if the proposed values are accepted.

The text width scroll bars in both wxsim.exe and wret.exe were given greater ranges, in
order to accommodate different font sizes and resolutions that may be available with
newer versions of Windows.

On the Text Width, Heat Index, and Frost Options form (under Parameters), users can
specify a choice of conditions under which to display frost as an output in the plain
text output.  This includes an option to mention frost only if it is “climatologically
significant”, meaning unusual enough for the season to be “newsworthy”.  This decision
is guided by WXSIM’s own internal estimate of the climatological probability of ground
frost occurring on the current date.  NOTE – This feature has already been present since
about Version 12.7.2, but I forgot to describe it sufficiently before.  ANOTHER NOTE – I
have become aware that, in many countries “frost” refers speficically to the occurrence
of freezing temperatures.  This is NOT the meaning in WXSIM, where it instead refers to a
form of condensation (more properly, “deposition”) of water ice onto surfaces like grass
or cars.  “Heavy” frost, here, means a lot of the white stuff, not necessarily especially
low temperatures.


CHANGES SINCE 12.7.4:

Version 12.7.5 was completed on July 2, 2010 and has the following changes relative
to Version 12.7.4 (described below):

Changes were made to the plain text output decision algorithm, mainly to prevent
mention of precipitation chances below 20 percent when the 'Omit trace amounts or
very slight chances of precipitation' box is checked.  This is actually a second
attempt at the fix in 12.7.3, which still had a loophole and was not fully
successful.

A bug was discovered in the sea breeze routine, in which it wrongly used north as a
default water direction when reactivated during auto run.  This has been fixed, as
was a closely related problem involving the mountain/valley breeze routine, where
is had been ‘forgetting’ the diurnal breeze amplitude.

The Diurnal Breeze form (containing both the sea breeze and mountain/valley breeze
controls) now had a ‘Reset Defaults’ button, which if clicked populates the form
with the originally customized data, including current seasonal sea surface
temperature (adjusted to site level, as always, with a lapse rate of about 3.5
degrees F per 1000 feet or 6.5 degrees C per kilometer).

There is now a message box which warns the user if, in auto run, the retrieved (at
boot up) water temperature is different from the default climatological value by more
than 4.5 degrees F (2.5 degrees C).  This si intended to prevent the problem of
unseasonal default water temperatures being used in the forecast when users do not
reset the value reasonably often.

A very small bug, which could make temperature forecasts on subsequent runs using
identical data different by perhaps a couple tenths of a degree, has been fixed. 
It was due to an inconsistency in how the ‘air mass temperature’ was determined the
first time through, versus on subsequent runs.


CHANGES SINCE 12.7.3:

Change #3 under Version 12.7.2 (below) was discovered to cause an occasional error
#5 (invalid procedure call or argument).  This has been corrected, while preserving
the new parsing ability introduced in Version 12.7.2.


CHANGES SINCE 12.7.2:

A change in the plain text output algorithm, introduced in 12.7.2, caused a change
in the output in the case of using the 'Omit trace amounts or very slight chances
of precipitation' box on the 'Minimum UV Index and Precipitation for Display, etc.'
box.  It should now behave as before.


CHANGES SINCE 12.7.1:

An isolated instance of failure to recognize commas as potential decimal separators
(in certain Windows regional settings) was corrected.

An option (mainly for Canadian users) to use humidex instead of heat index was
added, and can be accessed under Preferences on the same form as text width.
Humidex was also added to wret.exe's optional outputs.

METAR barometric pressures failing to use standard prefixes (“A”, “SLP”, or “Q”)
are now read anyway.  Also a default pressure of 29.92 inches of mercury (1013.2
millibars or hectopascals) is now assumed at the beginning of METAR import in case
no pressure reading is found.

WXSIM now detects other open copies in the same folder, or instances of failure to
close the program properly, and alerts the user to this with the choice to proceed
or quit (and perhaps either use or close any other open copies).

WXSIM now optionally includes frost descriptions in the nighttime forecast periods.

The frost decision routine was modified using additional data, including
information on the difference between ‘grass’ temperature (within 10 cm of the
surface) and 1.5 meter “shelter temperature”, from http://www.knmi.nl/publications/
fulltexts/hisklim7.pdf.

The plain text output (saved as plaintext.txt and also incorporated in some other
products) now includes (optionally, if Convective Bulletins are enabled under 
Preferences) mention of showers, thunder, or severe weather if WXSIM considers the
probability sufficiently high, even if imported model data doesn’t suggest
measurable precipitation.

A new option, activated by checking the new ‘Allow decoupling’ box on the Interrupt 
Planner form, permits WXSIM to decrease both maritime temperature-moderating
influence and the strength of warm air advection when the strength of (mainly
nocturnal) temperature inversions exceeds a certain, rather weak, threshold value. 
This effect increases with the strength of the inversion and is therefore strongest
on clear, calm nights.  It is most significant in coastal and near-coastal areas
and its main effect is to lower nighttime low temperature forecasts.  This change
was motivated by reports of too-warm overnight lows, mainly in coastal areas, under
clear conditions with light winds.

Made minor cosmetic and help files changes.


CHANGES SINCE 12.7:

Provided error handling in case a printer is not declared.  Now, a message will
appear explaining the need to do so, along with instructions for how to do so in
control Panel.

Fixed a bug which could cause errors in the station precipitation amount in
Comparisons in wret.exe for users of Weather Display

Made minor cosmetic changes.


CHANGES SINCE 12.6.3:

A ‘subscript out of range’ error that could have occurred when importing GFS data
that is initialized after the forecast (which can happen only if you are running
forecasts after the fact) has been averted.

Another ‘subscript out of range’ error that could have occurred when importing GFS
advection data for a different site has been averted.  A message box will now
appear alerting the user to import fresh GFS advection data relevant to the current
site.

The optional GFS temperature and dew point plots on the Output form’s graph now
have correct colors for the current background color (an earlier coding problem
had led to low-contrast displays).

Thunder and severe convection outputs (the same ones displayable in wret.exe) are
now written to the main (not ‘daily’) .csv output file.  Column headings help
describe these roughly 0-5 scales.

An option has been added to the Auto Run form to execute a user-defined DOS batch
file after auto runs or after the user clicks ‘Repeat’ after a manual run. 
Possible uses might include converting a .bmp file to a more compact format
(like .png) using another program, uploading files to the internet, or a combination
of such actions.  A sample batch file, called latestbmppng.bat, is provided in the
demo package to instruct IrfanView Version 3.2 (see www.irfanview.com if you are
interested in obtaining this program) to convert the optionally produced graphic
latest.bmp to latest.png in the c:\wxsim folder.

An option has been added (to the Minimum UV Index and Precip form) to adjust the
effectiveness of diurnal breezes (sea breeze or mountain-valley breeze).  This
affects the diurnal wind vector component and also (in the case of sea breeze) the
direct effect on temperature.  It is strongly recommended that users research their
forecast bias histories before considering any such alterations.

Another option added to the above form adjusts the effectiveness of cold or warm
advection.  It is strongly recommended that users research their forecast bias
histories before considering any such alterations.  The only locations I know of at
present that seem to warrantthis intervention are in southern Greece.

Various cosmetic changes were made, including adding program-specific icons to the
forms in both wxsim.exe and wret.exe, and changing the background color of the help
forms in both programs from yellow to a less harsh tannish-orange.

Changes were made to the vertical lines on both the regular and comparison plots in
wret.exe.  On the regular plots, the bright blue vertical lines (which did not
consistently mark days) were made a darker blue, and with other dark blue lines form
an unobtrusive finer scale (easily interpreted only when showing 2,3,4,6, or 8 days)
than the gray lines marking midnights.  The comparison plots’ blue lines were removed
and, instead, the dark gray lines now show midnights while the light gray lines show
every six hours.

The fog sensitivity wording was changed to put the default value of 45 (instead of
the previous 50) in the middle of the ‘normal’ range.  Also, the description is now
highlighted in red if it is outside the range of ‘low-normal’ to ‘high-normal’. 
Similar behavior was also built in to the new diurnal breeze and advection 
adjustments discussed above.


CHANGES SINCE 12.6.2:

A change was made to avoid an ‘input past end of file’ error (#62) when WXSIM
tries to access GFS data for advection, and it’s not present.  This error
generally occurred if the ‘GFS for advection’ box in WXSIMATE was not checked (it
generally should be checked, as this is a valuable source of data for most users).
Now the program should silently close the file with missing data without producing
an error.

A cosmetic error introduced accidentally in 12.6.2 (the 2 PM check box on the auto
run form had been shifted in front of the 1 PM check box, rendering the latter
invisible) has been fixed.


CHANGES SINCE 12.6.1:

The ‘~Monotone’ check box on the advection form was replaced by a ‘Mono’ scroll
bar which allows mixing of the monotone and not monotone fits in various ratios,
from 0% monotone to 100% monotone (in increments of 10%).  The default value is
50%, which is generally a good compromise between getting the closest fit to the
data points and avoiding unrealistic extrapolations.  This setting is not saved.
The 50% default is also used in auto run, unless ‘Enforce monotone’ is checked on
the auto run form, or there is a strong inversion.  In these cases, the fit will
be 100% monotone, meaning the advection profiles for temperature and dew point
will not have any slope reversals.

The GFS advection data across longitude 180 degrees (see #1 below) is now active
on Chris McMahon’s site, and the feature is now fully operational.


CHANGES SINCE 12.6:

Support was added for advection across longitude 180 degrees (such as in New
Zealand with winds from the east), in anticipation of expanded coverage in the
GFS files for advection produced by Chris McMahon.

Colors were changed for the temperature and dew point displayed by the ‘Show GFS’
button on the Output form.  Previously (by mistake) they were not matched properly
with the blue or gray backgrounds of the graph.  They now will be displayed with
the same colors as WXSIM’s forecast values, but with thicker lines.

A scale was added for the wind speed arrows on the advection data maps.

Minor informational and cosmetic changes were made to the Auto Run form.


CHANGES SINCE 12.5.4:

Support was added for a new set of GFS data kindly downloaded and culled by Chris 
McMahon.  This is GFS data, but now for a 20 x 20 degree grid surrounding the home
site, so that GFS may now be used for advection data, both initially and after
wind shifts.  This feature should be especially useful for users outside North
America (since they do not have MOS for after wind shifts), but also for North
American users more than 2 or 3 days into a forecast, when MOS runs out.  It will
also be helpful for users on islands or near coastlines, as data from ocean
locations will be available (the extent depending on my original allotment of
surface advection sites in the customization).

GFS data can be used to fill out the main Data Entry form values, with most of it
coming from the new data set, except for barometric pressure, which uses the 
reviously existing set.  This is not the best way to fill out this form, since
local METAR, synoptic, or home station data would be more timely and accurate.
However, for remote sites with no surface data available, this should initialize
the program well enough for a good forecast in most cases.

A time series of GFS temperature and dew point data is now extracted, and can be
displayed by clicking the new ‘Show GFS’ button on the Output form.  This makes
an interesting, direct comparison with WXSIM’s own forecast on the Output form’s
graph.

Internal changes in the auto run routine were made, which may reduce or eliminate
the possibility of certain errors (especially number 52, ‘Bad file name or number’).
This change avoids opening the FOUS and RAOB data display forms, which should keep
things simpler for Windows as it tries to thread the actions properly.

A warning was added to all the options under the Start menu to prevent users from
starting a new forecast without clearing the Ouput form from a prior run.  This
eliminates one possible cause of Error #52 (see above).

A new, very small form consisting of a progress bar and percentage figure (appearing
in the lower left part of the screen, just above theWindows ‘Start’ button) has been
added, to display the percentage of the forecast complete so far, as it runs.

There is now an option to ‘Minimize forms’ on the Auto Run form.  This causes almost
all forms to be minimized during auto runs.  The exceptions are the small progress bar
form (see above), the file import progress bar form (which appears intermittently, and
in this case is moved to the lower left part of the screen, just above the new progress
bar form). And – in the case of ‘Run Immediately’ – the Data Entry form.  In a
scheduled auto run, Data Entry will start out minimized if the program just booted, and
will otherwise remain minimized once it has been manually minimized.  These changes
should enable users to perform other tasks on the computer while WXSIM runs, with only
minimal distraction.

Message boxes have been added to the Unload event of several forms, to warn users not
to close forms with the little red Windows ‘X’ in the upper right corner.

Choice of surface data source (METAR, SYNOP, or GFS) is now saved only after import of
data for the home site, and no longer after advection data imports.  The reason for this
is the complexity of choices now that all these (plus MOS) are now supported.

The retrieval program wret.exe now checks for completeness of the initialization file
retini.txt to trap errors resulting from damage (which a few users have seen, though the
cause is at present not known).  If damage (usually missing lines) is detected, wret.exe
displays an error message to that effect and then attempts to restore the file using a
backup file, retinibak.txt, which in turn is created as a copy of retini.txt if the
latter is not damaged.  Therefore, just one successful load of the program is sufficient
to establish the backup file.  Meanwhile, a copy of any damaged retini.txt file is saved
as retinibad.txt.

A new check box, ‘Close program after auto run’, has been added to the Auto Run form.
If checked, this will cause the program to shut down right after the run is finished.
The intention here is to save users, who use System Scheduler (or similar) to open the
program, the trouble of also using such an external program to close WXSIM.

Changes were made to wret.txt to allow comparison of precipitation forecast to actual
values, and also to include averages as well as maximum and minimum values in the
analysis of this plus existing items.  NOTE: In order to analyze precipitation for past
forecasts, WeatherLink users will need to run Import Data in WXSIMATE for all past
months for which analysis is desired.  This is best done by manually entering a date
(make sure the Scheduler is OFF) early in the *following* month so that a file will be
created for the entire previous (desired) month.  Start in the past and work forward one
month at a time.  After this, the latest two monthly files will be updated (including
precipitation) every time Import Data is run, so no further corrective actions will
be needed. 

A small cosmetic change was made to allow better readability of weather types in the
saved bitmap plots in wret.exe.

In wret.exe, the default directory for the WXSIMATE-derived VWS and WeatherLink data
files is now forced to the current (boot-up) directory of wret.exe for using the
Comparison feature.  This was already almost the case, but there was a loophole that
might have allowed the path name to change in some cases of analyzing forecasts in
other directories.  The forecasts may be located wherever you like, but wxsim.exe,
wret.exe, and wxsimate.exe must all be located in the same folder (usually c:\wxsim).

Capacity for number of combined forecasts in ‘Compare to Actuals’ in wret.exe has been
increased from 999 to 9999.

A bug that could allow a ‘File already open’ error in wret.exe - when changing weather
station software types and/or directories in wret.exe for Compare to Actuals – has been
fixed.

Changes were made in wret.exe to allow proper display and use of certain items which may 
have been affected by regional and language setting in Windows which use commas as a
decimal separator.  There now should be no problems in the program related to this.

A change was made in WXSIM to hopefully preclude the possibility of a #Nul# value
appearing for the diurnal range multiplier in the .wxf files.

A change was made to allow a tolerance of 1 in either direction on 6 digit
WXSIM registration codes, due to an apparent computational uncertainty in the
encryption algorithm.

Changes were made to avoid errors in case certain small, optional files (such as
skiplog.txt) exist but are empty.

Clarified language on ‘Auto Compare’ form in the Retrieval Module (wret.exe).

A safeguard was added to prevent an error which could have occurred while using
GFS advection data.

Specified that the 'Retrieval Module (wret.exe) not found' error message really
require that error code instead of assuming that this was the only such error
that could occur.


CHANGES SINCE 12.5.3:

A bug which could occur after pressing ‘Start Fresh’ on the Output form has been
fixed.

Options were added to the Auto Run form, allowing omission of either the log
files (log.txt and latestlog.txt) or the comma separated variable files (latest.csv
and latestdaily.csv), or both, from the forecast run.  These files are not
essential to operation and their accessing (mainly in auto mode) may trigger
sporadic ‘Bad file name or number’ errors (#52) on certain computers.  The reason
for this is not clear, but may be associated with having a number of other programs
(perhaps especially Terminate Stay Resident, or “TSR” programs) active.  If you
encounter such errors, checking one or both of these new boxes may solve the
problem.

The wording of the command buttons has been altered slightly to be more descriptive,
and the (new wording) ‘Disable Auto Run But Keep Settings’ button now allows any
changes you made to settings to be saved, both within the current session and on
exit, for later boot-ups.

The ‘Activate scheduler on next boot up’ option now not only “sticks” (as it did
before) upon leaving the Auto Run form, but also “stays stuck” when the Auto Run
form is reactivated. 


CHANGES SINCE 12.5.2:

A bug, which caused the program to stall if both the ‘skip this screen’ and ‘start
scheduler on next bootup’ options were check, has been fixed.


CHANGES SINCE 12.5.1:

There is now a search option in the On-File Sites form, to locate a desired site
by METAR, Name, State, or Country.  This is mainly for the me (the author) so that
I can more quickly find sites in my list of over 600.  It may also be somewhat
useful for the few users who have several sites.

The data is now read using separate commands for month, day, and year, so that more
date formats should now be supported.  The two options for display are still
MM/DD/YY and DD/MM/YY.  (This change was actually implemented in 12.5.1, but I
forgot to include it in the list below) 

There is now an option to archive forecast files in a directory other than that of
the main program.  You must first create the folder.  Then, after running a WXSIM
forecast, click Save.  Then, on the form that appears, browse to and select the
desired folder and save the forecast to it.  This change will be remembered for
future saved forecast, including automatically archived ones.

There is now a check box on the splash screen (of the pretty sunset) allow you to
skip that screen in the future.  This was already possible in auto mode using the
‘Start scheduler on next boot-up’ option, but it can now be done without
automatically starting the scheduler.

A bug, which sometimes caused errors (mainly #52: ‘Bad File Name or Number’)
in auto run (for those not booting WXSIM with a third program such as System
Scheduler) has been fixed.  Now, running WXSIM continuously through auto runs
should be much more reliable than before.


CHANGES SINCE 12.5:

A bug, which allowed the time step (determined by output interval and iterations
per interval) to influence the effect of the new temperature (slope) bias
correction factor, has been fixed.

Values of the new bias correction factors, if used, are now included in the log.txt
or latestlog.txt files (right after urban heat island effect).

A bug, which occasionally allowed data on a second line of a synoptic report to be
mistaken for a station code, has been fixed.


CHANGES SINCE 12.4.5:

WXSIM can now read bias correction factors, determined from comparisons of 
archived forecasts with actual results (if you have a home weather station working
with WXSIMATE).  These are activated by checking the ‘Use learned bias corrections’
box on the form which appears when you click ‘READY/GFS bias factors’ on the Import
form.  Note: This feature is restricted to the professional mode, which all
customers who ordered before July 23, 2008 already have. Upgrading from standard to
professional mode costs $50 as of this writing.

The retrieval module now has the ability to create the correction factors (for
temperature and dew point) referred to above.  The relevant new command buttons are
‘Set as Earliest Date’, ‘Auto Select’, and ‘Omit’.

New blue text help items have been added in wxsim.exe and wret.exe to explain the
new learned bias correction features.

A change was made to wret.exe’s Weather Display log file parsing mode, to handle
uncommon log files which omit decimal points in zero rainfall values.  Previously,
this could trigger an error at line 578.  Also, reading of values with commas as
decimal separators was more widely enabled, hopefully avoiding some occasional
errors.

Minor cosmetic changes were made.

WXSIMATE no longer downloads NGM FOUS or NGM MOS, as these no longer exist as of
March 3, 2009.  You can still import them into WXSIM from old data files in case you
ever want to dorun retrospective historical runs.


CHANGES SINCE 12.4.4:

A bug in the TTAA (RAOB) parsing system, which could occasionally result in bad
sounding data.  This error involved reading a wind field with a direction of 300
or 305 as a height field for the 300 mb level.

TTAA parsing was improved to read wind speeds of over 100 knots.

The range of the temperature controls below the sounding on the upper air form
has been increased from +/-20 Celsius degrees to +/-35.  The previous range had
allowed occasional invalid property value errors (#380) in extreme weather, when
1-Click was pressed, or in auto run.

An attempt was made to eliminate errors, mainly overflow (#6), occasionally seen
when wret.exe is called in auto run or by clicking the Repeat button.  Specifically,
some DoEvents commands were added to the code, to hopefully get Windows to handle
events completely, in the order the code attempts to execute them.  Feedback on
whether this attempt was successful would be helpful, as I cannot seem to replicate
the errors.


CHANGES SINCE 12.4.3:

A typo in wret.exe's sounding plots was corrected ('850-500 mb thickness' was
changed to '1000-850 mb thickness').

Even more safeguards were instituted to prevent loss of import file name. Note
that if the name is somehow temporarily lost, the replacement name will be
c:\wxsim\wdata.txt, so that is a good name to use anyway.

A new check box, labeled 'ext boot', was added to the Output form as an option
under 'Graphic'. If checked, wret.exe will NOT be run (as it normally would be to
make graphics in auto run or right after clicking "Repeat'); instead wret.exe will
simply be prepared to make the graphics and close the next time it is booted, either
manually or by an external program such as System Scheduler. The reason for this
option is an elusive (perhaps dependent on some unknown condition in Windows) error
(#6, Overflow) that some users have encountered at times. This new check box
provides an alternative way to automatically generate the same plots and soundings.
The help files were also updated accordingly.

The diagnostic file replog.txt, which was used to narrow down possible causes of
the Overflow error described above, was omitted.


CHANGES SINCE 12.4.2:

More protections were instituted against loss of import file name.

A bug capable of causing an 'index out of bounds of array' error, especially in
subfreezing weather at sites near sea level, was fixed.

The retrieval module's sounding bitmap naming convention was changed to simple
serial numbers, instead of skipping.  You can still specify a skip interval to
determine which soundings are produced, but the numbering is now simpler.


CHANGES SINCE 12.4.1:

Further work was done to prevent erroneous reports of missing initial surface data.

Additional protections were instituted against loss of import file name and
settings.


CHANGES SINCE 12.4:

A bug (accidentally introduced in 12.4) which caused occasional repeated lines of
text on the output page has been fixed.

Another bug, which caused an erroneous report of missing initial surface data, has
been fixed.

A change was made to further ensure preservation of import file names in the event
of errors, including the file not being found.

A new log file, called replog.txt, was introduced into the code associated with
the Output form's Repeat button, to help track down the cause of a reported
overflow error (#6) which I have not been able to replicate.  Any users who
encounter this error should send this file to eburger@aol.com.


CHANGES SINCE 12.3:

Snow level was added as an output, in menu option #8, in the plain text output,
and as an output to .wxf files.  This item is calculated by working downwards
through the atmosphere until the first freezing level is found, and integrating
temperature above freezing with respct to height until an amount of melting energy,
based on the precipitation rate, in encountered.  The heavier precipitation, the
further below the freezing level it melts.  Snow level is defined here as the level
at which a large majority (perhaps 90 percent) of the precipitation is snow, though
this is a difficult and somewhat uncertain variable to calculate anyway.  However,
it should still be quite useful for users in mountainous areas.  Display parameters
can be set on the new, expanded version of the fog sensitivity form, under.

The precipitation type algorithm was tweaked in light of further research and to
better coordinate with the new snow level output.

Slight changes were made to the melting effect of frozen precipitation.  This
cooling was reduced by about 10% for sno or snow/rain mixtures.  Also, an error
which reversed the melting effects of 'snow/rain' and 'rain/snow' was corrected.

The latest.csv file (and any archived or saved versions of it) has been augmented
to include freezing level and snow level.  These are listed on the far right side.

The retrieval module, wret.exe, was expanded to accommodate snow level, which is
now displayed in the 'thickness' category.  The graphical displays in this category
are now more precisely labeled on the plots.

The sounding plots in the retrieval module were changed to include snow level, and
also to display height, temperature, and pressure on the graph at the tip of the
mouse cursor, to enable more precise examination of the sounding.

The retrieval module now allows production of bitmaps of soundings, by checking both
the 'Save Bitmap' and 'Inc Soundings' boxes on the Plots form.

The retrieval module's bitmaps are now cropped to reduce the size.  They can be
converted to other formats, such as PNG, by using a third-party program such as
IrfanView (www.irfanview.net).

Changes were made to reduce the likelihood of an error (other than File not Found
or Bad File Name or Number) causing a deletion of the name of the file to import.GFS
data consisting of zeros (as may happen if that system fails to actually parse the
data) is now treated as being simply absent.  This may reduce the possibility of any
errors resulting from such an event.

Additional notations have been added to the plain text output to indicate when WXSIM
fails to find various data types - such as GFS, READY, or METAR, SYNOP, or local
station data – to serve as a warning of possible inaccuracy in the forecast.

An error log (wretlog.txt) was created for the retrieval module (wret.exe) to help
diagnose any future errors occurring in that program.
 

CHANGES SINCE 12.2:

The boot up default values for wind speed, haze, and level 2 and 4 cloud cover
now represent rough climatological normals for the site.  Also, if no temperature
data is manually entered or imported (via METAR, SYNOP, or from local station
data), temperature and dew point will default to climatological normals for that
time of day under the given wind and cloud conditions.  This makes more reasonable
auto forecasts in the rare cases in which data is missing.  It also allows for easy
production of climatological normal temperature curves in a research or educational
mode.

Handling of date formats is now more versatile, allowing use of yyyy-mm-dd format
(used in Sweden, Poland, and perhaps some other places).  There are still only two
format choices (month/day/year and day/month/year) under Preferences, but WXSIM
will now at least correctly populate the entry form on boot-up regardless of
Windows regional settings.

A bug which caused errors and loss of import form settings, after failure to find
GFS or READY data in auto mode, has been fixed.  In auto mode, no warning will
appear to alert the user to the lack of data, but a message will be included in the
latestlog.txt file (and the forecast may be rather monotonous).


CHANGES SINCE 12.1:

A new feature was added (on the Interrupt Planner) for specifying the number of
hours permitted to pass between advection prompts.  This is intended to facilitate
updates to advection data (mainly using MOS, which is available only for North
American sites) in cases where wind shifts remain below the specified tolerance.
A good default figure is about 30 hours.

An option was added (on the Output Form) to specify saving of only the .wxf files
when archiving forecasts.  This is intended to minimize disk space usage for users
archiving large numbers of forecasts.  Manually saved forecasts will continue to
be saved as all five file types even when automatically archived forecasts aren't.

Improved error handling and messages have been provided for the case of clicking
'Get Data' on the Import form with a blank or non-existent file name in the box.


CHANGES SINCE 12.0:

A problem, which could produce 'Invalid property value' errors after importing
home weather station data showing very heavy rain, has been corrected.

A new safeguard was added, against bad METAR wind speeds imported during autorun
(for the home site).  It defaults them to 7 (mi/hr, km/hr, or whatever your units
are), though this can then be overwritten with your own local station data.


CHANGES SINCE 11.8.7:

Slightly increased thresholds for mentioning fog in the plain text output.

Expanded use of 'slight chance of' precipitation to include the lower part of the
range previously covered by 'chance of'.

Added an option (under Preferences, along with the existing minimum UV index
threshold) for omitting mention of very light or low probability precipitation
from the plaintext output.

Added site, date, and time information to the Comments section of saved forecasts. 

Slightly reduced severity of convective bulletin outputs for Northwest European
mode (in both wxsim.exe and wret.exe)..

Added information on some forms, including clarification of the use of certain
controls.

Made numerous changes to facilitate the use of different registration codes for
different levels of use: standard and professional.

Changed the demo cty.fdt file to include just two sites: Atlanta - which
illustrates professional mode - and Marks Point, Australia, which shows
standard mode. 

Updated price structuring to cover four combinations of mode and of level of
customization (basic and enhanced).

Updated surface and upper air databases used in customizing WXSIM.

Changed the TM for the intended WXSIM trademark to ® indicated the recent
registration of WXSIM with the United States Trademark and Patent Office.


CHANGES SINCE 11.8.6:

Added the ability to read Dobson unit values for up to 10 days, to be used in UV
index calculations.  These values can be obtained from web sites (see blue text
help for Ozone on Data Entry form) and used to create a simple data file.  A sample
of such a file, dobunitsAtl.txt, is now included in WXSIM's distribution and
upgrade packages.

The UV index algorithm now includes reflected radiation off of snow cover, plus
some consideration of surface type (forest, grass, desert, etc.).

Changed the interpolation scheme for determining level 1 temperatures from GFS or
READY data, in order to avoid some bad results that could previously occur when
surface pressures are very low.

Made forecast log show correct version number.

Allowed for comma as the decimal separator in the Distance Ratio item on the 
Advection form.


CHANGES SINCE 11.8.5:

MOS advection in auto run after wind shifts now defaults to using smooth curve fit,
with ‘enforce monotone’ if you so chose on the Auto Run form.  Previously, it
defaulted to a best fit line, which appears to have subdued temperature advection
after sharp frontal passages too much.

The retrieval module (wret.exe, accessible from the main program via File/Retrieve)
now enables comparison of previous forecast with Ambient’s Virtual Weather Station
software, in addition to Weather Display and WeatherLink.

The help files were updated to reflect the above changes.


CHANGES SINCE 11.8.4:

The suffix ‘NDV’ (No Directional Variation) is now understood by the METAR parsing 
routine, as applied to visibility reports.

The ‘maximum distance’ value (which you can control with a scroll bar on the
Advection form) now applies to the cutoff time for advection (when you can choose
to continue with a decay).  Previously the maximum distance simply determined
which points to leave out of the curve fit.  This change should help limit
temperature excursions in cases of sparse, inappropriately fit data, especially in
auto run, when you are not there to oversee the profile.

The auto run form has a new check box option for enforcing the monotone condition
on smooth curve fits in initial regional data advection in auto run mode.
Otherwise, WXSIM decides between monotone and not monotone fits based on the amount
of temperature inversion, with monotone applied only if a significant inversion
exists.  As in (2) above, this change is intended to reduce strongly curved 
advection profiles, which can result from sparse data (such as near coasts).

The help files were updated to reflect (2) and (3) above, and generally explain
auto run advection options better.


CHANGES SINCE 11.8.3:

Checks were added to prevent use of regional data advection in auto run mode when
no sites (METAR, SYNOP, or MOS) are found more than one fifth the maximum advection
site distance (which you can set on the Advection form).  This should prevent some
unrealistic temperature excursions that were occurring in auto run, mainly for some
near-coastal sites.

Regional data advection is now weakened in cases of poor flow curvature fits.
Specifically, flow fits of 90 percent or better remain as they were.  Flow fits
below 90 percent are weakened in such a way that, for example, a 45 percent fit
now has 71 percent as much effect as previously.

The message box saying that MOS data has run out now appears even if the user makes
repeated attempts to use this data; previously it had appeared only the first time).
In such cases, the Import form is now closed to allow immediate access to the
Advection for, to allow a new choice.

The “sleet/mix” precipitation type no longer contributes to above ground freezing
rain accumulation.

The summary.txt file is now saved in the directory in which WXSIM was first booted
up (usually c:\wxsim), which could in some cases be different from the current
directory at the time the file is saved.

The version number in the log file was updated to 11.8.4 (it had been left as 11.8.2
in Version 11.8.3).


CHANGES SINCE 11.8.2:

The auto haze routine was improved based on a recent analysis of up to 25 years of
visibility data for a few U.S. cities.  Generally, the haze amount is somewhat
less sensitive to wind speed and recent precipitation than before.  Also, a new
algorithm allows the initial (input or imported) visibility and associated haze
value to decay towards the auto haze amount, rather than abruptly changing to it.

A new output file, called summary.txt, is now produced with each forecast and
placed in the directory with WXSIM.  This file is a copy of the “Summary” ,
“Supplemental data”, “Nightime lows and daytime highs”, and “Totals” which appear
in the original forecast.

The criteria for the plaintext output’s phrases “temperatures rising after midnight”
and “temperatures falling in the afternoon” have been changed slightly, so that
average temperatures must rise or fall by at least 0.3 Celsius degrees (0.54
Fahrenheit degrees) to trigger inclusion of these phrases.  This will prevent the
phrases from appearing when temperatures are almost steady.


CHANGES SINCE 11.8.1:

(1) A bug, preventing second and subsequent scheduled auto runs with WXSIM
remaining open, had appeared first in version 11.8.  This resulted from a mismatch
between a timer in the program and the way it was being read.  It has been fixed.

(2) A bug which prevented MOS data from being read on the first try after a “MOS
not started yet” message, has been fixed.

(3) Additional diagnostic items were added to the log file.


CHANGES SINCE 11.8:

(1) A bug introduced by a changed yesterday was fixed.  In particular, users with
day/month/year format would see an error message about the month being greater
than 12 pop up incorrectly.  The protection feature still exists, but the problem
at boot up has been eliminated.

(2) Additional small changes were made to prepare for the multi-site controller
under development.


CHANGES SINCE 11.7.3:

(1) The algorithm for interpreting FOUS relative humidities as cloud cover was 
modified for the second time this year (see item #5 for Version 11.7.3, below).  
Specifically, in light of about two months of additional data, cloud cover was 
increased slightly – about halfway back to what it had been before Version 11.7.3.

(2) Based on data from many users, including several months’ worth that I had 
collected this year, a change was made to make spring slightly warmer and fall 
slightly cooler than before.

(3) Also based on the data in #2, slight changes were made affecting the shape of
the diurnal temperature curve.  The main effect that the afternoon high temperature
will occur about 10 minutes later.

(4) Based partly on the data mentioned in #2, and also on an extensive review of 
verification statistics for the GFS model since the former “parallel” version 
became the operational (and improved) one on May 1, 2007, the default model 
temperature bias adjustment was changed from +1.0 to +0.5.  The blue text help for
that item was also changed to reflect this.  Official GFS verification data can be
found at http://www.emc.ncep.noaa.gov/gmb/STATS/STATS.html.

(5) The program version number is now included in the log files.  Also, most error
messages will now be recorded in these log files.

(6) An error message will now inform the user if an attempt is made to enter a
date with a month number greater than 12.  This should catch most instances of
entering day/month/year dates when the format under Preferences is month/day/year.
If this occurs, the usually solution would be to change to the date format you
want under Preferences.

(7) A rare error in the routines for determining how old RAOB or READY/GFS data is
has been corrected.  Specifically, in earlier versions, a forecast start time
between midnight and 1 AM, using daylight savings time, was interpreted by these
routines as belonging to the previous day.  WXSIM now understands the distinction
and should determine the ages of these data blocks properly.

(8) Non-visible changes now enable use with a third program (in addition to WXSIM
and WXSIMATE), currently under development, for sequentially running forecasts for
multiple sites.

(9) A customizable adjustment was added to account for variations in the evening
temperature curve.  Most sites will not need this, but for a few future sites it
may improve temperature forecasts slightly.

(10) Two minor bug fixes, involving inconsistency between scrolling and clicking
the default frontal codes scroll bar, were fixed.

(11) A quick start guide (for both WXSIM and WXSIMATE), illustrated and in either
PDF or Microsoft Word format, is now available from www.wxsim.com/downloads. 


CHANGES SINCE 11.7.2:

(1) A bug - which could cause an “overflow” error (error #6) when the Multi-Curve
smoothing option was enacted with insufficient regional data – was corrected.

(2) A bug – which could cause an “invalid use of null” error (error #94) when
using FOUS without precipitation simulataneuously with READY/GFS data – has been
corrected.

(3) Latest.txt (and any name under which you choose to save a forecast) now will
contain complete data even if the “TEXT BOX FULL” message appears on the screen.
(That message is not an error, but simply results from Visual Basic’s 32 KB text
box size limit, and can be avoided by choosing either a shorter forecast or a
longer output time interval).

(4) A couple of typographical or formatting errors in the introctory material
were corrected.

(5) Changes were made in the way WXSIM uses FOUS data to predict cloud cover.
These changes were based on a careful study forecast versus actual solar radiation
in over 100 forecasts, including 55 re-run forecasts after modifications.  The
previous algorithm, based on comparison of FOUS relative humidities with METAR
reports, had resulted in too-thick cloud cover and too-low solar radiation
forecasts, which led to reduced diurnal temperature range during the first day
or two of forecasts for many U.S. users (as elsewhere FOUS is not available). 
The most significant error had been too-low summer high temperature forecasts.
This correction should make FOUS a more dependable and useful adjunct to the GFS
or READY component of imported model data.
 

CHANGES SINCE 11.7.1:

(1) A bug which prevented the WXSIM from properly ‘remembering’ the ‘Stop AM Rain’
setting was corrected.

(2) A bug which could cause an error when WXSIM attempted to use ‘remembered’
Recent Precip settings was corrected.

(3) The wording of the message box regarding ‘Yes/No’ refinement(s) still being
activated and warning that values must be reset or reviewed (as some may be quite
erroneous) has been made more explanatory.  This issue is bypassed when using auto
run, with old (but possibly no longer correct) data in use.


CHANGES SINCE 11.7:

(1) A bug in 11.7, which left temperature and precipitation column headings in the
new ‘daily.csv’ file as ‘deg F’ and ‘inches’ when metric units were in use, has
been corrected so that they will read ‘deg C’ and ‘mm’.


CHANGES SINCE 11.6.1:

(1) A new comma separated variable (.csv, capable of being imported into spreadsheets 
such as Excel) file was introduced, containing a wide variety of data in a daily 
summary format.  This file, whose name ends with ‘daily.csv’, complements the 
existing and much larger .csv file containing almost all output data.

(2) Most of the refinements (in particular: Auto cumuls, auto stratus, auto haze, 
recent precip, snow/ice cover, recent temps, diurnal breeze, and stop AM rain) now
have settings saved on exit.  This is really intended for use in auto run mode, as
these should ideally be set by the user at run time.  To allow the settings to 
‘stick’, the ‘Activate scheduler on next boot-up’ box must be checked and the ‘Use
Above Settings’ button must be clicked on the Auto Run form.  One item that is not
saved is the last 24 hours max and min temperatures (which are not recommended for
general use, anyway) on the Recent Temperatures form.  Also, the message (appearing
if not in auto mode with scheduler activated and splash sceen skipped) warning of
old diurnal breeze data is separate from the warning about the other refinements.

(3) Minor cosmetic or instructional changes were made, and a bug resulting from
running comparisons in the retrieval module (wret.exe) with bad or ‘gappy’
WeatherLink data was corrected by changes to WXSIMATE rather than in wxsim.exe
or wret.exe.


CHANGES SINCE 11.6:

(1) A bug was corrected, which had caused an error when data was imported after
setting a negative precipitation skew setting in the READY/GFS Bias Factor.

(2) Meters per second are now displayed as “m/s” instead of “mps”.

(3) The retrieval module (wret.exe) was updated to include the changes in WXSIM’s
UV index.

(4) The help file wxsimhelp.doc was updated to include information on the
READY/GFS Bias Factors.


CHANGES SINCE 11.5.1:

(1) Model data (READY or GFS) imported to the Interrupt Planner is now subject
to bias adjustments on upper temperatures, cloud cover, and precipitation.  To
access these settings, click the new “REAGDY/GFS Bias Factors” button on the
Import form.  Settings are saved on exit.

(2) Default frontal codes now include some consideration of current above or
below normal temperatures, so that a “return to upwind normals” assumes that
“normal” includes a fraction of the home site’s departure from normal.  This
should make default advection somewhat more accurate than before during periods
of abnormal weather, by allowing a bit more persistence of the abnormality.

(3) The UV Index algorithm was altered based on further study of a variety of
sources of data.  The general effect will be to lower UV index slightly, mainly
with low sun angles.

(4) The Dobson Units setting on the Entry form is now saved on exit.

(5) The lower limit for display of UV index in the plain text output is now
user-defineable, under Preferences on the Entry form.

(6) A very slight adjustment was made in the program, producing a barely
noticeable increase in spring temperatures and drop in autumn temperatures.

(7) An adjustment was made in the program to lower dew points very slightly,
based on a consensus of user feedback.

(8) A rare bug - in which an infinite loop error when negative wind speed in
advection sites was encountered – was corrected.  Such erroneous winds are now
set to zero.

(9) A bug, resulting in an “Invalid Use of Null” error message and occurring with
initial precipitation, was corrected.

(10) The “No data found for these sites” message during auto mode has now been
more thoroughly suppressed (see #5 under Version 11.5.1, below).


CHANGES SINCE VERSION 11.5:

(1) The precipitation description “MIX” now no longer leads to mention of freezing
rain in the plain text output unless the temperature was actually below freezing
at the time.

(2) Initial snow cover is no longer included in the first period accumulation in
the plain text output.

(3) A bug, which kept snow accumulation units on the snow/ice cover entry form
from properly switching between centimeters and inches, has been corrected.

(4) The isolated METAR signifier “T1” now will not be mistaken for the first two
characters of an extended temperature field (which can also start with those two
characters).

(5) The “No data found for these sites” message (after attempting to import
regional advection sites) has been suppressed while in auto mode.  In this case
advection will default to either ‘Default (frontal codes)’ or ‘Neutral’, according
to your earlier specification on the Auto Run form.  This should prevent many
cases of stalling while in auto run mode.

(6) Maximum UV index for the day has been added to the plain text output, as long
as it exceeds 5.5.


CHANGES SINCE VERSION 11.4:

(1) Item #4 in the revisions in Version 11.4, below, was not completely corrected
in Version 11.4.  A further change was made in 11.5 so that it will work as intended.

(2) The METAR signifier “NCD” is now recognized, as meaning “no clouds”.

(3) Some changes were made to the FOUS and Interrupt Planner shower options.
In particular, the Interrupt Planner showers now fall one third of the time, rather
than one fifth (several versions back, it had been one third), but about 9 minutes
later, in order to display the precipitation even with one hour output intervals
(with one fifth, the showers were often missed in the output).  To partially
compensate for the slightly reduced daytime highs with the longer showers, the
increase in cloud thickness due to precipitation was decreased slightly.  Also, FOUS
and Interrupt Planner showers now work together in a complex, but more accurate
(than before) manner.

(4) A minor bug, involving cloud thickness after precipitation, was corrected.

(5) Minor cosmetic changes were made.

(6) Slight tweaks were made to the advection routine and the diurnal range.  The
only noticeable difference should be a slight reduction in the initial strength of
advection (or in cases of very steep temperature gradients), generally amounting to
about one or possibly two degrese Fahrenheit warming at 12-24 hours in strong cold
air advection, for example.  These changes were made after extensive testing on
historical and recent operational data in Atlanta, plus consideration of feedback
from users in other regions.

(7) A change was made in the default frontal codes routine to slightly decrease
temperature gradients.  This probably now makes the default frontal code option
superior to neutral advection after wind shifts, when no MOS data is available.

(8) The Help item on the Data Entry form is now more informative, including mention
of the wxsimhelp.doc file, where all the blue-text help items are presented in an
organized form.  


CHANGES SINCE VERSION 11.3:

(1) There is now an option on the Auto Run dialog form allowing the the Scheduler
to activate on the next boot-up of WXSIM.  This allows starting by an external
program, such as System Scheduler, skipping the start-up splash screen, and going
straight into auto run mode.

(2) A log file (latestlog.txt) is automatically created with each run, showing
virtually all significant user actions (and some program-directed ones).  This is
intended mainly for diagnosis of problems, but can also serve as a simple record
of how the run was made, especially as it is archived and time stamped if you
choose to archive the forecast.

(3) The menu item ‘Customize’ was renamed ‘Preferences’, to avoid confusion with
the customization process involved with program registration.

(4) Auto run now distinguishes between lack of MOS data on wind shifts due to
being before, versus after, the start of the data.  Now it will read MOS in
spite of an earlier finding that it hasn’t started yet.

(5) Precipitation with chances less than five percent is now not mentioned,
either as a weather description, or as a precipitation amount, in the plain
text forecast.

(6) Persistent moderate to dense fog now precludes mention of sky condition in the
plain text forecast.  This is to avoid such combinations as “Sunny.  Dense fog.”.
Also, a new category, “moderate fog” was added, along with other slight wording
changes.

(7) Several message boxes regarding READY data were modified to include the GFS
option.

(8) If used to import local station data, WXSIMATE now produces a file called
locallog.txt, containing the same information it displays in the program itself.
Also, wording of some error messages in WXSIMATE has been improved.


CHANGES SINCE VERSION 11.2.3:

(1) The ability to use GRIB-derived GFS model data – downloaded, processed, and
made available on the internet by Chris McMahon - was added.  Other changes made
to accommodate this were the expansion of the number of interrupts of each item
on the interrupt planner from 35 to 62, and the ability for WXSIMATE to download
site-specific GFS data for use in WXSIM.

(2) A couple of related bugs in the retrieval module (wret.exe), which caused high
and low temperatures and dates to be shifted relative to each other for forecasts
made between 11 PM and midnight, were corrected.

(3) A bug in the comparison feature of the retrieval module, which caused a
failure to properly read home station (Weather Display or WeatherLink) in
forecasts spanning two months, was corrected.

(4) Temperatures and dew points in U.S. METAR reports are now consistently and
properly rounded off to whole number Fahrenheit degrees in reports with the
extended temperature section.  Previously, these would sometimes be reported
differently by one tenth of a degree.

(5) Temperatures and dew points parsed from synoptic data now have leading zeros
omitted.

(6) 24 hour max and min temperatures from local station import are now displayed
on the Recent Temperatures form even if they are not checked for use.


CHANGES SINCE VERSION 11.2.2:

(1) Changes were made to accommodate a recent (September 28) change in the READY
data’s header.  WXSIM can still recognize the older format as well, in case you
want to re-run old forecasts.

(2) A bug, which could allow certain METAR station codes to be read as weather
type abbreviations, was corrected.


CHANGES SINCE VERSION 11.2.1:

(1) A bug, resulting from the addition of a few incomplete entries to the NWS's
MOS data files, has been fixed.  This had caused a 'Bad sky cover data' message box
during MOS import for advection.  WXSIM now ignores these non-standard MOS entries.

(2) Any actual bad sky cover data now encountered will default to partly cloudy,
instead of clear.


CHANGES SINCE VERSION 11.2:

(1) A bug, which caused the plain text output wind direction to always be 'north'
when the diurnal breeze routine was in effect, has been fixed.


CHANGES SINCE VERSION 11.1:

(1) A bug in the retrieval module, which prevented changing the directory for
Weather Display forecast comparison, has been fixed.


CHANGES SINCE VERSION 11.0.2:

(1) The retrieval module’s comparison feature was expanded to include input from
Davis WeatherLink files, via a new feature in WXSIMATE which saved files in text
format as they are read for local station import.

(2) The ability was added to list the files being compared and/or combined in the
retrieval module.

(3) Compared and/or combined data in the retrieval module in the retrieval module
can now be saved as a spreadsheet-viewable .csv file.

(4) The ‘Combine’ check box now maintains its state (checked or unchecked) between
comparison retrievals in the retrieval module.

(5) The second weather text item now appears in WXSIM’s saved forecast .csv files
(it was intended to appear in earlier versions, but failed to).

(6) The column headings in WXSIM’s saved .csv files are now left-justified (instead
of right-justified), to make them more visible.

(7) Enabled printing of plain text forecast with ‘Graph and Summaries’ option
(in addition to the other options).

(8) A bug, which could cause repeated dates when retrieving forecasts made using
daylight savings time, was fixed.


CHANGES SINCE VERSION 11.0.1:

(1) A bug, which kept files from being archived properly when the ‘Quit’ button was
used, was corrected.


CHANGES SINCE VERSION 11.0:

(1) A bug was fixed in wret.exe, which had caused occasional scale problems when
viewing comparison plots of relative humidity.

(2) On the form for naming saved forecasts, the default name was changed from
'latest to latest (leading apostrophe removed). 


CHANGES SINCE VERSION 10.6:

(1) An Auto Run option (under the Start menu) has been added, allowing almost all
features of WXSIM to be used either for an immediate run or at user-prescribed times.
In conjunction with these changes, WXSIMATE can now import data at prescheduled times
as well, and the retrieval module, wret.exe, can be set for brief automatic boot-ups
and shut-downs to save bitmap graphics of forecast plots.

(2) A plain text forecast, with wording somewhat similar to zone forecasts from the
U.S. National Weather Service, now appears at the end of the previous text output,
and is also saved as a file called “plaintext.txt”.

(3) A global warming option (with the option to switch on or off under the Customize
menu) has been added.  It affects customized climate data, the world climate data
grid, and radiative properties in the program itself.  It is normalized to approxi-
mately the year 1995, meaning dates with that year will have neutral effect.

(4) The default frontal codes algorithms were improved using a large amount of
climate data for several U.S. cities.

(5) The precipitation probability algorithms were improved by mixing the existing
routine with another, seasonally-dependent estimate using the relationship between
amount of predicted precipitation and the probability of any measurable amount
actually occurring.  This relationship was derived from both historical climate data
from several U.S. cities and results from about 400 forecast-days in Atlanta.

(6) An option was added to the retrieval module (wret.exe) to allow comparison of
previous forecast data with actual data logged on home weather stations.  Currently
it requires the use of Brian Hamilton’s Weather Display program’s log files, but I
hope at some point to add support for Davis WeatherLink .wlk files as well.  A great
deal of statistical data can be gleaned from this feature, which may help with future
customizations and, in some cases, possible tweaks of existing ones.

(7) A problem with parsing certain Italian METARs was corrected.

(8) WXSIM’s Daylight Savings Time check box’s contents are now saved for the next
boot-up.

(9) Several aspects of FOUS use are better handled now, including dependable disabling
of the routine if no data was imported, and saving of settings for the next boot-up. 
FOUS can also now produce more than one wind shift if allowed to do the first one.

(10) The Search routine on the Advection form now properly imports MOS (instead of
METAR) as the default after wind shifts and correctly resets the number of sites
found to zero in between searches.

(11) A new, optional setting allows automatic archiving of forecast data files, using
the format fyymmddhh in front of the .txt., .csv, and .wxf formats.  A similar setting
in WXSIMATE allows archiving of data files in the format dyymmddhh.txt.

(12) The retrieval program now automatically defaults to the file latest.wxf on boot-
up, though you can change the file to any forecast you’ve made, as before.

(13) The apostrophe in front of the default saved file name “latest” has been removed,
as has the one in front of the retrieved data file name “lastret”.

(14) WXSIMATE can now import local station data over the internet, given a root URL
as the path.

(15) A couple of background bugs (including a redundant variable name) were corrected.

(16) Various minor cosmetic and documentation changes were made to all three programs:
wxsim.exe, wret.exe, and wxsimate.exe.

(17) The help files and manual were updated to reflect changes.

(18) A copy of the custinit.txt file (which contains your personal boot-up settings
for WXSIM) is saved, as custinitbak.txt, in case the file ever gets corrupted or you
wish to return to the settings you had before a run.  To restore the previous values
you would simply rename custinitbak.txt to custinit.txt.
    

CHANGES SINCE VERSION 10.5:

(1) All of the slider controls were changed to horizontal scroll bars, 
thus reverting to the form in all versions prior to 10.0.  There are
two reasons for this.  First, and most importantly, I learned that
installation of Microsoft Office XP or MS Office 03 apparently delete
(from Windows/System32) the comctl32.ocx which the slider control
requires, thus leading to an error in WXSIM.  By switching to the
scroll bars, this error should be avoided.  Second, the scroll bars
allow finer control of the values they represent.

(2) A rarely encountered bug, in which RAOB data segments could be
mistakenly read as buoy data (if the digits happened to be the same
as the WMO synoptic code of the buoy), has been fixed.

(3) Minor cosmetic changes were made in a few places. 


CHANGES SINCE VERSION 10.4:

(1) A new control, for ‘Maximum Distance’ was added to the advection
form.  This allows you to limit consideration of advection site data to
only those less than the upwind distance you specify.  In particular,
this applies to the various smoothing routines (working on data points
from Regional Data, Two Upwind Sites, Frontal Codes, and Direct Click)
and also to the speed (‘Spd’) and flow fit (‘%’) figures found above
the ‘Search’ button.  The straight line (segment) fit is unaffected.

(2) The ‘Difficulty reconciling total cloud cover with upper level
relative humidities’ message had been coming up too often.  This is
because the GFS READY meteogram data always seems to start with .000
as the cloud cover, before becoming reasonable with the very next report.
WXSIM now overlooks the problem if it occurs only on the first entry
(which has little effect on the output).

(3) I discovered that the (rarely used) ‘Two Upwind Sites’ advection
option was not functioning.  This has been corrected.

(4) Minor cosmetic changes were made to the retrieval module, wret.exe.

(5) Blue clickable page numbers were added to the Table of Contents of
this manual to allow instant jumps to specific topics.


CHANGES SINCE VERSION 10.3:

(1) The handling of level 1 temperatures entered on or imported to the
Interrupt Planner was improved.  Formerly, the values were interpreted
as actual level 1 temperatures.  This is still the case if you clicked
them in yourself, but now READY-based temperatures take into account
the actual pressure level(s) (i.e. 925 mb) and adjust accordingly to
the level 1 pressure in WXSIM at the time.

(2) A set of options for use of level 1 temperatures (see above) was
added.  Now the temperatures can be ignored (“0%”), so that WXSIM’s own
routines are in charge, they can be fully used (“100%”) so that WXSIM
will follow them very closely, or they can be partially considered
(“50%”) so that WXSIM uses a compromise between its native figures and
those from the Interrupt Planner.  My current thinking is that the “50%”
option may be best on average.  However, this is a new option and I am
not yet sure if it will be truly advantageous.  It does *not* always
yield temperatures halfway between the other two options.

(3) A bug was fixed involving the Diurnal Breeze option.  In the original
changeover to versions 10.6, an oversight left the Mountain/Valley Breeze
routine out of consideration for the default diurnal breeze (the other
option being Sea Breeze, which is the default unless your customization
contains specific topographic data for the Mountain/Valley Breeze).  This
has been corrected.

(4) A slight change was made to the interpretation of FOUS and READY based
winds.  In particular, non-100% wind correction factors now use slightly
different factors for winds of different speeds.  Light winds (below about
9 mph) are adjusted by relatively larger amounts than are stronger winds.
This change was motivated by my experience that wind speed differences are
best characterized as a sort of mix of additive and multiplicative corrections.
Places averaging 80% of standard winds, for example, might show 7.2 mph (80%)
when standard winds are 9 mph, but 3.5 mph when standard winds are 5 mph (70%)
and 17 mph when standard winds are 20 mph (85%).

(5) A message box was added to warn against use of METAR or SYNOP surface
data for advection, after the forecast run has already started, such as after
a wind shift interrupt.  Such use was formerly discouraged only by the
automatic switch to MOS as the default source for regional data advection.
METAR and SYNOP import at this point are still allowed, but should be used
only rarely, for instance in cases of almost immediate wind shifts (i.e. an
hour or two into the forecast run).

(6) Various minor cosmetic changes were made, mainly to some text boxes which
weren’t wide enough to hold some of the values that might be encountered.

***** ALSO, note that the new manual now contains a Glossary of Terms *****


CHANGES FROM 10.2 TO 10.3:

(1) A new option was added to the regional advection data routine
choices.  This is ‘Multi-curve fit’, which blends two of the ‘Smooth
curve’ solutions – one for the nearest half of the advection sites and
one for the farthest – using a weighted average.  The ‘~Monotone’ box
can be checked or left unchecked, as it still applies to the far-half
smooth curve solution.

(2) A small correction was made to the root-mean-square fit quality
output on the advection form’s temperature and dew point gradient plot
(~monotone had previously included a distant non-site point in the
data, slightly altering the values).  Also, the gradient plots’
internal resolution has been doubled, sometimes leading to slightly
more accurate curves.

(3) Based on further research and testing, changes were made to the
temperature and dew point advection routines.  The main effect is slight
increases in the strength of advection in the stronger advection events.

(4) Help forms now automatically unload when a new blue-text item is
clicked, so that it is not necessary to first click ‘OK’ to clear the
last help item before choosing another one.  This change was implemented
in both wxsim.exe (the main program) and wret.exe (the retrieval module).

(5) Minor changes and additions were made to the help files, to
accommodate the new advection option.

(6) A bug was corrected, which had kept the file list box on the
Cull/Append form from updating when the directory was changed.

(7) A few text boxes on the Entry form were widened to accommodate the
longer displayed text items, which in some cases had been cut off before.

(8) The Atlanta sample data in cty.fdt was updated with a newer version,
the most significant change being a small increase in the default urban
heat island effect (for this site only).


CHANGES FROM 10.1 TO 10.2:

(1) The range of allowed text widths (in both the main program and the
retrieval module) was increased to accommodate a very wide range of
system conditions.

(2) A few blue-text help items had ended up with the wrong links during
the change from Version 9.6.5 to Version 10.0.  These have now been
corrected.

(3) Label name changes from Version 9.6.5 to Version 10.0 had caused
incorrect behavior of the red versus blue caption highlighting on the
advection form.  This has been corrected.

(4) Problems were discovered in the Import/Cull/Append routine.  This
caused in some cases severe limitation of the number of METAR or SYNOP
sites culled from downloaded data.  This has been corrected.  NOTE: This
is an old routine, whose functionality and speed have been greatly
surpassed by similar abilities in the WXSIMATE program.

(5) A new document, WXSIMHELP.DOC, has been included in the package.
This conveniently displays for direct reading all of the information in
the blue-text help file help2.txt.  Many thanks to Fred van den Bosch
for this idea and for organizing it into this format.


CHANGES FROM 10.0 TO 10.1:

(1) The location list box was widened (country names were partially cut
off in 10.0).

(2) UV index is now rounded off to tenths for all sun altitudes.

(3) Slight cosmetic changes were made.

(4) It was discovered that, despite a message to saying the program was
defaulting to Atlanta, users without registration codes were still able
to access their home sites.  This has been corrected, so that the code -
obtainable by paying the upgrade fee - is now required.  
(The upgrade to 10.0 was a lot of work!). 

(5) Two new items have been added to the ‘Other Data’ section of the 
retrieval module: % Sky Cover (Lev 1, 2) and Wind Direction.  The new sky
cover item compliments the existing % Total Sky Cover item (which combines
levels 1-5) by displaying the combined coverage of just those clouds in
levels 1 and 2.  The wind direction item allows plotting of wind direction
at all forecast times, instead of just the few times a day wind vector
‘sticks’(which are still included).

(6) Updated and corrected some help file items for the retrieval module.  


CHANGES FROM 9.6.5 TO 10.0:

(1) The entire program (both the main and retrieval modules) have been
converted from the old 16-bit Visual Basic 2 to 32-bit Visual Basic 6.  This
should give the program a long future of compatibility with upconing versions
of Windows.  Backwards compatibility has been maintained so that old data,
customizations, and forecasts can be accessed smoothly from the new program.
Also, significant speed increases resulted, by a factor of about 1.7, so data
imports and forecasts take only about 60% as long as before.

(2) A new registration and custom file access method has been implemented.
This allows all users full use of the program in demo mode (i.e. using Atlanta
as a default site), while a simple registration code (provided with registration
or upgrade fee) unlocks full use of customized sites.  Also, the last site used
is conveniently the default site at next boot-up.

(3) The names of the executable files have changed: wxsim.exe replaces the
old wxsimw.exe, and wret.exe replaces wxrw1.exe.  This allows older versions
to coexist in the same directory with the new ones, in case you ever want to
compare output or performance.

(4) The forecast saving routine has been changed.  Now, all forecasts are
automatically saved as 'latest, and the save is applied AFTER the forecast run
(like most first time users seem to expect).  There is also a new button on
the output form to allow for convenient saving of forecasts right after a run.
Furthermore, there is a warning if you try to overwrite an existing file.

(5) A very carefully calibrated correction has been made for some subtle
temperature biases I discovered.  Specifically, there will be a tendency, as
compared with earlier versions, for cloudy days in summer to be warmer, cloudy
days in winter to be cooler.  Clear days at all times of year should be very
similar to before, with perhaps a trivially smaller diurnal range.

(6) Numerous cosmetic changes, including replacement of many 'scroll bars'
with 'sliders', particularly with wind direction, relative humidity, and cloud
cover, where the tick marks are particularly appropriate.

(7) Added wind arrow graphics to help user visualize the entered wind direction.

(8) Added level 1 temperature as a variable for the Interrupt Planner and READY input.

(9) Added adjustment '+' and '-' buttons the Interrupt Planner to allow quick raising
or lowering of all values of the chosen planned (or imported) item.

(10) Modified the low level mixing routine to reduce the likelihood of superadiabatic
lapse rates between the surface and level 1.

(11) Changed the Interrupt Planner's saved-file retrieval form so that it now
indicates only files with extension .pln.

(12) Improved formatting of printouts in all modules.

(13) Slightly reduced the diurnal variation of thickness and temperatures on the
Interrupt Planner.

(14) Added three new message boxes to warn (mainly) new users who fail to make
use of FOUS, upper air, and/or READY data, and give them a second chance to use
the data if they like.

(14) Added three new message boxes to warn (mainly) new users who fail to make
use of FOUS, upper air, and/or READY data, and give them a second chance to use
the data if they like.  Also, provided more explanation in the ‘Visibility
uncertain …’ message box.

(15) Changed the METAR pressure import algorithm to avoid a bug which could
incorrectly show a station pressure as a surface pressure.  Also changed both
this and the corresponding synoptic import routine to ensure precision to 0.1 mb
(previously, round –off errors were possible).

(16) Changed METAR routine to allow more reports with some missing data, such
as winds.  This may increase the number of advection sites available for use.


(Note: 17 through 23 are specific to the data retrieval module, wret.exe)

(17) Corrected various problems associated with use of Daylight Savings Time,
including a situation in which the text output would repeat the same day of the
week as the heading.

(18) Enhanced the data saving routine so that actual 24 hour and AM/PM extreme
temperatures are recorded for later retrieval with wret.exe.  (The old wxrw1.exe
will not properly read these new files, but the new wret.exe can read the old ones).

(19) Correction of a bug which had caused the dates to line up wrong on plots of
forecasts initialized just before midnight, and had also caused the text output
to sometimes repeat the same day of the week over and over.

(20) Added the WXSIM version number (10.0) to the caption of the main form.

(21) Added AM lows/PM highs to the plots (for new forecasts) and enabled use of
the new data (see (2) above)) saved by wxsim.exe.

(22) Corrected a bug which could confuse the program's determination of the
mouse position on the plots after a printout command.

(23) Corrected a small bug in the plotting routine which would combine all
precipitation before the first day displayed with the first day's precipitation.

********************************************************************

These notes refer to the shareware version of Weather Simulator
(WXSIM) completed on August 13, 2005.  This version has all the
features of the registered version, except for the site customization,
unless you happen to live in Atlanta GA, Grand Forks ND, Columbus OH,
or Sydney or Canberra, Australia - which are the demo custom sites.
With registration, you get a full customization job for your specific
site, plus 25 extra sites around the world, and full customer support.

The Atlanta and Canberra data are recent, and can use most or all of
WXSIM's features.  Columbus and Grand Forks are limited slightly by
the lack of synoptic import, and Sydney is the oldest, with very
limited data import capability, but as a coastal site lets you try
out the diurnal (sea) breeze routine.

If, after trying this shareware, with its demo sites, you decide
you'd like to own a registered version customized for your site,
please send as much of the following information as possible:

    Your site's name, latitude, longitude, and elevation
    (though a description of how to find it on a map is usually
    adequate as well).

    A brief description of the general topography and degree of
    urbanization of your site.  Relevant information would include
    whether your site is in a local low spot or on a hill, near
    a large body of water (if so, the distance and direction to
    the water at its nearest point would be useful), and whether
    the ground is predominantly sand, grass covered, forested, or
    paved.

    Whether you will be using data from an official reporting
    station or a home weather station.  One reason for this is
    that home-based wind instruments are often closer to the
    ground, buildings, and trees than those at airports, and may
    give somewhat lower wind readings.

    A short list of any preferred surrounding sites you'd like
    to use for advection.  In most cases I'll supply over 200 of
    these, out to about 1200 miles (1900 km), but I can try to
    include those you mention.  You can also provide ID's for
    a few upper air sites and NGM or Eta FOUS forecast sites in
    your region.  I will generally select 3 of each, including
    your site or in a triangle surrounding it, but welcome your
    suggestions.

    Optionally, any comments you'd like to make about your site's
    climatology.

*********************************************************************
NOTE: The ordering information below is valid as of December 29, 2012,
but is subject to change.  Please check either http://www.wxsim.com for
the latest details and ordering information.

Basic customization/standard mode  $129
Basic customization/professional mode  $179
Enhanced customization/standard mode  $199
Enhanced customization/professional mode  $249

*********************************************************************

UPGRADING:

For users who purchased after Version 10.0 (in 2004), upgrading is very
simple, and free - just run the installer at www.wxsim.com/wxsimupg.exe.
For those coming back to the program from before 10.0, there is a $49
fee.

-----------------------------------------------------------------------

WHAT THIS PROGRAM IS INTENDED TO BE:

WXSIM is a very unique piece of software, and I suspect many users
not immediately know what to do with it!  While the User's Guide
included with the registered version contains substantial help in this
area, some brief notes on the subject follow:

I began writing the program in the early 1980's as an attempt to
model a fairly generic diurnal temperature curve, something that for
some reason has fascinated me since I was in my early teens.  To make
a very long story short, I kept tinkering with this for years, bringing
new variables into the fold and collecting data against which to test
the model.  By about 1985 it had become a legitimate temperature
forecasting tool that could deal with a wide range of initial condi-
tions, including geography, climate, recent temperature data, cloud
cover, snow cover, precipitation, temperature and dew point advection,
and *much* more.

While the model was originally just for temperature, I starting modeling
other (temperature-related) variables as well, such as dew point, snow
melting and accumulation, and diurnal variations in wind speed, cumulus,
and stratus cloud cover, formation and dissipation of dew, frost, and
fog, and more.

What was (and mainly still is) beyond the model's grasp is the ability
to predict large-scale (synoptic) weather patterns and changes.  This is
partly because, except for the inclusion of temp[erature and dew point
advection (transport of these characteristics from upwind sites), the
model is in the 'single station' category.  It's also because modeling
the atmosphere on a large scale requires vast amounts of data and a 
supercomputer, and is already done (by the National Center for Environ-
mental Prediction, and others) *much* better than I could do it!

For this reason, I found it very useful to allow the user to interact
with the program, 'injecting' data into it as it runs.  For example,
say that the initial sky condition was clear, but that - based on other
model data, satellite images, personal experience, or whatever - clouds
are expected to increase rapidly after midnight, followed by precipi-
tation by dawn.  The user can simply tap a few keys or click the mouse
a few times to tell this to WXSIM *as it runs* so that the items it does
model can respond accordingly.  Alternately, you can enter changes in
advance, using the 'Interrupt Planner' form.

What you may notice in such a case is that the temperature, previously
falling under clear skies, stabilizes or perhaps even rises under the
increasing cloud cover.  It then drops sharply with the onset of precip
(if the relative humidity wasn't too high) as the dew point rapidly
increases.  The program also makes the decision as to whether the inter-
jected precipitation will fall as rain, freezing rain, sleet, snow, or
some mixture.  If it's frozen precip, WXSIM will track accumulation and
melting, and the modeled temperature will behave in a way appropriate
to all these conditions.

This is only one of *many* scenarios the program is intended to handle.
In a sense, WXSIM is not an independent weather forecasting model, but
a 'companion', whose main task is to handle temperature and other items
that are closely related to it.

It also can be used as a simulator in a sense much like that of aircraft
simulators.  Its behavior and response to changing conditions is much
like that of the real atmosphere, so that a great deal of insight can be
gained simply from 'playing' with it.


-----------------------------------------------------------------------

INSTALLATION:

WXSIM is installed via an installation program (which you have probably
just used) called either WXSIMDEM.EXE (for initial download/demo) or
WXSIMUPG.EXE (upgrade for existing users).  This is a very simple and
compact installation, placing all associated files in the same directory:
c:\wxsim by default, though you can choose another name if you wish.  It
also produces a WXSIM program group and places WXSIM's icon on your Desktop.
Here is a list of most of the files:

WXSIM.EXE
WRET.EXE
CTY.FDT
WORLD2.FDT
HELP2.TXT
WXSIMHELP.DOC
MANUAL.DOC
MAP.TXT
CUSTINIT.TXT
RETINI.TXT
NEWINI.TXT
FIRSTUSE.TXT
AUTORET.TXT
NEXTAUTO.TXT
WXF.TMP
DATA0128.TXT
DATA0129.TXT
PLAN0128.PLN
F0128P.TXT
F0128P.CSV
F0128P.WXF
README11.TXT
SEA_AF.TXT
SEA_AK.TXT
SEA_AS.TXT
SEA_AU.TXT
SEA_EU.TXT
SEA_NA.TXT
SEA_PO.TXT
SEA_SA.TXT


-----------------------------------------------------------------------

RUNNING THE PROGRAM:

The file to run is WXSIM.EXE.  You can start it in any of several
ways, ranging from double clicking on it from Windows Explorer to
creating an icon or shortcut for it (which should already be done if
you ran the setupwxm.exe program).  The program should run in
Windows 98 through Windows 8, though its appearance may be vary
slightly.  The opening screen includes buttons to click to bring
up some more information you should read before making an actual
forecast run.

Sample data files has been included so that you can see what it is
like to use the data import features.  DATA0128.TXT and DATA0129.txt
includes METAR, MAPS, FOUS, MOS, and READY data relevant to the site
ATL for January 28 and 29, 2005.  The data was obtained over the
Internet, by accessing sites discussed in the manual.  You might
want to look at this file directly using a text editor to see the
types of data WXSIM can use.  Thorough examples using these files can
be found in the User's Guide (manual.doc).

WXSIM can save output in three formats: text (.txt), comma separated
variable (.csv, for spreadsheets), and .wxf, which WXSIM's retrieval
module (accessed via File/Retrieve) can display as both text and graphics.

The program can also run automatically, without your even having to be
at the computer.  See AUTO RUN MODE (below) for more details.


-----------------------------------------------------------------------

GETTING HELP:

WXSIM is a very unique, capable, and flexible program, so there's a lot
to learn to take advantage of all it can do.  However, I've tried hard
to make it very user-friendly, and it can be run at many different levels
of sophistication - ranging from simple, limited, manual input to import
of several kinds of outside (mainly internet) information and a multitude
of user options.  Few people will just "figure it out" on their own,
however, so there are three basic ways to get help:

First, included in this package is a comprehensive manual (manual.doc),
which includes example scenario/tutorial sections.  It includes details
on just about every aspect of the program's use.  While I must admit I'm
not prone to pick up manuals first before trying new software, I must
nevertheless recommend it here, especially since the program is so unique.

Second, virtually every caption (word or term) on every form in the program
is clickable to bring up instant help on that item.  There's no index,
table of contents, or searching in this help system; it's just instant
information about every item as you encounter it.  Much of this information
is educational, even beyond its actual use in the program.  I highly
recommend clicking on every blue word you see!

Third, on the Downloads page of www.wxsim.com, you will find both PDF and
Word document versions of the WXSIM Quick Start Guide.  This illustrated
document should help you quickly learn the basics of both manual and auto
runs.  ALSO, it is now included in the installation package, and can be 
found in C:\wxsim (or wherever you installed WXSIM) as wxsimquickstart.pdf.

Fourth, I provide thorough, free customer support via email and by phone if
necessary (after initial email).  I do have a full time (teaching) job and
a family, so I'm not available all the time, but this program is quite a
'labor of love' and I want customers to understand, enjoy, and benefit from
it, so I take pride in a good record of customer service.  I'm also happy
to answer limited questions from people trying out the shareware, even if
they haven't registered it.


-----------------------------------------------------------------------

NOTES ON CERTAIN ALGORITHMS: 

There are hundreds of algorithms, curve fits, procedures, etc. in
the program.  Some of the results are visible directly on the entry
form.  Examples include sunrise and sunset times, sun altitude and
azimuth, dry bulb-wet bulb-relative humidity-dew point interrelations,
wind chill factor, and heat index.

The humidity-related algorithms were recently improved by adopting
some widely publicized curve fits (to replace my own slightly less
accurate ones).  The heat index algorithm is a piece-wise fit I
developed which, I believe, fits the official NWS table better than
another I've seen.

The sun relations are mostly straightforward trigonometry.  I did 
use a 'data-table' type approach to the 'equation of time' issue, 
and the interpolations involved may lead to errors in sunrise and 
sunset times of a minute or two in some cases - trivial for the 
purposes of this program.

The low-level-thickness-based maximum temperature estimate (an
adjunct to - rather than a substitue for - the actual forecast run)
is inspired by similar schemes used by forecasters in many areas.
This routine, however, was developed independently, using large
amounts of historical data for a number of sites, mainly in the
eastern and central United States.  It takes into account many
factors, including time of day, time of year, altitude, latitude,
humidity, cloud cover, and snow cover.  It also is incorporated into
the program in such a way as to make use of WXSIM's own upper air
profile as well as imported radiosonde or other model data.


-----------------------------------------------------------------------

SOURCES OF INPUT DATA:

WXSIM is exremely flexible in this regard.  It can run on minimal
data, such as date, time, temperature, approximate humidity, an
estimate of wind speed and direction, and a visual inspection of
the sky condition (though at this extreme, the value will be mainly
just for short term temperatures).  At the other extreme, it can employ
METAR surface reports for over 200 stations, GFS model data - either
specially prepared in advance for your exact location or from NOAA's
READY site - NAM FOUS data (for North American users), RAOB soundings,
buoy and ozone data, and both current and recent data from a home
weather station.  Generally, the more data types used, the better
the forecast.  With sufficient data (especially from external models),
richly detailed and accurate (limited to a large extent by the accuracy
of imported model data) forecasts for as long as a week can be produced.

The internet and home weather station data are quickly and easily obtained
using the (included) companion program WXSIMATE.:

------------------------------------------------------------------------

WXSIMATE PROGRAM:

This now included as a standard part pf the WXSIM package.  It provides an
easy and fast way to get the internet data types automatically, and can also
import current and recent data from certain home weather software (Davis
WeatherLink, Brian Hamilton's Weather Display, and Ambient's Virtual Weather
Station, as of this writing).

------------------------------------------------------------------------

WRET PROGRAM:

This is a powerful data analysis and display tool, which provides text and/or
graphical display for over 80 forecast variables.  It also allows for direct
comparison of forecast to actual data (for users with home weather stations)
and even allows (in WXSIM's professional mode) WXSIM to 'learn' from past
mistakes!

-------------------------------------------------------------------------- 

AUTO RUN MODE:

While the program can be run manually, it is also possible (and quite popular)
to have WXSIMATE and WXSIM run in fully automated mode, for weeks on end, without
interference from you (though attention might be needed sporadically for various
reasons).  With the help of other software or scripts (including some nice third-
party ones), excellent graphical and text output can be displayed on the web, in
a variety of languages.

--------------------------------------------------------------------------

DISCLAIMER:

The author disclaims any responsibilty for damages of any type
resulting from the use of this program or its output.  This
includes but is not limited to hardware or software corruption of
your computer.


-----------------------------------------------------------------------

FINALLY:

Enjoy the program - I've enjoyed writing it!  I'd love to hear
feedback, whether you decide to register or not.  My email address 
is eburger@aol.com.

Tom Ehrensperger
July 30, 2017