Wind analysis software: from LiDAR to bankable report

Every wind campaign follows the same path: LiDAR or tower generates months of data, the engineer processes them in wind statistics, and these numbers feed the estimate of AEP that will determine the DSCR and the debt capacity of the project. How? This processing happens — and the method matters more than it seems.

The fragmented flow — Excel for QA/QC, Python scripts for Weibull, IT and shear, manually typed into Word — is the norm in smaller consultants. It works. But introduces invisible risks: untraceable decisions, non-reproducible analyses, and audit trails that live in the memory of the engineer instead of in the deliverable file.

The current tool scenario

Three categories of software dominate the analysis of wind resource. Each covers the problem differently:

Excel/Python avulsed. Zero cost, maximum flexibility, zero traceability. Each campaign is a custom workflow. QA/QC's decision in March — "we excluded this period because the bug showed saturation" — may not appear anywhere in the final report if the engineer who took it is no longer on the team. The Python script that generated Weibull lives in a local folder; the number in the report was manually copied from a chart.

Windograph (Mistaya Engineering, ~US$ 2.000–2.500/year). Market standard for wind resource analysis. Solid in MCP (Measure-Correlate-Predict with ERA5/MERRA-2), strong in fundamental analyses (Weibull, shear, wind rose). Weak point: reports are manual exports — the link between analysis decisions and the deliverable document is not automatic. No native audit trail for IEC 61400-12-1. Interface in English only.

Academic tools and open-source. Library like – Windrose, Windpowerlib Technically solid, but they produce bankable output only with considerable manual work on the results.

What defines an integrated workflow

The concept is direct: a single campaign file concentrates raw data, processing decisions, analysis results and the information that feeds the report. Decisions taken in QA/QC are recorded in the same structure that generates the narrative of Section 4 of the report. If the lender asks "why was August excluded?", the answer is in the file — with timestamp, reason and responsible.

Three properties define a truly integrated workflow:

It's the only real source. A unique campaign file (owner format, type) - .bora. , or equivalent) that loads data + decisions + metadata. Move or duplicate this file moves the entire campaign history.

Automatic propagation. One-step decisions propagate to the next without manual re-digitation. The percentage of computer availability in QA/QC is the same number in the report — not a value copied by the engineer with possible rounding error or outdated version.

Replay determinism. Given the same inputs and the same sequence of decisions, the analysis is reproducible by any engineer with access to the file. This is the foundation of §5 of IEC 61400-12-1 on data quality assessment documentation — and what a due diligence auditor will verify.

BORA Wind Analyzer as a case study

The BORA is an offline desktop tool for LiDAR (ZephIR, WindCube) campaigns and met masts, built around the above three properties. The concrete operational flow:

1. Automatic ingestion. The engineer points to the folder with raw files. BORA detects the type of equipment, date intervals and heights available automatically. Files outside the detected format are signaled on the interface — with the reason — rather than silently discarded. The visual configuration of parser profiles covers ZephIR, WindCube CSV, WindCube .sta and Campbell TOA5.

2. QA/QC with score 0–100. Six categories of alert (availability, quality, sensor, data integrity, calibration, operation) are automatically evaluated against the IEC 61400-12-1 thresholds. Each alert can be confirmed by the engineer with a justification that goes to the audit trail — a structured record within the file - .bora The 0–100 score reflects the current state after the recognitions, not before.

3. Analysis IEC without manual transfer. Weibull by height, shear (alpha and profile), representative IT with category IEC 61400-1, wind rose, directional and day analysis — all computed on the validated dataset, without manual copies of numbers between tabs or spreadsheets. The frequency table for WAsP (format - .tab) is exported directly from the session.

4. Report generated — not typed. Word with self-generated narrative in PT/EN and PDF in 8 sections IEC are produced directly from the session. The availability table in Section 3 reads the same data as QA/QC. The parameters Weibull in Section 6 are the same numbers displayed on the analysis tab. OSM map with equipment marker is inserted automatically.

5. .bora file as campaign memory. The campaign file accumulates months indexed with pre-computed statistical summaries (MonthSummary), allowing monthly comparison without reprocessing the original CSVs. Each decision — bearing correction, exclusion of period, recognition of alert — is recorded with timestamp, creating a historical replay-deterministic of the entire campaign.

Critical Gap: MCP is not covered

Workflow integrated or not, a central function remains outside the current scope of BORA: the MCP (Measure-Correlate-Predict). This is the step that correlates the measurement period (typically 12–36 months) with a long-term reanalysis reference (ERA5 or MERRA-2) to extrapolate the wind speed P50/P90 for the economic life of the project.

The current flow with BORA is:

Raw data → [BORA: QA/QC + analysis + campaign report]
            → [Windographer or WAsP: MCP]
            → [WAsP: flow modeling + AEP]

BORA exports frequency tables in format - .tab For WAsP, which eliminates the Windographer from the flow modeling stage. But the MCP correlation itself still requires external tool. For a discussion on the choice of the long-term reference (ERA5 vs MERRA-2) and its methodological implications, see NT.02.

This gap is honest and does not change the central argument: for campaigns under analysis — from raw data to the characterization of the wind regime on the site — the integrated workflow already covers what most impacts traceability and bankability. MCP is the next step, and will be the most significant competitive differential when implemented.

Time and traceability in practice

The most expressive data of the comparison is in the report: the manual writing of a technical report IEC to funder consumes between 8 and 16 hours of senior engineer — time spent recompiling numbers already calculated, not adding technical value. With self-generated narrative from the analysis session, this time falls to 2-3 hours of revision and customization.

The second impact is less immediate but more significant: traceability. Each hour of work in fragmented flow adds an opportunity for divergence between what has been analyzed and what has been documented. A report generated directly from the analysis session has zero divergence by construction.

Implications for bankability

A bankable wind resource report needs to answer three questions in a technical due diligence, according to international legend standards:

1. Data custody chain. Where did each measurement come from, and how was it processed? Fragmented flow typically produces a validated data file with no history of how it got there. The integrated campaign file has a complete history — each ingestion operation, each bearing correction, each period deletion.

2. Track of decisions. What periods were excluded and why? In the fragmented flow, the justification lives in a comment in a script, in an internal note or in the memory of the engineer. In the integrated workflow, each alert recognition carries motive, timestamp and author — reproducible and auditable regardless of who did the analysis.

3. Method compliance. The analysis follows IEC 61400-12-1 (or equivalent)? Without structured documentation of applied threads, evaluated alert categories and acceptance criteria, compliance is difficult to demonstrate. QA/QC automated with IEC score and categories resolves this systemically.

The same logic applies to the decomposition of uncertainty discussed in NT.06A well-documented AEP uncertainty is useless if inputs cannot be traced to a QA/QC record. The audit trail and uncertainty quantification need to be part of the same coherent workflow — and it is precisely this consistency that differentiates a bankable deliverable from a technically correct but unheard of report.

For LiDAR campaigns with data availability below the IEC limits, see the gap and recovery criteria discussed in NT.01 — and how the way to document the gaps directly impacts the acceptance of the report by the lender.