Open rmcgibbo opened 10 years ago
Does the ProgressReporter have anything more, or not really?
The formatting is maybe slightly different, but it's basically the same stuff now.
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.)
Specify separator="\t". You'll mostly get even columns, though it won't rigidly enforce that.
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?
IMO we should remove it here to avoid duplication, and any improvements to StateDataReporter can be done with a PR on the OpenMM tracker.
Thanks, I agree.
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.
Thanks - I'll give it a try. I would expect the columns in successive rows to have basically equal width anyway. :)
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
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.
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
@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.
Sure, I can do that.
The key functionality is now in OpenMM 6's StateDataReporter.