André Mermoud

In your first question, I don't understand which "Default value" you are talking about. The "number of strings" in the width of the row: if you have one only module, it will be one. If you have 2 modules in width, this will be two if the modules belong to 2 different electrical strings, and one if they belong to the same string. The cell's width is 15.6 cm if you have 6" cells, and 12.5 cm if you have 5" cells. I think you did not understand the meaning of the "fraction for electrical effect". When you calculate shading losses, you have the "linear" losses" (the real deficit of irradiancre due to shades) and the "Electrical losses" corresponding to the electrical effect due to string connexions (i.e. the yellow part on the 3D shading animation). The "Fraction for electrical losses" indicates to which extent the Yellow part is taken into account in the losses. For shed arrangement this fraction will always be 100% (i.e when the bottom cells row is shaded, there is no electrical production anymore for this string). Please see our FAQ How to evaluate the the effect of by-pass diodes in shaded arrays ?

These data will be difficult to accurately manage within PVsyst, as the time shift is highly varying along the year. This indicates that your datalogger's time reference has shifted, and the data are difficult to accurately recover (not possible in PVsyst). In this case the best choice would be to specify a time shift of around -15 min, so that the time variation of the data with respect to the average will be +/- 15 min. Now such a variation could be explaind by the fact that you imported the data using the "Solar time". Please make sure that you have specified "Legal time" in the second page of the import format.

Sorry, I don't understand well what you are doing. However mathematically, averaging PR for different periods doesn't make sense: you have to add the GlobInc and E_Incid values, and calculate the PR with these sums. Please see our FAQ "How is calculated the PR ?" Now I don't understand well why you have so low PR with low irradiations: for analyzing this you should study the detailed losses in hourly values.

The Clear day model shown in PVsyst gives a reference of the time at which the solar geometry is computed within the software. Imported data should match the internal time of PVsyst. This is usually a difficult question, explained in the help "Meteorological data > Hourly Meteorological Data > Time shift". When importing hourly ASCII files, PVsyst allows to specify a correction for the real measured data time with respect to the internal PVsyst time. But sorry, a correction of data written in UT is not yet available in this tool.

Yes, it is possible to simulate this situation. In the calculation version parameters, you have an option "net metering", which requires to define your self-consumption profile. After defining that, the simulation will evaluate de self-consumed energy, and the energy reinjected into the grid sepaprately. You can simply consider to discard the energy into the grid (E_Grid). However this cannot be explicitely shown on the report (the EGrid will always be mentioned in the result).

The replacement of data is indeed not implemented in this tool. I have done this for the next version 6.36, to be released soon. The missig values will be replaced by an average of the corresponding values of the previous and the next day.

In the version 6.35, we have implemented the new Meteonorm program (DLL) V 7.1. And we observe that indeed for some locations, this new DLL crashes. However this is not quite reproducible, and often trying a second time gives the correct result. We have to investigate this problem with the provider of the Meteonorm DLL.

Yes. In the menu of the 3D editor, you have an option "Tools" / "Ignore interpenetration of PV fields". This may result in errors when calculating the shades on the concerned table (not important im many tables).

Which tool are you using for importing these data ? Which value are you replacing (GlobH, DiffH, temp) ? How much values are to be replaced ? I think I have indeed not developed this replacement of values by a synthetic generation in the general ASCII importing tool. I have only done this with specific importing formats (like HelioClim or SolarAnywhere if I remember well). This means that the help is probably erroneous. However if you are not interested in the "integrated" results, you can either put null values, or simply suppress the concerned records in the ASCII source file and reimport it.

This depends on the locatione where you are of course. The Timezone is an official specification for a given location. The summer Time Zone is usually a shift by +1 hour. Usually PVsyst (and people dealing with meteo data) use to define the Winter time for the whole year. Now in Australia there are half-hour (and even quarter hour?) time shifts. There may be errors either in the Meteonorm data, or perhaps also in the SolarGIS data. The important thing is that the hourly values are established for a given Timezone. If you change the Timezone you will have a shift in your data, with respect to the internal PVsyst time definition. You can analyze your data in "Meteo tables and Graphs > Check data quality", and here get explanations in the help by pressing F1 (Help: "Meteorological data > Hourly Meteorological data > Time shift").

This is a parasitic line appearing on the report by error. It is not significant. This will be repaired in the next version 6.36.

No sorry, this is not possible in the present time. The helios3D exporting tool to PVsyst doesn't define trackers, and it is not possible to convert tables into trackers in PVsyst.

Message en français: "Aucune imprimante par défaut sélectionnée". Sorry, this sometimes arises even if you have correctly installed printers (it is a Windows problem), and we don't know why. You can try to download the free tool PDFCreator (to be installed as a printer): http://www.pdfforge.org/products/pdfcreator and select it as default printer. To my knowing this works in any case. And after that every printer may again be recognized as default printer. Mysteries of Windows...

I had indeed defined an Axonometry view mode in a very old time (see the main menu "View > Specify observer's position"), but it seems that this functionnality has been lost along the evolutions of the 3D editor... We will try to correct this in a next version. We have also to analyze the problem of very long objects, distorted when far outside of the screen.

