Metadata optimization: Only write ADIOS2 attributes from rank 0 in openPMD-api >= 0.16

[franzpoeschel]

We were thinking about using this as the default option generally in openPMD, but our documentation specifies that attribute writing is collective only in HDF5, and attributes can be written independently in ADIOS2. So it would have broken the API contract to assume that attributes outside of rank 0 can be ignored.
In PIConGPU, however, they can.

[chillenzer]

Why isn't this more targeted? Like this

Suggested change

	"attribute_writing_ranks": 0,
	# if OPENPMDAPI_VERSION_GE(0, 16, 0)
	"attribute_writing_ranks": 0,
	# endif

(with appropriate string concatenation). The next person changing something in this configuration will have to do so in two places. I'm aware that these are close together and it's not a huge burden but still it's something that could get overlooked in a quick diff that doesn't show the other section. (In fact, I've only seen the duplication because I've looked at the full file to understand what's going on. The current diff doesn't even show the other version.)

[franzpoeschel]

Tried that at first, it's far worse to read than just seeing directly the configuration listed for the supported versions:

#    if OPENPMDAPI_VERSION_GE(0, 16, 0)
#        define PICONGPU_ATTRIBUTE_WRITING_RANKS                                                                      \
            "\n"                                                                                                      \
            R"(    "attribute_writing_ranks": 0,)"
#    else
#        define PICONGPU_ATTRIBUTE_WRITING_RANKS ""
#    endif

        std::string const& defaultValues = R"(
{
  "hdf5": {
    "dataset": {
      "chunks": "none"
    }
  },
  "adios2": {)" PICONGPU_ATTRIBUTE_WRITING_RANKS
                                           R"(
    "engine": {
      "preferred_flush_target": "buffer",
      "parameters": {
        "BufferChunkSize": 2147381248
      }
    }
  }
}
        )";

The only solution that I'd really consider an improvement in maintainability would be to define separately:

        std::string const& baseConfiguration = R"(
{
  "hdf5": {
    "dataset": {
      "chunks": "none"
    }
  },
  "adios2": {
    "engine": {
      "preferred_flush_target": "buffer",
      "parameters": {
        "BufferChunkSize": 2147381248
      }
    }
  }
}
        )";
    std::string const& openPMD_0_16_additionalConfiguration = 
        R"({"adios2": {"engine":{"attribute_writing_ranks": 0}}})";

And then use openPMD::json::merge() instead of manual string concatenation, but that's an additional round of parsing, an additionaly call to an external library and an additional runtime error source, too.

For a long-term solution, I'd suggest that we add something like {"dont_warn": ["preferred_flush_target"]} to openPMD so that warnings about unknown keys can be suppressed, making this above distinction unnecessary:

{
  "hdf5": {
    "dataset": {
      "chunks": "none"
    }
  },
  "adios2": {
    "engine": {
      "dont_warn": ["preferred_flush_target"],
      "preferred_flush_target": "buffer",
      "parameters": {
        "BufferChunkSize": 2147381248
      }
    }
  }
}

[chillenzer]

A very online "offline" discussion: The current solution oscillates between string and json representation quite a bit. A cleaner solution that would also allow for a very readable solution of this particular problem would be to stay completely in json-world. @franzpoeschel will consider if changing this a beneficial move and act accordingly.