gonecrawfishin

Has anyone found that the "edit orientations" option is no longer available if you import a .pvc file from PVCase? I just updated to PVsyst v 7.2.7 and am struggling to use my .pvc shading scene in the same way that I used to.

correction, I updated to v7.2.4 and I sometimes no longer get this error. I sometimes do though, and am not sure what I'm doing differently. Is there a certain order to entering data that needs to be followed? ---------------------- Has there been any resolution on this topic? I also get that error, and am not yet finding answers in the forum or help.

Help! When opening a new workspace, PVsyst cannot find the project that I was workign on previously, which is normal and typical of PVsyst. When I go to "open" to load the correct project file, I get a popup titled "TDOSMemStr" which says "Stream Read Errro". I cannot load any project files, and have to force close PVsyst. I just updated to patch 7.1.8, and cannot use PVsyst now. I tried it on multiple workspaces.

I am trying to simulate some 2-up portrait single axis trackers. Does PVsyst have a way to define the electrical effect, as it does with fixed tilt?

I found it yall!

That file is no longer available, does anyone know how to export a 12x24 table?

I think I'm trying to accomplish the same thing. I've used the peak shaving method, and am still finding quite a lot of losses due to batteries being fully charged. When I dove into hourly results, I see that the state of charge of my batteries almost never goes below 50%, despite my minimum discharge being set to 10%. The batteries are not "ready" to absorb the day's solar peak, and they are not discharging their full capacity during load peak hours. The model also does not seem to cycle the batteries every day. Is there a way to force a daily BESS operation in this way?

Same! Though we don't need the network license functionality. Following this thread.

Thanks for responding. We had not defined terrain, so steep slopes cannot be the problem. For whatever reason, PVsyst was creating tables on top of tables, so we manually deleted duplicates to get the simulation to run.

I've attempted to "Fill Zone" using the zone editor in the shading scene construction. I've got 0.20m spacing between tables, 0.02m defined in "field properties"-->"frame", and I don't even have "enable shadow casting" on. After I fill my zone and exit the shading scene construction, I get the following RED error (which won't let me proceed): "The object "Sample table #3, Zone #1" is penetrating the PV field "Sample table #2, Zone #1". For more reliable shading calculations, please ensure a minimum spacing of 2-3 cm between fields and other shading objects! All of my sample tables are automatically created by the zone fill function. How do I correct this error?

Is there a way to simulate shading impacts to discrete bypass diodes? For example, within a module I'm likely to lose voltage in groups of 3 when in landscape orientation, or 1 in portrait. For half cell modules, I'd lose voltage in groups of 3 in landscape, and groups of 2 in portrait. Would it be appropriate to define electrical effect on the mutual shadings based on these values, when they are not individual "strings" in the system definition, but rather individual circuits within the string? Update: I did just find this post https://forum.pvsyst.com/viewtopic.php?t=1594 helpful in understanding why not to consider bypass diodes when you have more than two strings per MPPT in landscape orientation. What about the other cases where bypass diodes do have an effect, such as 1-2 strings per mppt? What about when the whole array is shaded as one, such as a tracker array with 1 half-cell module up in portrait? When half of a module is shaded, all of the array is experiencing more or less the same thing (half voltage). In this scenario, would you recommend assuming 2 "strings" in the width of the single module? I suppose it's rather unlikely that you'd reach your minimum input voltage at the inverter, in that case.

Has anyone had success saving a .hor file from data downloaded from PVGIS? Here's an example of what I'm getting, no data points PVObject_=pvHorizon Comment=Horizon from PVGIS website API, Lat Version=6.83 Flags=$00 FracAlbedo=1.000 End of PVObject pvHorizon

When simulating battery storage, does PVsyst have a way to estimate heating & cooling loads as a function of ambient temperature?

In a load-less system, I would have expected system production to represent E_grid, particularly since what is sent to the battery is put onto the grid a few hours later. I'm not sure what the significance of "total system production" would be in a scenario like this, but good to know!

I am running simulations using the battery storage options, however no matter what size batteries I include, both in power & energy, my "Results Overview" provides the exact same "System Production". I finally realized that the "System Production" is inaccurate, or at least misleading, when compared to the results in my report. Screen clippings attached.

