search

USEPA / EPA_MOVES_Model

Estimating emissions for mobile sources
Other
82 stars 23 forks source link

MOVES 3.1 inconsistent about auditlog I/M Programs Flag #53

Closed DEQjpowell closed 1 year ago

DEQjpowell commented 1 year ago

Required: MOVES 3.1 on Windows 10

MOVES is inconsistent about what constitutes a well formed county database between the command line and the graphical user interface.

To reproduce:

  1. Create a new county database outside MOVES, using for example SQL (structured query language).
  2. Using the XML you have in an existing run spec, change the county database name to the name of the database you just created.
    • This weird step is necessary to avoid the ugly side effect of a red check-mark from the GUI which is otherwise triggered at this step, see below.
  3. Launch MOVES from the command line using the Ant tool with that runspec. Observe: no error messages, useful output.
  4. Open the MOVES GUI (graphical user interface), and open the run spec you just used.

What I expect: green check-marks all the way, "ready to run" status.

What happens instead: red check mark for the input database. This will not go green until I use the user interface to check the "No I/M" box.

Background: checking the "No I/M" box causes the CDB to be modified in two ways.

  1. An annotation in the auditlog table: ,---- | INSERT INTO auditlog VALUES... | ,('2022-12-20 10:49:04','I/M Programs Flag','No data needed',''); `----

  2. A spammy list of probably harmless but useless entries in sourcetypeyear: ,---- | > (2020,42,0,0,0) `----

    • By the way, MOVES added /many/ entries for source type 42 with zeros in this step, all just like the above. Other source types too.

The modified CDB appears to produce the same output as the original, un-annotated, un-spammed CDB.

The GUI and the command line need to agree on what constitutes a well-formed input. This inconsistency causes confusion and delay.

Also, the bug that writes out the spammy sourcetypeyear entries should be fixed too, but this seems almost harmless and doesn't lie in the critical path of my work.

danielbizercox commented 1 year ago

As documented in the Command Line MOVES documentation, running on the command line (unfortunately) bypasses many of the helpful checks that the MOVES GUI provides. As part of the condition for getting all green checkmarks in the County Data Manager, the GUI looks for either 1) a properly filled out imcoverage table or 2) the presence of the "No I/M Program" checkbox being ticked. If the checkbox is not ticked and the table is empty, you will get a red X. If you run in this condition via the command line (it is impossible to run in this condition from the GUI), MOVES will use the default imcoverage table for the county and year that you are running. If there is no I/M program in the default database for this scenario, then the results will be the same as if you had checked the box and ran from the GUI.

The proper way to indicate that the "No I/M Program" checkbox is ticked is as you describe in method 1: create an entry in the auditlog table where the importerName column contains "I/M Programs Flag" and briefDescription column is "No data needed".

All that said, the MOVES team agrees that the GUI and the command line should provide the same level of error checking to prevent erroneous results, and the "No I/M Program" entry in the auditlog table could be better documented. We hope to include these in a future MOVES release. Thank you for the suggestion!

danielbizercox commented 1 year ago

The MOVES4 release provides the same level of input database error checking as the GUI. The "No I/M Program" checkbox feature is documented in docs/MOVESDatabaseTables.md, and we will include a note about it in our MOVES4 training materials. Thank you for your suggestion!