deblynn

Hello PVsyst Team, I tried out a Helios 3D import file in version 6.64 to see how the new orientations interface works. Nice to see that it now takes the average orientation overall instead of the orientation of the first table. I noticed a reduction in near shading losses compared to running the same H2P import in an earlier PVsyst version. Have changes been made to the way shading losses are calculated, aside from the orientations options? Perhaps something to do with the evaluation of diffuse shading losses? Just checking. (Editing this post to add:) The change appears to have occurred between version 6.53 and 6.62 (same result in 6.62, 6.63, and 6.64 for near shading losses, which is lower than version 6.53). Thanks very much, Debbie

It appears that I can manually correct to the average azimuth and tilt if I first adjust the detailed simulation verification conditions to allow large orientation angle differences (for example 50 degrees for all the related settings). Perhaps this answers my own question. No actually, it didn't work. During the simulation the numbers were changed back to match the 3D scene. -Debbie

Thank you Sylvain, it's good to know this is an area of active development. It seems like currently the program is taking not the average of the orientations (tilt and azimuth), but the values from the first table. Until a new release that addresses these issues, is there a way to over-ride the requirement that the orientations match in the shading scene and orientation interface so that we can manually set to the average from the "orientations analysis"? I appreciate your help. -Debbie

Hello, I'm running version 6.62 with updated graphics driver and the graphic improvements are great! However, I think I'm finding two problems. 1) The azimuth change due to baseline tilt seems high. I did an experiment with a single PV table. First I set the azimuth to zero, and the baseline tilt to 9.5 degrees. The resulting azimuth is -24.4. Next, I set the azimuth to -10, and the baseline tilt to 9.5 degrees. The resulting azimuth is -44.4. The net change should be the same for both situations, but it is off by 10 degrees for the -10 starting azimuth. It would be helpful to learn what formula PVsyst is using for this azimuth and tilt adjustment according to starting azimuth, tilt, and baseline tilt. Perhaps there is an error? 2) In this version, 6.62, I am having trouble getting the ohmic loss percentages that I enter for 2 sub-arrays to work when running the model. They keep changing. This applies to both DC and AC ohmic losses. Thanks very much! -Debbie

Hello, this topic was partly covered in another post, but I would like to start a new thread specific to this topic. When undulations of terrain cause multiple azimuths, is it correct that PVsyst does not allow categorizing those multiple azimuths into a few average ranges? Do they need to be run as a single average for the full site? Is this still true for version 6.62? Does it matter whether using an H2P file, or other source of 3D image? If this is the case, then the impact of azimuth on production is not fully accounted for when running H2P files. We are considering post-processing methods to estimate this impact based on the exported orientations data. Does anyone have further thoughts on this question? Thanks very much, Debbie

Yes, I just found the same thing in version 6.43. I turned on shadow casting for a complex ground object and the shading seems buggy (extremely high and intermittent over time).

Actually I want to retract the previous comment. The terrain I was trying to import had very uneven point density with clusters of points along a drainage ditch. I think this is why it did not generate the triangles. With a more evenly distributed point density it worked. I was able to build the array using the zones and for a 26MW array it ran quickly in version 6.42 (6 minutes for shading table). Thanks for the improvements! -Debbie

Hi André, Thanks very much for this information. We have reduced the point density in a terrain in order to import a csv file covering about 82 hectares. It imports, and when I open the ground object in the Ground Editor, I can see the points. However, it does not generate the triangles and the terrain is not visible in the Global Scene View. Is there perhaps also a maximum distance between points for it to generate the triangles? Or some other criteria that I am not meeting? I am using 6.41. For a site this large (26MW on 82 hectares) is the only feasible approach to divide into sub-arrays? I have previously run a PVsyst model using a Helios3D import of 77MW and it ran (overnight). Is the Helios 3D format import still really the only feasible way to run a large array on terrain, or can it be done within PVsyst alone using the correct import parameters for the terrain, and building the array using the zones? Thanks for your help, -Debbie

