General Notes

This section provides ten general notes covering input file formatting requirements, key coding conventions, and operational guidance for running ADS-IDAC. All analysts should read these notes before preparing or reviewing input files.

---

Note 1: Input File Format

ADS-IDAC requires the user to provide an extensive amount of information related to reactor plant systems, operator knowledge and skills, and crew preferences and tendencies. This information is supplied through a collection of input text files. Section 4, "Input File Format," provides a detailed discussion of each required input file including its purpose, file format, input options, and a sample.

The following conventions are used throughout the input file descriptions in Section 4:

Variable Types

Input data can be one of three data types:

Type	Description	Examples
double	Real-valued numbers	3.14, 0.001, -1.5e-3
integer	Integer numbers	1, 0, -12
string	Word comprised of character elements	Reactor_Trip, EOP_E0

Notation in This Manual

Notation	Meaning
Bold italics	An input variable that must be provided by the analyst
"quoted name"	An input file name (e.g., "ControlPanel.txt")
[bracketed item]	A conditional input — only required when the associated option has been selected
. (three dot lines)	Indicates multiple data entries of the same type are permitted; only a representative sample is shown

One Datum Per Line

ADS-IDAC input files are line-oriented. Each input datum must be entered on its own line. Inline comments are not supported. Do not place data and explanatory text on the same line.

---

Note 2: Input Strings

When string variables are entered in ADS-IDAC input text files, they must be entered without spaces. The underscore character (_) may be used to separate words where needed.

Reactor_Trip
EOP_E0_Step_3
SGTR_Diagnosis

This convention prevents a multi-word string from being misinterpreted as two separate input quantities.

Exception: Quoted Strings

The no-spaces rule does not apply when the string is enclosed in quotation marks. The detailed file format descriptions in Section 4 identify where quoted strings are permitted for each input file.

Because ADS-IDAC parses input files based on whitespace delimiters, a two-word string such as Reactor Trip would be read as two distinct entries — Reactor and Trip — potentially causing an input processing error or incorrect behavior.

Case Sensitivity

String variables in ADS-IDAC are case-sensitive. The string Reactor_Trip is not the same as reactor_trip or REACTOR_TRIP. All cross-references between input files (for example, a control name used in a procedure step file that must match the name defined in ControlPanel.txt) must use identical capitalization.

---

Note 3: Integer Term-Conversion Codes

To make the ADS-IDAC source code more readable while maintaining computational efficiency, a catalog of integer codes has been developed. These codes cover commonly used integer variable values. For example, the integer variable that stores the current operator problem-solving strategy is assigned a unique code for each possible strategy.

All coded variable names begin with the letter V. The remainder of the name is a descriptive noun or acronym representing the quantity (e.g., VSFP for "Follow Written Procedure").

Example: Problem-Solving Strategy Codes

Strategy	Variable Name	Integer Value
Wait and Monitor	VSWM	3054
Follow Instruction	VSFI	3062
Knowledge-Based Reasoning	VSIDR	3058
Follow Written Procedure	VSFP	3059

INFO

The Knowledge-Based Reasoning strategy is also known as "Inductive/Deductive Reasoning", which is where the names VSIDR and sim::Strategy::InductiveDeductive come from.

The complete range of integer term conversion codes used in ADS-IDAC is approximately 3000–3165. A complete listing is provided in Section 5, "Term Conversions."

Enter Integer Values, Not Variable Names

Several input files require the user to enter the integer value for a quantity rather than the descriptive variable name. For example, enter 3059 rather than VSFP. The input file descriptions in Section 4 explicitly identify which fields require integer code values and list the allowable values.

The integer values are defined in the C++ header src/ADSIDAC/Global/SimConstants.h. The V... names are those of the 2009 manual; the Term Conversions page lists them next to the names used in the code.

---

Note 4: Procedure Naming Conventions

ADS-IDAC uses two main types of procedures:

Type	Description
Written procedures	Formal proceduralized guidance contained in normal, abnormal, and emergency operating procedures
Memorized mental procedures	Skill- and rule-based actions routinely used by operators that do not require formal procedure guidance

