Remove ProgressReporter

[rmcgibbo]

The key functionality is now in OpenMM 6's StateDataReporter.

[leeping]

Does the ProgressReporter have anything more, or not really?

[rmcgibbo]

The formatting is maybe slightly different, but it's basically the same stuff now.

[leeping]

Does StateDataReporter have the ability to report stuff in straight columns? (I'm a perfectionist with formatting but I know it's not that important.)

[peastman]

Specify separator="\t". You'll mostly get even columns, though it won't rigidly enforce that.

[leeping]

I agree tab characters are a bit weird, and I try to avoid them (a habit that comes from coding).

I think improved formatting might be worth adding to StateDataReporter if we want to remove ProgressReporter, because clean formatting is good for the user to see in a terminal. I spend a lot of my time visually scanning numbers in the terminal which is why I have this preference.

I think Robert did a nice job with constant-width column formatting in ProgressReporter; is this something we can add to StateDataReporter?

[rmcgibbo]

IMO we should remove it here to avoid duplication, and any improvements to StateDataReporter can be done with a PR on the OpenMM tracker.

[leeping]

Thanks, I agree.

[peastman]

Have you actually tried using tabs as delimiters? If not, try it out. Constant width columns are notoriously problematic - just look at PDB files if you have any doubt of that. You either have to use excessively wide columns (which is a problem when you're trying to produce clean output to a console), or you run into situations where you need to display values that are wider than the column. Tab delimited columns are just as easy to read, but can adapt if the values grow. They also are much easier to process, which is relevant even when they're mainly intended for display. You can copy the output from your console window, paste it into a spreadsheet, and it comes out exactly right the first time.

[leeping]

Thanks - I'll give it a try. I would expect the columns in successive rows to have basically equal width anyway. :)

[leeping]

I found that sometimes the number of decimal places can change by a lot, which shifts things over by a whole tab. Otherwise, the formatting works quite well and we can go with it.

5.6%    5.0     1252473.53203   2216537.57037   3469011.10241   769373.384442
11.1%   10.0    1340641.91412   2047015.38806   3387657.30219   710531.225894
16.7%   15.0    989168.186567   1705568.46992   2694736.65649   592012.968173
22.2%   20.0    1038417.54812   1742739.21417   2781156.76229   604915.154757
27.8%   25.0    832425.755724   1392740.65437   2225166.4101    483428.571312
33.3%   30.0    914538.920323   1360749.99133   2275288.91166   472324.421749
38.9%   35.0    627985.092731   932921.997803   1560907.09053   323822.778582
44.4%   40.0    581319.406421   931972.052551   1513291.45897   323493.046931
50.0%   45.0    466164.40515    616558.426117   1082722.83127   214011.099721
55.6%   50.0000000001   484744.955925   624949.877623   1109694.83355   216923.822488
61.1%   55.0000000001   354533.688987   446485.058617   801018.747603   154977.621513
66.7%   60.0000000001   325565.877183   439053.314182   764619.191365   152398.018783
72.2%   65.0000000001   235167.422606   323697.456073   558864.878679   112357.313786
77.8%   70.0000000002   277694.55042    341884.59416    619579.14458    118670.177674
83.3%   75.0000000002   209955.405874   222540.570894   432495.976768   77245.1568126
88.9%   80.0000000002   189819.367995   226371.089996   416190.457992   78574.7527938
94.4%   85.0000000002   137761.480159   102288.22808    240049.708239   35504.8528292
100.0%  90.0000000002   133845.209642   113729.299219   247574.508861   39476.1167235

[peastman]

I bet you ran that with Python 2.7. Python 3 switched to a different way of formatting numbers that doesn't produce things like 50.0000000001.

[leeping]

Hi Peter,

I've done a number of different simulations over the past few days using the two Reporters, and to be honest I still like the fixed-width formatting more. One benefit is that the column headings are matched up with the column content - otherwise it's possible to get confused as to which one is potential energy, which one is kinetic energy etc.

Because of this, I would still like to incorporate fixed-width formatting into the StateDataReporter, but the user interface could be a simple on/off switch rather than a slew of new options.

A comparison of the two (not apples to apples because different systems):

Current ProgressReporter

Progress   WallTime Left      Speed          Time            P.E.            K.E.        Total E.          Temp        Vol        Rho
     (%)       (d:h:m:s)   (ns/day)          (ps)        (kJ/mol)        (kJ/mol)        (kJ/mol)           (K)     (nm^3)     (g/mL)
  0.000%              ??       0.00       0.00000    -12349.88918      1586.42099    -10763.46819     295.13126     6.4765     0.9977
  0.020%         1:00:01     239.83       2.00000    -11597.68733      1049.51717    -10548.17016     195.24788     6.3859     1.0119
  0.040%           57:52     248.69       4.00000    -11445.95390      1095.22004    -10350.73387     203.75025     6.3862     1.0118
  0.060%           57:11     251.64       6.00000    -11386.84742      1180.80703    -10206.04039     219.67250     6.5190     0.9912

Current StateDataReporter

#"Progress (%)" "Time (ps)"     "Potential Energy (kJ/mole)"    "Kinetic Energy (kJ/mole)"      "Total Energy (kJ/mole)"        "Temperature (K)"
11.1%   5.0     174564.58254    101618.557217   276183.139757   74751.6128986
22.2%   10.0    159233.886472   92894.9338741   252128.820346   68334.4295314
33.3%   15.0    132363.05001    63951.7447281   196314.794739   47043.5341442
44.4%   20.0    115207.705587   40785.2471523   155992.952739   30002.0300486
55.6%   25.0    106238.37542    34424.4895082   140662.864928   25322.9939927
66.7%   30.0    91887.465263    23123.6322535   115011.097517   17009.9719418
77.8%   35.0    85418.1738723   16532.22716     101950.401032   12161.2693475
88.9%   40.0    79640.6846378   11345.6646349   90986.3492728   8345.98280175
100.0%  45.0    73796.7076056   5446.9589777    79243.6665833   4006.83674447

[rmcgibbo]

@leeping: let's open this as an issue in OpenMM, where we can figure out how to improve StateDataReporter so that it fits everyone's use cases.

[leeping]

Sure, I can do that.