Hello, What is the maximum number of x,y,z points that can be imported? Is there a specific maximum or does it depend on other details? I tried importing a large # of points (93,216) in version 6.40 and it did not accept the import. When I reduced the number it worked. Knowing the maximum will help select a sampling density for larger sites. I will upgrade to 6.41 today. Thanks! -Debbie

I just observed the same change as well from 6.39 to 6.40.

OK, perhaps I have to select the tables before I can partition them. Sorry that I missed that.

Hello, The new features of 6.40 are promising, but I'm having trouble getting a few things to work. The partition in module chains button sometimes does not bring up the dialogue. And when importing a ground image I can rescale the size, but I'm having trouble moving it to a specific set of coordinates. Thanks, Debbie

A further follow-up. If I placed two multi-row back-tracking arrays next to each other, but with an elevation difference, could I still use the linear near shading loss between the two as a proxy for the impact of elevation? And if I modified the pitch of the back-tracking arrays, could I look at whether changing the backtracking settings helps with the shade impacts of the elevation difference? Sorry, I know this is complicated. -Debbie

Hello, I'm writing with a follow-up question to the earlier conversation. Can you define 2 separate trackers, at two different elevations, with no backtracking specified, and get an estimate of shading losses without backtracking? If those shading losses are linear (not according to strings), will the energy estimate be comparable to a backtracking system? (though I realize diffuse losses and IAM factor will be different). If there are only 2 trackers, I recognize that only one tracker will be shaded at a time, so the shading loss will be half the impact on a large array. I am trying to figure out a way to use PVsyst to answer the question: how much elevation difference between trackers (E-W) is acceptable in terms of the magnitude of shading/backtracking loss? I would like to set up a simple 3D layout to test this, but I am not sure if it will work. Thanks for any insights! -Debbie

Hello André and colleagues, Should we assume that any complete project created in a newer version will not be readable in an older version? (for example a project created in 6.34 was not directly readable in 6.32, perhaps due to shade scene). Or are there specific innovations, not occurring in every new release, after which backward compatibility becomes an issue? If your team knows that a particular innovation is going to prevent backward compatibility, that would be a helpful note in the software development log. For example, that topic could end with: "note, this change prevents backward compatibility". Thanks, Debbie

Hello PVsyst team, When entering the tracker Phi limits the orientation screen images make it appear that a +/- 60 degree rotation must be entered as +/- 30. However, the results make it clear that entering as +/- 60 is correct. Can you clarify? Perhaps the images (little animations) on the orientation tab should be edited to make it clearer? Thanks very much. -Debbie Blue Oak Energy

Hello, I recently modeled a stand-alone system for the first time, so I am not sure if this is a bug, or my own error. I ran the system first with a generic regulator, fixed voltage, and it showed a high loss with respect to MPPT. Then I ran it with the generic MPPT regulator and also the generic DC-DC regulator. In both cases, there was a significant increase in production. The problem is that the increase was too great - the production is now significantly above an equivalent grid connected system (yield of 1843 for a fixed tilt system in San Francisco). Perhaps I did something wrong? Thanks very much, -Debbie

Hello, When I upgrade PVsyst, I often get the following message: "The component ___ has been modified by respect to the original database. Do you want to keep your modifications?". Can you explain what actions on my part have triggered this message, and the implications of choosing yes or no? Is PVsyst detecting this situation based on duplicate component names, or duplicate file names? I want to avoid overwriting a custom PAN file that we might have modified internally or received from the manufacturer. At the same time, I do want to upgrade component files with the newest information. Some additional detail on this situation would help me better understand how to respond when this question arises. Thanks! -Debbie Blue Oak Energy

Follow up questions: I noticed that when you import from the 3D near shading drawing, it brings in all the "tables", but does not maintain their position relative to each other. 2 of them were overlapping. Could this perhaps explain the high shade loss that resulted initially? I spaced them out further and ran it again, getting 2.5% near shadings irradiance loss, and 1.7% electrical loss, which is lower losses than the original model with 100%, according to strings. So, does the relative position of the "tables" in the view screen matter, or is all the shading calculated according to the positions in the near shading dialog? Also, regarding bypass diodes and MPPT, does the calculation assume that the inverter can "find" a maximum power point if the curve has multiple peaks and valleys? Thanks! -Debbie

