Lazare Fesnien

Dear Sir, We update the database using the requests of the manufacturers, and publish it with each new issue of PVsyst. We can't of course follow all the new products of all manufacturers in the world. We don't want to include data without the acknowledgement of the manufacturer. Nevertheless you can easily create your own components by yourself. The easiest way is to choose a similar existing device in the database, modify its parameters according to the manufacturer's datasheets, and save it under a new name, therefore creating a new file in your database. You have a tutorial for that on youtube: https://www.youtube.com/c/PVsystTutos, page Component database

Dear Sir, We update the database using the requests of the manufacturers, and publish it with each new issue of PVsyst. We can't of course follow all the new products of all manufacturers in the world. We don't want to include data without the acknowledgement of the manufacturer. Nevertheless you can easily create your own components by yourself. The easiest way is to choose a similar existing device in the database, modify its parameters according to the manufacturer's datasheets, and save it under a new name, therefore creating a new file in your database. You have a tutorial for that on youtube: https://www.youtube.com/c/PVsystTutos, page Component database Regards,

The speed of the simulation mainly depends on the complexity of the system and the complexity of the 3D scene you are trying to simulate. Here are a couple of ideas: In the 3D scene: When near shadings are used, the calculation of the shading factor basically requires to compare each elementary surface to each PV table (goes with the square of the number of elements) You can simplify the calculation by using arrays of tables instead of single PV tables if your tables are well aligned; The shading calculation with trees is very slow, as each face of each tree has to be calculated independently. For tree arrays, you are advised to use a single parallelepiped; A significant time may also be due to the pre-calculations for the optimization of the shading factor calculation, or the check that each table should not interpenetrate any other table or objects. Try to avoid interpenetrating objects; Too much detail in the topography will lead to long import and simulation durations and possibly slows down the user interface. There is a limit of 500’000 unique points when importing topography data through a CSV file, and a maximum of 1’000’000 triangles when the triangulation is performed. In the ground data details, you can use the simplification tool to reduce the number of points. System definition: You can simplify the definition of the system if you have defined many sub-arrays with a single inverter. This will make the simulation very slow, and it is best to group identical inverters in the same sub-arrays; Using the multi-MPPT feature will slow down the calculation. If possible, you can disable it, which means considering inverters as a whole; With string inverters, the simulation is performed for each inverter input, which significantly increases the simulation time. Shadings calculation: When using the “Module Layout” for electrical mismatch effects, defining more than 1’000 - 1’500 modules leads to extremely long calculation times; You can simplify the shadings calculation by using "According to module strings", and if necessary the "Fast (table)" option, instead of "Detailed electrical calculation (acc. to module layout)". The shadings calculation will be less accurate but it should be much faster. Here is the link to the help page that explains how to set up partitioning: https://www.pvsyst.com/help/index.html?shadings_partitioninstrings.htm In the slow case, at each simulation step the shading factor is recomputed.

Dear Berthiaud, The SolarEdge architecture obeys very strict rules, established by SolarEdge. PVsyst strictly applies these rules. These rules namely define the compatibility conditions between the optimizer and the inverter models, , as well as some maximum sizing and operating limits. Please ask the SolarEdge team.

Dear Massimo, We update the database using the requests of the manufacturers, and publish it with each new issue of PVsyst. We can't of course follow all the new products of all manufacturers in the world. We don't want to include data without the acknowledgement of the manufacturer. Nevertheless you can easily create your own components by yourself. The easiest way is to choose a similar existing device in the database, modify its parameters according to the manufacturer's datasheets, and save it under a new name, therefore creating a new file in your database. You have a tutorial for that on youtube: https://www.youtube.com/c/PVsystTutos, page Component database

Dear Pvfrance, When you have a different number of strings on the MPPT inputs, you should create one sub-array for each configuration (for example one sub-array for the MPPTs with a single string, and another one for the MPPTs with two strings). Then, in ‘power sharing’, you tell PVsyst which sub-arrays belong to the same inverter and how the power of the inputs is balanced. I have attached a PDF document to this e-mail with short examples on how to proceed. You can also find more information in the help under: ‘Project design > Grid-connected system definition > Multi-MPPT inverters’ ‘Project design > Grid-connected system definition > Multi-MPPT inverters: power sharing’

You must check that the manufacturer's name is written correctly and you must restart PVsyst after an import.

The error message in red is normal. You have defined a PV power on your main input well below its nominal power (55 KWac). You need to increase the number of strings on this main input

Dear Michalis Angeli, The « Module Layout » calculation is based on the internal geometric arrangement of the sub-modules. See the help “Physical models used > PV Module - Standard one-diode-model > PVModule Structure > Submodules”. This submodules partition is defined in the PV module definition, page “Sizes and technologies”. Now only the options “In length”, “In width” and “Twin Half cells” or Twin Third cells” have been implemented in PVsyst. More and more PV modules have other exotic configurations. You cannot use this option with other layouts. This error message was added rather recently (some few months ago), for avoiding erroneous calculations. It is possible that your previous simulation has been done before this protection. In your old calculation, the electrical shadings calculation may be not quite accurate. The only way for avoiding this problem is to cheat, by redefining your PV module with an allowed submodule layout. However in this case, the electrical shading calculation accuracy cannot be guaranteed with respect to the reality.

We cannot adapt to technologies that are not clearly defined. Manufacturers dont' communicate on the internal electrical wiring of the cells. We therefore cannot "guess" how the shading affects this PV module via the layout module. You can use the shading scene to calculate a shading and electrical loss factor via "partition"

