André Mermoud

Basically the TArray corresponds to the cell temperature. If some people make a difference between Cell and Module temperature, this is mainly related to the way of measuring it. Please remember that a thermometer always measures its own temperature. If you put a sensor behind the PV module without insulating it, there will be a thermal flux between the cell temperature and the sensor, and from the sensor to the ambient, so that the sensor measures an intermediate value (not well determined). If you put some insulation, you block this flux and the sensor will measure the "real" cell's temperature (thermal equillibrium conditions). For such a measurement, after some optimizations at the University of Geneva (using a special module with an integrated sensor directly on the cell within the encapsulation), we propose to cover the sensor with a piece of polystyrene of about 7 x 7 x 1 cm3. This size ensures a compromize, i.e. a sufficient insulation, without perturbating too much the local Cell's temperature.

The definition of the SOC (State of Charge) is 0 for a completely empty battery, and 1 (100%) for a fully charged battery. A SOC of 50% means a half-charged battery.

In your comparison, the second option certainly gives a higher yield (E_Grid). Please check. However if you have identical PV model behaviors, the PR should be identical, as you have different Nominal powers, compensated by different efficiencies. Except if you have overload losses. In this case, you will have higher overload losses with the second option, and therefore lower PR. NB: Please remember that the PR doesn't depend on the Efficiency. A higher efficiency means a lower area for the same nominal STC power, and therefore a lower Gincid. This result may be biased: - If the low-light performance of both modules is not identical (essentially depending on Rserie) - If the PNom of both modules (370 and 365) are not rigourously equal to the Imp * Vmp product at STC. Please see the FAQ Why is the Pmpp of my module different of the specified value ?

We update the database using the requests of the manufacturers, and publish it with each new issue of PVsyst. We can't of course follow all the new products of all manufacturers. It would be a very big task, and we don't want to include data without the acknowledgement of the manufacturer. Therefore, please ask your provider/manufacturer to take contact with us for updating the database. The database of PVsyst holds now about 15'000 PV modules and 5'000 inverters. Nevertheless you can easily create your own components by yourself. The easiest way is to choose a similar existing device in the database, modify its parameters according to the manufacturer's datasheets, and save it under a new name, therefore creating a new file in your database. For Crystalline modules, except Isc, Vco, Impp and Vmpp, nb of cells in series and module sizes, you can let all the other parameters (mainly Rserie, Rshunt, Rsh(0) and RshExp) at their default value. You have a checkbox near to each parameter for retrieving the values proposed by PVsyst.

In PVsyst the Voc(temp) is calculated by the one-diode model. The expression given here is a direct result of the "pure" one-diode model: you can easily get it by simply writing the one-diode model equation for I = 0 PVsyst adds some corrections to this "pure" model, so that the result may be slightly different.

Before defining the Bi-facial tool, please make sure that your system is really compatible with a tracking array, horizontal axis orientated at -9°: - In the orientation part "Horizontal axis, unlimited trackers", or: - In the orientation part "Tracking, tilted or horizontal axis", - And in the 3D part you have to define an array with Azimuth = 0 in the tracking parameters, and rotate this whole "rectangular" object by -9° in the scene.

This information is now part of the project: in the project's definition dialog, button "Project's settings". The value in the hidden parameters is just an initialization for new projects.

The agreement between the simulated data and measured ones highly depends on the meteo data. And as a second cause, on the parameters you have chosen for the simulation. They may also be due to an erroneous measurement. In good measurements and simulation conditions, the accuracy of the simulation is usually below some few percents. Please see the FAQ What is the accuracy of the simulation results ?

You can simply save the whole workspace \PVsyst660_Data\. You will find its location in the main menu "Files > Workspace" dialog. NB: Remember that at each new installation (update), PVsyst automatically saves a full copy of your present workspace.

Please send the following files to support@pvsyst.com: - your original data CSV file, - the *.SIT file of the location of your data (that you are using for the import), in the directory \sit\ - the MEF file (formatting file) you have defined for this import, that you will find in the directory \Meteo\ - the MET file you have created.