Ah, I just answered my own question. In case anybody else has this issue, I had accidentally tried to track from -45deg to -45deg, which admittedly is not a great idea.

Does anybody know how global incident in coll. plane could be negative? That's a new one for me. I just downloaded version 6.7.9, but it was able to successfully run some of my older tracker simulations just fine.

It seems to me that GlobEff should be less than GlobHor 100% of the time, because GlobEff includes some losses like IAM and shading. Why would GlobHor be less than GlobEff?

Holy moly, side note, when I compare the PSM v3 data to meteonorm or the Albany TMY3, it is HUGE, like, 1.5% more global horizontal. I tried the PSMv2, which required a 30 min time shift to match the clear sky model. In the end, it actually required a 5hr + 30min time shift, which starts to make sense. But when I compare that one to Meteonorm or TMY3, PSMv2 drastically underestimates production, like 1.5% less than MN/TMY3, 3% less than PSMv3. I'm new to using the NSRDB directly, but boy is it all over the place! Something is wrong, and I don't believe I am using this data correctly yet.

Well that's just baffling, I used your MEFv3 file and got completely different results, see attached (left). I am not downloading from NSRDB in 30 minute intervals & do have that unchecked. I'm questioning the difference in definitions of what, for example, 10am *means* for NSRDB vs PVsyst. But perhaps, as long as I can brute force PVsyst's time shift comparison to the clear sky model, then that's the best I can hope for. I added an hour and "the Meteo file seems to be OK". Unnerving, but ok. I'm really appreciating the help so far.

I think I'm getting closer. I had been using the instructions of two different posters on this thread together. Ok, so I checked "convert UTC to local time" when downloading a site in New York. In my MEF file, I have my time base is universal time and a +5 hour shift entered. I'm still getting an error of "The imported meteo data are shifted by -59 minutes with respect to the Clear Day model." Why might that be? On the side, I tried having NSRDB leave the data in UTC then I changed the MEF file to have no time shift and I got "The hourly data are not defined. This meteo file is unuseable for simulations!". So, there I go moving backwards again. Additionally, it was my understanding that the NSRDB PSM v3 data represents instantaneous values (or for some values, averages centered at the time label)? The PVsyst help menu seems to indicate that it is calculating solar position based on the half hour, so a value with a 10am time label is paired with a solar angle at 1030am? Thoughts on what would be most appropriate to account for that? If I brute force trial and error this until I get a green message from PVsyst, am I in the best place, or should I be adding in 30min offsets because I know better than PVsyst?

It's not clear to me what time shift is appropriate. I downloaded NSRDB data and did not select "convert UTC to local time". I then used the .MEF file which was posted by solarguru on 10/17/16 which included a shift of 5 hours. My site is located in UTC-5. I'm getting errors that "GlobHor" data is undefined, and also that my time seems mismatched. Does anyone know what the most appropriate way is to treat NSRDB data, specifically PSM v3?

Sometimes, when I go to import PVsyst project and components and try to Browse for Folder, my drive is not completely mapped. It will show just one folder within the drive rather than all of the folders, and I can't figure out how to import files from another portion of that drive. In this example, project 4715.32 is just one of hundreds of folders within "WORK". I can't find any "map drive" type options when I right click. I can navigate to all my folders if I take the "open zip file" route so I have a workaround, it just doesn't seem like that should be necessary.

All, I learned that the image was not importing because it was too large, not in file size (it was <1MB) but in number of pixels. After reducing resolution, I was able to import the image. The help section's explanation of the transformation tools are still very unintuitive. I got this to work: It seems x1 and x2 are only used in rotation, not scaling. They are just two points (in the original coordinate system when the image is imported) that will be rotated to be the x (west-east) axis. I accomplished scaling by entering a value in "image base width", or the width of your full image. "Distance x1->x2" doesn't seem to do anything, though. I left it at the default "100m" and my image scaled properly, even though my actual distance from x1->x2 should be 585.2m. -Jen

All, I walked through it all with Arno of PVsyst, and found that you actually have to define "zones" within the shading scene construction, and fill it with "tables". The orientation parameters should be using "fixed tilt" not "unlimited sheds". This youtube video was really helpful for me. https://www.youtube.com/watch?v=_RbsIDEl2PU&feature=youtu.be -Jen