[BurnP3+ Bug]: After scenario merge in beta release, FBP output options are duplicated and cause errors

[katieb1]

Contact Details

No response

What happened?

After using the new merge transformer in the beta release of FireSTARR (v1.5.5), the FBP spatial output options are duplicated for every results scenario (see screenshot).

This results in the following downstream error:

[Failure] The external program failed.
Program name was: C:\Program Files\R\R-4.5.2\bin\Rscript.exe
Arguments were: "C:\Users\Administrator\AppData\Local\SyncroSim\Packages\burnP3Plus\2.6.5\burnProbability.R"
Exit code was: 1
More information:
Joining with `by = join_by(Iteration)`
Joining with `by = join_by(Iteration, FireID)`
Error in if (!is.na(componentOutputOptions$Individual) & componentOutputOptions$Individual) { : 
  the condition has length > 1
Execution halted

The above fails because instead of getting a single TRUE or FALSE it returns a list of TRUE or FALSE. To fix, we just need to add a %>% distinct() at the end of line 22 (where the FBP Output Spatial datasheet is loaded for the first time).

What component are you seeing the problem on?

No response

Relevant log output

SyncroSim Version: 3.1.23.0
Operating System: Microsoft Windows Server 2022 Datacenter (Microsoft Windows NT 6.2.9200.0)

Packages:
burnP3Plus -> 2.6.5
burnP3PlusFireSTARR -> 1.5.5
core -> 3.1.23

Parent Scenario is: [12] FBP outputs
Result scenario is: [13] FBP outputs ([12] @ 26-Feb-2026 6:56 PM)

[Information] External input files have been excluded from this result scenario.

--------------------------------------------
STARTING SIMULATION: 2/26/2026 : 6:56:57 PM
--------------------------------------------

START TRANSFORMER: 4 - Summarize Burn Probability

This Library is capable of using conda environments, but the 'Use conda' property is disabled.
To enable conda, refer to https://docs.syncrosim.com/getting_started/quickstart_conda.html

[Information] 4 - Summarize Burn Probability: Using a newer version of rsyncrosim (2.1.9) than BurnP3+ was built against (2.1.0).

[Information] 4 - Summarize Burn Probability: Using a newer version of terra (1.8.86) than BurnP3+ was built against (1.5.21).

[Information] 4 - Summarize Burn Probability: Using a newer version of sf (1.0.23) than BurnP3+ was built against (1.0.7).

[Information] 4 - Summarize Burn Probability: Using a newer version of dplyr (1.1.4) than BurnP3+ was built against (1.1.2).

[Information] 4 - Summarize Burn Probability: Using a newer version of codetools (0.2.20) than BurnP3+ was built against (0.2.19).

[Information] 4 - Summarize Burn Probability: Using a newer version of data.table (1.17.8) than BurnP3+ was built against (1.14.8).

[Information] 4 - Summarize Burn Probability: Using a newer version of arrow (22.0.0) than BurnP3+ was built against (14.0.1).

Finished preparing inputs in 3.7 minutes

[Warning] 4 - Summarize Burn Probability: Could not sample enough fires above the specified minimum fire size for 17612 iterations.
Please increase the 'Proportion of Extra Ignition to Sample' in the Fire Resampling Options or decrease the 'Minimum Fire Size'.
Please see the Fire Statistics table for details on specific iterations, fires, and burn conditions. Incomplete iterations will not be included in summary burn maps

Burn Summary:
227514 fires burned. 
95182 fires discarded due to insufficient burn area.
58% of simulated fires were above the minimum fire size.
0% of extra simulated fires not used because target ignition counts were already met.

Finished summarizing burn status and resampling fires in 17 seconds

Finished building burn summary maps in 1.6 minutes

[Failure] The external program failed.
Program name was: C:\Program Files\R\R-4.5.2\bin\Rscript.exe
Arguments were: "C:\Users\Administrator\AppData\Local\SyncroSim\Packages\burnP3Plus\2.6.5\burnProbability.R"
Exit code was: 1
More information:
Joining with `by = join_by(Iteration)`
Joining with `by = join_by(Iteration, FireID)`
Error in if (!is.na(componentOutputOptions$Individual) & componentOutputOptions$Individual) { : 
  the condition has length > 1
Execution halted

--------------------------------------------
SIMULATION COMPLETE: 2/26/2026 : 7:02:36 PM
--------------------------------------------
Total simulation time: 00:05:39

Approvals Process

• Testing For Issue
• Merge

[shreeramsenthi]

Great catch! I'm curious why I never ran into this issue before, but I also don't think the merge transformer actually modifies any of the Output Option tables.

Did SyncroSim change anything about default datasheet inheritance from multiple dependencies that could be merging these datasheets? And could you double check that none of the input scenarios to the merge transformer already have duplicated Output Options?

Regardless, we probably need error handling to ensure that users don't specify different FBP output options for the same component twice, either manually or by merging. I think distinct only works if there are exact duplicates though, so there's still room for unexpected errors. I think instead I would lean towards either erroring out or warning that there are multiple rows for a given component and that we're just going to respect the first row we encounter.

[katieb1]

Do you usually merge your dependencies in your merge/summarize scenario? I think that might be causing the duplicate rows. It's an artefact of the SyncroSim dependencies where any multirow datasheet gets duplicated and I think it's been around for a while (I remember running into this with WISDM a while ago too). I don't think we plan to fix it, so would be good to handle it at the BurnP3+ level.

I like the idea of throwing a warning and using the first row.

[shreeramsenthi]

Gotcha! I don't usually merge dependencies, but I wonder if that's why I haven't haven't seen this before. Are dependencies merged in this example?

[katieb1]

They are merged in this example, but I'm guessing if you don't merge them then they don't need to be?

[shreeramsenthi]

Yeah, I never do, but good to know it has this problem. The BP3+ merge transformer basically just scrapes the SIDs from it's dependencies grabbing any results and successful children of selected parents and does all the merging based on that. It doesn't actually read in any of it's "own" datasheets. In effect the only real "input" to the transformer is the Scenario IDs and all the necessary data is pulled out of each of the selected scenarios. I suppose it's rather non-standard SyncroSim, but I just thought there was too much opportunity otherwise for users that are not familiar with SyncroSim to get results they weren't expecting.

I'll add that warning we talked about and close this issue once it's up.