Alexandre Denis
email: alexandre.denis@inria.fr

Sébastien Lacour
email: sebastien.lacour@irisa.fr

Christian Pérez
email: perez@irisa.fr

Thierry Priol
email: thierry.priol@irisa.fr

AND André É Ribes
email: andre.ribes@irisa.fr

S Ébastien Lacour

Christian P Érez

Programming the grid with components: models and runtime issues

Keywords: component model, middleware, runtime, component deployment AMS subject classifications

come   L'archive ouverte pluridisciplinaire

1. Introduction. Programming distributed systems has always been seen as a tedious activity for a programmer. A Grid infrastructure, as the latest incarnation of distributed systems, is no exception to this reality. In addition to the associated coding activity, a programmer often has to deal with low-level programming and runtime issues such as communications between different modules of the application or deployment of modules among a set of available resources. To cope with this problem, several approaches have been pursued to make the programming task easier. Some well known approaches such as Remote Procedure Call or Distributed Objects allowed usual programming paradigms (function call or objects) to be applied to transparently invoke a function of a remote program or a method of a remote object. Despite some success stories, these two approaches have not been able to reduce the complexity of distributed programming to an acceptable level. Moreover, the automatic deployment of distributed applications is still an important issue.

A third approach based on the composition of software modules has gained acceptance in the last few years. Instead of following an object-oriented approach, and its associated inheritance mechanism, a component approach enforces composition as the main paradigm to develop distributed applications. It offers the advantage of decreasing the design complexity and improves productivity by facilitating software re-use. Such an approach can be applied to programs running on Grid infrastructures. Moreover, a Grid infrastructure, and its associated services to manage distributed resources, is well suited to deploy software components by placing them on available resources taking into account various constraints. It is worth noting that deployment of distributed software components is the missing feature of most of the available distributed component models. Therefore, we think that associating component programming with the Grid is of mutual benefit: making Grid programming easier and deploying software components in a transparent way. Thus, this will insure a larger success of these two promising technologies.

The focus of this paper is to apply component programming to scientific computing, especially multi-physics applications. Such applications aim to simulate various physics, each of them being implemented by a dedicated code, to increase the accuracy of simulation. It is becoming clear that a radical shift in software development should occur to handle the increasing complexity of such applications. Moreover, the computing infrastructure should provide the level of performance in order to run such applications within a reasonable time frame. A computational grid is by no doubt a computing infrastructure that could deliver this level of performance by combining together high-performance computing resources connected to the Internet.

However, modern software development approaches are often suspected of not providing the level of performance which high-performance computing systems would offer. If we consider the use of a component programming methodology for the design and the implementation of multi-physics applications, and the use of a Grid infrastructure for their execution, several obstacles can be foreseen. The first one is the suitability of existing component models for the encapsulation of scientific simulation codes within software components. It may often be the case that such codes are parallel (mostly SPMD) whereas component models are not designed to encapsulate SPMD parallel codes in an efficient way. The second obstacle is communications between software components. Within a grid infrastructure, there may be several networking technologies from System-Area Networks (SAN) to Wide-Area Networks (WAN). The use of the Internet's lingua franca TCP/IP jointly with a SAN is probably not the best way to exploit all this networking technology. Moreover, several communication middleware or runtime environements will have to work together in a seamless way to ensure communication within a component (parallelism) or between components (distribution). A third obstacle is the deployment of components within a grid infrastructure. Such a deployment should be made transparent to the users taking into account end-user constraints. An end-user should not have to map components onto available grid resources by himself. A grid middleware should manage this operation in an automatic way on behalf of the end-user. We think that these three obstacles represent the major ones and should be addressed by computer scientists.

The objective of this paper is to present some solutions to overcome these three obstacles. Within the framework of the Padico project, we carried out three research activities, each of them addressing an obstacle. Section 2 addresses the first one: the design of a component model for the grid (GridCCM) based on an existing one (Corba Component Model or Ccm). Section 3 presents a communication framework, called PadicoTM, allowing several communication middleware and runtime environments to work together by isolating them and allowing for various networking technologies to be shared. Section 4 explains the process of deploying components within a Grid and the required extension that should be made to existing Grid middleware such as the Globus Toolkit [START_REF] Foster | Globus: A metacomputing infrastructure toolkit[END_REF]. Finally, section 5 draws general conclusions and mentions perspectives of this work.

A Grid Component

Model. The component model we describe in this section is based on the Corba Component Model instead of designing a new one. We think that such a decision offers more advantages than drawbacks. Using an existing component model allows us to take benefit of all the work that has been done both on the design of the model itself and its realization through several open source implementations. We propose here some extensions to the Corba Component Model that do not require the modification of the Omg specification. Before introducing such extensions, we give a brief overview of Ccm in the following sections.

2.1. Overview of the CORBA Component Model. The Corba Component Model [START_REF] Omg | CORBA Component Model V3.0[END_REF] (Ccm) is part of the latest Corba [START_REF] Omg | The Common Object Request Broker: Architecture and Specification V3.0[END_REF] specifications (version 3). The Ccm specifications allow the deployment of components into a distributed environment, that is to say that an application can deploy interconnected components on different heterogeneous servers in one operation. Figure 1 presents the general picture of Ccm. The component life-cycle is divided into two parts. First, the creation of the component requires to define the component interface, to implement it and then to package it so as to obtain a component package, i.e. a component. The second part consists in (optionally) linking together several components into a component assembly and in deploying it. Ccm provides a model for all theses phases. For example, the Ccm abstract model deals with the external view of a component, while the Component Implementation Framework (CIF) provides a model to implement a component. There are also models for packaging and deploying a component, as well as for the local runtime environment of a component. In this section, we briefly introduce the abstract model, the execution model and the deployment model.

CCM Abstract Model.

A Corba component is represented by a set of ports described in the Interface Definition Language (Idl) of Corba 3 defined by the Omg. The Idl of Corba 3 is an extension of the Idl of Corba version 2 by the Omg. There are five kinds of ports as shown in Figure 2. Facets are named connection points that provide services available as interfaces while receptacles are named connection points to be connected to a facet. They describe the component's ability to use a reference supplied by some external agent. Event sources are named connection points that emit typed events to one or more interested event consumers, or to an event channel. Event sinks are named connection points into which events of a specified type may be pushed. Attributes are named values exposed through accessor (read) and mutator (write) operations. Attributes are primarily intended to be used for component configuration, although they may be used in a variety of other ways. Figure 3 shows an example of component definition using Idl3.

Facets and receptacles allow a synchronous communication model based on the remote method invocation paradigm. An asynchronous communication model based on data transfer is implemented by the event sources and sinks.

A component is managed by an entity named home. A home provides factory and finder operations to create and/or find a component instance. For example, a home exposes a create operation which locally creates a component instance.

CCM Execution Model.

Ccm uses a programming model based on containers. Containers provide the run-time environment for Corba components. A container is a framework for integrating transactions, security, events, and persistence into a component's behavior at runtime. Containers provide a standard set of services to a component, enabling the same component to be hosted by different container implementations. All component instances are created and managed at runtime by its container.

CCM Deployment

Model. The deployment model of Ccm is fully dynamic: a component can be dynamically connected to and disconnected from another component. For example, Figure 4 illustrates how a component ServerComp can be connected to a component ClientComp through the facet FacetExample: a reference is obtained from the facet and then it is given to a receptacle. Moreover, the model supports the deployment of a static application. In this case, the assembly phase has produced a description of the initial state of the application. Thus, a deployment tool can deploy the components of the application according to the description. It is worthwhile to remark that it is just the initial state of the application: the application can change it by modifying its connections and/or by adding/removing components.

The deployment model relies on the functionality of some fabrics to create component servers which are hosting environments of component instances. The issues of determining the machines where to create the component servers and how to actually create them are out of the scope of the Ccm specifications. 2.5. Adapting CCM to the Grid. The main problem of Ccm is that it does not provide any support to encapsulate parallel codes. Modifying the parallel code to a master-slave approach so as to restrict Corba communications to one node (the master) does not appear the right solution: it may require non trivial modifications to the the parallel code and the master node may become a communication bottleneck in parallel to parallel component communications. This problem is address by GridCCM.

