Open anchal-physics opened 3 months ago
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?
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...
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.
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)
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.
<top_ids_name>[:occurrence]</path/to/grid_ggd>
Here:
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.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.
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
IMAS data model schema has property
path
ingrid_ggd
IDS which is a path to another IDSgrid_ggd
to refer to an existing definition ofgrid_ggd
. For example,radiation.grid_ggd[1].path
can refer toedge_profiles.grid_ggd[1]
by having valueIDS::edge_profiles/grid_ggd(1)
. This is described in the webpage for OMAS data schema for all differentgrid_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 relevantgrid_ggd
, it would be a really cool enhacement if IMASDD implements this link internally such that whendd.radiation.grid_ggd[1]
is called, it points todd.edge_profiles.grid_ggd[1]
automatically. I envision a check in the constructor call ofgrid_ggd
functions where ifpath
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.