For a tilted plane, the isotropic diffuse component is indeed evaluated as the irradiances coming from the "orange slice" between the collector plane and the horizontal plane. The result of this integral may be calculated explicitely, it gives DiffPl = DiffHor * (1 + Cos(tilt)) / 2. This evaluation is done in the transposition model (see especially the Hay model). Now the shading factor is a corrective effect due to the shading of objects. If you don't have shading objects, you don't have any shading factor.

The albedo effect corresponds indeed to what you would see across a window. However this would correspond to a vertical PV plane (façade). The albedo contibution, as "seen" by the collectors, is proportionnal to (1 - Cos(tilt)). This means that: - for a vertical plane (Tilt = 90°), the contribution is 100%. - for an horizontal plane (Tilt = 0), the contribution is = 0. - for a 30° plane, it is 1 - 0.866, i.e. about 13.4%. - and for a 15° plane, it is reduced to 3.4%. NB: if you have a row-like (shed) arrangement, only the first row "sees" the albedo. The shading factor on the albedo component will be (n-1)/n (n= nb of sheds).

The albedo effect corresponds indeed to what you would see across a window. However this would correspond to a vertical PV plane (façade). The albedo contibution, as "seen" by the collectors, is proportionnal to (1 - Cos(tilt)). This means that: - for a vertical plane (Tilt = 90°), the contribution is 100%. - for an horizontal plane (Tilt = 0), the contribution is = 0. - for a 30° plane, it is 1 - 0.866, i.e. about 13.4%. - and for a 15° plane, it is reduced to 3.4%. NB: if you have a row-like (shed) arrangement, only the first row "sees" the albedo. The shading factor on the albedo component will be (n-1)/n (n= nb of sheds).

Nothing prevents you to run PVsyst V5 and PVsyst V6 in parallel on the same machine. Simply the data structures are not the same: you cannot use files created with the version 6 in the version 5 (but the inverse is possible: downwards compatibility). You can even run several Versions 6.xx simultaneously on the same machine. The installation process gives you the choice of "Parallel Install". However be careful: if you share the same data structure, some files created using a recent version may be in error with older ones.

OK. This line "Orientation #1" is irrelevant, and should not appear on the report. This is indeed a mistake. I will correct this for the next version 6.36.

I can't understand that. Please check your affirmation. And if the "error" persists, please give a full explanation of what you did or are doing, where the error appears, and join a screenshot.

Some answers to these numerous questions. 1. The help file still refers to functionality in the 6.24 version, such as the save mode - eg. "Mode and File definition page" In the latest version there is no option for copy of monthly tables after each simulation. This is an error in the Help file: this feature has never been developed. I probably intended to do so when writing the help. 2. In the save mode, there is a radio button option for "Save" or "Save As" - I assume this is to over write or save new VCi files during each simulation - this option box keeps disappearing. This is only visible when it is pertinent, i.e. when you create simulations on the basis of different existing *.VCi files. This allows choosing if you want to overwrite the source VCi file. 3. The Results variables specification tab - These variables doesn't seem to be updated in the BatchResults CSV file. This would be aestonishing as it is the basis of the batch mode, used by everyone. We will check. 4. In the Meteo and Save Mode tab, "Create hourly files" - It is not clearly shown, but this option seems to inherit the output file setup on the simulation start screen. Thus the "hourly files" can actually be any output file, including monthly values. - Could you indicate that in the help file? When specifying to create "Hourly File" in the Batch mode, you are prompted to define the output file. Here you can specify any kind of output file (hourly, daily or monthly). I admit that the "Hourly" label is not quite correct, but it corresponds to the usual use ogf the output files.

If in the "detailed losses", page "Module Quality Loss", you have checked "Default", the Module quality loss factor will be reevaluated at the beginning of the simulation as a function of the actual PV module's parameters.

Thes values are used for the default value of the "Module Quality Loss" parameter. See our FAQ How to define the "Module Quality Loss" parameter ?

Installing 875 kW on an area of 4047 m2 is indeed problematics. If installed horizontally, this would mean collectors of 21.2% efficiency, without any intervals between them. Please see our FAQ In sheds arrangement, which power can I install on a given area ?

The installed nominal power (STC) is directly proportionnal to the collector area: Pnom [kWp] = Coll. Area [m2] * Effic at STC [%] / 100 Now the Utilization Factor UF (= Acoll / Aground), which is the inverse of the Ground Coverage Ratio (GCR), is calculated according to: Utilization Factor We can notice that the more relevant parameter is the collector tilt: with 30° tilt you can install only 40-50% of the available ground area, when with 4° or less you can install more than 80% of your ground area. This is very weakly dependent on your limit angle. UF as function of collector tilt Therefore when the area is limited, you are always advised to put your collectors as horizontal as possible (with the only limit of the soiling problems). Moreover, this results in much simpler support's mechanics, less wind sensitivity, lower weight, etc. This allows also to define higher shed's width, i.e. more strings in the width of the shed. This drastically limits the electrical shadings losses. In most cases, taking the shading effects into account, the overall energy loss will be less than 2-3% with respect to 20-30° sheds.