Microgrid Load Profile Guide: Build and Validate an 8,760-Hour CSV

Key takeaways

• Define the electrical boundary first: every value must represent the same loads, losses, operating mode, and unit convention.
• Use exactly 8,760 finite, nonnegative hourly-average kW values for the current MicrogridModeler uploader; perform timestamp and calendar QA before removing timestamps.
• Reconcile annual energy, monthly energy, peak demand, load factor, percentiles, ramps, zeros, and operating schedules before any capacity search.
• Preserve normal, critical, flexible, auxiliary, and future loads as documented scenarios instead of hiding every uncertainty in one curve.
• Annual kWh and peak kW do not prove chronology is correct: the worked six-hour shift keeps both unchanged but makes the retained screen infeasible.

Applicability, boundary, and assumptions

For this workflow, a load profile is the electrical demand the proposed off-grid bus must serve in every modeled hour. It is not a utility bill total, an equipment nameplate list, or a load-duration curve. Chronology matters because solar availability, battery state of charge, generator loading, and unmet energy depend on when each kW occurs and on the sequence before it.

Apply this guide to hourly PV + battery + diesel feasibility and sizing. It helps prepare the demand input and test whether it is internally credible. It does not replace subhourly motor-start studies, power flow, protection, harmonics, controls design, equipment derating, field metering plans, or a forecast of customer adoption.

The worked method assumes hourly-average kW on one aggregate electrical boundary, an explicitly chosen 8,760-hour non-leap calendar, and a resource series aligned to the same clock. It does not assume that synthetic data equal site evidence; the source class and reconciliation determine how much confidence the profile deserves.

Write the boundary in one sentence before touching the data: site, meters or end uses included, auxiliary and conversion loads, normal or contingency mode, gross or net convention, time zone, data period, and whether future phases are present. A perfectly clean file that represents the wrong boundary is still the wrong input.

• Use kW for hourly-average power; calculate energy as the sum of kW multiplied by each interval duration.
• Keep source timestamps and raw files immutable; create the model-ready series as a documented transformation.
• Do not mix facility load, generator output, PV production, and battery flow unless the energy boundary explicitly requires a derived net load.
• Keep one owner, source date, unit, time zone, and confidence level with every profile version.

Sources for this section: NLR guidance on utility bills and interval load data · World Bank and ESMAP mini-grid demand-profile workflow

Choose the strongest available load source

Measured interval data are usually the strongest starting point for an operating site because they preserve actual coincidence and operating schedules. NLR guidance recommends 15-, 30-, or 60-minute site data when available and uses bills to reconcile or scale simulated profiles. For a new site, productive-use program, or changed operating model, a transparent end-use build may be more honest than pretending an unrelated meter is representative.

Public reference profiles can supply a documented starting shape, but they are not site measurements. NLR describes its End-Use Load Profiles as simulated building-stock data calibrated and validated against empirical datasets. Use that distinction in the evidence note: measured, calibrated simulation, local parametric shape, survey build, and assumed schedule are different evidence classes.

Sources for this section: NLR End-Use Load Profiles for the U.S. building stock · NLR guidance on utility bills and interval load data

Build the 8,760-hour series in ten ordered steps

Keep a source table with timestamps until the calendar and interval checks are complete. Only the final handoff to the current MicrogridModeler uploader should become a one-column numeric series.

1. Write the load boundary and operating mode. Name every included meter, end use, auxiliary load, loss, and excluded future phase.
2. Archive the raw source. Preserve the original file, meter export settings, time zone, interval convention, units, and retrieval date.
3. Normalize the interval. Convert energy readings to average kW using kW = interval kWh divided by interval hours; aggregate subhourly power to hourly energy-weighted averages.
4. Normalize the calendar. Choose a documented non-leap model year, time zone, and daylight-saving treatment; resolve duplicate, missing, and out-of-order timestamps before stripping them.
5. Repair only with an explicit rule. Flag outages, telemetry gaps, impossible values, and substitutions; retain an unfilled series and a repair log.
6. Reconcile energy. Compare interval totals with trusted bills, fuel-generation records, submeters, or equipment schedules by month and for the year.
7. Test power and shape. Review peak, minimum, load factor, percentiles, ramps, zero runs, weekday/weekend patterns, seasons, and known operating hours.
8. Separate scenarios. Preserve a central case plus credible low, high, growth, critical-load, and flexible-load variants rather than averaging uncertainty away.
9. Export the model-ready column. Use exactly 8,760 finite, nonnegative hourly-average kW values in chronological order for the current uploader.
10. Upload last and verify. Finish site and load-control edits first, upload the CSV, rerun, confirm annual load in results, and independently recalculate peak from the cleaned source column; re-upload after any edit that regenerates the load.

