PL-TR-92-2097 A SINGLE-STATION FORECASTING MODEL William H. Jasperson David E. Venne Miriam R. Peterson gig =Z._ W Augsburg College L Center for Atmospheric and Space Sciences 731 21st Ave South Minneapolis, MN 55454 1 April 1992 W% ELCTE JUL 15 19092 SA Final Report 15 December 1988 - 15 January 1992 Approved for public release; distribution unlimited j Phillips Laboratory Air Force Systems Command Hanscom Air Force Base, Massachusetts 01731-5000 92-18198 .......... l ...... ... ...
Transcript
PL-TR-92-2097
A SINGLE-STATION FORECASTING MODEL
William H. JaspersonDavid E. VenneMiriam R. Peterson
gig=Z._
W Augsburg CollegeL Center for Atmospheric and Space Sciences
731 21st Ave SouthMinneapolis, MN 55454
1 April 1992 W% ELCTE
JUL 15 19092SA
Final Report15 December 1988 - 15 January 1992
Approved for public release; distribution unlimited
j Phillips LaboratoryAir Force Systems CommandHanscom Air Force Base, Massachusetts 01731-5000
92-18198.......... l ...... ... ...
This technical report has been reviewed and is approved for publication.
06SEMARY M. DYER DONALD A./CHISHOLMContract Manager Chief, Atmospheric Prediction Branch
Atmospheric Sciences Division
IR09tRT A. McCLATCHEYDirector, Atmospheric Sciences Division
This document has been reviewed by the ESD Public Affairs Office (PA) and is releasable to theNational Technical Information Service (NTIS).
Qualified requestors may obtain additional copies from the Defense Technical Information Center.All others should apply to the National Technical Information Service.
If your address has changed, or if you wish to be removed from the mailing list, or if theaddressee is no longer employed hy your organization, please notify PLTSI, Hanscom AFB, MA01731-5000. This will assist us in maintaining a current mailing list.
Do not return copies of this report unless contractual obligations or notices on a specificdocument requires that it be returned.
T 'c' Ap~prcaed
REPORT DOCUMENTATION PAGE o1, no 'A0o788
•%tp~ei~r++ 3pC + },nt + 01 , A • *''if•+ I, r. 'o-0 e "• I1ti•i q the rt'e OrreJ n sthuI tl e ar 'r , e ths r d ., sou r'e C -, ,1 ''II ' ' I~C1 r -0C1.elir *,h J I .- ,-- er, n r r0ra,'r S' hrrerrts reP rI-M- tr,sburde 'st-,lre ,"v Itherp, r I; .1 01 hS
qell,0'r " 0,•_ '+r' • (o, rrr 42".-1. r COLA ',1rI ' A •t.., jrM* . adLaýrters if ,e r!)viteN , rnmralton DO'.rvitrs and' epCrts. 1) lb Jeflrsonsr€•,+ "rp~a.or , 2,r l, .( l .. ', .: 2 2 tV) + a , a 4 ; ' H' • ' ,;" -0' tCd get ",pe-or' k ReCdu Ctlr Pre-Ct fO 04-0198) •'/. .n ton 'C 20503
I. AGENCY USE ONLY (LeP ve bla,'k 2. REPORT DATE 3. REPORT TYPE AND DATES COVERED
11 April 1992 Scientific Final (15 Dec 88---15 Jan 92
4. TITLE AND SUBTITLE 5. FUNDING NUMBERS
A Single-Station Forecasting Model PE 62101FPR 6670 TA 10 WU DD
6. AUTHOR(S) Contract F19628-89-C-0015William H. JaspersonDavid E. VenneMiriam R. Peterson
7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION
Augsburg College REPORT NUMBER
Center for Atmospheric & Space Sciences
731 21st Avenue, SouthMinneapolis, MN 55454
9. SPONSORING / MONI IORING AGEN. f NAME(S) AND ADDRESS(E S) 10. SPONSORING / MONITORING
Phillips Laboratory AGENCY REPORT NUMBER
Hanscom AFB, MA 01731-5000
PL -TR-92-2097
Contract Manager: Rosemary Dyer/GPAP
11. SUPPLEMENTARY NOTES
12a. DISTRIBUTION/AVAILABILITY STATEMENT 12b. DISTRIBUTION CODE
Approved for public release;Distribution unlimited
13. ABSTRACT (Maxpmum 200 words)
This report describes the development of an advanced prototype expertsystem, named Itasca, for the classical single-station weatherforecasting problem. The forecasting skills necessary to produceforecasts from limited data are being lost though they continue tohave application to certain military scenarios which includecommunications interruptions. Itasca is intended for use at anarbitrary mid-latitude station, and utilizes physical relationshipsbetween the synoptic weather and variables that affect the localweather rather than station specific rules. Itasca is designed as animbedded expert system where the user has control over the operationof the system through a user interface. Rule bases are loaded andused as appropriate to the task at hand. The rule bases and theclass/object structure used in the expert system were developed usingthe NEXPERT-Object development system. Testing of the system duringdevelopment was limited by the lack of suitable datasets, but a planis in place for further independent testing and evaluation.
JEstdicat~on ............... HB y .. ......... .... ... .................
Di); ibkjtio: I
Availab~lity Coý''-,S
Av'. a;. orDist
1. INTRODUCTION
The needs of the Armed Services for accurate, timelyforecasts of environmental conditions have becomeincreasingly critical with the evolution of currentoperational requirements and sophisticated weapons systems.Accurate forecasts of basic meteorological fields such aswind, temperature, cloud cover, precipitation, andvisibility are essential for the planning, execution andsuccess of almost any operation.
The best forecasts are created by a human forecaster,experienced with the geographic forecast area, interpretingdata and computer-generated (numerical or statistical)forecast products. However, the Armed Services must beprepared to make critical forecasts even in the event thatdata and/or products from central collectors becomeunavailable. Questions that must be asked are: Is aforecaster trained to forecast the weather utilizing moderntools able to perform adequately when these tools are notavailable? How does a forecaster inexperienced with theforecast area perform when only limited observational dataare available? Can a forecaster cope with both the loss ofstandard products and the pressure to provide usefulforecasts in this scenario?
Artificial intelligence (AI) has been identified as apotential tool for solving difficult problems of thisnature. Practical outgrowths of this field of research areknowledge-based software systems, sometimes referred to asexpert systems. Knowledge-based systems have the capabilityto encapsulate the knowledge experts use to solve problemsand make it useful to less experienced individuals.
During the past several years, several meteorological expertsystems have been developed. The applications range frjmforecasting snowfall in Colorado (Swetnam and Dombroski ),to forecastirg of thunderstorms and severe weather (Rieseand Zubrick; Elio, de Hann and Strong ; McArthur, R. C., J.R. Davis and D. Reynolds 4 ), to interpretation of D?pplerimagery in detecting wind shear hazards (Campbell; Olson6 ;Campbell and Olson ), to forecasting fog (Stunder, et al.8 ).This last system has been evaluated for its applicability tolocations obher than those for which it was developed (Dyerand Freeman ). There has also been significant recentinterest in evaluating different expert systems designed forforecasting severe weather, and the results of the most•2npxehensive comparison is given by Moninger, et al.1u
TbLi Ij ye ot tle project described in this report was todevelop a knowledge-based system, hereafter referred to asItasca, that can be used to make short-range weatherforecasts from limited input data. This "single-station"
1
method of forecasting was develyyed during World War II forshort range weather forecasting . Specifically, Itasca isto make hourly forecasts of each of the input variables forthe six to twelve hour forecast period. To our knowledge,it is the first system that attempts to forecast more than asingle meteorological event. Providing a forecast of manyvariables implies a complexity that impacts the structure ofthe system, the user interface, and the data and knowledgecontained within the system. This report describes thestructure and operation of Itasca and concludes withcomments and recommendations for further work.
2. SYSTEM DESCRIPTION
In the early stages of Itasca development, it was realizedthat the task of forecasting short-range weather fromlimited data requires a variety of skills. Some of theseskills, such as heuristics concerning physical behavior, canbe efficiently described in terms of collections of rules,commonly referred to as knowledge bases (KBs). Other skillsmay require the use of computations or sophisticatedstatistical methods.
The diverse set of tools required to embody these skills andmake them accessible to the user suggested that the Itascasystem could be most successful if it were a conglomerate ofsoftware tools. The alternative, in which the expert systemis developed using a single tool or programming language,was juidged to lack the flexibility needed to address theforecasting problem. Many previous systems built using onlya single software tool (e.g., an expert system shell) orprogramming language (particularly one considered to be an"AI language" such as Lisp) have been very good at dealingwith one aspect of their targeted problem but performedother functions poorly or inefficiently.
Therefore a primary design goal for Itasca was to give itthe potential to use a wide variety of tools effectively andefficiently. This was accomplished by using a programminglanguage (C) common to microcomputers and UNIX-basedworkstations as the "backbone" of the system on which thenecessary tools could be supported. The added benefit ofusing a common programming language was that a variety ofgraphics and interfacing software packages were availablefor use. A description of the C program in which thecontrol structure of Itasca is embodied is presented inSection 2.1.
Itasca currently uses a knowledge base system developmenttool called 1ETXPERT Object (hereafter referred to as NO) tocreate and maintain expert knowledge. NO provides a richand powerful environment for the encapsulation and use ofmeteorological expert knowledge that is accessible from C
2
language routines. NO knowledge bases are hierarchical, canbe moved in ond out of machine memory as needed and providea freedom in knowledge representation that is advantageousduring development of a system like Itasca. The NOknowledge bases, their organization and use are described inSection 2.2.
The process of meteorological analysis and forecasting is ahighly visual exeicise, therefore Itasca was designed toincorporate graphic capabilities. While the graphicaldisplay of meteorological features (for example, thegeographic depiction of the locations of pressure centersand fronts) is a future goal for Itasca, the current userinterfaces incorporate graphical as well as numericalrepresentations of the observations. The Itasca interfacesare described in Section 2.3
2.1 Control Structure
The portion of Itasca that is coded in the C language isintended to perform the functions of analysis/forecastingsession control, observation data management, graphicsoperations, user interactions and computationally-intensecalculations. The first of these responsibilities, control,is delegated to the C programs because of the difficultytraditional knowledge-based systems have in expressingcontrol operations. Small knowledge-based systems may notsufter significant penalties caused by the use of rules (ortheir analogs) to control system operations. However, largesystems such as Itasca often have a significant portion oftheir rules dedicated to controlling operations that havelittle to do with expert knowledge manipulation. Routinescoded in C are well-suited to controlling administrative andprocedural cperations; using C routines in this way allowsthe knowledge bases to be structured more clearly andconcisely.
The controlling C routines are loosely divided into blocksthat are roughly analogous to the major tasks of theforecaster. The initialization block establishes the localenvironment in terms of geography and climate. Theobservation block is used to input, modify, and preprocesssurface and upper air observations. The analysis blockproduces a representation of the current meteorologicalstate, and the forecdst block is concerned with forecastingthe future meteorological state. Some routines have widerapplications and can be considered global rather thanbelonging to any one block. Examples of these globalroutines are computational routines and graphics and systemutilities.
The management of observational databases is anotherimportant t.,'ý k of the C program. Itasca maintains adatabase for each type of observation (standard and special
3
surface observations, radiosonde and pibal observations) anda number of routines allow the user to enter, inspect,modify, and extract observation data from these databases.Other routines search the databases for data to be used inmaking analyses and forecasts, in effect selecting a subsetof observations that is relevant to the task. A special setof routines manages information about clouds, includingthose observed, inferred and potentially existing.
Meteorological numerical calculations are performed by alibrary of C routines. These routines contain thealgorithms needed t o determine such quantities as stabilityindices, thertnodynamic values, diurnal variations, solarparameters, shears, time averages, and so on.
C routines are used to control all user interfaces andgraphical presentations. These will be described in Section2.4.
2.2 Knowledge Bases
2.2.1 Introduction to Terminology
Before describing the knowledge bases constructed duringItasca development, a brief overview of the terminology usedin this Section may prove helpful. Although some of theterms used here are common to most traditional AI systems,the use of a specific knowledge base tool (in this case, NO)brings about an inevitable use of jargon. In this report anattempt is made to minimize the use of obscure or tool-specific words.
The primary knowledge base building block is a rule. Rulesexpress knowledge that relates a condition to a consequence.Rules are often called "if-then" constructs because of theform of this relationship: If a condition or set ofconditions is true, then the consequence is true. A simpleexample of a rule is if the 500 mb wind is from the west andif the observation is from the Northern Hemisphere, then lowpressure is located toward the north. In NO the consequenceis referred to as the hypothesis.
A condition in a rule may be (or contain) the hypothesis ofone or more other rules. Therefore, to find the validity ofa given hypothesis, other hypotheses may have tc beevaluated. Titls linkage of rules thzough their conditionsand hypotheses forms the basis of rule-based systems, andthe rules can be evaluated in what is called backward and/orforward chaining. NO allows more complex metho(cs of workingwith rules that will not be described here.
A set of actions may also be associated with each rule suchthat when a hypothesis is determined to be true (because allof its conditions are true), these actions will be
4
initiated. These actions may be of many forms includinginitiating the evaluation of a new hypothesis, setting avalue or evaluating a function.
Representational structures such as objects, properties andclasses are used within an expert system to describe theentities in the system. An object in NO is just what itsname suggests - an entity with one or more properties. InItasca, the largest and most visible use of objects is therepresentation of meteorological features. A cold front isan example of an object within Itasca. While all cold frontobjects have the same set of properties, the values of thoseproperties ace different and specific to each individualcold front. Properties associated with an object are calledslots (the terms "property" and "slot" will be usedinterchangeably). Slots can have numeric, text and specialvalues such as Unknown and NotKnown. A slot has the valueUnknown if the system has not tried to determine its value,and has the value NotKnown if the system has beenunsuccessful in its attempt to determine the value.
A class is a grouping of objects that have one or moreproperties in cc.Tnmon. For example, the class Coldfrontdefines the set of properties that all the cold frontobjects will have. When a particular cold front object iscreated, it has the ability to inherit the properties of itsparent class, Coldfront. An object may descend from morethan one parent class. The network of parent classes andchild objects form a knowledge structure for representingcomplex entities within the system.
The purpose of rules in Itasca is primarily to create anddestroy objects, when appropriate, and to determine thevalues of their slots. Slots may obtain values in severalways. One way is to inherit the value of the same propertyfrom its parent class. A second way slots are filled isthrough the actions of rules as previously mentioned.Another very useful way slots obtain values is through a setof actions that can be attached to the slot; these actionsare executed when the value of the slot is requested but iscurrently unknown. These are called order of sourceactions, and may include the evaluation of the slot from anexternal source such as a function, the loading andexecution of another knowledge base to determine the slotvalue, the -luerying of the user or the assignment of adefault value.
5
Finally, the rule-based reasoning system may be l1nked tothe object representation through an if chainge mecanrism.Each slot of an object or class can define additionalactions that are executed whenever the value of the slotchanges. The possible actions are the same as describedabove and include loading a knowledge base, executing anexternal function, etc. Like sloc values, order of sourceand if change actions can be inherited from parent classesor objects.
2.2.2 Itasca Class/Object Structure
The Itasca Class/Object structure is made up primarily ofmeteorological and geographic entities. The completestructure is given in the Appendix, but an overview andexamples will be described in this section.
In Itasca, most entities within the class/object structurehave been grouped using the geometrical descriptions ofpoint, line or region. The point can be used to represent,for example, an observing station or the center of a high orlow pressure center. A line can be used to representfeatures such as a mountain range or a meteorological front.A region can be used to represent objects with areal extentsuch as a body of water or an airmass. These threegeometric descriptions are given properties of absoluteand/or relative position. Points have the properties oflatitude, longitude and elevation as well as direction anddistance from some defined reference point. Lines are giventhe properties of orientation and direction and distance.Regions have properties of area, center latitude andlongitude, and direction and distance from a referencepoint.
In addition to their geometric description, most objectsmaintained within Itasca are characterized by either time-dependent or time-independent beha\lor. In the examplesabove, the station, the mountain range and the water bodyare time-independent while the pressure centers, fronts andairma.;ses have time-dependent behavior. Therefore, two highlevel classes have been defined called Timedepo•ndent objand Timeindependent_obj. Objects created from subclassesof Time_dependent obj inherit two slots: age and timesteD.The age slot of an object contains the value of the numberof hours that have passed since its creation. A numberrepresenting the current date and time (called a timestamp)Ls assigned to the timestep slot each hour. Attached to thetimestep slot is a list of if change actions designed toexpress or trigger the time-dependent behavior cf theobjecl .
6
A movcn goo:.: el ic ent itY i:_" aI sulbcl-ass of both theTime deo:~dcr ofI aas_ sand the appropriatte geome~tric
class. it iniherit.s pr~opiý ties fromr each ofL its pareýntclasses, a--i it may be ui~ven additional properties oL itsown. For eximple, the cls oving_line inherits theproperties oý its parent: classe-s Time dependent:_o~bj andLine, but i is also giv.,en properties characterist~ic of amoving line- :sch as direction of motion (dir of motion),speed u1arid !.he L me thati it passc-A or is expected Lo
pass thie ltorý cast:sarr reldtjve to tihe current time(t ime tr (ý A rZI va 1)
All mer-eoroloaical front clas;ses (Warm_ front, Cold_-front,Static.mra'- t1.ont- arid 0--luhdedfroi-t.) descend from the classFront tlIa 1,t a D-cl - Moving-line and inherits all ofthe p~aren- '5 propertLies. in addition, the Front class hasproperlies:s i:ch as a slopL of the frontal surface and theheightý rf th front-al i :-face above the ground. one
disint~in etwenfront. classes is the addition of th eslot iowl am containing the name of the low associatedwith wa,,m inI col(:, frontsý.
Other rreerigclentities such as pressure systems andaiimasses have analogous structures which can be found inthe Appeýndir-.
Another r-I i7 def~in-ed in Itasca is the Oh or observaitionclass. This class, has a parent class Times which hasproperties --oresenting the year, month, day, hour, minutea n se,,--_ n T.Sbclas~seS of the class Ob are surfaceobserv,ýt..n- n (Sfc_-ob) , upper-air observat ions (Upa_oh) andpibal onr~irons (PiLhal-oh) Also included but notutilized ý ,ubclasseL- for radar observations (Radar_ oh)and satelI ito_ A-bse-rvat: ions (Satellit~e ob).
Each of tseobservati.on classes h~ave appropriate slotsdefined' for "he t~ypes ofý' observations they represent. Forexample, ' le class, Sfc-oh has s3lot-s for all of the observedsurfac-e vaibe:temperat',Le, and dew point; pressure; windspeed, (iotinand gusits; up to four levels of clouds byamount:, typ- and height and whether the height was measured
or etis~ 1totl ad oague sky covers; visibilityweather, rir iarks, and a sky and ceiling description;rainfall o-- snowfall and its water equivalent; snow depth.There ar-e _,1:o some slot~s assigned to the surfaceobserva' or. -I,-i_-s whos v 'a ues3 areý computedl or determinedfrom o. ba ,e Tho *-~ iclude items such as_ the pr-essuread]just ed I i -L nqp the a irmaiss type, the dew pointdep r es. i;i h I -, 3-,nd 6-hour: pressure changes, and thepresen:- _1, 1 ons0 such as a land- or sea-breezeordrt w
The class Upa ob has slots for pressure, height.,temperature, dew point, wind speed and direction for each ofthe significant and mandatory levels. There are alsic slotsfor surface observations cf wind, temperaru!-k, dew point andpressuie, the height and pressure of the tropopause, themaximum wind, and a number of computed values su.ch as thewind snear between the gradient and 700 mb levels, the lowlevel advection, the mean temperature and dew point for thelow, middle and high level of the sounding, precioitablewater and all of 1he common stability indices computed fromthe sounding.
The class Fcst_ob is a similar to the Ob class in that iscontains slots for all of the variables for which forecastvalues are determined. In addition, it contains slots forthe time oil the forecast, the number of hours between theforecast. time and the analysis time, the names of the lastand the next fo-ecast, and whether or rot a land- or sea-breeze is forecast.
The Station class, used to define objects representingobservation stations, inherits properties frorr its parentclasses of Point, Localclimate and Local-terrain. Pointprovidtes location information, while Localclimate andLocalterrain provide local climatological and terrain data.
The -ocalclimate class has properties for the meantemperature, the mean maximum and minimum temperature themean dew noint, the mean monthly precipitation, and thediurnal temperature range. It also has properties for thenormal start and end time for possible land- or sea breezes.The u:ser is interrogated for these va±ues if the systemdeLermineb that a land- and/or sea-breeze may be possible.TLs Station class also has slots for the ICAO and the MAOstation identifiers.
The Local-terrain class has slots for local conditions thatmight alter the reliability of the observed wind. The useris questioned a; he start, of a session as to the extent ofthese influences and the slots ate filled A(ccoi(ingl',.
Even though provision for cloud observations arf- containedwithii the Ob class, Itasca also defines a Cloud class toredulce the problem caused by the observation techniques usedin cloud reportirl. Clouds are reported in tenths of skycover, and, for an overcast sky, the coverage should add upto ten tenths. To illu;-..trate the difficulty this type ofobservation causes for forecasting, assume there is a solidaltostratus cloud deck at 8000 feet and a lay jr of cumuluscovering five tenths of the sky at 40U0 ft. This woulo, bereporlied as five tentIhs cumulus and rive t, nths aitocumulus.If th• crumulus Ilaye• disappears, the next ohservation wouldbe t eu tenths altocimtiluos. Evert though t her, iz; no ,hangein physical cloudiness of the altocumulus layer, there is an
8
apparent inciease of clouds due to the nature of surfaceobservations. The Cloud class provides slots for "true"cloud amount as well as observed cloud amount. The truevalue is computed using the assumption of uniform clouddistribution. This technique also allows the retention ofhigher layer s such as cirrus when the sky becomes overcastwith lov:er clouds. The forecasting of each cloud type ismade separately. This process is internal to the system,and the pres•:ntation of forecast clouds are made as if theyhad been observed from the ground.
2.2.3 ItascI Knowledge Base Structure
The function of KBs is to contain the expert knowledgeobtained from a meteorologist with single-stationforecasting skills. KB domains are generally broken alonglines of the control blocks noted above, with the exceptionof one global KB that exists for the life of the forecastingsession. Non-global KBs will be loaded when needed andunloaded wher. they have served their purpose, permitting adynamic allocation of resources and more sharply definedtask domains. Loads and unloads of KBs are performedprimarily by actions in other KBs; a notable exception tothis is when the C control routines load (unload) KBs at thesession start (end) and the beginning (end) of the analysisand forecasting processes.
The human meteorological forecasting process that Itasca ismodelled on begins with the collection and analysis of allpertinent data and the assimilation of these data into adiagnostic model of the current synoptic situation. Thisis perhaps the most important part of the forecastingprocess because without a good understanding of the synopticstructure, the forecast is likely to be deficient. Thisdiagnostic model is used to project a consistent forecast offuture meteorological events.
There are advantages to structuring the expert system inthis two-step diagnostic-prognostic formulation. First, itfits the actual manner in which meteorologists approach theforecasting problem whether it be forecasting using onlysingle- station data or forecasting using state-of-the-artcomputer models. This makes the system more understandableto the user. Secondly, rules can be developed independentlybetween the two parts of the problem. This is importantbecause the type of rules or logic used in the two parts isinherently different. The diagnostic or interpretive partmust use knowledge in a cumulative sense. Evidence isaccumular-e as more data become available. The forecastingpart must expl citly take time into account in making theforecast.
Finally, se ý-cating the forecasting process into a model-building esd a forecast ing section allows the users to
9
include their own input at the appropriate place in theforecasting process. That is, they may modify the model,and then the forecast will be based on that best-estimatemodel.
The KBs ot Itasca are structured in this same way.Logically, the KEs can be grouped into three distinct sets.The first set has as its sole member the global knowlidgebase that contains all elements that must be accessibleduring both the diagnostic and prognostic phases of thecycle. These glibal elements include primarily the overallclass structure and the objects that have been created. Themeteorological objects, such as pressure systems and fronts,contain information about their location and movement thatis necessary to the forecasting process. There are also asmall number of rules in the global KB that are common toboth diagnostic and prognostic evaluation. Currently theserules are used to either determine the effect of cloud coveron the observed temperature change or to forecast the cloudcover effect on temperature.
The other two KB sets include objects and rules that arenecessary to either the diagnostic or the prognostic portionof the process, but not both. Both of these sets are loadedand unloaded once during the diagnostic/prognostic cycle,although in the prognostic case specific KBs may be loadedand unloaded once for each hour of the forecast. Itascarequires hourly observations, and an analysis must be madeeach hour. Forecasts are made for each of the first sixhours as well as for the ninth and twelfth hours after theanalysis time. The user is not required to initiate aforecast after each analysis.
2.2.3.1 Analysis
The first action taken by Itasca upon the user's initiationof an analysis is to determine the value of a variablecalled the representative wind (designated as slot rwnd inthe surface observation object). The representative wind isthe suirface wind direction that is representative of thelarge scale surface pressure field. During the firstanaly:is cycle, the user is queried about the possibility ofsmall scale wind flows that may be present due to localtopography. The KB that determines rwnd may request otherKBs if the station is in a geographical location where otherlocal circulations such as a land- or sea-breeze arepossible. If the system determines from the geography thatsuch a circulation is possible, the user is requested tofill Ln appropriate tinmes of occurrence.
The variable rwnd is important because it is used todetermine the location and movement of pressure systems andthe possibility of frontal passages. During the. presence ofa local circulation (a sea-breeze, for example), the value
10
of rwnd remains the same, assuming that it represents thelarger scale pressure field upon which a local circulationis superimposed. When there is no specific localcirculation, rwnd takes on the value of the wind averagedover a period of time.
The successful operation of Itasca is dependent uponreliable measurements of the wind. The representative windKB attempts to determine the validity of hour-to-hour windchanges by considering factors such as the presence ofconvective precipitation in the area, the pressure andpressure changes, the presence of fronts, the strength ofthe wind, etc. The system may not perform well, however, ifthe input wind values are subject to persistentunreliability due to observation or measurement error.
The second action taken by Itasca during the analysis is thedetermination or verification of the airmass present at thestation. This determination is made primarily with respectto current values of temperature, dew point temperature andcloud cover relative to climatological values of temperatureand moisture. The airmass type is placed in the slot amtvoein the surface observation object.
The third action taken by Itasca is to insert the timestampvalue into the slot timesteL. This is done to force alltime dependent objects to update their slot values, usingthe new hour of observations. The primary time dependentobjects include the meteorological objects: pressuresystems, fronts and airmasses.
The slots (see Appendix) are updated by applying rules whichutilize present and past observations as well as slot valuesfrom other objects. The slots that are currently active infront objects are the time the front is expected to pass thestation (time to arrival), and the front's speed, distance,orientation, direction from the station and direction ofmotion. The front's time to arrival and distance areautomatically updated each hour, but if either of thesevalues or speed is updated, they are all recomputed.
A prioritized set of rules is applied to each slot of eachobject of the given class. For example, the orientation ofa cold front may be determined or updated from the gradientlevel to 700 mb shear vector, if an appropriate sounding isavailable. Otherwise, if the front has passed, theorientation might be estimated by examining the winddirections before and after frontal passage. Or if thefront hasn't passed, the orientation might be estimated fromthe wind direction before the frontal passage.
High and low pressure systems are also updated similarly.Slots that are evaluated each hour include the time toarrival (the time of passage of the highest or lowest
11
pressure at the station), the value of the highest or lowestpressure observed at the station, the direction to pressuresystem and its direction of motion.
The only slot for the airmass objects that is evaluated eachhour is the lower level slot which accepts the value of thesurface pressure.
Objects also may be created or destroyed during the analysisphase. In Itasca, fronts are tied to low pressure systems;a warm front and up to two cold fronts may be associatedwith a low pressure center. Because single-stationforecasting allows little information to be inferred aboutan object (front or pressure system) once it is well pastthe station, most slot values are reset to Unknown and arenot evaluated further. The object and its time of passageare retained until a new object of the same type has beencreated, after which the object is deleted.
At the conclusion of each analysis cycle, Itasca updates theset of cloud objects. Each cloud object represents a cloudlayer and/or cloud type. As discussed before, the knowledgebases in Itasca depend upon true cloud amounts rather thanobserved cloud amounts. Therefore, a cloud object may ormay not be contained in the current observation. Cloudobjects that represent clouds in the observation have theirslot source set to the value "seen", while cloud objectsthat are retained but are not in the current observationhave their slot source set to "inferred". Cloud objects areretained within the system until there is reason to deletethem. Cloud objects are deleted if they should be visiblein the observation but areni't or if a curient soundingindicates a lack of sufficient moisture in the layer.
2.2.3.2 Forecast
Forecasts of the different meteorological observationscannot be made independently. For example, changes intemperature are affected by cloud cover and vice versa.Because of the dependence between variables, forecasts aremade for each hour using the prior hour's forecast as if itwere a valid observation. This stepwise procedure allowsfor some measure of concurrence between variables during theforecast period.
The forecast KBs provide forecasts for the variables in thefollowing order: wind direction, speed and gusts;temperature, dew point; pressure; clouds; weather;visibility. All of the variables are forecast using theanalysis (location and movement of pressure systems, frontsand airmasses), the last observation, the last forecast,and, if appropriate, geographical information such as thepresence of large bodies of water.
32
The wind direction, speed and gust forecasts are based onthe movement of pressure systems and the passage of fronts.In addition, wind speed and wind gusts may have a diurnalcomponent. A diurnal component in wind direction, with theexception of a possible sea-breeze circulation, is not takeninto account at this time.
Temperature forecasts are also based upon the passage offronts as well as the diurnal component, modified by cloudcover or air flow over iarge bodies of water. The diurnalcomponent is adjusted by use of an amplitude factordetermined by the amount and height of cloud cover. Dewpoint is assumed to be constant in an airmass but ismodified by advection in the vicinity of fronts.
Pressure forecasts are based upon the movement of pressuresystems and the passage of fronts.
Clouds are perhaps the most complex forecast variable. Astarting set of forecast clouds are generated by thecontrolling C-program shell of Itasca. These areessentially the cloud objects carried forward from theanalysis and include observed as well as inferred clouds.In addition, potential cloud objects are created at levelsdetermined favorable from a recent sounding. The forecastknowledge base then operates on this set of cloud objects bymodifying the slot values containing cloud height, amountand type, and/or by deleting the object at some point duringthe forecast period.
Cloud forecasts are dependent upon the type of cloud and thesynoptic environment. With the exception of diurnalconvective cumulus, clouds are forecast on the basis ofpersistence, trends and the presence of fronts. Forexample, cirrus cloud amounts observed in advance of a frontare increased over time. Middle level and low level cloudsin advance of a warm front are increased and lowered overtime. Soundings are used to determine moisture advection tomodify existing clouds or to form clouds (create additionalcloud objects) not yet observed. Convective clouds arecreated and forecast based upon the surface temperature, dewpoint and convective temperature.
Precipitation is forecast based on the synoptic environment,the presence of moisture, and the atmospheric stability.The type of precipitation (snow, rain, or freezing rain) isdetermined by surface temperature and sounding data.Precipitation is currently forecast if proper conditions aremet. No probabilistic measure is used at this time.Precipitation, therefore, is forecast more often than it isobserved.
13
Visibility is determined on the basis of type and intensityof forecast precipitation and/or the forecast of fog. Fogis forecast on the basis of dew point depression and thepresence of conditions conducive to the formation of fog(radiation, advection, and precipitation cooling).
2.3 User Interfaces
Itasca makes use of a fully mouse-driven, menued userinterface that is similar to that used by many popularsoftware programs available to the public. The system hasbeen designed with this type of interface because it isrelatively easy to learn and use, and lends itself to thehighly graphical interactive displays built into Itasca. AnItasca User's Manual has been prepared that describes thecomplete use of Itasca and its interfaces.
The interfaces are highly dynamic to assist users inoperating the system. Menu items are automatically enabledand disabled as the forecasting session passes from oneoperational phase to another or as the use of commandoptions renders them relevant or irrelevant. For example,the menu item used to initiate the production of a forecastremains disabled until an analysis has been produced.
Displays commonly referred to as dialog boxes are used bythe KBs to request the information concerning land/seabreezes and terrain effects mentioned previously.Informational messages, system advisories and warnings arepresented to the user through the use of dialog boxes.Dialog boxes are also used as editors as explained below.
Itasca was designed not as a fully automated system butrather to take advantage of user inputs and knowledge. As apart of this design, graphical tools were provided to allowthe inspection and modification of analyses and forecasts.Aside from the command screen from which the commandstructure of Itasca is controlled, Itasca interfaces may bebroadly classified as Viewers and Editors. Viewers are usedto aid the forecaster in understanding either the data orsystem products (analyses and forecasts). Editors providethe user with the capability of entering or changing bothqualitative and quantitative information. The Itasca User'sManual includes complete instruction for the use of allviewers and editors.
Itasca currently has viewers for surface and upper air datathat are capable of displaying the observations in bothgraphics and text form. The graphical display of surfacedata includes time series of temperature, dewpoint,pressure, wind (direction, speed and gusts), clouds (amountand height), weather and visibility. The upper air datadisplay is a fully interactive skew-T (or Stuve) diagram
14
that allows the user to explore one or two soundings in anumber of ways. The display also provides a variety ofvalues computed from the sounding(s), includingthermodynamic values, common stability indices, and shears.Upper air dira may also be presented in height-timediagrams.
Editors are used to enter, edit, save and deleteobservations in a straightforward way. Objects used inmaking forecasts (including airmasses, fronts, pressurecenters, and water bodies) and their slots can be edited byusing specially designed dialog boxes.
3. TESTING AND EVALUATION
At the time of this report, Itasca has not undergone formaltesting or extensive evaluation because of time constraintsand difficulties in obtaining data of sufficient quality andcompleteness. However, informal testing and evaluation isan essential and continuing process during knowledge basedevelopment. The data used for testing the system duringdevelopment consisted of approximately three weeks of hourlysurface and twice-daily upper-air data from Omaha NE andAtlantic City NJ for April 1989, and an additional month ofdata (August 1988) for Omaha. The April data were manuallyentered into the system from the original MFl-10A and MF1-10B surface weather observation forms. Much of the clouddata were reported at 3-hourly intervals and had to beconverted to hourly observations by interpreting the sky andceiling observations and making them consistent with thesynoptic cloud observations. The August data for Omaha wereobtained from the USAF Environmental Technical ApplicationsCenter (ETAC) on magnetic tape. These data were deficientin that several fields were missing, including remarks, windgusts and cloud layer data at non-synoptic times. A programwas written to interpolate cloud data, but was not entirelysuccessful because of the random errors and inconsistenciescontained in the raw data. Therefore some of the data weresubjected to manual editing. Some of the upper-air dataalso required manual editing.
Most of the testing and evaluation of the system has beendune on the analysis portion. In general, the systemgenerates a reasonable synoptic description of the currentmeteorological conditions. Pressure systems and fronts arecreated and destroyed at appropriate times and move throughthe analysis in a relatively orderly manner. Nine frontsand troughs moved through Omaha during the April timeperiod, and only a very weak trough, with virtually nopressure signature and a two hour wind change, was not foundby Itascq. Fight fronts and troughs were created atAtlantic City for the April test case and at Omaha for the
15
August test case. Again, pressure systems and fronts werecreated and destroyed at appropriate times.
The Itasca analysis is relatively sensitive to wind data.Winds that vary back and forth over fifty degrees or moreover a short period of time can cause pressure systems to berelocated, and they are not always repositioned to alocation that would seem appropriate based on the windsafter the direction has become more constant. This occursbecause, at the current time, Itasca does not maintain anhistorical record of the synoptic description or frontalpositions; therefore, changes in the position ofmeteorological features may not be accurately reversed ifthe original movement was dependent upon a short termfluctuation. This is particularly noticeable in the timingof cold frontal passages, which is closely tied to pressureand pressure variations.
It was anticipated that Itasca might not perform well withthe August test case since much of the development was doneusing springtime data. The magnitude and nature of thepressure variations are substantially different in thesummer. However, the system performed quite well using theAugust data. It created the proper number of lows andanticipated the arrival of cold fronts within about 6 hourson several occasions. Some fronts did pass the station whenthey hadn't been anticipated within the twelve hour forecastperiod.
In general, Itasca appears to create an appropriate synopticdescription. There have been instances where the system hasgenerated an unrealistic synoptic environment (e.g. threelows and no highs), although most of these problems havebeen corrected. If this does happen, the system must berestarted. The time chosen to start the system also willimpact the analysis generated by the system. Best resultsare obtained if the system is started with data taken froman uncomplicated synoptic environment; just as a forecasterwill have difficulty discerning the synoptic situation ifwinds are light and variable and pressure changes areslight, so will Itasca. If the system does not startproperly and doesn't correct itself within several hours, itshould be restarted from an earlier time.
The forecasting portion of the system has been subjected toless testing and evaluation, but, in general, the forecastsappear to be reasonable reflection of the synopticdescription. This is particularly true for temperature, dewpoint temperature, wind direction and speed. Clouds aredifficult to forecast on the basis of single-stationobservations, but the system shows some capability in thisarea. Precipitation and visibility are probably the mostdeficient forecast parameters at this time, but there isreason to believe that performance can be improved.
16
Precipitation is currently forecast to occur much morefrequently than it really does because it is based upon thesynoptic environment and limited data. Future developmentshould concentrate upon determining the knowledge requiredto generate a probability assessment and a presentationformat that can communicate the information to the user.
With the limited data available for testing and the timeconstraint of the work, there are portions of the system(rules) that have not been exhaustively tested. As data aremade available and testing continues, these problems willbecome evident and corrections will be made.
4. CONCLUSIONS AND RECOMMENDATIONS
The problem of forecasting the weather during periods whennormal data and numerical forecast products are unavailableis one which must be considered in contingency planning.The classic single-station forecasting methodology providesa basis for operations under this scenario as well as othersituations where detailed local short-range forecasts arerequired.
This report describes a project whose objective was to usesingle-station concepts and develop a knowledge-based systemto make short-range station forecasts of the observedmeteorological variables assuming availability of no dataother than that collected at the station.
The result of this project is a system that:
"* uses embedded KBs (providing analysis and forecastingcapabilities) inside a traditional control structure
"* provides for interaction with the user
"* provides database management
"* provides computational and procedural support
The modular nature of the design makes the system versatileand easy to operate. Training time necessary to learn howto operate the system should be minimal. The system as itcurrently exists is considered an advanced prototype.
Recommendations for the system and future developmentinclude:
Testing and Evaluation: Because of problems in acquiringsatisfactory detailed surface observations on mediaconducive for transferring large quantities of data, thesystem ha:, iiad only rudimentary testing. However, thedevelopmentc is at a point where substantial testing is
17
possible and necessary. The availability of complete,quality controlled data sets for evaluation is still aproblem. Particularly limiting are cloud data of sufficientdescription. The data used for testing to Oate were hand-entered from standard MFl-10A and 10B forms. However,complete transcriptions of these data are not available onelectronic media. It is recommended that datasets ofdetailed hourly surface observations be developed fortesting systems developed for short range weatherforecasting. Portions of these datasets could bedistributed to developers and portions could be maintainedas standard independent test sets.
Further evaluation and testing should concentrate ondetermining environments for which the system does notperform adequately. It is recommended that testing beginwith more extensive evaluation for stations located in theMidwestern United States. Evaluation should be made forboth the diagnostic as well as the prognostic components ofthe system. As performance for these stations is evaluated,other stations should be added to the testing data set andresults compared to the earlier stations.
It is recommended that standards be developed for verifyingthe system forecasts. Itasca is a limited data forecastsystem, and it should be tested against comparable forecastprocesses such as persistence, climatology, or limited datastatistical models. Comparison of results with humanforecasters can only be made if data availability is thesame. Documentation of the results of such testing can beused to improve the system performance.
An inherent limitation of Itasca is that it is designed suchthat a minimum amount of information is required of theuser. If the system cannot determine the answer to aquestion, it assumes that there is no known answer andproceeds accordingly. It does not, in general, prompt theuser for an answer. This is in accordance with the scenarioof little available data and no experienced forecasteroperating the system. However, answers to such questions as"Is the sky brightening?" are important to the short rangeweather forecast but are -ot often included in observationremarks. The system tries to overcome this limitation byallowing the user to modify the analysis on the basis ofhis/her knowledge, but the modification must be initiated bythe user.
Databases: At the present time, there are only limiteddatabases available to the system. The meteorologicaldatabase currently contains average monthly maximum andminimum temperature from the World WeatherDisc , averagediurnal wind speed variation and average diurnal pressurechange which has been given a latitudinal variation. There
18
are a number of additional databases that would be useful.For example, databases of airmass source regions, averageairmass characteristics as a function of latitude andlongitude, storm tracks as a function of month or season andupper-air climatology would all be very useful.
The geographic database currently consists of map strings(latitude-longitude pairs) from which land and water bodiescan be determined. However, there is no information onwater body surface temperature which is very important inforecasting temperature, moisture, clouds and fog forstations in the vicinity of these water bodies. Thegeographic database also contains a topographic grid thatcontains terrain elevation and roughness parameters on ascale of 6 minutes, although these data are not used in anysubstantial way in the system.
Even if these data were easily available, the problem ofdetermining how to efficiently and usefully represent thistype of information within the system has not been solved.The disparity between the human ability to synthesize visualfeatures and patterns and the ability to simulate thisprocess on the computer is real, significant and important,and more work is necessary.
System Desian: The most significant deficiency in thecurrent design is that the system maintains no history ofhow things have evolved. The objects are created anddestroyed as necessary, and they maintain information (slotvalues) about themselves. However, they know nothing aboutthe sequence of how they all came to be. If those data arechanged because of an unexpected change in the observations,which at the next hour is nullified, the system has no wayof recovering well. This places a large dependency onaccurate, representative observations. For example, asudden large drop of pressure may mean that a frontalpassage is imminent and the time to cold front passage maybe reduced to 1 or 2 hours. If the next hour pressurechange is small, or possibly even a rise, the system mightbe better off with the original value which had beenreplaced, and therefore lost. The objects within the systemshould retain a history of their attributes.
19
REFERENCES
1. Swetnam, G. E. and E. J. Dombroski, 1985: ADemonstration Expert System for Weather Forecasting.Preprints: 2nd International Conference onInteractive Information and Processing Systems forMeteorology, Oceanography and Hydrology, Boston,Amer. Meteor. Soc., 310-316.
2. Zubrick, S. M. and C. E. Riese, 1985: An Expert Systemto Aid in Severe Thunderstorm Forecasting.Preprints: 14th Conference on Severe Local Storms,Boston, Amer. Meteor. Soc., 117-122.
3. Elio, R., J. de Haan and G. S. Strong, 1987: METEOR:An Artificial Intelligence System for ConvectiveStorm Forecasting. .6 Atmos. Qcean. Tech., 4, 29-35.
4. McArthur, R. C., J. R. Davis and D. Reynolds, 1987:Scenario-Driven Automatic Pattern Recognition inNowcasting. JL, tmos. Ocean. Tech., 4, 19-28.
5. Campbell, D., 1986: Microburst Recognition: An ExpertSystem. Preprints: 23rd Conference on RadarMeteorology, Boston, Amer. Meteor. Soc., 26-29.
6. Olson, S. H., 1986: Overview of an ArtificialIntelligence System for Gust Front Recognition andTracking. Preprints: 23rd Conference on RadarMeteorology, Boston, Amer. Meteor. Soc., 22-24.
7. Campbell, S. D. and S. H. Olson, 1987: Recognizing Low-Altitude Wind Shear Hazards from Doppler WeatherRadar: An Artificial Intelligence Approach. J.Atmos. Ocean, Tech., 4, 5-18.
8. Stunder, M. J., R. C. Koch, R. N. Sletten and S. M.Lee, 1987: ZEUS: A Knowledge-Based Expert System thatAssists in Predicting Visibility at Airbases. AFGL-TR-87-0019, Air Force Geophysics Laboratory, HanscomAir Force Base, MA. (ADA184197)
9. Dyer, R. M. and G. L. Freeman, 1989: Rule-Based Systemsfor Visibility Forecasts. GL-TR-89-0116, GeophysicsLaboratory, Hanscom Air Force Base, MA. (ADA214622)
10. Moninger, W. R., J. Eullas, B. de Lorenzis, E. Ellison,J. Flueck, J. C. McLeod, C. Lusk, P. D. Lampru, R. S.Phillips, W. F. Roberts, R. Shaw, T. R. Stewart, J.Weaver, K. C. Young and S. M. Zubrick, 1991:Shootout-89, A Comparative Evaluation of Knowledge-based Systems That Forecast Severe Weather. Bull.Amer. Meteor. Soc., 72, 1339-1354.
20
11. Oliver, V. J. and M. B. Oliver, 1945: Weather Analysisfrom Single-Stat non Data, Handbook of Meteorologv, F.A. Be:pry, E. Bollay and N. R. Beers, eds., New York,McGraw Hill, 858, 879.
12. World WeatherDisc, WeatherDisc Associates, Inc., 4584NE 897h, Seattle, WA 98115.
21
APPENDIX
Itasca Class/Object Structure
Key:
Classproperties dc'finod by class
Subclass (inherits slots from Class)properties defined by subclass
Most classes inherit from two main classes:Time-dependent-obj and Time-independent-obj
Other classes that do not inherit from these two main classes are:CloudCloudlayerTimesLocal climateLocal-terrainLinePointRegionWavephenomena
22
Tim. dependent ob jagetimestepMoving line (also inherits from Line; see below)
diz of motionspeedtime_ to-arrival
Frontheightslope
Warm-frontlowi-name
Cold-front
1 owl-nameStatijonary-frontoccluded-front
Moving_wavePressure-wave
slope
Pressure_ridgePressure-trof
Moving~point (also inherits from Point; see below)dir-of-motionspeedtime-to-arrival
Local-climatedTrange meant emplandý_breezeý_end mean 2m axland breeze-pcs.,ible mean Trinland-bre.:e~s tart sea-breeze-endmeandewp sea_breeze~possiblemeanprec sea_breeze-start
Atation. (also inherits from Point; see below)icao1 ocnwmnon
Local-terrainno-terrain-influence bad wd2_2number-bad-wdirs drainage-flow possbad-wdl_1 drain-flow dirbadwd1_2 drain-flow wsbad-wd2_1
Station (also inherits from Point; see below)
i cao1 ocnwinon
Linedirectiondistance
orientationNoving~line
(see above, under Time-dependent-obj)
pointdirection latidistance Ingiel ev
Moving-point(see above, under Time--dependent-obj)