All ADS-IDAC procedure input files use the prefix ZProcedure_. Mental procedures are distinguished from written procedures by the sub-prefix ZProcedure_MPBG_ (where MPBG stands for "Mental Procedure – Belief Generated"). Mental procedures are generally initiated by the activation of a mental belief defined in KB_OAT(ODM)_HardWired_Diagnosis.txt.

Procedure Transfers

A written procedure normally continues until completed. However, procedure flow may be interrupted by:

• a procedure transfer (directing the crew to a different procedure),
• activation of a mental belief that initiates a memorized mental procedure, or
• abandonment of the "Follow Written Procedure" strategy.

Two types of procedure transfers are modeled:

Transfer Type	Behavior	Example
Permanent transfer	Original procedure is terminated and will not be reactivated	Transfer from E-0 to E-3 during a steam generator tube rupture
Temporary transfer	Original procedure is suspended and will resume at the interrupted step when the new procedure completes	Crew temporarily follows a functional recovery guideline (FRG) to address a degraded condition

ADS-IDAC executes a temporary transfer when the new procedure is either a mental procedure or carries the prefix ZProcedure_FRG_.

Procedure Permissions by Crew Role

Role	May Initiate Mental Procedures	May Initiate Written Procedures
Action Taker (OAT)	Yes	No
Decision Maker (ODM)	Yes	Yes

Only the Decision Maker is permitted to direct the performance of a written procedure. The Action Taker may initiate and transition between mental procedures but may not initiate or transition to a written procedure.

---

Note 5: Operator Control Inputs

ADS-IDAC provides four possible control input modes for each component that can be operated by the control room crew:

Mode	Description	Example
1. Operating mode change	Change the component between automatic and manual mode	Switching a pump from auto to manual control
2. Specific control value	Set a specific value for a component	Throttling a control valve to 50% open
3. Incremental control	Increment the current control setting by a specified amount	Throttling a control valve open by an additional 10%
4. Parameter-based control	Set a control value based on a perceived plant parameter	Setting the steam dump target pressure equal to the perceived main steam header pressure

These four modes provide sufficient flexibility to realistically model all significant operator interactions with the plant model. Control variables are given the prefix X_ by convention (consistent with PRA practice). The detailed implementation of each control input is described in Section 4 of this manual.

---

Note 6: Input File Consistency

Many ADS-IDAC input files contain cross-references to items defined in other input files. For example, a procedure step file may reference a control defined in ControlPanel.txt. Inconsistencies between cross-referenced files will cause errors during input processing or program execution.

Review Consistency Before Running

Prior to running ADS-IDAC, all input files should be reviewed to verify the consistency of data cross-references. Although ADS-IDAC contains many input data checking features, the user should not rely solely on program checks to ensure input validity.

The following checklists identify the key cross-reference relationships that must be verified.

Control Panel Information

• Indicators, controls, and alarms in ControlPanel.txt must reference valid names (control_volume_names, control_junction_names, variable_trip_names, logical_trip_names, interactive_control_names, and control_variable_names) defined in RELAP5_channels.txt.
• References to plant controls (valves, pumps, actuators) in the following files must match a valid control_name in ControlPanel.txt:
  • ZProcedure_procedure_name_step_name.txt
  • ProcedureControlValueBranches.txt
  • ProcedureActionTimeBranches.txt
  • SystemReliability.txt
  • KB_OAT(ODM)_Diagnosis_Actions.txt
  • KB_OAT(ODM)_System_Decomposition
  • Initiating_Event.txt
• References to plant parameters, component states, and alarms in the following files must match a valid parameter_name, component_name, or alarm_name in ControlPanel.txt:
  • ZProcedure_procedure_name_step_name.txt
  • ProcedureActionTimeBranches.txt
  • SystemReliability.txt
  • KB_OAT(ODM)_Diagnosis_Actions.txt
  • KB_OAT(ODM)_System_Decomposition
  • KB_OAT(ODM)_HardWired_Diagnosis.txt
  • KB_OAT(ODM)_Bias_Factors.txt
  • KB_OAT(ODM)_Scanned_Parameters.txt
  • KB_OAT(ODM)_Time_Constrained_Input.txt
  • KB_OAT(ODM)_Safety_Parameters.txt

