pvlib.iotools.get_psm3 attribute "reverse mapping" produces invalid names

[kandersolar]

Describe the bug
Most iotools functions have the ability to transform from the data source's naming convention to pvlib's. get_psm3 is a bit of an oddball in that it can also do the reverse (map pvlib names to PSM3 names). It does this by inverting the dictionary used to map PSM3 data names to pvlib names (iotools.psm3.VARIABLE_MAP) and using that to map pvlib names to PSM3 data names.

The problem is that, irritatingly, the PSM3 API uses a different naming convention for its requests than it uses for its responses. For example, what pvlib calls temp_air is referred to as air_temperature in the API request and Temperature in the API response. Thus simply inverting the response mapping does not produce a valid request mapping. Using this invalid reverse mapping results in the API complaining about unrecognized attributes.

To Reproduce

In [3]: _ = pvlib.iotools.get_psm3(40, -80, 'DEMO_KEY', 'kevin.anderson@nrel.gov', attributes=['temp_air'], names=2020)

Traceback (most recent call last):

  Input In [3] in <cell line: 1>
    _ = pvlib.iotools.get_psm3(40, -80, 'DEMO_KEY', 'kevin.anderson@nrel.gov', attributes=['temp_air'], names=2020)

  File ~\Software\Anaconda3\envs\dev\lib\site-packages\pvlib\iotools\psm3.py:206 in get_psm3
    raise requests.HTTPError(errors, response=response)

HTTPError: ["The optional 'attributes' parameter must contain a list of comma separated attributes. Values may include air_temperature, clearsky_dhi, clearsky_dni, clearsky_ghi, cloud_type, dew_point, dhi, dni, fill_flag, ghi, relative_humidity, solar_zenith_angle, surface_albedo, surface_pressure, total_precipitable_water, wind_direction, wind_speed, ghuv-280-400, ghuv-295-385"]

Expected behavior
I expect the function's behavior to satisfy the claims in its docstring, which in this case is that pvlib names are allowed:

pvlib-python/pvlib/iotools/psm3.py

Lines 73 to 77 in 5b05914

	attributes : list of str, optional
	meteorological fields to fetch. If not specified, defaults to
	``pvlib.iotools.psm3.ATTRIBUTES``. See references [2]_, [3]_, and [4]_
	for lists of available fields. Alternatively, pvlib names may also be
	used (e.g. 'ghi' rather than 'GHI'); see :const:`VARIABLE_MAP`.

Having separate forward and reverse maps is one route to closing this issue. I would also find it acceptable to just do away with the "reverse mapping".

Versions:

• pvlib.__version__: 0.9.4

[AdamRJensen]

Yikes! I still think it's a useful feature, but I have begun learning that useful features aren't always worth the maintenance cost...

I'd be happy to correct this mistake if we decide to keep the reverse mapping (which I'm voting for).

Let it be known that for most of the iotools, reverse mapping will never be a consideration, as it's often not possible to choose which parameters to request (all available parameters are returned).