Create internal links within dd when grid_ggd[:].path is provided

[anchal-physics]

IMAS data model schema has property path in grid_ggd IDS which is a path to another IDS grid_ggd to refer to an existing definition of grid_ggd. For example, radiation.grid_ggd[1].path can refer to edge_profiles.grid_ggd[1] by having value IDS::edge_profiles/grid_ggd(1). This is described in the webpage for OMAS data schema for all different grid_ggd.

This is an important feature for this data model to save space and reduce redundancy. While end users can write their own parser for grid_ggd.path and link to th relevant grid_ggd, it would be a really cool enhacement if IMASDD implements this link internally such that when dd.radiation.grid_ggd[1] is called, it points to dd.edge_profiles.grid_ggd[1] automatically. I envision a check in the constructor call of grid_ggd functions where if path is provided, it creates this link. And an explicit function too, so that one can add the path after creation of IDS object and get this link working.

I don't know though how this will be implemented or if it is even possible in a meaningful way without slowing down IDS access too much since all children grid_ggd are actually separate data types based on parent IDS.

[TimSlendebroek]

This sounds very similar to the expressions feature that we have for this in another repository, @orso82 do you think this could be added to IMASDD?

[orso82]

Yes, that can be done in a similar way that we handle expressions.

@anchal-physics can you confirm that the IDS::edge_profiles/grid_ggd(1) syntax is something specific to how the GGD specification is implemented in IMAS. I have not seen such referencing anywhere else...

[anchal-physics]

I've read it on the OMAS schema page.

Path of the grid, including the IDS name, in case of implicit reference to a grid_ggd node described in another IDS. To be filled only if the grid is not described explicitly in this grid_ggd structure. Example syntax: IDS::wall/0/description_ggd(1)/grid_ggd, means that the grid is located in the wall IDS, occurrence 0, with relative path description_ggd(1)/grid_ggd, using Fortran index convention (here : first index of the array)

Maybe this is Fortran syntax. I'm unaware of official IMAS data schema documentation. I'll search for it.

[orso82]

IMAS has actually done a good job at updating their documentation.
Take a look here https://sharepoint.iter.org/my.policy (unfortunately you still need an ITER account to see it)

[anchal-physics]

From the official html documentation of IMAS, all I can find about grid_ggd[:].path is the following:

Path of the grid, including the IDS name, in case of implicit reference to a grid_ggd node described in another IDS. To be filled only if the grid is not described explicitly in this grid_ggd structure. Example syntax: IDS::wall/0/description_ggd(1)/grid_ggd, means that the grid is located in the wall IDS, occurrence 0, with relative path description_ggd(1)/grid_ggd, using Fortran index convention (here : first index of the array) {dynamic}

But I was able to find the PR where this feature was introduced. In particular, the file IDS-path-syntax.md provides complete syntax for idspath. The webpage documentation is slightly outdated as it does not show the utilities documentation for some reason. Following description should follow grid_ggd(:)/path:

Path of the grid, including the IDS name, in case of implicit reference to a grid_ggd node described in another IDS. To be filled only if the grid is not described explicitly in this grid_ggd structure. Example syntax: 'wall:0/description_ggd(1)/grid_ggd', means that the grid is located in the wall IDS, occurrence 0, with ids path 'description_ggd(1)/grid_ggd'. See the link below for more details about IDS paths

The link is to IDS-path-syntax.md file. In this syntax, note that there is no IDS present and occurrence is shown differently.

I'll paraphrase the new syntax here:

<top_ids_name>[:occurrence]</path/to/grid_ggd>

Here:

• <top_ids_name> is top most IDS such as wall, radiation, edge_profiles etc.
• [:occurrence] parameter is actually optional. Physics Data Model and Access Layer User Guide v1.11 Sec 4.1 says that within a single data entry, IDS can occur multiple times. In storage, each IDS is a separate HDF5 file and data entry is an HDF5 file referring to all other IDSs, thus occurrence technicaly means the HDF5 index of the IDS in the path. I think for IMASDD, each IDS only occurs once, so we can probably ignore this. When not provided, Access Layer software assumes 0th occurrence.
• </path/to/grid_ggd> is idspath description which is '/' separated path in the IDS structure. If an array of IDS is present, it's index can be provided using curved brackets.

Example:

If I want to refer to grid_ggd of edge_profiles to store radiation information. Then at dd.radiation.grid_ggd[1].path, I will store the value: edge_profiles/grid_ggd(1).

Note: As far as I understand, since a particular grid_ggd instance out of the array of grid_ggd has this path field (dd.radiation.grid_ggd[1].path in above example), it must be referring to a particular index of grid_ggd in the path as well otherwise it won't really make sense. The example in documentation however misses this detail.

---

I hope this was helpful. If this feature comes up soon, it will be helpful in synthetic bolometer that I am developing.

[orso82]

How about something like this in IMASDD.jl ?

all__grid_ggd = Union{IMASDD.edge_profiles__grid_ggd, ...}

function Base.getproperty(@nospecialize(ids::all__grid_ggd), field::Symbol)
    if _getproperty(ids, :path)..
        return _getproperty(getfield(top_dd(ids),getproperty(ids, :path)), field)
    else
        return _getproperty(ids, field)
    end
end

[anchal-physics]

I missed the last comment here. This looks like a good solution. Please add this functionality if possible.

[anchal-physics]

I really needed this functionality to move forward with a synthetic diagnostic, so I have for now overloaded getproperty here in IMASggd. It works quite well but I imagine there might be better way to do this. I haven't overloaded setproperty but I'm not sure if that is even required. I'll remove it from IMASggd once it is implemented here.