Alan Guégan

Benoît Rafine

Laurent Descombes

Hanane Fadiaw

Pierre Marty

Philippe Corrignan

Romain Le Nena

Alan Guegan
email: alan.guegan@sirehna.com

Compliance matrix model based on ship owners' operational needs

Keywords: compliance matrix, requirements management, operational scenario, system architecture, microservices

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Shipbuilding industry products are typically associated with large investments corresponding to one or several specific operational needs. Thus the maritime mode of transport does not benefit from the economy of series production and design studies are made on purpose for each ship. In this context, shipyards and designers shall be able to deliver, in a limited time, a ship design driven by a global trade off among operational requirements and constraints (rules, life-cycle cost, environmental impact…).

In addition, naval architects are facing increasingly complex ship designs and operations. This new challenge is induced by:  New technical missions often assigned to one single multi-purpose ship in order to reduce costs  Increased interactions between external and internal assets of various types and sizes (onshore communication centres, surrounding ships and aircrafts, UAV, USV, UUV, satellites, etc).  Integration of complex sub-systems with a high technology level and high connectivity or modularity.

Novel design methodologies have been introduced, some of which are reviewed in [START_REF] Andrews | State of the art report on design methodology[END_REF]. The HOLISHIP project addresses these challenges by developing systems engineering methods associated with numerical modelling and simulation tools. The final output of the project will be a software platform that enables naval architects to manage system complexity and reach a balanced design that takes into account all life cycle requirements (technical and cost).

This paper focuses on the System Architecture and Requirement management tool, the goal of which is to provide a general structure for managing system design and ensuring that customer requirements are satisfied. Requirements that are transverse to several subsystems and technologies are the main point of focus and should benefit the most from the tool being described here, as compared with local, subsystem-specific requirements.

First, the design method is described. Whereas in textbook approaches requirements are assigned to physical equipment, here requirements are assigned to operational scenarios. Guidelines are provided on how to describe scenarios in an efficient way, and a method to describe system architecture in a comprehensive way is introduced. Then, the procedure to link requirements with scenarios and eventually physical equipment within the architecture is described. This procedure consists of building "communities of interest" made of design artifacts of heterogeneous nature, such as architectural blocks, operational scenarios and requirements.

Once the method has been described from a theoretical point of view, the practical nature of ship design is discussed and a software tool is described. By essence, ship design is iterative and involves multiple technical domains. The data flow during the design is heterogeneousstructural design, electrical design, hydrodynamics, etc. are all addressed simultaneously -and asynchronous since design decisions in a domain have impacts on any other technical domain that are difficult to anticipate. Software architectures have emerged in the past few years that excel at managing heterogeneity and asynchronicity. The approach described here acknowledges these two aspects of ship design and builds on state-of-the-art software architectures to address them. After a brief introduction to service-oriented and "microservices" architectures, their application to the development of a requirements management software is described. Eventually, the application of the tool to a test case is discussed, with a focus on compliance assessment.

Ship design driven by operational scenarios

Customer needs and operational scenarios

The design of a ship is driven by the future operational needs of the ship owner and by ship design regulations. The customer specification translates operational needs into technical requirements, e.g. "maximum ship speed shall be at least 20kts", or "ship stability shall be preserved if 3 consecutive compartments are flooded".

The common practice in naval architecture is to allocate these requirements to the various subsystems aboard the ship, complementing them with know-how and technical constraints such as manufacturing limitations of the shipyard. The compliance of the design to the requirements is evaluated and eventually demonstrated to the customer by means of technical analyses, numerical simulations, controls and tests.

Practically, acceptance tests for operational requirements are achieved by running scenarios that mimick actual operational situations with the vessel. In a sense, operational scenarios are at the beginning and at the end of the design and manufacturing process. In the course of the design, operational scenarios are broken down into a list of supposedly independent operational requirements that can be managed by independent design teams (engine, structure, hydrodynamics, fluids, and so forth).

When it comes to designing or refitting multi-purpose, energy-efficient, cyberproof ships, the requirements are strongly interdependent and the "breakdown" approach finds a limit. Heterogeneous yet interdependent requirements have to be managed together, as a whole rather than as a list of separate items. The common denominator of each group of requirements is the operational scenario to which they contribute. The method described in this paper uses operational scenarios rather than technical requirements as the main drivers for the design. In the best case, operational scenarios are written together by the future ship owner and naval architects, otherwise the design teams reconstruct the scenarios from the requirements they have in the specification. This method has consequences for the tools and the governance of the design, that leave room to iterations and bottom-up contributions.

Operational scenarios are defined in IEC (2011) as "Description of an imagined sequence of events that includes the interaction of the product or service with its environment and users, as well as interaction among its product or service components." More specifically, the following rules for writing scenarios have been applied in this paper: • a scenario shall describe a single sequence of eventsoptions, alternative or "branched" scenarios are prohibited, • a scenario is a description and shall be written in the present tense -the use of "shall" or the conditional tense are prohibited, • prerequisites and initial state are clearly identified (e.g. ship configuration, environmental conditions), • final state is clearly identified as well (e.g. ship sails at cruise speed), • events are described in a chronological order with all relevant stakeholders, environmental conditions, operating modes of the ship and its subparts, etc., • measurable values are given whenever needed, • the description has enough details so that the scenario can be "replayed" (with the actual vessel or by simulation).

Ship design :Product design and Functional design

A ship may be seen both as a product, in the sense that it is an assembly of components and physical artifacts of all kinds, and as a system that delivers services and performs functions. The challenge with complex shipsand complex systemsis to understand and manage the behaviour of the many components of the system as they work together, otherwise called emerging behaviours.

At the intersection between the "component" view and the "functional" one are the multiple interfaces between the components of the ship. It is because components have been connected (physically) that they can interact and generate emerging behaviours. In the most recent ships, for instance, the machinery (engine, energy production), the payload (cranes, ROV or helicopter facilities), the navigation instruments (radar, gps) and communication systems (VHF, AIS), the onboard networks, etc. are all interconnected.

In the following, the functional interfaces between the subsystems of the ship are mapped with system architecture diagrams (see [START_REF] Guegan | A Systems Engineering approach to ship design[END_REF]). The top-level diagram of a multi-purpose surveillance vessel is given in Figure 1. The subsystems (or "blocks") are displayed as ellipses and their physical interfaces (their "links") are represented by solid lines. A line connecting a lower-level subsystem, e.g. "Ship Management System" (SMS), with the higher-level system it belongs to, e.g. "Ship", is a shortcut for "SMS is ubiquitous and connected with many components within Ship". Each "block" may be expanded to reveal its subcomponents (sub-blocks): the hierarchy of blocks provides a Product Breakdown Structure (PBS) of the ship system.

