André Mermoud

Yes, in the simulation there is a threshold in the incident Irradiance, fixed at 10 W/m2, under which the system is not computed. Please observe that even by a very covered weather, we rarely observe less than 40-50 W/m2. Therefore this threshold is quite reasonable. However this loss should indeed be accounted in the GIncLss variable. It seems this is not the case, I will check in the simulation.

For the first question: this strategy of choosing one tracker in the middle of the array is indeed an approximation suited for "big" tracking arrays; it is used only for the evaluation of the shading factor applied to the diffuse component. The impact of other environmental objects is supposed to be not very significant for the diffuse (which is probably an acceptable assumption). But the calculation of the shading on the beam component takes indeed these objects into account. The backtracking calculation is dependent on the neighbour trackers. This algorithms of this calculation are difficult to establish, and only suited for well delimited conditions like regular tracker arrays. We didn't develop backtracking algorithms for neighbour trackers which are, for example, at different altitudes. This is the reason why PVsyst requires that all tracking arrays are identical and "regular". By the way, if we had different backtracking conditions for different parts of the system, the plane orientation would be different for each of these groups of trackers at a given time. We have not developed such a complexity in the simulation of tracking systems up to now.

In the present time, the "Stand-alone" part is very simplified. It is not possible to define sub-arrays, multi-orientations, and so on. I am completely rewriting this part of the program, which will include most of the new properties developed for the grid-connected systems since the last years. This new version should be available within some few months. However it is not possible yet to define a grid-connected system with storage. See our FAQ Can I include a battery in a Grid-Connected system?

This choice will be available in the next version 6.39, to be released soon.

In monthly values, you can simply redefine manually the values in the "Geographical sites" dialog, and then use the synthetic generation. On hourly values, this doesn't make sense. You cannot average hourly values of 2 different meteo sources; when averaging hourly data of a clear day with a covered day, you will obtain a sequence of "average" hours without meaning.

It is indeed possible to ask for the construction of CSV files of houly results in the batch mode. This will produce one file for each run.

There is no limitation on the energy loss of course. In the daily I/O diagram, the plateau we see in battery systems corresponds to full battery periods, i.e. when the battery is full at the end of the previous day: in this case only the required daily load during 24H may be produced/used by the array. Now in other circumstances, the battery may be empty at the beginning of the day. In these cases the solar array will yield the 24H load and also fill the battery, which corresponds to the points above.

I don't understand well the question. Please have a look on the FAQ What is the shading loss "according to module strings" ? The parameter "Fraction for Electrical effect" is only related to the calculation "According to module strings". It doesn't make sense in the "Modulelayout" calculation.

The Global incident is just the result of the transposition of your meteo data (GlobHor) to your tilted plane. With tracking arrays, when using backtracking, this could change when you change the width of the trackers or the pitch between trackers, because the backtracking conditions will vary. In any other case, the Incident Global has no relationship in any way with the rest of the system, such for example the AC capacity.

When performing the simulation, PVsyst checks the compatibility of the parameters between different parts of the program. Namely the parameters specified in the 3D part should match the parameters of the "Orientation" part. However I don't see how you do a change of the axis tilt in the batch mode: this parameter is not proposed as a modifiable parameter.

Please explain the messages you have obtained.

I can't say anything without a detailed description of such devices.

We have indeed to review the treatment of the transformer losses in a more detailed dialog. This is on our todo list. However please see our FAQ How to determine the parameters for the transo losses ?

I have indeed changed some behavior for the Pthreshold in the version 6.37, and this warning for PThres=0 is an unexpected consequence, sorry.... With this error the inverter dialog may crash (especially when openting the Efficiency page). For avoiding this you should put a not null value for Pthresh, and save the OND file as a new file in the database. This will be of course be corrected in the next version 6.39.

In PVsyst, you can get meteo data for anywhere on the earth. See our FAQ Which meteo data are available in PVsyst ? Now if you want very specific and good data, you can get them from companies like SolarGIS or 3Tier. But these are for pay.

Yes, this is the correct way of estimation the global irradiance with shadings on the plane.

The Focalization loss arises indeed when the trackers are not pointing to the sun. - In the simulation, this arises when the sun is outside of the tracking limits. - In the reality, this could be produced by any misrunning of the tracking system. Remember that with 500x concentration, the acceptance angle is less than 1° or even 0.5°.

As a general definition: Efficency = Pmpp [W] / (Incid. Irrad [W/m2] * Ref area [m2]). The reference area may be either the module area (usual module efficiency) or the sensitive area (which will give a "cell" efficiency, more related to the technology). In the specific case of the STC efficiency mentioned on the loss diagram: - Irrad = 1000 W/m2 - Pmpp = Impp * Vmpp issued from the application of the model at 25°C

The annual variability is the RMS of the normal distribution of your annual data. If you have 10 years of meteo data for your site, you can import them (create 10 *.MET files in PVsyst - each MET file is for one year). Then since version 6.37, you have a new tool in "Meteo tables and graphs" > button "Compare", for comparing different meteo files and establish the RMS of their distribution.

PVsyst works on an hourly basis. You can import 1-minute data, but they will be converted into a meteo hourly file *.MET, which is the only basis for PVsyst simulations.

For the first problem: the version 5 of PVsyst is not able to recognize network paths (beginning by \\). You should put your source file in a path beginning by a disk letter. For the second problem: The TMY format follows a very strict definition. PVsyst only recognizes files following the TMY2 or TMY3 protocol definitions. But perhaps something was not up-to-date in this very old version 5.59. You should update to the version 5.74.

Sorry, we will correct this in the next version 6.38, very soon. Please try to print to a PDF document, it seems that this problen doesn't appear in this case.

This arises at the first use of the version 6.35. You should simply create a new workspace. However this has been corrected in the version 6.37, please update.

Please explain exactly what you are doing, in which part of the program you are when this error occurs. Please send a screenshot of the error message (full screen) to support@pvsyst.com.

Some parts of the software are translated in different languages, including Spanish (switchable within the software). However this is not complete, we have still to translate many parts. But sorry, we don't intend to issue documentation in other languages than English in the present time.