Update JSON generator to work with vt's LBDataHolder

[cwschilly]

In order for vt to successfully encode information in an object's ID, we need to:

• Add collection_id to each entity field
• Output the entire entity in the communications to/from fields (including home, and migratable)
• Use seq_id instead of id for objects/tasks (since id now means that the value is encoded)
• Use shared_id instead of shared_block_id everywhere #531

---

As a model, vt's LBDataHolder has this function:

void LBDataHolder::outputEntity(nlohmann::json& j, ElementIDStruct const& id) const {
  j["type"] = "object";
  j["id"] = id.id;
  j["home"] = id.getHomeNode();
  j["migratable"] = id.isMigratable();
  if (node_idx_.find(id) != node_idx_.end()) {
    auto const& proxy_id = std::get<0>(node_idx_.find(id)->second);
    auto const& idx_vec = std::get<1>(node_idx_.find(id)->second);
    j["collection_id"] = proxy_id;
    for (std::size_t x = 0; x < idx_vec.size(); x++) {
      j["index"][x] = idx_vec[x];
    }
  } else if (node_objgroup_.find(id) != node_objgroup_.end()) {
    auto const& proxy_id = node_objgroup_.find(id)->second;
    j["objgroup_id"] = proxy_id;
  } else {
    // bare handler
  }
}

which is called any time an object is being written, whether in the communications field or tasks field. For example:

      // Adding entity to tasks
      outputEntity(j["tasks"][i]["entity"], id);
      
      // Adding entity to communications["to"] or communications["from"]
      outputEntity(j["communications"][i]["from"], key.fromObj());
      outputEntity(j["communications"][i]["to"], key.toObj());

[ppebay]

@cwschilly I am unsure I understand from the description, whether seq_id will replace id, or be in addition to it.

In either case, is it correct to understandseq_id in the same sense, as in examples such as below:

?

[cwschilly]

@ppebay seq_id should replace id in LBAF's generated JSON files.

The convention we have landed on in vt is:

• id denotes a bit-encoded ID (ie it contains information regarding the object's home, migratability, and node)
• seq_id is a standard integer identifier, which is what the LBAF generator currently creates.

Basically, what LBAF is currently calling an id is actually a seq_id in vt.

(We'll need to update LBAF's reader in order to accommodate this change.)

[ppebay]

Alright, thanks @cwschilly -- and also following discussion with @lifflander I understand that any object would now be identified via a triplet (seq_id, home_id, migratable) in $\mathbb{N}^2\times\mathbb{Z}_2$.

Will the generator be then responsible for turning this triplet into a packed id; or would that be done by vt itself when reading a JSON using that format?

[cwschilly]

@ppebay vt will read in the plain seq_id and generate the packed id from there. This work is being done in vt PR 2343

This being said, in the future it might be advantageous for LBAF to use the same identification schema as vt. But for now, LBAF's generator is not responsible for packing the ids.