I too am having problems, and I did everything I was supposed to with the app_info.xml file.

The good news is I downloaded the linux cpu version and ran 20 old cases. It agreed on all of them and was substantially faster. So this is very promising.

Awesome. Now, how to get this working within the boinc ecosystem?

I tried replacing "GetDecics" with "testDecics" and it didn't work.

Here is the app_info.xml wiht testDecics and also checking the Decics Field Testing in my project preference.

<app_info>
  <app>
    <name>testDecics</name>
    <user_friendly_name>Get Decic Fields</user_friendly_name>
  </app>

  <file_info>
    <name>GetDecics_passiflora_0.1.0_windows_x86_64.exe</name>
    <executable/>
  </file_info>

  <file_info>
    <name>GetDecics_passiflora_gpu_0.1.0_windows_x86_64.exe</name>
    <executable/>
  </file_info>

  <app_version>
    <app_name>testDecics</app_name>
    <version_num>400</version_num>
    <platform>windows_x86_64</platform>
    <avg_ncpus>1</avg_ncpus>
    <file_ref>
      <file_name>GetDecics_passiflora_0.1.0_windows_x86_64.exe</file_name>
      <main_program/>
    </file_ref>
  </app_version>

  <app_version>
    <app_name>testDecics</app_name>
    <version_num>402</version_num>
    <platform>windows_x86_64</platform>
    <plan_class>opencl_nvidia</plan_class>
    <avg_ncpus>1</avg_ncpus>
    <max_ncpus>1</max_ncpus>
    <coproc>
      <type>NVIDIA</type>
      <count>1</count>
    </coproc>
    <file_ref>
      <file_name>GetDecics_passiflora_gpu_0.1.0_windows_x86_64.exe</file_name>
      <main_program/>
    </file_ref>
  </app_version>

  <app_version>
    <app_name>testDecics</app_name>
    <version_num>402</version_num>
    <platform>windows_x86_64</platform>
    <plan_class>opencl_amd</plan_class>
    <avg_ncpus>1</avg_ncpus>
    <max_ncpus>1</max_ncpus>
    <coproc>
      <type>ATI</type>
      <count>1</count>
    </coproc>
    <file_ref>
      <file_name>GetDecics_passiflora_gpu_0.1.0_windows_x86_64.exe</file_name>
      <main_program/>
    </file_ref>
  </app_version>

  <app_version>
    <app_name>testDecics</app_name>
    <version_num>402</version_num>
    <platform>windows_x86_64</platform>
    <plan_class>opencl_intel_gpu</plan_class>
    <avg_ncpus>1</avg_ncpus>
    <max_ncpus>1</max_ncpus>
    <coproc>
      <type>intel_gpu</type>
      <count>1</count>
    </coproc>
    <file_ref>
      <file_name>GetDecics_passiflora_gpu_0.1.0_windows_x86_64.exe</file_name>
      <main_program/>
    </file_ref>
  </app_version>
</app_info>

Here is the boinc event log error message with the same error message as with GetDecics app name that I previously tested, i.e. "Message from server: This project doesn't support computers of type anonymous"

10/9/2026 5:12:08 PM | NumberFields@home | update requested by user
10/9/2026 5:12:11 PM | NumberFields@home | Sending scheduler request: Requested by user.
10/9/2026 5:12:11 PM | NumberFields@home | Requesting new tasks for CPU and NVIDIA GPU
10/9/2026 5:12:12 PM | NumberFields@home | Scheduler request completed: got 0 new tasks
10/9/2026 5:12:12 PM | NumberFields@home | Message from server: This project doesn't support computers of type anonymous
10/9/2026 5:12:12 PM | NumberFields@home | Project requested delay of 86400 seconds

I would strongly advise against enabling Anonymous Platform at the present time.

Anonymous platform allows anyone to use any executable to download Tasks and return work to a project- and without it being Validated against a known good application (ie the projects default/stock applications) a system can return nothing but rubbish, but still have the work Validated and get credit.
All the while, corrupting the science.

If Anonymous platform is going to be enabled, then validation needs to be done with at least 2 returned Tasks, one of which being done by a stock application.

