Now I'm at 99.5 after 31,5h
On my S3

---

Now I'm at 99.5 after 31,5h
On my S3

These are wus for I7 or Ryzen, not for my little arm... :-(

I agree. I'll talk to the researcher. The long run time is due to filtering logic. Even on one of our local machines it takes about an hour to generate a model (after quite a few filtered attempts).

---

I've another one. 99,1% after 18h.

99,6 after 37h....a small agony
Now, i think 1000 points is earned!!! :-P

Although these slow jobs take longer to find a solution, they are heavily biased to sampling regions of conformation space that these peptides can actually access and which are relevant to our interests. That is, we might make the sampling rate slower by a factor of 100, but we're perhaps 1,000 or 10,000 times more likely for any given sample to be "useful". We're crunching numbers more intensively to produce better results instead of just relying on more sampling. I can say that the jobs that we're running now are successfully sampling the native state with fewer samples in cases in which incredible amounts of the old, naïve sampling produced nothing near the native state.

I'm not sure that we can make the sampling faster (i.e. produce more samples per CPU-hour), but the credit earned per sample should be proportional to the CPU-hours spent per sample, no?

We're crunching numbers more intensively to produce better results instead of just relying on more sampling.

This is not a problem, i like the science you do!!

the credit earned per sample should be proportional to the CPU-hours spent per sample, no?

I'm not sure. If i crunch a decoy in 2h with, for example, a Ryzen 1800x and the same decoy with my Huawei in 30h, i take the same points?

Since the android app is a separate application, the credit per decoy running average will only use results from android jobs. But there is the issue of possibly adding a correction factor to try to normalize the credits coming from the standard app vs the arm app given the same protocol. I'll have to look into this and it would require running some benchmarks and updating the standard app. The arm app is running the latest Rosetta version.

---

99,6 after 37h....a small agony

Now 99,7% after 57h.
Strange behaviour, it continues to slow down.
I don't think i'll finish before deadline (tomorrow morning).

Although these slow jobs take longer to find a solution, they are heavily biased to sampling regions of conformation space that these peptides can actually access and which are relevant to our interests.

i'm afraid, but it's 99,8% after 105h. I've killed this wus.

Hi:

I see there are many here who have tasks that have been running for quite some time. I have three that have gone well past their reply by time: one running for 74 hours at 99.2%, a second 29 hours at 98.1% and a third at 30 hors at 98.2%. This is using a Pixel on Android 7.1.2 (newest). Do I let them keep going or do I stop them?

Do I let them keep going or do I stop them?

I know these working units are important for admins/developers, but i kill all "ralphtest_c." wus

All with these warnings:

WARNING: linker: ../../projects/ralph.bakerlab.org/minirosetta_android_3.83_arm-android-linux-gnu: unused DT entry: type 0x6ffffffe arg 0x2828
WARNING: linker: ../../projects/ralph.bakerlab.org/minirosetta_android_3.83_arm-android-linux-gnu: unused DT entry: type 0x6fffffff arg 0x2
WARNING: linker: ../../projects/ralph.bakerlab.org/minirosetta_android_3.83_arm-android-linux-gnu: unused DT entry: type 0x6ffffffe arg 0x2828
WARNING: linker: ../../projects/ralph.bakerlab.org/minirosetta_android_3.83_arm-android-linux-gnu: unused DT entry: type 0x6fffffff arg 0x2
WARNING: linker: ../../projects/ralph.bakerlab.org/minirosetta_android_3.83_arm-android-linux-gnu: unused DT entry: type 0x6ffffffe arg 0x2828
WARNING: linker: ../../projects/ralph.bakerlab.org/minirosetta_android_3.83_arm-android-linux-gnu: unused DT entry: type 0x6fffffff arg 0x2
WARNING: linker: ../../projects/ralph.bakerlab.org/minirosetta_android_3.83_arm-android-linux-gnu: unused DT entry: type 0x6ffffffe arg 0x2828
WARNING: linker: ../../projects/ralph.bakerlab.org/minirosetta_android_3.83_arm-android-linux-gnu: unused DT entry: type 0x6fffffff arg 0x2
WARNING: linker: ../../projects/ralph.bakerlab.org/minirosetta_android_3.83_arm-android-linux-gnu: unused DT entry: type 0x6ffffffe arg 0x2828
WARNING: linker: ../../projects/ralph.bakerlab.org/minirosetta_android_3.83_arm-android-linux-gnu: unused DT entry: type 0x6fffffff arg 0x2
WARNING: linker: ../../projects/ralph.bakerlab.org/minirosetta_android_3.83_arm-android-linux-gnu: unused DT entry: type 0x6ffffffe arg 0x2828

please keep those going.

---

You can ignore those warnings. They are harmless. I will hopefully have those warnings removed in the next release soon.

---

please keep those going.

50h to crunch 0,1% i think 2 options:
- a bug in "ralph_test_c." wus
- my smartphone is too little to crunch these wus and i need an S8

I'll try another wu

I just finished correctly a "ralp_test_c." wu after 20k seconds.
But these wus are different from problematic "ralphtest_c."??

- a bug in "ralph_test_c." wus

"ralphtest_c.", i mean

Here again.
99,9% after 111h of crunching.
The deadline was 3 days ago.....
4044862

I have this problem:

In my "Tasks for user" page I have 4 WU in progress, but ....... on my smartphone I have 5 WUs. :-)

I don't know if this is a problem specific to android app or is a general problem

---

99,9% after 111h of crunching.

Still 99,9% after 145 hours.
What should i do?

I aborted those that I had at 99%. The others just timed out while the server was down.