Time information and realistic animations

[DraTeots]

Dear developers,
As I saw the examples, event data of them don't have actual time information. So two questions:

1. Is it correct that currently phoenix doesn't works anyhow with the right times and the animation is just a visual effect.
2. Are there plans to work with timing information and provide realistic animations?

The background of the question, at HallD in Jefferson Lab was this event viewer:

https://halldweb.jlab.org/talks/2018/HDvis-Video/js/event.html#

It is not fancy but has real time information from the experiment. And our experience of using it was that it gave very valuable debugging information for people working on the real data reconstruction. At least it almost instantly revealed several bugs and lead to several enhancements. So it was proven to be valuable.

Now I'm one of developers working on EIC Athena collaboration software. And we desperately want to start working on something to better represent our simulation/reconstruction data and for sure phoenix effort is something that we seriously consider to join.

[EdwardMoyse]

Hi Dmitri,

This has been raised before and it's certainly something we'd be interested in supporting. Adding the time information to the Event Data Model (EDM) would be the first step, and should be pretty trivial. What is your event format? Do you have any examples we could look at?

Secondly we need to work out how to animate this - this is probably quite a bit more work, but still doable.

What might be a good idea is if you could join a Phoenix developer chat (Wednesday at 3pm, Central European Time) so we can discuss this "in person"

[9inpachi]

Hi Dmitry,

If you would like to dig into the code a bit, you can take a look at the AnimationsManager which handles all the animation stuff.

Now based on the event viewer you shared, we also have ways to animate the camera through the scene. It's possible to pretty much do any kind of animation without having to dive deep into the Phoenix core and just updating the AnimationsManager. There is also a possibility to just use Phoenix as a dependency and handle the animations in another project entirely.

All in all, introducing and handling time information in animations shouldn't be unrealistically hard but it heavily depends on the requirements and how generic we want it to be.

[deveshbervar]

Hi all,

I’ve been reading through this issue and the earlier comments, and this is something I’d be very interested in contributing to.

From my understanding:

• Phoenix currently does not model real event timing in the EDM
• Animations are visual rather than time-driven
• Adding time information to the EDM would be a reasonable first step

I’d be happy to start with a small, non-breaking contribution (e.g. introducing optional time fields in the event data model) and iterate from there based on feedback.

Before starting, I just wanted to check:

• does this sound like a reasonable first step?
• are there any design constraints I should follow for EDM changes?

Thanks!

[cohm]

Since I happened to come across this, I just wanted to connect it to #235 which is another pretty clear use case (though I have trouble accepting it is 5 years ago I suggested it..). And it’s perhaps worth pointing out that when showing truth info we have the time of the vertices and can calculate the speed of the particles from the four-vectors — and there are use cases with heavy slow-moving BSM particles which would be very nice to visualize.

[EdwardMoyse]

That's a really good point. And actually I'm embarrassed to admit I forgot about the BSM use case. I think it'd be really helpful to have a dataset to develop this against.

[cohm]

I think it'd be really helpful to have a dataset to develop this against.

This I can help with easily. What format would you like? Actually, since people who don’t work on ATLAS could help with this, perhaps it’s best to check if we have some open data with samples like these.

[deveshbervar]

Hi @cohm and @EdwardMoyse,

This is really exciting — having a real dataset to develop
against would make this much more concrete.

From the discussion on PR #822, I understand the right
approach is per-object timing (hit.time, track.time) rather
than a global eventTime, so that:

• Each hit/track appears when the animation reaches
  its specific timestamp
• Works correctly for non-symmetric detectors
• Handles cases like cosmic rays (top → bottom) and
  slow BSM particles naturally

@cohm — once you share the dataset format, I can make sure
the EDM time fields are designed to match it properly.

In the meantime, would it make sense for me to:

1. Add optional time?: number (ns) to hit/track objects
   in the EDM as a foundation
2. Keep animation changes for a follow-up PR once we
   have the dataset to test against

Happy to follow whatever direction works best for the team!