MessagesFileNN.csv does not faithfully serialize the FSCell event buffer

[ntua-el20123]

Summary

MessagesFileNN.csv appears to be generated from the in-memory FSCell buffer using a row count that does not match the semantics of FSCell.

As a result, the output file is not guaranteed to contain either:

• the complete set of recorded fire spread events, or
• exactly one message per burned destination cell.

Instead, it currently writes an order-dependent prefix of the recorded event stream.

---

What FSCell contains

In CellsFBP::manageFire(...), every time the fire front from a burning cell reaches the center of a neighboring cell, one message event is appended to FSCell.

Each event consists of four values:

• source cell ID
• destination cell ID
• fire period
• realized ROS

Relevant code:

if (fireProgress[nb] >= distToCenter[nb]) {
    FSCell->push_back(realId);
    FSCell->push_back(nb);
    FSCell->push_back(period);
    FSCell->push_back(ros);
}

Therefore, FSCell is naturally an append-only event stream containing every recorded reach-to-center message generated during the simulation.

---

Where the mismatch occurs

At the end of the simulation, MessagesFileNN.csv is written using

CSVPloter.printCSVDouble_V2(
    this->burntCells.size() - this->nIgnitions,
    4,
    this->FSCell
);

However, printCSVDouble_V2(...) simply writes the first rows tuples from the supplied vector.

Thus the number of rows written is

burntCells.size() - nIgnitions

instead of

FSCell.size() / 4

which is the actual number of recorded events stored in FSCell.

---

FSCell may legitimately contain:

• repeated (source, destination) message events across multiple fire periods,
• multiple incoming message events for the same destination cell,
• reach-to-center events for destinations that ultimately never satisfy get_burned(...).

Consequently, MessagesFileNN.csv is currently not guaranteed to represent either:

1. the complete set of recorded message events, or
2. one canonical message per burned non-ignition cell.

Instead, it becomes an order-dependent prefix of the event buffer.

Furthermore, because events are appended while iterating over containers such as burningCells and ROSAngleDir, the retained prefix does not appear to correspond to any explicit or documented selection rule.

---

Observed downstream impact

This affects all outputs that consume MessagesFileNN.csv, including:

• PropagationTreeNN.png
• FireSpreadTreeNN_*.png
• aggregated spread graphs constructed from the message files

because these visualizations are built from a potentially truncated event stream.

---

Questions for the maintainers

1. Was MessagesFileNN.csv intended to contain:

   • all recorded reach-to-center events, or
   • exactly one representative message per burned destination cell?

2. If the latter is the intended behavior, what is the intended parent/message selection rule?

   • First arrival?
   • Earliest fire period?
   • Highest ROS?
   • Another criterion?

Without an explicit selection rule, the current implementation appears to produce an order-dependent subset of the recorded events rather than a well-defined propagation tree.

[DLWoodruff]

Thanks for the unusually precise write-up — the diagnosis is exactly right. MessagesFileNN.csv was being filled from the first burntCells.size() - nIgnitions tuples of the append-only FSCell buffer, which (as you note) can hold multiple events per destination and events for cells that never burn, so the result was an order-dependent prefix rather than a well-defined tree.

Q1 — intended content: exactly one representative message per burned, non-ignition cell — i.e. a spanning forest rooted at the ignition cells. That was always the intent: the burntCells.size() - nIgnitions row count (a forest with nIgnitions roots has nodes − roots edges) has been there since the first commit. What was missing was an actual selection — the code just trusted the buffer order.

Q2 — selection rule: the parent of each burned cell is now chosen by earliest fire period, with ties broken by highest realized ROS and then lowest source id (the last purely for determinism). First-arrival matches the wave-propagation semantics of the model and is the closest well-defined version of what the original prefix approximated. Output rows are also now sorted by destination id, so the file is reproducible.

One subtlety we had to handle: ignition cells never pass through get_burned, so they're never cleaned out of their neighbors' ROSAngleDir and can appear as message destinations in FSCell. The fix tracks ignition cells explicitly and excludes them as destinations, so the roots stay parent-less.

This is an output-only change — burned cells, grids, and stats are unaffected. Fix is in PR#140. Thanks again for the report.

[ntua-el20123]

Thank you for the detailed response and for addressing this so quickly.

The clarification makes sense, especially the intended interpretation of MessagesFileNN.csv as a spanning forest with one representative parent message per burned non-ignition cell. The new first-arrival selection rule, with deterministic tie-breaking, also resolves the ambiguity I was concerned about.

The point about ignition cells appearing as destinations because they do not pass through get_burned is particularly helpful. I had noticed some behavior in that direction but had not fully connected it to the cleanup logic.

Thanks again for reviewing the issue carefully, this makes the output much easier to interpret and use reliably in downstream graph-based formulations.