Flush Before storeChunk: Triggers Write

[ax3l]

@franzpoeschel just realized that a series.flush() for new record components, before a storeChunk is even called, queues a one-element dataset-write to the backends.

This is visible in the parallel write example:

https://github.com/openPMD/openPMD-api/blob/0.7.1-alpha/examples/5_write_parallel.cpp#L86

and doesn't seem right from our internal handling logic:

• it will write unnecessary, random data to location (0,[0,...0])
• this data will be overwritten later on
• all backends have to handle this unusual corner case

Likely origin:
https://github.com/openPMD/openPMD-api/blob/0.7.1-alpha/src/backend/PatchRecordComponent.cpp#L97

[franzpoeschel]

After following things around in the debugger, I can confirm that the code you are pointing to is the origin of this behavior.
First problem: auxiliary::allocatePtr will only allocate memory, but not initialize it, so we read uninitialized memory in the backends while performing the bogus writes. An easy fix would be to make auxiliary::allocatePtr actually initialize the memory. Apart from this file, the function is only ever used twice in CommonADIOS1Handler.cpp and never for large values of numPoints. If we do this, the function should probably be renamed to avoid confusion.

The behavior of ADIOS not to create variables if no actual values have been written persists in ADIOS2. We could discuss whether it should be ok for our API to simply leverage this behavior. After all, when creating a dataset but not writing actual data to it, not seeing the dataset in the bpfile is arguably less surprising than seeing uninitialized memory at position 0 – especially since the behavior leaks into the other backends, resulting in such things:

{
  "attributes": {
    ...
  },
  "data": [
    [
      43,
      null,
      null,
      null,
      null
    ],
    [
      null,
      null,
      null,
      null,
      null
    ],
    [
      null,
      null,
      null,
      null,
      null
    ]
  ],
  "datatype": "UINT"
}

It is likely impossible in either version of ADIOS to force the creation of a variable without doing tricks like this, but before we investigate it: should we? I would suggest just removing the lines that @ax3l pointed to and calling it a day.