Linking customer needs and ship design

The ship owner and the design team have shared interests in delivering a ship that best fits the operational needs. As stated in paragraph 2.1, the operational needs are expressed in terms of technical requirements in the customer specification. The actual life of the ship in operation is described in operational scenarios. The system architecture of the ship is described with system architecture diagrams (paragraph 2.2).

In current design approaches technical requirements are allocated to individual blocks within the PBS. This is perfectly fine for a number of "local" requirements specific to some subsystems such as for instance safety communication devices on the bridge. However, when requirements that involve several blocks are refined into requirements specific to a single block each, the transverse nature of these requirements is lost in the process, making it difficult to address emerging behaviours and strongly coupled interactions. By contrast, in the approach described here requirements are allocated to the relevant operational scenarios, and then the list of all the blocks that contribute to any given scenario is drawn (Figure 2). The requirements and blocks that are linked to a given scenario may be seen as a "community of interest" whose members are interdependent. The main advantage of this approach is that transverse requirements or emerging behaviours are addressed globally within the scope of each operational scenario, rather than locally at the level of each component independently from its neighbours. In Figure 2, Max/Min speed, Dynamic Positioning accuracy, payload capability, etc. are addressed simultaneously to find a global trade-off in the design of the machinery, bow thrusters, ship management system, etc.. Adjustments to current engineering practices may be needed to take full advantage of the concept of "community of interest". In this approach engineers are invited to participate in a design debate, to build a consensus around a technical solution that satisfies operational needs, rather than designing their own subsystem according to a predefined list of requirements with little consideration for the overall optimumarguably guaranteed by the a priori requirement refinement and allocation process.

Paragraph 3 builds on the most recent progress in software architecture to propose a software tool that supports the "community of interest" approach, in the view of filling up a comprehensive compliance matrix.

Ship design managed by "communities of interest"

Ship design: heterogeneity, asynchronicity, iterations

As for most industrial systems, a ship is composed of multiple subsystems that implement various technologies. The goal of the design process is to reach a balanced design in which all the technologies onboard work together smoothly while satisfying criteria such as, e.g. general arrangement consistency, ship stability, fire safety, Electro Magnetic Compatibility,... The main challenge in the design process is to coordinate inputs from a large number of specialists, regarding several heterogeneous technical domains. Since subsystems share a lot of interactions, the design process is iterative by nature: the behaviour of every subsystem in its environment cannot be defined a priori, and the design proceeds by consecutive adjustments. In the general case, design processes have well-defined, synchronized milestones that take into account their iterative nature. Still, technical inputs are generated on a daily basis, following the work of the many engineers involved; the flow of technical information produced during the design process is asynchronous by essence. The goal of the HOLISHIP project is to develop methods and tools to address these issues with improved efficiency.

Managing heterogeneous, asynchronous inputs within iterative processes has been a big concern of the software community in the past few years. Some software architectures are particularly well suited for this purpose, among which the so-called "Microservices" approach used, e.g. by Netflix® (see [START_REF] Newman | Building Microservices[END_REF]). The prime goal of Microservices is to parallelize software development by ensuring that the services and their several instantiations can be deployed independently. The principle is that context-bounded software "services" cooperate in a distributed framework that ensures a consistent output from the asynchronous contributions of all. Heterogeneity in the types of services provided is encouraged to provide the richest possible service to the end-user.

It might seem puzzling that software principles invoking independently deployable services might be of interest to solve the issue of transverse performances of ships. The reader is advised that, although Microservices supporters emphasize the independence of its components, the overall consistency of the services provided by the software to the end-user is never lost from sight. End-user (global) experience is a key driver of the design. It is monitored and managed in a variety of ways depending on companies, but it is the ubiquitous reference to assess the developments implemented within each individual service. Microservices software architectures are indeed very close to system architectures: in both cases the development of each component is assigned to specialized teams (electricity, machinery, etc. for a ship vs video streaming, community management, etc. for a web application software for instance), while the overall consistency of the service provided (ship speed and range vs video quality and response time, for instance) is guaranteed by the constant focus on the customer needs (operational scenarios, vs user experience "epics").

The following sections describe how Microservices technologies can be used to implement a software tool for ship design. The tool is designed as a platform that allows "communities of interest" (see 0) to emerge and develop around each of the future ship owner's operational needs; heterogeneity, asynchronicity and iterations are managed within each community of interest with the help of microservices technologies which principles are described in the following section.

A Micro-services-based software tool for ship design

The architecture of the design management tool is sketched in Figure 3. Requirements, Operational scenarios and Blocks from the system architecture diagram are managed with three separate tools (rectangles) that come with their own independent databases (cylinders). Each tool with its database is an independent context-bounded service.

Communication between services is performed in two different ways. Services can either exchange data by a standard request / response process, or share notifications with a publish / subscribe process (arrows). For the latter, the common practice is to implement a Message Queue (MQ) service. Each service is free to subscribe to notifications from other services; the role of the MQ is to dispatch the notifications from one service to the others, according to the subscription list.

When the amount of data is small enough, the notification sent through the MQ can embed all the information about the event (e.g., when a scenario is updated, the text of the scenario can be sent along with the notification). When the event involves larger amounts of data (e.g. when a whole set of scenarios has been imported from a previous project), the event is notified through the MQ but the services that need it exchange data outside the MQ, with a request / response process. This implies that the services that communicate know the addresses of one another. It is the role of the Service Discovery to return a list of all available services and their addresses upon request. This service is vital to the Microservices architecture since the list of available services is in constant evolution, whether new services are created, others are shut down, or overloaded, or moved to a new server, etc. The features above define an event-driven, service-oriented software architecture. Since the services involved are loosely coupled and limited in their scope (essentially, the management of one list of items each), it is fair to call it a Microservices architecture.

