meta, location, and systemdef philosophy

[jforbess]

I don't fully understand the differences of meta, location, and systemdef, in terms of how they should be used.

systemdef expects TMY meta to be used in its first parameter. But what if I want to use the lat/long for my plant, not the TMY station? What if I am looking at operating data (which I am), and have no need to pull in a TMY file?

Why doesn't systemdef use a location instead of a TMY meta as its first parameter? (Why isn't a TMY meta a Location object?)

[wholmgren]

These are all good points/questions. This is definitely a place where we need to improve the package.

I propose that we:

• Make TMY importers return Location objects instead of meta dicts.
• Create a System class that inherits from Location and replaces systemdef. System objects could be instantiated directly or accept Location objects plus the current systemdef arguments.
• Make use of System objects where appropriate throughout the library.
• These improvements should be a 0.2 milestone.

For 0.1 (#15), I think that we should just change the tmy_meta argument name to be meta and clarify the docs (#16) to specify that it should just be a dict that has these particular keys. There's nothing special about a dict that comes from the TMY importers vs. a dict that is user generated.

[jforbess]

Great, that is what I was thinking, but I wasn't sure there was something I was missing. Both the 0.1 and 0.2 solutions make sense to me.

I am interested in helping on small fixes like this, but as I'm an advanced beginner in python, and a beginner in github, is there a good reference doc for the process preferred by this repo of making some of these changes and presenting them for review?

[wholmgren]

@jforbess would you like to make a pull request with the 0.1 fixes?

Should probably add a test_systemdef_dict function to test_pvsystem to prove that it works as expected.

[jforbess]

@wholmgren sure, I'll do that, but not until Sunday or Monday.

[wholmgren]

@bmu and @Calama-Consulting do you support the proposal above or do you have other ideas for how to resolve this? I think is a high priority for 0.2 since it could impact the API in fairly significant ways.

@jforbess, sorry, just now realizing that I did not respond to your question regarding contributing. Does the Development information wiki help?

[bmu]

As mentioned by @jforbess I think that one often uses a lat/lon different from the TMY data. So I am not really sure, if it is a good idea to return the Location from the TMY reader. This may be different for other data sources, e.g. measurement data or satellite data.

A System or perhaps better a PVSystem class would be really nice. However I wouldn't derive it from Location because it is something completely different. And it is a very complicated task to develop something that covers all aspects. Here are some points, that come to my mind:

• Should be able to describe a whole PV system, e.g. components (inverters, modules, transformers, wiring, mounting, connection to strings, ...)
• The components should be characterized independent of the models used for the simulation of their behaviour (e.g. not parameters of the two diode model for a PV module, as there are other models, that use different parameters). Alternatively it should be possible to include parameters of multiple models.
• I don't know a standard for this, maybe because there is no standard. We could look at other software (e.g. PVSyst, SAM ...). There was the idea of PVML, a XML dialect dedicated to PV systems within the European project "Performance", but as far as I remember without published results.
• It should be able to be read from various sources and exported to different formats

We cannot cover all of this in pvlib (maybe this would be a good topic for a PhD and I think it would be very useful to have a standard for the whole PV community). And up to now we don't need all of this (e.g. we don't have models for calculation of shading losses, wiring losses, transformers ...). But maybe we should have it on mind when we implement something like this.

And I agree, this is something important for our API, so we should have something quite stable for the future.

[bmu]

My comment in #39 is possibly related (is it possible to link to a specific comment?)