Operator Knowledge Base

• Key plant functions in KB_OAT(ODM)_System_Decomposition must be included in the event diagnosis matrix KB_OAT(ODM)_Event_Matrix.txt.
• Each symptom referenced in KB_OAT(ODM)_Event_Matrix.txt must be associated with a mental belief in KB_OAT(ODM)_HardWired_Diagnosis.txt.
• Any mental belief used as a prerequisite condition for another mental belief must be included in KB_OAT(ODM)_HardWired_Diagnosis.txt.

Procedures

• All procedure steps listed in Procedures.txt must be associated with a unique procedure step input file (ZProcedure_procedure_name_step_name.txt).
• Procedure names referenced in mental beliefs (KB_OAT(ODM)_HardWired_Diagnosis.txt) must refer to a valid procedure name.
• The following branching files must reference valid procedure names:
  • ProcedureControlValueBranches.txt
  • ProcedureActionTimeBranches.txt
• Mental procedure branching options in MentalProcedureActivationTimeBranches.txt must reference a valid mental belief in KB_OAT(ODM)_HardWired_Diagnosis.txt.

---

Note 7: Branch Generation

Some procedure actions require the operator to interact with the reactor plant or coordinate with other crew members — for example, checking equipment status, manipulating a control, or verifying a parameter value. These tasks require time to complete, and further operator decision-making is suspended until the task is finished.

Within ADS-IDAC, each such task is represented as a branch event — a discrete event or information chunk created during a simulation sequence. Most branches do not cause multiple accident sequences to be generated. However, when two or more branches of the same type are generated within a single time step, ADS-IDAC splits the current sequence path into two or more separate paths. This constitutes a DDET branching event.

ADS-IDAC supports the following five categories of branching:

Branch Type	Description
Timing branches	Procedure action execution times and mental procedure activation times are represented by three-parameter Weibull distributions. Branches are generated by sampling over different partitions of the distribution.
Control value branches	For procedure step actions involving a quantitative control input, two or more branches can be generated to explore the effect of variations in the control setting.
Mental belief branches	When prerequisite conditions for a mental belief are met, two branches are generated: one where the belief is activated and the associated mental procedure is executed, and one where the belief remains inactive.
Hardware failure branches	Component demand failures generate success and failure branches. If the operator attempts to restart failed equipment, recovery and permanent failure sub-branches are also generated, yielding up to three outcomes per equipment event.
Step-skip branches	When step skipping is enabled, two branches are generated for each procedure action: one where the action is performed and one where it is omitted.

By appropriately combining these branching rules, a wide spectrum of possible plant and operator states can be simulated.

---

Note 8: Branching Rules

Branching rules control how DDET branching events are generated during a simulation. They can reflect variations in both plant hardware behavior and crew responses.

The full set of branching attributes available in ADS-IDAC is:

Branching Attribute	Outcomes Generated
Use of memorized information	(1) Operator uses previously perceived (memorized) information; (2) Operator always obtains current information from the control panel
Troubleshooting probability	(1) Operator attempts knowledge-based actions; (2) Operator immediately implements emergency operating procedures
Procedure use probability	Switches operator from knowledge-based strategy to procedure-following strategy
Mental belief branch probability	(1) Mental belief activated, memorized, and used to execute associated mental procedure; (2) Mental belief remains inactive
Mental procedure activation time	Two or more branches representing different partitions of the Weibull activation time distribution
Equipment failure and recovery	(1) Equipment does not fail; (2) Equipment fails but is later recovered; (3) Equipment fails and is unrecoverable
Procedure step skipping	(1) Step action is performed; (2) Step action is omitted
Action control value	Two or more branches representing different quantitative control input values
Action time	Two or more branches representing different partitions of the Weibull action time distribution

Probability Requirements

Branch Probabilities Must Sum to 1.0

For any given branching point, the probabilities assigned to all branches must sum to exactly 1.0. Failure to satisfy this constraint will result in an error during input processing.

Weibull Partition Method

Timing-based branches (mental procedure activation time and action time) use a three-parameter Weibull probability distribution. The distribution is partitioned into intervals, and each branch represents a sample drawn from a different partition. The probability assigned to each branch equals the probability mass within the corresponding partition interval. This method ensures that the full probability space is covered while limiting the number of sequences that must be simulated.

---

Note 9: Terminating Sequences

To achieve complete scenario coverage in a DDET, a large number of accident sequences must be explored. Because simulating every sequence to completion can be computationally prohibitive, ADS-IDAC provides several methods to terminate or truncate sequences. Truncation can be based on elapsed simulation time, sequence probability, or conditional plant events.

The following termination methods are available:

Method	Trigger	Configuration
Sequence truncation time	Sequence simulation time exceeds the specified maximum	Set in ZCtrlPar.txt
Sequence probability cutoff	Sequence probability falls below the specified cutoff value	Set in ZCtrlPar.txt
Procedure non-response exit (VSTOP)	Operator determines that procedure step expectations are not met	Specify VSTOP as the non_response_action type in the relevant ZProcedure_procedure_name_step_name.txt file
Alarm activation (A_ENDSEQ_)	An alarm with the prefix A_ENDSEQ_ is actuated	Define the alarm name and actuation conditions in ControlPanel.txt

RELAP Time Limit Coordination

When using the sequence truncation time option, the RELAP5 time control cards (Card2, lines 200–299) must set a maximum simulation time equal to or greater than the sequence truncation time specified in ZCtrlPar.txt. If the RELAP5 time limit is shorter, RELAP5 will terminate the sequence prematurely.

---

Note 10: Running ADS-IDAC

Starting a run

ADS-IDAC is started from the command line. The project directory (which holds Input/) and the RELAP5 input deck are given with --project-dir and --input-deck, or in an options file named ZiniADS.txt in the current directory (one name=value line per option). The RELAP5 steam table files must be in the directory the run is started from. See Running a simulation.

Units

ADS-IDAC supports both SI and British units. The unit system is set in the source code; there is no provision to change units from the input files. To toggle between unit systems, change the following line in Scheduler::initiationForSimulation() (src/ADSIDAC/Scheduler/Scheduler.cpp) and rebuild:

r5pars_.si_unit = false;

Value	Unit System	Examples
false	British units	psi, °F, lbm/sec
true	SI units	Pa, K, kg/sec

Time Steps

Two time steps are relevant to ADS-IDAC operation:

Time Step	Description	Configuration
RELAP5 time step	Controls the thermalhydraulic simulation integration interval	Set by lines 200–299 in the RELAP5 input deck
ADS-IDAC time step	Controls the cognitive model and scheduler update interval; it is 0.5 seconds	Set in the source code (below)

To change the ADS-IDAC time step from 0.5 seconds, two source files must be modified consistently:

1. In the Fortran routine src/Relap/relap/dtstep.f:

if((timehy - timesno) .ge. ADS-IDAC_time_step) then

2. In src/ADSIDAC/Scheduler/CommandControlCenter.cpp:

this->reduceRemainingTime(ADS-IDAC_time_step)

Synchronize Both Time Step Settings

Both dtstep.f and CommandControlCenter.cpp must be set to the same value to keep the ADS-IDAC scheduler synchronized with the RELAP5 thermal hydraulic model. Setting them to different values will cause inconsistent behavior.

Additionally, the maximum RELAP5 simulation time should be set to a value greater than the truncation time specified in ZCtrlPar.txt to prevent RELAP5 from terminating sequences early.

Error Log File

ADS-IDAC appends to an error log file when an error or warning is encountered during a simulation run. After each run, check whether the file err messages.txt exists. A serial run writes it in the directory the run was started from. In an MPI run every rank writes its own file in rank_N/; the default merge (--merge=now) and --merge-only collect them in Output/ES/err messages.txt. Some errors will cause termination of the simulation; others are less severe and alert the user to an unexpected condition without stopping execution.

Post-Run Checklist

After every simulation run:

1. Check for the presence of err messages.txt.
2. Review all entries in the error log, even if the simulation completed normally: non-fatal warnings may indicate input data issues that affect result validity.
3. Independently verify the results.