André Mermoud

Yes it is possible. In the EXCEL document, be sure to specify a filename for each hourly file (with extension .CSV)

When defining the batch mode, you are prompted for defining the variables to be put in your output file. And in the batch definition (EXCEL) you have to define the name of the CSV file to be created.

Very strange. This importing tool with formatting works quite well. How are your data interpreted in the preview when defining the format ? In your definitions, is the comma defined as the separator ? Please send your source data and *.MEF formatting file to support@pvsyst.com

On the I/O diagram, I can't read the variable you have put as y-axis. If it is the EArrMPP, it is not affected by the behavior of the system (i.e. the full battery). However according to the loss diagram, the behavior of you system seems very strange. Please send your whole project (using "Files > Export project") to support@pvsyst.com

The relevant time is the time for the calculation of the solar geometry (should be in the middle of the accumulation interval). Yes indeed, this will have an impact on the diffuse evaluation, and much more on the transposition model.

PVsyst works with hourly meteo data. If there is fog, this will be included in these input data.

I don't know this error. Please send your project to support@pvsyst.com.

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