Download and unzip krasnoff.zip if you want to download your own copy of the Krasnoff Soaring Simulator, or if you can't handle PC zip files, look in the local install section.
Along the top of the screen are a set of buttons labelled 'Practice', 'Day 1', 'Day 2' etc. Select which day you want to fly, and the various panels on the page will be initialised to startup values for that day. Make careful note of the weather briefing, in particular the expected timing of changes in conditions. Each day has different conditions and a different task set, and your starting altitude will be 2000 feet, as if you have just released from tow. If during the flight you forget the assigned task, click the 'show task' button.
After selecting a day, click the 'Hunt' button to hunt for a thermal. This button gives you a very low cross-country speed but improves your chances of finding a thermal. As you haven't started the competition task yet, the cross-country speed doesn't matter and you simply want to climb to cloudbase prior to starting. As you 'hunt' you'll see the time counting forwards and your altitude reducing.
When you are offered a climb, either accept it by clicking the 'Climb' button, or continue looking for another thermal with the 'Hunt' button. Perhaps the simplest thing to do is to accept the first climb you are offered and climb to cloudbase.
When the climb reaches cloudbase, the climb will stop and the simulator will wait for you to hit a 'Cruise' button to continue. First, hit the 'Start Task' button to call a start. Then, click the 'Cruise 80' to set off on track at 80 knots. The altitude will count down as your distance counts up, until you reach the next thermal. As you are cruising, you can select another cruise speed mid-cruise by clicking on the appropriate 'Cruise' button. Hence you can fly at 90 knots down to 2000 feet, and then select 60 knots while you pray for a thermal. If things look really bad (e.g. you're under 1000 feet) click the 'Hunt' button - your chances of finding a thermal are increased, but your progress on track is very limited.
Essentially, just like gliding, you now continue in a climb-glide-climb-glide manner until you've reached the goal. The simulator will call 'Good Finish' when the distance shown reaches the task length set for the chosen day, or will give 'Landed Out!' if you get low and don't reach the next thermal.
The idea is that competition flying techniques used in real flying should improve your cross-country speeds in the simulator. These include the following:
The simulator is implemented entirely as HTML and JavaScript, in a set of source files which are freely readable and copyable. In fact you can copy these files to your local PC and run the simulator entirely locally.
It is worthy of note that the simulator doesn't contain any 'special' rules for the behaviour of the glider other than a table containing the sink speeds at various cruise speeds (see the polar table). To simulate a different glider or the carrying of water ballast only the polar table need be altered.
The simulator maintains three particular pieces of information as you proceed around the task:
The simulator repeatedly makes a random selection at check points in the flight:
In both cases, the values are looked up in the 'current conditions' table. The look-up is implemented by generating a random number between 1 and 20 (in effect throwing a dice with 20 sides) and using that number to look up a lift strength or distance in the appropriate table. The simulator currently has tables representing six sets of conditions defined (0=normal Cu, 1=strong Cu, 2=over-convected, 3=blue, 5=weak, 5=weak-blue), given in the conditions tables below.
The current table to use is given by a variable in the program called 'current_conditions', and this value can be changed during the flight to simulate changing weather conditions. When and how this value should change is defined in the day file (e.g. 'k_day1.html'), so different days can be defined with different tasks and conditions without having to alter the actual simulator. A description of the key values defined in the day file is given in the day file section of this page. The simplest day file need not select a new conditions table at all, so conditions remain on 'type-0', i.e. normal Cu, throughout the flight. For a more complex day, the conditions can be changed at a certain time or on reaching a certain distance.
One parameter setting the conditions as you fly around the task is 'thermal_width' in feet, with most conditions setting this at about 1000 feet. The simulator assumes you straight climb for this distance. The climb rate is the netto strength of the thermal you've just entered minus the minimum sink of the glider. The time spent climbing in a straight line is calculated as the time taken to fly the 'thermal_width' distance at a speed taken as the average of 60 knots and your most recent cruise speed. Pull-up height is then 'climb rate' times 'time spent climbing'.
If you fly at 60 knots, in a glider with a min sink of 1 knot, and enter a thermal with a netto strength of 4 knots and thermal_width of 1000 feet, you pull-up will be calculated as follows:
Average speed through rising air = 60 knots (=100 feet per second).
Time to fly across lift = 1000 feet crossed at 100 feet per second (=10 seconds).
Climb rate of glider = 4 knots (netto) minus 1 knot (min sink) = 3 knots (=300 feet/min, 5 feet per second).
Pull-up height = 10 seconds times 5 feet per second (=50 feet).
Hence the following will improve your pull-up height:
Note that the simulator is not simulating the speed-versus-height tradeoff as you decelerate into the thermal, nor the reverse trade-off as you exit it, as these should mostly net out. I guess I could do an altitude adjustment based on speed change each time you enter/exit a thermal or select a new cruise speed. Later, maybe.
Please note that the conditions tables have been modified since this was written, but the principle remains broadly the same. The conditions tables now contain netto climb values, and the actual climb of the glider is calculated from the thermal value minus a sink value for the ballasted glider. To keep the day conditions similar to those planned below, I upped the values in the table from those given below by approx 1 knot, so the true climb (netto minus sink rate) remains about the same. Also each condition also has a 'thermal_width' parameter, which affects pull ups (see above).
For this section you really need an appreciation of the basic structure of a web (html) document, and ideally a basic understanding of web page scripting (JavaScript). I really do mean basic, though, so you should get the idea even if you don't have that knowledge.
Each 'day' page is loaded into the bottom half of the browser when you click the day selection button. You can 'view source' of the day page by right-clicking on the newly loaded day description and selecting 'view source' on the mouse menu. You will see that the day page is just text, marked up for the browser fomatting, plus a header section giving the parameters defining the page.
In the day file, you define all the parameters (key-values) associated with the day, plus the welcome text which appears when that day is selected. The key-values are given as the values of a set of variables in the 'head' section of the web page (between SCRIPT tags) while the description of the day is given as the main 'body' of the page.
Here is an example of the the key-values defined in a typical day page ( 'k_day0.html', you can open the page, ignore the errors, and 'view source').
var task_length = 302; // DEFINE YOUR TASK LENGTH (in km) HERE
var tp = new Array("Gransden","Didcot","Leicester");
var leg_length = new Array(90,130,82);
var leg_wind = new Array(10,2,-8); // head (pos) / tail (neg) wind
var events = new Array("general,time,13:00,conditions,1", // stronger
"general,time,14:20,conditions,3", // blue
"general,time,14:50,conditions,5", // weak-blue
"special,distance,80,100,conditions,2"); // over-convected
These five items, with the associated 'conditions' data in the simulator (see below) completely define the characteristics of a particular day, and each item is explained in the following sections.
Here you define the overall length of the competition task in kilometers. The simulator will load this figure and continually compare your achieved total distance with this figure to establish whether you have completed the task.
In this array (don't worry about the format if you are not familiar with JavaScript), you can put the text names of the turnpoints (omitting the finish, which is assumed to be the same as the first tp).
note: the simulator currently does not us these values... I'm thinking of improving the 'distance-to-next-tp' field with the actual name of the turnpoint.
In this array the length of each leg of the task (which have to add up to task_length) is given. While the simulator fundamentally keeps track of total task distance flown, this data can be used to simply calculate the 'distance-to-next-tp' figure, and to change the headwind/tailwind according to the current leg you are flying.
This array give the headwind(+) or tailwind(-) on each leg, in knots. This figure is subtracted from the cruise speed to give penetration speed during cruise, and is used to adjust the distance flown with drift while you are thermalling.
Now here is the complicated piece... this simulator is a computerized development of a card game created by Peter Krasnoff, in which the next thermal or distance flown is truly random. The first version of this simulator generated the 'next thermal strength' or 'next cruise distance' by generating a random number between fixed bounds. For example, 'next thermal strength' was generated as a random number between 1 and 8, and this meant you would fly along with 1 knot thermals one minute and possibly 8 knot thermal the next. This was too random to be realistic, and so the 'conditions table' was created, in which the random number was used a a 'seed' to point into a table to look up the thermal strength or cruise distance.
The first simulator had one, fixed, conditions table. The results of a simulation were surprisingly realistic, especially when wind was added. The values in the table could be simply adjusted to model a realistic distribution of thermal strengths (or in another column, cruise distances) found on a typical flight. For typical (good) English conditions, I bunched the values around 3.5 knots, with some weaker thermals thrown in and a smaller number of stronger ones. If you disagree with the values given, you can edit the table to something you are more happy with. At any rate the technique is far more controllable than the simple generation of a random thermal strength between set bounds.
Having the conditions defined in a table meant that the conditions could be changed simply by loading a different table, but the less simple issue is how to trigger that change in the simulator. Also, the change in conditions should be specified somehow in the 'day' file, so that many different setups can be stored representing different competition days.
The changing conditions are defined in the 'day' file in the 'events' array.
var events = new Array("general,time,13:00,conditions,1", // stronger
"general,time,14:10,message,Looks stronger ahead!",
"general,time,14:20,conditions,3", // blue
"general,time,14:50,conditions,5", // weak-blue
"special,distance,80,100,conditions,2"); // over-convected
The simulator always starts with conditions type-0, and the example above defines 4 events:
Each event is defined as either 5 or 6 fields, representing the circumstances under which the event should be triggered and the action to be taken when the trigger occurs.
There are (currently) two types of event, general and special, given as the first word of the string defining the event. A general event occurs once when the associated circumstances are met, e.g. in the example above the conditions are changed to type-1 as soon as the current time passes 13:00, and no further action will ever be taken associated with that event. A special event is slightly different: the associated action can be thought of as applying between the two limits set in the event. After the second limit is reached, the associated parameter reverts back to its value before the event was triggered. So a special event changing conditions can be thought of as two events: one to set the new conditions, and one to revert back to the previous ones.
A 'general' event triggered by time is a good way of systematically changing the conditions during the day, i.e. you create a set of events to change the conditions at 1pm, 2pm, 4pm, 5pm etc.
A 'special' event can be used to set up certain conditions (e.g. spreadout) on a particular section of the task by using a 'distance' trigger around the distance of the tp (maybe 10km either side).
There are (currently) two parameters which can be measured to trigger an event, time and distance. Time is specified in hh:mm, and distance in kilometers. For example, when the current distance exceeds the value given in a general distance event, the associated action will be triggered. The event will then be flagged to prevent it being triggered again.
There are (currently) two permissible actions, namely to pop up a message or to change the current conditions. It wouldn't be difficult to define some more actions, e.g. to have an area of sink, but I haven't got around to that.
Hopefully it is clear that you specify a 'general' event with five fields in total, separated by commas: 'general', 'time' or 'distance', trigger-value, 'message' or 'conditions', message-string or conditions-type. A 'special' event is similarly specified except with an additional 'trigger-value' field to indicate when the event should no longer apply.
Note that when you define the events, a suitably worded description of the task needs to be written in the 'body' part of the day file. This is the bit that the user actually gets to see.
When you select a 'cruise' button, the simulator updates your distance-to-go at the appropriate rate (cruise speed minus headwind) and reduces your altitude at the rate given in this table. This gives the flight performance experienced by glider pilots, of poor apparent glide performance and slow cross-country speed into wind, and long extended glides downwind. I am yet to find out whether a higher cruise speed is appropriate for the last glide of an into-wind leg (I suspect you should) but I may find out through practice with the simulator.
| Speed | 60 knots | 70 knots | 80 knots | 90 knots | 100 knots |
| Sink | 1.5 knots | 2.0 knots | 2.7 knots | 3.6 knots | 5.0 knots |
At each 'checkpoint' of the simulator (start of cruise, reaching a thermal, clicking 'Hunt') the simulator effectively rolls a twenty-sided 'dice' (i.e. generates a random number between 1 and 20) and uses the result to look up a thermal strength and inter-thermal distance from an appropriate 'conditions' table. Note that the dice is rolled for each of the thermal strength and the cruise distance, so you are equally likely to to get a stronger thermal at a shorter distance or vice versa.
Look-ahead message: Cumulus clouds can be seen in the distance.
Description: The sky is full of good-looking cumulus clouds. Cloudbase is about 4000 feet
| 'Dice' | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| Thermal knots | 0.5 | 1.1 | 1.5 | 2.1 | 2.5 | 2.7 | 3.2 | 3.5 | 3.6 | 3.6 | 3.7 | 3.7 | 3.7 | 3.8 | 3.8 | 3.9 | 4.4 | 4.5 | 4.8 | 5.2 |
| Distance km | 0.5 | 1.0 | 1.1 | 2.0 | 3 | 5 | 6 | 6 | 7 | 8 | 10 | 11 | 11 | 12 | 12 | 12 | 14 | 16 | 18 | 20 |
Look-ahead message: Cumulus clouds can be seen in the distance.
Description: The sky is full of good-looking closely spaced cumulus clouds. Cloudbase is approximately 5000 feet
| 'Dice' | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| Thermal knots | 0.5 | 1.1 | 1.5 | 2.1 | 3.0 | 3.2 | 3.7 | 4.0 | 4.1 | 4.6 | 4.7 | 4.7 | 4.7 | 4.8 | 4.8 | 4.9 | 5.4 | 5.5 | 5.8 | 6.2 |
| Distance km | 0.5 | 1.0 | 1.1 | 1.4 | 2 | 3 | 4 | 4 | 4.5 | 6 | 6.6 | 7 | 7 | 8 | 8 | 8 | 9 | 10 | 12 | 14 |
Look-ahead message: The sky in the distance looks over-convected.
Description: The sky has over-convected, with 6/8ths Cu and rapid cycling. Cloudbase is around 4000 feet, and the climbs are harder to find.
| 'Dice' | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| Thermal knots | 0.5 | 1.1 | 1.5 | 1.6 | 2.2 | 2.2 | 2.3 | 2.3 | 2.4 | 2.4 | 2.5 | 2.6 | 2.6 | 2.7 | 2.8 | 2.8 | 2.9 | 3.0 | 4.0 | 4.5 |
| Distance km | 0.7 | 1.5 | 1.8 | 3 | 6 | 9 | 9 | 12 | 12 | 12 | 15 | 16 | 16 | 18 | 18 | 18 | 20 | 22 | 27 | 30 |
Look-ahead message: The sky in the distance looks blue.
Description: The sky has gone completely blue. Cloudbase is around 4500 feet, and the climbs seem further apart.
| 'Dice' | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| Thermal knots | 0.5 | 1.1 | 1.5 | 2.1 | 2.5 | 2.7 | 3.2 | 3.5 | 3.6 | 3.6 | 3.7 | 3.7 | 3.7 | 3.8 | 3.8 | 3.9 | 4.4 | 4.5 | 4.8 | 5.2 |
| Distance km | 0.7 | 1.5 | 1.8 | 3 | 6 | 9 | 9 | 12 | 12 | 12 | 15 | 16 | 16 | 18 | 18 | 18 | 20 | 22 | 27 | 30 |
Look-ahead message: The sky in the distance has weakening Cu's.
Description: The Cu's look scattered and weak. Cloudbase is around 3500 feet, and the climbs seem further apart.
| 'Dice' | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| Thermal knots | 0.3 | 0.6 | 0.8 | 1.1 | 1.3 | 1.4 | 1.6 | 1.8 | 1.8 | 1.8 | 1.9 | 1.9 | 1.9 | 1.9 | 1.9 | 2 | 2.2 | 2.3 | 2.4 | 2.6 |
| Distance km | 0.7 | 1.5 | 1.8 | 3 | 6 | 9 | 9 | 12 | 12 | 12 | 15 | 16 | 16 | 17 | 17 | 17 | 18 | 18 | 20 | 21 |
Look-ahead message: The sky in the distance is blue.
Description: The sky has gone completely blue. Cloudbase is around 3500 feet, and the climbs seem further apart.
| 'Dice' | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| Thermal knots | 0.3 | 0.6 | 0.8 | 1.1 | 1.3 | 1.4 | 1.6 | 1.8 | 1.8 | 1.8 | 1.9 | 1.9 | 1.9 | 1.9 | 1.9 | 2 | 2.2 | 2.3 | 2.4 | 2.6 |
| Distance km | 0.7 | 1.5 | 1.8 | 3 | 6 | 9 | 9 | 12 | 12 | 12 | 15 | 16 | 16 | 18 | 18 | 18 | 20 | 22 | 27 | 30 |
The easiest way is to download and unzip krasnoff.zip, but if you can't handle PC zip files, follow the instructions below.
If you are familiar with downloading web pages from a web site, simply collect all the html pages in this directory and copy them onto your local PC. The simulator is written entirely in JavaScript and will run locally on your PC without change.
If you are less familiar with the process, follow these steps: