[lmi] Automate input reconciliation?

[Greg Chicares]

Calling MvcModel::Reconcile() enforces self-consistency of input.
Input files created by lmi itself are already self-consistent,
but those created by external systems generally are not.

To see this with the very troublesome census recently discussed,
edit the first cell (Census | Edit cell...). A messagebox pops up,
complaining of inconsistencies. Press OK, and the inconsistencies
are resolved; the census manager updates accordingly.

This phenomenon can also be seen by direct drill-down editing.
Load the census and look at "InforceMonth" for the first cell:
it's five. Now change any other value in that row--e.g., click
the "InforceIsMec" checkbox (even changing one letter in the
"AgentName" field suffices): any change causes "InforceMonth"
to be corrected from five to six.

This reconciliation is always performed--i.e., inconsistencies in
input are resolved--before running any illustration, to ensure
that the illustration is correct. What you get, then, is based
not on the inconsistent input you see, but on reconciled input.
Forcing this reconciliation is the right thing to do; failing to
force it would be wrong.

Once you know what to look for, though, it's clearly anomalous
that the census manager displays inconsistent input unless and
until you edit it. Or, if you use "Census | Edit cell...", you
don't even have to be paying attention--the messagebox gets in
your face...for every single cell you edit. Our impression is
that end users train themselves to press "OK" heedlessly, and
regard the messagebox as a nuisance.

Wouldn't it make more sense to clean up the census while it's
being loaded, so that the visible anomalies described above
are never even seen? Yes, of course...but that takes time, and
how much delay are we willing to accept? Commit 8465685ad helps
us decide, by showing how much time the reconcile-while-loading
step takes.

Reconciliation is an iterative process: fixing one inconsistency
may expose another, which must then be fixed, and so on. Calling
Reconcile() once takes care of all inconsistencies. Calling it
again has no further effect, but still takes some time: that's
why this experimental change shows the time for the initial
reconciliation, and, separately, the time for one repetition.
For ease of reference, let's call the initial reconciliation R0,
and any re-reconciliation RR.

It must be borne in mind that a command like "Census | Run case"
implicitly reconciles each cell. If the cell had already been
reconciled, it's reconciled again--but less expensively: at a
cost of RR, not R0. Consider this scenario:

  Load census. Run all cells. Run all cells again.

With '-pyx=skip_reconciliation' (which suppresses this commit's
effect), the cost of reconciliation (in addition to all the
other work these commands do) is:
  nothing (load)
  R0 (run)
  R0 (run again)
With this commit (not suppressed), it's:
  R0 (load)
  RR (run)
  RR (run again)
Thus, the choice is not between paying for R0 or not paying;
it's between paying for R0 up front when the file is loaded,
and then paying only RR to run it (potentially more than once,
though I suppose a single run is most common).

If the cost of RR were zero, then I'd say we clearly want this
change: the extra time taken to load the file is saved when it
is run, so the total time remains the same, and we prevent the
annoying messageboxes and remove the visible anomaly in the
census manager for free.

But the cost of RR is not zero. At least now it's measurable,
so we can make a decision in light of concrete facts.

It seems obvious that the cost of RR can be reduced virtually
to zero with some extra work. It would take minutes to add an
already-reconciled flag, and some number of days to make it
work correctly. I'm not going to spend days on this now.