CASP (Critical Assessment of Structure Prediction) experiments are held every two years. Recent rounds have seen dramatic increases in modeling accuracy, resulting from the introduction of deep learning methods: In 2018, for the first time, the folds of most proteins were correctly computed [1]; in 2020, the accuracy of many computed protein structures rivaled that of the corresponding experimental ones [2]; in 2022, there was an enormous increase in the accuracy of protein complexes [3].

We have seen the beginning of what deep learning methods may achieve in structural biology. In addition to further increases in the accuracy of protein complexes, methods are being developed for RNA structures, organic ligand-protein complexes, and for moving beyond single macromolecular structures to compute conformational ensembles. Accurate computational methods together with experimental data also offer the prospect of probing previously inaccessible biological systems. CASP has expanded its scope to provide critical assessment in all these areas.

CASP is only possible with the generous participation of the experimental structural biology community in providing suitable targets: A total of over 1100 targets have been obtained over the previous CASP rounds. We are now requesting targets for the 2024 CASP16 experiment.

The timeline for the 2024 CASP requires that targets are submitted starting now and until July 1. We would like to hear from you as soon as possible if you may have something suitable or have suggestions about other target sources. In order to maintain rigor, the experimental data for a target must not be publicly available until after computed structures have been collected. For assessment, CASP requires the experimental data by August 15, but the data can remain confidential after that. Target providers are invited to contribute to papers [11-15] for a special CASP issue of the journal Proteins.

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
08:36:42 (5544): called boinc_finish(1)

I have no problem with the project, just the python vbox app. Virtual box seems to be a real pain in the ass, IMHO.

AdaptiveCpp has been repeatedly shown to deliver very competitive performance compared to other SYCL implementations or proprietary solutions like CUDA.

No targets specification needed anymore! AdaptiveCpp now by default compiles with --acpp-targets=generic. This means that a simple compiler invocation such as acpp -o test -O3 test.cpp will create a binary that can run on Intel, NVIDIA and AMD GPUs. AdaptiveCpp 24.02 is the world's only SYCL compiler that does not require specifying compilation targets to generate a binary that can run "everywhere".

Current batch of Beta tasks have the same naming convention as Rosetta 4.20, and use a similar amount of RAM.

With the publicly accessible Rosetta repository, we're using the now-standard Fork-and-PR model for development. The benefits of this model is that it's standard for many Open Source projects, so there's plenty of documentation out there for it. (See the GitHub Documentation for a start.) It also allows potential contributions by people who aren't members of the RosettaCommons, and who do not have write access to the Rosetta repositories.

A basic development flow would proceed as follows:

1. Create a Fork of the Rosetta repository into your own userspace

2. Clone your forked repo into a local repository If you already have a local clone of the RosettaCommons/rosetta repo, you can convert it to reference your fork (see below).

3. Create a development branch in your local repository Your fork is your own personal workspace, so feel free to name your branch whatever you want -- you do not need to namespace it with your GitHub username Just keep in mind that the branch name will be visible to others when you eventually make a PR

4. Code, Code, Code Make your changes in the local repository

5. Create tests for your new code Run the tests locally. Also check the existing tests to make sure you didn't accidentally break anything.

6. Push your branch to your GitHub fork Your changes will stay within your fork until you release them, so feel free to stash whatever you like there.

7. Repeat 4-6 until your branch is ready

8. Open a PR against the Main RosettaCommons/rosetta repo using the GitHub interface A PR is your way of giving back your code changes to the community.

9. Your PR will be reviewed by other members of the RosettaCommons Reviewers are checking for bugs you may have missed, issues with code quality, and other potential issues with the code. The goal is to "peer review" your code and get it into a "publishable" state. Another thing they'll check for is that you've signed the developer or contributor licensing agreement.

10. If your PR passes review, it will get merged. Only someone with write access to the main RosettaCommons/rosetta repo can push the merge button - you don't do it yourself, another person will do it for you.

Q. Why don't you use the OpenSource-standard "inbound=outbound" model for licensing?

Rosetta uses a Fork-and-PR model for development. To start developing with Rosetta, use the "Fork" button on the RosettaCommons repo to create a new Rosetta fork in your own Github space. (Note that if you wish to alter the content of submodules, you will need to separately fork the submodule.)

You can then clone the repo from your space, start a new branch and edit your code. Feel free to push the code to your forked repo at any time - it will not affect the main Rosetta repository.
When you feel your contributions are ready to be incorporated into the main version of Rosetta, use the Pull Request (PR) feature of Github to open a PR, targeting your branch on your repo to merge into the main branch of the RosettaCommons/rosetta repo.

If you haven't already, you will need to sign the Rosetta Contributor Licensing Agreement (See below for details).

Once you've opened your PR, members of the Rosetta development team will take a look at the code and check to make sure it works in the wider framework of Rosetta. They may ask you to make some changes to alter your code to fit with Rosetta conventions, or to fix edge cases. Once your code looks good, they will squash-merge the code into the Rosetta main branch. (Squash-merge means that all of your changes will be re-written to be a single commit.)

Q. Why don't you use the OpenSource-standard "inbound=outbound" model for licensing?