I looked into the anonymous platform, and apparently it is automatically enabled. But it wont work if apps are already deployed for the OS/platform being tested. It looks like I need to create a special test application but not deploy any executables. The user then handles the anonymous platform on the client side via the app_info.xml.

As has been mentioned, Anonymous platform allows people to use their own executable to process work instead of the one provided by the project.

But as to how to allow the project to accept the work from a host running the anonymous platform, my searches so far have come up with zilch.

I created the new app "testDecics". It has no platforms defined, so should work with the anonymous platform. I also generated 100 WUs for it.

For it to work, and people to be able to download the generated Tasks, they must be defined by platform. just like the regular applications. As well as their own Validators and Assimilators.

Beta-test applications
You can designate application as "beta", and only beta-test users will be sent jobs for these apps. To do this:

Create a new application using xadd. or the administrative web interface. Mark the app as "beta", e.g. by including <beta>1</beta> in the <app> element.
Add a validator and assimilator for the test application.
Create application versions for the test application.
Create jobs (as needed for testing) for the test application. To prevent test jobs from dominating regular work, either use the --allapps feeder option (and give the test app a small weight) or make a work generator for the test app that maintains only a small number of unsent results.
Note: for beta applications, the scheduler ignores which apps a user has allowed to run in their project specific preferences (the <app_id> element in the XML). If a project has several beta applications, a user can only either run all or none.

Beta-test app versions
You may want to verify that new app versions compute the same results as old ones, i.e. that your validator accepts combinations of old and new.

You can do this by designating app versions as "beta". These app versions will be sent only to beta-test users. For results processed using beta app versions, usually the other replicas will be processed using non-beta app versions; you can examine these workunits and check whether they validated.

When you create a new app version you can mark it as beta by including <beta/> in its version.xml file. You can toggle the beta flag for existing app versions using the administrative web interface.

https://github.com/BOINC/boinc/wiki/BetaTest





Or as you appear to have done, release them as part of the general work output, with the option for people to select them.
Even so, they still need to be defined by platform- otherwise the Scheduler doesn't know how to allocate them to hosts- ie what can they be run on; Winodws, Lunix, Android, GPU, cPU???

https://github.com/BOINC/boinc/wiki/User-app-selection

---

Grant
Darwin NT, Australia.

As many have pointed out, the anonymous platform mechanism is not safe. Also, increasing the min quorum to 2 or more would require a new validator, so that is not optimal.

Since the goal here is to test the new app version, I am leaning towards deploying Alperen's new binaries using the new test app that I created earlier. I can dump 1000 or more tasks from an older data set whose results can be used as truth.

But I will wait for feedback before I go down this path.

I can dump 1000 or more tasks from an older data set whose results can be used as truth.
But I will wait for feedback before I go down this path.

A 1000 tasks will probably finish in a few hours across a handful of volunteers or perhaps just one volunteer. Alperen's apps is running about 20x faster on CPU and about 10x on GPU based on the estimate on sf3_DS-16x270 task I used as reference since it has the longest run time. Possible to put a limit on the tasks downloaded and tighten the task deadline to expire in 24 hours? At least give others with different hardware and OSes a chance to try out and prevent a few volunteers from downloading too many tasks at once. My one cent.

I tested one sf6_DS-16x10 using boinc manager and the same exact task outside of boinc ecosystem for the custom app on my 3950x with fixed clock at 3.5GHz concurrently. No other background task. The custom app finishes very quickly. Here is the speed improvement seen on my testing: 7913secs(stock)/403secs(custom) = 19.6x faster.

As many have pointed out, the anonymous platform mechanism is not safe. Also, increasing the min quorum to 2 or more would require a new validator, so that is not optimal.

Since the goal here is to test the new app version, I am leaning towards deploying Alperen's new binaries using the new test app that I created earlier. I can dump 1000 or more tasks from an older data set whose results can be used as truth.

But I will wait for feedback before I go down this path.

It would be the best option IMHO- the least amount of work required on your part, but will still result in a valid check of the new application's accuracy without having any impact on the science database.


You'll need to determine how to differentiate the results provided by the current stock applications and the new application being used to process the test Tasks, as they will be handled by the present Validator and Assimilators, but you don't want them to be assimilated into the science database (1 we still don't know how accurate they are and 2 you've already got those results there anyway).


