Bruno Wittmer

In fact the variants were not being properly restored after each batch run step. This is now fixed for the coming version 6.42. Thank you for reporting the issue.

The electrical loss according to strings depends strongly on the specific details of the simulation. Could you send your project (or a minimal example where you observe the behavior) to support@pvsyst.com, so we can have a look at it? We did not introduce any fundamental change in this calculation, so we do not expect major differences in the results of V6.39 and 6.40.

Yes, there seems to be something wrong there. I will look into it right now.

The procedure to import data from Solar Prospector is described in the PVsyst help 'Meteorological data -> Meteorological data sources -> Solar Prospector Data -> Importing Solar Prospector Data'. Did you follow the steps described there? Which tool are you using to uncompress the .gz file?

There is no simple answer to this question. You are absolutely right in saying, that a pitch of <2m with a shed width of 2m leads to large shading factors and subsequent losses. The ideal situation is to choose the optimal tilt for your latitude, and either to have all sheds side by side, so that there is no shading, or to put them behind each other with infinite wide spacing, which will also lead to no shading. Of course you cannot do this in practice, so you have to approximate to it, given your specific constraints, like availability of the area, clearance for access paths, etc. The optimum from an economic point of view will include also an assessment of the costs of the surface, installation and maintenance costs, and the expected revenues or savings per kWh that is produced. This is highly dependant on your specific project and has to be studied case by case. But as a general rule, you can take that you should put as much sheds as possible side by side and keep the distance between rows as large as possible. Remember, that the closer the rows are to each other (i.e. the smaller the pitch), the smaller you should choose the tilt angle to minimize shading losses. The tool that André mentions, will help you already with the geometrical optimization, for given surface constraints. We are also preparing a tool in PVsyst that will allow a more complex analysis, including economic variables. This should be available in a version within the coming month or two.

TIGO Optimizers are available for PVsyst V6.27 or higher. In the 'System' dialog check 'Use Optimizer' (in the module selection group). A pull-down menu will appear below the module selection field, where you can choose the model of the optimizer.

This problem happens on the southern hemisphere for two specific tracking cases: - Two Axis - Vertical Axis It is a bug that is caused by a wrong sign in the calculation of the diffuse shading. This bug has been fixed for Version 6.31.

This error means, that there is a mismatch between the total module area as specified in the 'System' dialog, and the total active area as defined in the 'Near Shadings' scene. You have defined more sensitive area in the 3D scene, than the sum of all modules areas.

The electrical shading losses account already for the shading losses, the loss is not computed twice. The percentage losses in the loss diagram always refer to the preceding amount of energy. You should read the loss diagram as percentages on top of each other, not as percentages of the total initially available energy. Since shading loss and electrical effect are conceptually something different, and since logically they happen at different stages, it is reasonable to display them separately.

The linear shading loss is the fraction of irradiance that you loose due to shading. For the direct component this is just the fraction of the active surface that is shaded, but for diffuse and albedo it involves an integral over the entire hemisphere. This loss means, that less light is reaching the modules. The electrical loss caused by the mismatches due to shadows, is an additional effect that comes on top of this. If you do the simulation according to strings, you can define how much the impact of partial shading should be in a string. 100% means that a partially shaded string will produce no output, 50% that it will still generate half of the output, and so on. This is to account for the fact, that the production in a string will not drop to total zero, due to remaining diffuse irradiation. If you use 100% for this factor, then your comment is right, it would not be necessary to calculate the linear shadings, since you loose all the string production. But for factors less than 100%, this mismatch(!) loss has to be applied on top of the irradiance loss, and this is why you have two separate entries in the loss diagram.

The filled circles mark the MPP and in the legend you find the power loss at MPP which is the difference in power between the average (green) curve and the resulting one (black). In order to show, that the losses can become larger if you work at a fixed voltage, the graph also shows the difference in current for V = Vmpp * 0.9 (where Vmpp is taken from the black curve). This is marked by the open squares.

For the SolarEdge architecture, when you want to connect different strings to the same inverter, you have to use the option 'Use fractional inputs'. In this way you can define different number of modules for each sub-array, but you should make sure, that you assign an adapted number of modules to each fraction of the inverter. In your case, you could define for example a fraction of 0.3 for East and West and 0.4 for South and assign a matching number of modules to each. The screenshot shows how the the system definition in the report could look like. SolarEdge Inverter with three different orientations

If you do not need all versions you created in all projects, you might want to consider using different workspaces to keep things organized. See also the Help under 'Technical aspects > File organisation > User data > Workspace'

