André Mermoud

The hourly values are obviously part of the input Meteo hourly data (*.MET file). Now if you only avail of monthly values, PVsyst will use a specific model, the synthetic generation. Please see our FAQ What are the Synthetic hourly data ? Now for very special uses (especially for sizing tools) PVsyst sometimes uses an approximation which is a distribution established by the Clear day model, eventually renormalized to a required daily value.

This is indeed a problem which arises with some computers. It is related to the Graphic card, which is now used by the 3D editor. Some old drivers of the graphic card don't support the functions that PVsyst is using, without noticing this to the program You can either pass to the next version 6.61, or update the driver of your graphic card (this doesn't work in any case, very mysterious...).

This was indeed an error with not-south tracking systems, which has been fixed in the version 6.53.

Are you sure that you re-open the version 6.61 and not a version below 6.39 ? If so, please send us one of the *.OND file that you cannot open with the version 6.61. (send it to support@pvsyst.com).

You can calculates these values in this approximate way if you want. However PVsyst doesn't need these VMin and VMax values during the simulation, it calculates the effective Vmpp at each operating hour from the one-diode model. It only needs these values (as well as the Voc(TMin) at the desigh time, for the determination of the minimum and maximum numbers of PV modules in series. Please see the help "Project design > Grid-connected system definition > Array voltage sizing" for a complete explanation of this sizing process and the corresponding tool. And our FAQ How to adjust the design temperature ?

PVsyst doesn't use this approach of NOCT, which is extremely confusing. Please see our FAQ How to adjust the NOCT value? and also How is evaluated the module temperature during simulation ?.

You are right. This was a fundamental question when I did this difficult choice (perhaps 15-20 years ago). This was the case in very old versions (up to V 2.2 ?), but this lead to contradictions in the results interpretation and losses evaluation. However I don't remember exactly which ones, sorry. Probably with irradiance data already including the horizon substraction (i.e. measured data at a given place), when the horizon of the system is not the same. Or concerning the calculation of the effect on the diffuse component. NB: With the present choice, the horizon loss is included in the PR evaluation (referenced to the GlobInc value), which is not optimal indeed.

In PVsyst all results values are for the global system. The GlobInc value is the average of the 3 GlobInc values, weighted by the nominal power of each sub-array.

You are probably using SolarEdge optimizers with fractional inputs. There is a bug with these devices and this situation in the verson 6.60, which has been corrected in V 6.61.

No. In PVsyst the results are only available as global for the whole system. If you want an evaluation of each subsystem, you have to perform an independent simulation for each one.

Technically, I don't see how your system will work. If it is really forbidden to reinject electricity into the grid, your system will only run when the full production is indeed consumed internally. As soon as the consumption goes below the inverter nominal power, unless there is a very special control device within the inverter for running at partial load (I don't know any device of this kind), this will stop working. Now the unavailability tool is not suited for this use. You cannot define more than 5 periods. The only way is the definition of the load in hourly values, and discard the energy reinjected into the grid. In this case you can recalculate the PR by yourself according to your hypothesis. You can also create an hourly file when performing the simulation, and calculate your balances by yourself in EXCEL.

Please check that you don't have a too high Vmpp value. See the FAQ Why the overload loss sometimes increases significantly without reason ?

This is not the right way of taking the not-used energy into account. You should use the option "Net metering", and consider the energy injected ito the grid as lost energy.

Please simply read my previous post

This has been fixed in the version 6.60.

We will not create a "Major" version 7. Our policy is now to improve PVsyst progressively, in an incremental way. Now the import of Sketchup and AutoCAD files is now possible in the version 6.60 (considered as a "Major" version by the introduction of a professional tool "OpenGL" for the 3D editor).

In the present time, you have the choice of taking the losses into account either before or after the transformer. We are deeply renewing this feature, and this will be improved in a next version.

The Inactive band is the extension of the mechanical structure, with respect to the PV module itself. NB: the bottom Inactive band is not significant in the "Unlimited sheds" calculation: the mutual shadings begin when the bottom of the PV modules become shaded, whatever the bottom inactive band.

The power derate of PNom(ac) as function of the temperature may be specified in the inverter's definition. The fan's consumption should be specified as "Auxiliary Loss" (in the "Detailed losses part). The inverter temperature conditions during the simulation may be specified in the "Miscellaneous tools" part.

This is corrected in the version 6.61.

In PVsyst V 6, you can define up to 8 orientations. In the version 5, this was limited to 2 different orientations only.

In PVsyst you can define sub-arrays for at most 8 orientations. However this is not possible with stand alone systems yet.

The pitch is the distance between identical points of 2 rows (for trackers: from axis to axis, for sheds: from base to base).

You can read my previous post, and also our FAQ How is the database of PVsyst updated?

Sorry, there is no progress with this in the present time.