Before analyzing the way this architecture works, it is worth introducing the Subscription tool service. Communities of interest are created when the design team makes relevant associations between blocks, scenarios and requirements. The subscription tool enables the designers to select one item, say block B003, get the list of scenarios or requirements it has subscribed to, and update this list. To do so, the subscription tool uses the service discovery to know which items are managed by the services that are currently running; then, the subscription tool calls each of these services separately to know which items can be subscribed to, which subscriptions have already been registered, and to request updates when necessary. An example might be useful at this point. Data transfer is illustrated with grey lines in Figure 3. Let us assume that, for some reason, scenario S003 has been updated by the design team. The update results in a change in the database of the scenario management tool; a notification is sent to the MQ (double-headed arrow) that S003 has been updted. The MQ propagates the notification to the services that had subscribed to "scenario update" notifications, namely the architecture diagram and the requirements management tools (solid grey lines). Other, non-subscriber tools like Service Discovery are not informed.

Upon receipt of the notification the architecture diagram tool sends an alert to blocks B002,03,04,10,11,12 that had previously subscribed to "scenario S003 update" notifications. These blocks are highlighted in the diagram as displayed in the graphic interface of the System Architecture Diagram tool, which allows the designer of block B004 to 1/ acknowledge that S003 has been changed (notification process, dashed line) and 2/ if there is more information about the event than the one provided by the notification, send a request for additional information to the scenario management tool (request / response process, dotted line). This basic architecture offers enough features to test the scenario-driven design method described in section 2. Yet it is worth to mention that it has a strong potential for evolutivity, like the implementation of other services dedicated to different aspects of ship design. It has already been planned to connect this tool and the simulation platform developed in the HOLISHIP project, in order to enable traceability between system architecture, requirements, scenarios, and ship performance simulations. Section 3.3 provides an example of how this tool can be used to guide the design of a multi-purpose surveillance vessel. The design tool is tested on a pollution-fighting scenario relevant to this kind of ships. An additional focus is given on compliance assessment and the construction of a compliance matrix that matches the customer expectations while extending the scenario-oriented approach.

Compliance assessment with the compliance matrix : use case

In the upcoming example, the future owner of the ship requests a pollution fighting capability. The requirements listed in Figure 2 are an excerpt from the customer specification.

The following scenario (Figure 4), inspired both by experience acquired during the design of previous ships and by the specification from the customer, describes a meaningful operational context to analyse the requirements. The description of the scenario includes more information than the original specification. The goal is to remove any ambiguity from the specification and to provide a complete description of ship operation that can be shared with the customer to improve common understanding.

In most cases, the designer has a portfolio of several other ships with similar operating profiles. This is a source of inspiration for writing the scenario and also for initializing the design. Starting from a similar, existing design (the reference design), the designer draws the ship system architecture diagram displayed in Figure 1a.

The designer knows from the reference design that the following blocks are involved in scenario S003 : B002,03,04,10,11,12. Together with requirements R001,2,4,5,8 and scenario S003, they form a "community of interest" (Figure 2) regarding the pollution fighting capability of the vessel. Video management is one example of a deviation from the reference design. The customer described in more detail what he expects during ROV operation, with the requirement R005.17 (Figure 2) that had never been encountered previously by the design team.

In the design management tool, requirement R005.17 is pointed out as an "orphan requirement" that has not subscribed to any scenario. The design team decides to: 1/ amend scenario S003 to incorporate R005.17 (the final version of the scenario is given in Figure 4, with R005.17 in bold font), 2/ subscribe R005.17 to S003 : R005.17 is now traced to S003 and enters the compliance demonstration workflow.

Compliance demonstration starts at system architecture level. All the blocks that have subscribed to S003 receive a notification that a new requirement called R005.17 has subscribed to S003, and that S003 has been updated. The subscribing blocks, including B012 Modular Deck Equipment, send a request to S003 to evaluate the impact the update might have. B012 is the source of the video thread from the ROV, and it has a high chance of being impacted. Thanks to the notification the designer is aware that the role of B012 with respect to requirement R005.17 needs to be investigated.

The architecture diagram in Figure 1b shows that there is no connexion between the bridge and block B012 Modular Deck Equipment: the modular ROV system is unable to communicate with the bridge. The designer finds a way to satisfy requirement R005.17 by connecting B012 with the onboard network and implementing changes in the bridge and onboard network in terms of software and hardware. The designer updates the architecture diagram accordingly, as shown in Figure 5. In a similar fashion as for the update in scenario S003, changes in the "onboard network" block and the "bridge" block are notified to the neighbouring blocks in the diagram, and to all the scenarios these blocks have subscribed to through the design management tool described in section 3.2.

In the above example, the changes will most probably not propagate beyond the network and the bridge blocks. In more complex cases, though, a single update in a requirement might trigger a cascade of changes across the system, the scenarios and even the requirements (in case of inconsistent requirements, for instance). The design management tool described here provides a support to help the designers of the ship manage these otherwise uncontrollable interrelated design changes.

Eventually, the tool may be used to build a complete and consistent compliance matrix, with clear traceability with the design of the ship. An extract of the compliance matrix is provided in Figure 6. The matrix reads from left to right: "requirement R001 / is requested for performing scenarios S001 & S003 / the design is 100% compliant within both scenarios / alert: scenario 1 has changed since last assessment / see comments to evaluate impact". The design management tool is useful to fill in the fourth columnscenario changed / unchanged. The novel approach based on "communities of interest" centered around a few operational scenarios makes it much more unlikely that a change in the requirements or in the design goes unnoticed in the compliance matrixespecially so in collaborative engineering environments.

Consistent and provable traceability between the compliance matrix and the design is often difficult to achieve, due to the conceptual and technical heterogeneity between design tools and requirements management tools. The design management tool described in section 3.2 overcomes this difficulty, however the tool is still at a "Proof-Of Concept" maturity level. One of the remaining challenges is to develop a robust, stable and appealing software tool that could be deployed for an actual project and demonstrate "in the field" the benefits of the approach for ship design. Testing the design management tool is one of the tasks foreseen in the HOLISHIP project.

Fig. 1

 1 Fig. 1 (a) Top-level architecture diagram of a Multi-Purpose Surveillance Vessel; (b) detail of the Ship Management System.

Fig. 2

 2 Fig.2The technical requirements (left) and the blocks composing the ship (right) are linked to the scenarios for which they are relevant (center). Together these elements constitute a "community of interest" around scenario S003 "Early response to pollution event".

Fig. 3

 3 Fig. 3 Architecture of the design management tool. Independent, context-bounded design and evaluation tools (left half of the sketch) are connected with a Microservices-inspired infrastructure (right: Message Queue, Subscription Tool, Service Discovery). An example data flow is displayed in grey lines.

