Allow excluding capabilities from filling downstream dependencies.

[ChrisJChang]

This PR adds the ability to use multiple functions for the same capability, where only one is expected to fill the downstream dependencies. One use of this is that you could use different calculators for a physics observable, and save them both for the purpose of understanding systematic uncertainty.

This is done via yaml rules:

- capability: TestDependency
  function: testdependency_2
  purpose: Observable
  exclude_from_dependency_resolution: true

It will still add any functions needed for this to the dependency graph.

If you specify one excluded capability, but not which will capability will actually fill the dependency, it will pick the other if there is only one other possible, and raise the regular dependency resolution error if there are more than one options.

I have added an example to spartan.yaml doing this.

This closes issue #56

This is a very simple PR, so should not take too much effort to review.

[patscott]

This is good, but I don't think it actually addresses #56. How would one use this option to allow a module function to declare the same dependency twice, in order to get it from two sources and compute the difference?

[ChrisJChang]

How would one use this option to allow a module function to declare the same dependency twice, in order to get it from two sources and compute the difference?

So with the changes in this PR, your yaml code would be something like:

- capability: RD_oh2
  function: RD_oh2_DS
  purpose: Observable

- capability: RD_oh2
  function: RD_oh2_micromegas
  purpose: Observable
  exclude_from_dependency_resolution: true

This would run both relic density calculations, but only use the DarkSUSY one to fill downstream dependencies. Both of these would be written to file, and so you could manually compute the difference after the scan has run. It would not be doing this during a scan. We could look at adding functionality to do this online during a scan, but this would not be using our standard dependency resolution mechanics, because it would need to have two dependencies on the same capability.

[patscott]

Right, but that's my point -- by 'doing it manually' #56 means declaring the module function to have two dependencies and manually writing code into the module function to take the difference between the two dependency values computed in the scan. This would still just be a waypoint to a more sophisticated system that allows multiple functions to be run to fulfill ~any dependency, and the range between them automatically taken as a systematic error on the dependent quantity. Possibly with the central value taken as the mean or something like that too.

Allowing a scan to compute two things with the same capability is another, even earlier and simpler step on this path. I agree it's worthwhile doing, but I think a) it doesn't close #56, and b) steps 2 and 3 are the ones that would add the most value.

[ChrisJChang]

by 'doing it manually' #56 means declaring the module function to have two dependencies and manually writing code into the module function to take the difference between the two dependency values computed in the scan.

I added in the ability to have multiple dependencies from the same capability. These are declared with a new macro DEPENDENCY_ON_FUNCTION:

DEPENDENCY_ON_FUNCTION(calc1, TestDependency, double, testdependency_1)
DEPENDENCY_ON_FUNCTION(calc2, TestDependency, double, testdependency_2)

Here TestDependency is the capability it depends on, testdependency_1/_2 are the two functions that are both for TestDependency. calc1/calc2 are tags that you name (only needed in the DEPDENDENCY_ON_FUNCTION macro), so that you can refer to them in the function, e.g.:

double blah1 = *Dep::calc1;
double blah2 = *Dep::calc2;

Then you can do whatever you want this this in your new capability.

Does this fulfill what you were thinking?

[patscott]

It definitely goes in the right direction. The only concern I have with it is that it requires declaring in advance in the header what function is used to fulfill the two dependencies. This should really be done by the dep resolver according to applicable run-time rules.

I think the function-local tag/alias for the dependency is a good design though. Could we perhaps just add alias as an optional arg to DEPENDENCY, so that it overrides how you refer to the dep in the pipes, as in your solution - but then have the dep resolver resolve each of the dependencies, using the tag/alias as an additional part of the conditional? Like this:

DEPENDENCY(TestDependency, double, calc1)
DEPENDENCY(TestDependency, double, calc2)

with matching rules in the YAML something like

- if: 
    tag: calc1
  then:
    function: testdependency1
- if: 
    tag: calc2
  then:
    function: testdependency2

and referred to in the module function as in your example:

double blah1 = *Dep::calc1;
double blah2 = *Dep::calc2;

We'd maybe also want some dep resolver option prefer_different_functions_for_duplicate_dependencies that defaulted to true.