reading bug on '*_TMY3.epw' file

Describe the bug When a tmy3 file formatted in epw is read, the precipitable_water is not converted from mm to cm, and it results in diverging results for spectral mismatch factor (like negative factor for instance), then resulting in negative ‘effective_irradiance’ results

To Reproduce Steps to reproduce the behavior:

1. Create a ChainModel object with a .epw weather file, coming from TMY3 data and imported with ‘pvlib.iotools.epw.read_epw()’
2. Run the model
3. Check for inconsistencies in effective_irradiance with ‘chain1.effective_irradiance.loc[chain1.effective_irradiance<0]’

or

1. Run the code attached

Expected behavior All the effective_irradiance should be positive or null.

bug_report_read_epw.txt

Versions:

• pvlib.__version__: 0.6.3+24.gbbb4580.dirty
• pandas.__version__: 0.23.4
• python: 3.7.1

[cwhanse]

@wholmgren and I talked about this in person (still happens sometimes 😃. Neither of us are strongly opposed to any of the following options:

1. add a note to read_epw about older TMY files from energyplus.net
2. add pw = np.minimum(pw, max_pw) to first_solar_spectral_correction and expose max_pw as a kwarg. Could use this opportunity to also implement min_pw, min_am and max_am but that could be done in a later PR. Default of 8. Return np.nan when inputs are outside the accepted pw range, and warning.

We both think the better course for read_epw is to return exactly what is in the EPW file, rather than attempt to check or correct the content.

[cwhanse]

I don’t think that the read_epw function should attempt to correct errors in EPW data files. I think that will only cause trouble for pvlib down the road.

I’m OK if we want to add a Note to the docstring about TMY3 files from energyplus.net having a known error, and providing helpful suggestions for handling the error.