kamomeno68

The wire losses section of HV Transformer losses isn't recording the ohmic loss percentages properly. The transformer losses section in general appears to have issues if HV Transformer is chosen. MV Transformer options seems to work fine.

When attempting to export a project, program will stop working & generate an error code.

No changes to the computer recently

I'm not sure if this is a bug, or a setting that I unknowingly changed. I've been modeling in PVsyst for years, and often run the shadow animations tool to see how the shadows cast across an array. Was using it successfully during a session today, but then it simply stopped working. Nothing is happening when I click the "play" button. I've tried shutting down PVsyst and reopening, as well as restarting my computer, but still the same problem. Any idea why this might be happening? Thank you!

Is there an output data file parameter that shows the inverter DC input voltage? I see there is UArray for the DC output voltage of the array, but I'm interested specifically in the input voltage at the inverter.

I just wanted to check, is this capability to customize the table in the simulation report available yet in PVsyst?

Andre', I apologize for replying to an old thread, but it covers a subject I'm wondering about. I would appreciate your perspective on LID losses in PVsyst. - Let's assume crystalline modules. - Recently module manufacturer's have been providing test reports on measured LID for their modules, ranging from 0.5-1.5%. I usually assume this is the minimum possible module degradation in the first year. - Module manufacturer's also have warranty language that specifies the module degradation in the first year, ranging from 2-3%. I usually assume this is the maximum possible module degradation in the first year. - Given that there are factors other than LID that might contribute to degradation in the first year, I'm usually inclined to use the LID PVsyst input to account for them all, picking a number between the module manufacturer's specified LID and the warranty language. Is this a reasonable approach, or would you recommend simply using the LID number provide by the module manufacturer?

When exporting a project file, any associated shading scenes are not automatically included. Can this function be modified so that any project zip file created includes the associated shading files as well?

I've been having a very frustrating time with importing new meteo files into V6.4X of PVsyst. The meteo files appear to import properly, and can be found in the Databases/Meteo Tables section. But, when trying to attach them to a project in the Project Design/Site & Meteo section, the newly imported files can't be found. I've tried exiting PVsyst and restarting, still no luck. The only way I've found to solve the problem is to create a project V6.39, export the project and then import it into V6.43. If I do this, then the new meteo file appears properly. Am I missing something?

I started using PVsyst originally witth v5. At that time, I accounted for the increased losses due to snow by increasing soiling percentages in the winter months. I realize this method is not perfect, but it seemed like a reasonable option. In v6, however, there is the option of increasing unavailability in winter months to account for the increased lossed due to snow. Based on your experience, is either of these methods preferred over the other? Is there another way to best account for snow which remains on an array during sunlight hours? Also, can you provide further explanation for how the "unavailability" section works, particularly the "unavailability periods"? For example, I chose an "unavailability period" = 2 days, and the "number of periods" = 4 periods. In the "unvailability periods" section, I can then choose starting date, starting time, and duration in hours for each "period". An example would be 1/21/1990, 9am, 12hrs. I assume these numbers are intended to represent simply fractional periods in a 365day/8760hr year, and not the actual hours chosen. For example, the pv system will not be producing for 12 hours on 1/21, so I'm a little confused how PVsyst would model this particular unavailability input. Thank you!

I apologize for the simple question, but is it possible to include some basic simulation parameters in the CSV output file? There is a long list of variables that can be added via the "add vvariable" button, but I can't find any of the input parameters such as "module name" or "inverter name". Is it possible to output these as well? Thank you.

Is there a way to model multiple orientations with unlimited sheds in a single production model? At the moment, I assume I simply have to run individual models for each orientation.

I am attempting to model a tracker system, but after creating the 3D scene, the program will not allow me to continue with running the model. In the near shadings definition window, it gives the following warning: "In the field "tracking field"pitch between trackers is too low! Please correct this in the shading scene." And the "Table" button is grayed out, so it can not be used. My tracker pitch is relatively tight, but I need to run a model as it is. I assume there is a hidden parameter which is causing this error, but I can't determine which one. Which hidden parameter should I change to avoid this error?

I've upgraded to Ver.6.19. In the "Orientation" window, I select "Several Orientations" and set two orientations. Both at 20deg tilt, but one at 90deg azimuth and the other at -90deg azimuth. In the "System" window, I select the "Orient" button, and chose "Orientation #1". After choosing a module, inverter, and string qnty, I go back to the "Orient" button and chose "Orientation #2". After choosing a module, inverter, and string qnty, the original "Orientation #1" details have been over-written. There seems to be a bug which will not allow the proper input of system information for several orientations. Please advise.

Quick question about Voltage Threshold. I assume this item reflects inverter losses incurred when the input voltage to the inverter drops below its minimum dc operating voltage. In a real-world installation, I can see how this scenario would arise. Object shading could knock out a number of modules in a string, for example, which would drop the string voltage below the min inverter operating voltage, or you could have row-to-row shading on modules in landscape which would engage bypass diodes which would also drop the string voltage below the min inverter operating voltage. In the PVsyst model, however, I'm having trouble seeing when this will occur. For extremely high temperatures, maybe, but not as a result of shading. I have run two models which are identical in every respect other than the row-to-row spacing. Flat roof, single rows in landscape, near shadings defined "according to strings, 100% electrical effect". The wider row-to-row spacing shows 0% "loss due to voltage threshold", while the narrower spacing shows 0.2% "loss due to voltage threshold". With this near shading definition, it seems to me object or row-to-row shading would never result in a low string voltage - as soon as a shadow hits the string, it is considered 100% lost. I've tried running a number of different test models, just trying to better understand this loss factor, but the results aren't intuitive to me. Can you offer some insight into this loss factor? Thank you.

I've just adopted V.6 of the software, and am still trying to sort out the differences form V.5. The software help has answered most of my questions. One I can't seem to identify is change in the way the Shading losses are listed in the Loss Diagram. In V.5, there is only one line item: "Near Shadings". In V.6, there are two line items: "Near Shadings irradiance loss" and "Shadings: Electrical loss acc. to strings". In V.6, is the loss diagram simply splitting out the impact of shading into two components, a "linear" portion and a "strings" portion? Are these two together equivalent to the "Near Shadings" loss listed in V.5?

I've run into a problem with a module PAN created for Ver.6 not being compatible with Ver.5 - is this true? Are the PAN files created for ver.6 not compatible with ver.5?