Defining and computing derived variables

[anagainaru]

This PR introduces derived variables to ADIOS2.

Everything is guarded by ADIOS2_HAVE_DERIVED so ADIOS2 will have to be built with -DADIOS2_USE_Derived=ON

The API is similar to defining normal variables.

    auto Ux = bpOut.DefineVariable<float>("Ux", {Nx, Ny, Nz}, {0, 0, 0}, {Nx, Ny, Nz});
    auto Uy = bpOut.DefineVariable<float>("Uy", {Nx, Ny, Nz}, {0, 0, 0}, {Nx, Ny, Nz});
    auto magU = bpOut.DefineDerivedVariable("magU",
                                            "x:Ux \n"
                                            "y:Uy \n"
                                            "magnitude(x,y)",
                              adios2::DerivedVarType::StoreData);

For now, variables need to be defined before defining the corresponding derived variables.
The types of Derived Variables are:

enum class DerivedVarType
{
    MetadataOnly,     ///< Store only the metadata (default)
    ExpressionString, ///< Store only the expression string
    StoreData         ///< Store data and metadata
};

I removed the examples for now, there is a testing for add and magnitude that can be used for examples. Once we have some applications using derived variables and the functions introduced here are tested more, I will add documentation and examples.

I am currently working on a list of TODOs for what is left to do and what performance we want to test. I will share it with everyone when it's done.

[anagainaru]

@lizdulac I pushed the grammar commit as you the author (and for testing, you should appear as co-author). Can you check why you don't exist for GitHub?

[anagainaru]

The tests that are failing are not related to this branch:

366 - Engine.BP.*/BPChangingShapeWithinStep.MultiBlock/*.BP3.MPI (Timeout)
367 - Engine.BP.*/BPChangingShapeWithinStep.MultiBlock/*.BP4.MPI (Timeout)

This is ready to be reviewd (history is cleaned so each contribution is one commit and I added authors to whoever worked on that piece).

[eisenhauer]

I was trying to see if this was done, but perhaps easier just to ask. WRT the parser and lexer. If I recall, the default behavior of les/yacc was to create code that defined a set of functions and variables like yyparse(), and if you didn't take extraordinary steps you couldn't have two parsers/lexers linked together. In the ffs/cod stuff we manually do :

#define yyparse cod_yyparse
#define yylex cod_yylex
#define yyrestart cod_yyrestart
#define yywrap cod_yywrap
   . . .

Because YACC didn't support a nice alternative. However I think that if you don't worry about YACC (which by now is pretty extinct in the wild) and instead assume you've got bison, it has a prefix mode where you can essentially do the same thing, choose a prefix for the subroutine/variable names generated for your parser/lexer. Has this been done here? (This is like stopping at a stop sign. The system might handle one guy that never stops (or unsafely doesn't add a prefix), but if you encounter someone else who does the same thing, things will end badly.)

[anagainaru]

I am fairly sure this code creates an yyparser (not in a namespace and without any prefix) even though we are using bison and not yacc (again fairly sure but it's not my code). I'll ping @lizdulac here and talk to her separately to see if she can generate some prefix.

My solution was to exclude anything that is in the parser from what we expose as external headers so other apps using bison will never see yyparser. I include headers from parser/* only in cpp files so they don't propagate outside. I would feel better if there was a prefix anyway so it's worth looking into this.

[eisenhauer]

The failing tests are unrelated to this PR. Approving now and we'll handle the YACC/Lex build later.