Yes, this is what i have been using and it works.

However, I noticed a different problem now:

When i fix the capacities after the first run, and rerun the model, it may occur that the constraint, which remains in the model after the first run, causes an infeasibility. This happened because of minor constraint violations that occured during the first solve, e.g., I got

Link-ext-p_nom-lower[PL0 0 urban central water pits charger-2030]: +1 Link-p_nom[PL0 0 urban central water pits charger-2030] ≥ 8892.54423403
Store-ext-e_nom-upper[PL0 0 urban central water pits-2030]: +1 Store-e_nom[PL0 0 urban central water pits-2030] ≤ 1333881.6351
TES_energy_to_power_ratio[50]: +1 Store-e_nom[PL0 0 urban central water pits-2030] - 150 Link-p_nom[PL0 0 urban central water pits charger-2030] = -0

This is infeasible, because: 150 * 8892.54423403 = 1333881.6351045 > 1333881.6351

Not sure how to best solve it, for a quick fix i just allowed the store to be extendable, because this constraint anyways forces store and link to be proportional. Not sure why it occured in the first place, since it should only affect extendable link and i thought i had all of them disabled 🤔

Anyways, while i am figuring this out, this PR can be merged

Yes, this is what i have been using and it works.

However, I noticed a different problem now:

When i fix the capacities after the first run, and rerun the model, it may occur that the constraint, which remains in the model after the first run, causes an infeasibility. This happened because of minor constraint violations that occured during the first solve, e.g., I got

Link-ext-p_nom-lower[PL0 0 urban central water pits charger-2030]: +1 Link-p_nom[PL0 0 urban central water pits charger-2030] ≥ 8892.54423403
Store-ext-e_nom-upper[PL0 0 urban central water pits-2030]: +1 Store-e_nom[PL0 0 urban central water pits-2030] ≤ 1333881.6351
TES_energy_to_power_ratio[50]: +1 Store-e_nom[PL0 0 urban central water pits-2030] - 150 Link-p_nom[PL0 0 urban central water pits charger-2030] = -0

This is infeasible, because: 150 * 8892.54423403 = 1333881.6351045 > 1333881.6351

Not sure how to best solve it, for a quick fix i just allowed the store to be extendable, because this constraint anyways forces store and link to be proportional. Not sure why it occured in the first place, since it should only affect extendable link and i thought i had all of them disabled 🤔

Anyways, while i am figuring this out, this PR can be merged

Thanks for the review! Infeasibilities after fixing some decisions are quite common. Did you try enabling cross-over or tightening the infeasibility tolerance (and loosening it for the second run)?