Aggregation displays wrong Unit in Plots

[Karen K]

I defined a new aggregation type called 'energy_integral' for the observation type 'radiation'. And I added new unit groups to reflect the unit of the result:

weewx.units.agg_group.setdefault('energy_integral','group_radiation_energy')
weewx.units.USUnits.setdefault('group_radiation_energy','watt_hour_per_meter_squared')
weewx.units.MetricUnits.setdefault('group_radiation_energy','watt_hour_per_meter_squared')
weewx.units.MetricWXUnits.setdefault('group_radiation_energy','watt_hour_per_meter_squared')
weewx.units.default_unit_format_dict.setdefault('watt_hour_per_meter_squared',"%.0f")
weewx.units.default_unit_label_dict.setdefault('watt_hour_per_meter_squared',u" Wh/m²")

Then I defined a get_aggregate() function that returns the value.

If I use a tag like $yesterday.radiation.energy_integral then I get the right unit Wh/m^2.

But the graph is labelled with the unit label of the original value. That is W/m^2 (without h) instead of Wh/m^2.

I wonder what I could do to have the correct unit label in graphs, too?

[Tom Keffer]

Hi, Karen

Offhand, no ideas. 

However, I will say that your plot looks more like a plot of something in units of W/m². Wouldn't Wh/m² be bigger numbers? Are you sure you're plotting what you think you are plotting?

--
You received this message because you are subscribed to the Google Groups "weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-developm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/15a59830-708a-4888-a04f-46f4a802aeb2n%40googlegroups.com.

[Karen K]

Tom Keffer schrieb am Montag, 8. März 2021 um 03:25:46 UTC+1:

However, I will say that your plot looks more like a plot of something in units of W/m². Wouldn't Wh/m² be bigger numbers? Are you sure you're plotting what you think you are plotting?

 

Some estimate to check:

maxSolarRad is calculated by WeeWX. The daily maximum of that value in that time of year is about 500 W/m^2. Daylight is about 10 hours a day. To get it easier imagine the curve under maxSolarRad like a triangle. So the total energy of a day would be E = P(max) * t(daylight) / 2 = 500 W/m^2 * 10 hours / 2 = 2500 Wh/m^2. That is on a bright sunny day. If there are clouds, it is less. 

So I think, the range of values could not be totally wrong.

[Karen K]

The database query I use is that:

_result = db_manager.getSql( 

    "SELECT SUM(radiation*interval)/60.0, "
    "MIN(usUnits),MAX(usUnits) FROM %s "
    "WHERE dateTime>? AND dateTime<=?"
    % db_manager.table_name,timespan)

[Tom Keffer]

Yes, but I was thinking more in terms of the specification for the plot in skin.conf. What observation type did you say to plot? Are you accidentally plotting "radiation" instead of "energy_integral?"

-tk

--

You received this message because you are subscribed to the Google Groups "weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-developm...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/ecc0844c-2061-4efb-8fd3-93a54f00936fn%40googlegroups.com.

[Karen K]

Ah, ok, then. That is the section in skin.conf:
[[[monthRadiationEnergy]]]
    line_gap_fraction = 0.04
    [[[[radiation]]]]
        label = "Sonnenenergie (täglich gesamt)"
        data_type = radiation
        aggregate_type = energy_integral
        aggregate_interval = 86400

[Tom Keffer]

I've been able to confirm that this is a bug. Issue #654. 

Thanks, Karen. I think this bug has survived all this time because plots of aggregation types that change the unit type are rare. XTypes are changing that.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/0cb6b4b7-1bab-46cc-9e6e-63ef47e28206n%40googlegroups.com.

[Tom Keffer]

Karen,

Can you apply this simple patch to imagegenerator.py? Let me know if that fixes the problem.

diff --git a/bin/weewx/imagegenerator.py b/bin/weewx/imagegenerator.py
index 4daae09a..0e33e40f 100644
--- a/bin/weewx/imagegenerator.py
+++ b/bin/weewx/imagegenerator.py
@@ -196,7 +196,7 @@ class ImageGenerator(weewx.reportengine.ReportGenerator):
 
                     # Add a unit label. NB: all will get overwritten except the
                     # last. Get the label from the configuration dictionary.
-                    unit_label = line_options.get('y_label', weewx.units.get_label_string(self.formatter, self.converter, var_type))
+                    unit_label = line_options.get('y_label', self.formatter.get_label_string(new_data_vec_t[1]))
                     # Strip off any leading and trailing whitespace so it's
                     # easy to center
                     plot.setUnitLabel(unit_label.strip())

-tk

[Karen K]

I applied the patch. Then I removed all the PNG files in the HTML directory, that they need to be re-created. Then I re-started WeeWX and waited for the next archive interval to come. I used Seasons skin.

There was no error message in syslog.

I checked all the plots in all time spans for their respective unit labels. All the unit labels were correct, including that of the radiation energy integral. 

Please, could you include "energy_integral" in the list in line 185 of imagegenerator.py together with "min", "max", and "avg" in order to put the point into the middle of the aggregation interval for that aggregation type, too?

[Tom Keffer]

Your aggregation type energy_integral is too specialized to be included.

However, I'm inclined to just get rid of the list. Can you give it a try? Change this

                    if aggregate_type and aggregate_type.lower() in ('avg', 'max', 'min') and plot_type != 'bar':

to this

                    if aggregate_type and plot_type != 'bar':

See if that works for all your graphs.

-tk

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/a1d0c101-6f55-45bc-afc2-ca09d6ca3d0en%40googlegroups.com.

[Karen K]

I will try it, but let me explain why I came to name the aggregation type that way.

"integral" is just the opposite of "tderiv", which is available somewhere. So it seems to me not that special. 

But why not name it just "integral"? Because you need a separate entry in agg_group for each unit label. The principle is always the same: time is added to the unit. But it is not possible to express that in agg_group on a general basis.

Integration over power to get energy is not only useful for sun radiation, but also for the measurements of solar power plants. So I saw it not that special for that reason, too.

[Tom Keffer]

Well, you could use aggregate type 'cumulative', then apply an appropriate label for individual plots.

You can understand why I want to avoid having entries for 'ET_integral', 'rain_integral', and all the other possible extensive quantities.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/60c4fae6-f705-4f47-8432-1381def9219dn%40googlegroups.com.

[Karen K]

Tom Keffer schrieb am Dienstag, 9. März 2021 um 16:47:39 UTC+1:

Well, you could use aggregate type 'cumulative', then apply an appropriate label for individual plots. 

You can understand why I want to avoid having entries for 'ET_integral', 'rain_integral', and all the other possible extensive quantities.

Oh, there's a huge difference between rain etc. and solar radiation. Rain and ET are really cumulative. You can summarize them and get the value. And the unit label does not change.

Not so with solar radiation and solar power plant power. You need to multiply each single radiation reading by the respective observation interval. And only after that you can summarize the products. It is especially important, if the interval changes sometime. Energy is not the sum of power readings (or radiation reading, respectively). Energy is power (radiation) multiplied by time. Or power (radiation) integrated over time, if the readings are not constant.

So for 'rain' and 'ET' it's 'sum'. For energy it's something else.

 

[Karen K]

Tom Keffer schrieb am Dienstag, 9. März 2021 um 14:07:56 UTC+1:

However, I'm inclined to just get rid of the list. Can you give it a try? Change this

                    if aggregate_type and aggregate_type.lower() in ('avg', 'max', 'min') and plot_type != 'bar':

to this

                    if aggregate_type and plot_type != 'bar':

See if that works for all your graphs.

I can confirm, that this works for me.