# Supporting grid representation and grid index APIs for cases with LGR

**URL:** <https://discourse.f2i-consulting.com/t/supporting-grid-representation-and-grid-index-apis-for-cases-with-lgr/251>\
**Category:** FESAPI\
**Created:** [June 18, 2025, 4:22pm UTC](https://discourse.f2i-consulting.com/t/supporting-grid-representation-and-grid-index-apis-for-cases-with-lgr/251 "2025-06-18T16:22:59Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![sgthomas-github](https://discourse.f2i-consulting.com/user_avatar/discourse.f2i-consulting.com/sgthomas-github/32/12_2.png) [@sgthomas-github](https://discourse.f2i-consulting.com/u/sgthomas-github)\
**Post date:** [June 18, 2025, 4:22pm UTC](https://discourse.f2i-consulting.com/t/supporting-grid-representation-and-grid-index-apis-for-cases-with-lgr/251/1 "2025-06-18T16:22:59Z")

</div>

Hi, One more question. In the old 0.13 version of fesapi I recall the APIs such as `getSupportingGridRepresentation` didn’t work correctly to yield `Title` and `UUID` of supporting grid representation (e.g. for LGR models), i.e. the below didn’t work:

```auto
            const auto& support_grid_rep = gcsr->getSupportingGridRepresentation(idg);
            if (support_grid_rep != nullptr)
            {
              usg_grid_names.push_back(support_grid_rep->getTitle());
              usg_grid_uuids.push_back(support_grid_rep->getUuid());
            }

```

and I used to workaround it by instead access it from the data object reference as:

```auto
            const auto& support_grid_rep = gcsr->getSupportingGridRepresentationDor(idg);
            if (support_grid_rep != nullptr)
            {
              usg_grid_names.push_back(support_grid_rep->Title);
              usg_grid_uuids.push_back(support_grid_rep->UUID);
            }

```

Likewise the API to `getGridIndexPairs` to get the grid index pairs of a connection set representation (e.g. for cases with LGRs), also used to not work correctly (can’t recall the exact behavior of the bug - either crash or just returns nothing) in the older 0.13 version and instead I had to get it directly from the HDF5 as below:

```auto
          const auto& gcsr_uuid = gcsr->getUuid();
          const std::string& gridid_dataset_name = "/resqml20/" + gcsr_uuid + "/GridIndexPairs";
          const auto& hdf_proxy = m_impl->epc_data_repo->getHdfProxy(0);
          hdf_proxy->readArrayNdOfUShortValues(gridid_dataset_name, &gcsr_gridid_pairs[0]);

```

Similarly the `setParentWindow` API used to fail with an exception in 0.13 unless I set HDF proxy prior to calling it as below:

```auto
        grid_ptr->setHdfProxy(m_impl->epc_data_repo->getHdfProxy(0));
        grid_ptr->setParentWindow(lcidh_prop_data->data(),
                                  lcidh_prop_data->size(),
                                  coarse_grid_ptr);

```

I believe this one is fixed from the new API which now acceps the HDF proxy as last argument:

```auto
        grid_ptr->setParentWindow(lcidh_prop_data->data(),
                                  lcidh_prop_data->size(),
                                  coarse_grid_ptr,
                                  m_impl->epc_data_repo->getHdfProxy(0));

```

Also related to that I recall the LGR parent (host) cell IDs used to be not written to the H5 file and I had to manually write them to the H5. I am still in the process of making changes to the client code to accommodate all the changes in the latest version 2.12.2.1, and will be testing this shortly once I get a good build, but just wondering if anyone recalls if the above have been fixed in the more current versions. Much appreciated.