Fig. 4 -

 4 Fig. 4 -Operational scenario "Early Response to pollution event". Requirements from the customer specification are underlined.

Fig. 5 -

 5 Fig. 5 -Updated architecture diagram of the Ship Management System. The update from Figure 1b consists in connecting the modular ROV equipment with the onboard network (dashed lines). ROV video is delivered to the crew at the bridge through the ship's own network (arrow).

Fig. 6 -

 6 Fig.6-Compliance matrix extract for requirements R001 and R005.17. Requirements and design changes are monitored with the help of the design management tool described in section 3.2.

Acknowledgements

This project has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement n° 689074.


Bertrand Maury
email: bertrand.maury@math.u-psud.fr

Sylvain Faure

Jacques Angel É2

Rémi Bachimont

A Time-continuous Compartment Model for Building Evacuation

Keywords: modeling, human behavior, risk assessment, evacuation times, exit capacities

We propose here a general framework to estimate global evacuation times of complex buildings, and to dynamically investigate the dependence of this evacuation time upon various factors. This model relies on a network, which is in some way the skeleton of the building, the nodes of which are the bottlenecks or exit doors. Those nodes are connected by edges which correspond to portions of egress paths located within a given room. Such models have been proposed in a discrete setting. The model we propose takes the form of a continuous evolution equation of the differential type. It relies on a limited number of variables, namely the number of people gathered upstream each node, together with the number of people on their way from a node to the next one. The basic parameters of the model are the capacities of doors, and the time needed to walk from one node to the next one. In spite of its macroscopic character (the motions of pedestrians are not described individually), this approach allows to account for complex and nonlinear effects such as capacity drop at bottlenecks, congestion induced speed reduction, and possibly some dispersion in evacuees behaviors. We present here the basic version of the model, together with the numerical methodology which is used to solve the equations, and we illustrate the behavior of the algorithm by a comparison with experimental data.

Introduction

Providing accurate and robust estimates for evacuation times in complex buildings is a long-term challenge in public safety. A common dilemma resides in the opposition between microscopic and macroscopic approaches. Microscopic descriptions (see e.g. [START_REF] Helbing | Pedestrian, Crowd and Evacuation Dynamics, Encyclopedia of Complexity and Systems Science[END_REF][START_REF] Maury | A discrete contact model for crowd motion[END_REF][START_REF] Schadschneider | Empirical results for pedestrian dynamics and their implications for cellular automata models[END_REF] allow for a precise description of evacuees interactions, possibly accounting for non uniformity of individual behavior (social tendencies, speed, . . . ), but they lead to higher, possibly prohibitive, computational times. Besides, they call for an accurate knowledge (at least statistically) of people characteristics, which is most of the time out of reach. On the other hand, macroscopic models ( [START_REF] Hughes | A continuum theory for the flow of pedestrians Transportation[END_REF][START_REF] Maury | A macroscopic crowd motion model of gradient flow type[END_REF]) handle the crowd as a continuum, represented by a local density. The evolution of this density typically follows a conservative transport equation which expresses the "people conservation", and the core of the model lies in the manner the effective velocity is determined, based on individual tendencies and local density. This approach makes it possible to account for very large number of people at a reasonable computational cost. Yet, most models of this type are not able to reproduce some observable effects, like the Faster-is-Slower effect ( [START_REF] Garcimartín | Experimental evidence of the"Faster Is Slower" effect[END_REF]), the Capacity Drop phenomenon ( [START_REF] Cepolina | Phased evacuation: An optimisation model which takes into account the capacity drop phenomenon in pedestrian flows[END_REF]), or the fluidizing role of an obstacle ( [START_REF] Zuriguel | Effect of obstacle position in the flow of sheep through a narrow door[END_REF]). Both approaches rely on a fine description of the behavior of individuals and their interactions with neighbors (finite number of finite-size individuals for the microscopic setting, infinitely many point particles for the macroscopic setting).

If one aims at predicting the evacuation time of complex building, it may be of interest to use a coarse grain description of the crowd, based on quantities that are directly observable and measurable. This approach, which we may call systemic, is based on a decomposition of the building into various compartments, corresponding to distincts areas (like rooms, halls, or corridors). Those compartments are connected by doors, and the balance of global headcounts in compartments is driven by fluxes between them. The model we propose here is based on a network defined as follows: the nodes of the network are the exits of the various compartments. Each compartment has a certain number of entrances, each of which is the exit of an compartment upstream. Each entrance of a given room is connected by an oriented edge to the exit. We shall follow the convention that the exit points to the entrances, in such a way that the arrows (oriented edges) express a dependence relation. More precisely, a node i points to a node j if i is influenced by the situation of j (possibly in the past). The model which is presented here is not new in its constitutive principles. In particular the Capacity Constrained Routing Approach presented in [START_REF] Lu | Evacuation Planning: A Capacity Constrained Routing Approach[END_REF] is based on the same type of network. The same type of model is also proposed in [START_REF] Daganzo | The cell transmission model: network traffic[END_REF] to represent car traffic networks. The main novelty of the approach lies in the nature of the model, which is continuous in time, whereas previous approaches were essentially discrete. This continuous character gives a sound theoretical character to the approach, which can be used in particular to design rigorous methodologies for parameter identification. It also makes it possible to tune up the time step, which is in our setting a discretization parameter, depending on the situation which is considered.

While allowing for faster-than-real-time computations, the large granularity of the description level a priori rule out the possibility to properly describe small scale interactions between individuals, and this model may not be used to investigate in any way the cause of the aforementionned phenomena. Yet, the most relevant parameters (in particular capacities and node-to-node travel time) can be made dynamic, and allow for an account of phenomena like the Capacity Drop, or the reduction of the walking speed in case of congestion.

Model description, mathematical formulation

Let us start with a toy problem: A certain quantity of people is accumulated upstream a single exit door. Since we aim at setting a continuous model, applicable to large numbers of entities, we represent this quantity by a real number N ∈ R + . The capacity of the exit, that is the maximal number of individuals which can go through it per unit time is denoted by C. We denote by f = f (t) ≥ 0 the incoming flux, that is the upstream flux of pedestrians, and by Φ = Φ(t) ≥ 0 the instantaneous flux through the door. The incoming flux is assumed to be known. The balance at the door writes dN /dt = f -Φ. The core of the model relies in the expression of Φ as a function of the dynamic variables N , f , and the static parameter C. By definition of the capacity it holds that Φ ∈ [0, C], and Φ = C whenever N > 0. When N = 0, Φ lies between 0 and C. Its value is f when f < C, but it may happen that Φ saturates to C if f > C. To sum up, the evolution problem can be written

             dN dt = f -Φ Φ = C if N > 0 arg min Φ∈[0,C] Φ -f if N = 0 (2.1)
The extension to a many-room building is built in a similar manner, by accounting for the fact that people flowing through some passage node reach the next one after some transit time which is a parameter of the model. We denote by R the number of room / compartments, m i the number of inlet accesses to room i. For n = 1, . . . , m i , we denote by α n i the index of the room upstream the access n to room i. The time spent by an individual to walk (in room i) from entrance n to the exit is T n i . Finally, Φ i is the instantaneous flow rate of people through the exit of i. The problem writes

dN i dt = -Φ i + m i n=1 Φ α n i (t -T n i ) , i = 1, . . . , R, Φ i = C i if N i > 0 arg min Φ∈[0,C i ] Φ - m i n=1 Φ α n i (t -T n i ) for i = 1, . . . , R.
(2.2)

Numerical solution

In spite of non-trivial mathematical issues (see [START_REF] Maury | Crowds in Equations[END_REF]), designing numerical algorithms to solve this sort of problems is straightforward. Let τ > 0 denote a time step. To simplify the presentation, we shall assume that the transfer times are whole multiples of this time step, and denote by Ti = T i /τ ∈ N the corresponding dimensionless times. We shall furthermore assume that people are initially gathered in the neighborhood of exits. The approximation of N i at time t k = kτ is denoted by N k i .

The scheme is actually simpler than the continuous model, since it simply expresses that, at some time t k , the number of individual walking through exit i between t k and t k+1 is C i τ whenever there is enough people available to achieve this full capacity, and N i otherwise. In other words, the average flux in this time interval is either

C i or N i /τ . Φ k+1 i = min(C i , N k i /τ ) , i = 1, . . . , R, N k+1 i = N k i -τ Φ k+1 i + m i n=1 τ Φ k+1-T n i α n i , i = 1, . . . , R, (3.1)
where Φ k i is set to 0 for all k < 0 (no evacuation before the initial time), and R is the number of rooms. Assuming, as we did in the continuous setting, that all people are initially gathered upstream doors, we supplement this system with initial conditions N 0 1 , . . . , N 0 R . We may add an extra equation to keep an account of people who have evacuated the building at time k:

N k+1 0 = N k 0 + τ Φ k+1 1 .
N k+1 i,n = N k i,n + τ Φ k+1 α n i -τ Φ k+1-T n i α n i .
Global people balance is straightforwardly obtained by summing up all discrete equations:

N k 0 + R i=1 N k i + R i=1 m i n=1 N k i,n = Constant.

Illustration: comparison to experimental data

The model is tested in the configuration presented in [START_REF] Chen | Experimental Study of Evacuation from a 4-storey Building[END_REF], were a full set of experimental evacuations is presented. The topography is represented in Fig. 3.1 (left): it is made of 10 interconnected compartments. The underlying oriented network is represented on the left-hand side of the figure. Transit times are automatically computed as follows: the common target is defined as the gate upstream thestairs, denoted by 2 on the figure. The geodesic distance to the target, which corresponds to the length of the shortest path (accounting for walls and obstacles) to the target, is quasi-instantaneously computed by mean of a fast marching algorithm. More precisely, distances are computed at the center of cells of a cartesian grid which covers the whole domain, in a frontal way, starting from the target where is it set at 0, and then propagating backward upstream the domain. We refer to [START_REF] Maury | Crowds in Equations[END_REF] (Chapter 8) for methodological and implementational details concerning those computations. The travel times are computed from those distances by setting the speed of pedestrian at 1 m/s. Isolines of this geodesic distance is represented in Fig. 3.1 (middle). To illustrate the evacuation, we also represent some egress paths computed with a microscopic model ( [START_REF] Maury | A discrete contact model for crowd motion[END_REF]), based on an initial random distribution of individuals (Fig. 3.1, right).

The time needed to get from one node to the other can then be computed as the difference between the geodesic distances divided by the speed of pedestrians. The initial number of individual is 86, distributed over the rooms 2 to 10 (circled black indexes in Fig. 3.1, left). The headcount in each room is indicated by the numbers in red. The effect of various gate widths have been experimentally studied, and we reproduce with the present model the two scenarios, referred to as scenario 4 and scenario 5, respectively, like in [START_REF] Chen | Experimental Study of Evacuation from a 4-storey Building[END_REF]. In scenario 4, the exit gate is wide open (1.24 m), and the corresponding capacity is estimated at 2.78 Ps -1 . In scenario 5, the door is reduce to half its width (0.62 m), with a capacity of 1.72 Ps -1 . We run the numerical model is both situations, and we illustrate the results by representing the computed number of people gathered upstream the exit gate versus the time. Fig. 4.1 represents the plots in the two scenarios. The model makes it possible to recover the "state" of this sensitive point when the evacuation time goes on. As expected (see the figure at the top), this number first decreases. Then, around time 8 s, people coming from upstream rooms start to reach this node. The gate continues to work at full capacity, but the incoming fluxes are higher, which explains the increase. The little irregularities on the curve between times 8 and 17 corresponds to instants at which the first people coming from some given upstream room reach the gate node. Then, in a final phase (after time 25), all people still in the building are gathered at the gate, and the crowd flows out at full door capacity. The second plot corresponds to a smaller capacity: the initial decreasing phase is less efficient, then, in the second phase, the slope is higher (the incoming flux is the same as previously, but the outflow smaller). We recover, like in the experiments, a larger evacuation time, around 50 s, to compare to the 32 s of Scenario 4.

Figure 3 . 1 :

 31 Figure 3.1: Topography: network, geodesic distance to the gate, and typical paths

Figure 4 . 1 :

 41 Figure 4.1: Computed number of people gathered upstream the exit gate vs. time, for scenarios 4 (top) and 5 (bottom)


Imen Akrouti

AND Hatem Baloudi

Aref Jeribi

THE 2-DIMENSIONAL ADJACENCY MATRIX

Keywords: 2010 Mathematics Subject Classification. 05C12, 05C63, 47B25, 81Q35 Simplicial complex, spectral graph theory, infinite graphs. 1

Introduction

In the last few years, the question of the essential self-adjointness of discrete Laplacian acting on graph drew a lot interest, see for instances [START_REF] Milatovic | Essential self-adjointness of magnetic Schrödinger operators on locally finite graphs[END_REF][START_REF] Golénia | Unboundedness of adjacency matrix of locally finite grphs[END_REF][START_REF] Baloudi | The adjacency matrix and the discrete Laplacian acting on forms[END_REF][START_REF] De Verdière | Essential self-adjointness for combinatorial Schrödinger operators II, Magnetic fields[END_REF]. Graphs can be regarded as 1-dimensional simplicial complex. Simplicial complexes represent useful and accurate models of complex networks and complex systems in general. In this paper, we will focus on weighted triangulation as 2-dimensional complex such that all 2-simplexes are triangle. The concept of triangulation was investigated in [START_REF] Chebbi | The discrete Laplacian of a 2-Simplicial complex[END_REF][START_REF] Mukherjee | Random walks on simplicial complex and harmonics[END_REF] as generalization of graphs. We refer to [START_REF] Lim | Hodge Laplacians on graphs, Geometry and Topology in Statistical Inference[END_REF] for this point of view and applications to game theory and ranking. The weighted triangulation permits to define two discrete Laplacian: The 2-Laplacian ∆ 2 and the 1-Hodge Laplacian

∆ 2 := ∆ fu 1 + ∆ lo 1 ,
where ∆ fu 1 is the full Laplacian and ∆ lo 1 is the lower Laplacian. In the case of 1-simplicial complex, the weight of the 2-simplexes equal 0 and thus ∆ 1 = ∆ fu 1 . Recently, the 1-Hodge Laplacian was visited in [START_REF] Mukherjee | Random walks on simplicial complex and harmonics[END_REF]. The question of the self-adjointness was visited in [START_REF] Baloudi | The discrete laplacian acting on 2forms and application[END_REF][START_REF] Chebbi | The discrete Laplacian of a 2-Simplicial complex[END_REF]. More specifically, in [START_REF] Chebbi | The discrete Laplacian of a 2-Simplicial complex[END_REF], the author gives a relation between the geometric hypothesis for the triangulation and the self-adjointness for ∆ 1 and ∆ 2 . In [START_REF] Baloudi | The discrete laplacian acting on 2forms and application[END_REF], the authors give a criterion of essential self-adjointness using the Nelson lemma. In this paper, we continue the discussion of the question of essential self-adjointness for ∆ 1 and ∆ 2 . Note that the two Laplacian depends on the weight of vertices m, weighted edge E and weighted face F. Let d V be the degree of vertices and d E be the weight degree of edges, we refer to Section 2 for precise definitions. Thanks to [START_REF] Nussbaum | Quasi-analytic vectors[END_REF][START_REF] Masson | Classes of C ∞ vectors and essential selfadjointness[END_REF], we prove that ∆ 1 and ∆ 2 are essentially self-adjoint under some hypothesis on d V and d E . This hypothesis covers a certain book-like triangulation, see Section 4 for more detail. The article is organized as follows: In Section 2, we present general definitions about graphs and simplicial complex. Then we define two different types of discrete operators (The discrete 2-Laplacian and the 1-Hodge Laplacian). In Section 4, we provide a new criterion of essential self-adjointness for ∆ 1 and ∆ 2 using Stieltjes vectors approach. Finally, in Section 5 and 6, we apply the obtained results to investigate the question of essential selfadjointness for the book-like triangulation and the adjacency matrix.

Preliminary

2.1. Definitions on graphs. We star with some definitions and fix our notations for graphs. We refer to [START_REF] De Verdière | Spectres de graphes[END_REF][START_REF] Chung | Spectral graph theory[END_REF][START_REF] Mohar | A survey on spectra of infinite graphs[END_REF][START_REF] Jeribi | Spectral theory and applications of linear operators and block operator matrices[END_REF] for surveys on the matter. A weighted graph G is a triple (V, m, E) where V is a set at most countable whose elements are called vertices, E is a non-negative symmetric function on V × V and m : V -→ (0, +∞). We say that two vertices x, y ∈ V are neighbors if E(x, y) > 0. In this case, we write (x, y) ∈ E. In the setting of electrical network, E correspond to the conductances. We say that there is a loop in x ∈ V, if E(x, x) = 0. A graph G is simple if it has no loops and E has values in {0, 1}. The of neighbors of x ∈ V is denoted by

N G (x) := {y ∈ V : E(x, y) > 0}.
A graph is locally finite if ♯N G (x) is finite for all x ∈ V. The weighted degree of vertices is given by

d V (x) := 1 m(x) y∈V E(x, y). When G is simple, d V (x) = ♯N G (x). A graph G is connected, if for all
x, y ∈ V, there exists an xy-path, i.e., there is a finite set (x 0 , ..., x n ) ∈ V n such that x 0 = x, x n = y and E(x i , x i+1 ) > 0 for all i ∈ {0, ..., n -1}. The minimal possible n is denoted by ρ V (x, y) and called the distance between x and y. For simplicity, we assume that all graphs are locally finite, connected and have no loop. 2.2. Simplicial complex. Simplicial complex generalize the notion of a graph of higher dimensions. Let V be a countable set. Any nonempty subset σ ⊂ V of the form σ = {v 0 , v 1 , ..., v n } is called a n-dimensional simplex or n-simplex. A simplicial complex X is a collection of simplexes of various dimension that is closed under taking subsets; that is, for any set σ ∈ X and any subset Y ⊂ σ, we have Y ∈ X. Let X be a simplicial complex. We denote the set of n-simplexes of X as X n . We say that X is m-dimensional or that X is a m-complex if X m = ∅ and X m+1 = ∅. Graphs can be regarded as 1-dimensional simplicial complex.

2.3.

Triangulation. Let G := (V, m, E) be a weighted graph and let x, y ∈ V. The path γ is called a cycle or closed when the origin and the end are identical.

A cycle γ = {a, b, c} is called triangle if (a, b) ∈ E and c ∈ N G (a) ∩ N G (b).
Let Tr(G) the set of all triangles. Let F =Tr(G)/ ∼ where (x 0 , y 0 , z 0 ) ∼ (x 1 , y 1 , z 1 ) ⇐⇒ (x 1 , y 1 , z 1 ) ∈ {(x 0 , y 0 , z 0 ), (y 0 , z 0 , x 0 ), (z 0 , x 0 , y 0 )}.

Let F : V 3 -→ [0, +∞) such that F(x, y, z) > 0 ⇐⇒ (x, y, z) ∈ F and F(x, y, z) = F(z, y, x), (x, y, z) ∈ V 3 .
We say that T := (V, m, E, F) is a weighted triangulation with vertices V, weight of the vertices m, weighted edges E and weighted faces F. Remark 2.1. A triangulation is a 2-simplicial complex such that all faces are triangles.

We say that T is simple if G := (V, m, E) is simple and the weight of the faces equal 1. The set of vertices belonging to the edge (x, y) is given by

F (x,y) := N G (x) ∩ N G (y).
The weighted degree of edges is given by:

d E (x, y) := 1 E(x, y) z∈F (x,y) F(x, y, z).
When T is simple, d E (x, y) = ♯F (x,y) .

The 2-Laplacian and the 1-Hodge Laplacian on a triangulation

Let T := (V, m, E, F) be a weighted triangulation. Let C c (V) be the set of functions f : V -→ C with finite support and let ℓ 2 (V, m) be the set of function f : V -→ C such that

f ℓ 2 (V,m) := x∈V m(x)|f (x)| 2 < ∞.
is finite. Note that ℓ 2 (V, m) is a Hilbert space with respect to the scalar product

f, g m := x∈V m(x)f (x)g(x).
Let C c (E) be the set of skew-symmetric functions f : V × V -→ C with finite support and let ℓ 2 (E) be the set

   f : V × V -→ C skew-symmetric: 1 2 (x,y)∈E E(x, y)|f (x, y)| 2 < ∞   
We have ℓ 2 (E) is a Hilbert space with respect to the scalar product f, g := 1 2

x,y∈V E(x, y)f (x, y)g(x, y).

The set of 2-cochains or 2-forms is given by

C(F) = f : F -→ C : f (x, y, z) = -f (z, y, x) .
The set of functions with finite support is denoted by C c (F). Let us define the Hilbert spaces ℓ 2 (F) as the sets of 2-cochains with finite norm, we have

ℓ 2 (F) :=    f ∈ C skew (F) : f = 1 6 (x,y,z)∈F F(x, y, z) | f (x, y, z) | 2    .
The associated scalar product is given by f, g := 1 6

(x,y,z)∈F F(x, y, z)g(x, y, z)f (x, y, z).

The 1-Hodge Laplacian of T is defined to be

∆ 1 := ∆ fu 1 + ∆ lo 1
where ∆ fu 1 is the full Laplacian given by ∆ fu 1 f (x, y)

1 m(x) z∈V E(x, z)f (x, z) + 1 m(y) z∈V E(z, y)f (z, y)
and ∆ lo 1 is the lower Laplacian given by

∆ lo 1 f (x, y) := 1 E(x, y) z∈F (x,y) F(x, y, z)(f (x, y) + f (y, z) + f (z, x)) with f ∈ C c (E). The 2-Laplacian of T is defined to be ∆ 2 f (x, y, z) = 1 E(x, y) t∈F (x,y) F(x, y, t)f (x, y, t) + 1 E(y, z) t∈F (y,z) F(y, z, t)f (y, z, t) + 1 E( z, x) t∈F (z,x) F(z, x, t)f (z, x, t), with f ∈ C c skew (F).
Both of them are symmetric and thus closable, see [START_REF] Chebbi | The discrete Laplacian of a 2-Simplicial complex[END_REF]. We denote the closure by ∆ 1 (resp. ∆ 2 ), its domain by D(∆ 1 ) (resp. D(∆ 2 )) and its adjoint by ∆ * 1 (resp. ∆ * 2 ). Remark 3.1. In [START_REF] Baloudi | The adjacency matrix and the discrete Laplacian acting on forms[END_REF], in the case of 1-simplicial complex, we have F = 0 and thus ∆ 1 = ∆ fu 1 .

Essential self-adjointness

Let T = (V, m, E, F) be a weighted triangulation. The ball of radius n ∈ N * around a vertex o ∈ V is the set

B n (o) = {x ∈ V : ρ V (o, x) ≤ n}.
In [START_REF] Baloudi | The adjacency matrix and the discrete Laplacian acting on forms[END_REF], they prove that ∆ fu 1 is essentially self-adjoint on C c (E) when

+∞ n=1   i≤n sup x∈B i (o) d G (x)   -1 2n = ∞.
The technique of the proof is based on the Stieltjes vectors approach. In the following theorem, we adapt this approach for ∆ 1 .

Theorem 4.1. Let T = (V, m, E, F) be a weighted triangulation and let o ∈ V. Assume that

(1) ∞ n=1 n k=1 sup x∈B k (o) d V (x) + sup (x,y)∈B k (o) 2 ∩E d E (x, y) -1 2n = +∞, where B k (o) 2 = B k (o) × B k (o). Then ∆ 1 is essentially self-adjoint on C c (E).
Proof. Let n ∈ N and g ∈ C c (E). Then

g, 1 B 2 n (o)∩E ∆ 1 1 B 2 n (o)∩E g = 1 B 2 n (o)∩E g, ∆ fu 1 1 B 2 n (o)∩E g + 1 B 2 n (o) g, ∆ lo 1 1 B 2 n (o) g
By repeating the proof of [2, Theorem 6.15], we have

1 B 2 n (o)∩E g, ∆ fu 1 1 B 2 n (o)∩E g ≤ sup x∈Bn(o) d V (x). 1 B 2 n (o) g 2 ℓ 2 (E) .
Furthermore, we have

1 B 2 n (o)∩E g, ∆ lo 1 1 B 2 n (o)∩E g ≤ 1 6 (x,y,z)∈F F(x, y, z)|1 B 2 n (o)∩E (x, y)g(x, y) + 1 B 2 n (o)∩E (y, z)g(y, z) + 1 B 2 n (o)∩E (z, x)g(z, x)| 2 ≤ 2 3 (x,y,z)∈F |1 B 2 n (o) (x, y)g(x, y)| 2 = 2 3 (x,y)∈B 2 n (o)∩E E(x, y) 1 E(x, y) z∈F (x,y) F(x, y, z) × |1 B 2 n (o) (x, y)g(x, y)| 2 ≤ 4 3 sup (x,y)∈B 2 n (o)∩E d E (x, y). 1 B 2 n (o) g 2 ℓ 2 (E) .
Therefore,

1 B 2 n (o)∩E ∆ 1 1 B 2 n (o)∩E ≤ sup x∈Bn(o) d V (x) + sup (x,y)∈B 2 n (o)∩E d E (x, y) . Let f ∈ C c (E). There is p ∈ N such that supp(f ) ⊂ B 2 p (o) ∩ E, where supp(f ) = {(x, y) ∈ E : f (x, y) = 0}. Note that supp(∆ n 1 f ) ⊂ B 2 p+n . Therefore, ∆ n+1 1 f ℓ 2 (E) ≤ 1 B 2 p+n+1 (o) ∆ 1 1 B 2 p+n+1 (o) ℓ 2 (E) ∆ n 1 f ℓ 2 (E) ≤ 4 3 sup x∈B n+p+1 (o) d V (x) + sup (x,y)∈B 2 n+p+1 (o) d E (x, y) ∆ n 1 f ℓ 2 (E) .
Hence, we have

+∞ n=1 1 2n ∆ n 1 f := +∞.
Applying [START_REF] Nussbaum | Quasi-analytic vectors[END_REF] or [START_REF] Masson | Classes of C ∞ vectors and essential selfadjointness[END_REF], the result follows.

In the next theorem, we adapt the previous approach for ∆ 2 . Then ∆ 2 is essentially self-adjoint on C c (F).

Proof. We set

F n := {(x, y, z) ∈ F such that x, y, z ∈ B n (o)}.
Let g ∈ ℓ 2 (F). Then,

1 Fn g, ∆ 2 1 Fn g = (x,y)∈E 1 E(x, y) | z∈F (x,y) F(x, y, z)1 Fn (x, y, z)g(x, y, z) | 2 ≤ (x,y)∈E 1 E(x, y) t∈F (x,y) F(x, y, t) × z∈F (x,y) F(x, y, z)|1 Fn (x, y, z)g(x, y, z)| 2 ≤ sup (x,y)∈B 2 n (o)∩E d E (x, y) 1 F k g ℓ 2 (F ) . Now, let f ∈ C c (F). There is p ∈ N such that supp(f ) ⊂ F p . This implies that supp(∆ 2 f ) ⊂ F p+1 . Therefore, ∆ n+1 2 f ℓ 2 (F ) ≤ 1 F p+n+1 ∆ 2 1 F p+n+1 ∆ n 2 f ℓ 2 (F ) ≤ sup (x,y)∈B 2 p+n+1 ∩E d E (x, y) ∆ n 2 f ℓ 2 (F ) .
In this way, we see that

+∞ n=1 1 2n ∆ n 2 f := +∞.
Applying [START_REF] Nussbaum | Quasi-analytic vectors[END_REF] or [START_REF] Masson | Classes of C ∞ vectors and essential selfadjointness[END_REF], the result follows.

Application to the class of Book-like triangulation

In this section, we strengthen the previous section and follow idea of [START_REF] Bonnefont | Essential spectrum and Weyl asymptotics for discrete Laplacians[END_REF].

Definition 5.1. [4] A 1-dimensional decomposition of the graph G = (V, m, E) is a family of finite sets (S n ) n∈N which forms a partition of V, that is V = ∪ n∈N S n , and such that for all x ∈ S n , y ∈ S m , E(x, y) > 0 =⇒ |n -m| ≤ 1
The following definition is introduced in [START_REF] Chebbi | The discrete Laplacian of a 2-Simplicial complex[END_REF].

Definition 5.2. Let T := (V, m, E, R) be a weighted triangulation and (S n ) n∈N a 1-dimensional decomposition of the graph G = (V, m, E). We say that T is a book-like triangulation if

1) ♯S 0 = 1, ♯S 2n+1 = 2 and ♯(S 2 2n+1 ∩ E) = 1, for all n ∈ N. 2) x, y ∈ S 2n+2 =⇒ E(x, y) = 0, 3) ∀x ∈ S 2n+1 , N G (x) = S 2n ∪ S 2n+2 .

A book-like triangulation

In [START_REF] Chebbi | The discrete Laplacian of a 2-Simplicial complex[END_REF], they prove that ∆ 2 is not necessarily essentially self-adjoint on a simple triangulation. Moreover, they not give an example of book-like triangulation where ∆ 2 is essentially self-adjoint. The aim of the following theorem is to tackle it.

d V (x)) - 1 2n ≥ ∞ n=1 1 2 √ 2n α + 1 = ∞
Applying Theorem 4.1 and Theorem 4.2, the result follows.

Application to the adjacency matrix

The spectral theory of adjacency matrix acting on 1-simplicial complex is useful for the study of some gelling polymers, of some electrical networks,

Theorem 4 . 2 .

 42 Let T = (V, m, E, F) be a weighted triangulation and let o ∈ V. Assume that +∞ n=1 n k=1 sup (x,y)∈B 2 k (o)∩E d E (x, y)

Theorem 5 . 3 .

 53 Let T := (V, m, E, R) be a simple book-like triangulation. Set α ∈ (0, 2]. Assume that ♯S 2n+2 = ⌊n α ⌋. Then ∆ 1 is essentially selfadjoint on C c (E) and ∆ 2 is essentially self-adjoint on C c (F).d E (x, y) + sup x∈B k (o)

