[Split GlobBak into GlobBakInc and GlobBakEff]

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!

[Support for sub hourly]

... 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.

["Maximum Field/Shadings Area ratio" ignored]

... 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!

["Maximum Field/Shadings Area ratio" ignored]

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

 

[POA import diffuse and global in module plane]

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.

[POA import diffuse and global in module plane]

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!

["Maximum Field/Shadings Area ratio" ignored]

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.

["Maximum Field/Shadings Area ratio" ignored]

... 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).

["Maximum Field/Shadings Area ratio" ignored]

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!

[Set Default "Report Options" in Preferences]

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!

[v7.2.8: Import Project - must overwrite files]

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.

[Does BkGlobInc variable include Rear Side Shading loss?]

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.

[Does BkGlobInc variable include Rear Side Shading loss?]

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.

[Does BkGlobInc variable include Rear Side Shading loss?]

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.

[FShdBm and Iso-Shadings Diagram]

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.

[FShdBm and Iso-Shadings Diagram]

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

[Bifacial: importing measured rear side irradiance]

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

[Array field/Near shadings area ratio (6.7.6/6.7.7)]

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"?

 

[Array field/Near shadings area ratio (6.7.6/6.7.7)]

... seems the forum won't allow more than one attachement, here's the second screenshot:

 

[Array field/Near shadings area ratio (6.7.6/6.7.7)]

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]

[Hourly soiling loss values in v6.74]

Thanks for the fix!

[Hourly soiling loss values in v6.74]

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.

[.SIT file in Project Export .zip]

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

[Helios3D import in v. 6.6.1]

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

[Axis Azimuth with SAT in v6.47]

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!