LHCathome-dev (ex- vLHCathome-dev) (ex-CMS-dev)

[fzs600]

 

LHCb Application :
http://boincai05.cern.ch/CMS-dev/forum_thread.php?id=141&postid=2183#2183

[[AF>Libristes>Jip] Elgrande71]

Merci fzs600 

[fzs600]

 

Change of project name :
http://boincai05.cern.ch/CMS-dev/forum_thread.php?id=150&postid=2269#2269

As mentioned earlier (under "Project Restructuring"), CMS-dev has evolved into a more general dev project for virtual machine applications running under LHC@home.

We will therefore rename the "CMS-dev" project to "vLHCathome-dev" as it is now a development project for early testing of applications that potentially could run in production under the Virtual LHC@home platform.

The change is planned for tomorrow 13 UTC, and you should later see this project as:
http://lhcathomedev.cern.ch/vLHCathome-dev/

Redirection will be put in place, so in principle BOINC clients should be able to follow. Otherwise please detach the project and re-attach to the new URL at your convenience.

Thanks to your contributions and feedback on tests of our applications, CMS-dev has been a success, and we would like to express our warm thanks for your contributions! :-)

Please note that this remains a development and test project, that might provide unstable applications and that any BOINC credit accumulated here might get lost.

If you prefer to just crunch and get credit, please give priority to our production LHC@home projects.

Many thanks for your collaboration!

... the team

[fzs600]

 

13 Mar 2016, 5:52:06 UTC    14 Mar 2016, 6:04:10 UTC    Error while computing    604.77    2.38    ---    LHCb Simulation v0.03 (vbox64)
12 Mar 2016, 14:40:12 UTC    13 Mar 2016, 5:30:51 UTC    Error while computing    607.28    6.32    ---    LHCb Simulation v0.03 (vbox64)

[MDodier]

Merci pour l'information, je me suis détaché et rattaché!

[[AF] fansyl]

Hello,

je vous rejoins sur ce projet !
j'ai reçu mon code d'invitation et commencé à cruncher quelques UTs.

[JeromeC]

Moi j'avais fait ça :

Code Sélectionner Étendre

<app_config>
  <project_max_concurrent>1</project_max_concurrent>
  <app>
    <name>ATLAS</name>
    <max_concurrent>1</max_concurrent>
  </app>
  <app>
    <name>ALICE</name>
    <max_concurrent>1</max_concurrent>
  </app>
  <app>
    <name>CMS</name>
    <max_concurrent>1</max_concurrent>
  </app>
  <app>
    <name>LHCb</name>
    <max_concurrent>1</max_concurrent>
  </app>
  <app>
    <name>Theory</name>
    <max_concurrent>1</max_concurrent>
  </app>
</app_config>

en me basant sur les noms d'appli trouvés ici, mais maintenant il me dit ça :



C'est pas terrible non ???

[JeromeC]

J'ai toujours ce même problème, si y'en a que ça inspire, à vot' bon coeur !

[JeromeC]

Ça me saoule ce truc, personne personne personne a d'idée ?

Les noms de projet correspondent pourtant systématiquement à ce qu'on voit ici...

[Sébastien]

Pour déterminer si le nom de l'application est correct, BOINC se base sur les applications chargées sur ta machine. Il est probable que ta machine n'a chargé que des UT CMS. Le client ne connaît donc pas les autres applications. Ce n'est qu'un message d'avertissement, il ne devrait pas gêner le fonctionnement du fichier app_config.
Quoiqu'il en soit, si tu souhaites limiter le projet à une UT en cours de calcul, le fichier suivant est suffisant:

Code Sélectionner Étendre

<app_config>
  <project_max_concurrent>1</project_max_concurrent>
</app_config>

[JeromeC]

Ah ok, donc si jamais il récupère une UT d'un des autres sous projets il devrait comprendre alors !

(en fait je voulais limiter à une UT de chaque application du projet, pas tout le projet globalement)

Je verrai ce qu'il se passe le jour où j'ai d'autre UT.

Merci.

[DocPhilou1966]

Perso je me sers de ce ces messages d'erreur pour trouver le nom exact des applis 

[Sébastien]

(en fait je voulais limiter à une UT de chaque application du projet, pas tout le projet globalement)

Dans ce cas, il faut enlever la ligne <project_max_concurrent>

[JeromeC]

@phil : sauf dans mon cas il montre tout le temps le même, à priori parce que c'est le seul qui a déjà dû tourner sur mon ordi comme l'explique seb

@seb : heu mais c'est le seul paramètre que j'ai ! (mon config est visible plus haut) je comprends pas...?

[Sébastien]

Je parle de la deuxième ligne qui contient la balise "project_max_concurrent".

[JeromeC]

Ah mais oui ballot que je suis

Bon je l'ai viré, et tant que j'aurai pas eu des UT des autres sous projets j'aurai toujours ces erreurs, compris.

Merki !