and in number theory, e.g. [START_REF] Doyle | Random walks and electric networks[END_REF][START_REF] Davidoff | Elementary number theory, group theory, and Ramanujan graphs[END_REF][START_REF] Mohar | The spectrum of infinite graphs with bounded vertex degrees, Graphs, hypergraphsGraphs, hypergraphs and applications[END_REF]. We define the adjacency matrix:

It is symmetric and thus closable. We denote its closure by the same symbol. Definition 6.1. Let T = (V, m, E, R) be a weighted triangulation. The triangular graph of T is the graph T = ( V, m, E) where V = F, m = 1 and E((x 0 , y 0 , z 0 ), (x, y, z)) = R(x 0 , y 0 , z 0 ) R(x, y, z) E(x, y)

In the case of tri-partite triangulation, in [START_REF] Baloudi | The discrete laplacian acting on 2forms and application[END_REF], we proved that ∆ 2 is unitarily equivalent to

and Q(V ) be the operator of multiplication by V .

Example 6.3. ( Z-like triangulation)

Let T = (V, m, E, F) be a weighted triangulation. We say that T is a Z-like

in particular, we have

where σ(∆ 2 ) is the spectrum of ∆ 2 . Then A G is essentially self-adjoint on C c ( V).

Proof. Combine Theorem 4.2 and [START_REF] Baloudi | The discrete laplacian acting on 2forms and application[END_REF].