{'fraction_non_alphanumeric': 0.02885834064541289, 'fraction_numerical': 0.004972214097689383, 'mean_word_length': 4.963953488372093, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Exploring server/web-client event display for CMS

The divergence of windowing systems among modern Linux distributions and OSX is making the current mode of event display operations difficult to maintain. In order to continue to support the CMS experiment event display, Fireworks, we need to explore other options beyond the current distribution model of centrally built tarballs. C++-server web-client event display is a promising direction that can maintain the full functionality of Fireworks, including operation from the full experiment framework. In addition, it brings new features like multi-user debugging and the possibility to implement more elaborate visualization of non-event data through remote access to independent services. We have been exploring mainly in the direction of Fireworks-based C++ server and thin web-client user interface as it allows for a large degree of reuse of existing algorithms as well as for full access to CMS data formats and accompanying functions that are crucial for the correct physics interpretation of event data. This paper presents the basic architecture of the system, discusses the communication protocol between server and client, and shows existing prototypes that demonstrate the feasibility of advanced event display features.


Introduction
Fireworks is the official physics analyis oriented CMS event display since 2008. Its unique and powerful feature is its full interactivity with CMS Event Data Model (EDM) [1,2]. From the very beginning, it has been intended to assist with physics analysis, trigger performance monitoring and evaluation, reconstruction algorithm development, and to facilitate development and debugging of detector geometry description. Every CMS physics collection can have a plugin that produces representation of physics objects in graphical views. The plugins are typically simple 100 line C++ sources that access EDM data and create new elements for a graphical scene. A screenshot of Fireworks application is shown in Figure 1.

Event Visualization Environment EVE as a base
After CMS reimplemented its software framework and data formats in 2007 a need arose also for a new event display application. At that time ROOT's Event Visualization Environment (EVE) [3] was chosen as the base. EVE was fully integrated with ROOT and it also provided most of the components required for any physics event display, enumerated below.

Track propagation:
• magnetic field representation; • track propagation through a set of points with given track parameters.
2. Projected views supporting nonlinear projections: • nonlinear scaling; • runtime distortion; • overlay guides like coordinate axes and energy scale legends. 3. A wide range of elements used to represent physics objects in 2D and 3D scenes: tracks, points, digit sets, calorimters, jets, etc.
4. Window management: it was possible to easily create OpenGL views, undock them, or rearrange them in complex layouts.

Motivation for change
It has been more than 10 years since EVE framework has been developed. ROOT GUI and OpenGL components are even older and have by now really started to show their age. Furthermore, there is an increasing number of issues with the system level support for local and remote OpenGL. OpenGL API is being deprecated in favor of Vulkan (supported on Android, Linux, and Windows). Apple has even announced OpenGL deprecation in OSX-10.4 in favor of proprietary graphics API Metal. Another motivation to implement web-based event display was the fact that ROOT is moving to a web-based graphical interface. This is part of the ROOT project modernization branded as ROOT-7. While the full release is planned for the future, existing features are shipped with normal ROOT releases, enabling an easy start for web-based EVE module. An important component for this development is an embeddable http server that also supports usage of web sockets. The client side of web-based ROOT interface is named JSROOT [4,5]. Its features include: • mechanism to instantiate client windows and subwindows; • integration of OpenUI5 GUI toolkit; • simple structure to construct GL scene and navigate a camera; • support drawing TGeo geometrical shapes.

Web-based Event Visualization Environment EVE-7 3.1 Modernization approach
Most of the functionality existing in EVE module can be simply reused on the server side. All elements representing physics objects are created on the server side. Magnetic field representation, track propagation system, and non-linear projections are reused without change. The life cycle management of EVE elements, views, and scenes stays basically the same as in the old implementation but requires some extensions to support server-client object synchronization.
The client side of EVE naturally extends JSROOT (a client side of ROOT-7) framework. In current prototype, we added a highlight / selection system across different views that also supports compound objects. At this stage, we have not yet implemented the window management functionality available in EVE. To test scene updates we have implemented graphical editors for EVE elements where each element type has a minimalistic definition of widget type and stubs required for sending method invocation requests to the server side.

Server-client communication
The server can send content to the client in text or binary format. Rendering information of scene elements is sent in binary format. This includes vertices, polygons indices, normals, and transformation matrices. All other data is sent in text format using nlohmann::json package [6].

Client connect
When a new client connects to a server all the scenes are streamed and sent to the client. This is a limitation of the prototype: when window management is implemented, the client will receive only the scenes from the viewers it subscribes to. For each scene a core text (typically this is nlohman::json object dumped into a flat string) information is sent first and then the binary.

Scene changes
In the current prototype element editors are auto generated based on their class type (example of REveJetCone editor is shown in figure 2). When a value inside a widget is changed by the user a method invocation request (MIR) is sent to the server. Below is a fragment of the javascript code: sendMethodInvocationRequest : function(value, event) { var mir = event.getSource().data("myData").srv + "(" + value + ")"; var obj = { "mir" : mir, "fElementId" : this.editorElement.fElementId, "class" : this.editorElement._typename }; this.mgr.handle.Send(JSON.stringify(obj)); } The server invokes the method requested by the client and collects element changes into change information buffers held by each scene. Here is the list of currently supported element changes and the package content sent to the client in each case: visibility: element ID, element and children visibility flags.
color: element ID, color and transparency attributes.
complete rebuild: element ID, core data and render data data.
Element additions and removals are also part of scene change updates. The new elements are streamed in the same way as when the client first connects to a server (core data as JSON, render data in binary format). When elements are removed only element indices are sent.

Physics collections in EVE-7
Original EVE package has no support for management and display of experiment-specific physics collections. EVE objects were always just a visual representation of physics objects. During development of Fireworks we saw that access to physics collections and their contained physics objects are essential to the ability of the event display to offer the user full interactivity with the experiment data model. For this reason we have decided to implement this functionality in EVE-7 from the very beginning, relying on capabilitis of ROOT Cling and C++ lambda expressions. Some immediate benefits are: • the ability to provide filtering of physics objects on the level of physics collections, and • the support for table views with arbitrary, user specified expressions for each column.
A collection of TParticle objects shown in all supported views is presented in figure 3.

Dynamic tables
Example of an EVE-7 table is shown in figure 4. It is possible to edit the table properties at runtime, including changing of the assigned physics collection. The column contents can be modified by editing the C++ expression applied to every object in the collection. New columns can also be created from the GUI.

Migrating Fireworks from EVE to Web EVE
Fireworks will continue to keep its primary role as a physics analysis oriented event display. From EDM event data the same minimally changed plugins will construct EVE elements and register them to EVE scenes for display and further processing, e.g., automatic transformation for projected views, or propagation of tracks through a set of given markers. Removing the TVirtualX dependency will be the first effort in the migration. The OpenUI5 [7] controls will be used instead of the ROOT GUI toolkit to access and control event navigation, filtering and physics collection content.
Some parts of Fireworks will be replaced with functionalities now available in EVE-7 and OpenUI5. For example, physics collection implementation is already existing in EVE-7 and custom TVirtualX implementation of tables will be replaced by OpenUI5 tables.

Conclusion
The exploratory work presented in this paper has reassured us that web-based event display is an attainable solution for the next decade. CMS is committed to supporting development of EVE-7 and modernization of Fireworks as it remains the official physics analysis oriented event display application for Run-3 of the LHC and for the High Luminosity LHC.
The proposed work plan is to evolve EVE-7 to a level where the majority of basic features are supported and then port a subset of Fireworks to EVE-7. Afterwards, as more advanced features are being implemented, development of EVE-7 and Firworks-Web can proceed in lock-step, especially for visualization of digits, calorimeters, and particle flow objects. In parallel, required optimizations will be implemented on server and client side as as well as in the server-client communication protocol.