Mutable Attributes: Allow redefining attributes. BP4 stream reading will provide the late…

[pnorbert]

…st definition at a given step. BP4 file reading provides the last definition even if BeginStep/EndStep is attempted. BP3 does not support changing attributes, it always presents the first definition of the attribute (although, in the encoded data blocks newer attributes appear but the metadata does not change).

Caveat: Modifying an attribute on non-zero rank process will have no effect as the change is not registered on the metadata aggregator.

$ ctest -R Engine.BP.BPWriteReadAttributes.WriteReadStreamMutable.BP4.Serial
Test project /home/adios/ADIOS2/build.debug
Start 258: Engine.BP.BPWriteReadAttributes.WriteReadStreamMutable.BP4.Serial
1/1 Test #258: Engine.BP.BPWriteReadAttributes.WriteReadStreamMutable.BP4.Serial ... Passed 0.01 sec

Stream reading:
$ ./bin/bpls -lta testing/adios2/engine/bp/bp4/foo/AttributesWriteReadMutable.bp/
Step 0:
int32_t var1 scalar
double var1\dArray attr = {0.1, 0.2, 0.3}
uint32_t var1\i32Value attr = 0
int32_t var2 {8}
double var2\dArray attr = {0.1, 0.2, 0.3}
uint32_t var2\i32Value attr = 0
Step 1:
int32_t var1 scalar
double var1\dArray attr = {1.1, 1.2, 1.3} -- modified value of attribute
uint32_t var1\i32Value attr = 1 -- modified value of attribute
double var2\dArray attr = {0.1, 0.2, 0.3} -- attribute was not modified so last value appears
uint32_t var2\i32Value attr = 0 -- attribute was not modified so last value appears
Step 2:
int32_t var1 scalar
double var1\dArray attr = {2.1, 2.2, 2.3}
uint32_t var1\i32Value attr = 2
int32_t var2 {8}
double var2\dArray attr = {2.1, 2.2, 2.3}
uint32_t var2\i32Value attr = 2

File reading:
$ ./bin/bpls -lA testing/adios2/engine/bp/bp4/foo/AttributesWriteReadMutable.bp/
double var1\dArray attr = {2.1, 2.2, 2.3} -- last definition appears
uint32_t var1\i32Value attr = 2
double var2\dArray attr = {2.1, 2.2, 2.3}
uint32_t var2\i32Value attr = 2

[eisenhauer]

I was thinking a bit simpler a mechanism might work for tracking changes. In particular, currently SST just looks at the size of the AttrMap returned by IO.GetAttributes and compares it to the previous timestep to see if there's anything new to marshal. I was thinking of adding an external AttrModificationNumber to the IO that would be incremented with every change. Then the engines could see if that changed from timestep to timestep for attribute marshaling purposes. But the NotifyEngineAttribute call gives the engines more info, so I don't have strong feelings about either approach. Since SST always marshals all attributes if any have been added/changed, NotifyEngineAttribute there could just set SSTWriter's m_MarshaledAttributesCount to 0, and that should enable mutable attributes there. But we'd need a matching testing test in staging-common to verify.

[ax3l]

Wuhuu!! cc @franzpoeschel for post-vacation 🎉