[PR] Negative Power Fixes (originally for Nash)

[solderq35]

Fixes #280

Findings

• The real power A, B, C when added up is roughly the same as the "total real power" value.
  
  • 38.44 + 50.5 + 14.24 = 103.18 which is a bit off from the value in the database of 102.59
  • Data taken from Nash Power 1500 Amp (meter ID 31), 2024-01-18 23:45:00 GMT (3:45 PM PST)
  • Not sure why - rounding errors?
• Assuming it's correct that phase A, B, and C should roughly add up to the total real power, then the units are wrong as noted in Brandon's previous email. It should either by shown with kilowatt units (kW), or if we keep watts (W), multiply the numeric value by 1000
• Based on looking at the source code (https://github.com/OSU-Sustainability-Office/energy-dashboard/blob/master/backend/dependencies/nodejs/models/meter.js#L222), it seems like the total real power (so to speak) is already calculated by the Acquisuites before it is uploaded to our database (which may also explain any rounding errors)
• Reactive power shows the same issue with units (total reactive power is shown as Var instead of kVar, but this doesn't align with the assumption that total reactive power is roughly equal to the sum of phase A, B, and C of reactive power)
• I couldn't find a good example where phase A / B / C had different phases for real power, but I found one for reactive power
  
  • 29.53 + (-22.48) + (-60.99) = -53.94, which is roughly equivalent to the -53.51 value in the database for total reactive power
  • Data taken from Nash Power 1500 Amp (meter ID 31), 2024-01-18 23:45:00 GMT (3:45 PM PST)
  • Hence it can be inferred that if some phases are positive and some are negative, the Acquisuite doesn't do any sign flipping (e.g. negative to positive) before adding the phase values together

Conclusion

• It is pretty straightforwards to just change the units for total real / reactive power to kW or kVAR
  • Assuming it's generally true that 3 phases should add up to total power, then this should be a safe change to make whether we alter the total power calculation on the Acquisuite side, or on Energy Dashboard's side
• However, the total real / reactive power seems to be calculated by the Acquisuites, so if we flip the sign of the Acquisuite-calculated total, the math might be wrong per Brandon's last email (if some phases are positive and some negative)
• We could look into a way of setting all phases to positive, and then have Energy Dashboard calculate the total real / reactive power based on the flipped phase values. But as noted earlier, there seem to be rounding? discrepancies with how the Acquisuite calculated the total real and reactive power, so the values will be somewhat off compared to before (even for buildings that didn't have any negative power)

Other

The changes to backend\dependencies\nodejs\models\meter.js are in a GET endpoint, which will affect for example https://api.sustainability.oregonstate.edu/v2/energy/allbuildings (replace https://api.sustainability.oregonstate.edu with http://localhost:3000 if testing locally). Therefore, there should not be any worries about overwriting old data etc.

[solderq35]

If we end up manually recalculating the total real and reactive power, we can probably do it in chart.module.js: https://github.com/OSU-Sustainability-Office/energy-dashboard/blob/master/src/store/chart.module.js#L47

Check Reqpayload.point, then make 3? calls to metergroup with different point values (phase A / B / C), then set to positive and sum up.

Also need to remember to ask if all values are meant to be positive. Voltage, apparent power, etc.

edit- also need to do this for download_data.vue probably

[solderq35]

Other wrinkles:

There are at least 2 places in the frontend src/store where the Energy Dashboard tries to flip values to positive sign.

accumulated_real.js (known about):

• https://github.com/OSU-Sustainability-Office/energy-dashboard/blob/master/src/store/chart_modifiers/line_bar/accumulated_real.js#L116
  • Takes the absolute value of whatever is being added to the accumulator variable. Absolute value means both positive and negative input > positive output. So the accumulator (net energy) always grows in a positive direction

meter_group.module.js (new find)

• https://github.com/OSU-Sustainability-Office/energy-dashboard/blob/master/src/store/meter_group.module.js#L153

  • This flips signs of all values. Negative input becomes positive output, positive input becomes negative output (based on the negate column in the meters table in SQL database)
  • For some reason, this doesn't always work consistently. If you log the value of meter.negate in for (let meter of store.getters.meters) {... in the file linked above, Nash hall's 1500 amp meter (meter ID 31) is set to true for negate column, on the default meter group ("Nash Electric"). But once you change meter group to "Nash 1500 Amp", the negate value becomes false.
    • 
  • By contrast, Dixon (meter id 5) keeps the negate value as true after switching measurements to real power. Possibly because the meter group is not switched? Unclear.

• It should also be noted that Dixon's meter groups consist of one meter group with one electric meter in it, and another meter group with one steam meter in it. Only the default measurements (accumulated_real aka net energy for Electricity) support multiple meters in the same meter group, as explained here: https://github.com/OSU-Sustainability-Office/energy-dashboard/blob/master/src/store/meter_group.module.js#L94

  • That's why Nash's default meter group only allows for Net Energy, while Dixon's default meter group allows for all the measurement options

The end result is that:

• Buildings like Nash don't have the negate flag set properly in src/store/meter_group.module.js, but the accumulated real (net power) is still set to positive due to an override in src/store/chart_modifiers/line_bar/accumulated_real.js

  • Compare select * from data where meter_id = 31 order by time DESC; with what's shown on the frontend at https://dashboard.sustainability.oregonstate.edu/#/building/28/2
    • Everything matches up except the accumulated_real is positive on the frontend, negative in database

• Buildings like Dixon have negative values flipped to positive by src/store/meter_group.module.js,(making the additional override in src/store/chart_modifiers/line_bar/accumulated_real.js redundant). However, initially positive values for building like Dixon are flipped to negative by src/store/meter_group.module.js, and this is not reversed

  • Compare select * from data where meter_id = 5 order by time DESC; with what's shown on the frontend at https://dashboard.sustainability.oregonstate.edu/#/building/10/2
  • 
  • 
    • The apparent power is positive in SQL, negative on frontend for Dixon

• It's also still unclear to me which values (if any) should ever show a positive value

[solderq35]

Changes

• Applied absolute value to src\store\chart_modifiers\line_bar\base.js
• Removed mentions of negate from meters table, and operation from meter_group_relation (only from the energy dashboard codebase)

Regex / Python Script for reference (fix unit tests)

• Fixed unit tests to accommodate removing negate and operation - Python / regex script I used for removing them from the backend test SQL queries:

Input (example from backend\tests\assertedData\meter_group_relation_insert.sql):

INSERT INTO `` (`id`,`meter_id`,`operation`,`group_id`) VALUES (160,8,9,1);
INSERT INTO `` (`id`,`meter_id`,operation`,`group_id`) VALUES (161,9,9,1);
INSERT INTO `` (`id`,`meter_id`,operation`,`group_id`) VALUES (166,40,11,1);

Remove operation (or whichever variable) with just "find and replace" in text editor / vscode.

Script

For VALUES (166,40,11,1);, you can use script (tested on python 3.8.0)

import re

# replace line below to match input file name in directory
input_file_path = 'meter_group_relation_insert.sql'

output_file_path = 'modified_' + input_file_path

# originally 5 items in parentheses, remove 4th item
# regex_pattern = r'\(([^,]+),([^,]+),([^,]+),[^,]+,([^,]+)\);'

# originally 4 items in parentheses, remove 4th item
regex_pattern = r'\(([^,]+),([^,]+),([^,]+),[^,]+\);'

with open(input_file_path, 'r') as input_file, open(output_file_path, 'w') as output_file:
    for line in input_file:
        # originally 5 items in parentheses, remove 4th item
        # modified_line = re.sub(regex_pattern, r'(\1,\2,\3,\4);', line)
        
        # originally 4 items in parentheses, remove 4th item
        modified_line = re.sub(regex_pattern, r'(\1,\2,\3);', line)
        output_file.write(modified_line)

print('output saved to: ' + output_file_path) 

Next todo

• If this looks good after more testing / merging into master branch, the negate from meters table, and operation from meter_group_relation columns can be deleted from SQL database

[solderq35]

Since the only changes here are either changes to frontend (VueX store), or GET requests on the backend, I think it is safe to review and merge this PR (if there are no obvious issues), and if anything needs to be changed later we can open a new PR.

Follow Up Tasks

• After merging this it should be safe to delete operation and negate columns from meter_group_relation and meter SQL tables respectively
• For future keeping track of negative meters in the future, see this automated-jobs PR: [PR] Negative Points checker automated-jobs#40

[s-egge]

The negative values and measurement labels appear to be fixed on the front end. The only thing that looks like it might be off is the meter_group_relation_insert.sql file that I commented on. Other than that, the branch looks good to me.