Badger object hierarchy

Object hierarchy

There is a bunch of configuration nodes in Badger that allow to represent as GUI object a parameter. They all inherit from ConfigNodeViewModel (if they can't have children) or NestedConfigNode (if they can). These two classes offer the common functionalities and virtual functions that need be implemented by subclasses.

Most of these classes represent a parameter object in a Simion app. For example, in the source code of an app we might have something like this:

RLSimionApp::RLSimionApp(CConfigNode* pConfigNode)
{
  pLogger= CHILD_OBJECT<CLogger>(pConfigNode, "Log", "The logger class");
  pWorld = CHILD_OBJECT<CWorld>(pConfigNode, "World", "The simulation environment and its parameters");
}
CLogger::CLogger(CConfigNode* pConfigNode)
{
  m_bLogEvaluationEpisodes= BOOL_PARAM(pConfigNode,"Log-eval-episodes", "Log evaluation episodes?",true);
  m_bLogTrainingEpisodes= BOOL_PARAM(pConfigNode,"Log-training-episodes", "Log training episodes?",false);
  m_logFreq= DOUBLE_PARAM(pConfigNode,"Log-Freq","Log frequency. Simulation time in seconds.",0.25);
}
CWorld::CWorld(CConfigNode* pConfigNode)
{
  m_numIntegrationSteps= INT_PARAM(pConfigNode,"Num-Integration-Steps","The number of ...",4);
  m_dt= DOUBLE_PARAM(pConfigNode,"Delta-T","The delta-time between simulation steps", 0.01);
}

and, then, it will show up in Badger as:

Note that the parameter names do not necessarily match the name of the variables holding those parameters in the source code. Instead, the user-friendly name is given in the source code (with the tooltip and the default value in case no value is assigned to this parameter).

The hierarchy of objects in Badger will be:

This hierarchy mimics the hierarchy of parameterized classes in the Simion app. Being organized in this manner, one can be output all the parameters to an XML file in a hierarchical structure. The Simion app will take the value for each parameter from this XML file.

Forks

Forks are the most helpful feature in Badger: they allow users to give several different values to a parameter. Then, Badger will do a parameter sweep, testing all the possible parameter combinations. A fork is a special node in the configuration node hierarchy.

Example

Lets consider the previous example: what if we want to run the experiment with Num-Integration-Steps= 4 and 6? We would have to fork (right-click) this parameter:

and two nodes would be inserted between the parent (World) and the parameter:

The first node (ForkedNode) represents a fork and can be given an alias (fork names cannot be repeated). The second (ForkValue) represents a branch within the fork and the node we forked in the first place will be hanging from it.

Now, we can add a second value to this fork (add button), navigate to it (using the arrows in the Fork), and change its value to 6.

The hierarchy in badger would be now:

When we launch the experiment, two different versions of the experiment will be run: one for each branch of the fork. If there were two different forks, the number of experiments would equal the number of combinations of the two forks, and so on.

Inside a forked node there can also be more forks, and they will only show under the fork branch that contains them.