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