add translator for OND files

[cwhanse]

• Closes #xxxx
• I am familiar with the contributing guidelines
• Tests added
• Updates entries in docs/sphinx/source/reference for API changes.
• Adds description and name entries in the appropriate "what's new" file in docs/sphinx/source/whatsnew for all changes. Includes link to the GitHub Issue with :issue:`num` or this Pull Request with :pull:`num`. Includes contributor name and/or GitHub username (link with :ghuser:`user`).
• New code is fully documented. Includes numpydoc compliant docstrings, examples, and comments where necessary.
• Pull request is nearly complete and ready for detailed review.
• Maintainer: Appropriate GitHub Labels (including remote-data) and Milestone are assigned to the Pull Request and linked Issue.

This discussion on the pvlib Google group showed code for translating the content of a PVsyst OND file to parameters for inverter.sandia. An OND file has sufficient information to fit the sandia inverter model to get the four empirical parameters C0, C1, C2 and C3.

Do we think a translator (ond_to_sandia_inv) is useful? I put it in pvlib.inverter because the translation is specific to the target model (sandia) and would be different for the ADR inverter model.

There are some content of the OND file (number of MPPT inputs, for example) that are useful but not for the inverter functions, rather, for the higher-level modeling objects (number of Arrays connected to an inverter). I'm not sure what to do with these (yet).

I don't know if this example OND file is typical of all files. Reading this file points out some possible improvements:

• in iotools.panond.read_panond, the OND structure is returned in this pattern {'PVObject_': data}, where data is a dict that has actual values.
• should read_panond default to UTF-8 encoding?
• inverter.fit_sandia says it accepts "array-like" inputs. Should "array-like" include lists? They don't work.

[fredrbl]

@cwhanse This is a very useful feature for us, we are working with this right now. So great that its being worked on, highly appreciated.
I looked at the google discussion and the code here, and the different validations. As far as I can see, this is only validated for one inverter? And, is there any reason to why it could perform worse for another inverter type/model?

In any case, I can pull the code here and implement it for our use case. If I see any improvements, I can post it here.

[cwhanse]

this is only validated for one inverter? And, is there any reason to why it could perform worse for another inverter type/model?

Yes, only one OND file. That's all I had on hand. I suspect the algorithm will work as well for other OND files, and where it fails its probably more of a problem with the model being fitted, than this fitting process.

Appreciate any help getting this to ready for merge!

[adriesse]

All of the above could be useful for fitting another model too. Perhaps we could make that a separate function called extract_inverter_characteristics?

[ErlingxIFE]

Hi!
I've looked at validating some some OND Files for the translator. I've found that many OND files lack the required data for the translator to extract parameters. Especially night time consumption and measurement points at different voltages. Although my sampling of OND files is likely not representative.

For some files with all parameters present, I've looked at the difference between Sandia parameters extracted from the OND files vs. parameters from the CEC database, there is some variation depending on the inverter used, sometimes on either side of 0:

(In this case 4 inverters from Fronius (Fro) and 4 from Canadian Solar(Can)

Checking the curve fits compared to the OND file points, they seem reasonable, although plotting the model fits using the parameters from the CEC database shows a clear difference between the curves (solid(OND) vs dashed line(CEC))

Not knowing the method used to extract the parameters for each inverter that is put into the CEC database is an unknown, but assuming they follow the handbook I would expect the curves to be more similar.

The translator seems to be working fine when the data is available, and I suppose it may be a parallel issue that the OND files and CEC database yield differing efficiency curves.

Hope some of this may be helpful in further development!

[adriesse]

I would expect the curves to be more similar.

Nice work. (There might be a better place for it than hidden in a PR...) The CEC/Sandia parameters are based on independent labs tests (or at least the were in the past), whereas the PVsyst parameters are somehow derived from manufacturer data. That probably accounts for some of the differences.

[hamiltonkibbe]

First off, great work, this is really helpful functionality! Echoing @adriesse, it would be great to have in main. I'd be happy to help out if you'd like a hand with any part of getting this into shape.

• should read_panond default to UTF-8 encoding?

I've only come across UTF-8 encoded PAN/OND files, many with a BOM, utf-8-sig might be a more robust choice than utf-8 if updating the default.

It seems the change to utf-8 for PVsyst-generated files happened mid-2019. I am not sure what manufacturer-provided files in the wild are using:

Starting with PVsyst version 6.80, the encoding of all PVsyst files (*.PRJ, *.VCi, *.PAN, *.OND, etc.) has changed to UTF-8 to support international characters.

ref: Format of PVsyst files

Whether its worth a breaking change is up to the maintainers, It might be nice to have the default functionality support "recent" files but I suspect there are a lot of older ones floating around.