Development for LHC@home

As discused in a recent thread, There will potentially be 6 LHC related applications (Six Track, Test4Theory, ALICE, ATLAS, CMS and LHCb) and hence between 1 and 12 projects depending on how things are organised. The options are:
1. One project with beta apps
2. Two projects; prod and dev
3, One project and six dev projects
4. Six prod projects and six dev projects

What would you prefer?

http://doodle.com/poll/esktqvrikqmpmyp2

Back in March last year you wrote...

Our vision is that in the near future when the application and back-end infrastructure is mature, we can include it in the vLHC project as another application. When this happens it will not be possible to transfer the credit so please add your resources there now if that would annoy you.

and...

..., what is happening is that CERN would like to consolidate technical support and user interaction for related BOINC projects as much as possible under one roof. It's not cast in concrete and we will see how such a combined platform works out over the next few months.

I voted for option 4 (6 prod/6 dev) simply because I would like to see the individual projects remain separate entities and effort for the individual project be identifiable. Currently if you run a CMS beta task at vLHC the credit gets added to your vLHC credit total and there is nothing to show what was done for each project. Will the other existing CERN projects just get their scores added to the vLHC scores when they get assimilated ?

I am ignorant on how much effort to set up and maintain (12) individual projects would be as opposed to the possible complexities of having everything under 1 or 2 overall projects. If each project would be set up in an identical manner and nothing needs changing to be different for a specific project then I don't see why they couldn't all just be sub-projects under one umbrella. However if different projects require their Boinc configuration to be different then wouldn't that mean they should be separate ?

I have no idea on how data volumes (including server communications) for the individual projects would impact on each other if they were combined as sub-projects or whether dependencies on specific Boinc server versions would cause conflicts between the sub-projects when it came to upgrade the Boinc server software. If these things could be a problem that would suggest the projects should be kept apart.

Additionally, if all production projects are combined together (as sub-projects or otherwise) then presumably it means that if the overall project goes down they all go down ?

I'm all for you (project team/management) deciding how you want to proceed, running and maintaining the projects costs money. Yes it costs us money to crunch but we will come and go, to some extent you need to keep 'us' happy and I'm sure 'we' will let you know when 'we' aren't :-)

I voted for option 4 (6 prod/6 dev) simply because I would like to see the individual projects remain separate entities and effort for the individual project be identifiable. Currently if you run a CMS beta task at vLHC the credit gets added to your vLHC credit total and there is nothing to show what was done for each project. Will the other existing CERN projects just get their scores added to the vLHC scores when they get assimilated ?

HM, I understand Option 4 different then you.

I see one BOINC-Project (like vLHC) and there you can run and choose up to 6 different Sub-Projects. You can choose to run all Projects, or only some you marked and you can choose if you are willing to run Beta-Test and there you can again choose from which Projects you like to Beta-Test applications

I prefer this Option 4

HM, may be I was a Little bit to fast. It Looks like the Options 1 - 4 are not enough clear differenced.

I forgot about the big differences your "Sub-Projects" Need. Sixtrack doesn't Need VirtualBox and VT-X, so this shouldn't be in the same Project-Container than Projects that Need VirtualBox and VT-X

For me, it would be best to bring all These into the same Project-Container, that have similar Needs, like VirtualBox, VT-X and Memory-Hunger.

So, if you get a Client working in one Sub-Project it will work for all other of these Sub-Projects.

And the question about Beta-Testing will be: If you are really willing to do Beta-Tests, then it is right in the same Project-Container. But for Alpha-Testing it would be better to have a separate Project-Container

HM, I understand Option 4 different then you.

I see one BOINC-Project (like vLHC) and there you can run and choose up to 6 different Sub-Projects. You can choose to run all Projects, or only some you marked and you can choose if you are willing to run Beta-Test and there you can again choose from which Projects you like to Beta-Test applications

I prefer this Option 4

Lol, I thought that was option 1 !

The main effort in supporting a project is communication and following the message boards, running multiple servers should be quite straight forward. We would in all cases have to support 36 app versions. Managing scale and availability is a separate issue and not really related to the number of projects.

I fully agree. We should not mix the classic and virtualized projects. The options are more there to help us understand direction.

option 2++ with

- sub-projects in prod
- option to test beta WUs in the same project, for those interested
- separate project for alpha testing, for those interested

You can mix VB and no-VB sub-project as long as you clearly explain the requisites, and easy option on the project preference page to allow each user select / unselect its own projects (plus beta yes/no).

All this on a profile basis (home / work / etc) like standard boinc setup, of course.

Primegrid works very well like that, with a long list of sub-project with their own prerequisites (very detailed) and you can check precisely those you want to do.

