expose pvlib.irradiance.dni() in API?

[Mark Mikofski]

This is a super cool function, IMO, but there's no mention of it anywhere, despite the long docstring, and lack of preceding underscore:

https://github.com/pvlib/pvlib-python/blob/master/pvlib/irradiance.py#L2812

def dni(ghi, dhi, zenith, clearsky_dni=None, clearsky_tolerance=1.1,

        zenith_threshold_for_zero_dni=88.0,

        zenith_threshold_for_clearsky_limit=80.0):

    """

    Determine DNI from GHI and DHI.

    When calculating the DNI from GHI and DHI the calculated DNI may be

    unreasonably high or negative for zenith angles close to 90 degrees

    (sunrise/sunset transitions). This function identifies unreasonable DNI

    values and sets them to NaN. If the clearsky DNI is given unreasonably high

    values are cut off.

    Parameters

    ----------

    ghi : Series

        Global horizontal irradiance.

    dhi : Series

        Diffuse horizontal irradiance.

    zenith : Series

        True (not refraction-corrected) zenith angles in decimal

        degrees. Angles must be >=0 and <=180.

    clearsky_dni : None or Series, default None

        Clearsky direct normal irradiance.

    clearsky_tolerance : float, default 1.1

        If 'clearsky_dni' is given this parameter can be used to allow a

        tolerance by how much the calculated DNI value can be greater than

        the clearsky value before it is identified as an unreasonable value.

    zenith_threshold_for_zero_dni : float, default 88.0

        Non-zero DNI values for zenith angles greater than or equal to

        'zenith_threshold_for_zero_dni' will be set to NaN.

    zenith_threshold_for_clearsky_limit : float, default 80.0

        DNI values for zenith angles greater than or equal to

        'zenith_threshold_for_clearsky_limit' and smaller the

        'zenith_threshold_for_zero_dni' that are greater than the clearsky DNI

        (times allowed tolerance) will be corrected. Only applies if

        'clearsky_dni' is not None.

    Returns

    -------

    dni : Series

        The modeled direct normal irradiance.

    """

    # calculate DNI

    dni = (ghi - dhi) / tools.cosd(zenith)

    # cutoff negative values

    dni[dni < 0] = float('nan')

    # set non-zero DNI values for zenith angles >=

    # zenith_threshold_for_zero_dni to NaN

    dni[(zenith >= zenith_threshold_for_zero_dni) & (dni != 0)] = float('nan')

    # correct DNI values for zenith angles greater or equal to the

    # zenith_threshold_for_clearsky_limit and smaller than the

    # upper_cutoff_zenith that are greater than the clearsky DNI (times

    # clearsky_tolerance)

    if clearsky_dni is not None:

        max_dni = clearsky_dni * clearsky_tolerance

        dni[(zenith >= zenith_threshold_for_clearsky_limit) &

            (zenith < zenith_threshold_for_zero_dni) &

            (dni > max_dni)] = max_dni

    return dni

[William Holmgren]

It should be in the API reference but I do not see it. Looks like a bug. Pull request welcome.

--
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 post to this group, send email to pvlib-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pvlib-python/12a63961-048b-40ea-ac43-d4c04ffccd87%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark Mikofski]

created an issue: https://github.com/pvlib/pvlib-python/issues/686

I'll leave it for someone to take up as a first time contributor

To unsubscribe from this group and stop receiving emails from it, send an email to pvlib-...@googlegroups.com.

[Debayan Paul]

Hi,

I am using this function to calculate dni values from the dataset in which I have ghi and dhi values. I also created the clearsky of ineichen model: but still getting some very high peaks (around 1600W/m2). I have also dni values in the dataset, but I am not sure of their reliability, unfortunately.

I am wondering if these two arguments(zenith_threshold_for_zero_dni,zenith_threshold_for_clearsky_limit) are good with the two default values 88 and 80 respectively, or need to be altered, depending on the location.

Also if someone knows which DNI estimator model performs better, please let me know.

Thanks,

Debayan

[Mark Mikofski]

