PVsyst Simulation Services: Reproducible Model Procurement

Quick Answer

Buy PVsyst simulation services for a named decision and project stage, not for one attractive yield number. Freeze a controlled input register, accepted software version, model variants, outputs, review process, and file-handover standard. Accept the work only after a qualified reviewer can reopen the delivered package, trace material assumptions, reproduce headline results, and explain every material change.

PVsyst simulation services should produce a model that another competent person can inspect, reopen, and reproduce. The purchase is not one annual energy number. It is a controlled model package for a defined decision at a stated project stage.

Begin by naming the decision. A concept layout, EPC bid, investment review, equipment change, construction issue, and operating comparison need different evidence. Their acceptable assumptions and review depth also differ.

The model provider should receive an approved input register. The contract should identify the PVsyst version, baseline variant, sensitivity cases, outputs, editable files, reviewer, comments process, security rules, and acceptance test.

Related-party disclosure

SurgePV and Heaven Designs have a related-party commercial relationship. Heaven Designs links are sponsored. Its published scope, sample, schedule, accuracy, project, and outcome statements are provider claims. Apply the same evidence and acceptance gates to every provider.

Key takeaways

Define the decision and model maturity before requesting a yield.
Freeze inputs with sources, units, dates, owners, and approval status.
Treat weather selection and long-term adjustment as analytical choices.
Match geometry, shading, equipment, stringing, and losses to current evidence.
Name the exact PVsyst execution version and reviewer version.
Require project files, dependencies, reports, exports, logs, and variants.
Reopen the delivered package and reproduce headline outputs before acceptance.
Separate model execution from independent assessment and contractual reliance.
Never choose a provider because its annual yield is highest.

Define the Purchased Decision First

A model can be internally consistent yet unfit for the decision. A preliminary layout may support option screening. It may not support an EPC guarantee or lender review.

Use this scope map before issuing an RFQ.

Purchased work	Primary purpose	Typical evidence need	What it does not become automatically
Concept simulation	Compare early layouts or equipment concepts	Preliminary coordinates, resource basis, geometry, equipment candidates, and stated assumptions	Detailed engineering or final production forecast
Bid model	Support a commercial or EPC bid	Bid layout, equipment, grid limits, scope, loss basis, and contract assumptions	Independent opinion for an owner or lender
Design-stage model	Reconcile current engineering decisions	Controlled layout, stringing, equipment, cables, transformers, controls, and operating limits	Structural, civil, electrical, or grid approval
Investment model input	Supply energy values to a financial model	Decision-grade resource, design, losses, variants, QA, and reliance definitions	Financial advice or guaranteed cash flow
Independent EYA	Provide a separate energy opinion	Independent resource and model review, uncertainty method, professional judgement, and defined reliance	A basic software execution task
As-built or operating model	Compare current configuration with measured operation	As-built records, commissioning data, event logs, meters, availability, and maintenance history	A warranty decision without contract and measurement review

The governing contract should state who may rely on the result. It should also identify liability limits and permitted uses. A file described as “bankable” has no defined value without those terms.

PVsyst itself does not approve financing. A lender, investor, owner, independent engineer, or insurer may set its own review requirements. Confirm them before modelling.

Issue a Controlled Input Register

The input register is the model’s audit trail. It should exist before the first accepted run.

Use one row for every material item.

Register field	Required entry
Input ID	Stable identifier used in comments and change logs
Model area	Resource, geometry, equipment, loss, control, output, or commercial interface
Parameter	Exact input name and intended model location
Value and units	Approved number, category, file, curve, or configuration
Source	Survey, drawing, datasheet, contract, weather product, study, or approved instruction
Source date and revision	Exact issue used for the baseline
Owner	Party responsible for the evidence
Status	Approved, provisional, rejected, missing, or superseded
Coordinate and time convention	Datum, projection, latitude and longitude format, time zone, and interval convention where relevant
Uncertainty or limitation	Known data limit without invented precision
Model treatment	Direct entry, transformation, derived value, default, or scenario
Reviewer disposition	Accepted, comment open, or revision required

Do not hide a default inside the model. If a default remains, identify it by screen, field, value, and reason. State whether it is accepted for the decision stage.

Freeze the baseline input register before the accepted simulation. Give the freeze a revision and date. Later changes should point to the affected input IDs and variants.

The provider may identify missing inputs during setup. The buyer or authorised reviewer should approve their treatment. Silence is not approval.

