SE2015

Hi, I have an existing multi orientation system that am trying to simulate in PVsyst. The pyranometer is installed parallel with the modules on one of the orientations. When I import the POA hourly data, PVsyst warns me that the data is only applicable to the modules belonging to that orientation. Will the simulation of the entire system be correct, or do multiple orientation systems require multiple pyranometers, if they are tilted? Thank you

Hi, the image below shows meteo data I am inserting in version 7 vs version 6.87. For some reason I get a kt error in V7. Any thoughts as to why? is there a hidden parameter I can change to fix it? Thanks!

The SolarEdge nominal Pnom ratio can be raised in the hidden parameters (parameter ID's 280 and 281). Don't forget to also raise the "Nominal Pnom Ratio" to the level you need in the Strings Configuration interface.

Hi, You are correct. To allow for string oversizing, 3 strings must be connected to the inverter.

As far as I know, the way to do this is to convert the DWG file to either *.3ds or *.dae, which can be imported into PVsyst.

Is it just me, or is the new site map (as of V6.77) slower and more importantly, does not allow a direct input of coordinates? A direct input of coordinates for the new SIT was very helpful (now we have to trawl the map to find the correct spot...)

Has the growth of mismatch been included as well, or just the aging? Thanks

The "Nb. of strings (transverse)" refers to the number of modules you have stacked in one table. But, if you are using MLPE such as microinverters or power optimizers, you need to specify the number of sub-modules, not modules. So for example, if you have a table that is 4 modules high, in landscape, then you will usually specify "4" in the Nb of strings. But, for the same system using SolarEdge power optimizers, for instance, you will specify "12" (because there are 3 sub-strings per module).

What may solve this is to import in inches. I don't know if it will solve your issue though, because of the extreme size difference you describe. Also, maybe use 3ds instead of dae, if Rhino can export in that format.

A current workaround I am using is to "snake" in an exclusion zone, like in the below image.

Does anyone know if the mismatch growth is included in the batch simulation? The module degradation is easy to show (even by using other params, as it is linear), but the mismatch growth will reduce production by an additional 2-3% over 20 years, needs to be included in the batch parameters list.

Correct, I see the warning now. I must say though that in V6.5x the functionality was better: we routinely use the module layout functions to verify our designs are correct (there is no other error-checking for this in PVsyst, other than manually counting the modules in the PV areas). We used to get a message like in the image below, telling us exactly where our discrepancy was. It's a shame to lose that functionality (now we only get a warning telling us we didn't do well, but not what we did...).

Hi, I notice that if my PV areas are bigger than the number of modules I designed, the Module Layout allows the simulation to proceed and does not warn of a discrepancy, as it used to do (it was a very useful error-checking tool). See the image, quite a few modules are missing from the scene, but the simulation can continue. i think this will have an effect on the shading response of the system. Thanks

Hi, in V6.61, when I partition the modules in a PV area into one string (i.e. the PV area will have a 1x1 sized partition), many times the PV area is deleted. Several 'undos' will bring it back, but I can't successfully proceed with the partition.

Hi Tecnum, When you select an object, then you click the red cross on the toolbar. You will see the three arrows allowing you to move the object. In order to edit an object, you select it and click the "wrench" button on the toolbar. Is that what you are referring to?