Hi Paul,

I am curious, what is the time-scale of the GHI/DHI data that you have? Is it minute resolution data?

• It is not uncommon for minute scale data to have very high instantaneous DNI values. I think this caused by clouds focusing sunlight slightly, some light get's concentrated and some is scattered making patchy distributions on the ground, you can see this sometimes from an airplane. I think it's similar to an office building that has a curved concave glass surface
• Have you tried using just the GHI data and using the something like the Erbs decomposition model? https://pvlib-python.readthedocs.io/en/latest/generated/pvlib.irradiance.erbs.html#pvlib.irradiance.erbs and compare the DHI and DNI you get from that? I believe that GHI measurements are a little more reliable than DHI measurements, because similar to DNI, a DHI measurement either needs to track the sun, or uses a  rotating shadowband radiamoter which have a low accuracy, and therefore a DNI calculation from GHI and DHI would have a high uncertainty as well.

check out the solar calendar from the NREL MIDC Solar Radiation Research Lab near Denver

https://midcdmz.nrel.gov/apps/sitehome.pl?site=BMS  

Here's an image from a day in July, and you can see instantaneous DNI is over 1200 Wm-2

https://midcdmz.nrel.gov/apps/plot.pl?site=BMS;start=20171201;edy=31;emo=12;eyr=9999;year=2019;month=07;day=4;time=1;zenloc=209;inst=3;inst=55;inst=69;type=plot 

--
You received this message because you are subscribed to a topic in the Google Groups "pvlib-python" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pvlib-python/aa-bZPXuohc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pvlib-python...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pvlib-python/901c6a16-3073-47da-884c-49cea3124978%40googlegroups.com.

--

Being deeply loved by someone gives you strength;
loving someone deeply gives you courage.
Lao Tzu

[cwh...@sandia.gov]

Hi Paul,

If those plots are one year of results, there's something wrong either with the plots, or with the data being plotted.  Can you isolate just a few days and show that plot?

I'm guessing you are seeing very high calculated DNI at high zenith, when measured GHI and DHI values are quite low, and subject to greater proportional error due to the sun being right near the horizon. The thresholds are a convenience to help with these circumstances, and you should feel free to adjust them to suit your analysis.

Cheers,

Cliff

[Debayan Paul]

Hi Mark,

My data frequency is indeed minute resolution for like 8 months.

This time I also applied the Erb's model as you suggested,

#for Erb's model

dniorderedDictList=pvlib.irradiance.erbs(sampledfDNI['global_horiz'], solpos['zenith'], sampledfDNI.index, min_cos_zenith=0.065, max_zenith=87)

dnidf=pd.DataFrame(dniorderedDictList, columns=dniorderedDictList.keys())

sampledfDNI['Erb dni']=dnidf['dni']

#from irradiance function

dniseries=pvlib.irradiance.dni(sampledfDNI['global_horiz'], sampledfDNI['diffuse'], solpos['zenith'], clearsky['dni'], clearsky_tolerance=1.1, zenith_threshold_for_zero_dni=85.0, zenith_threshold_for_clearsky_limit=80.0)

dnidf=pd.DataFrame(dniseries.values,columns=['value'])

dnilist=dnidf['value'].tolist()

sampledfDNI['Irradiance model dni']=pd.Series(dnilist,index=sampledfDNI.index)

sampledfDNI['Irradiance model dni']=pd.Series(dnilist,index=sampledfDNI.index)

where sampledfDNI, is a dataframe created from my 1-minute frequency dataset which contains ghi, dhi & dni(which maybe error-prone, but the maximum value present is 1005 W/m2). solpos is created in pvlib using location information. I replaced the negative values with zero before plotting.

For the plot attached, I filtered a few days, to visualize it more easily.

I am looking for a suggestion or solution which can lead me a realistic dni value(within 5-10% tolerance of actual, if measured), independent of the frequency & location of the dataset. Maybe a sort of filter or adjustment in the argument's value rather than the default.

On Tuesday, April 9, 2019 at 12:16:03 AM UTC+2, Mark Mikofski wrote:

