jeffn

I don't fault you for making the graphical input. If the 90-red_dot_angle fix is implemented then the corresponding graphical intuition should be very helpful. Thank you for adding this item to your backlog. However, I strongly dispute your assertion that the current implementation is "improving" anyone's understanding of what is actually happening in the calculations. If it is used "intuitively" then wrong values will be entered into the text entries and the simulation results will not reflect the actual hardware design.

When simulating single-axis-trackers, limits affect the magnitude of deviation from a horizontal orientation: but when entering the corresponding limits in the Orientation dialog, the graphical “interpretation” assigns these angles to the post-to-limit angle, rather than the horizontal-to-limit. It is reasonable to indicate that some range of angles is not reachable (I would not have selected “green” as the color to reflect this restriction, but that is not material), but it is not reasonable to map the numbers in the numeric entries to that “green” region… they should be mapped to the complement (90-value) of that restricted region. The “workaround” is to ignore the graphical assistance and simply enter the correct numbers, but the graphical assistance is highly misleading to inexperienced engineers. Example of as-computed interpretation of tracker position angles Example of incorrect graphical representation of this limit, with added (black) correct representation

SFI files contain a specification for power units. Some file formats need W, others need kW, and when we load an SFI file the units appearing in the software and used when the simulation is run do not correspond with the SFI file units. Current workaround is to remember which units are needed and change them manually rather than using the information in the SFI file.

I am finding the new bifacial irradiance loss tree doesn't appear internally consistent? See two attached reports PVsyst v6.6.7 Test_Bifacial_Project_VC7.pdf (1 - 0.700) * ( 1 - 0.817 ) * ( 1 + 0.238 ) * ( 1 + 0.025 ) * ( 1 - 0.05 ) = 6.6% PVsyst reports 5.4% (1.2% discrepancy) Test_Bifacial_Project_VC8.pdf (1 - 0.700) * ( 1 - 0.898 ) * ( 1 + 0.230 ) * ( 1 + 0.022 ) * ( 1 - 0.05 ) = 3.7% PVsyst reports 6.2% (2.5% discrepancy) Test_Bifacial_Project_reports.zip Two examples of bi-facial irradiance loss tree discrepancies

Meteonorm 7.1.8.29631 Test location: South of Ayers Rock, Australia Latitude: -25.35 Longitude: 131.03 Elevation: 523 Timezone: 9.5 Meteonorm shows hill "under" the sun paths Export HOR file from Meteonorm Import HOR file into PVsyst 6.4.9 PVsyst shows hill beyond edges of plot (south; not under the sun paths).

There is no project to send. This bug is in the Heterogeneous Arrays Tool, as the subject line indicates. For example, use the following settings: Array nb 1 Mfr: Trina Solar PAN: Trina_TSM_305_P14A.PAN Nb modules in Series: 2 (This is the ONLY one that really matters) In parallel: 1 Plane Tilt: 30 Azimuth: 0 Albedo: 0.20 Array nb 2 Mfr: Trina Solar PAN: Trina_TSM_305_P14A.PAN Nb modules in Series: 1 In parallel: 1 Plane Tilt: 30 Azimuth: 0 Albedo: 0.20 Incident Irradiation Site: Detroit Date: June 26, 2015 Fraction of Clear Sky Irradiation: 100% Diffuse Fraction: 15% Click the Graph button. In 6.38 the "Resultant Pmp" is 587W and loss is reported as 100%, but in 6.25 the Pmp is 584W and loss is reported as 43.1%.

v6.2.5 Heterogeneous arrays tool reports reasonable value of mismatch (0%+) tested V6.3.5 and v6.3.8 Heterogeneous arrays tool always reports 100% mismatch.

What about the misalignment that occurs if more than four lines are entered into the Specificities? Is the intent that no more than four lines ever be entered, or just that such extra lines may be recorded in the PAN file but are not guaranteed to be recorded in the clipboard? Also, do you intend to cause the Remarks field to work properly?

We keep a library of modified PAN and OND files, and have in the past added lines to the "Specificities" text box to keep track of usage notes and references to source information. This use appears inconsistent with the contents of the clipboard when pasting into the Components.xls file since the columns seem to get misaligned. Is the official use of "Specificities" likely to continue to allow such information to be stored? We have observed that the "Remarks" field does not appear to save/restore at all from the PAN file, and our notes tend to take several lines ... we have considered putting a one-line file-path to an internal documentation directory or external web-page in place of such usage notes... if there were a dedicated field for such then we would use that.