2.5.1. Introducing Parallelism into CCM. This section presents GridCCM, an extension of the Corba Component Model. It adds the concept of parallel components to Ccm. Its objective is to allow an efficient encapsulation of parallel codes into GridCCM components. We currently restrict ourselves to embed Spmd (Single Program Multiple Data) codes1 . Another goal of GridCCM is to encapsulate parallel codes with as few modifications to parallel codes as possible. Similarly, we target to extend Ccm without introducing deep modifications to the model. That is why, we do not allow ourselves to do any change to the Corba Interface Definition Language (Idl). In the same way, a parallel component has to be interoperable with a standard sequential component.

Figure 5 presents a parallel component in the Corba framework. The Spmd code may use Mpi for its inter-process communications; it uses Corba to communicate with other components. In order to avoid bottlenecks, all processes of a parallel component participate to inter-component communications. The nodes of a parallel component are not directly exposed to other components. We introduced proxies to hide the nodes. More details about parallel Corba are exposed in [START_REF] Pérez | A parallel CORBA component model for numerical code coupling[END_REF].

Managing the Parallelism.

To introduce parallelism support, like data redistribution, without requiring any change to the Orb, we choose to introduce a software layer between the user code (client and server) and the stub as illustrated in Figure 6.

A call to a parallel operation of a parallel component is intercepted by this new layer. The layer sends the data from the client nodes to the server nodes. It can perform a redistribution of the data on the client side, on the server side or during the communication between the client and the server. The decision depends on several constraints like feasibility (mainly memory requirements) and efficiency (client network performance versus server network performance).

The parallel management layer is generated by a compiler specific to GridCCM, In the new Idl interface, the user arguments described as distributed have been replaced by their equivalent distributed data types. Because of this transformation, there are some constraints about the types that can be distributed. The current implementation requires the user type to be an Idl sequence type, that is to say a 1D array. So, one dimension distribution can automatically be applied. This scheme can easily be extended for multidimensional arrays: a 2D array can be mapped to a sequence of sequences.

