Development for LHC@home

It looks like all scientific apps running under the roof of Theory Simulation are designed to run as singlecore app or at most as a chain of different singlecore apps. Even Theory (vbox) is not really a multicore app as it just provides a couple of slots each of them is running independent scientific chains.

Thus I wonder why Theory native has been started as multicore.
The tests show that multicore configurations always (ATM) run the standard singlecore scientific chain.


If we could vote, I would vote to continue Theory native as a singlecore app for the following reasons:
- easier app development
- easier helper apps, e.g. BOINC validator
- easier error handling - Which "slot" caused an error? How to calculate the credits?
- less idle cores - a single longrunner (e.g. sherpa) in an n-core setup can cause (n-1) idle cores


Other comments are welcome.

Other comments are welcome.

Replied to a post of captainjack: https://lhcathomedev.cern.ch/lhcathome-dev/forum_thread.php?id=446&postid=5872#5872

I agree the best option is single core, but I think the user should be able to run a single core task using 2 threads.
Because one job has several processes, that speeds up a single job, but one can do lesser jobs.

It looks like all scientific apps running under the roof of Theory Simulation are designed to run as singlecore app or at most as a chain of different singlecore apps. Even Theory (vbox) is not really a multicore app as it just provides a couple of slots each of them is running independent scientific chains.

Thus I wonder why Theory native has been started as multicore.
The tests show that multicore configurations always (ATM) run the standard singlecore scientific chain.


If we could vote, I would vote to continue Theory native as a singlecore app for the following reasons:
- easier app development
- easier helper apps, e.g. BOINC validator
- easier error handling - Which "slot" caused an error? How to calculate the credits?
- less idle cores - a single longrunner (e.g. sherpa) in an n-core setup can cause (n-1) idle cores


Other comments are welcome.

The multicore planclass was used as it already exists for ATLAS. We can create another one for singlecore.

Other comments are welcome.

Replied to a post of captainjack: https://lhcathomedev.cern.ch/lhcathome-dev/forum_thread.php?id=446&postid=5872#5872

I agree the best option is single core, but I think the user should be able to run a single core task using 2 threads.
Because one job has several processes, that speeds up a single job, but one can do lesser jobs.

I don't mind the singles but do prefer running X2 WU's on all my 8-cores since they have the ram needed.

I don't mind the singles but do prefer running X2 WU's on all my 8-cores since they have the ram needed.

If your host has enough RAM to run vbox tasks then it is not an issue for native tasks.

Other comments are welcome.

Replied to a post of captainjack: https://lhcathomedev.cern.ch/lhcathome-dev/forum_thread.php?id=446&postid=5872#5872

I agree the best option is single core, but I think the user should be able to run a single core task using 2 threads.
Because one job has several processes, that speeds up a single job, but one can do lesser jobs.

I have created the following plan class for this app:

  <plan_class>
    <name>native_theory</name>
    <min_ncpus>1</min_ncpus>
    <max_threads>2</max_threads>
    <mem_usage_base_mb>1000</mem_usage_base_mb>
    <projected_flops_scale/>
    <nthreads_cmdline/>
  </plan_class>

I don't mind the singles but do prefer running X2 WU's on all my 8-cores since they have the ram needed.

If your host has enough RAM to run vbox tasks then it is not an issue for native tasks.

Yes of course I know that.
It means I don't care which way we run the tasks native or not.

I have created the following plan class for this app:

  <plan_class>
    <name>native_theory</name>
    <min_ncpus>1</min_ncpus>
    <max_threads>2</max_threads>
    <mem_usage_base_mb>1000</mem_usage_base_mb>
    <projected_flops_scale/>
    <nthreads_cmdline/>
  </plan_class>

Now v4.08 and v4.09 are listed at the app page.
I got a task for v4.08.

Now v4.08 and v4.09 are listed at the app page.
I got a task for v4.08.

Thanks, have now deprecated all the old versions.