[cwh...@sandia.gov]

From this plot of 4 days, I suspect there's an error somewhere in the code. Perhaps double check the timestamps on the GHI data (are they in the correct time zone?) and the lat/long. Does a plot of GHI vs. zenith look correct? It looks like high GHI is being paired with high zenith.

[Mark Mikofski]

I agree with Cliff, the irradiance diurnal profile is usual symmetrical and kind of sinusoidal for GHI. Direct looks like a pillbox with steep sides, and a rounded top, again here's an image of typical day from MIDC SRRL baseline measurement station in Denver for July 9th, 2019, sorry there're a few clouds in the afternoon, but I think you get the picture:

https://midcdmz.nrel.gov/apps/plot.pl?site=BMS&start=20171201&edy=9&emo=1&eyr=2020&zenloc=209&amsloc=211&year=2019&month=7&day=9&endyear=2019&endmonth=7&endday=9&time=1&inst=3&inst=4&inst=5&inst=60&inst=69&inst=70&type=plot&wrlevel=6&preset=0&first=3&math=0&second=-1&value=0.0&global=-1&direct=-1&diffuse=-1&user=0&axis=1 

Your data looks like it's shifted in time by about 6 or 8 hours, which as Cliff suggested, implies that the timezone is off. This is a frequent dilemma when using pvlib and pandas, search through the group archives and SO questions, and you'll see folks ask it a  lot.

Can you share some of your data, or try to use something like pandas tz_convert to change to one of the Etc/GMT+<tz> timezones and try again?

And I agree, filtering will help with sunrise/sunset, that's what the zenith limits of 88-deg are for.

thanks,
Mark 

--
You received this message because you are subscribed to a topic in the Google Groups "pvlib-python" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pvlib-python/aa-bZPXuohc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pvlib-python...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pvlib-python/d1b20ec1-074f-418c-9645-4a36b37670ca%40googlegroups.com.

[Debayan Paul]

Hi Mark,

The original data comes in Central European Time zone with Day Light Saving of 1 hour from around 31st March to 27th October. I shifted the time index during DST only by 1 hour backwards using timedelta of pandas and created solarposition with datetimeindex of that DST adjusted index.

#solpos = pvlib.solarposition.get_solarposition(dfDSTadjusted.index, location.latitude, location.longitude, altitude) 

I am sharing some data(negatives are randomly created, I replaced them with 0) in the attached. I haven't used the timezone as an input argument anywhere. If I still need to make the data timezone aware, please suggest me. Meanwhile, I will look for the topic in the group.

Thanks,

Debayan

On Tuesday, April 9, 2019 at 12:16:03 AM UTC+2, Mark Mikofski wrote:

[Mark Mikofski]

yes, you must make the data timezone aware. I apologize for the inconvenience, and please let me know if this is not clear from the documentation. Otherwise, I think Python will use your local timezone, or something like that.

Try:

>>> dfDSTadjusted.tz_convert('Etc/GMT-1')

--
You received this message because you are subscribed to a topic in the Google Groups "pvlib-python" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pvlib-python/aa-bZPXuohc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pvlib-python...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pvlib-python/a6fc1d84-76a1-4299-bd3a-241777d79053%40googlegroups.com.

[Hansen, Clifford W]

Agree with Mark. I would avoid adjusting for DST manually; read in the timestamps and use tz_localize() to set the appropriate timezone.

--

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 on the web visit https://groups.google.com/d/msgid/pvlib-python/CALGe1A0PqMgKcdZY9F5%2Buz_ZF68hd83uBpn3RtrANi43aWQB4g%40mail.gmail.com.

[Debayan Paul]

Hi,

I localized the data to 'UTC' and it solved the problem as I figured out that my timezone naive datetimeindexes were being treated as default in 'UTC' in PVLIB. The angles were actually coming in a different timezone than CET.

Thanks, everyone for your help.

Thanks

Debayan

On Tuesday, April 9, 2019 at 12:16:03 AM UTC+2, Mark Mikofski wrote: