Juha Kiviluoma

My preference is to write equations like this:  Using capitals to indicate parameters is not as readable as distinguishing with v and p. There are issues with the way...

You wouldn't need to use the full long names - they could be a reasonable shorthand. The nomenclature could still be there to show the long form name. I think...

If you can get the formatting to have the superscript and subscripts aligned on top of each other, that would be great!

Great!

We're working to have something to present in Leuven. It's epic yes and should then be broken into sub-issues.

We should use method parameters to ensure that the user gets the intended behavior. The new SpineOpt data structure proposal includes method parameters - for example investments would be triggered...

Sounds very good. Just making sure that my intuition works here: I would assume t_consecutive_t would contain tuples like [A1, A2], but not [A2, A1] nor [A1, B2]. Right? And...

I think it's fine unless there is need for t_consecutive_t(t_after=t) (as per Jody's example), then it should be called t_former_t or t_preceding_t. Maybe the latter is more intuitively [A2, A1].

Thanks for the information! In the case of these energy system models, it can be sometimes difficult to predetermine the scaling factors, since in investment problems the investment variables are...

@manuelma I believe you did something about this already - are there remaining cases that would still benefit from this? Could they be listed here?