Ekaterina

I can reproduce CI error locally when using `lgpk`, while the workflow works with `cbc`

Hey @davide-f! Thanks a lot for the detailed analysis :) Ah, I see: the load is an input, not a result. So, `n.loads_t.p_set` is in fact more appropriate than `n.loads_t.p`....

Some adjustments were done to get closer to PyPSA-Eur implementation. However, `glpk` solution still breaks. The reason seems to be the following command is given to a solver: `'glpsol --lp...

Results of additional testing: 1) now highs is captured and used; 2) some introduced changes make a testing problem infeasible, and it looks like the reason for it is that...

> IT may be good to revive this PR and finalize it when possible, to be able to use the latest pypsa version. How far do you think we are...

Testing with the updated PyPSA version (0.25.2 is used locally). Clustering is failing currently: 1) the default SCIP solver (copy-pasted from PyPSA-Eur) is not included into PyPSA-Earth environment; 2) `ipopt`...

> Great work :) I see it is in work in progress; the CI is complying about the number of clusters; if/once you need a review/check, ping me :) Thanks...

Update: The PR allows to run the workflow with the latest version of PyPSA (0.27.1), but gplk error persists:`INFO:linopy.solvers:Invalid option '--solver_logfile'; try glpsol --help`. I suspect, that leads to troubles...

Testing with `cbc` also fails in some enigmatic way: optimisation itself is successful, while the workflow crashes after with `TypeError: cannot unpack non-iterable NoneType object` in `status, condition = n.optimize.optimize_transmission_expansion_iteratively(**kwargs)`....

> Great work :) I see it is in work in progress; the CI is complying about the number of clusters; if/once you need a review/check, ping me :) @davide-f...