When you open the dialog "Import ASCII Meteo files", in the first frame "Ascii Source file", make sure that you have correctly defined the site of your data.

Yes, when you have a tilted base on your PV tables, the plane orientation changes (tilt and awimuth). See our FAQ With sheds on a tilted roof, PVsyst changes my orientation.

In "Databases > Meteo Tables and graphs" tool, you can create a table in hourly values, and export this table as a CSV file (menu "Export") You can reupload this file using "Databases > Import ASCII meteo files".

This representation is quite correct. The efficiency is defined as the Pout / Pin ratio. Now if the Pout is limited to the PNom value, the efficiency Pout/Pin will obviously diminish above Pout, in the way shown on the graph. Now for the "unreasonable" Overpower loss: - Please remember that the value in the sizing tool is a rough pre-evaluation, just for helping you to design your system. The reliablel value is the result of the simulation. See the FAQ Why the overload loss is not the same at designe time as in the simulation ? - In some conditions (high array voltage), the overpower may significantly increase. See the FAQ Why sometimes the overload losses increase significantly ?

These values are simply the plane tilt and plane azimuth of your tracker, at a given time. I don's see in which way they are erratic: these are calculated from the tracker's position (phi angle, axis tilt and azimuth, depending on the tracking mode) and are quite real angles.

I really don't understand how you got this result. The Sandia model is hard-coded in PVsyst, the values are unmodifiable and give a result very close to the normal Fresnel's model. This curve is probably a user-defined IAM profile, specified in your PV module, with completely erroneous parameters. Sandia model and Fresnel, normal glass and with AR-coating

This is indeed the extra-terrestial irradiance, i.e the irradiance outside of the atmosphere. This is equal to the solar constant (1367 W/m2), which is indeed not a constant, but a yearly average. The extraterrestrial irradiance varies by about +/-3% around this value due to the earth's trajectory ellipticity. This "normal" extraterrestrial irradiance has to be multiplied by the sin(HSol) for representing the Horizontal global. The extraterrestrial value is used for the evaluation of the clearness index Kt, involved in the Transposition and Diffuse models.

The difference is 0.004% (equivalent to 4 cents on a sum of 1'000 euros). This may be a rounding effect, or an edge value in the shading's calculations. Such differences may arise in simulations. We could pass some hours (or dozens of hours) for understanding such "problems", but we have more urgent priorities.

This is very strange indeed. With which version of PVsyst ? Please check that you have defined a reasonable value in the Project's settings parameter: in the project's dialog, button "Project settings", page "Other limitations", item "Discriminating orientation difference between shading planes". The default value is 1°. If this is OK, please send your whole project (using "Files > Export project" in the main menu), to support@pvsyst.com.

This is indeed not possible. PVsyst requires to ask for creating an hourly file explicitly before simulation, for avoiding filling your disk with a lot of dummy files. Now if you have several runs with different parameters for optimizations, you are advised to use the Batch mode. Here you can choose getting the hourly CSV file for each simulation. Your list of parameters is kept with your Variant file, and eventually for the next file you will create/open. You can also save it as a template, for reusing it in any other project.

No, it is not possible. In the present time the bi-facial model is only useable with horizontal trackers. An extended model will not be available in PVsyst before several months.

Yes of course. This is a question of averaging mode. The basic hourly values are TArray. In the "TArray" variable: we average these values over the operating periods, we get an average module temperature which has not a big meaning. In the "TArrWtd" variable, we calculate an average weighted by the GlobInc value. This averaging mode is much more significant, it is required for the evaluation of a weather-correctd PR. Therefore for these variables, only the daily or monthly averaged values are different.

It is sometimes useful to read the Help ... See "Project design > Bifacial Systems > Bifacial systems procedure"

No, when you are using a module with bifacial capability, it is not necessary to define a bifacial simulation. It is always possible to do a simple standard simulation: in the bifacial tool, choose "Don't use in the simulation".

No, you should evaluate this by yourself. The soiling loss parameter is already extremely poorly defined (and not stable in time). Elaborating sophisticated corrections on such values doesn't make much sense.