Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Little projects #10

Open
petitcactusorange opened this issue Oct 14, 2015 · 5 comments
Open

Little projects #10

petitcactusorange opened this issue Oct 14, 2015 · 5 comments

Comments

@petitcactusorange
Copy link

After discussing with @betatim though of this issue.
This is a list of small projects people could work on during the parallel sessions :

  • Make different level of abstraction.
  • Make it easier to store new objects/classes in output files.
  • More to be added.
@betatim
Copy link
Member

betatim commented Oct 16, 2015

The idea is to have some time of the parallel allocated for "Hacking/break-out" sessions. For this we need some projects people can attempt to get the juices flowing and give them ideas. Ideally people bring their own ideas though.

abstraction levels

The higher level abstraction we can offer the "user" the more opportunity we have for optimising things. What is the right level of abstraction? Use cases from fitting tracks, doing things to a group of particles, selecting a range of events to store in a file.

storing objects

Right now it is impossible to add a new class to be stored in a DIGI/DST. This leads to all sorts of hacks. boost::any? captnproto? What are possible answers? This is related to backwards compatibility in #12

linking information across objects

We invented ExtraInfo as some crazy hack that does not work very well. We need a better way to be able to add more information to a given object (be that a track, particle, hit, ...). This information will exist for some but not all objects in a collection. If you think of the information in an event as a big table, then this is natural, you simply add a new column.

best way to express a processing pipeline

How do you express something like "take these hits, build tracks from them, filter on X, take these other hits, build different kinds of tracks from them, filter them on Y, merge the two track collections, evaluate PID info for them, select pions with pt>5GeV" in a way that is flexible and extremely easy for humans to read, and also possible for computer to parse?

@petitcactusorange
Copy link
Author

Quick note from afternoon chat :

  • Graph
  • std::any
  • Functional.
  • IO library.
  • Compose objects.

@petitcactusorange
Copy link
Author

What is the best way to advertise the little projects ? SLACK ? LHCb general ?

@betatim
Copy link
Member

betatim commented Nov 9, 2015

Not sure about how to advertise these.

Another project:

Random access store

What technology exists out there for efficient storage that fits our needs and allows for random access. A small review of the existing chunked, column stores could be a good starting point. The advantage of being able to do random access would be not having to read through large numbers of files that are in the same stripping stream.

@petitcactusorange
Copy link
Author

We discussed the possibility of having a short presentation of the projects Monday afternoon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants