I'd like to comment.

I see a problem, a problem that I should not be seeing. I try to make headway to resolve it, so ask. The result of asking each time is the same, basically, the BOINC folk tell me the problem is Folding, the Folding folk tell me it is not.

I have set no new tasks at both. I would seem to face a choice, I can support one or the other. Both are important to me.

Is this a new form of the Rosetta program or just a new structure or new way of working on a protein?

Who knows?
Meantime i noticed that the db we are using (open the screensaver) is 2022.33 (August 2022) and the latest is 2024.16 (2 days ago).
A refresh of the db will be welcome...

I've set no new tasks again. The current jobs have 8 hours as their runtime, but here, they are running for three times that, (4GHz i7), which is pushing my system into panic mode.

Just downloaded 4 beta 6.05 tasks one of which immediately (0.02 seconds CPU) failed with :-

<core_client_version>7.24.1</core_client_version>
<![CDATA[
<message>
process exited with code 1 (0x1, -255)</message>
<stderr_txt>
command: ../../projects/boinc.bakerlab.org_rosetta/rosetta_beta_6.05_x86_64-pc-linux-gnu @7a_hal_c_hal_7aa_12899_d40_0001.flags -nstruct 10000 -cpu_run_time 28800 -boinc:max_nstruct 20000 -checkpoint_interval 120 -mute all -database minirosetta_database -in::file::zip minirosetta_database.zip -boinc::watchdog -boinc::cpu_run_timeout 36000 -run::rng mt19937
Using database: database_0f7f01a1b07/database

ERROR: Error in protocols::cyclic_peptide_predict::SimpleCycpepPredictpplication::set_up_n_to_c_cyclization_mover() function: residue 1 does not have a LOWER_CONNECT.
ERROR:: Exit from: src/protocols/cyclic_peptide_predict/SimpleCycpepPredictApplication.cc line: 2442
BOINC:: Error reading and gzipping output datafile: default.out
21:15:06 (176255): called boinc_finish(1)

</stderr_txt>
]]>

Boinc 7.24.1 and Ubuntu 22.04.4

While you guys can discount my approach and everything I have said, things are going well now with all four projects to which I am attached, especially Rosetta which continues to return positive results.

BTW... .1 and .01? what the *%*%* is that nonsense. At minimum .25 and .25 for a half day queue. or .25 and 0 for a 1/4 day. But honestly....stop messing around with those values. .25 or .50 or some combination of the two for a quarter or a half or three quarters of a day of queued work. But first, NO NEW WORK!

Once again you've got it wrong.

Set the cache to an appropriate value, which for more than one project is 0. There is no need for a 3/4 day, 1/2 day or 1/4 day cache- it is completely, totally and utterly redundant & pointless unless every single one of the projects you are attached to has intermittent work availability or server up time. Since that isn't the case, there is absolutely no need for a cache of work.
And that alone will stop new work from coming until the system is ready for it. There is absolutely no need to remove projects, no need to set No new work on one or more projects, then re-enable it again later on. There is absolutely no need to fart-arse around with such things when setting the cache to 0.1 and 0.01 will do it for you, and stop the issue from re-occurring in the future.

Just set the cache to a reasonable level- and for multiple projects that is no cache, which 0.1 & 0.01 provides, while still allowing enough work to download so that when one Task finishes, another is ready to run & you don't have to wait for it to download before it can start. Any more fiddling around than those 2 values is unnecessary.

PrimeGrid is showing on your computer info page here at Rosetta. Following the link to your computer and tasks at PrimeGrid shows contact Feb 16th and a task 'timed out and no response'

https://boinc.bakerlab.org/rosetta/show_user.php?userid=2400235

http://www.primegrid.com/hosts_user.php?userid=1646462
http://www.primegrid.com/results.php?hostid=1323608

I would suggest setting 'no new tasks' to almost all your projects and just pick one or two projects to run for now. You can switch running projects in a few weeks or a month.

There really is nothing quite so tiresome as random people claiming the project is going to close down because they had a period with no tasks.

Not sure as the front page and server status page haven't been updated quite yet, but another batch of tasks seem to be coming through

Very small - maybe 50-60k. Not even enough to fill all cores at any one time.
Ah well, something.

The majority of the work goes to their 3 channel deep learning system.
That's what I saw on Robetta at least.
Robetta is the system that feeds all systems right? There is no separate system that feeds here?

You never seem to get tired of whining about something, do you
I thought you were going to leave
The latter would be preferable if the former is the only thing you ever have to say

[snip]

The majority of the work goes to their 3 channel deep learning system.
That's what I saw on Robetta at least.
Robetta is the system that feeds all systems right? There is no separate system that feeds here?

Robetta is a system that allows people outside their campus to enter work. This creates workunits with names that start with rb_ .
Work can also be created on campus, giving workunits with names that don't start with rb_ and at least used to be most of what was available.

There really is nothing quite so tiresome as random people claiming the project is going to close down because they had a period with no tasks.

Not sure as the front page and server status page haven't been updated quite yet, but another batch of tasks seem to be coming through

Very small - maybe 50-60k. Not even enough to fill all cores at any one time.
Ah well, something.

WCG now appears to be trying to get more useful work done by sending mostly tasks with small total sizes of the input files, such as tasks for the OPN1 subproject.

Is that what others are also seeing?

Not especially. My machine is set to process 4 WCG tasks at a time and is currently running
2 ARP1 and 2 OPN1 tasks. (and one more OPN1 ready to go.) True, I get fewer of the ARP1 tasks, sometimes none. Most of the time when my Boinc-client requests more work, it does not get any.

It is also runninig 4 Rosetta 4.20 tasks. Three 14res_af and one SRS9mpnn.

They're now back to tasks for at least three sub-projects, at the cost of much less total work.

The ARP1 tasks now seem to be only retries for tasks originally sent out about a week ago.

Download problems again.

Thanks, but it doesn't work for me. Also, I can't attach to any location except "school", even if I detach from the project and reattach.

EDIT: I can change locations by "resetting" the project, instead of detach/reattach.
But even that trick worked only on my Win10 machine, not my Ubuntu 20.04 machines.