Sources for this section: NLR REopt load-profile input tutorial · World Bank and ESMAP mini-grid demand-profile workflow

Use the safe MicrogridModeler CSV contract

The current uploader accepts CSV or text, splits all content on commas, semicolons, whitespace, and line breaks, discards nonnumeric tokens, and sends the first 8,760 numeric values to the engine. The safest contract is therefore one numeric hourly-average kW value per row, exactly 8,760 rows, with no numeric timestamp or index column.

This parser normalizes length; it does not certify data quality. A short sequence is tiled and a long sequence is truncated. The interface currently does not show those parser warnings. Timestamp strings may be ignored without proving their order, and negative values are not rejected. Treat the table below as an acceptance benchmark anchored to the evidence commit, not a promise that malformed data are safe.

Apply a pass-or-fail load-profile audit

A useful QA sheet ends in a decision, not a gallery of charts. Mark each check pass, fail, accepted exception, or not applicable; record the evidence and the person who accepted any exception.

Download and reproduce the worked 8,760-hour artifact

The downloadable CSV is a deliberately synthetic format and QA example. It uses MicrogridModeler’s local deterministic Outpatient parametric shape, a 2017 non-leap calendar convention, 100,000 kWh annual target, and 5.6°N seasonal phasing. The values were rounded to six decimals before the audit, so the file—not the unrounded generator array—is the evidence object.

The CSV contains one value per row and no header. Its SHA-256 fingerprint is a7efdf80e9d8d0bf97a6e8d27509b3341553fdf80fc7f7efc95dcf5956d58274. The companion manifest records assumptions, calculations, the capacity-search boundary, the clock-shift sensitivity, and limitations. Neither file represents a real outpatient clinic or a downloaded DOE/NLR reference time series.

Original sensitivity: the same values, six hours out of alignment

To isolate clock alignment, the shipped automatic sampled and locally refined search was run on the worked profile at the synthetic Remote clinic site. It evaluated a 256-point coarse grid plus 71 local-refinement calls and retained a first-pass design of 140 kW PV, 190 kWh / 38 kW battery, 16.9 kW aggregate genset, and 126 kW converter. This is the lowest-NPC point found by that sampled procedure, not a continuous global optimum.

The retained design was then simulated unchanged after moving the same 8,760 load values six clock hours later. Annual energy, peak, minimum, percentiles, and load factor remain identical. Only alignment changes. The shifted profile was not re-optimized, because the test asks whether the original recommendation survives a timestamp error.

The lifecycle figures use the manifest’s editable benchmark assumptions: a 25-year project, 8% nominal discount rate, 2% inflation, $1.45/L starting diesel, 2% real fuel escalation, and a 30% credit on eligible clean-energy capital. These are transparent calculation inputs, not current supplier quotes, financing advice, or values to reuse without a project-specific review.

Interpret the sensitivity without overgeneralizing it

This is not evidence that every six-hour error doubles lifecycle cost or that the retained capacities suit a real clinic. It shows something narrower and more useful: annual kWh, peak kW, and load factor can all pass while the hour-to-hour relationship with solar changes enough to invalidate a zero-unmet-load recommendation.

The high curtailment in both runs and the sharp shifted-case failure are reasons to widen the design and scenario review, not to defend the first-pass point. Re-optimize each accepted profile version, inspect difficult hours, and compare nearby feasible designs. If a clock convention is uncertain, resolve it or retain separate alignments as scenarios before recommending equipment.

Normalize leap years, daylight saving, and missing intervals explicitly

An 8,760-hour model year is a convention, not a property of every meter export. Leap years contain 8,784 hours. Daylight-saving clocks can create a missing or duplicated local hour. UTC data avoid daylight-saving ambiguity but must still align with a solar series and operating schedules. The current uploader reads position, not timestamp, so those decisions must happen upstream.

