tilt Azimut estimation

[mar6490]

Hi, I tried sdt to estimate tilt Azimut estimation work for my data, but I couldn't make it work. I wonder if my data is the problem. I have only one year of AC power for systems in Germany. Is this enough to make the tilt Azimut estimation work?

[bmeyers]

Hello @mar6490, thank you for your patience. Can you please share some more details about the algorithm failure? Is there a traceback, or did the code run successfully but provide worthless results? If you're able to share your data, I would be willing to take a look.

I can provide a bit of general advice:

• Make sure your timestamps are in the local timezone, with no "daylight savings" effects
• Make sure to run the .setup_location_and_orientation_estimation(tz_offset) method on your data handler instance, after running the pipeline, where tz_offset is the GMT offset for your local time in hours. For example, US/Pacific is -8. This is a good example to follow.

[mar6490]

Hi,

thanks so much for taking the time to help — I really appreciate it.

For testing, here is the cloudlink of the data i used https://cloud.htw-berlin.de/s/ft87QY7ixN6giHz (PW: SonnJa!_2015)(einleuchtend_wrdata_2015_wr1.csv). It contains AC power data (P_AC) from one inverter (WR1) of a research PV system.

Dataset details:

• Full year 2015
• 1-minute resolution
• Naive timestamps (local datalogger time, Germany / Europe/Berlin)
• Some data gaps
• No NaN values in P_AC
• Known ground-truth tilt and azimuth (lat, lon, tilt, azimut included in metadata)

I ran the standard SDT pipeline and then the orientation estimation. During the orientation estimation step, I encountered the following error:

ValueError: Must have k >= 0 and X must have < k elements along axis

I’m using this dataset as a reference case because the true orientation is known. My broader goal is to build a workflow that estimates tilt and azimuth for a few hundred PV systems from Germany and neighboring countries. Those datasets can’t be shared, but they are structurally similar (one year, 5-minute resolution, naive local timestamps, AC power only).

The larger dataset I aim to analyze is the one used in this study (in German):
https://solar.htw-berlin.de/wp-content/uploads/HTW-Solares-Laden-von-Elektrofahrzeugen.pdf

This is part of a university research project I’m working on this semester, focused on analyzing orientation and shading characteristics of these systems.

Before applying the method more broadly, I’d like to make sure I’m using SDT correctly and that this type of data should generally work for orientation estimation. I’ve started experimenting with building my own algorithm, but since I’m still new to coding, I’d strongly prefer to use Solar Data Tools if it’s suitable for this use case.

If there’s anything in the dataset structure (timestamps, DST handling, resolution, data gaps, etc.) that could explain the issue, I’d greatly appreciate your guidance.

Thanks again, this is really helpful for my project.

[mar6490]

The pipelin runs well, but this is what i get when i run the orientation estimation:

dh.setup_location_and_orientation_estimation(1)

tilt, azimuth = dh.estimate_orientation(
latitude=52.45544,
longitude=13.52481,
)

print("Estimated tilt:", tilt)
print("Estimated azimuth:", azimuth)

---

ValueError Traceback (most recent call last)
Cell In[36], line 3
1 dh.setup_location_and_orientation_estimation(1)
----> 3 tilt, azimuth = dh.estimate_orientation(
4 latitude=52.45544,
5 longitude=13.52481,
6 )
8 print("Estimated tilt:", tilt)
9 print("Estimated azimuth:", azimuth)

File ~\PycharmProjects\solar-data-tools\solardatatools\data_handler.py:1588, in DataHandler.estimate_orientation(self, latitude, longitude, tilt, azimuth, day_interval, x1, x2)
1586 ready = self.__help_param_est()
1587 if ready:
-> 1588 self.parameter_estimation.estimate_orientation(
1589 longitude=longitude,
1590 latitude=latitude,
1591 tilt=tilt,
1592 azimuth=azimuth,
1593 day_interval=day_interval,
1594 x1=x1,
1595 x2=x2,
1596 )
1597 tilt = self.parameter_estimation.tilt
1598 az = self.parameter_estimation.azimuth

File ~\PycharmProjects\solar-data-tools\pvsystemprofiler\estimator.py:184, in ConfigurationEstimator.estimate_orientation(self, longitude, latitude, tilt, azimuth, day_interval, x1, x2)
179 self.num_days = dh.num_days
180 self.omega = calculate_omega(
181 self.day_of_year, self.data_sampling, self.longitude, self.gmt_offset
182 )
--> 184 self.tilt, self.azimuth = self._cal_orientation_helper()

