Skip to main content

​
Data Quality and Limits

High-quality inputs matter as much as model fidelity. Daly enforces many structural checks and also relies on user data quality.

​
Weather Input Constraints

For maintained v2 solar preparation and admission, inline weather arrays must:
  • Use consistent lengths across required series (ghi, dhi, windSpeed, temperature, etc.)
  • Use finite observations: irradiance and wind speed must be nonnegative, temperature must exceed −273.15 °C, and supplied relative humidity must be between 0 and 100 percent
  • Include interval-center date labels in milliseconds; an unmarked 8760-point input may omit them for the 1990 compatibility calendar
  • Include explicit dates whenever dateUtcOffsetHours is present, even at zero
  • Stay within payload-size limits (up to 100,000 timestamps in validated model input)
Flat arrays and location weather wrappers are validated. Documented snake_case aliases are accepted, including weather_data, wind_speed and date_utc_offset_hours; normalization preserves explicit dates, observation values and unrelated metadata. These validation rules do not certify the underlying measurement quality.

​
Location and Timezone

Location selection controls:
  • Sun-position geometry
  • Time-zone assumptions and optional overrides
  • Far-shading profile applicability
Timezone mismatch between weather timestamps and site assumptions is a common source of error. dateUtcOffsetHours declares a fixed local-standard offset, from −12 to +14 hours, including fractional offsets. Native solar geometry uses the local labels and this offset; preparation subtracts it once to produce UTC intervals. For verified UTC native solar data, use settings.timeZoneOverride: 0 or an explicit zero weather offset. A supplied settings override must agree with the weather offset. The preparation sourceTimezone field records provenance; it does not reinterpret timestamps or supply missing clock metadata. Stored, unmarked, non-subhourly weather with exactly 8760 records retains an older compatibility rule: runtime hydration replaces its dates with the 1990 hourly calendar, even when dates were saved. Explicit inline dates and stored weather with dateUtcOffsetHours retain their dates. A settings timezone override alone does not disable that stored-calendar rule. Check the prepared axis before a historical or forecast comparison. Weather and solar settings may separately declare sourceTimeAdjustments. Nonzero solarGeometryOffsetMinutes is unsupported and rejected rather than dropped. appliedLabelShiftHours is information about a shift already applied to source labels; it never shifts the dates again. See Solar Template Preparation for import and reference-comparison requirements.

​
Equipment Library Quality

Module and inverter libraries strongly affect results. Parsed .pan and .ond fields drive:
  • IAM/AOI behavior
  • Temperature and electrical response
  • Inverter limits, efficiency curves, clipping behavior

​
Spectral and Bifacial Conditions

  • Spectral correction is applied for eligible conditions/modules.
  • Bifacial effects are modeled when bifacial inputs are present and complete.

​
Computational and API Limits

  • The retained standard solar API uses POST /energymodels, sync-first by default, with ?async=true for queued execution. This is the standard quick-run path, not native v2 preparation.
  • Native v2 studies submit a hybrid-1 or plant-1 request to POST /v2/energymodels?calculationEngine=hybrid and use queued execution. Keep reads and task polling on the same API base as the run.
  • Very large timeseries outputs (fullTimeSeries, debug-heavy payloads) can be expensive to store/transfer.
  1. Validate weather arrays and timestamp conventions before submission.
  2. Verify module/inverter metadata for key electrical fields.
  3. Run a baseline single-block case before portfolio-scale runs.
  4. Compare summary losses against expected ranges before operational decisions.