Michele Oliosi

Dear IgLoo, unfortunately no. You can change the report settings but at the moment TArray is not an option for that table. I'd add that since TArray may widely during the day / night, the monthly average value may not be very informative.

Yes, it technically is less accurate to modeling things with one orientation instead of having all orientations of your tables. But unless the RMS of the differences between planes is extreme (e.g. 20°) there should not be a huge impact.

Is it a PAN file provided by a manufacturer or a module from the database ? You can check whether the parameters do not have any of the default checkboxes checked (one of them is already good). E.g. If you are not sure you can send your PAN file to support@pvsyst.com. Personally I am not quite confident about giving good advice on modules, but my colleagues should help with that.

Looking at your data it seems that the irradiance values are too high. First of all please make sure that all the parameters of the import are correct. Try to double check all the units so that they match the units in your measurement. If in trouble you can also assign a multiplier to each value. I see you have a time sihft issue, I'd recommend setting the time shift (30' + or -, I am not sure of the needed sign) in the conversion protocol as well.

Hi, you may be interested in https://www.pvsyst.com/help/batteries_modeldescription.htm You can define two different types of initial state of wear

If you need to distribute strings over multiple tables, you can only do that with the module layout. At the moment we do not support partitions on multiple tables. I would advise the following: run the module layout once to get an estimate of the electrical shading factors. If your scene is too large, you can create a smaller scene with similar shadings. Then when using the partitions, start by defining 100% for the electrical effect fraction. If you see that this overestimates the shadings compared to the module layout, you can reduce the fraction. Apart from that there is no failproof way to define the electrical shading fractor whenever you have both regular (row-to-row) and complex (e.g. trees) shadings.

Please double click on fields #2 to #9. In your system summary you can see that no orientation was defined for them: they have orientation #-1 instead of #1 or #2. So please open the objects and select the relevant orientation.

Ok then that is likely the reason. The PR is basically a ratio between yield and incident irradiance. These values are different at every hour. Now, you should remember that the ratio of averages is not the average of the ratios. The correct way would be to sum the yield (E_Grid) and average the global incident irradiance (GlobInc) separately and then recalculate the PR based on the two resulting values.

On the main window, try going to File > Reload databases. As a second point, please check that coordinates do match closely. Let us know if either helps.

Can you explain your calculation for the monthly average PR ?

At the moment you cannot set different strings on the same MPPT within PVsyst. However you could modify the inverter and add an extra MPPT. As long as you are careful with the "power sharing" configuration, it can be a good representation of your system.

At the moment the workaround is to switch directly to "by modules". Adjust the spacing. Go back to "by summits" and redesign the polygon. I have submitted a ticket to improve the functionality at some point in the future.

I see, I will check whether we can create a similar functionality in the newer PVsyst as well.

Another point that may be at play: the module parameters have to be recomputed to be able to apply the degradation. If you are using a module that doesn't have standard one-diode parameters to begin with, once the aging is applied, they may change due to the recomputation of these parameters.

Yes it is the same issue with or without backtracking.

As far as I know, in the context of PVsyst they are the same (cell and module temperature). I will add a note in the help.

If you click on "by modules (adjust sizes)" instead of "by summits" you should be able to change the module spacings.

Recently released v7.2.21 should fix the bug.

Recently released v7.2.21 should fix the bug.

Thank you for the feedback. This is a known bug for the drawing only and its correction is in our roadmap. It does not affect the simulation in any way.

Hi, Please provide your question in english if possible. The language of the forum posts is in english (see forum rules). You can send us your questions at support@pvsyst.com you can turn on these settings by clicking on "by modules (adjust sizes)"

@laurahin You are right, only one pitch is being used atm: the average pitch.

Patch 7.2.20 has introduced an error affecting the partitioning into rectangle strings of tracker objects. The partitioning, either via the object management window or the individual objects edition windows, will not respond correctly to the inputs such as "number of partitions in X", and will not draw the partitioning correctly either. As a consequence, the shading animation and calculation of the electrical shading factor table will give erroneous results. Typically this yields 0% electrical shadings in the yearly results or losses diagram. This bug affects trackers only. For previously created projects, the trigger for the bug is opening the 3D scene and the tracker object definition, which will break the partitioning. We know of no workaround at the moment, but are working to provide a patch very quickly for this error. It should be published within this week. In the meantime you can also work in the previous version 7.2.19, while waiting for the patch. For that you need to uninstall and reinstall PVsyst. This has no averse effect on the licence, which stays active through the process. Here is the page with all previous versions: https://www.pvsyst.com/previous-versions/ Related post 1 : https://forum.pvsyst.com/topic/2935-partition-function-does-not-work-for-tracker-imported-from-pv-case-after-last-updated-720

Hi, At the moment in PVsyst we only have a tool to check multiple orientations within the clear day scenario: For anything other than clear day (taking into account a specific weather file), you should use the optimisation tool and run it while specifying a specific temporal range for the simulation: Note however that that optimum will be true for a specific weather file only !

Difficult to say with monthly data only. But the diffuse seems to be quite different, which could explain differences before and after transposition.