Development for LHC@home

As discussed in this thread, I have created a container-based version of the Theory app using runc and CVMFS. For now this is Linux only and requires CVMFS to be installed as a prerequisite similar to the ATLAS native application. As one of the main differences is that the real jobs are pushed through the BOINC server, we can not provide both the old style VM jobs and new container jobs for the same application. In order to test we would need to do one of the following:

1. Use the current Theory app (Linux Only for now)
   
2. Create a new app (TheoryNative)
   

Which direction would you prefer and why?

75% of the hosts are running Windows. Why are all their users ignored?

Couldn't you create a VM with your wished container configuration and other prerequisites, so that it can be used by all operating systems?

Hi Laurence


Some questions:

Do you refer to this thread?


Would (2.) also satisfy Windows users?
If YES, then this should be preferred, but maybe I misunderstand something.


My local CVMFS is currently configured to serve ATLAS repositories.
What changes would be necessary to also run Theory?

75% of the hosts are running Windows. Why are all their users ignored?

Couldn't you create a VM with your wished container configuration and other prerequisites, so that it can be used by all operating systems?

They are not being ignored. Making the container work natively is the first step. The second is making that work in a VM. In the short term while testing, Windows hosts can be used by running the BOINC client in a Linux VM.

Hi Laurence


Some questions:

Do you refer to this thread?

Thanks, the last '2' was missed from the copy and paste.

Would (2.) also satisfy Windows users?
If YES, then this should be preferred, but maybe I misunderstand something.

No, we would have to address Windows users later.

My local CVMFS is currently configured to serve ATLAS repositories.
What changes would be necessary to also run Theory?

You would have to ensure that CVMFS_REPOSITORIES in default.local contains grid.cern.ch and sft.cern.ch

To be honest, I don't understand what's different between (1.) and (2.) if both run on linux.
Could you give some hints?

In the short term while testing, Windows hosts can be used by running the BOINC client in a Linux VM.

I would like to do that, but I did not manage to get ATLAS native running in my Linux Mint VM running on my Win7 host.

Use the current Theory app (Linux Only for now)
Create a new app (TheoryNative)
Which direction would you prefer and why?

Hi Laurence,
in Atlas, the test-function must be activated to get native.
Problem is, the native-App is not seeing in the Boinc-Server-stats.

Otherwhise the same Linux-App as before would running with this stats. No change of the prefs is needed.
Is this native-App reduced for SL69 and CentOS7 normally?
All Hypervisor-also Hyper-V?

To be honest, I don't understand what's different between (1.) and (2.) if both run on linux.
Could you give some hints?

The main difference is with inputs/outputs, job length and credit. With (1) the job is the VM, no input/no output and jobs run for ~13 hours. With (2) there is an input and output file and the jobs run for ~90 mins.

Hi Laurence,
in Atlas, the test-function must be activated to get native.
Problem is, the native-App is not seeing in the Boinc-Server-stats.

Otherwhise the same Linux-App as before would running with this stats. No change of the prefs is needed.
Is this native-App reduced for SL69 and CentOS7 normally?
All Hypervisor-also Hyper-V?

The ATLAS VM and Native apps are the same. They both use the same input file and produce the same outputs.

I will drain the queue of VM tasks before creating the native ones.

To be honest, I don't understand what's different between (1.) and (2.) if both run on linux.
Could you give some hints?

The main difference is with inputs/outputs, job length and credit. With (1) the job is the VM, no input/no output and jobs run for ~13 hours. With (2) there is an input and output file and the jobs run for ~90 mins.

90 min seems to be a good runtime lenght.
It could also be good to monitor each job individually to identify app failures (see sherpa).

Thus I would prefer (2.).


The disadvantage is that the BOINC server would have more work but lots of short SixTracks show that this may not be a problem.

I have reconfigured the Theory app to use the native Linux version and the first task was successful.

To visit the link a CERN account is required.

I have changed the link. Please try again.