Control Weather and Resource Evidence

PVsyst’s current weather documentation calls weather data the starting point of project evaluation. It also identifies weather as a main source of uncertainty.

PVsyst uses .MET files for hourly or sub-hourly weather data. Its documentation distinguishes TMY, synthetic, time-series, and imported files. These labels describe data form, not fitness for a specific investment decision.

The resource register should record:

site coordinates, elevation, datum, and time zone
weather provider, product, edition, and access date
source period and whether the file is TMY, synthetic, or an actual-year series
GHI, DHI, temperature, wind, albedo, and any other supplied variables
interval length, timestamp convention, time shift, and missing-data treatment
source-file checks, import method, conversion settings, and resulting .MET file
validation or comparison with other suitable sources
any site measurements, cleaning, quality control, and period coverage
long-term adjustment method, reference period, and responsible analyst
reason the accepted weather basis fits the purchased decision

Do not call a synthetic or TMY file measured site data. Do not treat one operating year as a long-term forecast without a justified method.

PVsyst 8.1 documentation describes sub-hourly simulation and limited routes for creating sub-hourly weather files. A buyer needing that interval should require the exact software version, source interval, import route, variables, and exported results.

Weather comparison can reveal material differences. It does not decide which source is correct by itself. A qualified resource analyst should address bias correction, ground data, spatial resolution, interannual variability, and long-term adjustment where the decision requires them.

Freeze Geometry, Horizon, and Near Shading

Coordinates alone do not define geometry. The model needs a layout and a traceable spatial basis.

Record the source drawing, survey, surface model, imagery date, coordinate system, north reference, elevation convention, and layout revision. Identify roofs, terrain, rows, trackers, obstructions, setbacks, access paths, and reserved areas.

PVsyst documentation separates far horizon and near-shading work. The project tutorial treats the horizon as distant shading that acts globally on the array. It treats nearby objects through a near-shading scene.

The provider should state:

which horizon source was used and when it was measured or generated
which near objects and terrain surfaces are included
which objects are excluded and why
how the PV fields map to the engineering layout
which orientations, tilts, pitches, tracker limits, and backtracking rules apply
how module strings or electrical partitions map to the shading calculation
whether the scene contains simplifications that affect the purchased decision
which shading method and settings were used

Request the shading assets needed to reproduce the accepted variant. The PVsyst workspace documentation identifies .HOR horizon files and .SHD shading-scene files.

A model scene does not confirm buildability. Civil, structural, electrical, fire, access, planning, and construction reviewers still need their own evidence. Use the solar shading analysis guide for detailed shading-survey scope.

Match Exact Equipment and Stringing

Use the proposed manufacturer, model, revision, and applicable datasheet. A family name is not enough when electrical limits differ.

For modules, record rated power, technology, bifacial treatment if applicable, electrical coefficients, dimensions, series limits, and any custom definition. For inverters, record the exact model, AC rating, voltage limits, MPPT arrangement, current limits, efficiency data, power factor, reactive operation, and temperature behavior used.

PVsyst’s file inventory documents .PAN files for module definitions and .OND files for inverters. If the provider uses a custom or modified component, include the compatible file and source evidence.

The stringing register should reconcile:

total module count and installed DC capacity
modules per string and number of strings
inverter quantity and installed AC capacity
string allocation across inverter inputs or MPPTs
voltage checks at governing temperatures
current checks at the selected design conditions
unused, overloaded, or mixed inputs
orientation or block allocation
transformer and collection-system grouping
differences between the model and current engineering documents

PVsyst can help evaluate system behavior. It does not sign off electrical design. A qualified electrical engineer should verify code, protection, conductor, voltage, grounding, equipment, and grid requirements.

Make Every Loss and Operating Rule Traceable

Annual yield changes can result from model methods, physical assumptions, or operating rules. Do not accept a loss table without sources.

