André Mermoud

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.

The TMY2 and TMY3 formats are very specific and well-defined formats (see http://www.nrel.gov/docs/fy08osti/43156.pdf). PVsyst has established the import of files corresponding exactly to this format, and this works quite well with the files provided by the NREL. But it is not guaranteed for other sources. Now we have proposed a "PVsyst format" for the meteo data several years ago (see a description in the help). 3-Tiers has agreed to propose their data in this format when requested. Please ask them. By the way you can probably import your data using the general tool "Databases > Import meteo ASCII files" (and Press F1 for getting the procedure).

Your comparison with a window is correct for a vertical plane. However the additional yield of the albedo goes with (1-cos(tilt)). If this is 100 % for a vertical plane, it is only (1 - cos(30)) = 13.4% for a 30° plane, and 6% for a 20° tilted plane.