File ~\PycharmProjects\solar-data-tools\pvsystemprofiler\estimator.py:225, in ConfigurationEstimator._cal_orientation_helper(self)
222 day_range = np.ones(self.day_of_year.shape, dtype=bool)
224 doy = self.data_handler.day_index.day_of_year
--> 225 normalized_data, costheta_est = find_fit_costheta(
226 self.data_matrix, self.days, doy
227 )
229 self.data_handler.find_clipped_times()
230 boolean_filter = normalized_data >= 0.15 * np.exp(costheta_est)

File ~\PycharmProjects\solar-data-tools\pvsystemprofiler\algorithms\performance_model_estimation.py:38, in find_fit_costheta(data_matrix, clear_index, doy)
36 phi3 = 1e3 * cvx.sum_squares(cvx.diff(x3, k=2)) + 1e-6 * cvx.norm1(x3)
37 for val in set(solstice_centered_index(doy)):
---> 38 constraints.append(cvx.diff(x3[solstice_centered_index(doy) == val]) == 0)
39 constraints.append(x3 <= 0)
40 phi4 = 1e3 * cvx.sum_squares(cvx.diff(x4, k=2)) + 1e-3 * cvx.sum_squares(x4)

File ~.conda\envs\solar-data-tools\Lib\site-packages\cvxpy\atoms\affine\diff.py:44, in diff(x, k, axis)
42 # Always test shape[0] because if axis == 1 x is transposed.
43 if k < 0 or k >= x.shape[0]:
---> 44 raise ValueError("Must have k >= 0 and X must have < k elements along "
45 "axis")
46 for i in range(k):
47 if x.ndim == 2:

ValueError: Must have k >= 0 and X must have < k elements along axis

[mar6490]

This is what chatgpt says about it....

The pipeline runs successfully and the dataset report looks reasonable:

• 1.00 years of data
• Quality score: 0.89
• Clear days: 68 / 365
• No time shift or time zone errors detected

However, estimate_orientation() still fails with:
ValueError: Must have k >= 0 and X must have < k elements along axis

The error occurs inside:
pvsystemprofiler/algorithms/performance_model_estimation.py

specifically in find_fit_costheta() at the line:
constraints.append(cvx.diff(x3[solstice_centered_index(doy) == val]) == 0)

It appears that for at least one solstice_centered_index(doy) group, the masked slice of x3 has length 0 or 1, which causes cvx.diff() to fail.

I verified:
The dataset contains 68 clear days, reasonably distributed across the year.
Restricting to day_interval=(60, 300) (approx. March–October) does not prevent the error.
The issue seems related to how the solstice-centered grouping interacts with the filtered day selection rather than to timestamp handling or insufficient clear days overall.
It looks like an edge case where constraints are added even if a seasonal group contains fewer than 2 valid days.

Now the question:
Would you recommend adding a guard condition (e.g. only adding the constraint if the group size ≥ 2), or is there a preferred way to ensure the grouping remains valid?

I tried to go arround it and the outcome was an orientation estimation far from the ground truth. so i guess the orientation algorithm does not work for data wich is only a year long. Is this true?

Thanks again — I really appreciate your help with this.

Best,
Maren

[bmeyers]

Hi, I'm very sorry for the slow responses on my end, but I am taking a look at this now. Thank you again for your patience! I will follow up here soon.

Bennet

[bmeyers]

Hi Maren,

If you're able, do you mind testing the fix on this branch? https://github.com/NatLabRockies/solar-data-tools/tree/systemprofiler-fix

I think I didn't download the shared file in time because the link now doesn't work. If you'd like to share a link again, I'll take a look.

If you prefer, you can reach out to SolarDataTools@nlr.gov and we can continue the conversation there.

That said, I do think that a single year of data with a clearness score of <20% will push the limits of what this algorithm can do. I definitely want to fix the code error, or at least provide a more useful message to the user if necessary, but I wouldn't expect high accuracy in this scenario in general.

Cheers,
Bennet

[bmeyers]

Hi @mar6490,

I hope #224 fixed your issue. I will close this for now, but please feel free to open a new issue if the problem persists.

Thanks,
Bennet

[mar6490]

Hi Bennet,

Thank you so much for looking into this and for the quick fix! I haven't had the chance to dive into testing it yet, but I'll take a closer look soon and will get back to you if needed.

Right now I'm focused on finishing my project report, but I'm planning to make this topic the subject of my master thesis. So this issue remains highly relevant to my work, and I really appreciate your support!

Thanks again for the fix. Feel free to close this for now.

Best regards