TrajectoryPoints?

[cbernet]

Hi everybody,

In papas we have a data structure called path that contains trajectory parameters and points (reference points on the trajectory). We're talking about a purely geometrical object, this is not a track.

The number of points is arbitrary but limited to ~10, and the points are indexed by a name (e.g. vertex, ecal_entrance, ..). We would like to store such objects in the FCC EDM.

We thought about the following.
What do you think? wouldn't a fixed size array of points be more adequate in fcc::TrajectoryPoints?
Do we have such a thing?
Indeed, we think it is better to have concrete storage of the points within fcc::TrajectoryPoints rather than in a separate collection.

fcc::Helix:
   # here helix parameters
  OneToOneRelations:
  - fcc::TrajectoryPoints points

fcc::StraightLine:
   # here straightline parameters
  OneToOneRelations:
  - fcc::TrajectoryPoints points

fcc::TrajectoryPoints: 
  OneToManyRelations:
  - fcc::Point points 

Cheers,

Colin, @alicerobson

[alicerobson]

Hi Colin Have I missed something? How is the name that is associated with each point to be stored using your proposal? "the points are indexed by a name (e.g. vertex, ecal_entrance, ..)" Alice

…

On 01 Dec 2016, at 11:22, Colin Bernet ***@***.***> wrote: Hi everybody, In papas we have a data structure called path that contains trajectory parameters and points (reference points on the trajectory). We're talking about a purely geometrical object, this is not a track. The number of points is arbitrary but limited to ~10, and the points are indexed by a name (e.g. vertex, ecal_entrance, ..). We would like to store such objects in the FCC EDM. We thought about the following. What do you think? wouldn't a fixed size array of points be more adequate in fcc::TrajectoryPoints? Do we have such a thing? Indeed, we think it is better to have concrete storage of the points within fcc::TrajectoryPoints rather than in a separate collection. fcc::Helix: # here helix parameters OneToOneRelations: - fcc::TrajectoryPoints points fcc::StraightLine: # here straightline parameters OneToOneRelations: - fcc::TrajectoryPoints points fcc::TrajectoryPoints: OneToManyRelations: - fcc::Point points Cheers, Colin, @alicerobson <https://github.com/alicerobson> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#31>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANqb2oQBUFicQ0LNVV3Lyzj6YLp_oe_9ks5rDp_5gaJpZM4LBN-7>.

[jlingema]

Hi Colin and Alice,

Sorry for only answering now, I missed this somehow.

We now (since podio v0.6) have the possibility to store arrays, but it was only tested for builtin types. There is a small bug fix necessary to make it also work for PODs (components), PR soon. So something like this should be feasible:

components:
fcc::TrajectoryPoints: 
  points: std::array<fcc::Point, 10>

datatypes: 
fcc::Helix:
   # here helix parameters
  Members:
  - fcc::TrajectoryPoints points

fcc::StraightLine:
   # here straightline parameters
  Members:
  - fcc::TrajectoryPoints points

However, is it really fixed size? Regarding Alice's question, I guess that could be solved by an enum?

Cheers,
Joschka

[cbernet]

Hi Joschka, an enum could be good but is there a way to declare that with podio?

[jlingema]

No. After writing I also began wondering about how to make this work without risking to go out of synch.

[jlingema]

Although, I guess one could use the ExtraCode but I guess that was not it's intended usage, @hegner?

[jlingema]

To elaborate on that, something like this does work:

fcc::TrajectoryPoints: 
  points: std::array<fcc::Point, 10>
  ExtraCode :
      declaration: "
      enum class PointType : int { kVertex, kEcalEntrance, ...};"

[cbernet]

Cool!

…

Le 7 avr. 2017 à 09:26, Joschka Lingemann ***@***.***> a écrit : To elaborate on that, something like this does work: fcc::TrajectoryPoints: - std::array<fcc::Point, 10> points ExtraCode : declaration: " enum class kPoint : int { vertex, ecal_entrance, ...};" — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#31 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD8ku4as-dxCyXTHJ5fe9_g2fyqssdSoks5rteUtgaJpZM4LBN-7>.