@pierrepebay for your information you will find - in currently active #32 branch - the 2 example data files and configurations files (imported and adapted from the DARMA-tasking/LB-analysis-framework repository) as it was requested in #32 by @ppebay.
If it can help you to save some time.

@ppebay @tlamonthezie @pierrepebay

The immediate solution to this is to change the user_defined field of the JSON to be attributes instead. For example:

"tasks": [
  {
    "entity": {
      "home": 1,
      "id": 2,
      "migratable": true,
      "type": "object"
    },
    "node": 1,
    "resource": "cpu",
    "time": 5.0,
    "attributes": {
      "shared_id": 1,
      "shared_bytes": 15000.0,
      "home_rank": 1
    }
  }
],

Any attributes can then be called as QOI in the config file:

viz:
  rank_qoi: load
  object_qoi: shared_id

This brings up a larger question of the difference between the user_defined and attributes fields.

It seems like user_defined was initially intended to provide "phase-level information (like t or dt from the application)" (vt#2171), while the attributes field was meant to "allow arbitrary attributes per rank and object to be selected as QOIs" (vt#2229).

Should we update LBAF to adhere to this distinction (it looks like LBAF doesn't support the attributes field)? Or should vt-tv treat the user_defined field as representing QOI as well?

Should we update LBAF to adhere to this distinction (it looks like LBAF doesn't support the attributes field)? Or should vt-tv treat the user_defined field as representing QOI as well?

After discussing with @ppebay , we will treat the user_defined field the same as attributes