Streamlit webapp uses parallel math instead of FlexiMORP engine

[nishasdk]

Summary

The Streamlit app (webapp/app.py) computes baseline, uncertainty, and flexibility results with standalone NumPy formulas instead of calling BaselineOptimization, UncertaintyAnalysis, and FlexibleDesign.

Location

webapp/app.py — key functions:

Function	What it does instead of engine
run_analysis()	Fake progress bar; calls build_results() only
build_results()	Local capacity/LCOE/NPV math
derive_capacity()	Hardcoded 0.38 CF and 3.2 $/MW heuristics
allocate_capacity()	Weighted by cf / cost
calculate_technology_metrics()	capacity * cf * 8760 / 1000
calculate_lcoe() / calculate_npv()	Simplified annuity formulas
scenario_samples()	Random perturbations around local LCOE
flexibility_plan()	Rule-of-thumb expansion premium

The UI labels stages "Baseline", "Uncertainty", "Flexibility" but none invoke fleximorpv2 analysis classes.

Impact

• Webapp results can diverge from notebook/API/engine outputs for the same site config.
• Hardcoded defaults (default_capacity_factor, opex_ratio, 0.38 implied CF) are not shared with fleximorpv2/config.py.
• Users may treat Streamlit dashboards as authoritative while README examples use the real pipeline.

Suggested fix

1. Replace build_results() with calls to BaselineOptimization.optimize(), UncertaintyAnalysis.run_monte_carlo(), and FlexibleDesign.analyze_flexibility().
2. Map Streamlit settings (target_type, target_value, technologies) to engine OptimizationTarget inputs.
3. Add caching/timeouts for long runs; show engine errors in UI instead of silent approximations.
4. Keep lightweight preview mode optional, but label it clearly as "screening estimate".

Acceptance criteria

• "Run analysis" uses the same code path as tests/test_integration.py
• LCOE/NPV/capacity for a reference site match engine within documented tolerance
• UI indicates when results are engine-backed vs. screening-only