Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error with using PVGIS weather data (zenith conversion in airmass?) #2399

Open
expeon07 opened this issue Feb 25, 2025 · 10 comments · May be fixed by #2417
Open

Error with using PVGIS weather data (zenith conversion in airmass?) #2399

expeon07 opened this issue Feb 25, 2025 · 10 comments · May be fixed by #2417
Labels

Comments

@expeon07
Copy link

Describe the bug
Hi, I'm trying to run a ModelChain model using a weather file obtained through get_pvgis_tmy() function. However I am getting an error with the weather data

To Reproduce
Steps to reproduce the behavior:

weather, months, inputs, metadata = pvlib.iotools.get_pvgis_tmy(latitude, longitude, outputformat='epw', coerce_year=2023)

system_loss = 0.1
times = weather.index
solar_position = pvlib.solarposition.get_solarposition(times, latitude, longitude)

system = pvlib.pvsystem.PVSystem(
    surface_tilt=30,
    surface_azimuth=150,
    module_parameters=sandia_modules["Canadian_Solar_CS6X_300M__2013_"],
    inverter_parameters=cec_inverters["ABB__MICRO_0_25_I_OUTD_US_208__208V_"],
    temperature_model_parameters=pvlib.temperature.TEMPERATURE_MODEL_PARAMETERS["sapm"]["open_rack_glass_glass"],

)

mc = pvlib.modelchain.ModelChain(system, location=location)
mc.prepare_inputs(weather)

Error

---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
AttributeError: 'float' object has no attribute 'radians'

The above exception was the direct cause of the following exception:

TypeError                                 Traceback (most recent call last)
Cell In[6], line 23
     21 mc = pvlib.modelchain.ModelChain(system, location=location)
     22 print(mc)
---> 23 mc.prepare_inputs(weather)
     24 # # mc.run_model(weather)
     25 
     26 # ac_power = mc.ac * (1 - system_loss)
     27 # dc_power = mc.dc['p_mp']  # Maximum power point (Pmp)
     28 
     29 # print(dc_power)

File ~/.local/share/virtualenvs/Lowfield-Green-CSxyL99o/lib/python3.10/site-packages/pvlib/modelchain.py:1424, in ModelChain.prepare_inputs(self, weather)
   1421 self._assign_weather(weather)
   1423 self._prep_inputs_solar_pos(weather)
-> 1424 self._prep_inputs_airmass()
   1425 self._prep_inputs_albedo(weather)
   1426 self._prep_inputs_fixed()

File ~/.local/share/virtualenvs/Lowfield-Green-CSxyL99o/lib/python3.10/site-packages/pvlib/modelchain.py:1255, in ModelChain._prep_inputs_airmass(self)
   1251 def _prep_inputs_airmass(self):
   1252     """
   1253     Assign airmass
   1254     """
-> 1255     self.results.airmass = self.location.get_airmass(
   1256         solar_position=self.results.solar_position,
   1257         model=self.airmass_model)
   1258     return self

File ~/.local/share/virtualenvs/Lowfield-Green-CSxyL99o/lib/python3.10/site-packages/pvlib/location.py:319, in Location.get_airmass(self, times, solar_position, model)
    316 else:
    317     raise ValueError(f'{model} is not a valid airmass model')
--> 319 airmass_relative = atmosphere.get_relative_airmass(zenith, model)
    321 pressure = atmosphere.alt2pres(self.altitude)
    322 airmass_absolute = atmosphere.get_absolute_airmass(airmass_relative,
    323                                                    pressure)

File ~/.local/share/virtualenvs/Lowfield-Green-CSxyL99o/lib/python3.10/site-packages/pvlib/atmosphere.py:219, in get_relative_airmass(zenith, model)
    217 # set zenith values greater than 90 to nans
    218 z = np.where(zenith > 90, np.nan, zenith)
--> 219 zenith_rad = np.radians(z)
    221 model = model.lower()
    223 if 'kastenyoung1989' == model:

TypeError: loop of ufunc does not support argument 0 of type float which has no callable radians method

Would anyone know if there's something wrong with the code or if it's a bug? Thank you!!

@expeon07 expeon07 changed the title Error with using weather file (zenith conversion in airmass?) Error with using PVGIS weather data (zenith conversion in airmass?) Feb 25, 2025
@cwhanse
Copy link
Member

cwhanse commented Feb 25, 2025

The error tells you that zenith is a single value, with float type. Somehow you aren't getting a time series of weather data. What does times look like?

@cwhanse
Copy link
Member

