- 
                Notifications
    
You must be signed in to change notification settings  - Fork 2
 
Description
Right now, "nested parameters" have two uses.
First, they allow different parameters to vary together, so that the number of varying parameters is smaller then the dimensionality of the grid. For example:
grid_parameters:
  scenario: [bad, good]
nested_parameters:
  - scenario: bad
    R0: 2.0
    gamma: 0.5
  - scenario: good
    R0: 0.5
    gamma: 1.0We want scenario parameter could be seen as a kludge to make this work or a shorthand to refer to the scenarios.
Second, they allow for "promotion" of parameters in the griddle namespace. For example, the example above could have been implemented as:
grid_parameters:
  scenario:
    - name: bad
      R0: 2.0
      gamma: 0.5
    - name: good
      R0: 0.5
      gamma: 1.0and then the values accessed as parameter_sets[i]["scenario"]["R0"] (rather than as simply parameter_sets[i]["R0"] in the example above).
Third, they allow for matching (or "subgridding" or "nesting"). For example:
grid_parameters:
  method: [newton, brent]
nested_parameters:
  - method: newton
    starting_value: 0.5
  - method: brent
    lower_bound: 0.0
    upper_bound: 1.0None of these allows for a true subgrid, where I explore a grid of values within another grid parameter. For example, I can't explore a range of starting values when using Newton's method.
This last note may relate to #53 because the idea of grids within grids  is more compatible with tags rather than a top-level designation of which parameters are "fixed" versus "grid." One could, say, put method, starting_value, and lower_bound on the top-level grid, and then have some way to filter out certain values when needed, but this is kludgey.