Saves a large amount of memory during problem preparation and solving.
The aggregation and disaggregation steps take some time-overhead
however.

for more information, see https://pre-commit.ci

Saves a large amount of memory during problem preparation and solving.
The aggregation and disaggregation steps take some time-overhead
however.

Resolves occasional warnings issued by pandas when build year
aggregation is enabled.

Also specify nominal attrbibutes to store in `vars_to_store`

The "reversed" column can lead to problems upon exporting a network;
somehow these problems only become apparent upon build year
aggregation and disaggregation. Nominally, netCDF doesn't support
boolean values, which is a likely explanation. However, it's unclear
the problem arises specifically with the "reversed" column and only
when aggregating/disaggregating.

The solar potential constraint as originally formulated was not
compatible with build year aggregation. Here, the constraint has been
reformulated in such a way that it works for both "regular" networks
and ones which have been aggregated by build-year.

The previous formulation effectively calculated the remaining area
available for solar (by subtracting installed solar-hsat from
remaining area as given by p_nom_max, which itself has already been
reduced by existing solar), and using this to limit the sum of newly
installed solar and solar-hsat.

The new formulation instead calculates _total_ available solar
capacity (by summing installed capacity of the "solar" carrier and
p_nom_max of extendable "solar" generators), and uses this to limit
the total (both extendable and non-extendable) capacity of all solar
carriers (including "solar-hsat" and potentially others).

The new formulation is also a little shorter overall, and another
bonus is that it should work if ever more types of solar are
added (whereas the old formulation wasn't as easily adaptable to a
situation with more than just "solar" and "solar-hsat").

for more information, see https://pre-commit.ci