[ENH] model half cells

[mikofski]

AFAIK there isn't a canonically accepted method to model half-cell modules in PVMismatch. I think it's possible to model a half cell by creating a total cross-tied module with 3 subblocks and 2 substrings of cells each, but it would require some mental accounting to determine the actual location of each cell when applying irradiance and temperature. Since PVmismatch always organizes cells into modules into strings into a system, the approach of putting two half-modules in parallel, then in series with more full-size modules wouldn't work

I propose a new cell_pattern template for half-cell modules, that is similar to the existing standard module. It would make the following assumptions:

1. the cells are always cut in half
2. the template is called a half_cell_module
3. the strings will always start in the center, one going up, the other down
4. there will be bypass diodes in the middle, which use the existing bypass diode conventions, eg: [2,2,2] means bypass diode every two columns
5. ~the cells will be numbered 0 to Ns (Ns=78 in the image below) in a top group and a bottom group, so top[0] is the first cell on the positive (left) side, at the bottom of the top module, top[12] would be top-left, bottom[0] is right next to top[0] and bottom[12] would be bottom left, etc.~
6. Np = 2 always
7. the existing cross-tie calculation chain would be used, it's just the mental accounting of where the actual cells are that the new template takes care of
8. ~setSuns() and setTemps() for half-cell modules would have to specify the top or the bottom as a new key in the cell position list, eg: setSuns({'cells': {'top': [0, 1, 24, 25], 'bottom': [0, 25]}, 'Ee': 817.1}~
9. ~if specifying irradiance for each cell individually, then use top and bottom to specify Ee, eg: setSuns({'cells': {'top': [0, 1, 24, 25], 'bottom': [0, 25]}, 'Ee': {'top': 817.1, 'bottom': [813.1, 789.9]}~

A half-cell module looks like this:

UPDATE 2020-06-01 I don't know why I was making this so complicated. So see the comment below, we can make these using partially cross-tied modules, then we just need to fix the indices so that they conform to the Cartesian coordinate system where the 0th cell is in the upper left corner, then each column of cells is numbered from top to bottom, top to bottom, until the last column with the last cell in the lower right corner. Also we'd need to make sure that the bypass diodes are working correctly.

[jalderman9]

@mikofski I'm brand new to pvmismatch and this is the exact module architecture I'd like to model. I'm in the process of trying wrap my head around the various cellpos patterns. You mentioned that it should be possible to build this module using the current module object builders. Can you provide any guidance on how I might do that?

[mikofski]

For a 144-halfcell module with 3 bypass diodes, similar to the standard 72-cell/3-bypass module.

from pvmismatch import *

# make a half-cell module similar to a standard 72-cell module
# 72-halfcells on top, 72 on bottom, grouped by 3 bypass diodes
# 48 halfcells per bypass diode spilt into 2 substrings (1 top + 1 bottom = 2)
# pvmodule.crosstied_cellpos_pat(
#     [<no. cells per substring>] * <no. bypass diodes>,
#     <no. subsrings per bypass diode>, partial=True)
# set partial=True so that not all nodes are cross tied 

halfcell144_bypass3 = pvmodule.crosstied_cellpos_pat([24, 24, 24], 2, partial=True)

# the equivalent standard module
std72 = pvmodule.STD72

It's not ideal because the indices no longer conform to a Cartesian coordinate system. The idea being that the upper left corner is the 0th index cell, then counting indices down to the bottom of the column, then continuing to count indices at the top of the next column, and so on. Instead halfcell144_bypass3 has these indices: However the I don't believe the indices are used for anything in PVMM, they're there for your personal use, and there's no reason you can correct them to be int he correct order. The bypass diodes, and cross-ties are determined by the nested grouping of the lists, and the setting of crosstie=True in the dictionary

[jalderman9]

Brilliant, thanks!

[mikofski]

@chetan201 you might want to label this as a good first issue, the solution is nearly in this thread, it just needs the indices reordered, while keeping the other dictionary and list items exactly the same.

@jalderman9 are you working on a publication? Perhaps you can cite PVMismatch? Thx. Also feel free to submit a PR for this issue if you have the bandwidth

[AugustVan]

@mikofski I have a question about the working of this PVmodule. I have created this module: STD132 = crosstied_cellpos_pat([22, 22, 22], 2, partial=True), and if I understand your explenation from above correctly this is what I have created: However the irradiance values for each cell I simulated with bifacial radiance have this format: Via the function setSuns I gave every cell a different value by making an array wich consits of 132 values and equated Ee with my irradiance file (code below). My question now is if the value "0" of the array I made is equal to the "0" of the STD132 module I made. Because if so then how can I make sure that the table of pvmismatch is equal to that of bifacial radiance. So that the irradiance values are properly indicated

[mikofski]

You have the correct cell indices for PVMismatch, so you just need to map which cells from bifacial radiance match them. For example, pvm_cell[76] = bifi_radiance_cell[0], pvm_cell[75] = bifi_radiance_cell[6], etc.

Also, please note that Ee is provided as units of "suns" not W/m2 which is explained in the documentation for PVsystem.setSuns(). Divide by 1000-W/m2 convert from W/m2 to suns.

Did the 2-diode coefficients from #158 work for you?

[AugustVan]

So just to be sure, if I give in this array for "cells": Will the index 76 of the 'stdpl' array be linked to the index 0 of the 'Wm2Back' array?

[mikofski]

Yes, according to the indices In your illustration above