Message boards : RALPH@home bug list : cpu_run_time_pref
Author | Message |
---|---|
Darren Send message Joined: 16 Feb 06 Posts: 5 Credit: 777 RAC: 0 |
This is more of a comment than a bug I guess, and it may be totally unimportant. I had 2 WU's running on my HT machine with a run time setting of 4 hours. The second had 1 hour on it when the first was nearing completion. I then changed my online setting to 8 hours so any new work would go 8 instead of 4. To my surprise, and very neat, after reporting the first WU and doing the update triggered by that, it added 4 additional hours to the WU that was already underway. My comment, though, is about the stamp in the stderr output file. There is no entry showing the time was ever set to increase, leaving only the entry for "cpu_run_time_pref: 14400". Considering some of the complaints/problems from standard Rosetta about WU run times and units getting stuck and such, should there not be an entry (if for no other reason than troubleshooting) showing that the cpu_run_time_pref was reset to 28,800 (or whatever it was really reset to)? As it stands, just looking at this WU could lead to someone believing the program didn't work properly, as it says it should run 14,400 seconds, but it also says it really ran 29,014 seconds. |
dekim Volunteer moderator Project administrator Project developer Project scientist Send message Joined: 20 Jan 06 Posts: 250 Credit: 543,579 RAC: 0 |
We can add the stamp to stderr each time the preference is changed. |
Message boards :
RALPH@home bug list :
cpu_run_time_pref
©2024 University of Washington
http://www.bakerlab.org