Here is a list of things we observed while integrating Tulipa with annular - logging seems funky: on Abel's machine, it did not seem to do anything (we needed print); ~~logging on `pytest` with `--log-cli-level=DEBUG` crashes tests that use muscle3~~ -> I think this is fixed. - Have we run annular on mac ever? do we have CI? Abel was not able to run annular recently on his laptop, while the same version worked fine for me. We did not look further into i. - The simulation horizon is implicitly defined in the generator availability factors. I think it'd be better to do this explicitly, for instance by providing another input file, or a configuration option with start/end date and time resolution - We had some trouble working with pd timestamps and duckdb. In Tulipa, the time is just indexed by integers. annular needs to be date-aware, but I'm not sure it needs to be hour-aware, and perhaps it would make sense to have the simulation run in "integer time" and have a mapping to hours/dates that can be queried if necessary. - `validate_bids`: should it validate that bids are only for one day? or is this tested on the side of satellites? - More a question than an issue: our generator configs have the option for both linear and quadratic marginal cost. `Tulipa` only supports linear marginal cost, I think because it leads to a quadratic optimization problem? So, is Annular able to deal with this, or should we remove this option? - Format of market price and bids returned: it might be more robust for the market models to return time-indexed dataframes instead of (non-indexed) numpy arrays - various tests depend on creating bids for testing. They implicitly use they right format but this is brittle in case the format of bids changes. - some `literalinclude` in existing docs links to deprecated file names ("-" instead of "_"). ### Checklist - [x] I have checked the of [existing issues](https://gitlab.tudelft.nl/demoses/annular/-/issues) and couldn't find an issue about this.