C O R B A C l i e n t C o m p o n e n t G r i d C C M l a y e r C O R B A s t u b o > m ( m a t r i x n ) ; o 1 > m ( M a t r i x D i s n 1 ) ; o 2 > m ( M a t r i x D i s n 2 ) ; o 3 > m ( M a t r i x D i s n 3 ) ;
2.5.3. Preliminary Implementation of GridCCM. We have implemented a preliminary prototype of GridCCM on top of two existing Ccm implementations: OpenCCM [START_REF] Vadet | The OpenCCM platform[END_REF] and MicoCCM [START_REF] Pilhofer | The MICO CORBA component project[END_REF]. Our first prototype has been derived from OpenCCM [START_REF] Vadet | The OpenCCM platform[END_REF]. OpenCCM is developed at the research laboratory LIFL (Laboratoire d'Infomatique Fondamentale de Lille) and is written in Java. The second prototype has been derived from MicoCCM [START_REF] Pilhofer | The MICO CORBA component project[END_REF]. MicoCCM is an OpenSource implementation based on the Mico Orb and is written in C++. Considering the second prototype, we have shown that GridCCM is able to efficiently aggregate the bandwidth allowing parallel components to best use the underlying network. Some experiments have been done with a WAN, called VTHD [START_REF]The VTHD project[END_REF], a French high-bandwidth Wan that connect several clusters located in several INRIA research units. A bandwidth of 103 MB/s (820 Mb/s) was obtained (using a 1 Gbit/s link) between two clusters, each of them running a parallel component encapsulating a parallel code running on 11 cluster nodes. They should be able to efficiently share the resources (network, processor, etc.) without conflicts and without competing with each other. Moreover, we want every middleware systems to be able to use every available resources with the most appropriate method so as to achieve the highest performance. Unfortunately, existing Corba implementations are able neither to use a wide range of networks nor to be used beside Mpi. Therefore we designed a communication framework to cope with these issues. The important features which should be supported by grid-enabled middleware systems are: Transparency -The middleware systems used by an application should be able to transparently and efficiently use the available resources. For example, a Mpi, Pvm, Java or Corba communication should be able to utilize high speed networks (San) as well as local area networks (Lan) and wide area networks (Wan). Moreover, they should adapt their security requirements to the characteristics of the underlying network, e.g. if the network is secure, it is useless to cipher data. Flexibility -There is a diversity of middleware systems, and we can assume there will always be. It seems important not to tie grid applications to a specific grid framework but instead to ease the "gridification" of middleware systems. Interoperability -Grids are not a closed world. Grid applications will need to be accessible using standard protocols. So, there is a high need to keep protocol interoperability. Support Multiple Communication Paradigms -GridCCM requires several middleware systems, e.g. Mpi and Corba. Thus, it is important to allow different middleware systems to be used simultaneously. We introduce the PadicoTM [START_REF] Denis | Padicotm: An open integration framework for communication middleware and runtimes[END_REF][START_REF] Denis | Network communications in grid computing: At a crossroads between parallel and distributed worlds[END_REF] communication framework which is able to deal with these problems. PadicoTM is based on a three-level runtime layer model which decouples the interface seen by the middleware systems from the interface actually used at low-level: an arbitration layer plays the role of resources multiplexer; an abstraction layer virtualizes resources and provides the appropriate communication abstractions; a personality layer implements various APIs on top of the abstract interfaces. The originality of this model is to propose both parallel and distributed communication paradigms at every level, even in the abstraction layer. There is therefore no "bottleneck of features" as depicted in Figure 8. The following sections give a presentation of the different layers of PadicoTM as shown in Figure 9.

A communication

3.1. Arbitration Issues. Supporting Corba and Mpi, both running simultaneously in the same process using the same network, is not straightforward. Access to high-performance networks is the most conflict-prone task when using multiple middleware systems at the same time. We propose that arbitration should be dealt for at the lowest possible level, so as to build more advanced abstractions atop a fully reentrant system. Arbitration is performed by a layer which provides a consistent, reentrant and multiplexed access to every networking resources, each resource is utilized with the most appropriate driver and method. The arbitrated interfaces are designed for efficiency and reentrance. Thus, we propose these Api to be callbackbased (à la Active Message). For true arbitration, this layer is the only client of the system-level resources: all accesses to the network should be performed through the arbitration layer. It provides also arbitration between different networks (e.g. Myrinet against Ethernet) so that they do not bother each other, and between different middleware systems even if the communication library does not provide multiplexing. More details about cooperative access rather than competitive are given in [START_REF] Denis | Towards high performance CORBA and MPI middlewares for grid computing[END_REF].

The arbitration layer in PadicoTM is called NetAccess, which contains two subsystems: SysIO for access to system I/O (sockets, files), and MadIO for multiplexed access to high-performance networks. The core of NetAccess manages the threads with the polling loops and enforces fairness between SysIO and MadIO. The interleaving policy between SysIO and MadIO is dynamically user-tunable through a configuration Api to give more priority to system sockets or high performance network depending on the application. NetAccess is open enough so as to allow the integration of other subsystems beside MadIO and SysIO for other paradigms such as Shmem on Smp for example.

3.1.1. NetAccess MadIO: API for Accessing Parallel-oriented Hardware. For good I/O reactivity and portability over high performance networks, we have chosen the high-performance network library Madeleine [START_REF] Aumage | A portable and efficient communication library for high-performance cluster computing[END_REF] as a foundation. Madeleine is used for high-performance networks such as Myrinet , Sci, Via. Madeleine provides no more multiplexing channels than what is allowed by the hardware (e.g. 2 over Myrinet , 1 over Sci). MadIO adds a logical multiplexing/demultiplexing facility which allows an arbitrary number of communication channels. Multiplexing on top of Madeleine adds a header to all messages. This can significantly increase the latency if not done properly. We implement headers combining to aggregate headers from several layers into a single packet. Thus, multiplexing on top of Madeleine adds virtually no overhead to middleware systems which send headers anyway. We actually measure that the overhead of MadIO over plain Madeleine is less than 0.1 µs which is imperceptible on most current networks. 3.1.2. NetAccess SysIO: API for Accessing Distributed-oriented Hardware. Contrary to a widespread belief, using directly the socket Api from the Os does not bring full reentrance, multiplexing and cooperation. Several middleware systems not designed to work together may get into troubles when used simultaneously, even with only plain Tcp/Ip. There are reentrance issues for signal-driven I/O (used by middleware systems designed to deal with heavy load), which results in an incorrect behavior, or worst, in a crash. If a middleware system uses blocking I/O and another uses active polling, the one which does active polling holds near 100 % of the Cpu time; it will result in inequity or even deadlock. To solve these conflicts, SysIO manages a unique receipt loop that scans the opened sockets and calls user-registered callback functions when a socket is ready. The callback-basedness guarantees that there is no reentrance issue nor signals to mangle with.

Abstraction

Layer. On top of the arbitration layer, the abstraction layer provides higher level services, independent of the hardware. Its goal is to provide various abstract interfaces well suited for their use by various middleware systems.

A dual-abstraction model.

A wide-spread design for communication frameworks consists in providing a unique abstraction on which several middleware systems may be built (see Figure 8 a andb). However, if this unique abstract interface is parallel-oriented (à la Mpi: message-based, Spmd, logical numbering of processes), dynamicity and link-per-link management are not easy. On the other hand, if this unique abstract interface is distributed-oriented (à la sockets: streams, fully dynamic), the performance is likely to be poor. Thus we propose an abstraction layer with both parallel-and distributed-oriented interfaces; these abstract interfaces are provided on top of every method provided by the arbitration layer (Figure 8 c). The abstract layer should be fully transparent: a middleware system built on top of the abstract layer should not have to know whether it uses Myrinet , a Lan or a Wan; it always uses the same Api and does not even choose which hardware it uses. The abstraction layer is responsible for automatically and dynamically choosing the best available service from the low-level arbitration layer according to the available hardware; then it should map it onto the right abstraction. This mapping could be straight (same paradigm at low and abstract levels, e.g. parallel abstract interface on parallel hardware) or cross-paradigm-e.g. distributed abstract interface on parallel hardware.

The abstract interfaces in PadicoTM are called VLink for distributed computing, and Circuit for parallelism.

Distributed abstract interface:

VLink . The VLink interface is designed for distributed computing. It is client/server-oriented, supports dynamic connections, and streaming. In order to easily allow several personalities -both synchronous and asynchronous personalities-, VLink is based on a flexible asynchronous Api. This Api consists in five primitive operations -read, write, connect, accept, close. These functions are asynchronous: when they are invoked, they initiate (post ) the operation and may return before completion. Their completion may be tested at any time by polling the VLink descriptor; a handler may be set which will be called upon operation completion. Such a set of functions is called a VLink -driver. VLink drivers have been implemented on top of: MadIO, SysIO, Parallel Streams for Wan, AdOC [START_REF] Jeannot | Adaptive online data compression[END_REF], loopback.

Abstract interface for parallelism:

Circuit. The Circuit interface is designed for parallelism. It manages communications on a definite set of nodes called a group. A group may be an arbitrary set of nodes, e.g. a cluster, a subset of a cluster, may span across multiple clusters or even multiple sites. Circuit allows communications from every node to very other node through an interface optimized for parallel runtimes: it uses incremental packing with explicit semantics to allow onthe-fly packet reordering, like in Madeleine [START_REF] Aumage | A portable and efficient communication library for high-performance cluster computing[END_REF]. Collective operations in Circuit still needs to be investigated. Circuit adapters have been implemented on top of MadIO, SysIO, loopback and VLink (to use the alternates VLink adapters); a given instance of Circuit can use different adapters for different links.

Personality

Layer and Middleware Systems. The middleware systems likely to be used by grid-enabled applications are various: Mpi, Corba, Soap, Hla, Jvm, Pvm, etc. Moreover, for each kind of middleware, there are several implementations which have their own specific properties. Developing a middleware system is a heavy task -for example, Mpich contains 200,000 lines of C-and requires very specific skills. Moreover, the standards -and thus, the middleware systems themselvesare ever-changing. It does not seem reasonable to re-develop an implementation of each one of these middleware systems specifically for a given communication framework. Instead of adapting the middleware systems to our communication framework, we adapt our communication framework to the expectation of the existing middleware systems. Thus it is easy to follow the new versions and to use specific features of a given implementation.

To seamlessly re-use existing implementations of middleware systems, we choose to virtualize networking resources. It consists in giving the middleware system the illusion that it is using the usual resource it knows, even if the real underlying resource is completely different. For example, we show a "socket" Api to a Corba implementation so as to make it believe it is using Tcp/Ip, even if it is actually using another protocol/network behind the scene. This is performed through the use of thin wrappers on top of the appropriate abstract interface to make it look like the required Api. We call these small wrappers personalities. It is possible to give several personalities to an abstract interface.

PadicoTM provides several well-known Api through simple "cosmetics" adapters over the VLink and Circuit abstract interfaces. These thin Api wrappers are called personalities. The personalities for VLink are: Vio for an explicit use through a socket-like Api; SysWrap supplies a 100 % socket-compliant Api through wrapping at runtime, binary-compatible with C, C++ or Fortran legacy codes without even recompiling. Thus, legacy applications are able to transparently use all PadicoTM communication methods without losing interoperability with PadicoTM-unaware applications on plain sockets. We implement an Aio personality on top of VLink which provides a plain Posix.2 Asynchronous I/O (Aio) Api. Thin adapters on top of Circuit provides a Fm 2.0 Api, and a (virtual) Madeleine Api.

Thanks to SysWrap, various middleware systems have been seamlessly ported on PadicoTM with absolutely no change in their code: Corba implementations (om-niORB 3, omniORB 4, ORBacus 4.0, all Mico 2.3.x including Ccm-enabled versions), an Hla implementation (Certi from the Onera), and a Soap implementation (gSOAP 2.2). A Java virtual machine (Kaffe 1.0.7) has been slightly modified for use within PadicoTM, with some changes in its multi-threading management code. Thanks to the virtual Madeleine personality, the existing Mpich/Madeleine [START_REF] Aumage | MPICH/Madeleine: a true multi-protocol MPI for high-performance networks[END_REF] implementation can run in PadicoTM. The middleware systems are dynamically loadable into PadicoTM. Arbitration guarantees that any combination of them may be used at the same time.

4. Deploying Components on a Computational Grid. One of the long run goals of computational grids is to provide computer power in the same way as the electric power grid supplies electric power [START_REF]The Grid: Blueprint for a New Computing Infrastructure[END_REF], i.e. transparently. Here, transparency means that the user does not know what particular resources provide electric or computational power. So the user should just have to submit his or her application to a computational grid and get back the result of the application without worrying about resource selection, resource location, or mapping processes on resources. In other words, application deployment should be as automatic and easy as plugging an electric device into an electric outlet.

Automatic deployment of component-based applications is crucial for better acceptance of the component-based programming model as well as for the success of computational grids which can host various types of applications (parallel, distributed, etc.). One of the advantages of the Corba Component Model (Ccm, [START_REF] Omg | CORBA Component Model V3.0[END_REF]) is that it specifies both a packaging model and deployment model. However, Ccm does not say how execution hosts may be selected, nor how processes may be launched on computers from a practical viewpoint.

To really achieve automatic deployment, we need both a description of the computational grid which we have access to plus a packaged application (Figure 10). Those two pieces of information are given to a deployment tool which selects resources and actually launches the application on the selected, distributed resources of the grid. The following sections provide further details on the different steps of automatic deployment: application and resource information description, deployment planning, actual execution and configuration of the application. package. This is a compressed archive provided by the user to the deployment tool. It includes, among other files, the assembly description which describes all the components of the assembly and their interconnections, as well as initial configuration parameters.

The assembly and component descriptors can express various requirements such as the processor architecture and the operating system required by a component implementation. A component may have environmental or other dependencies, like libraries, executables, Java classes, etc. Another possible requirement is component collocation: components may be free or partitioned to a single process or a single host, meaning that a group of component instances will have to be deployed in the same process or on the same compute node.

The component deployment tool must make sure that those constraints and dependencies will be satisfied at execution time.

4.1.2. Grid Resource Information Description. Before automatically deploying the processes of a distributed application on a computational grid, the compute nodes on which the application will be run must be selected automatically. In order for the deployment tool to make wise decisions in selecting computers, grid resources must be described precisely.

Information about grid resources includes not only compute and storage resource information, but also network description. Network information is important for highperformance applications in particular: resource selection may be constrained by such computer-level and network-level requirements as "I want 32 computers connected by a network of at least 2 Gb/s, like Myrinet".

Compute and storage resource description is rather well mastered (computer architecture, number and speed of CPUs, operating system, memory size, storage capacity, etc.), as exemplified by MDS2 (Monitoring and Discovery Service, [START_REF] Czajkowski | Grid information services for distributed resource sharing[END_REF]), the Grid Information Service of the Globus Toolkit version 2 [12]. However, network description received less attention. Simple networks should be described in a simple way, but the description model should allow for the description of complex networks including firewalls, NAT (Network Address Translation), asymmetric links (like asymmetric bandwidths), non-hierarchical topologies, connection to multiple networking technologies (Myrinet, Ethernet, etc.). We have proposed [START_REF] Lacour | A network topology description model for grid application deployment[END_REF] a scalable description model of grid network topology (as shown in Figure 11) and have implemented it on top of MDS2. The main idea is to group compute nodes together within network groups where network characteristics are roughly similar (bandwidth, latency, jitter, loss rate, etc.). This results in a synthetic description of grid resources, including both compute nodes and network.

4.2. Deployment Planning. Once application and resource information has been retrieved, the deployment planner [START_REF] Lacour | A software architecture for automatic deployment of CORBA components using grid technologies[END_REF] is responsible for 1) selecting resources to run the application, 2) selecting the network links (or network technology) to interconnect the application components, and 3) mapping the application processes (or Corba component servers) onto the selected resources. The input of the deployment planning algorithm is made of the application description and the resource description. The application description represents a set of constraints which must be satisfied by the selected resources.

The output of the deployment planner is a deployment plan which describes the mapping of the components onto component servers and the mapping of the component servers onto the selected compute nodes of the computational grid. The deployment plan should also specify 1) in what order processes must be launched by the deployment tool, 2) how data must flow from the output of certain processes to the input of other processes, 3) what network connections must be established between every pair of processes. For instance, items 1) and 2) are necessary for Corba applications, where a Naming Service needs to be launched, and its reference needs to be passed to the component servers launched afterwards.

Actual Deployment of Components Using the Globus Toolkit.

Once a deployment plan has been obtained from the previous step, the componentbased application is launched and configured according to the Corba component model. The technical point is that the selected computers are assumed not to run any component activator or component server. That is the reason why a job submission method is needed to launch an initial process on the selected compute nodes.

This step is fully compatible with the Ccm deployment model as explained in [START_REF] Lacour | Deploying CORBA components on a computational grid: General principles and early experiments using the Globus Toolkit[END_REF]. For example, we have developed a prototype called ADAGE: Automatic Deployment of Applications in a Grid Environment. It is able to deploy standard Corba component using the Globus Toolkit version 2 [12,[START_REF] Foster | The Globus Project: a status report[END_REF]. The Globus Toolkit is an open source software toolkit used for building grids. It includes software for security enforcement, resource, information, and data management. This middleware is wide-spread and well-established, as exemplified by many projects relying on the Globus Toolkit, such as GriPhyN (the Grid Physics Network, [START_REF]The Grid Physics Network (GriPhyN) web site[END_REF]), the American DOE Science Grid [START_REF]The DOE Science Grid web site[END_REF], the European DataGrid project [START_REF]The DataGrid Project web site[END_REF], TeraGrid [START_REF]The TeraGrid web site[END_REF].

As shown on Figure 10, the deployment tool manages two sorts of handles: Corba references and handles returned by the grid access middleware (the Globus Toolkit). Both are useful to control application processes, like cancel, suspend, or restart their execution.

Conclusion.

The deployment of high bandwidth wide-area networks has led computational grids to offer a very powerful computing resource. In particular, this inherently distributed resource is well-suited for multi-physics applications. To face the complexity of such applications as well as the heterogeneity and volatileness of grids, the software component technology appears to be a very adequate programming model. We choose to work with the Corba component model because its deployment model is very complete: it specifies the deployment of a set of components on a set of distributed (component) servers. However, it does not handle very well some aspects that are inherent to Grid infrastructures: managing parallelism within a component, heterogeneity of networks and automatic deployment of components onto available compute nodes. It specifies neither how to select resources, nor how to initiate component servers on the selected resources. On the other hand, a grid access middleware, such as the Globus Toolkit, deals with security enforcement, resource, information, data management, and portability.

This paper presents some solutions to those problems. We have shown that managing parallelism within a Corba component, while maintaining scalable connection between components, can be done without modifying the Omg specification. Then, grid programmers can rely on an existing model, from the Omg, which is widely accepted in some application fields, but not yet within the grid user community, to be honest. Concerning network resources, we propose a framework that is capable of virtualizing various networking technologies and their associated protocols. It allows components to communicate between each other without taking care of the underlying networks. Thus a distributed application based on software components can be deployed independently of network resources. It can be executed anywhere while fully taking advantage of the performance characteristics of the underlying network. Moreover, several communication middleware or runtime systems can be used simultaneously within a component without suffering from any side effect or unexpected behavior. Our framework is able to share network resources even if they were not designed to be shared. This will give much flexibility for the deployment of components on Grid infrastructures. As for instance two components exchanging a large amount of data can be mapped onto a set of compute nodes interconnected over a very high-performance network such as Myrinet. However to do so, it requires that the Grid middleware managing the Grid infrastructure be aware of the presence of such networks as well as the topology of these networks. We proposed to extend existing information services to store information related to network resources (topologies, network technologies, etc.). Using such extensions, it is possible to allocate resources and to propose a mapping of components to those resources in an automatic way depending on the user's constraints and requirements. Most of our efforts are now devoted to integration of the results presented in this paper with the Globus Toolkit.

Figure 1 .

 1 Figure 1. Overview of the Corba Component Model.

Figure 3 .

 3 Figure 3. A component Idl definition. aComponent ref = ServerComp->provide avgPort(); ClientComp->connect avgClientPort(ref);

Figure 4 .

 4 Figure 4. Example of code to connect two components.

Figure 5 .

 5 Figure 5. Parallel component concept.

Figure 6 .Figure 7 .

 67 Figure 6. GridCCM intercepts and translates remote method invocations.

  Framework for Software Components. GridCCM requires several middleware systems at the same time, typically Corba and Mpi.

  Everything expressed through a single abstraction (distributed) -two cross-paradigm translations are needed for a parallel middleware atop a parallel network. (b) A unified abstraction makes compromises in all cases! -gives up most possible optimizations and imposes compromises to everything. Dual-abstraction model: use different abstract interfaces for different paradigms -only required compromises are done.

Figure 8 .

 8 Figure 8. Several abstraction models may be envisaged.

C

Figure 9 .

 9 Figure 9. The PadicoTM communication framework.

4. 1 .Figure 10 .

 110 Figure 10. Overview of the deployment architecture.

Figure 11 .

 11 Figure 11. Network graph describing the topology of a sample Grid.

This choice stems from two considerations. First, many parallel codes are indeed Spmd. Second, Spmd codes bring an easily manageable execution model.

Acknowledgments. This work was supported by the Incentive Concerted Action "GRID" (ACI GRID) of the French Ministry of Research.

This work was supported by the French ACI GRID initiative 1


F Perret

I Demouge

S Calmet

F Courtine

De

Risheng Sheng
email: risheng.sheng@ec-nantes.fr

Laurent Perret

François Demouge

Isabelle Calmet

Sébastien Courtine

Fabrice De Oliveira

Wind Tunnel study of the flow around a wall-mounted square prism immersed in an atmospheric boundarylayer

published or not. The documents may come     Wind Tunnel study of the flow around a wall-mounted square prism immersed in an atmospheric boundary-layer

INTRODUCTION

Wind load on the structures is one of the main wind effects which are very important for building construction. Most of the structures are bluff bodies hence the aerodynamics of bluff bodies is commonly studied in the wind engineering literature. [START_REF] Irwin | Bluff body aerodynamics in wind engineering[END_REF] has listed several examples of wind tunnel tests for bluff bodies and proved the importance of these tests can be to the safety and economics of large buildings and bridges. Evidently, full-scale measurements have no scale mismatch for all characteristics. However, they are costly and can be time-consuming. Additionally, the conditions of measurements can be hardly controlled. Every change of the environment can lead to the error of measurements. Hence, the well-controlled wind-tunnel tests were carried out for wind engineering. Niemann (1998) has compared the results of wind tunnel tests with those of full-scale measurements. Good agreement was found which ensure the quality of the wind tunnel measurements. [START_REF] Melbourne | Comparison of measurements on the caarc standard tall building model in simulated model with flows[END_REF] compared the results of wind tunnel tests from different laboratories for a same model and almost the same result was presented by those different laboratories. Hence we can conclude that conditions can be easily controlled for wind tunnel tests. Furthermore, wind tunnel experiment is a very important method for building construction. The wind tunnel experiment with a tower building as a bluff body presented in the present paper is part of a broader research project, the target of which is to validate the ability of Large Eddy Simulation (LES) to predict extreme wall-pressure events against experimental measurements. In order to be able to prescribe the correct inlet condition, detailed wind tunnel measurements were performed to measure the gradient of mean velocity and all the length scales of the turbulence. Different wind tunnel measurement techniques such as particle image velocimetry (PIV), high-frequency force measurement and unsteady wallpressure measurements were also performed in this study. In the present paper, the focus is on the high-frequency force measurement and unsteady wall-pressure measurements to investigate spectral content of the wind load in lateral and longitudinal directions.

EXPERIMENTAL MODELS AND PROCEDURES

All the wind tunnel tests were performed in the NSA wind tunnel at CSTB, Nantes, France, which is a close-loop wind-tunnel with a test-section 20 m long, 2 m high and 4 m wide. These large dimensions can allow for the reproduction of natural wind at scales ranging between 1:100 and 1:400 for the usual local and global measures. The velocity of the flow in the wind tunnel is adjustable from 0 to 30 m/s. The floor of the wind tunnel is equipped with a turntable table to position models from 0 to 360° ± 1°. The simulation of the wind is made by placing different sets of roughness and vortex generators on the floor of the wind tunnel.

Model

The tower building was modeled with a wall-mounted prism of square cross-section (dimensions: 10 cm 10 cm 49 cm) made of Plexiglas to allow for optical access. A second model equipped with 265 pressure taps was used to measure the unsteady pressure distribution on the model walls as shown in Figure 1.

The wind flow characteristics

The wind tunnel tests were carried out in turbulent flow, simulating the vertical velocity and turbulence profile expected at the construction site using roughness elements which include a rough carpet and turbulence generators at the entrance of the section (cf. Figure 2a). The targeted code roughness is z 0 =0.02 m according to Eurocode 1 (2005). At the reference height H ref = 0.67H (where H is the building height), the reference mean wind speed U ref =10m/s. Figure 2b and Figure 2c show the profiles of mean velocity and the turbulent intensity of the generated boundary layer. Comparison between measurements and results from the literature shows a good agreement, which ensure the inlet condition simulated by the wind tunnel NSA.

In addition to the mean velocity and the turbulent intensity profiles, power spectra of the wind speed were also checked. Here we compare the power spectrum of the longitudinal wind speed u at the reference height with the result given by the Eurocode 1 (2005). Figure 3 shows again a very good agreement between the experimental data and the model profile from the literature. We can conclude that in the NSA wind tunnel we can simulate a turbulent wind which can reproduce the fluid characteristics as proposed in the literature.

Experimental set-up

The tower building has been equipped with 265 pressure taps. Measurements were performed synchronously at a rate of 512 Hz for the pressure taps and 200 Hz for the force balance over 4 min. The pressure scanner designed by CSTB is the "1024 channels / 1024 Hz" capable pressure scanner. This accurate scanner is composed of high precision power supply over 32 channels. Each channel is connected to an ESP Pressure Scanners with 32 pressure ports multiplexed at 70 KHz. The tubing system was used to connect pressure tap and scanner port. The Helmholtz's resonance effects due to the tube cavity were corrected by using traditional restrictors.

RESULTS AND DISCUSSIONS

In this section, a detailed analysis of the characteristics of wind load is presented, focusing on its dynamics. Indeed, thanks to the pressure tap measurements, all local information such as mean pressure, variance of the pressure signal and the power spectrum of the signal are available. Global force measurements are compared with the integration of the local wind loads obtained from the pressure measurements.

Global wind loads and force

With the pressure tap measurements, the instantaneous value of the local pressure can be obtained simultaneously at the 265 pressure taps. After integration over the building surface, the global force signal can be compared with the result of the force balance. The original power spectrum of the force is altered by the mechanic resonance of the equipment. To facilitate the analysis and comparison, a filter is applied to remove the resonance according to Caracoglia (2015). Figure 4 shows a good agreement found between the two types of measurements. A strong peak appears in the lateral force power spectrum which gives us a Strouhal number at about 0.11. The Strouhal number is defined as St=fD/U ref with D the tower width and U ref the reference velocity. This value is very close to the one of 0.12 found in the literatures as Choi (2000) and [START_REF] Okajima | Numerical simulation of flow around rectangular cylinders[END_REF] for this type of structure. Difference exists because of the different definitions of U ref , which is the reference velocity at 0.67H here and free-stream velocity in those papers.

Local wind loads

A clear peak at St = 0.11 appeared only in the spectrum of the lateral force as shown in the Figure 4. We focus here on the local wind loads at the reference height to understand it clearly. We can number each pressure tap as shown in Figure 5b in which wind comes at the face of AB. Because of the symmetry of our tower building, identical results were found for sides BC and AD. Therefore, only the information at the three faces AB, BC and CD were needed.

Figure 5 shows the power spectrum for taps 1-15 around the tower at reference height. All the spectra on the BC side have a marked peak. This is expected as the lateral sides of the building are where shear layers at the origin of the vortex shedding cycle form and develop.

The spectral peak corresponding to the Strouhal number of 0.11 also exists on the AB and CD sides for some pressure taps (tap 1, 5, 11, 12, 14 and 15 symmetrically). This was less expected, especially on the side AB facing the oncoming wind where the flow is upstream the separation points formed by the upstream building corners. These tap locations are therefore under the influence of the vortex shedding. To better understand this phenomenon, the spectral coherence between different taps has been computed. At the frequency corresponding to the Strouhal number identified above, we found that there exists strong coherence (about 0.9) between two points on the same side of the face AB (tap 4 and 5) as shown in Figure 6a and also between taps located on the same side of the building (taps 5 and 6 to 10) (figure 6b), confirming that these tap locations are under the influence of the same shear layer. The coherence level drops to 0.65 for points at opposite corners of face AB (tap 1 and 5) as shown in Figure 6a. Even though vortex shedding from opposite sides of a bluff body is known to be well-synchronized (being roughly 180° out of phase), the marked loss of phase-coherence (also observed between two points from opposite sides) might be the result of the structure of the oncoming wind flow: the bluff body being immersed in a thick atmospheric boundary layer, the presence of strong turbulent structures might disturb the flow separation at the corners of the building side facing the wind near tap 1 and symmetrically tap 5. This loss of coherence of pressure signals measured on surfaces normal to the oncoming wind can therefore reduce or make disappear through the integration process the spectral peak in the global effort in the longitudinal direction. Finally, we can notice the presence of the same noise in the power spectrum figures and in the coherency figures. It's attributed to acoustic noises that exist in the wind tunnel and depend only on the wind tunnel configuration.

Figure 1 :

 1 Figure 1: a) distribution of pressure taps, b) tower building for PIV measurements, c) tower building with pressure taps for pressure distribution measurements on the model walls

