Inconsistent equality comparisons between where and expression sections

[irm-codebase]

What happened?

This bug was noticed while implementing #704

We are incorrectly using = instead of == for equality comparisons in where: strings.

This is confusing (= is generally used for assignation, not comparison).

Here is an example from the balance_storage constraint.

foreach:
- nodes
- techs
- timesteps

# '=' used for comparison (include_storage == true, base_tech==supply, base_tech==demand)
where: (include_storage=true or base_tech=storage) AND NOT (base_tech=supply OR base_tech=demand)
equations:
 # both '=' and '==' are used correctly
- expression: "storage == $storage_previous_step - sum(flow_out_inc_eff, over=carriers) + sum(flow_in_inc_eff, over=carriers)"

sub_expressions:
  storage_previous_step:
  # '=' used for comparison (timesteps == ... and cyclic_storage == ...)
  - where: timesteps=get_val_at_index(timesteps=0) AND NOT cyclic_storage=True
    expression: storage_initial * storage_cap
  # ditto
  - where: "(\n  (timesteps=get_val_at_index(timesteps=0) AND cyclic_storage=True)\n\
      \  OR NOT timesteps=get_val_at_index(timesteps=0)\n) AND NOT cluster_first_timestep=True"
    expression: (1 - storage_loss) ** roll(timestep_resolution, timesteps=1) * roll(storage,
      timesteps=1)
  # ditto
  - where: cluster_first_timestep=True AND NOT (timesteps=get_val_at_index(timesteps=0)
      AND NOT cyclic_storage=True)
    expression: (1 - storage_loss) ** select_from_lookup_arrays(timestep_resolution,
      timesteps=lookup_cluster_last_timestep) * select_from_lookup_arrays(storage,
      timesteps=lookup_cluster_last_timestep)

Which operating systems have you used?

• macOS
• Windows
• Linux

Version

v0.7.0

Relevant log output

No response

[brynpickering]

Not really a bug, although I can see why one would prefer to be consistent across the where and expression strings. We're just not strict about being pythonic in our math, because we're not targetting heavy Python users, necessarily.

[irm-codebase]

I did not really meant it as striving to be pythonic (a = b is assignation in all programming languages I know tbh), but more about the consistency and readability of the YAML, and to avoid possible bugs (two distinct operations sharing the same symbol spells trouble).

I am not an expert in our parsing methods, but this seems like an easy enough fix to me.