jrissman
commented
2 years ago @ToddFincannonEI will be handling this item. Thank you, Todd.
A few points I've thought about but didn't write above, just in case they are useful.
- If the policy schedule rows are entered as Python data (rather than each row being one long string that Python parses), then text editors will color the elements differently, which might help users entering schedule data to avoid typos, like a missing comma. This would involve using different delimiters than in my example above. One possible example (using
#as the delimiter between schedules):
-
The .csv output files read by Vensim, such as
FoPITY-1.csv1, should always go to 2100, irrespective of the end date of the model run. This is necessary to keep the end date of the model run fully data-driven. The value for the latest specified year (typically 2050) should simply be repeated for every year after that up through 2100. Note that this only applies to the Vensim version of the .csv output file. The output .csv file read by the web app, such asFoPITY-1-WebApp.csv, contains ordered pairs and should not specify any dates later than the last date the user entered in their desired policy schedules (which should be the same as the model run end date). -
The output file
FoPITY-policy-elements.csvis the same for all 9 policy schedules and therefore only has to be generated once.
robbieorvis
Currently, it is annoying to add new policies (or new subscripts for an existing policy) to the policy schedules (FoPITY) for two reasons:
Issue 1 can be solved by getting rid of the blue output tabs. Instead, export the green "Set Schedules Here" tab to .csv, and use a Python script to read the exported "Set Schedules Here" data and build the corresponding .csv output files. The script could trivially copy the files for the first (default) schedule to fill in any unused schedule slots (i.e. up through FoPITY-9). Note that the format of the "Set Schedules Here" tab would change to make it easier for the Python script to read/process. In fact, it would probably be replaced with a text-based input file, entirely removing Excel from the process.
Issue 2 can be dealt with by having one input file set all 9 policy schedules. The easiest way to do this is probably to change the input format so that each policy gets a set of ordered pairs for each policy schedule, and there is a delimiter character between schedules. For example, here is a row that would set two different schedules for a single policy element:
In this example, I'm using the pipe character (
|) as the item delimiter, to distinguish it from the comma delimiter used within the ordered pairs. The character/is the delimiter between policy schedules. There could be up to 9 policy schedules listed per row, though only one schedule is required. The Python script would simply re-use the first defined schedule for any schedules that are undefined, up through schedule 9.After this update, adding a new policy would simply involve opening one text file, adding one row for each subscript element of the new policy, and setting the schedule data all on that same row. It would be much more compact (rather than a spreadsheet with many columns) because schedule data would be entered as ordered pairs. There would be no more dealing with multiple files, no more copying and pasting anything, no repetitious definitions of policy and subscript names, and no more updates to formulas on blue output tabs. In fact, the Python script itself could be the place where the policy schedule data is set. And since it's all text-based, it would work better with Git and change tracking.
This issue added based on feedback from @robbieorvis on 11/17/2021.