ASSUMPTIONS

Objectives:

• GET: To retrieve subset of data elements
• GET_SIZE: To interrogate the size of subset of data elements,

• To retrieve subset of data elements (GET method), a syntax of the type a syntax of the type ids_get(<path_including_indices>) will likely be used. The possibility of using a more intuitive API ids.path.to.field.get(indices) will be also investigated (the latter is a priori easier to implement, directly as a Python method of the requested node, provided the new LL is restructured according to an object-oriented approach).

1.                                      i.     If the field is an array of structure, the returned data is an array of structure containing the desired indices (optional argument, by default all indices are returned). Example : magnetics.flux_loop(indices) à straightforward with Bartek’s method
2.                                     ii.     If the field is a simple structure or a leaf with no more than one array of structure ancestor, an array of the field is returned, containing the desired indices of its parent array of structure (optional argument, valid only if the requested leaf has the same size for all desired indices). Example : magnetics.flux_loop(indices).flux à how can we specify this with Bartek’s method ? Does a Python method accept a syntax such as magnetics.flux_loop(:).flux.get or magnetics.flux_loop.flux.get(:) ?
3.                                   iii.     It will be investigated if the method can be also easily implemented (i.e. the result is not guaranteed and the need is less obvious) for a field which
   1. Is an array of structure with an array of structure ancestor: e.g. ic_antennas.antenna(indices1).module.get(indices2)
   2. Is a field or a simple structure with more than one array of structure ancestor : e.g. ic_antennas.antenna(indices1).module(indices2).power_launched.get

• GET_SLICE type methods are not in the scope of the task (they are alternative ways to retrieve parts of the data elements) – although may be useful to add (independently of the deliverable) if straightforward to implement.
• To interrogate the size of subset of data elements, a syntax of the type ids_get_size(<path_including_indices>) will likely be used. The possibility of usage of a more intuitive API ids.path.to.field.get_size(indices) will be also investigated

1.                                      i.     If the field is an array of structure, the returned data is the size of the array of structure. Example : magnetics/flux_loop(indices)
2.                                     ii.     If the field is a simple structure or a leaf with no more than one array of structure ancestor, an array of sizes of the field is returned, containing the desired indices of its parent array of structure (optional argument, valid only if the requested leaf has the same size for all desired indices). Example : magnetics/flux_loop(indices)/flux
3.                                   iii.      It will be investigated if the method can be also easily implemented (i.e. the result is not guaranteed) for a field which
   1. Is an array of structure with an array of structure ancestor
   2. Is a field or a simple structure with more than one array of structure ancestor

• Although this is not part of the deliverable, contacts with users suggest that having a similar partial PLOT method would be very useful for leaves having an AoS3 ancestor (for plotting all time slices in a single instruction and avoid restructuring the IDS types with the time dimension for equilibrium and core_profiles signals for instance)

OPEN POINTS:

• Is it possible to implement ids.path.to.field.get(indices) -> arrays of structures as a part of path....