Output Files

ADS-IDAC writes three categories of output into the project's Output/ directory. All files are plain text.

Directory Layout

Output/
  ES/
    ESFolder_0/
      ZESNode_1.txt          # End state of sequence 1
      ZESNode_2.txt
      ...
    ES_summary.txt           # One line per sequence
    Scenario info.txt        # Event highlights per sequence
    Procedure data.txt       # Procedure step and step-skipping record
    Scan data.txt            # Operator scan queue history
    err messages.txt         # MPI runs: the ranks' error logs, concatenated
  KPS/
    KPSFolder_0/
      ZKPS_1.txt             # Key parameter time history of sequence 1
      ZDIA_1.txt             # Diagnosis confidence history of sequence 1
      ZPIF_1.txt             # Performance influence factors of sequence 1
      ...
  PE/
    PEFolder_0/
      ZPENode_0.txt          # Pivotal event node 0
      ZPENode_1.txt
      ...

Folder numbering

End-state and history files are bucketed by identifier: sequence <id> goes to ESFolder_<id/1000> and KPSFolder_<id/1000> (integer division), so each folder holds at most 1000 sequences. Pivotal-event files are bucketed the same way while a run is in flight; when the tree completes they are renumbered 0 .. N-1 and collected in PEFolder_0.

Serial runs write err messages.txt, indeck.i and restart scratch files into the launch directory, not into Output/.

End State Files (ES)

ZESNode

One file per completed sequence, ZESNode_<sequence id>.txt, three lines:

ES_<id> <end time> <id> <mother branch id> 0 3096 0 <probability>
Consequence <code>
"<description>"

ES_summary.txt

A header line followed by one tab-separated line per sequence:

Column	Description
ES#	Sequence identifier
Probability	Product of the branch probabilities along the sequence
End_time	Simulation time at which the sequence ended (seconds)
Consequence#	Termination code, see below
Description	Text of the end state

Consequence codes:

Code	Identifier in SimConstants.h	Meaning
-1	NoKB	A name the model refers to was not found in the control panel or in an operator's knowledge base. The description line and err messages.txt name it (see Troubleshooting)
0	Succeed	Success
1	TimeTruncated	Reached Truncation_time
2	ProbTruncated	Fell below Truncation_probability
3	THFail	Thermal-hydraulic failure
4	CrewFail	Crew failure
5	NonResponseAction	Non-response action
6	SGOverfed	Steam generator overfed
7	AdsSimErr	Simulation error
8	EndseqAlarm	An end-of-sequence alarm was raised

Analysis Files

Each file holds one block per sequence, introduced by a banner naming the sequence.

File	Description
Scenario info.txt	Event highlights: the branch points of the sequence with event types and associated data
Procedure data.txt	Tab-separated: Time, Operator, Procedure, Step, Action, Relevance, Time_Load_PIF, Dynamic_Factor, Static_Factor, Skip_Probability
Scan data.txt	Operator scan queue: time, operator, queue size, monitored alarms, components and parameters

Key Parameter Set Files (KPS)

Three files per completed sequence. Each starts with a line giving the number of columns and rows, then a row of labels, a row of units, and the data rows.

File	Content
ZKPS_<id>.txt	Time history of the control panel indicators defined in ControlPanel.txt
ZDIA_<id>.txt	Confidence level of each diagnosis event over time, per operator
ZPIF_<id>.txt	Dynamic performance influence factors: system criticality, time constraint loading, information loading

These files import directly into spreadsheet and plotting tools.

Pivotal Event Files (PE)

One node per pivotal event (branch point). A node records the branch event type, its time, its alternatives with their probabilities, and its links to the mother and child nodes. Together the nodes define the structure of the dynamic event tree.

Pivotal events include:

• Crew decisions: decision-maker, action-taker and consultant branches
• Procedure steps: step skipping, action timing and control value branches
• Hardware events: component failure and recovery branches
• Support system events: support system reliability branches

Layout. By default each node is a file ZPENode_<node id>.txt. With --aggregate-pe the nodes are records in a single ZPENodes_agg.txt:

#PE <node id> <content bytes>
<exactly that many bytes of content>

The explicit byte count makes the format self-delimiting, so concatenating two aggregate files yields a valid one. A node id may appear more than once; the last record wins. The content of a node is identical in both layouts.

Read either layout with python3 tests/scripts/pe_canonical.py Output/PE, which prints one line per node. find -name 'ZPENode*' also matches ZPENodes_agg.txt, so a file count is not a node count. See Output layout options and Output layouts.

MPI Output Handling

• Each rank works in <project-dir>/rank_<N>/ and writes to rank_<N>/Output/ during the run, with its console output in rank_output.log and rank_errors.log.

• Pivotal-event node ids are offset by rank (rank x 100000) while the run is in flight, so ranks never collide.

• When the tree is complete the outputs are merged into the project Output/ (--merge=now, the default):

  • each worker renames its own ZESNode, ZKPS, ZDIA and ZPIF files into the shared folders (their names carry the global sequence id, so ranks never collide, and a rename moves no bytes) and stages its analysis logs and err messages.txt under Output/ES/parts/ and Output/PE/parts/. With --aggregate-pe it first compacts its pivotal-event aggregate to the last record of each node.
  • rank 0 concatenates the staged parts in rank order and removes parts/, rebuilds ES_summary.txt from the merged ZESNode files sorted by id, and moves the per-file pivotal-event nodes in rank order. The same node id can exist on several ranks, because every rank saves its own view of the ancestors it shares with others; the highest rank's copy is kept.
  • rank 0 renumbers the pivotal events 0 .. N-1. In the per-file layout this is a sequence of renames recorded in Output/PE/renumber.map, which is removed on success and lets an interrupted renumbering continue. The renumbering changes file names and record headers only; the ids written inside a node keep their rank offsets.

• A --checkpoint-stop run merges but does not renumber, so that a resume can extend the tree.

• --merge=serial and --merge=defer are described in Running. A deferred run leaves Output/MERGE_PENDING.txt:

  # adsidac deferred merge v1
  ranks <N>
  aggregate_pe <0|1>
  sequences <N>
  config_fingerprint 0x<hex>

How MPI output compares to serial

The merged MPI output represents the same dynamic event tree as a serial run: the file counts match, and the sets of end states and pivotal events (time, probability, consequence, branch structure) are identical. Two differences in presentation follow from the design:

• Sequence numbering differs. Serial explores branches first in, first out; MPI assigns sequence ids in the order in which work is dispatched and completed. ZESNode_7.txt from a serial run and from an MPI run are generally different sequences of the same tree.
• Shared-ancestor pivotal events can differ byte for byte. Each rank saves its own view of the ancestors it shares, and the merge keeps one of them. The child-link bookkeeping in such a node reflects one rank's exploration.

The same holds between two MPI runs of identical inputs when there are several workers: the node ids written inside a node carry rank offsets, and which worker takes which branch depends on timing, so the pivotal-event files of the two runs differ byte for byte while the tree they describe is the same. A run with one worker (mpirun -n 2) is reproducible node by node.

Compare serial and MPI results by content (the validation scripts compare multisets of time, probability and consequence), not by diffing files.

Expected Counts (BV4 Test Case)

The BV4 test case at Truncation_time=15.5 produces:

Output	Count
ZESNode files	36
ZPENode files (or records with --aggregate-pe)	97
ZKPS / ZDIA / ZPIF files	36 each
ES_summary lines	37 (header + 36 sequences)
Analysis files	3 (Scenario info.txt, Procedure data.txt, Scan data.txt)

Counts for other truncation times, and the counts that belong to the legacy-baseline-2026-08-18 tag, are in Reference baselines.