Dear Vikram, if you would like to vary the plane tilt in the batch simulation, the end in your CSV file should look like the example below. Please note that the CSV file is an ASCII text file. You are not forced to use Excel, indeed you can youse any ASCII text editor. If you use Excel or a sophisticated editor like Word, you need to save the file as ASCII text. In Excel , when you choose 'Save As', you have an option 'CSV file', (wich stands for Copmma Separated Values). In Word you will have to choose 'Raw text' and remember to keep the .CSV ending of the file. Best regards, Bruno Table for varying only the tilt in a batch simulation: Ident;Plane;Simul;; ;tilt;Comment;; ;[deg];Y/N;; ; SIM_5;5;Tilt 5 ;; SIM_6;6;Tilt 6 ;; SIM_7;7;Tilt 7 ;; SIM_8;8;Tilt 8 ;; SIM_9;9;Tilt 9 ;; SIM_10;10;Tilt 10 ;; SIM_11;11;Tilt 11 ;; SIM_12;12;Tilt 12 ;; SIM_13;13;Tilt 13 ;; SIM_14;14;Tilt 14 ;; SIM_15;15;Tilt 15 ;; SIM_16;16;Tilt 16 ;; SIM_17;17;Tilt 17 ;; SIM_18;18;Tilt 18 ;; SIM_19;19;Tilt 19 ;; SIM_20;20;Tilt 20 ;; SIM_21;21;Tilt 21 ;; SIM_22;22;Tilt 22 ;; SIM_23;23;Tilt 23 ;; SIM_24;24;Tilt 24 ;; SIM_25;25;Tilt 25 ;; SIM_26;26;Tilt 26 ;; SIM_27;27;Tilt 27 ;; SIM_28;28;Tilt 28 ;; SIM_29;29;Tilt 29 ;; SIM_30;30;Tilt 30 ;; SIM_31;31;Tilt 31 ;; SIM_32;32;Tilt 32 ;; SIM_33;33;Tilt 33 ;; SIM_34;34;Tilt 34 ;; SIM_35;35;Tilt 35 ;; SIM_36;36;Tilt 36 ;; SIM_37;37;Tilt 37 ;; SIM_38;38;Tilt 38 ;; SIM_39;39;Tilt 39 ;; SIM_40;40;Tilt 40 ;;

Any text editor should do the job, TM2 files are plain ASCII text. If you are interested in the format of the file, a description of it can be found at: http://rredc.nrel.gov/solar/pubs/tmy2/data.html

To be able to interpret the simulation output as P50 value, one has to use an average over many years as meteorological input, not the data of a specific year. The PVsyst default is to use Meteonorm data, which is indeed an average over many years. If you use a different meteorological source, make sure it represent the average climate of the geographical location, like for example data sets with a Typical Meteorological Year (TMY). NB: PVsyst also allows to use a shift for taking the climate change into account. We observe - at least in Europe - a significant increase of the annual irradiation (of the order of 5%) with respect to the end of the last century. See What is the reliability and unceretainties of meteo data ? in our FAQ

The bug has been fixed for PVsyst V6.27

I did reproduce this error for that specific locaiton. Indeed it happens for all TMY2 files where the first line is exactly 58 characters long. A slightly different error occurs when the first line is shorter than 58 characters. I spotted the bug in the code and will fix it. As a quick workaround you can add a space to the end of the first line of the file, then it should work.

Which PVsyst Version are you using? I just tested in PVsyst 6.26 for Auckland, New Zealand, and the azimuth -135° gives, as expected, a drawing facing south-east in the orientation dialog. Could it be that you mis-interpret the sketch? On the right side, in the view from the top, the red and black dots are on ground level! Best regards, Bruno

The bug has been fixed vor PVsyst Version 6.26.

The table calculation can occasionaly crash due to a bug in a log message call. If this happens, a workaround is to generate the output as ASCII file. In the simulation dialog ckick on 'Output File' and select the variables that you want to look at. You can get hourly, daily or monthly values. The results can be viewed with a text editor or spreadsheet application like MS Excel. The bug is being fixed.

Hi Iain, currently there is no way to get all the hourly result values from a simulation that has already been run, except for the method you are using. If you need these results often, I would recommend you to systematically create an ASCII output file, when you run a simulation. You can customize which variables should be written to the output file, and save this as a template to re-use it. PVsyst will not store the output filename for a given variant, so you will have to choose it every time you want to run a simulation and create the ASCII file. We will consider to change this behaviour. As for the possibility to run all variants of a project in one go, we are reworking and improving the batch simulation feature of PVsyst, and we will see if we can add this possibility. This would be for somewhen end of the year. Best regards, Bruno

Note also, that if you are interested specifically in the IAM, PVsyst can generate for you a lot of detailed intermediate results such as: - IAM factor on global - IAM factor on beam component - IAM factor on diffuse component - IAM factor on albedo component - ... and many more, that allow you to study in detail the effect of the IAM on the simulation results. In the program you need to click on 'Output File' in the 'Simulation' Dialog, and then choose the variables that you would like to have in the output. See also the online help under 'Project Design -> Simulation -> Export ASCII File'

Which SMA Sunnyboy inverter exactly are you planning to use? The 8kW inverters have an operating voltage range between 300 and 480V. If you string up 11 SunPower 327 modules, you get operating conditions between 500V and 800 V, which is not compatible with these inverters. Also, using 4 strings of 11 modules would give you a nominal power of 14.4 kW, which is far less than 4 x 8kW on the inverter side. PVsyst will report errors with these design choices, and not permit a simulation.

Hi Mahnam, a PVsyst crash is definitely a bug, this should not happen. If you get a prompt asking to send a bug report, then it would be nice if you could do so, our support team will get the report and try to fix the bug. If you do not get the prompt, then I would ask you to export the project to a zip file (In the main window select 'Files -> Export Projects'), and send it to me (Bruno.Wittmer@pvsyst.com), we will have a look at it. Best regards, Bruno