Model area	Evidence question	Useful controlled case
Thermal behavior	Which mounting, ventilation, temperature, and wind evidence supports the parameters?	Alternative approved mounting or thermal basis
DC wiring	Which lengths, sizes, resistances, routing, temperature, and topology were used?	Current design versus unresolved design
Module quality and mismatch	Which procurement, flash, tolerance, binning, ageing, or test evidence applies?	Contractual equipment case versus provisional case
Soiling	Which site, cleaning, rainfall, seasonal, or operating evidence supports the profile?	Approved operating plan alternatives
Availability	Which equipment and grid events are inside the definition?	Contract definition versus operating-plan case
Auxiliary consumption	Which loads, schedules, and supply points are included?	Current load schedule versus pending schedule
Transformer and AC collection	Which designs, test data, loading, and conductor calculations apply?	Bid design versus issued design
Clipping and grid limit	Which inverter, export, plant-control, and interconnection limits govern?	Accepted grid limit alternatives
Curtailment	Which contractual or study evidence defines occurrence and treatment?	Named dispatch scenario, not an invented probability
Degradation	Is it inside the simulation scope or applied later in another model?	Separate agreed annual profiles

Distinguish an input loss from a calculated result. Do not add the same effect twice in PVsyst and a downstream financial model.

Define the energy boundary. State whether the accepted output is at the module, inverter, low-voltage bus, high-voltage side, revenue meter, or another point. Reconcile auxiliaries and transformer losses with that boundary.

Availability, curtailment, and degradation often need time-dependent treatment outside a simple annual percentage. The contract should identify the method and owner. It should also state where the adjustment occurs.

Use Variants and Sensitivities With Discipline

The current project definition explains that one project can hold several calculation variants. PVsyst uses a .PRJ project file and .VCi variant files.

Build a named hierarchy:

Reference variant for structural model setup.
Approved baseline variant for the purchased decision.
One controlled case for each unresolved material input.
Combined downside or upside cases only when their relationships are justified.
Design-change variants linked to the change register.

Each variant name should state its purpose. Its description should reference changed input IDs. Avoid names such as Final, Final2, or Best.

A sensitivity is not automatically a probability. A high and low weather case does not become P90 and P50 because of its label. Probability estimates require a defined dataset, method, correlations, uncertainty terms, and qualified review.

The P50 and P90 explainer owns probability terminology. The energy-yield assessment service guide covers independent assessment scope.

Specify the PVsyst Version and File Package

The PVsyst documentation home identified version 8.1 on 10 August 2026. Do not write only “latest version” in an RFQ. Record the full version and patch used for execution.

PVsyst documents file-format changes at versions 6.40, 6.60, and 6.80. It states that new formats at those changes are incompatible with older versions. Its file-format page also says internal files should not be manually edited.

Agree these controls before work begins:

execution version and patch
buyer or reviewer version and patch
whether opening will convert any file
preservation of the original delivered package
agreed export or compatibility method
treatment of custom components and user assets
responsibility for any licence needed to reopen the work
acceptance procedure if the reviewer cannot use the execution version

The official file inventory shows that a project may depend on several files. A PDF is not the editable model.

File or artifact	Acceptance purpose
`.PRJ` project	Preserves central project definitions
`.VCi` variants	Preserves specific configurations and saved results
`.MET` weather	Preserves the simulation weather basis
`.SIT` site	Preserves site and monthly weather definitions where used
`.HOR` horizon	Preserves the far-horizon definition where used
`.SHD` scene	Preserves the near-shading scene where used
`.PAN` and `.OND`	Preserves custom or modified module and inverter definitions
Workspace export	Can collect related assets for transfer, subject to agreed scope
Reports and loss diagrams	Provide readable review records for named variants
Time-series exports	Support downstream analysis at named interval, variables, and units

Require a file inventory with hashes. Scan the package for malware under the buyer’s security procedure. Store an immutable received copy before anyone opens or converts it.

Write a Deliverable Matrix

“PVsyst report included” is not a deliverable specification. Use a matrix.

Deliverable	Required detail	Acceptance evidence
Input register	Sources, dates, owners, status, units, and model treatment	Reviewer closes all material items
Assumption log	Defaults, derived values, gaps, and approvals	Every material assumption has disposition
Baseline model	Named project and accepted variant	Headline values match the approved report
Sensitivity set	One purpose and changed inputs per case	Change matrix reconciles every variant
Editable files	Project, variants, dependencies, and custom assets	Reopen test passes in the agreed version
PDF reports	Named variant, date, version, parameters, results, and loss diagram	Report matches delivered files
Data exports	Exact variables, units, interval, time zone, sign, and missing-value treatment	Row count and totals reconcile
QA record	Checks, warnings, findings, corrections, and approver	No unexplained material warning remains
Comment log	Reviewer comment, owner, response, evidence, and closure	All acceptance comments are closed
Change log	Baseline, revision, reason, inputs, variants, outputs, and approval	Accepted revision is unambiguous

