Scenario Configuration:

The Scenario Configuration option provides two options. The first, Timing and Controls, permits the specification of scenario timing and control; the second, Ground Fighting Parameters,  supports specification of generic ground combat factors. The timing options will permit the user to select the date and time in which the scenario is set, how fast the simulation should run both in reference to actual time and update intervals, and scenario aggregation information. Selection of the Timing and Controls option brings up the Editing Scenario Configuration Form . This form is used to :

The second Scenario Configuration option (Ground Fighting Parameters ). provides an interface to tailor the Ground Engagement Parameters for the scenario. These parameters support specification of generic ground combat factors. These factors address the direct-contact ground engagement algorithm and include the update rate for determining losses, the proximity between units before they automatically engagement, the basic kill rates of the Lanchester equations used for ground combat in the FORCES model, and so on. Selection brings up four Rules and PK Tables: Ground-Ground Engagement Rules; Defender PK Table; Attacker PK Table and Advance/Retreat Table . While the parameters are described below, it's useful to understand the algorithm; Click here for more information on the underlying algorithm.

Selection of the Ground - Ground Engagement Rules bar brings up the Ground Engagement Rules Form that presents a list of the Scenario Record to Edit.When a scenario is selected (e.g. Ft. Hood) a larger Ground Engagement Rules Form appears. On this form are six elements that the user can enter data:

The Attacker PK and Defender PK Tables are used to define "typical" losses that should be used for the attackers and defenders in this scenario. As covered in the algorithm description , these losses are based upon an unprotected, unarmored truck and are modified according to terrain, environmental factors, armor, posture and so forth by additional computations external to these tables. The firepower is an independent input to this table and it's calculation is also addressed in the algorithm description.

When the Defender PK Table bar is selected the Table Description Form appears.  The edit interface is the standard multidimensional table editing form; the generic procedures for editing this information is described here.  Particular information that will help the user in populating this table is the parameter definitions.  These are:

Computed Variable: Losses per update.

Independent Var. Values

Attacker Adjusted Gun Co

This is the firepower of the attacker.  During the scenario execution it is calculated as the simple rollup of the firepower for each attacker based on the database prototype definition of the armament subsystems onboard each attacker as adjusted by range, weather, etc.  An Edit button brings up the Independent Variables Form on which the user can Editing Values for: Defender PK baseline, Independent Variable: Attacker Adjusted Gun Co. AnAdd New Value bar allows the user to add a new value via the New Ind. Value Form .

# Defenders

This is a simple count of the defenders in an engagement. During presimulation the analyst creates this table for a range of possibilities.  During scenario execution the module computes the actual # of defenders in an area based on the situation.  An Edit button brings up the Independent Variables Form on which the user can Editing Values for: Defender PK baseline, Independent Variable: # Defenders.

An Add New Value bar allows the user to add a new value via the New Ind. Value Form .

Selection of the Attacker PK Table causes a very similar Table Description Form to appear, the only differences being that it's independent variable is the adjusted defender gun count and the result is the expected "typical" attacker losses. Naturally, the input variables and results can differ as desired between the attacker and defender PK tables.

Finally, note that these PK tables are optional. If not filled in the simulation will used default values.

Road Network Specification

This interface permits the user to define whether a road network will be used, and if so, which database contains the road network data.  To use this data a road network must be loaded.  The format of this database is as shown here.  There are routines for automatically loading the TIGER road database into a database compatible with the JFORCES representation.  Information on loading TIGER data into the JFORCES database is available here.

Engineering Barriers

This option permits the user to specify the effectiveness and time for deployment & removal for selected engineering barriers (e.g. Minefields, tank barriers, temporary bridges, etc). Selection of the Define Engineering Barriers causes the Engineering Barriers Form to appear with the option to choose the Scenario Record to Edit .  The minefield representation currently used in JFORCES is a very simple representation that only addresses the region covered, the time to remove or emplace the minefield, and it's lethality.  Better models are available upon request.

Selection of a scenario causes a Minefields Form to appear. The form lists the name of the scenario along with several fields that the user can edit:
A list of all pre-scripted minefields in the scenario is also presented on this form with the following data for each one: 1) Id, 2) start time, 3) extent (northern, eastern, southern and western limits).  When a minefield is selected the Minefield Coverage Form appears with the above data on it that can be modified by the user.  Coverage can also be changed using the Pick from Map option.  A new minefield can be added by selecting the Add New Minefield bar that brings up a blank Minefield Coverage Form

Data Collection

This is the master control form for specifying whether data is to be kept for scenario runs and, it so, what data will be saved for analysis. If you don't fill in this form you won't save data for analysis. Choosing this item causes the Define Data Collection Specs Form to appear.  Data specifications may be defined on the Define Data Collection Specifications window.  Six factors must be identified/defined by the user:

Collect Data - On/Off button. If this is left off (the default) you won't collect data for the run.

