I'm personally of the opinion that subprojects should only be used when the characteristics of the work are very similar. Sadly, that not the way they are being used. Look at the number of projects that have a subproject with native tasks and another with vbox tasks.

This is a problem because the current mechanisms for controlling which subprojects a computer runs are painfully limited. Most project web sites allow selecting subprojects, but only using the Home/Work/School/Other categories. First, 4 catagories is two few for people with multiple computers. Second, the Gridcoin people have no access to this mechanism.

I like to request an extension to the project config file to allow control of subprojects. Something like
<app>
<name>camb</name>
<no_download>1</no_download>
</app>

Putting the entry in <app_version> might allow even finer control.

This should do exactly the same thing as the project web site setting: Existing tasks will run, but no new tasks will be downloaded. This should be easy to implement.

Thanks

---

Over the years, I have seen this issue raised on the CPDN boards a few times though there the number of different task types has (in my opinion) never been high enough to need more than the home, school work and other web options. At the moment, there can be several sub-projects all of the same genre making it impossible to differentiate between them.

This means, there is no way to selectively choose between batches of work of the same task type which vary in length on my slow machine between about 10 days in length to almost 200 days for the longer tasks! As it is I micro manage by aborting the longer tasks to allow them to be re-issued on a faster machine. Even if there were a way to differentiate between the different areas covered by the different batches, for the same area, they can run from anything between 1 month model time and over 200 months model time so on CPDN a way of differentiating by task length would be nice but I know it isn't going to happen!

I hadn't though of that aspect. But I did say that using <app_version> instead of <app> would allow for finer control. So, consider:

<app_version>
<app_name>camb_boinc2docker</app_name>
<plan_class>vbox64_mt</plan_class>
<no_download>1</no_download>
</app_version>


Here the <no_download> is conditioned on both full app name and plan class. The project could define plans based on runtime, for example
run1 = 1 to 10 hours on a standard machine
run2 = 10 to 100
run3 = 100 to 300

and so on, as appropriate.


Maybe to make this work right we need to have <no_download> at both the <app> and <app_version> level with <app_version> overriding. Then you can use <no_download> at the <app> level to block everything, and use it at the <app_version> level to allow the plans you want.

---

I would assume something like this would require server logic to be updated as well to accept this from the client.

In Dave's case, at CPDN the app and plan class are the same. Some tasks just have larger data sets.

Yeah, it probably would require server changes. Right now, the client can decline to request jobs, but the only granularity is CPU v GPU. If the client requests CPU jobs, it gets what it gets. The request would have to be change to "give me CPU tasks for these subprojects". Still, I see other uses for that capability.

S

---

I would love this kind of local control.

There are many examples over the years (the Cosmology/LHC projects) but one from yesterday is Rosetta@home.

I want to get in at least 5000 hours on WUProps per WU and already achieved that with Rosetta-mini (which are frequent) but not with the full Rosetta WU.

Rosetta doesn't differentiate between the two and has no preferences choice for each WU type.

I would like to see BOINC add an advanced tab with a list of the computer cores with selections to assign affinities of each project to the cores.

This technique could be used to accomplish these goals (and streamline workload management) as, for example, we assign cores 0-3 to 1 project and deny the other projects access while giving cores 3-7 access to all participating projects.