More and more PV modules have other exotic configurations. You cannot use this option with other layouts.

Dear Meurville, The « Module Layout » calculation is based on the internal geometric arrangement of the sub-modules. See the help “Physical models used > PV Module - Standard one-diode-model > PVModule Structure > Submodules”. This submodules partition is defined in the PV module definition, page “Sizes and technologies” Now only the options “In length”, “In width” and “Twin Half cells” or Twin Third cells” have been implemented in PVsyst. More and more PV modules have other exotic configurations. You cannot use this option with other layouts. This error message was added rather recently (some few months ago), for avoiding erroneous calculations. It is possible that your previous simulation has been done before this protection. In your old calculation, the electrical shadings calculation may be not quite accurate. The only way for avoiding this problem is to cheat, by redefining your PV module with an allowed submodule layout. However in this case, the electrical shading calculation accuracy cannot be guaranteed with respect to the reality. Regards,

Dear Michalis, In your case you must define the average length of a string. Then PVsyst will calculate the resistance of the DC circuit taking into account the number of strings in your system. At this location, the number of MPPTs is not taken into account in the calculation of DC losses. We will take into account the number of inverters and strings Regards

The EUPVSEC conference will start in 5 days, as a reminder : We are pleased to announce that our collaborators #BrunoWittmer, #MicheleOliosi and #AgnesBridel will be present at the 40th European Photovoltaic Solar Energy Conference which will take place in Lisbon (Portugal) from September 18 to 22, 2023. For more information : https://www.eupvsec.org PVsyst will be presenting two posters Poster N°1: Limits of the single diode model in view of its application to the latest PV cell technologies Poster N°2: Accounting for sub-hourly irradiance fluctuations in hourly performance simulations We look forward to seeing you there

Dear Meurville, Thank you very much for your interest in a PVsyst training. We propose some online personalized sessions in the form of Consulting and PVsyst project support, to answer specific requests (no standard sessions for the moment). If you are interested in this service, you are kindly requested to request an online quote here: https://www.pvsyst.com/consulting/ We will establish a program relevant to your specific requirements. Our sessions last for 2 hours (including participants question time) and are charged CHF 700.- Our online sessions are limited to 5 participants per session. We do not provide any guarantee relating to your simulation results. In the meantime, we have designed several online video tutorials which we invite you to watch: https://www.youtube.com/channel/UCMzsEWHk3f7XD_dg1lngmzg or access our online course at: https://vimeo.com/pvsyst If you have a technical question, please feel free to send an email to support@pvsyst.com With best regards,

Dear Michalis Angeli, In the absence of reliable measured data, PVsyst proposes default values without wind dependency (i.e. assuming an average wind velocity): - For free-standing (open-rack) systems, i.e. with air circulation all around the collectors), according to our measurements on several installations: Uc = 29 W/m²·k, Uv = 0 W/m²·k / m/s - Therefore for fully insulated backside (no heat exchange at the backside, only one side contribution to the convecting heat exchange), the U value should be divided by 2: Uc = 15 W/m²·k, Uv = 0 W/m²·k / m/s - For intermediary cases (semi-integration, air duct below the collectors), the value should be taken between these 2 limits, but preferably lower than 22 W/m²·k as the air heat removing is often not very efficient. The default value proposed by PVsyst for any new project is Uc = 20 W/m²·k, Uv = 0 W/m²·k / m/s We have chosen this value as general default, because we consider that it is more representative of usual rooftop systems, managed by "less professional" people who will not necessarily modify the PVsyst default. For big systems, we suppose that trained engineers will indeed adjust this parameter (for example at 29 W/m² for row-like big power plants). - For domes, a manufacturer has measured the U-value on several installations (height about 40 to 70 cm above the ground): Uc = 27 W/m²·k, Uv = 0 W/m²·k / m/s: Now if reliable hourly wind velocity data are present in the data, we don't have any reliable measured data with wind. PVUSA proposes the following thermal correlation, widely used for the free-standing (open-rack) situations when wind speed data are available. Uc = 25 W/m²·k, Uv = 1.2 W/m²·k / m/s This corresponds to our default 29 W/m2, when the average wind velocity is 3.3 m/sec (rather usual in continental - not coast situations).

Dear Emi, If you can, you should mix orientation 1 & 2 and then separate orientations 4 & 5. Attention, its not at all conventional to put two strings of different length on a single MPPT input

Is is indicated in the PAN file that this PV module is no longer present on the market. You must therefore choose "all modules" in the "availability" filter.

Dear LFurzsina, Maybe there is a problem in the definition of the PAN file. Can you send the PAN file to support@pvsyst.com ?

Dear Shashank Sharma, These losses appear in the following loss diagram:

Dear Emi, You can simulate virtually your entire project. Attention it is not possible in PVsyst to mix two orientations with different lengths of strings. I just made your system under PVsyst, you just need to make a little change in the naming of the orientations in order to simulate your system correctly.

Dear Gba, This is a project setting. By default the value is 50°C, you can modify it from "Project settings" :

Dear Emi, In your configuration you must define orientation1 and 2 with "mix 1 and 2" the define your sub-array N°3 as orientation N°3. This will allow you to position three orientation on two MPPTs like the example below :

You must use the "power sharing" tool to set the power distribution correctly

Dear Emi, You set one string for two MPPT inputs, it can't work