So all returned Tasks processed by the Test application that pass initial Validation will get credit, but won't be assimilated into the Science database; they'll get shunted off to where you can then compare them to the results produced by the stock application.

I guess the number to be released will be determined by how much time and effort it will take to do that cross checking- the larger the number (and the spread as some of the present CPU Tasks can take from 1.5hrs to just under 6hrs to complete) the better. But there's no point doing 100,000 if it's going to take you months to check them all out.
You want the largest possible number over the largest possible range, that you can deal with.



And if it all checks out and you do release the new version as the stock version, i'd suggest changing the Time out after Scheduler contact back to 30sec or so, so high-end GPUs don't end up sitting idle waiting for enough work to keep them busy.
And if there are any limits on the number of Tasks per compute device per machine they may need to be revised also- people really don't need to keep more than a couple of day's worth of work these days IMHO. But if the new application works as well as initial results are indicating, any present hard limits will likely need to be raised so they can have even just 24hrs of work cached.

---

Grant
Darwin NT, Australia.

Oh, and getting back to the original post in this thread- if these new applications work out and become the Project's default stock applications then there'd be no need for being able to run multiple instances.
A well optimised application will take a CPU/GPU to it's limits while running just the one Task per core/GPU.

---

Grant
Darwin NT, Australia.

As many have pointed out, the anonymous platform mechanism is not safe. Also, increasing the min quorum to 2 or more would require a new validator, so that is not optimal.

Since the goal here is to test the new app version, I am leaning towards deploying Alperen's new binaries using the new test app that I created earlier. I can dump 1000 or more tasks from an older data set whose results can be used as truth.

But I will wait for feedback before I go down this path.

It would be the best option IMHO- the least amount of work required on your part, but will still result in a valid check of the new application's accuracy without having any impact on the science database.


You'll need to determine how to differentiate the results provided by the current stock applications and the new application being used to process the test Tasks, as they will be handled by the present Validator and Assimilators, but you don't want them to be assimilated into the science database (1 we still don't know how accurate they are and 2 you've already got those results there anyway).


So all returned Tasks processed by the Test application that pass initial Validation will get credit, but won't be assimilated into the Science database; they'll get shunted off to where you can then compare them to the results produced by the stock application.

I guess the number to be released will be determined by how much time and effort it will take to do that cross checking- the larger the number (and the spread as some of the present CPU Tasks can take from 1.5hrs to just under 6hrs to complete) the better. But there's no point doing 100,000 if it's going to take you months to check them all out.
You want the largest possible number over the largest possible range, that you can deal with.



And if it all checks out and you do release the new version as the stock version, i'd suggest changing the Time out after Scheduler contact back to 30sec or so, so high-end GPUs don't end up sitting idle waiting for enough work to keep them busy.
And if there are any limits on the number of Tasks per compute device per machine they may need to be revised also- people really don't need to keep more than a couple of day's worth of work these days IMHO. But if the new application works as well as initial results are indicating, any present hard limits will likely need to be raised so they can have even just 24hrs of work cached.

Another validation option: one task provided by stock app, two another tasks crunched by new app.

Дорогая Shmya-2.
У Герасима "кворум", - это свойство ВУшки. И обрабатывается они
точно так-же как и остальные ВУ.. Фокус начинается когда мы получем
число посчитанных результатов(Results) для ВУ равное кворуму. :)
p.s.
В общем, я готов рассказать Вам о кворуме (code: Cs, SQL) в обмен на информацию
from [scheduler request] ... to stored proc GetTask(..)

I deployed 4 of the test apps earlier - windows and linux, cpu and gpu.

I got some, but my cache is 0,5day. would take a while to crunch.
BTW it would be better if You release new app that is default off in settings.

I deployed 4 of the test apps earlier - windows and linux, cpu and gpu.

I've set my systems to take them if available. But with so few available, timing is everything.
None so far, maybe i'll get lucky with a resend or two.

---

Grant
Darwin NT, Australia.

2 first done:
https://numberfields.asu.edu/NumberFields/show_host_detail.php?hostid=2914780