Figure 2 :Figure 3 :

 23 Figure 2: a) roughness elements to simulate the turbulent flow, b) mean velocity profile, c) turbulent intensity profile

Figure 4 :

 4 Figure 4: Power spectrum for tree components of force: a) lateral direction, b) longitudinal direction and c) vertical direction

Figure 5 :

 5 Figure 5: a) power spectrum of pressure on AB, b) Configuration of pressure taps for the present local sectral analysis, c) power spectrum of pressure on BC, d) power spectrum of pressure on CD


Hans Havlicek

Boris Odehnal

Metod Saniga

Möbius Pairs of Simplices and Commuting Pauli Operators

Keywords: Mathematics Subject Classification (2000): 51A50 -81R05 -20F99 PACS Numbers: 02.10.Ox, 02.40.Dr, 03.65.Ca Key-words: Möbius Pairs of Simplices -Factor Groups -Symplectic Polarity -Generalised Pauli Groups

There exists a large class of groups of operators acting on Hilbert spaces, where commutativity of group elements can be expressed in the geometric language of symplectic polar spaces embedded in the projective spaces PG(n, p), n being odd and p a prime. Here, we present a result about commuting and non-commuting group elements based on the existence of socalled Möbius pairs of n-simplices, i. e., pairs of n-simplices which are mutually inscribed and circumscribed to each other. For group elements representing an n-simplex there is no element outside the centre which commutes with all of them. This allows to express the dimension n of the associated polar space in group theoretic terms. Any Möbius pair of n-simplices according to our construction corresponds to two disjoint families of group elements (operators) with the following properties: (i) Any two distinct elements of the same family do not commute. (ii) Each element of one family commutes with all but one of the elements from the other family. A threequbit generalised Pauli group serves as a non-trivial example to illustrate the theory for p = 2 and n = 5.

Introduction

The last two decades have witnessed a surge of interest in the exploration of the properties of certain groups relevant for physics in terms of finite geometries. The main outcome of this initiative was a discovery of a large family of groups -Dirac and Pauli groups -where commutativity of two distinct elements admits a geometrical interpretation in terms of the corresponding points being joined by an isotropic line (symplectic polar spaces, see [START_REF] Huppert | I. Die Grundlehren der Mathematischen Wissenschaften[END_REF], [START_REF] Shaw | Finite geometry, Dirac groups and the table of real Clifford algebras[END_REF], [START_REF] Saniga | Multiple qubits as symplectic polar spaces of order two[END_REF], [START_REF] Planat | On the Pauli graphs of N-qudits[END_REF], [START_REF] Sengupta | Finite geometries with qubit operators[END_REF], [START_REF] Rau | Mapping two-qubit operators onto projective geometries[END_REF], [START_REF] Thas | Pauli operators of N-qubit Hilbert spaces and the Saniga-Planat conjecture[END_REF], [START_REF] Thas | The geometry of generalized Pauli operators of N-qudit Hilbert space, and an application to MUBs[END_REF], and [START_REF] Havlicek | Factor-group-generated polar spaces and (multi-) qudits[END_REF] for a comprehensive list of references) or the corresponding unimodular vectors lying on the same free cyclic submodule (projective lines over modular rings, e. g., [START_REF] Havlicek | Projective ring line of a specific qudit[END_REF], [START_REF] Havlicek | Projective ring line of an arbitrary single qudit[END_REF]). This effort resulted in our recent paper [START_REF] Havlicek | Factor-group-generated polar spaces and (multi-) qudits[END_REF], where the theory related to polar spaces was given the most general formal setting.

Finite geometries in general, and polar spaces in particular, are endowed with a number of remarkable properties which, in light of the above-mentioned relations, can be directly translated into group theoretical language. In this paper, our focus will be on one of them. Namely, we shall consider pairs of n-simplices of an n-dimensional projective space (n odd) which are mutually inscribed and circumscribed to each other. First, the existence of these so-called Möbius pairs of n-simplices will be derived over an arbitrary ground field. Then, it will be shown which group theoretical features these objects entail if restricting to finite fields of prime order p. Finally, the case of three-qubit Pauli group is worked out in detail, in view of also depicting some distinguished features of the case p = 2.

Möbius pairs of simplices

We consider the n-dimensional projective space PG(n, F) over any field F, where n ≥ 1 is an odd number. Our first aim is to show an n-dimensional analogue of a classical result by Möbius [START_REF] Möbius | Kann von zwei dreiseitigen Pyramiden eine jede in Bezug auf die andere umund eingeschrieben zugleich heissen?[END_REF]. Following his terminology we say that two n-simplices of PG(n, F) are mutually inscribed and circumscribed if each point of the first simplex is in a hyperplane of the second simplex, and vice versa for the points of the second simplex. Two such n-simplices will be called a Möbius pair of simplices in PG(n, F) or shortly a Möbius pair. There is a wealth of newer and older results about Möbius pairs in PG (3, F). See, among others, [START_REF] Guinand | Graves triads, Möbius pairs, and related matrices[END_REF], [4, p. 258], [START_REF] Witczyński | Some remarks on the theorem of Möbius[END_REF], [START_REF] Witczyński | Möbius' theorem and commutativity[END_REF]. The possibility to find Möbius pairs of simplices in any odd dimension n ≥ 3 is a straightforward task [2, p. 188]: Given any n-simplex in PG(n, F) take the image of its hyperplanes under any null polarity π as second simplex. By this approach, it remains open, though, whether or not the simplices have common vertices. For example, if one hyperplane of the first simplex is mapped under π to one of the vertices of the first simplex, then the two simplices share a common point. However, a systematic account of the n-dimensional case seems to be missing. A few results can be found in [START_REF] Berzolari | Sull' estensione del concetto di tetraedri di Möbius agli iperspazî[END_REF] and [START_REF] Herrmann | Matrizen als projektive Figuren[END_REF]. There is also the possibility to find Möbius pairs which are not linked by a null polarity. See [1, p. 137] for an example over the real numbers and [3, p. 290ff.] for an example over the field with three elements. Other examples arise from the points of the Klein quadric representing a double six of lines in PG (3, F). See [10, p. 31] We focus our attention to non-degenerate Möbius pairs. These are pairs of nsimplices such that each point of either simplex is incident with one and only one hyperplane of the other simplex. This property implies that each point of either simplex does not belong to any subspace which is spanned by less than n points of the other simplex, for then it would belong to at least two distinct hyperplanar faces. We present a construction of non-degenerate Möbius pairs which works over any field F. The problem of finding all Möbius pairs in PG(n, F) is not within the scope of this article.

In what follows we shall be concerned with matrices over F which are composed of the matrices

K := 0 -1 1 0 , J := 1 1 1 1 , L := 1 -1 -1 1 , (1)
and the 2 × 2 unit matrix I. We define a null polarity π of PG(n, F) in terms of the alternating (n + 1) × (n + 1) matrix1

A :=                  K -J . . . -J J K . . . -J . . . . . . . . . . . . J J . . . K                  . (2)
Thus all entries of A above the diagonal are -1, whereas those below the diagonal are 1. Using the identities -K 2 = I, JK -KL = 0, and JL = 0 it is easily verified that A is indeed an invertible matrix, because

A -1 =                  -K -L . . . -L L -K . . . -L . . . . . . . . . . . . L L . . . -K                  . (3)
Let P := {P 0 , P 1 , . . . , P n } be the n-simplex which is determined by the vectors e 0 , e 1 , . . . , e n of the standard basis of F n+1 , i. e., P j = Fe j for all j ∈ {0, 1, . . . , n}.