PVsyst’s results documentation describes reports, monthly results, selected detailed values, tables, graphs, and loss diagrams. It does not mean every desired variable is included automatically.

Specify the requested variables and interval. State the time zone, timestamp position, units, decimal convention, sign convention, and energy boundary. Reconcile monthly totals with the accepted report.

Score Providers on Process, Not Yield

Give every bidder the same input pack and questions. Allow bidders to identify gaps without changing the baseline silently.

Score area	Buyer evidence
Scope reading	Written boundary, exclusions, decision, stage, and reliance understanding
Modeller competence	Named modeller, relevant experience evidence, and reviewer arrangement
Input control	Sample register, source treatment, question quality, and approval method
Version control	Exact software version, file plan, conversion policy, and archive method
Model method	Clear geometry, equipment, loss, control, and variant approach
QA	Independent internal check, warnings review, capacity reconciliation, and energy balance
Handover	Complete editable package, reports, exports, inventory, and hashes
Reproducibility	Demonstrated reopen and headline-output test
Review response	Comment workflow, revision discipline, and named closure authority
Security	Access, transfer, storage, subcontractor, retention, deletion, and incident terms
Commercial	Current price, tax, payment, schedule, revision allowance, and change method
Reliance	Permitted use, liability, exclusions, insurance, and governing contract

Do not award work based on the largest forecast. A higher number may reflect a better design, different evidence, missing loss, changed boundary, or error. Require a difference register when bids disagree materially.

Prices and turnaround depend on project scale, model maturity, shading detail, number of variants, data cleaning, exports, review rounds, and reliance. Obtain a current written quote. This guide invents no market rate or schedule.

Run a Reproducibility Acceptance Test

The buyer’s reviewer should use a clean workspace or controlled review environment. Preserve the received archive before importing it.

Use this acceptance sequence:

Verify file inventory, hashes, version statement, and scan result.
Import or open the package in the agreed PVsyst version.
Record conversion prompts, missing files, substituted components, and warnings.
Confirm site, coordinates, weather file, period, and time treatment.
Confirm geometry, orientation, horizon, near shading, and layout revision.
Confirm module, inverter, quantities, stringing, DC capacity, and AC capacity.
Trace every material loss and operating rule to the input register.
Run the accepted baseline without unapproved edits.
Compare headline energy, performance indicators, and loss diagram with the delivered report.
Reconcile requested time-series totals to monthly and annual values.
Open each required sensitivity and verify only approved inputs changed.
Save review findings in the comment log and require documented correction.

Set tolerances in the contract before delivery. A tolerance should reflect the output, version, rounding, and intended use. This page supplies no universal numeric tolerance.

Inspect warnings and inactive features. Confirm whether a stated input affects the accepted variant. A populated field may be outside the active model path.

Compare the energy balance from resource through the defined output point. Investigate unexplained gain, duplicated loss, missing transformer, wrong capacity, or inconsistent time-series sum.

Control Comments, Revisions, and Security

Use one comments register. Each entry needs an ID, date, reviewer, model area, finding, requested action, owner, response, evidence, affected files, and closure status.

Do not resolve comments only in email. Update the controlled register and link the accepted revision.

Every model revision should state:

prior baseline and new revision
reason and approving authority
changed input IDs
changed files and variants
effect on headline outputs and material losses
new or closed warnings
reviewer disposition

Store the received archive, working copy, accepted package, reports, exports, logs, and approvals under retention rules. Define access by role. Address client data, surveys, drawings, equipment files, weather licences, and subcontractor access.

Deletion after retention should be verifiable where the contract requires it. A provider’s use of PVsyst does not establish its cyber controls.

Separate Model Execution From Professional Reliance

A PVsyst modeller configures and runs a model. Other work may require separate qualified professionals.

A resource specialist reviews weather representativeness and long-term adjustment.
An electrical engineer reviews equipment, stringing, protection, cables, transformers, and grid compliance.
Civil and structural professionals review terrain, foundations, structures, drainage, access, and buildability.
A performance specialist reviews loss methods, uncertainty, validation, and operating evidence.
An independent engineer or lender adviser sets reliance and review requirements.
A finance professional maps accepted energy cases into cash flow.
Legal and insurance reviewers address liability, guarantees, licences, data, and permitted reliance.

The PVsyst report and bankability guide covers report packaging and reliance questions. The solar simulation accuracy comparison covers validation boundaries. The commercial solar design services guide covers wider engineering procurement.

