Would anyone like to check out the new site and provide some feedback before it goes live? If so, please send me an email and I'll respond with the temporary url.

Done!

---

Would anyone like to check out the new site and provide some feedback before it goes live? If so, please send me an email and I'll respond with the temporary url.

What's your e-mail?

---

dekim

at

uw

dot

edu

We hope to do the transition this month. The current server is operating as usual without any issues.

#TriesNotToHoldBreath

#Exhales

---

I beg your, rjs5, pardon if i have misspoken (i'm italian).
I think that the list in my first post is not in the correct order (i've insert it casually). In order of importance (IMHO):
1) Update compilers, tools, design software, etc, to have a better way to develop code (and, eventually, optimize it). Good code, good science.
2) Update the Boinc server code, to have a better web interface for volunteers (and better scheduler, validator and so on).
3) Update the server, for better security, bugfix, etc.

Done.
Now, the number one :-P

---

So, we're back. This coincided with me being away and 2 of my PCs crashing, so I'm only just getting up to speed.

- A small change in appearance in my Boinc Manager. Communication deferred for just 7 seconds following an update, down from 4 minutes previously. If that's ok for you, it's ok for me too.
- Task runtimes are showing as just 4hrs and some minutes for some reason - no idea why that's changed when I have an 8hr default. Lots of tasks coming down based on that runtime to fill my buffer, but actual runtime still looks to be 8 hours. I assume that'll adjust itself accordingly.
- Online, no mention of claimed credit, just actual credit received. Probably just as well - only ever results in complaints.
- I note a couple of my tasks have been 'cancelled by server' which I seem to remember is a feature of the new server software. Good thing.

Apart from various cosmetic and information updates (including Certificates for users and teams) things seems to have gone quite smoothly after a cursory look round. Well done everyone.

Edit: Is there some way I can get my sig images to appear side by side instead of one after the other? Trying not to waste screen real estate.

---

I beg your, rjs5, pardon if i have misspoken (i'm italian).
I think that the list in my first post is not in the correct order (i've insert it casually). In order of importance (IMHO):
1) Update compilers, tools, design software, etc, to have a better way to develop code (and, eventually, optimize it). Good code, good science.
2) Update the Boinc server code, to have a better web interface for volunteers (and better scheduler, validator and so on).
3) Update the server, for better security, bugfix, etc.

Done.
Now, the number one :-P

You are doing fine. Your English is far better than my Italian. I think your list is also fine. Your list combines multiple topics ... reliability, performance, ease of use ... It is hard to assign priority across them.

IMO, #2 would also include the demonstrated capability for Rosetta to steer applications to particular CPU families. An SSE2 version to old CPU and an AVX2 version to new CPU. That capability is important if Rosetta plans on taking advantage of any CPU features other than SSE2 parallelism. There is not much headroom if they have to optimize for SSE2 machines. If they cannot support multiple CPU groups per OS, then they are limited to the lowest common denominator.

The upgrade was handled about the way I expected it to be.

IMO, #2 would also include the demonstrated capability for Rosetta to steer applications to particular CPU families. An SSE2 version to old CPU and an AVX2 version to new CPU. That capability is important if Rosetta plans on taking advantage of any CPU features other than SSE2 parallelism. There is not much headroom if they have to optimize for SSE2 machines. If they cannot support multiple CPU groups per OS, then they are limited to the lowest common denominator.

That is a political consideration as much as a technical one. I always would prioritize for the overall good (greatest output) of the project. That is especially obvious in the case of GPU projects, where the old cards can't support the latest CUDA versions, for example, but it applies to CPUs as well.

That is, just go to the AVX2 version when that provides a greater output than staying with the older version. The administrators will get a lot of complaints. The beauty of computers is that you don't have to listen to them.

---

That is, just go to the AVX2 version when that provides a greater output than staying with the older version. The administrators will get a lot of complaints. The beauty of computers is that you don't have to listen to them.

One step at a time. Some ideas....
- Stabilize the server and take confidence with new scheduler, utilities, etc
- Update the code to the latest rosetta. Rosetta 3.8 seems to have some interesting new features
- Start with "little" optimizations, like Sse2/3

---

OK, I'm in. But remember you have the big hatchet if you need it.

---

- Task runtimes are showing as just 4hrs and some minutes for some reason - no idea why that's changed when I have an 8hr default. Lots of tasks coming down based on that runtime to fill my buffer, but actual runtime still looks to be 8 hours. I assume that'll adjust itself accordingly.

This is not resolving itself.

Last year there was an adjustment made that resulted in estimated runtime showing as half the actual runtime. I can't recall it specifically. Whatever it was, it seems to have slipped in again. That needs to be corrected.

---

OK, I'm in. But remember you have the big hatchet if you need it.

?? I don't understand.

---

- Update the code to the latest rosetta. Rosetta 3.8 seems to have some interesting new features

A recent news:

New weekly release (06 Jun, 2017)

Rosetta 2017.18 has been released

I hope for an update of the r@h code. (3.17 version of r@h was released 31 Mar 2016)

---

We've been waiting for a while for a researcher to fix his protocol for the graphics app. Just waiting on him for the update.

We've been waiting for a while for a researcher to fix his protocol for the graphics app. Just waiting on him for the update.

Great!! I'm ready on Ralph!

---

We've been waiting for a while for a researcher to fix his protocol for the graphics app. Just waiting on him for the update.

It's a long.....while
:-P

---

I've been out for the past 2 weeks on a vacation without any network access for the last 5 days last week. The researcher has also been out of the lab from conferences and workshops and will be back in communication soon.

I've been out for the past 2 weeks on a vacation without any network access for the last 5 days last week. The researcher has also been out of the lab from conferences and workshops and will be back in communication soon.

I'm just kidding!
Take your time to test the app!!

---

Rosetta 2017.18 has been released

Now the new version is 2017.26 and this give me a trouble about the "manage a trois" between Rosetta@Home, RosettaCommons and Foldit.
Which is the "master"?? I think is RosettaCommons, second is R@H and, at last, Foldit. But, for example, Foldit is updated continuously than R@H.
Are these Foldit updates, at the end, integrated into RosettaCommons code or Foldit is just "passive" in code revision?

---

Foldit has it's own code repository. The Rosetta core components are not updated as frequently as UI/game related features because I think it is a large task to merge the code.

The Rosetta Commons repository maintains the main source/scientific code. It is constantly being developed by the commons developers/scientists who are from institutions from all over the world (and the contributor base is growing).

When we update the R@h app, we use the latest commons code. I'm still waiting for our graphics app to be debugged but an update should hopefully come soon. A lot has changed including increased use of C++11 from the commons developers, some of which is not yet supported by Visual C++ and has to be ported, also new dependencies, and a migration away from Boost (related to increased C++11 use). Also, the "rosetta scripts" protocols will not be backwards compatible due to new XML format rules so the next app version will be a new app named "rosetta" which is appropriate :)