Modeling PV system - defining system size and DC output NaN values

[Dharik Mallapragada]

Hello, 

I am trying to develop a simple example for students in my class to play around with PV system design to understand the impact on output and ran into two issues that I was hoping to get some help with:

1.  The DC output time series is filled with NaN values for all the hours when AC output is zero. This only happens when the mount is set to "SingleAxisTrackerMount" and not with  FixedMount. Is it odd to get NaN values in the DC output?

2. I would like to simulate the performance of PV system with 100 MW DC capacity but could not figure how to set it up correctly. As a workaround, I decided to simulate a 25 4 MW DC capacity systems, where this is modeled with the following properties: module power = 400 W,  modules per string = 1000, strings per inverter =10.  

Is this a reasonable way to approximate 100 MW DC capacity system?

I am attaching my code

Thank you,

Dharik

[cwh...@sandia.gov]

Hello Dharik,

1. I see that are NaNs in the intermediate output as well: aoi, iam, for example. Something we should look into to find out where in the modeling chain the NaN is introduced.

2. pvlib currently doesn't support PVSystem with more than one inverter. You could model one PVSystem and multiply the AC power. Setting up a PVSystem with 1000 modules in series in each string is OK as long as the DC power model is PVWatts and the inverter model is also PVWatts. If someone switched to one of the other DC or AC models, then the strings would need to be commensurate with the inverter characteristics.

Best regards,

Cliff

[Will Hobbs]

Cliff,

pvlib.tracking.singleaxis() returns NaN for intervals where the sun is below the horizon. I think that is the reason that NaN values show up in other outputs for tracking systems. The first thing I typically do after running singleaxis() is a `.fillna(0)`...

Will

[cwh...@sandia.gov]

Will,

Thanks! Appears to happen here: https://github.com/pvlib/pvlib-python/blob/6dfeaf8ee97db6a7a8f3c8109eed8b5d285c4e41/pvlib/tracking.py#L155

It's worth a discussion if that's something pvlib should change, or whether '.fillna(0)' ought to be part of the singleaxis function.

Cliff

[Will Hobbs]

Cliff,

I found zero vs nan briefly mentioned a few times here https://github.com/pvlib/pvlib-python/issues/569. I didn't notice any clear opinions/justifications for either option, though.

Should we start a GitHub discussion or issue on the topic?

Will

[Will Hobbs]

FYI, I created an issue on the NaN vs zero topic: https://github.com/pvlib/pvlib-python/issues/2539.

Will

[Angelos Wafik]

Cliff, Will,

I appreciate this conversation, but I am in Nan values team, for these reasons:

1- how can you differentiate between zeros during the day (if you had) and non applicable values during the night?

2- it's an easy way to drop all nans, so you can have the target operation hours by sun. 

3- Unfortunately zeros will affect all your statistical operations, you will have the wrong median.

greetings

--
You received this message because you are subscribed to the Google Groups "pvlib-python" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pvlib-python...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pvlib-python/8cfc121e-c14d-4491-a3bb-e2fee5406b2en%40googlegroups.com.

--

----------------------------------------------------------||
Angelos Wafik

[Will Hobbs]

Angelos,

These are all valid reasons to keep NaNs. I think that solar position data could also be used for filtering to get at the same goals. I’d encourage you to bring this up in the GitHub issue I started. 

At a minimum, I think the inconsistent nighttime output from model chain for fixed vs tracking is confusing, especially to newer users, and that should probably be reconsidered.

Will

To view this discussion visit https://groups.google.com/d/msgid/pvlib-python/CAPBOex6sOgO2AsXLHvu1v76zg3WheX-0VrQ1dWmQBffTwR01PA%40mail.gmail.com.