An actual performance guarantee needs a separate contract. It should define the measured quantity, meter, period, corrections, availability, curtailment, weather normalization, exclusions, test method, threshold, and remedy. A simulation report alone supplies none of those promises.

Evaluate Heaven Designs With the Same Gates

Heaven Designs’ solar pre-design page says it uses energy tools such as PVsyst depending on the project. It lists PVsyst reports and shading analysis within its published service scope.

Its sample-request page lists PVsyst reports among available samples. These are provider-published claims, not proof for a buyer’s project.

Ask Heaven Designs and every alternative for the same items:

named modeller and checker for the proposed scope
exact PVsyst version and licence responsibility
project-stage-matched sample with permission to review
controlled input and assumption process
baseline, sensitivity, and change-control method
complete editable file and dependency handover
reopen and reproducibility acceptance
independent EYA or reliance boundary
security, subcontractor, retention, and deletion terms
current schedule, price, tax, revisions, and payment terms

Do not give Heaven Designs extra score because of the relationship. Do not exclude a better-supported alternative. Select the provider whose evidence passes the stated decision gates.

Keep This Page From Overlapping Adjacent Guides

This page owns procurement of reproducible PVsyst model execution. It does not own every adjacent decision.

Need	Use this page for	Use the adjacent guide for
PVsyst report	Required model files and reproducibility	Report review and bankability boundaries
Independent EYA	Separate model-execution scope	Independent energy-yield assessment
P50 and P90	Avoid unsupported probability labels	Probability terminology and method
Shading	File and input controls	Detailed shading-analysis method
Simulation software	PVsyst handover requirements	Solar design software concepts
Engineering	Model boundary and reviewers	Outsourced solar design services
Financial model	Accepted energy-case handoff	Solar financial-model replacement

SurgePV is a solar design and proposal platform. It is not PVsyst, an independent EYA, a lender, or a performance guarantor. Review the SurgePV solar-design workflow only for its own documented scope.

Frequently Asked Questions

What should a PVsyst simulation service deliver?

The contract should list the accepted software version, editable model package, reports, exports, input register, assumption log, QA record, sensitivity cases, and comment log. Define each file and output against the project decision and stage.

Is a PVsyst report the same as an energy-yield assessment?

No. A PVsyst report records model parameters and results. An independent energy-yield assessment may add resource analysis, methodology, uncertainty, professional judgement, reliance, and review duties under a separate scope. Define the required opinion, reviewer, liability, and permitted reliance in the contract.

Which weather data should a PVsyst model use?

There is no universal best file. Record the site coordinates, source, product, edition, period, variables, interval, time convention, processing, gaps, validation, and long-term adjustment. Compare suitable sources where the decision warrants it. Do not treat a default, synthetic year, or single year as automatically representative.

Do I need editable PVsyst project files?

Require them when independent review, later updates, or reproducibility matters. The handover may need project, variant, weather, shading, site, and custom component files. State the accepted PVsyst version and test that the reviewer can reopen the package without missing dependencies or unintended conversions.

Can an older PVsyst version open every delivered project?

No. PVsyst documents file-format changes that are incompatible with older versions. Agree the execution version, reviewer version, and compatibility plan before work starts. Do not assume that a PDF report or a manually edited internal file can replace a working project handover.

How should PVsyst sensitivities be designed?

Change one material unresolved input or a controlled group while holding the baseline traceable. State the source and reason for every alternative. Label each case as a scenario unless a qualified uncertainty method supports a probability. Do not call arbitrary high and low cases P50 or P90.

Does a PVsyst simulation guarantee solar plant performance?

No. The model calculates outcomes from defined inputs and methods. It does not verify every site fact, control construction, predict outages, assure weather, create lender acceptance, or guarantee production. Any performance guarantee needs separate contractual definitions, measurement rules, exclusions, correction methods, and remedies.

How should buyers compare PVsyst service providers?

Issue every provider the same controlled input pack. Score scope understanding, modeller competence, assumption discipline, version control, QA, handover, reproducibility, review, security, schedule, price, and reliance terms. Investigate material model differences instead of selecting the highest annual yield.

How should Heaven Designs be evaluated for PVsyst work?

SurgePV and Heaven Designs have a related-party commercial relationship. Treat its published scope and samples as provider claims. Apply the same input-control, competence, version, QA, handover, reproducibility, reliance, security, schedule, and price gates used for every provider before awarding work.