Hello, I am using the module layout tool for the first time (version 6.25). My intention is to see the shading according to the module string wiring details. When I run the model with near shading according to strings, 100%, and without the module layout, I get 2.7% near shadings irradiance loss, and 4.4% electrical loss according to strings. When I run the same model after completing the module layout section, I get 25.1% near shadings irradiance loss, and 0 electrical loss. This does not seem right, perhaps I am doing something wrong in the module layout. Any advice?

So I developed a backtracking single axis tracking array with the details specified in both the orientation tab, and the near shadings dialog. When I ran the shading table, all values came up as zero (for beam, diffuse, and albedo). However, when I ran the model, there were several changes to the results, compared to the model with backtracking defined only in orientation. 1) Near shadings, irradiance loss was added (1.6%) 2) Far Shadings / Horizon loss decreased 3) IAM factor increased Is this what should be happening? Thanks! -Debbie

Hello, The text below is copied exactly from the help file in version 6.25. I would like to verify a few of the points : 1. Is it still true that if you develop a 3D sheds model, you should use fixed tilted plane in the orientation tab? 2. However, for a tracking array, from what I am reading, a 3D model should always be used? And then should the orientation tab also specify tracking? 3. Is it still true that the orientation tab does not include electrical cell effects for sheds? I thought that is what the electrical effect dialog is for.... 4. Is it still true that near shading should only be used for up to 50 sheds? Or has that limitation been removed by more recent upgrades, so long as one can wait a few minutes while it runs... Thanks, -Debbie ---------------------------------------------------------------------------------------- Near shadings and sheds In PVsyst detailed simulation, the mutual shading of sheds (or sun-shields) can be computed in two different ways: - By defining them in the "Orientation" parameters option. You have here to define general parameters of sheds (width, tilt, pitch, etc.) valid for the whole PV system, and the simplified computation is assumed to be "linear" (without electrical cells effects) and for unlimited length (that is, neglecting edge effects on both extremities of the sheds). - By explicitely defining a PV plane as sheds in the "Near shading" scene. In this case the computation accounts for shed edges, and a module partition can be defined. Please note that these two options should not be used at the same time, as the shadings will be accounted for two times !!! Definition by the "Orientation" parameter shed option This option is most suited when you have a field of numerous and little sheds (for example "one-module" wide sheds), sufficiently long as you can neglect the edge effects. Nevertheless, if you have to combine such an array with other surrounding shading obstacles in a near shading scene, you should define the basic array in the near shading scene as an horizontal plane, covering the sheds base extent (i.e. the whole area used for installing the sheds, on which the surrounding shadings will apply). This way the mutual shadings will be taken into account by the “plane orientation” shed algorithms, while the surrounding shadings will apply on the basis plane. This is of course an approximation, but the only way when the sheds are so numerous that the near shading complexity and calculation times become prohibitive. Shed definition in the Near Shading scene The "Near shading" shed construction should only be used when the number of sheds is less than, say, fifty sheds. The computing time and complexity of the shading factor calculation grows with the square of the number of elements. When you define sheds in the 3D scene, you have to choose a fixed tilted plane (not sheds) in the "Orientation" parameters, with the real values of tilt and azimuth of one shed. .

Hello, It appears that I cannot import site measured meteo data starting with POA if it is a single-axis tracking array (not fixed tilt). Is this correct? Because I don't see any opportunity to specify that this is POA for a tracking array in the ascii or PVsyst standard format procedures. However, if I export "Transposition factor GlobInc/GlobHor from my model that I wish to test with measured data, can I use that to back-calculate from measured POA to GHI? Does this make sense? Are there some risks in doing this? Thanks very much!

Hello, I would like to upgrade to the latest verion of PVsyst 6. However, I have previous models for clients that I would like to run in version 6.07. In version 6 will it work to install an older version over the current version, and then go back to the current version? Before installing an older version are there steps needed to uninstall? Thanks very much, Debbie Gross Blue Oak Energy