NLR’s REopt tutorial requires the correct row count, a series beginning with the first hour of January 1, and a year that preserves day-of-week alignment; its legacy leap-year example removes December 31. That is a tool-specific rule, not a universal repair. Choose the calendar expected by the receiving model, document the transformation, and compare hourly index zero in load and resource before running dispatch.

• Keep raw UTC or local timestamps, offset, and daylight-saving flag in the source archive.
• Resolve duplicates with interval energy and meter semantics, not by deleting whichever row looks inconvenient.
• Fill gaps from adjacent days, matched operating days, a model, or zero only when the physical meaning supports it; flag every filled record.
• Do not blindly truncate 8,784 rows and call the result calendar-normalized.
• After transformation, recalculate annual and monthly energy and inspect the hours around every repair.

Sources for this section: NLR REopt load-profile input tutorial

Keep critical, flexible, and future loads as explicit scenarios

A normal operating profile and a critical-load profile answer different questions. Critical load should identify the services that must remain energized under a defined contingency, not simply multiply every hour by one convenient percentage. Flexible loads such as pumping, ice making, or charging need an energy requirement, power limit, operating window, and service consequence before a model may shift them.

For future demand, build phase- and adoption-based profiles when timing can change. A flat annual multiplier preserves shape and may be adequate for a narrow sensitivity, but it cannot represent a new evening productive load, daytime pumping program, clinic expansion, or changed occupancy schedule. World Bank guidance builds mini-grid demand by customer segment, equipment, hourly utilization, season, and expected productive use; retain those assumptions beside the aggregate.

Sources for this section: World Bank and ESMAP mini-grid demand-profile workflow · NLR resilience guidance on critical-load timing

A practical decision rule

Accept a microgrid load profile for capacity screening only when its boundary and provenance are explicit; the calendar contains exactly the intended 8,760 ordered hours; units and intervals are correct; repairs are logged; annual and monthly energy reconcile; peaks, ramps, zeros, and schedules are plausible; and central, critical, flexible, growth, and uncertainty scenarios cover the decisions the model must support.

If any check fails, do not hide the uncertainty inside extra battery or generator capacity. Correct the data, collect better meter or survey evidence, or preserve the uncertainty as a named scenario. Size the system only after the input owner and model reviewer can explain what record 1 and record 8,760 mean.

Limitations and engineering handoff

The worked file is synthetic, hourly, deterministic, and single-boundary. It contains no measured outages, subhourly peaks, motor starting, power factor, harmonics, operator interventions, forecast distribution, or customer adoption data. Its solar resource and capacity screen are also synthetic. Use it to reproduce the QA and parser method, not as a clinic design input.

The current MicrogridModeler uploader does not preserve filename, timestamps, time zone, source, repair log, or profile confidence. It can tile or truncate numeric data, and site or load-control edits can regenerate the current load. The results view reports annual load but does not display the uploaded series peak; the separate configuration peak is not recalculated on upload. Keep the evidence outside the browser, finish those edits before upload, upload the final one-column series last, verify annual load in results, independently recalculate peak from the cleaned source, and re-upload after any relevant edit.

Hand the next analyst the raw source, cleaned timestamped table, final 8,760-value column, QA record, transformation script or formulas, scenario register, source owner, checksum, model version, and unresolved exceptions. The evidence package should make it possible to rebuild the input without guessing.

Sources for this section: Sandia Microgrid Conceptual Design Guidebook · IEA PVPS blueprint for off-grid feasibility studies

Bottom line

Build the load profile before sizing the equipment. Preserve timestamps while cleaning, convert every interval to the right power convention, reconcile energy, inspect shape, separate scenarios, and only then export the exact one-column 8,760-value series the model expects.

The decision rule is deliberately strict because load errors propagate everywhere: PV energy, battery power and duration, generator duty, fuel, renewable fraction, unmet load, and lifecycle economics. A smaller model run with a defensible profile is more useful than a sophisticated optimization of the wrong hours.

Keep exploring

Sources and review notes

This article is grounded in the cited technical sources and the stated modeling assumptions. Recheck project inputs, equipment data, and local requirements before using it for design.