[JeromeC]

http://lhcathomedev.cern.ch/vLHCathome-dev/forum_thread.php?id=299

As mentioned previously, we would like to consolidate the existing production servers (Sixtrack, vLHC and ATLAS) into a single service. We hope that by doing this we can improve the support and reduce the confusion. One benefit for all is that there will be a single forum so both us and our volunteer moderators can be more effective.

The transition will have two phases, commissioning and decommissioning. First a new server will be prepared with a similar configuration as this dev project but based on the Sixtrack DB. This is because they have the most users and 50% of the active users from vLHC and ATLAS are already there, hence it should minimize the impact. Once this new server is ready, it will be opened up for use in parallel with the existing three servers.

Next comes the decommissioning. For Sixtrack this should be straight forward, the URLs for the old host will be redirected to the new host. For vLHC and ATLAS things will be a little more complicated. Those users who are already registered with Sixtrack will be encouraged to move to the new server. For those who are not registered they can either register themselves and move or we can do a bulk registration. Tasks can then be stopped and the URLs redirected.

Finally there is the issue of credit. It should be possible to migrate the credit from the old servers to the new server. This can only really be done once the servers are no longer used. There is no time critical aspect, just until this is done, only the new credit will be seen.

Comments and feedback on this proposal are welcome.

P.S The dev project will stay around as it is.

Comme mentionné précédemment, nous souhaitons consolider les serveurs de production existants (Sixtrack, vLHC et ATLAS) en un seul service. Nous espérons qu'en faisant cela, nous pourrons améliorer le support et réduire la confusion. L'un des avantages pour tout le monde est qu'il y aura un seul forum afin que les modérateurs et les bénévoles puissent être plus efficaces.

La transition se fera en deux phases, la mise en service et le décommissionnement [ça se dit "déclassement" pour ça ?]. Tout d'abord un nouveau serveur sera préparé avec une configuration similaire à celle du projet de dev, mais basée sur la base de donnée de Sixtrack. En effet ce sont eux qui ont le plus d'utilisateurs et 50% des utilisateurs actifs de vLHC et ATLAS y sont déjà présents, cela devrait donc minimiser l'impact. Une fois ce nouveau serveur prêt, il sera ouvert pour une utilisation en parallèle avec les trois serveurs existants.

Vient ensuite le décommissionnement. Pour Sixtrack cela devrait être simple, les URL de l'ancien hôte seront redirigées vers le nouvel hôte. Pour vLHC et ATLAS les choses seront un peu plus compliquées. Les utilisateurs qui sont déjà inscrits sur Sixtrack seront encouragés à se déplacer vers le nouveau serveur. Pour ceux qui ne sont pas inscrits, ils peuvent soit s'enregistrer et se déplacer ou nous pouvons faire un enregistrement en masse. Les tâches pourront ensuite être arrêtées et les URL redirigées.

[je comprends pas bien le concept de "se déplacer"...]

Enfin, il y a la question des crédits. Il devrait être possible de migrer les crédits des anciens serveurs vers le nouveau serveur. Cela ne pourra vraiment être fait qu'une fois que les serveurs ne seront plus utilisés. Il n'y a rien de critique rapport au temps, seulement une fois que cela sera fait les nouveaux crédits seront visibles.

Les commentaires sur cette proposition sont les bienvenus.

P.S Le projet dev restera dans les parages comme il est aujourd'hui.

[ça non plus c'est pas bien clair...]

[toTOW]

M'en fout, je fais que du Sixtrack

[Antares]

M'en fout, je fais que du Sixtrack

[JeromeC]

On écrit "m'en fous"

Et donc si j'ai bien compris 6-track-dev sera dans le lot, tu feras gaffe de pas choper de la VM accidentellement

[[AF>Libristes>Jip] Elgrande71]

A la place de "déplacer", Jerome, j'aurais mis "migrer" .
Merci pour la traduction 

[nabz]

De mémoire, on a déjà eu le cas d'un projet qui a fusionné plusieurs sous-projets. Il suffisait d'aller sur ses comptes de sous-projets cliquer sur un bouton pour migrer vers le nouveau projet.

C'était simple et efficace, ils pourraient faire pareil au LHC.

[toTOW]

Et donc si j'ai bien compris 6-track-dev sera dans le lot, tu feras gaffe de pas choper de la VM accidentellement

Ca risque pas, le nécessaire est pas installé !

[JeromeC]

Tu sous-estimes la nuisance sournoise des laquais de la machine virtuelles installés à Berkeley, à tous les coups y'a un installateur furtif de VirtualBox caché dans une mise à jour de wordpad avec un rootkit pour planquer les VM boinc

[Ceclo]

Tu sous-estimes la nuisance sournoise des laquais de la machine virtuelles installés à Berkeley, à tous les coups y'a un installateur furtif de VirtualBox caché dans une mise à jour de wordpad avec un rootkit pour planquer les VM boinc