We will likely issue jobs with lower memory requirements in the near future.

---

Where can I get a newer client, I found only 7.14.4 or is this the latest?

All R@H WUs fails on 32bit version of Windows. Because R@H try to start 64 bit versions (which actually not 64 bit, but 32bit app in the 64bit wrapper).

06/04/2020 10:44:10 | ralph@home | Finished download of minirosetta_database_357d5d93529_n_methyl.zip
06/04/2020 10:44:43 | ralph@home | [error] Process creation failed: (unknown error) - error code 193 (0xc1)
06/04/2020 10:44:44 | ralph@home | [error] Process creation failed: (unknown error) - error code 193 (0xc1)
06/04/2020 10:44:45 | ralph@home | [error] Process creation failed: (unknown error) - error code 193 (0xc1)
06/04/2020 10:44:45 | ralph@home | [error] Process creation failed: (unknown error) - error code 193 (0xc1)
06/04/2020 10:44:46 | ralph@home | [error] Process creation failed: (unknown error) - error code 193 (0xc1)
06/04/2020 10:44:51 | ralph@home | [error] Process creation failed: (unknown error) - error code 193 (0xc1)
06/04/2020 10:44:52 | ralph@home | [error] Process creation failed: (unknown error) - error code 193 (0xc1)
06/04/2020 10:44:52 | ralph@home | [error] Process creation failed: (unknown error) - error code 193 (0xc1)
06/04/2020 10:44:52 | ralph@home | [error] Process creation failed: (unknown error) - error code 193 (0xc1)
06/04/2020 10:44:52 | ralph@home | [error] Process creation failed: (unknown error) - error code 193 (0xc1)
06/04/2020 10:44:57 | ralph@home | [error] Process creation failed: (unknown error) - error code 193 (0xc1)
06/04/2020 10:44:58 | ralph@home | [error] Process creation failed: (unknown error) - error code 193 (0xc1)
06/04/2020 10:44:59 | ralph@home | [error] Process creation failed: (unknown error) - error code 193 (0xc1)
06/04/2020 10:44:59 | ralph@home | [error] Process creation failed: (unknown error) - error code 193 (0xc1)
06/04/2020 10:44:59 | ralph@home | [error] Process creation failed: (unknown error) - error code 193 (0xc1)

error code 193 = Application is not a valid Win32 app

If you want to drop win32 support, then should not send work to all such hosts and rise min system requirements.

7.14.2 and 7.14.4 are the latest stable versions of BOINC client.

But there are never beta-test versions available:

https://boinc.berkeley.edu/download_all.php

https://boinc.berkeley.edu/dl/

I'm not sure why your client is getting the 64bit wrapper of our "minirosetta" app which is an older version of rosetta that is still used for forward folding experiments. I'll see if I can build the 64bit version of the old app and see if that helps. So this is not an issue with the "rosetta" app? The "rosetta" app is a 64bit build.

---

The "rosetta" app is a 64bit build.

??
I'm crunching 32 bit "rosetta" 4.13 app on my Windows 10 64 bit hosts.
In Rosetta@Home i have 4.12 app at 64 bit.

All my wus not Covid was aborted by project. All was 4.13 version.
Waiting for 4.15 wus.

Not sure if the failed WU's are because of the batch, because of the application, or because of the machine, but both my MacPro's (2012, Xeon based) are showing mixed results on 4.15 over on Rosetta. (Not Ralph.)
Host: https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=3876438
Example "error while computing" after apparently completing tasks ~8hrs:
https://boinc.bakerlab.org/rosetta/result.php?resultid=1141134856
https://boinc.bakerlab.org/rosetta/result.php?resultid=1141134857

And several more... But also at the same time several other WU's did complete without issue:
https://boinc.bakerlab.org/rosetta/result.php?resultid=1141134616
https://boinc.bakerlab.org/rosetta/result.php?resultid=1141134621

Other host is showing similar returns...
https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=3752305

Still waiting on my other older machines to compete units. So far just the MacPro's are showing oddities.

https://boinc.bakerlab.org/rosetta/result.php?resultid=1141395048

Another failure on a different machine, but same message. "finish file present too long"

Are these just bugs in the work units? The same machine had 8 cores, 8 tasks going all at once, starting at the same time. They all finished at almost the same time... Of the 8, two failed, and 6 finished without error.


/edit. Sorry this is from Rosetta 4.15, not Ralph, but figured here would be the place to ask.

I received this too
https://ralph.bakerlab.org/result.php?resultid=4963304
Probably admin already know the errors since are recorded on ralph database. I don't know if we need to report each error.

Note my computer has been restarted unexpectedly at a moment, probably local issue.

I hope they will try widely 4.15 version before release it on production in Rosetta@Home.

I hope they will try widely 4.15 version before release it on production in Rosetta@Home.

Posts from the admin give me hope - but they'll need more volunteers here in order to ensure that, from what I understand.

Posts from the admin give me hope - but they'll need more volunteers here in order to ensure that, from what I understand.

It's not a problem. If you release work, the volunteers will arrive

I hope they will try widely 4.15 version before release it on production in Rosetta@Home.

Posts from the admin give me hope - but they'll need more volunteers here in order to ensure that, from what I understand.

That's what Ralph@home is for - testing new versions before they are released on Rosetta@home.

Posts from the admin give me hope - but they'll need more volunteers here in order to ensure that, from what I understand.

It's not a problem. If you release work, the volunteers will arrive

From the Admin's post earlier:

4.12 was tested on Ralph but not thoroughly enough. We wanted to get it out anyway so that we can start working on the scaffolds. Time is important. We've been trying our best to get this next app version pushed out. But want it thoroughly tested now since we are still able to get important COVID-19 work done on R@h with 4.12.

I'm inferring that they wanted to test it further, but time restraints forced them to release it to the public build sooner - they didn't have enough volunteers to test them thoroughly enough here, without delaying their research.

Hence - they have time now, so there's no urgent rush at the moment. But it implies that they do need to get 4.15 out in order to do the next stage of work, but 4.12+ on the public release can do important work for now.

It's all inferred, but given that there's only 269 active users here, 502 active hosts, I sincerely doubt they have enough volunteers here.

---

Maybe they are not promoting enough the test stage. I heard about ralph almost by accident.

I went ahead and posted the OSX update on R@h. We plan to update the rest of the platforms in the next day or so.

On Rosetta@home, the Mac 4.15 app is working well. I have had 3 end in a computation error at the end of processing. I've had trouble with Rosetta Mini 3.78 app they all fail immediately like the Rosetta 4.12 Mac app.

It is giving errors like:

<core_client_version>7.14.4</core_client_version>
<![CDATA[
<message>
process exited with code 255 (0xff, -1)</message>
<stderr_txt>
[2020- 4- 7 19:41:47:] :: BOINC:: Initializing ... ok.
[2020- 4- 7 19:41:47:] :: BOINC :: boinc_init()
BOINC:: Setting up shared resources ... ok.
BOINC:: Setting up semaphores ... ok.
BOINC:: Updating status ... ok.
BOINC:: Registering timer callback... ok.
BOINC:: Worker initialized successfully. 
command: minirosetta_3.78_x86_64-apple-darwin -abinitio::fastrelax 1 -ex2aro 1 -frag3 00001.200.3mers -in:file:native 00001.pdb -corrections::beta_nov16 -silent_gz 1 -frag9 00001.200.9mers -out:file:silent default.out -ex1 1 -abinitio::rsd_wt_loop 0.5 -relax::default_repeats 15 -abinitio::use_filters false -abinitio::increase_cycles 10 -abinitio::rsd_wt_helix 0.5 -abinitio::rg_reweight 0.5 -in:file:boinc_wu_zip CF_monomer_03_data.zip -out:file:silent default.out -silent_gz -mute all -nstruct 10000 -cpu_run_time 28800 -boinc:max_nstruct 600 -checkpoint_interval 120 -database minirosetta_database -in::file::zip minirosetta_database.zip -boinc::watchdog -run::rng mt19937 -constant_seed -jran 2413101
Registering options.. 
Registered extra options.
Initializing broker options ...
Registered extra options.
Initializing core...
Initializing options.... ok 
Options::initialize()
Options::adding_options()
Options::initialize() Check specs.
Options::initialize()  End reached
ERROR: Option matching -corrections:beta_nov16 not found in command line top-level context</stderr_txt>
]]>

The errors I get on the Mac 4.15 app are mostly like this one:

<core_client_version>7.14.4</core_client_version>
<![CDATA[
<stderr_txt>
command: rosetta_4.15_x86_64-apple-darwin -run:protocol jd2_scripting -parser:protocol predictor_v11_boinc--fuse--il1r_design_boinc_v1.xml @flags_il1r2 -in:file:silent 8er4nd4m_Mini_Protein_binds_IL1R_COVID-19_design5.silent -in:file:silent_struct_type binary -silent_gz -mute all -out:file:silent_struct_type binary -out:file:silent default.out -in:file:boinc_wu_zip 8er4nd4m_Mini_Protein_binds_IL1R_COVID-19_design5.zip @8er4nd4m_Mini_Protein_binds_IL1R_COVID-19_design5.flags -nstruct 10000 -cpu_run_time 28800 -watchdog -boinc:max_nstruct 600 -checkpoint_interval 120 -database minirosetta_database -in::file::zip minirosetta_database.zip -boinc::watchdog -run::rng mt19937 -constant_seed -jran 3296593
Starting watchdog...
Watchdog active.
======================================================
DONE ::   283 starting structures  29066.9 cpu seconds
This process generated    283 decoys from     283 attempts
======================================================
BOINC :: WS_max 8.82074e+08

BOINC :: Watchdog shutting down...
06:57:38 (55517): called boinc_finish(0)

</stderr_txt>
<message>
finish file present too long</message>
]]>

It looks like I also got a few of these on the Mac 4.09 app.

So I had the same error again on two more units that I pulled only a few hours ago from the server

<core_client_version>7.16.1</core_client_version>
<![CDATA[
<stderr_txt>
command: ../../projects/ralph.bakerlab.org/rosetta_4.15_i686-pc-linux-gnu -run:protocol jd2_scripting -parser:protocol predictor_v11_boinc--fuse--covid_spike_design_boinc_v1.xml @flags_Junior_HalfRoid_vs_COVID-19_test1 -in:file:silent 6np3ll6z_Junior_HalfRoid_vs_COVID-19_test1.silent -in:file:silent_struct_type binary -silent_gz -mute all -out:file:silent_struct_type binary -out:file:silent default.out -in:file:boinc_wu_zip 6np3ll6z_Junior_HalfRoid_vs_COVID-19_test1.zip @6np3ll6z_Junior_HalfRoid_vs_COVID-19_test1.flags -nstruct 10000 -cpu_run_time 3600 -watchdog -boinc:max_nstruct 600 -checkpoint_interval 120 -database minirosetta_database -in::file::zip minirosetta_database.zip -boinc::watchdog -run::rng mt19937 -constant_seed -jran 3983671
Starting watchdog...
Watchdog active.
Starting watchdog...
Watchdog active.
Starting watchdog...
Watchdog active.
BOINC:: CPU time: 18299.9s, 14400s + 3600s[2020- 4- 8  0:53:20:] :: BOINC 
WARNING! cannot get file size for default.out.gz: could not open file.
Output exists: default.out.gz Size: -1
InternalDecoyCount: 0 (GZ)
-----
0
-----
Stream information inconsistent.
Writing W_0000001
======================================================
DONE ::     1 starting structures  18299.9 cpu seconds
This process generated      1 decoys from       1 attempts
======================================================
00:53:20 (8724): called boinc_finish(0)

</stderr_txt>
]]>

It seems that this happens both here at Ralph and at main rosetta when the system sends me 32 bit tasks instead of 64bit ones. On rosetta the 64 bit tasks run as they should but the 32 bit 4.12 as well as 4.15 here that are 32 bit do not run right and only produce one decoy after hours of work. Hopefully this can be fixed

I'm inferring that they wanted to test it further, but time restraints forced them to release it to the public build sooner - they didn't have enough volunteers to test them thoroughly enough here, without delaying their research.

I know, i've read the admin's post.
I know, also, that with 4.15 version there are not only bugifix, but also some new science ("some new code related to COVID-19 interface design that we would like to push out to R@h soon.").
So, it is important to test it.

It's all inferred, but given that there's only 269 active users here, 502 active hosts, I sincerely doubt they have enough volunteers here.

After months and months of no work and no news, volunteer has gone (try to see the registration date of first page of top users. A lot of new users. Old users got tired of waiting).
But if you give work and news, people will arrive (see, for example, the forum and the wus of Rosetta).
(Also support to Raspberry will give more platform to test).

Maybe they are not promoting enough the test stage.

For sure!
The link in Home Page of Rosetta@Home to this beta project is very recent.