Sampling Frequency - sliding scale 1-100. This is actually not a very important entry. This only affects how often data is collected for sensor detections when a sensor is detecting a target. Data on all key events, including sensor detection change status (including all changes from detected to non-detected or vice-versa and all changes in reasons for non-detection) are collected regardless of this setting. The only reason this option is presented is to fill in the sensor/target detection geometry over long detection periods for the " Detection Profile " option of Data Analysis. If you're not intending to use this interface for data analysis it's recommended that you set this value to a large number (e.g. 100). Otherwise you'll use up an extraordinary amount of disk space and slow down the processing of data significantly.

Collection File - Directs user to another form where the user can choose where to save the data for the run. In order to increase run speed and execution versatility the data for runs is saved in a flat file and loaded into the database only when commanded to. The means to do this are described here . But to load this data you must know where the data is stored. This specifies the file.

Message Set - allows user to select the desired message set from a list in the drop-down inset. The user can choose to limit the messages being saved to minimize disk space and improve data analysis performance at the expense of limited information. Very reasonable when you know that you're not going to evaluate data of a specific type. Generally the most demanding messages (those you might want to consider not saving) are: da_snsrdetect (sensor detections), da_bombdropevt (bomb drops), and da_sat_err_detect (satellite detection error analysis data). Also, not that the message set "allmsgson" is a reserved message set - data will be saved for all messages regardless of database settings when this set is selected.

Tailor Data Collection by Class? - Yes/No button. When this is set to Yes the next button will allow the user to specify the class collection set; when set to No the next button will allow the user to select the object collection set.

Object Set ( or Class Set when the button above is set to Yes) - allows user to select the desired object (or class) set from a list in the drop-down inset. The purpose to this interface is to specify the collection of data only on specified assets. Class collection will collect data for all assets of a type; the object select permits greater resolution in the assets you wish to collect data on. Note that the option "allclasseson" is a reserved collection set; when this option is selected data will be collected on all scenario assets regardless of any defined settings in this widget. Currently most users always use this option; it seems that this filtering option is a relic of earlier installations when disk space was always at a premium. Now that it's not many users prefer to collect data on all assets just so they can explore the resultant dataset more freely.

On the lower portion of the form are four bars:

Edit/Create Message Sets

As mentioned above, filters can be applied to the messages recorded during runtime to limit disk usage.  Be aware the the disk utilization must be balanced against lost data; after the scenario starts execution if a message was not selected for collection it can not later be redeemed.  

When this option is selected the Create/Edit Message Sets Form   appears.  A list of Current Message Sets is presented each of which may be Reviewed, Edited, or Deleted. Note that the first many messages are written in a subdued color - this implies that the user can not choose to not select them. These are definitional messages and without these many of the data analysis reports would be unable to function correctly. Messages later in the list can be select for collection as the user wishes, though naturally this will affect the report options. For example, if DA_SNSRDETECT (sensor detections) is not selected no reports can be run to determine detection success.

The Create New Message Set bar allows the user to do that. When selected the Edit Message Set Form appears.

Edit/Create Class Collection Sets

Again, as mentioned above, filters based on the class of asset performing an operation can be applied to the messages recorded during runtime to limit disk usage.  Be aware the the disk utilization must be balanced against lost data; after the scenario starts execution if data on a specific class of asset was not selected for collection it can not later be redeemed.  

When this option is selected the Create/Edit Class Collection Sets Form appears.  A list of Current Class Collection Sets is presented each of which may be Reviewed, Edited, or Deleted.

The Create New Class Collection Set bar allows the user to do that on the Edit Class Data Collection Sets Form that appears.  The Names of the classes are listed - each with an Off/On button.  On the Class Collection Set line the name of the collection set is typed.

Edit/Create Object Collection Sets

Again, as mentioned above, filters based specific assets performing an operation can be applied to the messages recorded during runtime to limit disk usage.  Be aware the the disk utilization must be balanced against lost data; after the scenario starts execution if data on a specific asset was not selected for collection it can not later be redeemed.  

When this option is selected the Create/Edit Object Collection Sets Form appears. A list of Current Object Collection Sets is presented each of which may be Reviewed, Edited, or Deleted.

The Create New Object Collection Set bar allows the user to do that on the Edit Object Data Collection Sets Form that appears.  The Names of the objects are listed - each with an Off/On button. On the Object Collection Set

Specify Assets for Detailed Detection Monitoring

This permits the user to specify the assets for which detailed detection monitoring is maintained during runtime.  Only assets on this list (or subsequently specified during the execution) will be shown on the umpire's "Detailed Detection Monitor" (click here for more info) or the runtime "Detailed Sensor Detection" displays (click here for mode info).  This interface lists the assets already identified for detailed sensor monitoring and the option to change the entries to this list.  Selecting the "Add" button will result in being presented a list of platform types currently in the scenario.  Picking one of these platform types will bring up a list of all assets of that type in the scenario from which the uer can select one or more for monitoring and then save his selections.  Double-clicking on any asset in the list will permit the user to delete the asset from the monitoring list or change the "intent" description.  The "intent" description is free-format and has no effect on the scenario execution; this field just provides reference information displayed on the the umpire's "Detailed Detection Monitor".