You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The way that we control the indexing - to prevent sparsity issues - is to precompute the indexes of the variables. The way that we are doing it right now is to compute tables for these indexes. Assuming that keeps being the case, we have to define what is necessary for these tables and define their names.
These tables will probably also save the final result, so they are used outside of the model as well.
If we use tables as DuckDB tables, currently have 1:3 in the column but we have to change to two columns (?) 1 and 3.
Maybe it makes sense to keep these tables (only) as DF, so we keep storing ranges and possibly JuMP variables in them
Create a TulipaVariable struct and store the DuckDB table with the indexes (i.e., each row corresponds to a index), and store also a Vector of JuMP variables
The text was updated successfully, but these errors were encountered:
The way that we control the indexing - to prevent sparsity issues - is to precompute the indexes of the variables. The way that we are doing it right now is to compute tables for these indexes. Assuming that keeps being the case, we have to define what is necessary for these tables and define their names.
These tables will probably also save the final result, so they are used outside of the model as well.
If we use tables as DuckDB tables, currently have 1:3 in the column but we have to change to two columns (?) 1 and 3.
Maybe it makes sense to keep these tables (only) as DF, so we keep storing ranges and possibly JuMP variables in them
Create a TulipaVariable struct and store the DuckDB table with the indexes (i.e., each row corresponds to a index), and store also a Vector of JuMP variables
The text was updated successfully, but these errors were encountered: