APEX-CUTE v7.1 (APEX v1501) Crashing with Sensitivity Analysis/Calibration

[Kaveh Siah]

Environment
- APEX: v1501 
- APEX-CUTE: v7.1 

Problem summary
APEX and APEX-CUTE run successfully with the provided example/base .SUB (4 subareas). After deleting one or more subarea blocks inside the same .SUB file (e.g., reducing to 3, 2, or 1 subarea), APEX-CUTE Sensitivity Analysis and Calibration crash immediately upon start. Reverting to the original 4‑subarea .SUB restores APEX-CUTE functionality. The behavior points to a .SUB routing/block-structure or output-parsing issue during SA/Calibration, even though normal APEX runs may complete.

Change log (reproducible sequence)
1) Weather updates
- Edited .DLY, WPM1.DAT, .WP1, APEXRUN.DAT, APEXCONT.DAT, WDLSTCOM.DAT, and (as needed) .SUB to reflect the weather station and run dates.
- APEX run: Succeeds.
- APEX-CUTE SA (crop parameters only): Succeeds.

2). Added 5th headwater-subarea to SUB0002.SUB
- APEX run: Succeeds.
- APEX-CUTE SA (crop parameters only): Succeeds.


3) Crop files (.OPS, CROP.DAT, FERT.DAT, .SUB)
- Added Miscanthus as crop 180; updated the .OPS to use crop 180; adjusted FERTDAT as needed.
- APEX run: Succeeds.
- APEX-CUTE SA/Calibration: Crash at start.
Rollback experiment:
- Reverted .SUB and .OPS to example/base; pointed APEXRUN back to the example .SUB; APEX-CUTE SA restored (at least for one parameter test). Conclusion: OPS/CROP are not the trigger.

3a) Isolating .SUB
- Modified only the .SUB: deleted subarea blocks to reduce from 4 → 3, 2, or 1 subarea (staying with the example/base configuration otherwise).
- APEX-CUTE SA/Calibration: Immediate crash in all reduced-subarea cases.

Notes: Adding subareas, as long as done correctly (following routing rules), doesn't lead to crashing. The crashing occurs when any of the original subareas are deleted. Since the first listed subarea is an extreme channel/headwater, I thought it would be fine to run the model with this subarea alone, but the APEX-CUTE still crashes during SA/Calib. To note, all APEX1501.exe runs work fine and yield output as long as the .SUB files are structured correctly.  

3b) OPS-only changes (keep 4 subareas)
- With the original 4‑subarea .SUB intact, changed only the .OPS number that each subarea calls (to the Miscanthus schedule).
- APEX-CUTE SA (e.g., parameter WA): Succeeds.

What works
- Base example SUB0002.SUB with 4 or more subareas: APEX runs; APEX-CUTE SA/Calibration run.
- Weather and site substitutions with matching list references: APEX and APEX-CUTE SA run.
- OPS/CROP changes alone (keeping 4+ subareas): APEX-CUTE SA runs, calibration.

What fails
- Any reduction of subareas inside the .SUB (4 → 3/2/1) causes APEX-CUTE SA/Calibration to crash immediately at start. This seems to happen no matter what I do to the subarea parameters. 


What I verified
- ISUB in APEXRUN.DAT points to the intended SUBACOM.DAT index for the current test run .
- After reverting to 4 subareas (no subarea deletion), APEX-CUTE SA succeeds without changing anything else, confirming the OPS/CROP and weather/site changes are not the cause. Correspondingly, adding subareas does not cause any crashing. 

- With a single subarea, I ensured the subarea is a standalone “extreme” unit (RCHL = CHL; WSA positive) so it should not expect upstream donors. While the manual discusses data structure and routing conceptually, “improperly constructed .SUB” is the documented failure signal if something about the routing/block content is inconsistent .

Requests for guidance from the forum
1) When reducing subareas within the same .SUB file, are there additional flags or counts APEX requires (e.g., an explicit subarea count) beyond having N-repeated subarea blocks? Essentially, am I just missing a parameter somewhere?

I can produce files on request.