PFAlgo refactoring about cmssw

[guitargeek]

Thanks for the initiative and the summary, @jpata!

[hatakeyamak]

Have a good vacation. I will send you some thoughts/feedback over the next few days.

[hatakeyamak]

Coming back to this thread:
first of all, thanks for all you two do @jpata @guitargeek .

In the above list of Joosep,

• Follow up with a clang-format pass on the whole PFAlgo package
• Modernize logging and make it thread-safe (cout -> MessageLogger)
  are very clearly defined work, and sound good.

Beyond that would require algorithmic/conceptual developments which require deeper thoughts and planning. You might want to see the talk we gave at UPSG workshop yesterday:
https://indico.cern.ch/event/828365/

I think it will be also nice to add the utilization of the heterogeneous computing (e.g. GPU) for PF clustering and/or block producer if you are interested.

cc: @bendavid

[jpata]

Very interesting slides, thanks for that. Clang-format has already been done, following up with logging and cleanup here: cms-sw#27505

I would like to invest some time in understanding the actual flow of the algorithm and the relevant datastructures once I get the logging updated. Even though PF is not a major CPU time consumer, it could be useful to think about PF on heterogeneous devices. In the past weeks I have been heavily involved in GPU programming for analysis.

[jpata]

I have now followed up on sanitizing the inputs and outputs of the some of the functions in PFAlgo a little bit in this PR: cms-sw#27901.

Overall, I'm now generally able to follow the logic of the code and mostly OK with it. Apart from completely rewriting PFAlgo from scratch given the physics goals, I don't foresee many fundamental changes at the moment that are easy to implement. As I'm not sure that this would be the highest priority item, I think it is a good moment to discuss what would be a good next step for the overall particle flow modernization project.

Possible options I see include:

• revisit PFBlockAlgo in a similar way
• start thinking about an ML-based and/or vectorizable PF algo

[hatakeyamak]

Thanks. Are Josh and Jonas getting messages in this thread?

In addition to what you have done, I am hoping to finish:
cms-sw#27782
as the config is a little mess, and some config parameters can be removed.

Apart from that, I don't have anything really concrete to work on, but a couple of questions and thoughts:

• I am curious. Do you have any concrete ideas about "vectorize PF algo"?
• I am still studying PFBlockProducer/linking in detail, so I don't have concrete ideas, but given that PFBlockProducer is the leading time-consumer for PF [1], I think it will be nice to see if there is a room for improvement in terms of cpu(gpu?) performance and physics performance.

@bendavid do you have some suggestions?

@jpata maybe you want to summarize what you have done so far, and potential options on what you may want to consider next in the next Tuesday's PF meeting?

[1] https://patatrack.web.cern.ch/patatrack/timing_report_june_2019/piechart.html

[jpata]

@hatakeyamak Thanks for your thoughts. I believe everyone who was mentioned here earlier should get the emails unless they explicitly disabled it. I can also send private emails but I find it useful to have a discussion in the open.

I will be happy to talk at the next PF meeting, I will prepare a few summary slides and thoughts.