(

The elements of F n+1 are understood as column vectors. We first exhibit the image of P under the null polarity π.

Lemma 1. Let S be a subspace of PG(n, F) which is generated by k + 1 ≥ 2 distinct points of the simplex P. Then the following assertions hold:

(a) S ∩ π(S ) = ∅ if k is odd. (b) S ∩ π(S
) is a single point, which is in general position to the chosen points of P, if k is even.

Proof. Suppose that S is the span of the points P j 0 , P j 1 , . . . , P j k , where 0

≤ j 0 < j 1 < • • • < j k ≤ n. A point Y is in S if,
The rows of A with numbers j 0 , j 1 , . . . , j k comprise the coefficients of a system of linear equations in n + 1 unknowns x 0 , x 1 , . . . , x n whose solutions are the vectors of π(S ). Substituting the vector y into this system gives the homogeneous linear system (written in matrix form)

A k • (y j 0 , y j 1 , . . . , y j k ) T = (0, 0, . . . , 0) T , (6)
where A k is the principal submatrix of A which arises from the first k + 1 rows and columns of A. Note that (6) holds, because the matrix A k coincides with the principal submatrix of A which arises from the rows and columns with indices j 0 , j 1 , . . . , j k . The solutions of ( 6) are the vectors of S ∩ π(S ). There are two cases: k odd: Here A k has full rank k + 1, as follows by replacing n with k in (2) and (3). Hence the system (6) has only the zero-solution and S ∩π(S ) = ∅, as asserted.

k even: Here A k cannot be of full rank, as it is an alternating matrix with an odd number of rows. By the above, the submatrix A k-1 has rank k, so that the rank of A k equals to k. This implies that the solutions of the linear system (6) is the span of a single non-zero vector. For example,

(-1, 1, -1, 1, -1, . . . , -1) T ∈ F k+1 (7)
is such a vector. It determines the point

P j 0 , j 1 ,..., j k := F        k i=0 (-1) i+1 e j i        . ( 8
)
Since the coordinates of P j 0 , j 1 ,..., j k with numbers j 0 , j 1 , . . . , j k are non-zero, the points P j 0 , P j 1 , . . . , P j k , P j 0 , j 1 ,..., j k are in general position.

The previous lemma holds trivially for k + 1 = 0 points, since then S = ∅. It is also valid, mutatis mutandis, in the case k + 1 = 1, even though here one has to take into account S = P j 0 yields again the point S ∩ π(S ) = P j 0 . Hence the null polarity π and the simplex P give rise to the following points: P 0 , P 1 . . . , P n (the points of P), P 012 , P 013 , . . . , P n-2,n-1,n (one point in each plane of P), . . . , P 0,1,...,n-1 , . . . , P 1,2,...,n (one point in each hyperplane of P). All together these are

n + 1 1 + n + 1 3 + • • • + n + 1 n -1 = n i=0 n i = 2 n (9)
mutually distinct points. We introduce another notation by defining

P j 0 , j 1 ,..., j k =: Q m 0 ,m 1 ,...,m n-k , (10)
where 0

≤ m 0 < m 1 < • • • < m n-k ≤ n
are those indices which do not appear in P j 0 , j 1 ,..., j k . We are now in a position to state our first main result:

Theorem 1. In PG(n, F), n ≥ 3, let the null-polarity π and the n-simplex P = {P 0 , P 1 , . . . , P n } be given according to (2) and (4), respectively. Then the following assertions hold:

(a) P and Q := {Q 0 , Q 1 , . . . , Q n },
where the points Q m are defined by [START_REF] Hirschfeld | Finite Projective Spaces of Three Dimensions[END_REF], is a non-degenerate Möbius pair of n-simplices.

(b) The n-simplices P and Q are in perspective from a point if, and only if, F is a field of characteristic two.

Proof. Ad (a): Choose any index m ∈ {0, 1, . . . , n}. Then Q m is the image under π of the hyperplane S which is spanned by P 0 , . . . , P m-1 , P m+1 , . . . , P n . The proof of Lemma 1 shows how to find a system of linear equations for Q m . Furthermore, formula (8) provides a coordinate vector for Q m . However, such a vector can be found directly by extracting the m-th column of the matrix A -1 , viz.

m-1 i=0 (-1) i+m+1 e i + n k=m+1 (-1) k+m e k =: q m . (11)
(The vector from ( 8) is (-1) m q m .) As the columns of A -1 form a basis of F n+1 , the point set Q is an n-simplex.

The n + 1 hyperplanes of the simplex Q are the images under π of the vertices of P. Each of these hyperplanes has a linear equation whose coefficients comprise one of the rows of the matrix A. So a point P j is incident with the hyperplane π(P i ) if, and only if, the (i, j)-entry of A is zero. Since each row of A has precisely one zero entry, we obtain that each point of P is incident with one and only one hyperplane of Q.

In order to show that each point of Q is incident with precisely one hyperplane of the simplex P, we apply a change of coordinates from the standard basis e 0 , e 1 , . . . , e n to the basis b i := (-1) i q i , i ∈ {0, 1, . . . , n}. The points Fb i constitute the n-simplex Q. Let B be the matrix with columns b 0 , b 1 , . . . , b n . With respect to the basis b i the columns of B -1 describe the points of P, and B T AB = A is a matrix for π. The columns of B -1 and A -1 are identical up to an irrelevant change of signs in columns with odd indices. Therefore, with respect the basis b i , the simplex Q plays the role of P, and vice versa. So the assertion follows from the result in the preceding paragraph.

Ad (b): For each j ∈ {0, 2, . . . , n -1} the lines P j Q j and P j+1 Q j+1 meet at that point which is given by the vector

-e j + q j = -(e j+1 + q j+1 ) = (-1, 1, . . . , -1, 1, -1, -1 j, j+1 , 1, -1, . . . , 1, -1) T . ( 12
)
Comparing signs we see that -e 0 + q 0 and -e 2 + q 2 are linearly independent for Char K 2, whereas for Char K = 2 all lines

P k Q k , k ∈ {0, 1, . . . , n} concur at the point C := F(1, 1, . . . , 1) T . ( 13
)
Remark 1. Choose k + 1 distinct vertices of P, where 3 ≤ k ≤ n is odd. Up to a change of indices it is enough to consider the k-simplex {P 0 , P 1 , . . . , P k } and its span, say S . The null polarity π induces a null polarity π S in S which assigns to X ∈ S the (k -1)-dimensional subspace π(X) ∩ S . We get within S the settings of Theorem 1 with k rather than n points and π S instead of π. The nested nondegenerate Möbius pair in S is formed by the k-simplex {P 0 , P 1 , . . . , P k } and the k-simplex comprising the points

Q 0,k+1,...,n , Q 1,k+1,...,n , . . . , Q k,k+1,...,n . (14)
This observation illustrates the meaning of all the 2 n points which arise from P and the null polarity π. If we allow k = 1 in the previous discussion then, to within a change of indices, the nested degenerate Möbius pair {P 0 ,

P 1 } = {Q 0,2,...,n , Q 1,2,...,n } is obtained.
Remark 2. The case F = GF(2) deserves particular mention, since we can give an interpretation for all points of PG(n, 2) in terms of our Möbius pair. Recall the following notion from the theory of binary codes: The weight of an element of GF(2) n+1 is the number of 1s amongst its coordinates. The 2 n points addressed in Remark 1 are given by the vectors with odd weight. The 2 n vectors with even weight are, apart from the zero vector, precisely those vectors which yield the 2 n -1 points of the hyperplane π(C) : n+1 i=0 x i = 0. More precisely, the vectors with even weight w ≥ 4 are the centres of perspectivity for the nested non-degenerate Möbius pairs of (w-1)-simplices, whereas the vectors with weight 2 are the points of intersection of the edges of P with π(C). The latter points may be regarded as "centres of perspectivity" for the degenerate Möbius pairs formed by the two vertices of P on such an edge. Each point of the hyperplane π(C) is the centre of perspectivity of precisely one nested Möbius pair.

Commuting and non-commuting elements

Our aim is to translate the properties of Möbius pairs into properties of commuting and non-commuting group elements. We shortly recall some results from [START_REF] Havlicek | Factor-group-generated polar spaces and (multi-) qudits[END_REF]. Let (G, •) be a group and p be a prime. Suppose that the centre Z(G) of G contains the commutator subgroup G ′ = [G, G] and the set G (p) of pth powers. Also, let G ′ be of order p. Then V := G/Z(G) is a commutative group which, if written additively, is a vector space over GF(p) in a natural way. Furthermore, given any generator g of G ′ we have a bijection ψ g : G ′ → GF(p) : g m → m for all m ∈ {0, 1, . . . , p}. The commutator function in G assigns to each pair (x, y) ∈ G × G the element [x, y] = xyx -1 y -1 . It gives rise to the non-degenerate alternating bilinear form

[•, •] g : V × V → GF(p) : (xZ(G), yZ(G)) → ψ g ([x, y]). ( 15
)
We assume now that V has finite dimension n + 1, and we consider the projective space PG(n, p) := P(V). Its points are the one-dimensional subspaces of V. In our group theoretic setting a non-zero vector of V is a coset xZ(G) with x ∈ G \ Z(G).

The scalar multiples of xZ(G) are the cosets of the form x k Z(G), k ∈ {0, 1, . . . , p -1}, because multiplying a vector of V by k ∈ GF(p) means taking a kth power in G/Z(G). So x, x ′ ∈ G describe the same point X of PG(n, p) if, and only if, none of them is in the centre of G, and x ′ = x k z for some k ∈ {1, 2, . . . , p -1} and some z ∈ Z(G). Under these circumstances x (and likewise x ′ ) is said to represent the point X. Conversely, the point X is said to correspond to x (and likewise x ′ ). Note that the elements of Z(G) determine the zero vector of V. So they do not represent any point of PG(n, p). The non-degenerate alternating bilinear form from ( 15) determines a null polarity π in PG(n, p). We quote the following result from [6, Theorem 6]: Two elements x, y ∈ G \ Z(G) commute if, and only if, their corresponding points in PG(n, p) are conjugate with respect to π, i. e., one of the points is in the polar hyperplane of the other point. This crucial property is the key for proving Lemma 2 and Theorem 2 below. Lemma 2. Suppose that x 0 , x 1 , . . . , x r ∈ G \ Z(G) is a family of group elements. Then the following assertions are equivalent:

(a) The points corresponding to x 0 , x 1 , . . . , x r constitute an n-simplex of the projective space PG(n, p), whence r = n.

(b) There exists no element in G\Z(G) which commutes with all of x 0 , x 1 , . . . , x r , but for each proper subfamily of x 0 , x 1 , . . . , x r at least one such element exists.

Proof. The points corresponding to the family (x i ) generate PG(n, p) if, and only if, their polar hyperplanes have no point in common. This in turn is equivalent to the non-existence of an element in G \ Z(G) which commutes with all elements of the family (x i ). The proof is now immediate from the following observation: An n-simplex of PG(n, p) can be characterised as being a minimal generating family of PG(n, p).

This result shows that the dimension n + 1 of V can be easily determined by counting the cardinality of a family of group elements which satisfies condition (b). We close this section by translating Theorem 1: Theorem 2. Let G be a group which satisfies the assumptions stated in the first paragraph of this section. Also, let V = G/Z(G) be an (n + 1)-dimensional vector space over GF(p). Suppose that x 0 , x 1 , . . . , x n ∈ G \ Z(G) and y 0 , y 1 , . . . , y n ∈ G \ Z(G) are two families of group elements which represent a non-degenerate Möbius pair of PG(n, p) as in Theorem 1. Then the following assertions hold:

(a) There exists no element in G \ Z(G) which commutes with x 0 , x 1 , . . . , x n .

(b) The elements x 0 , x 1 , . . . , x n are mutually non-commuting.

(c) For each i ∈ {1, 2, . . . , n} the element x i commutes with all y j such that j i.

Each of these three assertions remains true when changing the role of the elements x 0 , x 1 , . . . , x n and y 0 , y 1 , . . . , y n .

Proof. The assertion in (a) follows from Lemma 2. Since all non-diagonal entries of the matrix A from (2) equal to 1, no two points which are represented by the elements x i are conjugate with respect to π. Hence (b) is satisfied. Finally, (c) follows, as the polar hyperplane of the point represented by x i contains all the points which are represented by the elements y j with j i. The last statement holds due to the symmetric role of the two simplices of a Möbius pair which was established in the proof of Theorem 1 (a). Remark 3. According to Remark 1 we may obtain nested non-degenerate Möbius pairs from appropriate subfamilies of x 0 , x 1 , . . . , x n . These Möbius pairs satisfy, mutatis mutandis, properties (b) and (c).

Example 1. We consider the complex matrices

σ 0 := 1 0 0 1 , σ x := 0 1 1 0 , σ y := 0 -i i 0 , σ z := 1 0 0 -1 . (16)
The matrices i α σ β with α ∈ {0, 1, 2, 3} and β ∈ {0, x, y, z} constitute the Pauli group P of order 16. The centre of P is Z(P) = i α σ 0 | α ∈ {0, 1, 2, 3} . The commutator subgroup P ′ = {±σ 0 } and the set P (2) = {±σ 0 } of squares are contained in Z(P). By Section 3, the factor group P/Z(P), if written additively, is a vector space over GF [START_REF] Brauner | Geometrie projektiver Räume II[END_REF]. For each β ∈ {0, x, y, z} the coset Z(P)σ β is denoted by β. In this notation, addition can be carried out according to the relations 0 + β = β, β + β = 0, and x + y + z = 0. The mapping 0 → (0, 0) T , x → (1, 0) T , y → (0, 1) T , z → (1, 1) T ( 17)

is an isomorphism of P/Z(P) onto the additive group of the vector space GF(2) × GF [START_REF] Brauner | Geometrie projektiver Räume II[END_REF].

Let G be the group of order 256 comprising the three-fold Kronecker products i α σ β ⊗ σ γ ⊗ σ δ with α ∈ {0, 1, 2, 3} and β, γ, δ ∈ {0, x, y, z}. This group acts on the eight-dimensional Hilbert space of three qubits. In our terminology from Section 3 (with p := 2) we have (2) = {±σ 0 ⊗ σ 0 ⊗ σ 0 }, [START_REF] Shaw | Finite geometry, Dirac groups and the table of real Clifford algebras[END_REF] and g = -σ 0 ⊗ σ 0 ⊗ σ 0 . Hence V = G/Z(G) is a six-dimensional vector space over GF(2) endowed with an alternating bilinear form [•, •] g . We introduce βγδ as a shorthand for Z(G)(σ β ⊗ σ γ ⊗ σ δ ), where β, γ, δ ∈ {0, x, y, z}. In this notation, addition in V can be carried out componentwise according to the relations stated before. An isomorphism of V onto GF(2) 6 is obtained by replacing the three symbols of an element of V according to [START_REF] Sengupta | Finite geometries with qubit operators[END_REF]. This gives the coordinate vector of an element of V. For example, the coordinate vectors of the six elements x00, y00, 0x0, 0y0, 00x, 00y ∈ V [START_REF] Thas | Pauli operators of N-qubit Hilbert spaces and the Saniga-Planat conjecture[END_REF] comprise the standard basis of GF(2) 6 . These six elements therefore form a basis of V. The projective space PG(5, 2) = P(V), like any projective space over GF(2), has the particular property that each of its points is represented by one and only one non-zero vector of V. We therefore identify V \ {000} with PG(5, 2). Recall the matrices defined in [START_REF] Berzolari | Sull' estensione del concetto di tetraedri di Möbius agli iperspazî[END_REF]. The matrix of the alternating bilinear form from [START_REF] Rau | Mapping two-qubit operators onto projective geometries[END_REF] with respect to the basis (19) equals to the 6 × 6 matrix diag(K, K, K) over GF [START_REF] Brauner | Geometrie projektiver Räume II[END_REF]. In order to obtain a Möbius pair

Z(G) = i α σ 0 ⊗ σ 0 ⊗ σ 0 | α ∈ {0, 1, 2, 3} , G ′ = G
P = {P 0 , P 1 , . . . , P 5 }, Q = {Q 0 , Q 1 , . . . , Q 5 } (20)
we have to use another basis of V, e. g., the one which arises in terms of coordinates from the six columns of the matrix

T :=           I J J 0 I J 0 0 I           . (21)
Indeed, T T • diag(K, K, K) • T gives an alternating 6 × 6 matrix A as in [START_REF] Brauner | Geometrie projektiver Räume II[END_REF]. We thus can translate our results from Section 2 as follows: First, we multiply T with the "old" coordinate vectors from there and, second, we express these "new" coordinate vectors as triplets in terms of 0, x, y, z. The vertices P 0 , P 1 , . . . , P 5 and Q 0 , Q 1 , . . . , Q 5 can be read off, respectively, from the first and second row of the following matrix: x00 y00 zx0 zy0 zzx zzy yzz xzz 0yz 0xz 00y 00x

We note that P and Q are in perspective from a point according to Theorem 1. This point is zzz. Since each line of PG(5, 2) has only three points, the entries of the second row in ( 22) can be found by adding zzz to the entries from the first row. We leave it to the reader to find the 6 4 = 15 nested Möbius pairs of tetrahedra which are formed by four points from P and the four appropriate points from (23). By Remark 2, the 32 points from ( 22) and (23) are precisely the points off the polar hyperplane of zzz. This means that none of the corresponding elements of G commutes with the representatives of the distinguished point zzz.

The results from [START_REF] Havlicek | Factor-group-generated polar spaces and (multi-) qudits[END_REF] show that Theorem 2 can be applied to a wide class of groups, including the generalised Pauli groups acting on the space of N-qudits provided that d is a prime number.

Conclusion

Following the strategy set up in our recent paper [START_REF] Havlicek | Factor-group-generated polar spaces and (multi-) qudits[END_REF], we have got a deeper insight into the geometrical nature of a large class of finite groups, including many asso-ciated with finite Hilbert spaces. This was made possible by employing the notion of a Möbius pair of n-simplices in a finite odd-dimensional projective space, PG(n, p), p being a prime. Restricting to non-degenerate Möbius pairs linked by a null polarity, we have first shown their existence for any odd n, a remarkable nested structure they form, and perspectivity from a point of the simplices in any such pair if p = 2. Then, the commutation properties of the group elements associated with a Möbius pair have been derived. In particular, the two disjoint families of n + 1 group elements that correspond to a Möbius pair are such that any two distinct elements/operators from the same family do not commute and each element from one family commutes with all but one of the elements from the other family. As the theory also encompasses a number of finite generalised Pauli groups, that associated with three-qubits (n = 5 and p = 2) was taken as an illustrative example, also because of envisaged relevance of Möbius pairs to entanglement properties of a system of three fermions with six single-particle states [START_REF] Lévay | Three fermions with six single-particle states can be entangled in two inequivalent ways[END_REF]. It should, however, be stressed that above-outlined theory is based on a particular construction of Möbius pairs, and so there remains an interesting challenge to see in which way it can be generalised to incorporate arbitrary Möbius pairs.

Note that indices range from 0 to n.

Acknowledgements

This work was carried out in part within the "Slovak-Austrian Science and Technology Cooperation Agreement" under grants SK 07-2009 (Austrian side) and SK-AT-0001-08 (Slovak side), being also partially supported by the VEGA grant agency projects Nos. 2/0092/09 and 2/7012/27. The final version was completed within the framework of the Cooperation Group "Finite Projective Ring Geometries: An Intriguing Emerging Link Between Quantum Information Theory, Black-Hole Physics, and Chemistry of Coupling" at the Center for Interdisciplinary Research (ZiF), University of Bielefeld, Germany.