The current implementation of conversion.csv is not great as it requires an in depth understanding of how the model works to interact with. A user understanding this file must know the name of the nodes that the converter will be in between. Furthermore, if there are two converters in a row, the user must know that the converter that the upstream converter must be listed before the downstream in the file. (At the very least, an error should be raised; however, it should be easy enough to re-sort so this issue doesn't happen too).
I'm not 100% certain on how I'd like to implement this, but here is my initial thought.
Create a file data/converters_def.csv. This file contains three columns:
converter_class (currently the "converter" column in conversion.csv input),
arc_start_class, and
arc_end_class.
Refactor the conversion.csv input file:
rename "converter" column to "class". Matches to converter_class in data/converters_def.csv
make the index column a new column (named "converter"). The data could be identical to the "class" column, or it could not. Users would get to define a custom technology that is placed in the same location as class. This way, multiple conversion technologies could be evaluated.
Leave numerical columns alone.
This allows advanced users to still change things around with the model construction, but without obfuscating the most important inputs. Users have the ability to evaluate multiple versions of the same type of converter.
I anticipate that there may be some issues in implantation. I don't know if the model construction can currently handle two parallel converters. The solver can; I just don't know if the current code is robust enough for this yet.
The current implementation of
conversion.csvis not great as it requires an in depth understanding of how the model works to interact with. A user understanding this file must know the name of the nodes that the converter will be in between. Furthermore, if there are two converters in a row, the user must know that the converter that the upstream converter must be listed before the downstream in the file. (At the very least, an error should be raised; however, it should be easy enough to re-sort so this issue doesn't happen too).I'm not 100% certain on how I'd like to implement this, but here is my initial thought.
data/converters_def.csv. This file contains three columns:conversion.csvinput),conversion.csvinput file:data/converters_def.csvThis allows advanced users to still change things around with the model construction, but without obfuscating the most important inputs. Users have the ability to evaluate multiple versions of the same type of converter.
I anticipate that there may be some issues in implantation. I don't know if the model construction can currently handle two parallel converters. The solver can; I just don't know if the current code is robust enough for this yet.