Remove {ll} wildcard?

[koen-vg]

It looks to me like the {ll} wildcard remains mainly as a historical artefact -- I'm guessing this goes back to "The role of spatial scale in joint optimisations of generation and transmission for European highly renewable scenarios". However, today I don't really see any particular reason why transmission expansion limits should get their own wildcard? To me it would make perfect sense to make this a configuration option instead, and add a flag to the {opt}/{sector_opts} wildcards instead.

It's not really consequential, and the main drawback would be a disruptive change for users, having to deal with a new file-name structure.

If it's worth considering breaking backwards-compatibility on the file-name like this, there are some other things to consider:

• Remove prenetworks and postnetwork directory  #708
• A little bit more radical, but I would love to merge the {opts}/{sector_opts} wildcards, eliminating confusion for new users and making it impossible to falsely put options in both of them. Instead, whether a network is electricity-only or sector-coupled should, in my opinion, be a configuration option.

[fneum]

I fully agree, and we'll go in steps. In #1472, the {ll} wildcard is removed in favor of a configuration setting. It can still be used from within the {opts} wildcard. This makes more sense than the {sector_opts} wildcard, as the constraint is set in the prepare_network rule.

Regarding the {opts} and {sector_opts} wildcards, the merging is also on the list. We have even discussed removing all wildcards -- which would be possible with the new scenario management (well, the {run} wildcard would stay).

[koen-vg]

Great, I like the new PR, and feel free to close this issue when it's merged :)

For what it's worth, I think a lot of practical sensitivity analysis can be done with the {sector_opts} wildcard (at least I've used it quite a bit in order to iterate over various costs, land use restrictions, etc. etc.), and for me it would be important to be able to replicate the same kind of behaviour from a disk space (and network preparation) perspective. I guess that's partially possible now with shared resources, but most networks would still be "duplicated" when using scenarios for these kinds of sensitivity analyses right?