Rust code in pvlib

[kurt-rhee]

Hello maintainers,

I have been playing around with the Rust programming language and I was wondering if Rust code would be welcome in pvlib? I have noticed some programs which already have some C code (SPA). The rust code would not give much advantage over existing C versions and would be less readable for users than native python and numpy implementations, but could give memory and speed improvements for functions which do not have a C implementation.

[kandersolar]

My two cents, and echoing #1906 (comment): although I personally am very willing to learn new languages and toolchains, I am quite hesitant to introduce them to pvlib-python. It seems unlikely to me that such a large increase in project complexity is warranted when we can get comparable performance improvements with numba today, or wait a little while for the arrays api to mature and give us JAX/GPU arrays for free(?).

I think serious consideration of a second language would need to start with a demonstration that the new language is meaningfully better than the tools currently at our disposal. I'd be very interested in such an example!

C code (SPA)

It's a bit of a tangent, but I think that C code should be considered an oddity, not a precedent; the reference SPA implementation from NREL is written in C, and in the beginning it was handy to be able to easily compare its output with that of pvlib's own implementations. I doubt it gets much use today. I think if you try it, you'll find that the C version is actually slower than pvlib's implementations due to the time series iteration being in python rather than C: https://github.com/pvlib/pvlib-python/blob/main/pvlib/solarposition.py#L215

[kurt-rhee]

I agree with you Kevin, it seems a large increase in project complexity for little benefit.

What I can do though is periodically post some time trials between my rust implementations and the pvlib code. I don't think that the speed comparisons will ever demonstrate that we should move to a new language as a community, but I think they might be interesting in that we might be able to find certain functions which could use speed improvements.

[mikofski]

I agree with Kevin as well. IMO neither speed nor security are important considerations for pvlib. Its main goal is dissemination of community supported implementations of PV modeling algorithms, and for that a simple language like Python is preferable.

However, a secondary goal is to support industry who might require faster more secure software and also need a reference implementation. I believe pvlib’s permissive license allows use, reuse, and mix-ins with attribution, so maybe your demonstrations could serve an additional purpose of showing 3rd party developers how to use pvlib to create such software and attribute pvlib accordingly.

[kurt-rhee]

Great point, thanks for the advice as always Mark!

[echedey-ls]

It's no wonder why SPA C code is much slower that pure python: that for loop appends to a list, and then creates a dataframe from it, that's too much overhead. It could be sped up by using lambdas, partial funcs and constructing directly from the resulting iterator.

I wanted to improve it and benchmark the difference, but couldn't get SPA C to install with PVLIB, even after downloading the .c&.h files and trying to compile. Is there any source I can check to know the steps I should follow?

[kandersolar]

TBH I'm not sure speed is really a priority for the nrel_c method, and I'm skeptical that it will ever be able to compete on speed as long as execution has to round-trip into python land and back again every iteration. But anyway, of course feel free to try speeding it up!

As far as I know, the README here is the best and only set of instructions for getting the SPA C method set up: https://github.com/pvlib/pvlib-python/tree/main/pvlib/spa_c_files

If that procedure doesn't work, of course please open an issue. Due to the licensing/access restrictions, we don't test the SPA C stuff in the CI, and I suspect almost nobody uses it with pvlib. So it's possible that the procedure has been broken for some time and nobody has realized :)