As discused in a recent thread, There will potentially be 6 LHC related applications (Six Track, Test4Theory, ALICE, ATLAS, CMS and LHCb) and hence between 1 and 12 projects depending on how things are organised. The options are:
1. One project with beta apps
2. Two projects; prod and dev
3, One project and six dev projects
4. Six prod projects and six dev projects

What would you prefer?

http://doodle.com/poll/esktqvrikqmpmyp2

Perhaps you can explain what one project would look like?

SETI has one production project and one dev project. Each supports two distinct application classes but credit is not split into two sub-projects.

Other projects have one production but split into multiple sub-projects.

If you have one production with six sub-projects and one dev with six sub-projects, I think this meets everyone's needs. People who want to set and leave can do so. People who like to adjust based on hours and/or credits can do so.

If you plan to lump all apps together then I'd vote for 6 + 6. If you have sub-projects, then I'd vote for 1 + 1.

Sub-projects with distinctly separate production and development projects is surely the best solution. If you go this route, please be careful with maintaining separations.

Thanks.

S.

option 2++ with

- sub-projects in prod
- option to test beta WUs in the same project, for those interested
- separate project for alpha testing, for those interested

You can mix VB and no-VB sub-project as long as you clearly explain the requisites, and easy option on the project preference page to allow each user select / unselect its own projects (plus beta yes/no).

All this on a profile basis (home / work / etc) like standard boinc setup, of course.

Primegrid works very well like that, with a long list of sub-project with their own prerequisites (very detailed) and you can check precisely those you want to do.

I agree in full with this option. vLHC becomes the "umbrella" for sub-projects T4T, CMS, etc. - credit kept separately by subproject for the stats sites ala PrimeGrid and many others (but as mentioned elsewhere, unlike SETI). PrimeGrid is, as said, THE one to look at for Preferences pages to select your sub-projects. CMS-Dev becomes vLHC-Dev, basically a clone of the 'new' vLHC but with sub-projects that come and go as new applications are developed by CERN. Message board folders in Dev for each separate application.

I personally don't see the need for beta testing in the main project at all, but some like it, so whatever. It does let the main user base "try out" an app early if they so desire, but it isn't a substitute for being "production-ready" before leaving the Dev sandbox.

What are sub-projects? Is it just this or something else?

https://boinc.berkeley.edu/trac/wiki/PerAppCredit

Couldn't really comment on the coding side though that looks like it.

Essentially the project keeps track of the scores for each of the sub-projects it has so there is a breakdown for them as well as an overall total.

Am sure someone who knows will pop in soon :-)

What are sub-projects? Is it just this or something else?

https://boinc.berkeley.edu/trac/wiki/PerAppCredit

That is the server-side view of it, yes. For a user-side view, PrimeGrid has sub-projects (14 I think right now, plus several that are retired), each of which gets a "badge" when enough credits are earned in that sub-project; within each sub-project they have multiple applications (which may not be necessary at vLHC) - for example, their "Genefer" sub-project has several applications numbered GFN-15 through GFN-22, based on one of the parameter values of the prime search. Volunteers can choose to run any/all of the applications, depending on their computer power (GFN-15 is pretty quick, GFN-22 can take many days to run, even on my fastest host!!!). Regardless of _which_ "Genefer" applications they run, the credit goes toward a "GFN" sub-project badge.

I would see T4T as one sub-project and CMS as another. You'd only really have one application for each (AFAIK right now) - version numbers don't matter, so whether it's CMS v0.4 or CMS v1.5, it's still CMS. If some future sub-project XYZ wants to simulate two different things, say magnet configuration and atomic mass of target material, XYZ might have apps "XYZ Magnets" and "XYZ Target" - both would go toward earning the volunteer credit toward their "XYZ" badge color.

Likewise if future sub-project ZZZ has CPU and GPU versions of the application - two different applications but one sub-project, and one badge. Users can choose to run either or both applications.

I’m not positive if you can see this without being logged in as me, but at
<http://stats.free-dc.org/stats.php?page=userbycpid&cpid=c5c24472bf7b8fd0675d4a1a454f0104>

right below the basic stats is a banner of badges. The first one (Collatz) is a single-app project, so only one badge. The next block of 4 (Asteroids) please ignore, they do things in a totally screwy way. Then you see the small square boring (hint!) badges that PrimeGrid awards. I have 11 of them in varying colors. At this instant, their “PSP” sub-project badge is bronze, their “GFN” sub-project badge is ruby, their “PPS Sv” badge is teal. That tells the world that I’ve done a whole bunch of PPS Sieve, quite a bit of GFN, and not so much PSP work. They give no clue as to which GFN applications earned me the credits for that GFN badge, but that’s okay, that’s what WuProp is for. And that’s a totally different conversation. :-) I’m not a “badge chaser” - I’ve seen banners that go completely across the page and have many dozens of badges on them. Badges WILL get people to come run your sub-projects, believe me.

+1 :)