Jump to content

johank

Members
  • Posts

    28
  • Joined

  • Last visited

Everything posted by johank

  1. Hi, Would it be possible to create a new output variable for rear-side irradiance before shadings and IAM? This would more closely model the rear-side irradiance seen by a sensor and allow for more accurate performance evaluations on measured data. See related discussion here: https://forum.pvsyst.com/topic/2508-does-bkglobinc-variable-include-rear-side-shading-loss Many thanks!
  2. ... late to +1 but absolutely agree. For modeling performance from built systems (with measured data), sub-hourly clipping losses can be very large. For predictive models, you'd also need high-res meteo data. Not much available yet afaik, but looks to be coming more and more.
  3. ... right, clearly did not read that closely enough: it's the minimum ratio that was causing the error. As dtarin said above, the definition is different depending on which settings you're in: Advanced parameters: "shading scene active area" / "system definition active area". Project settings: "system active area" / "shading scene active area" (I think) Setting lower minimum ratios in advanced settings made the error go away. Yay!
  4. Gotcha, thanks Stéphane. In that case it seems like the custom "Maximum Field/Shadings Area Ratio" (80.0) from my example above isn't being used: field / shading area = 174683 / 6189 ~= 28.2
  5. Never mind, I re-created the conversion protocol (.mef) from scratch and now all appears to be well. Apologies for briefly reviving this thread, didn't appreciate how old it was.
  6. Stumbled upon this post after running into issues importing measured POA data (GlobInc) from a tracking system. The reverse-Hay transposition is giving very high AM DHI readings, see att. Is this something that isn't fully implemented yet or am I doing something wrong? The "measured global" shown in the chart looks correct. Thanks!
  7. Thanks dtarin! I have it set up as in the attached, the "80.0" for this project was a test to see if changing the parameter by-project made any difference (it did not). Stephane, thanks for the reply - how is the ratio calculated? I'm OK with a high ratio here, as it just needs to be a representative tracker block (for a large tracking array). There are no significant external shadings.
  8. ... as a follow-up: after copy/paste, the warning changed to "area ... is slightly lower" (i.e. no longer blocks running the sim) with a ratio of ~7. Running PVsyst 7.2.11 (24303).
  9. Hi, I have purposely set a high field/shadings area ratio but still get an error that "The area of the 3D fields is lower than the area of the modules defined in the subarrays." See screenshots - I think the ratio here is ~28, below the project's / default limit. Thanks!
  10. Hi PVsyst team, (Apologies if this exists & I missed it-) it would be great to set default Report Options (which pages are printed) globally in Preferences rather than having to specify for each report. E.g. I usually do not print "special diagrams" etc. Thanks!
  11. When importing a project, if prompted to overwrite existing files (e.g. .OND, .PAN etc. already in PVsyst workspace) the project will not import successfully unless I click "Yes to All". If "No to All" is clicked, no further message appears and nothing appears to be imported. Overwriting a single existing file - e.g. clicking "yes" on the first prompt, then "No to All" on the next - first gives the "Projects successfully imported" message but follows with the error message: "Can't open the file: [path]\[project].prj File not found" I would expect it to import regardless of whether or not existing / duplicate files are re-imported. Thanks! PS - projects I've attempted to import were all created with PVsyst 6.
  12. Got it, thanks. Is the rear IAM loss captured in one of the output variables? Finally found the help section discussing it, sounds like it always uses the "Fresnel-Glass" (non-AR) profile to calculate rear IAM loss.
  13. Thanks! So just confirming - it is after shadings, but no other losses are taken out of GlobBak? Would it be possible to add an "after losses" variable, something like GlobBakEff? And have GlobBak be the "before losses" rear irradiance, analogous to GlobInc. That seems more in line with how the front irradiance chain is handled. In the meantime seems just adding BackShd to GlobBak gives you the before shadings irradiance. I think it'd be worth clarifying in the variables definition in the help that GlobBak is after shadings.
  14. Thanks dtarin. I only recently learned that GlobBak is after shading (and IAM?). Would it be possible to split out irradiance before / after losses are applied? As far as I'm aware then there's currently not a rear-side parameter that corresponds to GlobInc. Having that would be very useful for performance monitoring & the like. See also this post by jmallineni.
  15. Thanks for the reply! Much appreciated. I assume the loss %s shown in the Iso-shadings diagram are calculated from the "according to strings" shading factors/table derated by the electrical effect %. Will have to try to confirm this at some point.
  16. Hi, Just wanted to confirm if the "FShdBm" parameter in hourly output files should correspond to what's displayed in the Iso-Shadings diagram ("Beam shading factor (according to strings)")? Specifically, wasn't sure if FShdBm also captures the "according to strings" loss but may not be thinking about that right. Thanks! Johan
  17. Hello! Would it be possible to add measured rear side irradiance as an import variable for custom (ASCII) meteo files? This would be useful for performance validation on bifacial systems. Thanks, Johan
  18. Thanks! After posting this the other day I realized that those may have reset after updating PVsyst. Seems those parameters are not saving when I close & re-open PVsyst. Also, why are these under "Verifications on General system parameters" and not "System design parameters, losses, shadings"?
  19. ... seems the forum won't allow more than one attachement, here's the second screenshot:
  20. Hi, I've been getting an error for "The Shading area is lower than the PV modules area." when opening projects created in older versions of PVsyst (6.73). See attached example, the system area to shading area ratio here is about 1.1 and the maximum (in project settings) is 2.5. Why is the error still coming up? Thanks, Johan [attachment=1]2018-12-07 15_41_06-Project settings.png[/attachment]
  21. Hello, Noticed today that the hourly soiling losses (SlgLoss) are all zero in hourly output files created with PVsyst v6.74. This is also true for the soiling loss components (beam, diffuse, albedo). The values are included in hourly files from v6.73, we will continue to use that for now. Thanks for looking into it.
  22. Hello- recently noticed that the .SIT file used is not included when exporting projects to a .zip archive using the "Files > Export Projects" tool on the main screen. This is occasionally problematic if another user imports the project and attempts to import a meteo file (e.g. from observed data). Is it possible to include the .SIT in the export by default? Thank you, Johan
  23. Hello, upgraded to version 6.6.1 recently. The improvements in the 3D shading editor are fantastic! However, noticed that shadow objects (treelines etc.) registered in Helios3D are no longer importing through the H2P file. This had been working when last used in v6.4.3. See attached screenshots. EDIT: found that the objects do transfer when saving the imported h2p as a .shd in 6.4.3 and opening the .shd in 6.6.1. Still, would be great to have the full import working in 6.6. Thanks! Johan v643 H2P v661 H2P
  24. I'm having the same issue in v6.52. I'm simulating SAT with backtracking and ran a few comparisons, attached. Setting azimuth in the 3D Shading Scene alone appears to only affect IAM loss, leading to a small reduction in GlobEff. It does not appear to affect incident (POA) irradiance, GlobInc. This was unexpected. Changing GlobInc required this: - define 3d scene, use "position in scene" (ctrl+b) to set azimuth - compute shading factors table - set azimuth under "Orientation" (it says it's w.r.t. to 3d shadings but I suspect that's not the case) This prints the correct azimuth angle in the report. However, the value under "Orientation" resets to 0 after the simulation. The change in GlobInc starts to be fairly significant for larger azimuths. Please advise. The forum does not allow adding xlsx, happy to send via email if it would be helpful. Thank you!
×
×
  • Create New...