cwhanse commented Feb 25, 2025

@expeon07 happy to help you diagnose this problem here. For questions like "is there something wrong" we prefer a post to the pvlib-python google group, or stackoverflow. If we find a bug, then a GH issue is welcome.

@expeon07
Copy link
Author

times is a DateTimeIndex in UTC

DatetimeIndex(['2023-01-01 00:00:00+00:00', '2023-01-01 01:00:00+00:00',
               '2023-01-01 02:00:00+00:00', '2023-01-01 03:00:00+00:00',
               '2023-01-01 04:00:00+00:00', '2023-01-01 05:00:00+00:00',
               '2023-01-01 06:00:00+00:00', '2023-01-01 07:00:00+00:00',
               '2023-01-01 08:00:00+00:00', '2023-01-01 09:00:00+00:00',
               ...
               '2023-12-31 14:00:00+00:00', '2023-12-31 15:00:00+00:00',
               '2023-12-31 16:00:00+00:00', '2023-12-31 17:00:00+00:00',
               '2023-12-31 18:00:00+00:00', '2023-12-31 19:00:00+00:00',
               '2023-12-31 20:00:00+00:00', '2023-12-31 21:00:00+00:00',
               '2023-12-31 22:00:00+00:00', '2023-12-31 23:00:00+00:00'],
              dtype='datetime64[ns, UTC]', name='time(UTC)', length=8760, freq=None)

Thanks for the info about where to post questions! Can also transfer this question on stackoverflow if it takes long

@cwhanse
Copy link
Member

cwhanse commented Feb 25, 2025

transfer this question on stackoverflow

Let's do that. Please link your SO post here.

@expeon07
Copy link
Author

Sure, question is still on staging-ground. But it has the same title. Will update later when it gets published.
Thank you!!

@expeon07
Copy link
Author

@kandersolar
Copy link
Member

There's a workaround posted at the SO question.

The problem, which is probably something to fix on our side, is that get_pvgis_tmy(..., outputformat='epw') is returning columns with dtype object instead of float64. See:

In [12]: weather, _, _, _ = pvlib.iotools.get_pvgis_tmy(53.951, -1.124, outputformat='epw', coerce_year=2023)
    ...: weather.dtypes
Out[12]: 
year                             object
month                            object
day                              object
hour                             object
minute                           object
data_source_unct                 object
temp_air                         object
temp_dew                         object
relative_humidity                object
...

vs

In [13]: weather, _, _, _ = pvlib.iotools.get_pvgis_tmy(53.951, -1.124, coerce_year=2023)
    ...: weather.dtypes
Out[13]: 
temp_air             float64
relative_humidity    float64
ghi                  float64
dni                  float64
dhi                  float64
IR(h)                float64
wind_speed           float64
wind_direction       float64
pressure             float64

@AdamRJensen
Copy link
Member

AdamRJensen commented Mar 3, 2025

Personally, I see no reason we should support different download options (outputformat) for the get_pvgis_tmy or get_pvgis_hourly functions. It's the same data but with a lot more maintenance and some quite complicated code behind the scenes.

I suggest that we make the two PVGIS get functions simply use the outputformat=json behind the scenes.

I would also be in favor of removing the option of the PVGIS read functions being able to read EPW files as this can be done using the dedicated pvlib.iotools.read_epw function.

@kandersolar
Copy link
Member

I suggest that we make the two PVGIS get functions simply use the outputformat=json behind the scenes.

Which format option to use should be at least partially informed by the data that PVGIS returns for each of them. Some formats don't include all columns. But I don't know about json specifically.

@AdamRJensen
Copy link
Member

AdamRJensen commented Mar 22, 2025

This seems to be an undesirable effect of the pvlib.iotools._coerce_and_roll_tmy function which is applied when coerce_year is specified. As an example, when outputformat='epw' and coerce_year is not specified then the DataFrame has the correct dtypes:

In [XX]: weather, _, _, _ = pvlib.iotools.get_pvgis_tmy(53.951, -1.124, outputformat='epw')
    ...: weather.dtypes
Out[XX]: 
temp_air             float64
relative_humidity    float64
ghi                  float64
dni                  float64
dhi                  float64
IR(h)                float64
wind_speed           float64
wind_direction       float64
pressure             float64
...

The reason that outputformat='epw' is the only format type that is affected, is that it has a non-float column called 'data_source_unct'.

@AdamRJensen AdamRJensen linked a pull request Mar 22, 2025 that will close this issue
8 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants