workflows

UNDER CONSTRUCTION!

MABE is a huge software package, and we found that different people at times use fairly different workflows. So here, we wanted to elaborate on their differences, and give you the opportunity to reflect on how you do things, how we intended to do things, and what you might want to do differently. It also gives us the opportunity to explain why certain things are the way the are.

Workflow 1: Out of the box

One of MABEs key features is, that you can use it right out of the box. If you follow the [quick start guide](Installation-and-getting-started-with-MABE) you end up with a fully functional version of MABE that contains pretty much all relevant features you might ever want to use. This MABE version can be entirely controlled by command-line parameters or config files. The idea is that this ready made package allows you to run not only a wide variety of experiments, it also allows you to customize them easily. Very often we find that we want to repeat an experiment, but want to use a different environment, different optimizers, or other brains. Doing this, just requires you do change a line or two in the config file, no coding required, and no recompilation. BTW. testing you hypotheses with different brains or optimizers or in different environments/worlds will make you results more robust. There is one tiny drawback, and that is the large size of config options you get when you create all config files. It gives you all the power, but the sheer number of options might intimidate you, that is why there is a build system which you will use for the second type of workflow.

Workflow 2: Building your custom MABE

A more elegant way of using MABE is to only compile what you need. No worries, you can always add modules and components later, MABE is modular enough that you should not have any problem with that. In order to compile only what you need, you have to edit a file called "buildOptions.txt" and check or uncheck which modules you need. After that you call a python program called "MBuild.py" which takes the buildOptions.txt file and sorts out which files you need and which ones you don't, and secondly modifies the modules.h file so that the newly created project fits together properly. "Tada", you have a custom project. The advantage of this approach is, that you reduce the number of options in the config file drastically. Your compile time and size footprint is better, but that is so minimal that it virtually doesn't matter. This is not so much a functional improvement, as it is making it easier for you to focus on what you need. To give an example: Imagine you don't care for elite selection. Don't add that optimizer, because now you won't see the many options that are added to the config files. Not a functional change, but less text to scroll through and you brain doesn't need to concern itself with those options.

Workflow 3: Using MABE as a library

We want to support all your experimentation needs, and that means that you have to have the ability to customize everything to your needs. There are infinitely many possible experiments you might run, and it is impossible for us to foresee them. Thus MABE is designed to support what most people need right out of the box, while also giving you all the components and tools for you to build your own experiment. However, this means that you might need to leave the path that we typically do. To give you an idea of what that might mean: most people design new worlds/environments or new types of brains or gates and then evolve populations using these new modules and collect the data you need. But what if you now want to test evolved organism in a set of different worlds, or change environments while you evolve, or mix organisms from different experiments and compete them against each other, or .... Well, now you need to change more than just modules, you need to change what MABE typically does. The place for that is "main.cpp", and while we provide this file and our config and build tools are made so that you don't need to touch this file, we think of "main.cpp" as a place where "everything goes". Obviously, this requires a bit more coding skill and insight into C++ and MABE, but to support this, we have a tutorial "writing your own main.cpp" which shows you how the typical main works, and also how you might customize the code to fit your experiment. If you are doing this, think of MABE as a library you can use and assemble any which way you want.