Please post issues/bugs relating to minirosetta version 1.35 here. Version 1.35 is an attempt to fix several issues from the 1.34 release, including bugs in hydrogen bonding and long run times for certain workunits.

The super-long run times are occasionally a problem with the jobs that we send out to you. So if you encounter such a job, please post to this thread so we can properly adjust the parameters of the job to reduce the run times.

---

Hello all,

The next WU ended with a error: -1073741819 (0xffffffffc0000005) Unhandled Exception Detected...
hombench_mtyka_foldcst_boinc_test2_foldcst_simple_t327___5001_2_1

Important to tell; after ± 5 minutes runtime I started boinc.scr which started OK. But didn't close anymore.
Not able to start Taskmanager I decided to hit the “sleep' button on my keyboard. After “awakening” my computer, the minirostta seemed to crunch on. However some 10 minutes later my firewall asked permission for Minirosetta 1.35 to contact the Internet.

Have a nice weekend,
Path7.

1.35 still has the same problem that 1.34 had with the Granted credit being the same as the Claimed credit.

Also RAC decay has still not been implemented, on either participants or participants computers, project stats have no current merit.
It used to work some months ago then stopped during one of the updates and has not worked since.

---

One more -1073741819 (0xffffffffc0000005) error for hombench_mtyka_foldcst_boinc_test2_foldcst_simple_t317___4997_3_2, with large BOINC Windows Runtime Debugger output.

- Unhandled Exception Record -
Reason: Access Violation (0xc0000005) at address 0x006AA016 read attempt to address 0x403E8A08

And the callstack looks weird - the accvio happened at the same address as in the Path7's case, but the call stacks are definitely different.

Peter

So if you encounter such a job, please post to this thread so we can properly adjust the parameters of the job to reduce the run times.

...any progress on getting the tasks to automagically report back to you with the runtime for each model? Seems to be a key piece of data that has been neglected in the past. We've been seeing occaisional 4-6 hour models for quite some time and have always assumed they were within the normal range.

---

So if you encounter such a job, please post to this thread so we can properly adjust the parameters of the job to reduce the run times.

...any progress on getting the tasks to automagically report back to you with the runtime for each model? Seems to be a key piece of data that has been neglected in the past. We've been seeing occaisional 4-6 hour models for quite some time and have always assumed they were within the normal range.

We do get that information from our workunits, but it can take a while for that data to come back, especially if the workunits take a long time to make a single decoy. To get a good estimate on the actual amount of time required to make a single decoy, we also need a lot of data because different people have very different computational power available for R@H.

We're doing an update today with more finely tuned parameters for job runtimes, so hopefully this won't be an issue soon. We're also reverting to an older version of the BOINC API that should eliminate at least some of the access violation errors, the BOINC API for v1.35 had some errors.

More soon. Thanks for your input!

---

I'm also adding a reporter column to our data files which should report individual decoy times. THat way we should be able to catch "stray" or spurious run-time outliers.

Are you enhancing the watchdog as well? To "think" at the model level, rather then the task level, about when things have been running too long?? In fact, perhaps the watchdog could abort the current model, and continue running the rest of the task?

---