Jen H

Hello, I'm seeking clarification on the relationship between Maximum current per MPPT and Min. Voltage for PNom in the OND file - 'main parameters' tab. When I enter the Maximum current per MPPT (22A), the Min. voltage for Pnom automatically changes from N/A to 463V. Where does this value come from and what is its significance? The inverter datasheet I'm using has the following datasheet parameters: Max. Input Voltage - 1100V Max current per MPPT - 22A Max short circuit current per MPPT - 30A Start voltage - 200V MPPT operating voltage range - 200-1000V Rated input voltage - 600V Max. number of inputs - 12V Number of MPP trackers - 6 Nominal AC power 60 kVA As an aside, if the parameter is not in bold type does this mean that it doesn't matter for the purposes of the simulation? Any clarification would be much appreciated! Thanks, Jen

To follow up on gugel88's post (copied below), does anybody know of any studies in which either the fraction for electrical effect for thin objects is defined orthe shading loss due to a defined thin object is calculated? Thanks!

Hi André, Thanks for this response, that's useful to know. Could we please clarify what is meant by "all the points interpolations up to the first <1" just so we are clear between which points the linear interpolation applies? Thank you!

Hi We have seen changes in the diffuse model in PVsyst projects in V6.42 which we believe is due to the change mentioned in this post. This raises a few questions for us: Will we be able to select between Perez and Erbs in future updates?What is the difference between the two e.g. rough % difference seen As far as I am aware we can’t actually test this as we also have several other changes e.g. update in PVsyst shading engine, which makes a like-for-like test impossible, is this correct?

We have a similar issue to this. We can import a .dat file from MN7 and it will upload into PVsyst, however it does not generate the site file. When we use the ‘Show all available meteos’ function we can see the file. However when we select this it comes up with the following error message ‘The distance between the Project and the Meteo is too large (1248k,). The solar geometry….’. We have a work around of uploading the .dat file in v6.39 and exporting .met and the .site file from here into version 6.42. Are we doing something wrong, or is this a possible bug?

Many thanks for looking into this. Looking forward to the update!

I am having the same problem too. When I export a project from 6.39 into version 6.41 and recompute the shading table, sometimes there is a small difference in linear shading but bigger difference in electrical shading, which can translate to a significant difference in electrical shading loss between the two versions. I've attached a project to this post as a reference. The differences in electrical shading factor (shading factor according to strings) between version 6.39 and 6.41 is below: I did not change anything in the simulation other than recomputing the shading table. P.S. In 6.41 the shading table is calculated much more quickly than for previous versions, so thank you! Bedford_Project.zip

I'm facing the same issue. Maybe we could set the fraction for electrical effect to 0% (quasi-linear shading) but use a non-zero thin object ratio. Then define all external shading objects as thin objects? This will keep the module inter-row shading as linear.

If the inverter has MPPT capability then PVsyst will give you the option to choose whether to use it and how many MPPT inputs to use (2, in your case). Then I believe you would just choose to have 9 string inputs, which PVsyst would automatically distribute between the two inputs. See the highlighted portions of the attached image. Hope that helps!

Ah, thank you for clearing that up!

I've faced a similar problem when using PVsyst 6.37 I have to identical pan files but they originate from different sources. In PVsyst, it says that muVoc for both of them should be, as expected, identical. However, when I "copy to table" and export the pan file details into a spreadsheet, the mu.Voc values are different. I attach the an image of the pan file details spreadsheet and PVsyst screenshots for reference. spreadsheet and screenshots Did either of you find out the reason for this? I'd be curious to know :) Thanks!

Hello, I understand that CIGS panels show quite a different low irradiance behaviour from c-Si (as shown on page 19 here: http://www.sophia-ri.eu/fileadmin/SOPHIA_docs/documents/Workshops/1st_European_Workshop_on_PV_Performance_Modelling/Session_B/MERMOUD_PVsyst.pdf) Given that (in PVsyst 6.32 at least) the default Rs is set to give relative efficiency at 200 W/m2 of 97% that at 1000 W/m2, then the "default" Rs for CIGS modules should be different. What is the best way to represent CIGS modules' low irradiance behaviour? Thanks!

Many modules exhibit better performance at irradiances just below 1000W/2 than at STC, e.g. see http://static.renesola.com/f/2014/07/12/Virtus%20II%20250-260M-24Bb%20Technical%20Specification(US).pdf. So if the irradiance levels at your site are mainly around 600-100W/m2 then it's possible to observe a low irradiance gain.

On a related note, why has this change in the definition of series resistance been implemented? Series resistance changes with illumination (e.g. http://www.ijetae.com/files/Volume4Issue8/IJETAE_0814_49.pdf) so why has 200 W/ m2 been used? Or is the two I-V curve method of determining series resistance the new method, using the 1000 W/m2 curve AND the 200 W/m2 curve? Thank you for your help :)

Hi André, I've noticed the same problem with the Phonosolar, PS240P - 20/U module. The pan file on PVsyst uses the default value of series resistance so its value - and consequently the gamma and the low irradiance loss - changes depending on whether I open my project in version 6.25 or version 6.32. Given that the pan file data source is 'Manufacturer 2013' is it best to stick with a 2013 version of PVsyst (i.e. the 6.2 series) which was the version that the manufacturer may have been working with? The low irradiance loss for the project changes from -2.6% (v 6.25) to -1.6% (v 6.32) so this version change would have big implications for all projects going forward. Thanks for your assistance, Jenna

Hi André, I'm using version 6.25.

Dear André, Thank you for your response and for directing me to the other thread. Apologies if I've misunderstood, but I wasn't considering any losses after the inverter: rather than examining the output at the grid injection point, I was examining the output at the inverter, which is where the limitation is applied. So why are the clipped values of the inverter output, 'EOutInv', dipping below the threshold? For example, I'm imposing a clipping limit of 2.55MW, so I assume that an unclipped 'EOutInv' value of 2.61MW would be clipped to exactly 2.55MW, whereas it is actually clipped to 2.53MW. I'd appreciate if you can help me to understand the process more :) Best wishes, Jen

Hello! I applied a grid power limitation of 2.55 MW to a system. I output the hourly "available energy at inverter output" before and after applying the grid power limitation. I noted that all values greater than 2.55 MJ/hr were reduced to values below 2.55 MJ/hr, causing losses. Why are the values not reduced to exactly the clipping limit? Many thanks, Jenna