Peter.W

I wanted to get a little clarity on muVoc mV/°C vs %/°C. We have often done string sizing calculations by hand by using the %/C value on the data sheet but when using the same temperature values we receive a close but slightly different maximum Voc value. For example: STC 25°C with an absolute low of -14°C. VOC Coef = -.0026V/C string size of 18 Starting Voc of 49.8 (-14 - 25)(-.00265)(49.8)+49.8=54.95VocMax 54.95*18=989V a -14°C system with a Voc Coef would indicate a max voltage of 983.33 for a string of 18 with an VOC of 49.8 and a VOC Coef of -.265% for a 25°C STC system. The pan file indicate a muVoc of -150mV/°C. When I use the Pan defined MuVoc value It indicates the max Voc at 994V, if I use the one diode model we see a max Voc of 999V. This isn't a problem with this solution as both methods are in are inverter range, but we have run into being a large enough discrepancy. Essentially, PVsyst indicates we should lower our string size, but the datasheet calc indicates we are in an acceptable range. I have tried to read the Module parameters section of the help section and it indicated the one diode can no longer be edited because its an R shunt and R series calc. Values which I wouldn't know where to start with. Any advice on this subject would be greatly appreciated on why these values aren't inline and if its a problem to proceed with the one calculation over the other would be greatly appreciated. Pan defined MuVoc Pan File One Diode model

Hello Michele, I wanted to ask a follow up question regarding partitions as we would like to evaluate First Solar's Cadmium telluride modules. As these don't have internal diodes similar to the case studies we mentioned above, I was curious which modeling practice would be more accurate to have the modeled according to linear shading or to have them defined as partitions for the whole string. For example a SAT system with 108 modules but strings of 6 would look like this. My assumption would be that we would still use partitions, but any guidance you have would be greatly appreciated.

I updated the local time to 0 (it was previously -6) and am still getting a 360 minute time shift error.

Hello, I was trying to create a .Met and .SIT file for an NREL meteo file. I used the "NREL NSRDB Hourly TMY" Data source and received an error for a 360 minute timeshift. I don't completely understand the functionality of timeshift, but after looking into there didn't seem to be a way to fix the error while still using the "NREL NSRDB Hourly TMY" source. My attempted solution was to take the NREL data and convert it to a PVsyst Standard format with the command #timeshift 360 in the 1st and second column. It appears to have updated the timeshift although I do get two errors now. I get a comment that "This file is not a valid PVsyst Standard Meteo file the line definining the unit is empty or missing". It still lets me go past this where i further receive the error invalid meteo file time shifted by 0 minutes. How can I go about fixing this?

I have been trying to better understand the batch simulation tool in Pvsyst. I was able to create a SAT model that will allow me to run batchs that adjust for both pitch of E/W trackers and number of strings. I have struggled to replicate a similar experience with a FT system. I can edit by pitch and by strings for an unlimited shed scene. Is there a way to edit by pitch and strings for a fixed tilted plan with a shade scene?

Thanks @Michele Oliosi, This has given me a pretty new and deeper understanding of partitions. I did have one more case study based on this guidance, but it is isn't related to Rooftop systems and is instead related to Single Axis Tracker systems, using half-cut modules. This would be for a 1 in "portrait" with strings around 25-30 long. I currently define 2 partitions for each string essentially cutting the strings in half into two electrical zones. Is this what you would recommend? I have attached an image for 1 string. If this were two in length, I would change the inputs to "2" in length and "2" in width.

@Michele Oliosi I think that makes a lot of sense, but this did muddle my understanding of the Fraction for Electrical effect. I take it when this percentage is used at below 100% it isn't "adding" diffused light than. For example I would have thought with a tree where light is still seeping through branches there would be an increase diffused light making it to the modules, but based on the guidance you have given and my review of this section in the help guidance my understanding was incorrect. Does this fraction only affect the the direct light and its effect on those partitions? I am not entirely understanding the use of "regular" in the guidance.

@Michele Oliosi. That’s interesting I have noted that the more partitions defined the less shading and electrical losses due to Shading effect our systems. I’m a little turned around if we are trying to compensate for diffused light due to the electricity that could still be generated from non direct light wouldn’t we want more partitions not less? This approaches feels more conservative than the how the submodules already act.

Oh interesting @Michele Oliosi! I would have thought based on the guidance for tables (shown below) two high that it would have had partitions defined as the whole module or as three rectangles. Is it due to the optimizers or the modules being defined individually that we would cut it in half (see the second image?

@Michele Oliosithanks! I do need a little clarification though. When you are saying put 2 partitions in height, do you mean that in the settings it would be 1x2 creating 3 long rectangle?or are you saying essentially cut the module in half with a partition? thanks,

How should the partitions be set up in the near shade for the following scenario? We are using half cut cells with optimizers connecting every two modules. We are importing our shade scene so the tables each represent a singular module in landscape. Based on the guidance for partitions systems with "little" tables partitions should be 1x1, but for the section "Defining rectangles as one module/ module optimizers" indicates that rectangular strings should represent 1 to 2 modules(2 in our case). Additionally the section before "String Optimizers" mentions that for landscape the best model is two partitions per row. So i believe there are two options Partitions of a 1x1 per table which defines a whole module (this is problematic because the optimizers connect every 2 modules). Partitions of a 1x3 per table which cuts a module into three landscape based rectangles (this is problematic because the optimizers connect every 2 modules).