MNWild

Following

Is module area the area with user entered frame, or user entered inactive bands, without? Or is the area based on dimensions in .pan file? Is it supposed to be cell area etc?

Instead of throwing a cryptic error, may I courteously propose the software spits out a dialog box that contains all those words from your June7 response?

Bothersome phenomonon indeed. Wish I didn't have to work around this and trick clients or claim pvsyst doesn't let us type in the correct values. Either your GCR will read wrong (not equal to module datasheet length/pitch), or your backtracking limit angle will be wrong, or your sensitive area, or your actual 3d scene module width or length idk which. It's very inconsistent. Inactive Band Left Right, Inactive Band Top Bottom, bandwidth X spacing, Y spacing Frame L/R T/B Backtracking Limit angle, GCR, and bifacial section's version of above conflicts on report batch version of above We have to parameterize all this information and test every revision to understand what pvsyst thinks it's doing, vs what it says it's doing, vs what help file says its supposed to do, vs what is on report, vs what forums answers say, vs orientation tab, vs 3d scene, vs bifacial page. All definitions overlap and change depending on if you are in shading scene or elsewhere in program.

For trackers it doesn't equate to logical sense. X axis in shade scene is east west. But a single axis tracker's "X spacing" will actual spread the modules further apart in the Y direction along length of tracker which is the "Y axis in shade scene". Typing a value in the "Y spacing" of .02m or 10m doesn't appear to do anything to the tracker dimension because the modules are 1 in portrait along single axis tracker n/s. **1 in portrait I should clarify further even: meaning industry standard description of the long side of module set E/W and module short width is N/S...pvsyst may or may not have "portrait or landscape" label correct in 3d scene for 1-axis trackers depending on the version you're using. So you have to sanity check all the visuals and measure stuff until you get fired for taking so long to model a solar site.

This has been a problem for years. Looks like in in the release notes from 7.x.18 the latest release they actual fixed the ability export the .met finally. But not .sit. So the export project function is useless and confusing. Also, Does software still not export the shade scene as well? We've been manually hunting and pecking to compile all files for sharing with outside entities.

Let's say I wanted obtain a more accurate value for actual inverter setpoints in 8760(closer to reality): 1st: Would I have to run PVsyst once with default(non-separated) grid limitation setting to get cleaner* 8760 of inverter output set points. 2nd: Then run PVsyst 2nd time: selecting the grid limit setting to "account as separate loss". Then Pull this separated clipping "loss" from 8760. 3rd step: Would I subtract the 2nd step's "separated clipping loss" in 8760 from the 1st step's Inverter Output 8760? Is there a method to avoid two models? *I deduced above because you stated the default grid limit settings(non-separated) 8760 will contain clipping "losses" inside "overload loss" 8760 field...But that 8760 field "overload loss" contains other losses. So a user can't simply subtract "Overload Loss" 8760 from the inverter output 8760 field to obtain inverter set-point closer to real world? Note: I forget the sign convention off top of my head for these 8760 fields, but let's assume everything is positive: clipping losses and inverter output. Example so when I say subtracting I mean: 121MWinverter output - 20mw Clip will get us to 101MW inverter set point.

What great news on Valentine's day. Wonderful to hear.

thumbs up emoji

+1. Nearly impossible to review and compare what a user enters vs what's shown in PVsyst. We never know if the black box is propagating a rounded value or a magical unseen entered digit exists. Makes for more meetings too.

+1

?

+1, thanks for sharing issue. I would have thought PVsyst would separate xfmr loss and ac loss with independent Bases especially since the new transformer section allows user to type in a kVA rating. This applies to MV and HV tranformer "Nominal Power" under Datasheets section. Also, if your transformer nominal power typed in is too large PVsyst will error as well. Example xfmr is 8000kva and inverter nom is 3000 from .ond. "HV transfo: The Transformer nominal power is far higher than the maximum output power of the inverter, i.e. Future Development Request: AC loss section & new MV cable section to provide similar flexibility similar to the new transformer section appears to have in v7. Allow user to type in custom base rating and type in %ac ohmic or kw cable loss instead of forced into a base of Pac(stc)=Pdc(stc)*(efficiency).

Looks like PVsyst just released a 64bit version. Trying figure out how to download but I thought I would respond to this thread. In version 7.0 (25.05.2020) 5.25.2020 May 25th. New features: Support of 64-bit architectures : this will extend PVsyst capabilities of handling large projects and shading scenes Irradiance: new improved treatment of the circumsolar component, impacts on the electrical shadings and vertical Bi-facial systems System : unlimited number of sub-arrays Shadings : conversion of fixed tables to trackers, new trackers with central gap parameter for bifacial, import of trackers from Helios3D, import of PVC files Output AC circuit : definition of several MV and HV transformers, with their specifications Live results display : see results values and graphs while the simulation is running Economic evaluation : Levelized Cost of Energy (LCOE), Net Present Value (NPV), multiple loans of multiple types, advanced depreciation configuration Economic evaluation : now available for Stand-alone and Pumping systems Simulation : display of warnings during the simulation and with the results Improvements: Module Layout: great improvements in submodule shading calculations accuracy, print of the layout has also been improved and can now be printed in the report User interface : improvements of the user interface and user experience License management simplification Localization : full-software translation coverage (except the Help), Turkish and Korean languages now available

I'll private message a work around I've used. I wish I would have read this sooner since some time has past now.