A. To support RosettaCommons's ability to maintain Rosetta, the RosettaCommons currently charges a fee for commercial usage. All profits from the sale of Rosetta go toward supporting the scientific mission of the RosettaCommons. At the moment, we currently don't see a way to go officially (OSI) Open Source while keeping the same level of support. As a consequence, the Rosetta license is written in a way which privleges the RosettaCommons and their ability to charge a commercial license fee. However, licensing inbound contributions under that same license would result in an incompatible mess, particularly if we ever attempted to change the license in the future.

As such, the current code base is licensed under the existing licensing framework, but we ask new contributions to be submitted under more permissive terms, to allow flexibilty for future license changes.
To maintain RosettaCommons's ability to license Rosetta commercially, we ask that people sign a Contributor Licensing Agreement (CLA). (See CLA.md for the current text)

Please read and make sure you understand the agreement prior to signing, as it is a legal agreement. You only have to sign it once, as it will apply to all the contributions you submit to the RosettaCommons as PRs.

If you are making contributions as an employee (which includes employees and graduate students of academic institutions), you may have assigned rights for code you develop to your employer. In that case, please confirm with your employer that you are authorized to sign the CLA on their behalf. If you change employers, please re-sign the agreement with your new employer's information.

To sign the CLA, please visit https://www.rosettacommons.org/forms/cla.

If you are a member of a RosettaCommons lab, there is a separate Developers Agreement process. Please consult an existing member of the lab or your PI for details.

Q. Can I use the Rosetta code in my own software?

Use of Rosetta code in other projects is governed by the Rosetta license agreement. The combination of Rosetta with another program must maintain the Rosetta licensing terms for those portions which include Rosetta. In particular, use of Rosetta (or PyRosetta) as a library in another program does not negate the requirement for purchasing a separate Rosetta (and/or PyRosetta) license for commercial use of the combined program. Please contact UW CoMotion license@uw.edu with any questions about commercial licensing requirements for programs containing Rosetta code.

We note specifically that the Rosetta license is incompatible with the GPL and other such license with "share alike" provisions.

We're excited to announce that we have moved the Rosetta code repository to a public repository! We have made this move to honor our longstanding philosophy of sharing our work publicly and making it broadly accessible to scientists. This change marks a new chapter for Rosetta, where future developments will be more collaborative and accessible.

The repository's public status means that non-commercial users no longer need to explicitly sign up for a license to access Rosetta. However, despite being publicly accessible, Rosetta is not open source; redistribution restrictions and other licensing restrictions remain in place for all users. For our commercial users, the existing license will continue as before, with no immediate changes. New commercial users will also be required to purchase a separate commercial license.

Code contributions:
With the repository now open, we welcome code contributions from both academic and commercial users outside of the Rosetta Commons. To contribute, non-Rosetta Commons contributors will first need to sign a Contributor License Agreement, ensuring a smooth integration of contributions into the Rosetta codebase. Scientists in Rosetta Commons labs remain able to contribute under the terms of their Institutional Participation Agreement and individual Developers Participation Agreement.

.....3/3/2024 6:16:26 PM | GPUGRID | Requesting new tasks for Intel GPU
3/3/2024 6:16:27 PM | GPUGRID | Scheduler request completed: got 0 new tasks
3/3/2024 6:16:27 PM | GPUGRID | Project requested delay of 11 seconds
3/3/2024 6:42:43 PM | Einstein@Home | Computation for task h1_1257.80_O3aC01Cl1In0__O3ASHF1b_1258.00Hz_21329_0 finished
3/3/2024 6:42:43 PM | NumberFields@home | Starting task wu_sf6_DS-13x11_Grp7914498of10485760_0
3/3/2024 6:42:46 PM | Einstein@Home | Started upload of h1_1257.80_O3aC01Cl1In0__O3ASHF1b_1258.00Hz_21329_0_0
3/3/2024 6:42:46 PM | Einstein@Home | Started upload of h1_1257.80_O3aC01Cl1In0__O3ASHF1b_1258.00Hz_21329_0_1
3/3/2024 6:43:03 PM | Einstein@Home | Finished upload of h1_1257.80_O3aC01Cl1In0__O3ASHF1b_1258.00Hz_21329_0_0 (4273960 bytes)
3/3/2024 6:43:03 PM | Einstein@Home | Finished upload of h1_1257.80_O3aC01Cl1In0__O3ASHF1b_1258.00Hz_21329_0_1 (4

Is there work?

Is there a problem at the project?

Is there something wrong with my installation?

Vbox jobs still don't use multiattaching.

That's a really weird place to put it (should be on the project preferences page), but thank you for the information!

I added the VM Extension pack, but still having problems. The WUs will now at least run for a while (hours in most cases) but then still error out. Anyone figured out what else to do?

196 (0x000000C4) EXIT_DISK_LIMIT_EXCEEDED

To help us with testing and gathering performance statistics, we ask that you do not abort related work units.

Seems like 5 million tasks have become available to run !!

As of 24 Feb 2024, 8:02:19 UTC [ Scheduler running ]
Total queued jobs: 4,921,248
In progress: 115,690
Successes last 24h: 43,490