core_client_version>7.16.1</core_client_version>
<![CDATA[
<stderr_txt>
command: ../../projects/ralph.bakerlab.org/rosetta_4.14_i686-pc-linux-gnu -run:protocol jd2_scripting -parser:protocol predictor_v11_boinc--fuse--il1r_design_boinc_v1.xml @flags_il1r2 -in:file:silent 2cl4lm5k_Mini_Protein_binds_IL1R_COVID-19_test2.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 2cl4lm5k_Mini_Protein_binds_IL1R_COVID-19_test2.zip @2cl4lm5k_Mini_Protein_binds_IL1R_COVID-19_test2.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 3983067
Starting watchdog...
Watchdog active.
BOINC:: CPU time: 18365.7s, 14400s + 3600s[2020- 4- 5 19: 6:15:] :: 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  18365.7 cpu seconds
This process generated      1 decoys from       1 attempts
======================================================
19:06:15 (101755): called boinc_finish(0)

</stderr_txt>
]]>

Not sure about the warning at the top and the fact that it only created one decoy in the span of several hours

I'm not sure either. Likely job specific. Let's see if it continues.

Posted another application update to 4.15. This includes database files that are required for some protocols. As a result the size of the database has increased a little over 100MB.

Signed up after the call out over on the normal Rosetta forums. Been having issues with 4.12 on my older OSX machines (everything pre-2015 it seems fails all tasks immediately as many have reported).

I'm not sure if it's lack of WU or if something changed but my newer OSX machines (that always worked on 4.12) are happily crunching 4.14 units, but I'm not getting any units for the older machines that were having 4.12 issues. Are there no test WU's or are they now being cut out on purpose on the machines that they were failing on?


Rosetta 4.09 and Rosetta Mini continue to work on all machines. (All OSX machines running Bonic 7.14.4)


/edit I should add I'm not getting any 4.14 or later tasks on Ralph@home test machines older then 2015. More recent machines are getting tasks 4.14 and crunching fine.

All my machines did not like 4.13.

/edit 2 The bulk of my machines are in my office, won't be able to force them to try and grab more work until about 12 hours from now when I'm back at work.

I'm running 4.15 on my mac and processing seems to be working. Thanks for the update.

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.

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.

I only have my laptop here at home, 2012 MacBook Pro, latest Catalina, 2.93GHz Ivy Bridge i7 but it seems to be running normal Rosetta 4.15 tasks fine so far, whereas it would fail instantly running all 4.12 tasks.

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.

4.15 works on my three Macs where 4.12 would crash immediately. Thanks!

Any chance you can change the ARM64 version so it will run on a 2GB SBC? My 2GB Odroid C2 has a little over 1.7 GB of free RAM. The error says it needs 1.9GB. I'd like to be able to run one or two WUs on it.

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.

I aborted some of the older test batches. I'm not sure why your client is getting confused and running the wrong app. It should be running the 64bit version on your 64bit computer.

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.