text:
# The CAVES Project - Exploring Virtual Data Concepts for Data Analysis To Dad

## I INTRODUCTION

Most data in contemporary science are the product of increasingly complex computations and procedures applied on the fast increasing flows of raw information coming from more and more sophisticated measurement devices (the “measurements”), or from growingly detailed numeric simulations - e.g. pattern recognition, calibration, selection, data mining, noise reduction, filtering, estimation of parameters etc. High energy physics and many other sciences are increasingly CPU and data intensive. In fact, many new problems can only be addressed at the high data volume frontier. In this context, not only data analysis transformations, but also the detailed log of how those transformations were applied, become a vital intellectual resource of the scientific community. The collaborative processes of these ever-larger groups require new approaches and tools enabling the efficient sharing of knowledge and data across a geographically distributed and diverse environment.

Here is where the concept of virtual data is bound to play a central role in the scientific analysis process. We will explore this concept using as a case study the coming generation of high energy physics (HEP) experiments at the Large Hadron Collider (LHC), under construction at the European Laboratory for Particle Physics CERN close to Geneva, Switzerland. This choice is motivated by the unprecedented amount of data (from petabytes to exabytes) and the scale of the collaborations that will analyze it (four worldwide collaborations, the biggest two with more than two thousand scientists each). At the same time, the problems to be solved are general and will promote scientific discoveries in different disciplines, enhance business processes and improve security. The challenge facing HEP is a major driving force for new developments in computing, e.g. the Grid gridblueprint ; gridanatomy . The computing landscape today is marked by the rise of Grid gridphysiology  and Web services w3cwebserv  and service oriented architectures (SOA) soa . An event-driven SOA is well suited for data analysis and very adaptable to evolution and change over time. In our project we will explore and adopt service oriented solutions as they mature and provide the performance needed to meet mission-critical requirements.

This paper is organized as follows: in the next section we introduce the concept of virtual data, than we discuss the issues arising when dealing with data equivalence, describe how data analysis is done in HEP, digress with a metaphor, elucidate the ideas driving the CAVES project, continue with a detailed treatment of the CAVES architecture, sketch the first implementation, discuss the relationship with other Grid projects, and conclude with an outlook.

## II VIRTUAL DATA

The scientific analysis process demands the precise tracking of how data products are to be derived, in order to be able to create and/or recreate them on demand. In this context virtual data are data products with a well defined method of production or reproduction. The concept of “virtuality” with respect to existence means that we can define data products that may be produced in the future, as well as record the “history” of products that exist now or have existed at some point in the past.

The virtual data paradigm logs data provenance by tracking how new data is derived from transformations on other data chimera ; chimera2 . Data provenance is the exact history of any existing (or virtual) data product. Often the data products are large datasets, and the management of dataset transformations is critical to the scientific analysis process.

We need a “virtual data management” tool that can “re-materialize” data products that were deleted, generate data products that were defined but never created, regenerate data when data dependencies or algorithms change, and/or create replicas at remote locations when recreation is more efficient than data transfer.

From the scientist’s point of view, data trackability and result auditability are crucial, as the reproducibility of results is fundamental to the nature of science. To support this need we require and envision something like a “virtual logbook” that provides the following capabilities:

* easy sharing of tools and data to facilitate collaboration - all data comes complete with a “recipe” on how to produce or reproduce it;
* individuals can discover in a fast and well defined way other scientists’ work and build from it;
* different teams can work in a modular, semi-autonomous fashion; they can reuse previous data/code/results or entire analysis chains;
* on a higher level, systems can be designed for workflow management and performance optimization, including the tedious processes of staging in data from a remote site or recreating it locally on demand (transparency with respect to location and existence of the data).

## III DATA EQUIVALENCE

If we delete or accidentally loose a piece of data, having a log of how it came into existence will come in handy. Immediately the question arises: is the “new” chunk of data after reproduction identical to the “old” one? There are two extreme answers to this question:

* the two pieces of data are identical bitwise - we are done;
* not only are the two pieces of data not identical bitwise, but they contain different information from the viewpoint of the application using them.

The second point needs discussion: clearly two chunks of data can be “identical enough” for some types of applications and different for other types. Each application has to define some “distance” measure between chunks of data and specify some “minimal” distance between chunks below which the pieces are considered identical. In this language bitwise sameness would correspond to zero distance.

Let us illustrate this with two examples. In an ideal world, if we generate events with the Monte Carlo method, starting from the same seeds and using portable random number generators, we should get the same sequence of events everywhere. Or if we do Monte Carlo integration, we should get exactly the same result. In practice, due to floating point rounding errors, even on systems with processors with the same word length simulations tend to go down different branches, diverging pretty soon. So the results are not guaranteed to be identical bitwise. Usually this is not a problem: two Monte Carlo integrations within the statistical uncertainty are certainly acceptable. And even two different sequences of events, when their attributes are statistically equivalent (e.g. histograms of all variables, correlations etc.), are good enough for many practical purposes. There are exceptions though: if our code crashes at event 10583, we would like to be able to reproduce it bitwise. One way to proceed in such a situation is to store the initial random seeds for each event along with the how-to (i.e. the algorithm and code for producing events). Then any single divergence will affect at most one event.

The second example is analysis of real data. If we are interested in statistical distributions (histograms, scatter plots, pie charts etc.), a “weak” equivalence in the statistical sense can be enough. If we are selecting e.g. rare events in a search for new particles, we would like to isolate the same sample each time we run a particular selection on the same input (“strong” equivalence). One way to proceed here is to keep the list of selected events along with the how-to of the selection for future verifications. As long as the input sample is available, we will have reproducibility of the selection even if portability is not guaranteed.

To sum it up - each application has to define criteria establishing the equivalence of data for its domain. Good choice of metadata about a chunk of data (e.g. a dataset) can be very useful later when trying to decide if your reproduction is good enough. For instance, if we kept the moments like mean value and standard deviation with their statistical uncertainties from a distribution with millions of events, it will help in determining if our replica is statistically equivalent later.

Last but not least, an important aspect in recording the data provenance is the level of detail. The result of the execution of the same algorithm with the same input in today’s complex software world may depend on environment variables, linked libraries containing different versions of supporting applications, different compilers or levels of optimization etc. When these factors are important, they have to be included in the data provenance log for future use.

## IV DATA ANALYSIS IN HEP

The high energy physics field is sociologically very interesting. The experimental collaborations have grown from being counted on the fingers of one or two hands in the sixties to around five hundred in the nineties and two thousand today. Even in theoretical physics collaborations are growing with time. That explains why the field was always in the forefront of developing and/or adopting early new collaborative tools, the best known example being of course the invention of the World Wide Web at CERN. At present, the LHC experiments are heavily involved in Grid efforts, continuing the tradition, see e.g. griphyn ; ppdg ; eudatagrid ; ivdgl ; lcg ; egee .

After a high energy physics detector is triggered, the information from the different systems is read and ultimately recorded (possibly after cleaning, filtering and initial reconstruction) to mass storage. The high intensity of the LHC beams usually results in more than one interaction taking place simultaneously, so a trigger records the combined response to all particles traversing the detector in the time window when the system is open. The first stages in the data processing are well defined and usually tightly controlled by the teams responsible for reconstruction, calibration, alignment, “official” simulation etc. The application of virtual data concepts in this area is discussed e.g. in cmsprod .

Here we are interested in the later stages of data processing and analysis, when various teams and individual scientists look at the data from many different angles - refining algorithms, updating calibrations or trying out new approaches, selecting and analyzing a particular data set, estimating parameters etc., and ultimately producing and publishing physics results. Even in today’s large collaborations this is a decentralized, ”chaotic” activity, and is expected to grow substantially in complexity and scale for the LHC experiments. Decentralization does not mean lack of organization - on the contrary, this will be one of the keys for building successful structures, both from the social and technical points of view. Clearly flexible enough systems, able to accommodate a large user base, and use cases not all of which can be foreseen in advance, are needed. Many users should be able to work and share their results in parallel, without stepping on each other’s toes. Here we explore the benefits that a virtual data system can bring in this vast and dynamic field.

Moving from production to analysis, the complexity grows fast with the number of users while the average wall and CPU time to complete a typical task goes down, as illustrated in Figure 1.

An intermediate phase are large analysis tasks which require batch mode. The ultimate challenge comes from interactive analyses, where users change their minds often and need fast response times to stay productive. The latency of the underlying systems at this stage is critical. There should be no single point of failure and the system should re-route requests automatically to the next available service. The redundancy should be accompanied by efficient synchronization, so that new results are published fast and made accessible for all interested parties regardless of their geographical location.

An important feature of analysis systems is the ability to build scripts and/or executables “on the fly”, including user supplied code and parameters. On the contrary, production systems often rely on pre-build applications, distributed in a centralized way from “officially controlled” repositories. The user should be in position to modify the inputs on her/his desk(lap)top and request a derived data product, possibly linking with preinstalled libraries on the execution sites. A grid-type system can store large volumes of data at geographically remote locations and provide the necessary computing power for larger tasks. The results are returned to the user or stored and published from the remote site(s). An example of this vision is presented in Arbree:2003wh . At each stage in the analysis interesting events can be visualized and plots for all quantities of interest can be produced.

What will a virtual data system bring to this picture? I have in my office a large collection of paper folders for different analyses performed working on various tasks, stored in varied ways. They match with codes stored and archived on different systems. So when a colleague comes in and asks me how I obtained that plot three months ago, I have to sift for some time (depending on my organization) through my folders, make a photocopy, then find the corresponding code, make sure it is the “historically” right version, and that I wrote down which version of the pattern recognition was used at the time etc. Or if I go to my colleague, she will go through similar steps, but her organization will be different and we will possibly exchange information in a different format. Or if one of us is on leave things will slow down. So we are recording data provenance, but manually, very often incomplete, and not easily accessible. And clearly this scales poorly for larger and geographically distributed collaborating groups.

In a “virtual logbook” all steps of an analysis, even the blind alleys, can be recorded and retrieved automatically. Let us assume that a new member joins the group. Even without bugging one’s colleagues too often, it will be quite easy to discover exactly what has been done so far for a particular analysis branch, to validate how it was done, and to refine the analysis. A scientist wanting to dig deeper can add a new derived data branch by, for example, applying a more sophisticated selection, and continuing to investigate down the new road. Of course, the results of the group can be shared easily with other teams and individuals in the collaboration, working on similar topics, providing or re-using better algorithms etc. The starting of new subjects will profit from the availability of the accumulated experience. At publication time it will be much easier to perform an accurate audit of the results, and to work with internal referees who may require details of the analysis or additional checks.

## V A METAPHOR

At the beginning of a new project, a suitable metaphor can be helpful. As we would like to make our “virtual data logbooks” persistent, distributed and secure, the following analogy came quite naturally:

* A cave is a secure place to store stuff.
* Usually you need a key to enter.
* Stuff can be retrieved when needed (and if the temperature is kept constant, usually in good shape).
* Small caves can be private, larger ones are usually owned by cooperatives.
* When a cave is full, a new one is build.
* To get something, one starts at the local caves and, if needed, widens the search …

We can go on, but, as we will see in a moment, these are striking similarities with the goals of our project, so CAVES seemed a peculiarly apt name. The use of metaphors is inspired from the adoption of extreme programming techniques beck  in our project. For their relationship to the programming style in HEP see carmin .

## VI CAVES PROJECT

The Collaborative Analysis Versioning Environment System (CAVES) project concentrates on the interactions between users performing data and/or computing intensive analyses on large data sets, as encountered in many contemporary scientific disciplines. In modern science increasingly larger groups of researchers collaborate on a given topic over extended periods of time. The logging and sharing of knowledge about how analyses are performed or how results are obtained is important throughout the lifetime of a project. Here is where virtual data concepts play a major role. The ability to seamlessly log, exchange and reproduce results and the methods, algorithms and computer programs used in obtaining them enhances in a qualitative way the level of collaboration in a group or between groups in larger organizations.

It makes it easier for newcomers to start being productive almost from day one of their involvement or for referees to audit a result and gain easy access to all the relevant details. Also when scientists move on to new endeavors they can leave their expertise in a form easily utilizable by their colleagues. The same is true for archiving the knowledge accumulated in a project for reuse in future undertakings.

The CAVES project takes a pragmatic approach in assessing the needs of a community of scientists by building series of prototypes with increasing sophistication. Our goal is to stay close to the end users and listen carefully to their needs at all stages of an analysis task. In this way we can develop an architecture able to satisfy the varied requirements of a diverse group of researchers.

Our main line of development draws on the needs of, but is not limited to, high energy physics experiments, especially the CMS collaboration cms ; cmssoft ; cmsweb , planning to begin data taking in 2007 at the Large Hadron Collider. The CMS experiment will produce large amounts of simulated and real data, reaching tens and hundreds of petabytes. The analysis of datasets of this size, with its distributed nature, by a large community of users is a very challenging task and one of the strongest driving forces for Grid computing. The CAVES project explores and develops these emerging technologies to facilitate the analysis of real and simulated data. We start by analyzing the simulated data from the data challenges of the CMS experiment, which will grow in scale and complexity approaching the situation when real data will start to flow.

In extending the functionality of existing data analysis packages with virtual data capabilities, we build functioning analysis suites, providing an easy and habitual entry point for researchers to explore virtual data concepts in real life applications, and hence give valuable feedback about their needs, helping to guide the most useful directions for refining the system design. By just adding capabilities in a plug-in style we facilitate the acceptance and ease of use, and thus hope to attract a critical mass of users from different fields in a short time. There is no need to learn yet another programming language, and our goal is simplicity of design, keeping the number of commands and their parameters to the bare minimum needed for rich and useful functionality.

The architecture is modular based on Web, Grid and other services which can be plugged in as desired. In addition to working in ways considered standard today the scientists are able to log or checkpoint their work throughout the lifetime of an analysis task. We envisage the ability to create private “checkpoints” which can be stored on a local machine and/or on a secure remote server. When an user wants to share some work, he can store the relevant know-how on the group servers accessible to the members of a group working on a given task. This could be a geographically distributed virtual organization. In the case of collaboration between groups or with internal or external referees portions of this know-how can be made accessible to authorized users, or a shared system of servers can be created as needed. The provenance of results can be recorded at different levels of detail as decided by the users and augmented by annotations. Along with the knowledge of how analyses are performed, selected results and their annotations can be stored in the same system. They can be browsed by the members of a group, thus enhancing the analysis experience both for experts and newcomers. When desirable, information from different phases of an analysis can easily be shared with other groups or peers.

We stressed already the value of complete logs. In the heat of an active analysis session, when there is no time or need to be pedantical, users may see merit in storing sometimes also partial logs, a classical example being a program with hidden dependencies, e.g. the calling of a program or reading of a file within a program, not exposed externally. In this case, the data product is not reproducible, but at least the log will point what is missing. Or the users may even store a non-functional sequence of actions in the debugging phase for additional work later, even without producing a virtual data product. Our system should be able to support partial logging, provided that the users are aware of the limitations and risks of this approach.

An important point is how groups will structure their analyses. Each virtual data product needs an unique identifier, which may be provided by the users or appended automatically by the system with e.g. project id, user id and date to render it unique. For smaller tasks, all identifiers and logs can be located in a single place, like a big barrel in a cave. Then the group will benefit from adopting a policy for meaningful selection of identifiers, making subsequent browsing and finding of information easy. For larger projects the virtual data space can be structured in chunks corresponding to subtasks, like many barrels in a large cave. Then at the beginning of a session the user will select the barrel to be opened for that session. When needed, information from related (linked) barrels can be retrieved. In principal there are no restrictions on how deep the hierarchy can be, only the practical needs will determine it.

We base our first functional system on popular and well established data analysis frameworks and programming tools, making them virtual data enabled. In the course of our project we will leverage best-of-breed existing technologies (e.g. databases, code management systems, Web services), as well as the developments in forward-looking Grid enabled projects, e.g. the virtual data system CHIMERA chimera ; chimera2 , the CLARENS server clarens  for secure remote dataset access, the Condor condor , PEGASUS pegasus  and SPHINX sphinx  schedulers for executing tasks in a Grid environment. Further down the road we envisage building distributed systems capable of analyzing the datasets used in the CMS collaboration at all stages of data analysis, starting from Monte Carlo generation and simulation of events through reconstruction and selection all the way to producing results for publication. We plan to use the Grid test bed of the Grid Physics Network (GriPhyN) project griphyn  for Grid enabling the collaborative services. The GriPhyN Project is developing Grid technologies for scientific and engineering projects that will collect and analyze distributed, petabyte-scale datasets. GriPhyN research will enable the development of Petascale Virtual Data Grids (PVDGs) through its Virtual Data Toolkit (VDT vdt ).

## VII CAVES ARCHITECTURE

The CAVES system can be used as a building block for a collaborative analysis environment, providing “virtual data logbook” capabilities and the ability to explore the metadata associated with different data products.

Our first functioning system extends the very popular object-oriented data analysis framework ROOT root , widely used in high energy physics and other fields, making it virtual data enabled. The ROOT framework provides a rich set of data analysis tools and excellent graphical capabilities, able to produce publication-ready pictures. It is easy to execute user code, written in C++, and to extend the framework in a plug-in style. New systems can be developed by subclassing the existing ROOT classes. And the CINT cint  interpreter runs the user code “on-the-fly”, facilitating fast development and prototyping. All this is very helpful in the early phases of a new project. In addition, ROOT has a large and lively user base, so we plan to release early and often and to have a development driven largely by user feedback. Last but not least, ROOT is easy to install and very portable. Versions for many flavors of LINUX and UNIX and for Windows are available.

We leverage a well established source code management system - the Concurrent Versions System CVS cvs . It is well suited to provide version control for a rapid development by a large team and to store, by the mechanism of tagging releases, many versions so that they can be extracted in exactly the same form even if modified, added or deleted since that time. The CVS tags assume the role of unique identifiers for virtual data products. CVS can keep track of the contributions of different users. The locking mechanism makes it possible for two or more people to modify a file at the same time, important for a team of people working on large projects. The system has useful self-documenting capabilities. Besides the traditional command line interface several products provide Web frontends which can be used when implementing Web services. All these features of CVS make it a good match for our system. Nowadays CVS is already installed by default on most UNIX and LINUX systems and a Windows port is available. In this way, our system can be used both from UNIX and Windows clients, making it easy for users at all levels to reproduce results.

A key aspect of the project is the distributed nature of the input data, the analysis process and the user base. This has to be addressed from the earliest stages. Our system should be fully functional both in local and remote modes, provided that the necessary repositories are operational and the datasets available. This allows the users to work on their laptops (maybe handhelds tomorrow) even without a network connection, or just to store intermediate steps in the course of an active analysis session for their private consumption, only publishing a sufficiently polished result. This design has the additional benefit of utilizing efficiently the local CPU and storage resources of the users, reducing the load on the distributed services (e.g. Grid) system. The users will have the ability to replicate, move, archive and delete data provenance logs. Gaining experience in running the system will help to strike the right balance between local and remote usage. More details about the distribution of services is given in the next section.

The architecture of CAVES builds upon the concept of sandbox programming. By sandbox programming we mean users work on per session basis, creating a new sandbox for a given session. All the changes or modifications and work the user does in a session between checkpoints is logged into a temporary logfile, which can be checked in the CVS repository with a unique tag. The system checks if the user executed external programs (in the ROOT case these are typically C++ programs) and logs them automatically with the same tag. Here an interesting point arises: a possible scenario is that a user runs the same program many times, just varying the inputs. In this case CVS will do the right thing: store the program only once, avoiding duplication of code, and tagging it many times with different tags, reflecting the fact that the program was executed several times to produce distinct data products. Or the user can choose during the same session to browse through the tags of other users to see what work was done, and select the log/session of interest by extracting the peers log with the tag used to log the corresponding session activities. Here two modes of operation are possible: the user may want to reproduce a result by extracting and executing the commands and programs associated with a selected tag, or just extract the history of a given data product in order to inspect it, possibly modify the code or the inputs and produce new results.

We also have the concept that users can log annotations or results in the repository along with the data provenance, storing useful metadata about a data product for future use (see the discussion in the data equivalence section). It is possible to record the metadata in relational databases too, e.g. in popular open source products like MySQL MySQL , so that another user first queries the database to retrieve the annotations or condensed logs of what other users have done already. This approach will ensure scalability for large groups of researchers accumulating large repositories, and will reduce the load on the CVS servers, improving the latency of the overall system. In this case the searching of a database is expected to be faster than the direct search for a given tag among a large number of stored tags. This will be investigated by building functional systems and monitoring their performance. The additional burden of synchronizing the information between the databases and the repositories is worthwhile only if we can improve the overall performance and scalability of the system. A further enhancement can come from retrieving first the metadata, and only if the user is interested, the complete log about a particular data product.

The architecture is shown in graphical form in Figure 2.

Let us discuss now some possible scenarios, which can take place in our architecture.

Case1: Simple
User 1 : Does some analysis and produces a result with tag projectX-stepY-user1.
User 2: Browses all current tags in the repository and fetches the session stored with tag projectX-stepY-user1.

Case2: Complex
User 1 : Does some analysis and produces a result with tag projectX-stepY-user1.
User 2: Browses all current tags in the repository and fetches the session stored with tag projectX-stepY-user1.
User 2: Does some modifications in the code files, which were obtained from the session of user1, runs again and stores the changes along with the logfile with a new tag projectX-stepY-modcode-user2.
User 1: Browses the repository and discovers that the previous session was used and contains modified or new code files, so decides to extract that session using the new tag projectX-stepY-modcode-user2 and possibly reuse it to produce the next step and so on.
This scenario can be extended to include an arbitrary number of steps and users in a working group or groups in a collaboration.

Based on our work so far, the following set of commands emerges as useful:

1. Session commands:

* open $`<\mathrm{session}>`$ : authentication and authorization, connection, selection of CVS services, local or remote mode, the barrel to be opened etc.
    * close $`<\mathrm{session}>`$ : save opened sessions, clean-up etc.
2. During analysis:

* help $`<\mathrm{command}>`$ : get help for a command or list of commands
    * browse $`<\mathrm{tag}>`$ : browse all tags in (a part of) a repository, subsets of tags beginning or containing a string etc; possibly browse the metadata about a specific virtual data product e.g. by clicking on a selected tag from a list displayed in a graphical user interface
    * startlog : define the starting checkpoint for a log (part of a session between user-defined points), which will be closed by a log command
    * log $`<\mathrm{tag}>`$ : log (part of) a session between user-defined checkpoints together with all programs executed in the session; this may be a complete or optionally a partial log with user-defined level of detail
    * annotate $`<\mathrm{tag}>`$ : store user-supplied notes (metadata) about the work being done, preferably in a concise and meaningful manner; optionally, selected results can be stored along with the annotations e.g. a summary plot, subject of course to space considerations; this can be a separate command or part of the log command e.g. the user may select to be prompted to provide annotations when logging a tag
    * inspect $`<\mathrm{tag}><\mathrm{brief}|\mathrm{complete}>`$ : get a condense (annotations plus user commands, in a sense something like header files), or the complete log for a tag including the programs executed, but do not reproduce the data product; useful for reusing analysis work
    * extract $`<\mathrm{tag}>`$ : in addition to inspect, reproduce the virtual data product
3. Administrative tasks:

* copy $`<\mathrm{tag}>`$ $`<\mathrm{from}>`$ $`<\mathrm{to}>`$ : clone a log to a new repository
    * move $`<\mathrm{tag}>`$ $`<\mathrm{from}>`$ $`<\mathrm{to}>`$ : as you expect
    * delete $`<\mathrm{tag}>`$ $`<\mathrm{from}>`$ : remove a log; CVS has the nice feature of storing such files in the Attic, so it is similar to moving a file in the Trash can without emptying it
    * archive $`<\mathrm{tag}>`$ $`<\mathrm{to}>`$ : store in an archive (e.g. a mass storage system)
    * retrieve $`<\mathrm{tag}>`$ $`<\mathrm{from}>`$ : retrieve from an archive (for whole repositories normal CVS techniques can be used).

Our first release is based on the minimal scope of commands providing interesting functionality. Future developments will be guided by the value users put on different options. As we want a fast release cycle this limits the number of features introduced and tested in any new version. The command set is extensible and new commands may be introduced as needed.

## VIII FIRST IMPLEMENTATION

In this section we sketch the process of building the first CAVES release as prototype of a real analysis system, and examine some of the issues that arise. The first prototype has been demonstrated at the Supercomputing conference in Phoenix, Arizona, in November 2003, and the first release was made public on December 12, 2003. More details can be found in cavestalk01 , and an in-depth technical description about the virtual data enabled ROOT client and the remote services is in preparation caves01 .

We limit the scope to the most basic commands described in the previous section:

* open $`<\mathrm{session}>`$ : sets the CVS service (default or user choice)
* help: short help about the commands below
* browse $`<\mathrm{tag}>`$ : browse tags in the repository
* log $`<\mathrm{tag}>`$ : log part of a session between user-defined checkpoints
* extract $`<\mathrm{tag}>`$ : reproduce a virtual data product.

These commands are implemented by subclassing basic ROOT classes. Commands not recognized by our system are delegated to ROOT for execution or catching exceptions.

The ROOT framework provides the ability to access both local and remote files and datasets. One way to realize the second option is to store datasets on APACHE apache  servers which are ROOT-enabled with a plug-in provided by the ROOT team. In this way we implement a remote data service from Web servers.

The CVS system also is able to access both local and remote repositories. One way to realize the second option is to use the CVS pserver. Contrary to some opinions it can be configured in quite a secure and efficient way as follows: the remote users need just CVS accounts with password authentication, they never get UNIX accounts on the server. A dedicated CVS user (or several for different groups) acts on their behalf on the server. The mapping is done by a special CVS administrative file. Similar design was adopted by the Globus globus  toolkit with the grid mapfiles to control user access to remote sites, the only difference being the use of certificates in place of passwords, thus enhancing the security and providing a temporarily limited single sign-on to a Grid. The virtual organization tools developed by Globus can be used also for CVS services. In addition, we implement access control lists per CVS user for reading of the repository or writing to specific directories only for authorized users. This makes the server secure: even compromising the password a normal user can not modify administrative files and thus can not run shell commands on the server. Only the administrator needs an UNIX server account. Adding and managing CVS users is undoubtedly much simpler, safer and more scalable compared to dealing with UNIX accounts, not to talk about the dreaded group variety. A single server can handle multiple repositories, making it easy to “fine structure” projects.

To test the functionality after each modification we have a test suite: we use events generated with PYTHIA pitia  (or the CMS PYTHIA implementation in CMKIN), and analyze, histogram and visualize them with code pythview  (for results obtained with this code see e.g. Bourilkov:2003kj ; Bourilkov:2003kk ) built on top of the object-oriented data analysis framework ROOT root . To conclude we give a couple of snapshots of the first CAVES system in action:

```

START a virtual data enabled ROOT client: rltest

rltest

*************************************************************************
*                        Welcome To CAVES                               *
*       Collaborative Analysis Versioning Environment System            *
*                                                                       *
*                  Dimitri Bourilkov & Mandar Kulkarni                  *
*                       University of Florida                           *
*                         Gainesville, USA                              *
*                                                                       *
*                  You are Welcome to visit our website                 *
*                       cern.ch/bourilkov/caves.html                    *
*************************************************************************

 Please set the cvs pserver OR hit enter for default

CAVES:

 Pserver for this session:  :pserver:test@ufgrid02.phys.ufl.edu:/home/caves

*************************************************************************
*                        TO GET STARTED:                                *
*                  just type  help  at the command prompt               *
*                                                                       *
*            commands beginning with ’.’ are delegated to ROOT          *
*************************************************************************
CAVES: help

List of commands and how to use them:

  === help : to get this help

    help

  === browse : to list all existing tags or a subset beginning with string
  ===>       de facto the content of the virtual data catalog is displayed

    browse
    browse <prefix-string-of-tag>

  === log : to store all command line activities of the user labeling them with a tag
  ===         the actions after the last log command OR
  ===         from the beginning of the session are stored
  ===
  ===         <tag> must be CVS compliant i.e. start with uppercase or lowercase letter
  ===         and contain uppercase and lowercase letters, digits, ’-’ and ’_’
  ===         HINT: this a powerful tool to structure your project
  ===
  ===>      in effect this logs how a chunk of virtual data was produced
  ===>      and can be (re)produced later; the macro files executed by the user
  ===>      are stored in their entirety along with the command line activities
  ===>      creating a complete log

    log <tag>

  === extract : to produce a chunk of virtual data identified by a tag
  ===>      the necessary macro files are downloaded automatically to the client
  ===>      and can be reused and modified for new analyses

    extract <tag>

CAVES: browse
higgs-ww-plotpxpypz-500  Ψ(revision: 1.5)

higgs-ww-plotpxpypz-100  Ψ(revision: 1.4)

CAVES: extract higgs-ww-plotpxpypz-500
********************Storing data for usage....*********************
ROOT Command is :.x
Macro is :dbpit1web.C
Macro is :dbpit1web.C
U data/dbpit1web.C
You have [0] altered files in this repository.
Are you sure you want to release (and delete) directory ‘data’: y
Argument is 500
Argument is input "http://ufgrid02.phys.ufl.edu/~bourilkov/higgs.root"
Argument is output "higgs-ww-plotpxpypz-500"
Command is :.x dbpit1web.C(500,"http://ufgrid02.phys.ufl.edu/~bourilkov/higgs.root",
"higgs-ww-plotpxpypz-500")
TFile**ΨΨhiggs-ww-plotpxpypz-500.rootΨ
 TFile*ΨΨhiggs-ww-plotpxpypz-500.rootΨ
  KEY: TCanvasΨcanv2;1ΨROOT PYTHIA Plotter  D.Bourilkov  University of Florida
.x dbpit1web.C(500,"http://ufgrid02.phys.ufl.edu/~bourilkov/higgs.root",
"higgs-ww-plotpxpypz-500")

**************************End****************************
You have [0] altered files in this repository.
Are you sure you want to release (and delete) directory ‘v01’: y
CAVES: .q
.q

```

The running of this example produces the following plot from five hundred simulated input events, as illustrated in Figure 3.

It is worth mentioning that the plot materializes on the client machine out of “thin air”. The user can first download the CAVES code from our remote repository and needs just ROOT and CVS to build the client in no time. Then the remote logs are browsed, one is selected for extraction, the corresponding commands and programs are downloaded, built on the fly and executed on the client machine, the input data are accessed from our remote Web data server, “et voilà”, the plot pops up on the client’s machine.

An example of our event display built also on top of ROOT is shown in Figure 4.

## IX RELATIONSHIP WITH OTHER GRID PROJECTS

We envisage extending the service oriented architecture by encompassing Grid and Web services as they mature and provide the performance needed to meet mission-critical requirements. Our system will benefit from developments like the Globus authentication system, enhancing the security and providing a temporarily limited single sign-on to Grid services, the GriPhyN Virtual Data Toolkit for job executions on Grids, possibly augmented by Grid schedulers like SPHINX or PEGASUS. Other promising developments are remote data services e.g. CLARENS, which can possibly be used also with our set of CVS services to provide a Globus Security Infrastructure, distributed databases etc. Another closely watched development is the GriPhyN virtual data system Chimera, which evolves a virtual data language. Our “virtual data logbooks” in the first implementation are formatted as standard ASCII files, in future versions we might use also a more structured format e.g. XML, which is well suited for Web services. Chimera also converts the virtual data transformations and derivations to XML and further to directed acyclic graphs. It is a challenging research question if all analysis activities can be expressed easily in the present Chimera language. With the developments of both projects it may be possible to generate automatically virtual data language derivations from our logs of interactive ROOT sessions for execution on a Grid or storage in a Chimera virtual data catalog.

Another promising path is integration with the ROOT/PROOF Ballintijn:2003yt  system for parallel analysis of large data sets.

CAVES can be used as a building block for a collaborative analysis environment in a Web and Grid services oriented architecture, important at a time when Web and Grid services are gaining in prominence. We are monitoring closely the evolving architecture and use cases of projects like CAIGEE caigee , HEPCAL hepcal , ARDA arda  and collaborative workflows workflow , and are starting useful collaborations. Besides the ROOT-based client a Web browser executing commands on a remote ROOT or CLARENS server is a possible development for “ultralight” clients.

## X OUTLOOK

In this white paper we have developed the main ideas driving the CAVES project for exploring virtual data concepts for data analysis. The decomposition of typical analysis tasks shows that the virtual data approach bears great promise for qualitatively enhancing the collaborative work of research groups and the accumulation and sharing of knowledge in todays complex and large scale scientific environments. The confidence in results and their discovery and reuse grows with the ability to automatically log and reproduce them on demand.

We have built a first functional system providing automatic data provenance in a typical analysis session. The system has been demonstrated successfully at Supercomputing 2003 and a first public release is available for interested users, which are encouraged to visit our Web pages, currently located at the following URL:
http://cern.ch/bourilkov/caves.html

###### Acknowledgements.

In the process of shaping and launching the project the author enjoyed discussions with Paul Avery, Rene Brun, Federico Carminati, Harwey Newman, Lothar Bauerdick, David Stickland, Stephan Wynhoff, Torre Wenaus, Rob Gardner, Fons Rademakers, Richard Cavanaugh, John Yelton, Darin Acosta, Mike Wilde, Jens Vöckler, Conrad Steenberg, Julian Bunn, Predrag Buncic and Martin Ballantijn. The coffee pauses with Jorge Rodriguez were always stimulating. The first prototype and first release are coded by Mandar Kulkarni and myself, the members of the CAVES team at present. This work is supported in part by the United States National Science Foundation under grants NSF ITR-0086044 (GriPhyN) and NSF PHY-0122557 (iVDGL).


format: text

text:
# 1 𝑅 measurements in the c.m. energy range from 2.0 to 3.73 GeV from BES [] with best fit, 𝑅=2.26±0.04.

## Abstract

The latest data for $`J/\psi `$ and $`\psi ^{}`$ leptonic decays, and the latest measurement of the R–parameter are used to show that the present summary values of the branching ratios of the virtual photon mediated hadronic decays of both $`J/\psi `$ and $`\psi ^{}`$ are overestimated. The current best results are $`B(J/\psi \gamma ^{}h)=(13.3\pm 0.3)`$%, and $`B(\psi ^{}\gamma ^{}h)=(1.65\pm 0.10)`$%.

Hadronic Decays of $`J/\psi `$(1$`{}_{}{}^{3}S_{1}^{}`$) and $`\psi ^{}`$(2$`{}_{}{}^{3}S_{1}^{}`$) Through Vitrual Photons

Kamal K. Seth

Northwestern University, Evanston, Illinois 60208

The $`J/\psi `$(3097) and $`\psi ^{}`$(3686) 1 states of charmonium couple to leptons only through virtual photons, and the branching ratios $`B(J/\psi ,\psi ^{}\gamma ^{}hadrons)`$ are among the largest decay ratios for both. These ratios were first reported by Boyarski et al.  and Luth et al.  from the 1975 measurements with the Mark I detector at SLAC. The Review of Particle Properties (PDG) has continued to quote these results ever since . The quoted values are:

$$B(J/\psi \gamma ^{}h)=(17.0\pm 2.0)\%,$$
(1)
$$B(\psi ^{}\gamma ^{}h)=(2.9\pm 0.4)\%.$$
(2)
Both these results were obtained by using the relation

$$B(J/\psi ,\psi ^{}\gamma ^{}h)=\frac{\sigma _h(nonresonant)}{\sigma _l(nonresonant)}\times B_l(J/\psi ,\psi ^{}l^+l^{})$$

$$R(nonresonant)\times B(J/\psi ,\psi ^{}l^+l^{}).$$
(3)
Boyarski et al.  reported $`B(J/\psi \mu ^+\mu ^{})=(6.9\pm 0.9)`$%. Using the value $`R=2.5\pm `$ 0.3 measured by Augustin et al. , they obtained $`\mathrm{\Gamma }(J/\psi \gamma ^{}h)=(12\pm 2)`$ keV, or equivalently the PDG result of Eq. (1).

More recently, much more precise result for both $`R(nonresonant)`$ and the leptonic branching ratio have become available. BES  has reported high precision results for $`R`$ in the region 2–5 GeV, and PDG  itself has fitted and summarized the latest results for the leptonic branching ratios. The $`R`$ values measured by BES  are constant in the region 2.0 to 3.73 GeV (Fig. 1). The result of our fit to these data is

$$R=2.26\pm 0.04$$
(4)
which is very close to the theoretical expectations for three flavors, $`R`$=2.13 (correct to third order) . The average of $`B(J/\psi e^+e^{})`$ and $`B(J/\psi \mu ^+\mu ^{})`$ is

$$B(J/\psi l^+l^{})=(5.90\pm 0.09)\%.$$
(5)
These leads to

$$B(J/\psi \gamma ^{}h)=(13.3\pm 0.3)\%,$$
(6)
a result which represents a large improvement over Eq. (1).

For $`\psi ^{}`$(2$`{}_{}{}^{3}S_{1}^{}`$) Luth et al.  reported $`B(\psi ^{}e^+e^{})=(0.93\pm 0.16)`$% and apparently used $`R`$=3.1 to obtain $`B(\psi ^{}\gamma ^{}h)=(2.9\pm 0.4)`$%. The PDG listing is $`B(\psi ^{}l^+l^{})=(0.73\pm 0.04)`$. Using fitted value of $`R`$ in Eq. (4), we obtain

$$B(\psi ^{}\gamma ^{}h)=(1.65\pm 0.10)\%,$$
(7)
a result which is significantly different from that of Eq. (2).

Since hadronic decays through virtual photons are included in the total hadronic decays, these revised values do not change the branching ratios, $`B(J/\psi ,\psi ^{}h)`$, but they do alter the estimates of $`B(J/\psi ,\psi ^{}ggg)`$.

This work was supported by the U.S. Department of Energy.


text:
# Anistropic Stars: Exact Solutions and Stability

## I Introduction

A common assumption in the study of stellar structure and evolution is that the interior of a star can be modeled as a perfect fluid CLAYTON . This perfect fluid model necessarily requires the pressure in the interior of a star to be isotropic. This approach has been used extensively in the study of polytropes, including white dwarfs, and of compact objects such as neutron stars GLENDENNING . However, theoretical advances in the last decades indicate that deviations from local isotropy in the pressure, in particular at very high densities, may play an important role in determining stellar properties RUDERMAN .

The physical situations where anisotropic pressure may be relevant are very diverse. By anisotropic pressure we mean that the radial component of the pressure, $`p_r(r)`$, differs from the angular components, $`p_\theta (r)=p_\phi (r)p_t(r)`$. (That $`p_\theta (r)=p_\phi (r)`$ is a direct consequence of spherical symmetry.) Of course, spherical symmetry demands both to be strictly a function of the radial coordinate. Boson stars, hypothetical self-gravitating compact objects resulting from the coupling of a complex scalar field to gravity, are systems where anisotropic pressure occurs naturally B-STARS . In the interior of neutron stars pions may condense. It has been shown that due to the geometry of the $`\pi ^{}`$ modes, anisotropic distributions of pressure could be considered to describe a pion condensed phase configuration SAWYER . The existence of solid cores and type P superfluidity may also lead to departures from isotropy within the neutron star interior GLENDENNING .

Since we still do not have a detailed microscopic formulation of the possible anisotropic stresses emerging in these and other contexts, we take the general approach of finding several exact solutions representing different physical situations, modeled by ansatze for the anisotropy factor, $`p_tp_r`$. Previous studies have found some exact solutions, assuming certain relations for the anisotropy factor BOWERS . Our goal here is two fold: first, to find new exact solutions which may better model realistic situations and explore their physical properties kg1 ; second, to investigate their stability against small radial perturbations kg2 . For this, we generalize Chandrasekhar’s well-known variational approach to anisotropic objects. We find that not only interesting exact solutions can be found kg1 , but that they may have a wider stability range when contrasted with their isotropic counterparts kg2 .

## II Relativistic Self-Gravitating Spheres: Basics

We consider a static equilibrium distribution of matter which is spherically symmetric. In Schwarzschild coordinates the metric can be written as

$$ds^2=e^\nu dt^2e^\lambda dr^2r{}_{}{}^{2}d\theta ^2r{}_{}{}^{2}\mathrm{sin}_{}^{2}\theta d\varphi ^2,$$
(1)
where all functions depend only on the radial coordinate $`r`$. The most general energy-momentum tensor compatible with spherical symmetry is

$$T_\nu ^\mu =\mathrm{diag}(\rho ,p_r,p_t,p_t).$$
(2)
We see that isotropy is not required by spherical symmetry; it is an added condition. The Einstein field equations for this spacetime geometry and matter distribution are

$$e^\lambda \left(\frac{\nu ^{}}{r}+\frac{1}{r^2}\right)\frac{1}{r^2}=8\pi p_r;$$
(3)
$$e^\lambda \left(\frac{1}{2}\nu ^{\prime \prime }\frac{1}{4}\lambda ^{}\nu ^{}+\frac{1}{4}\left(\nu ^{}\right)^2+\frac{\left(\nu ^{}\lambda ^{}\right)}{2r}\right)=8\pi p_t;$$
(4)
$$e^\lambda \left(\frac{\lambda ^{}}{r}\frac{1}{r^2}\right)+\frac{1}{r^2}=8\pi \rho .$$
(5)
Note that this is a system of 3 equations with 5 unknowns. Consequently, it is necessary to specify two equations of state, such as $`p_r=p_r(\rho )`$ and $`p_t=p_t(\rho )`$.

It is often useful to transform the above equations into a form where the hydrodynamical properties of the system are more evident. For systems with isotropic pressure, this formulation results in the Tolman-Oppenheimer-Volkov (TOV) equation. The generalized TOV equation, including anisotropy, is

$$\frac{dp_r}{dr}=(\rho +p_r)\frac{\nu ^{}}{2}+\frac{2}{r}(p_tp_r),$$
(6)
with

$$\frac{1}{2}\nu ^{}=\frac{m(r)+4\pi r^3p_r}{r(r2m)},$$
(7)
and

$$m(r)=_0^r4\pi r^2\rho 𝑑r.$$
(8)
Taking $`r=R`$ in the above expression gives us the Schwarzschild mass, $`M`$. \[This implicitly assumes that $`\rho =0`$ for $`r>R`$.\]

In order to solve the above equations we must impose appropriate boundary conditions. We require that the solution be regular at the origin. This imposes the condition that $`m(r)0`$ as $`r0`$. If $`p_r`$ is finite at the origin then $`\nu ^{}0`$ as $`r0`$. The gradient $`dp_r/dr`$ will be finite at $`r=0`$ if $`(p_tp_r)`$ vanishes at least as rapidly as $`r`$ when $`r0`$. This will be the case in all scenarios examined here.

The radius of the star is determined by the condition $`p_r(R)=0`$. It is not necessary for $`p_t(R)`$ to vanish at the surface. But it is reasonable to assume that all physically interesting solutions will have $`p_r,p_t0`$ for $`rR`$.

## III Exact Solutions

In ref. kg1 , we obtained several exact solutions for different forms of the pressure anisotropy. Our solutions fall into two classes: i) $`\rho `$ = constant, and ii) $`\rho 1/r^2`$. Given the limited space, we will restrict the presentation to the latter case. Interested readers should consult ref. kg1  for details.

Consider stars with energy density modeled as

$$\rho =\frac{1}{8\pi }\left(\frac{a}{r^2}+3b\right),$$
(9)
where both $`a`$ and $`b`$ are constant. The choice of the values for $`a`$ and $`b`$ is dictated by the physical configuration under consideration. For example, $`a=3/7`$ and $`b=0`$, corresponds to a relativistic Fermi gas, as in the Misner-Zapolsky solution for ultradense cores of neutron starsZAPOLSKY . If we take $`a=3/7`$ and $`b0`$ then we have a relativistic Fermi gas core immersed in a constant density background. For large $`r`$ the constant density term dominates ($`r_c^2a/3b`$), and can be thought of as modeling a shell surrounding the core. We also take the pressure anisotropy to be

$$p_tp_r=\frac{1}{8\pi }\left(\frac{c}{r^2}+d\right),$$
(10)
with $`c`$ and $`d`$ constant.

We found it convenient to seek solutions for the metric function $`\nu (r)`$ directly, rather than solving the generalized TOV equation. We then use the known functions $`\lambda (r)`$ and $`\nu (r)`$ to find the radial and tangential pressures. From eqs. 3, 4, and 5, we find

$$\left(\frac{\nu ^{\prime \prime }}{2}+\frac{(\nu ^{})^2}{4}\right)e^\lambda \nu ^{}\left(\frac{\lambda ^{}}{4}+\frac{1}{2r}\right)e^\lambda \left(\frac{1}{r^2}+\frac{\lambda ^{}}{2r}\right)e^\lambda +\frac{1}{r^2}=8\pi (p_tp_r).$$
(11)
Introducing a new variable $`y=e^{\frac{\nu }{2}}`$, eq. 11 becomes,

$$(y^{\prime \prime })e^\lambda y^{}\left(\frac{\lambda ^{}}{2}+\frac{1}{r}\right)e^\lambda y\left[(\frac{1}{r^2}+\frac{\lambda ^{}}{2r})e^\lambda \frac{1}{r^2}\right]=8\pi y(p_tp_r).$$
(12)
Since $`e^\lambda =12m(r)/r`$, using eq. 9 we find

$$e^\lambda =1abr^2I_b^2(r),$$
(13)
where we defined the function $`I_b^2(x)1abx^2`$. When $`b=0`$, we write $`I_0^21a`$. Using the expression for $`e^\lambda `$ in eq. 12 and substituting for the pressure anisotropy we find

$$\left[br^4(1a)r^2\right]y^{\prime \prime }+(1a)ry^{}(acdr^2)y=0.$$
(14)
The full solution of eq. 14 with $`a,b,c,d0`$ is in kg1 . Here, we will only consider solutions with $`b=d=0`$. In this case, the total mass is $`M=aR/2`$, and $`\mathrm{exp}[\lambda ]=1a`$. Since for any static spherically-symmetric configuration we expect $`(2M/R)_{crit}1`$, we must have $`a<1`$. (Also, the metric coefficient $`g_{rr}`$ becomes infinite when $`a=1`$).

Since we want to construct stars with finite radii and density in the context of anisotropic pressure, we impose boundary conditions such that $`p_r(R)=0`$. With $`b=d=0`$, eq. 14 reduces to an Euler-Cauchy equation,

$$(1a)r^2y^{\prime \prime }(1a)ry^{}+(ac)y=0.$$
(15)
The solutions of this equation fall into three classes, depending on the value of $`q`$ ($`q`$ is real, $`q=0`$, or $`q`$ is imaginary), where

$$q\frac{(1+c2a)^{\frac{1}{2}}}{(1a)^{\frac{1}{2}}}.$$
(16)
We will only show results for $`q`$ real. (See ref. kg1  for the other cases.)

The solution for $`y`$ is

$$y=A_+\left(\frac{r}{R}\right)^{1+q}+A_{}\left(\frac{r}{R}\right)^{1q},$$
(17)
with the constants $`A_+`$ and $`A_{}`$ fixed by boundary conditions. For the case under consideration here ($`b=d=0`$), the boundary conditions are

$$e^{\lambda (R)}=e^{\nu (R)}=I_0^2,\mathrm{and}e^{\nu (R)}\frac{d\nu }{dr}|_R=\frac{a}{R}.$$
(18)
Applying the boundary conditions we find

$$A_+=\frac{I_0}{2}+\frac{13I_0^2}{4qI_0}\mathrm{and}A_{}=A_+(qq).$$
(19)
The radial pressure for this case, after substituting the expressions for $`A_+`$ and $`A_{}`$, is

$$8\pi p_r=\frac{(3I_0^21)^24q^2I_0^4}{r^2}\left[\frac{R^{2q}r^{2q}}{(3I_0^21+2qI_0^2)R^{2q}+(13I_0^2+2qI_0^2)r^{2q}}\right].$$
(20)
We note that the boundary conditions automatically guarantee that $`p_r(R)=0`$. The radial pressure is always greater than zero provided $`a<2/3`$ and $`a^2>4c(1a)`$. Since by definition $`a>0`$, the second condition implies $`c>0`$. Thus, this model does not allow for negative anisotropy. Further, since we are considering the case $`q>0`$, we must impose the condition $`1+c<2a`$. Combining the two inequalities for $`a`$ and $`c`$, we obtain, $`2a1<c<a^2/4(1a)`$. Since we have $`0<a<2/3`$ we find that $`0<c<1/3`$. We note that for the anisotropic case the maximum value of $`a`$ is $`2/3`$, corresponding to a $`33`$% increase when compared with the isotropic case ($`a=3/7`$). In figure 1 we plot the radial pressure, $`p_r`$, as a function of the radial coordinate $`r`$, for $`a=3/7`$ and several values of $`c`$. Note that for this choice of $`a`$, the inequality $`c<a^2/4(1a)`$ imposes that $`c<0.08`$ for positive pressure solutions. This can be seen in the figure. For larger anisotropies, no static self-gravitating stable configuration is possible. For $`rR`$, we find

$$8\pi r^2p_r=3I_0^212qI_0^2.$$
(21)
Choosing $`a=3/7`$ we recover, in the limit $`c0`$, the Misner-Zapolsky solution ZAPOLSKY , with $`p_r=1/(56\pi r^2)=\rho /3`$.

## IV Stability

For sake of brevity, we will skip most details of our generalization of Chandrasekhar’s formalism to anisotropic spheres. Readers can consult ref. kg2  for details. As in Chandrasekhar’s original formalism, we limit our study to small radial and baryon-number conserving perturbations. Writing $`\rho =\rho _o+\delta \rho ,p_r=p_{r}^{}{}_{o}{}^{}+\delta p_r,p_t=p_{t}^{}{}_{o}{}^{}+\delta p_t,\lambda =\lambda _o+\delta \lambda ,`$ and $`\nu =\nu _o+\delta \nu `$ we find that, to first order in $`v=d\xi /dt`$ ($`\xi `$ is the Lagrangian displacement) and using the zeroth-order equations, the perturbation in the radial pressure satisfies,

$$\delta p_r=p_{r_o}^{}{}_{}{}^{}\gamma p_{r}^{}{}_{o}{}^{}\frac{e^{\nu _o/2}}{r^2}\left(r^2e^{\nu _o/2}\xi \right)^{}+\frac{2\xi }{r}\mathrm{\Pi }_o\frac{p_{ro}}{\rho _o},$$
(22)
with $`\gamma `$ being the adiabatic exponent defined as

$$\gamma \frac{1}{p_r(n/p_r)}\left[n(\rho +p_r)\frac{n}{p_r}\right],$$
(23)
and $`\mathrm{\Pi }p_tp_r`$. We now assume that all perturbations have a time dependence of the form $`e^{i\omega t}`$. Further, considering $`\delta \lambda `$, $`\delta \nu `$, $`\delta \rho `$, $`\delta p_r`$ and $`\delta \mathrm{\Pi }`$ to now represent the amplitude of the various perturbations with the same time dependence we obtain, after using the zeroth-order equations, the pulsation equation governing the radial stability of anisotropic stars kg2

$`\omega ^2\left(\rho _o+p_{r}^{}{}_{o}{}^{}\right)\xi e^{\lambda _o\nu _o}={\displaystyle \frac{4}{r}}p_{r}^{}{}_{o}{}^{}\xi e^{(\lambda _o+2\nu _o)/2}\left[e^{(\lambda _o+3\nu _o)/2}\gamma {\displaystyle \frac{p_{r}^{}{}_{o}{}^{}}{r^2}}(r^2e^{\nu _o/2}\xi )^{}\right]^{}`$ \+
$`8\pi e^{\lambda _o}(\mathrm{\Pi }_o+p_{r}^{}{}_{o}{}^{})(\rho _o+p_{r}^{}{}_{o}{}^{})\xi {\displaystyle \frac{1}{(\rho _o+p_{r}^{}{}_{o}{}^{})}}(p_{r}^{}{}_{o}{}^{})^2\xi +{\displaystyle \frac{4p_{r}^{}{}_{o}{}^{}{}_{}{}^{}\mathrm{\Pi }_o\xi }{r(\rho _o+p_{r}^{}{}_{o}{}^{})}}{\displaystyle \frac{4\mathrm{\Pi }_o^2\xi }{r^2(\rho _o+p_{r}^{}{}_{o}{}^{})}}`$
$`e^{(\lambda _o+2\nu _o)/2}\left[e^{(\lambda _o+2\nu _o)/2}{\displaystyle \frac{2}{r}}\xi \mathrm{\Pi }_o\left({\displaystyle \frac{p_r}{\rho }}+1\right)\right]^{}{\displaystyle \frac{8}{r^2}}\mathrm{\Pi }_o\xi {\displaystyle \frac{2}{r}}\delta \mathrm{\Pi }.`$
The boundary conditions imposed on this equation are

$$\xi =0\mathrm{at}r=0\mathrm{and}\delta p_r=0\mathrm{at}r=R.$$
(25)
The pulsation eq. (IV), together with the boundary conditions eq. (25), reduce to an eigenvalue problem for the frequency $`\omega `$ and amplitude $`\xi `$. One multiplies this equation by $`r^2\xi e^{(\lambda +\nu )/2}`$ and integrates over the entire range of $`r`$, using the orthogonality condition

$$_0^Re^{(3\lambda \nu )/2}\left(\rho +p_r\right)r^2\xi ^i\xi ^j𝑑r=0(ij),$$
(26)
where $`\xi ^i`$ and $`\xi ^j`$ are the proper solutions belonging to different eigenvalues $`\omega ^2`$.

We now apply this equation to the exact solutions with $`\rho 1/r^2`$ described above. Using the trial function $`\xi =r^2(\rho +p_r)e^\nu `$ we found that all integrals could be computed exactly. In table 1 we present results for the frequencies of radial oscillations $`\omega ^2`$ as a function of the anisotropy parameter, $`c`$, for given values of the density parameter. Instabilities set in for $`\omega ^2<0`$. This can be used to find the critical value for the adiabatic index, $`\gamma _c(c)`$, and the maximum value for the anisotropy paramenter, $`c_{max}`$. We also give, in table 2, the values of $`\gamma _c`$ above which stable oscillations are possible. Here we see that the effect of a positive anisotropy is to reduce the value of $`\gamma `$, thus giving rise to a more stable configuration when compared with the corresponding isotropic model. In particular, for the Misner-Zapolsky solution ($`a=3/7`$), we find that a small positive pressure anisotropy in the equation of state improves the neutron star’s core stability.

## V CONCLUSIONS

I have presented a summary of results obtained with Krsna Dev concerning the existence of self-gravitating spheres in General Relativity with anisotropic equations of state, aka anisotropic stars. I have also presented a summary of our investigation of their stability, based on the extension of Chandrasekhar’s celebrated variational formalism for isotropic spheres to those with anisotropic energy-momentum tensors.

Although the search for exact solutions restricts the forms of anisotropy we could treat, our results illustrate the fact that, indeed, pressure anisotropy may greatly affect the physical structure of the star, leading to several observational effects. Most importantly, the absolute stability bound $`2M/R<8/9`$ can be violated, and the star’s surface redshift may be arbitrarily large ($`z_s>2`$). It is thus conceivable that objects which are observed at large redshift may actually be closer than we think due to anisotropic distortions. They may also be more stable then we think, especially if pressure anisotropy exists near the stellar core.

Here, I have presented results only for one of the cases we treated, stars with energy density scaling as $`1/r^2`$. These are of interest as they include ultra-relativistic equations of state used to model the cores of neutron stars. Perhaps the most important lesson of our study is that one must keep an open mind as to whether isotropy is or not a justified assumption to describe stellar matter. Until we have a better microscopic understanding of what truly goes on inside ultra-dense compact objects, isotropy should be taken with a grain of salt. Especially if some of these objects contain bosonic condensates at their cores, as is the case for several models of neutron star interiors and for a whole class of fully-anisotropic hypothetical objects known as boson starsB-STARS .

###### Acknowledgements.

I’d like to express my gratitude to the organizers of IWARA 2003, and in particular to Helio Coelho, Sandra Prado, and Cesar Vasconcellos for their invitation and wonderful hospitality. My research is sponsored in part by a NSF grant PHY-0099543.


text:
# Regular and Periodic Tachyon Kinks

## 1 Introduction

String theory is perhaps the most plausible candidate for a relativistic theory to describe the electromagnetic, weak, strong, and gravitational interactions altogether. It engenders a very rich structure which includes stable or BPS and unstable or non-BPS branes. In the last case, instabilities of non-BPS branes are marked by the presence of tachyon fields, whose dynamics are directly related to the process in which non-BPS branes decay into BPS branes — see e.g. Refs. .

These recent investigations on tachyons have suggested that the tachyon dynamics is described by the action

$$S=d^{p+1}xV(T)\sqrt{1+\eta ^{\mu \nu }_\mu T_\nu T}$$
(1)
where $`T=T(\stackrel{}{x},t)`$ is the tachyon field, real, and $`x^\mu =(t,\stackrel{}{x})`$ is the position vector. Also, the Minkowski metric has signature $`(,+,+,+,\mathrm{})`$, and $`V(T)`$ is the potential, which is non negative, obeys $`V(T\pm \mathrm{})0`$ and attains its global maximum at $`T=0.`$ We consider $`0V(T)1.`$

In the present work, in the above action we modify the Lagrange density to the new form

$$\stackrel{~}{}=V(T)\left(\sqrt{1+\eta ^{\mu \nu }_\mu T_\nu T}\frac{1}{\sqrt{1+r^2F^2}}\right)$$
(2)
where $`r`$ is a parameter, real and positive, and $`F=F(T,\eta ^{\mu \nu }_\mu T_\nu T).`$ The real parameter $`r`$ is introduced to control the way one goes beyond former investigations: for $`F`$ that behaves appropriately, the limit $`r\mathrm{}`$ gives the former action (1) and leads to the problem investigated by Sen in Ref. ; for $`r>>1`$ one may get to the recent investigation , in which one modifies the action (1) by adding a term which depends on the derivative of the tachyon field. In Ref. , the term included in the action is controlled by a very small parameter, and admits a perturbative investigation which very nicely leads to regular kink, and gives the singular kink of Ref.  in the appropriate limit.

In this work, in the modification we are introducing in (2) we consider functions that only depend on the tachyon field, that is, we consider $`F=F(T)`$ as a non negative function $`T`$ alone. Moreover, we suppose that $`F(T)`$ is limited to some interval, that is, we suppose that $`0F(T)1.`$ As we shall show, the above model engenders specific features which are of direct interest to high energy physics. To do this, we organize the subject of this work in the sections that follow, where we study the presence of tachyon kinks of regular and periodic profile.

## 2 Generalities

We use the modified model to examine the energy corresponding to static configuration $`T=T(\stackrel{}{x})`$. We get

$$E=d^pxV(T)\left(\sqrt{1+_iT^iT}\frac{1}{\sqrt{1+r^2F^2}}\right)$$
(3)
We investigate stability of static solutions with the Derrick-Hobart theorem  — see also Ref. . We change $`T(\stackrel{}{x})T^\lambda (\stackrel{}{x})=T(\lambda \stackrel{}{x})`$ to get to the condition for stability of the solution $`T(\stackrel{}{x})`$

$$\frac{p+(p1)_iT^iT}{\sqrt{1+_iT^iT}}=\frac{p}{\sqrt{1+r^2F^2}}$$
(4)
The case of a single spatial dimension is special. Here the above condition reduces to the simpler form $`T^2(x)=r^2F^2(T),`$ or better

$$T^{}(x)=\pm rF(T)$$
(5)
where the prime stands for derivative with respect to $`x.`$ We note that the above Eq. (5) reproduces first-order differential equations that appear in the bosonic sector of supersymmetric field theory described a single chiral superfield; see, e.g., Ref. .

Let us now investigate the equation of motion that follows from the modified action. It can be written in the form

$$\frac{1}{\sqrt{1+_\mu T^\mu T}}\left(\frac{dV}{dT}V_\mu ^\mu T+V\frac{^\mu T^\nu T_\mu _\nu T}{1+_\mu T^\mu T}\right)=\frac{1}{\sqrt{1+r^2F^2}}\left(\frac{dV}{dT}\frac{r^2FV}{1+r^2F^2}\frac{dF}{dT}\right)$$
(6)
In the case $`p=1,`$ the static field obeys

$$\frac{1}{T^{}}\frac{d}{dx}\left(\frac{V}{\sqrt{1+T^2}}\frac{V}{\sqrt{1+r^2F^2}}\right)=0$$
(7)
This equation is solved by $`T^{}\mathrm{},`$ which are stable solutions of the equation (5) in the limit $`r\mathrm{}`$, which leads to the case first investigated by Sen in , giving rise to the stable but singular tachyon kinks

$$T_S^\pm (x)=\{\begin{array}{cc}\pm \mathrm{}\hfill & \mathrm{for}x>0\hfill \\ \mathrm{\hspace{0.17em}0}\hfill & \mathrm{for}x=0\hfill \\ \mathrm{}\hfill & \mathrm{for}x<0\hfill \end{array}$$
(8)
There are other solutions, which obey

$$T^2=\frac{1}{\left(\frac{V_0}{V}+\frac{1}{\sqrt{1+r^2F^2}}\right)^2}1$$
(9)
where $`V_0`$ is a real constant, constrained to obey

$$0\frac{1}{\sqrt{1+r^2F^2}}+\frac{V_0}{V}1$$
(10)
The case $`V_0=0`$ reproduces the former Eq. (5), leading to the conclusion that the solutions of the equation of motion are stable for $`V_0=0.`$

In our model, in the case $`p=1`$ the unidimensional stable static solutions have energy in the form

$$E=r^2𝑑x\frac{V(T)F^2(T)}{\sqrt{1+r^2F^2(T)}}$$
(11)
In the case $`r\mathrm{}`$ we get

$$E_S=_{\mathrm{}}^{\mathrm{}}𝑑TV(T)$$
(12)
which requires that the tachyonic potential be integrable. Another case is given by $`r=0.`$ Stable solutions should satisfy $`T^{}=0,`$ which makes the tachyonic field constant. The energy associated to such constant configurations vanishes. The energy in (11) is non-negative, and for stable solutions it varies in the interval $`0EE_S,`$ for functions $`F(T)`$ which behave appropriately.

We notice that in the modified model, in the case $`p=1`$ stable tachyon solutions obey $`T^{}=rF(T)`$, and so they do not depend on the explicit form of the tachyon potential. However, the tachyon potential plays the important role of controlling the energy of the tachyon solution. This fact helps us to understand why the singular tachyons (8) are stable, finite energy solutions.

We also notice that in the modified model, the energy-momentum tensor $`T_{\mu \nu }`$ gives the energy density $`T_{00}`$

$$T_{00}V(T)\left(\sqrt{1+T^2}\frac{1}{\sqrt{1+r^2F^2}}\right)$$
(13)
and pressure along the non trivial $`x`$ direction $`(P_1=T_{11})`$

$$T_{11}\frac{V}{\sqrt{1+T^2}}+\frac{V}{\sqrt{1+r^2F^2}}$$
(14)
The pressure is constant since $`T_{11}^{}(x)=0`$ — see Eq. (7). We see that $`T_{11}=V_0,`$ where $`V_0`$ is the constant that we have introduced to write Eq. (9). Thus, the case $`V_0=0`$ corresponds to vanishing pressure, and gives rise to stable finite energy tachyon configurations which obey $`T^{}=\pm rF.`$ Furthermore, since $`V_0`$ must obey the constraint (10), we can also have two other distinct possibilities: one for $`V_0`$ positive, representing the case of negative pressure, and the other for $`V_0`$ negative, representing the case of positive pressure. We shall show below that in the case of non vanishing $`V_0,`$ we must compactify the real line in order to have finite energy, and this will give rise to periodic tachyon kinks. Thus, in the modified model we shall find stable and regular tachyon kinks in an environment with vanishing pressure. And also, we shall find periodic kink-antikink array in another environment, with negative pressure. We notice from the above Eq. (14) that the limit $`r\mathrm{},`$ which leads to the standard tachyon action, gives rise to the case of negative pressure, and nothing more — see Ref. .

## 3 Specific models

We investigate the case with $`V_0=0,`$ which corresponds to vanishing pressure. This case gives rise to models that support stable tachyon kinks of regular profile. The energy depends on the tachyon potential, $`V(T)`$. Thus, we choose the tachyon potential such that $`E_S=1.`$ In this case the energy of the tachyon configurations is restricted to be in the interval $`0<E<1`$. We may choose $`V_I(T)=\mathrm{exp}(\pi T^2),`$ $`V_{IIa}(T)=1/2\mathrm{cosh}^2(T)`$, $`V_{IIb}(T)=1/\pi \mathrm{cosh}(T),`$ and $`V_{III}(T)=1/\pi (1+T^2)`$ which identify type-I, type-II, and type-III models, all leading to unit energy. We will study these models to have a better understanding of the role of the potential for the modified tachyon action that we propose in (2). Specific models involving the choices $`F(T)=1`$ and $`F(T)=1/\mathrm{cosh}(T)`$ will be investigated below.

### 3.1 Type-I models

We consider the case $`F(T)=1,`$ which implies that $`T^{}=\pm r`$, giving rise to the solutions $`T_\pm (x)=\pm rx,`$ which lead to the singular kinks (8) in the limit $`r\mathrm{}.`$ This case reproduces the solutions of Ref. . The energy corresponding to these solutions has the form

$$E_I(r)=\frac{r^2}{\sqrt{1+r^2}}_{\mathrm{}}^{\mathrm{}}𝑑xV(T)$$
(15)
Thus, for $`V(T)=\mathrm{exp}(\pi T^2)`$ and for $`T_\pm =\pm rx`$ we get

$$E_I(r)=\frac{r}{\sqrt{1+r^2}}$$
(16)
We use this result to get $`E(r=0)=0.`$ This is interesting, since the limit $`r0`$ leads to a constant tachyon configuration. Our model gives vanishing energy for trivial constant tachyon configurations at $`r=0,`$ and unit energy for the singular kink (8) at the limit $`r\mathrm{}.`$ The stable kink solutions $`T^\pm (x)=\pm rx`$ are parametrized by $`r`$, and have energy as in Eq. (16), which is well-defined in the entire interval $`0r1.`$ In Fig.  we plot $`E_I(r)`$ in the whole interval $`r[0,\mathrm{}).`$

We also consider the case of $`F(T)=1/\mathrm{cosh}(T)`$ to get

$$T^{}=\pm \frac{r}{\mathrm{cosh}(T)}$$
(17)
This equation was already solved in Ref. . The solutions are $`T(x)=\pm \mathrm{arcsinh}(rx)`$, and we realize that the singular kink (8) is now very naturally recovered in the limit $`r\mathrm{}.`$ The energy of the regular kinks can be written as

$$\stackrel{~}{E}_I(r)=r_{\mathrm{}}^{\mathrm{}}𝑑x\frac{e^{\pi \mathrm{arcsinh}^2(x)}}{(1+x^2)\sqrt{1+\frac{r^2}{1+x^2}}}$$
(18)
and depends on the parameter $`r.`$ It vanishes for $`r=0`$, and converges to unit in the limit $`r\mathrm{}.`$ In Fig.  we plot the energy density for $`r[0,\mathrm{}).`$ We note that $`\stackrel{~}{E}_I(r)`$ is very close to $`E_I(r),`$ indicating that the choice of $`F(T)`$ determine no qualitative behavior.

### 3.2 Type-II models

We first consider type-IIa models, and use $`F(T)=1.`$ The investigation is similar to the former case. The kink solutions and the energy give the very same results already obtained in the corresponding type-I model. Thus, we consider the next case: $`F(T)=1/\mathrm{cosh}(T).`$ Here the energy changes to

$$\stackrel{~}{E}_{IIa}(r)=\frac{r}{2}_{\mathrm{}}^{\mathrm{}}𝑑x\frac{1}{(1+x^2)^2}\frac{1}{\sqrt{1+\frac{r^2}{1+x^2}}}$$
(19)
It vanishes for $`r=0`$, and converges to unit in the limit $`r\mathrm{}.`$ In Fig.  we plot the energy $`\stackrel{~}{E}_{IIa}(r)`$ in the entire interval $`r[0,\mathrm{}).`$ We note that $`\stackrel{~}{E}_{IIa}(r)`$ is very close to $`\stackrel{~}{E}_I(r),`$ suggesting that the specific choice of the tachyonic potential seems to determine no qualitative behavior.

We also consider type-IIb models, with the potential $`1/\pi \mathrm{cosh}(T).`$ For $`F(T)=1`$ we get the very same result already obtained in the former case. For $`F(T)=1/\mathrm{cosh}(T),`$ the investigation is slightly modified, with the energy changing to

$$\stackrel{~}{E}_{IIb}(r)=\frac{r}{\pi }_{\mathrm{}}^{\mathrm{}}𝑑x\frac{1}{(1+x^2)^{3/2}}\frac{1}{\sqrt{1+\frac{r^2}{1+x^2}}}$$
(20)
In Fig.  we also plot $`\stackrel{~}{E}_{IIb}`$ as a function of $`r.`$ We see that it is similar to $`\stackrel{~}{E}_{IIa},`$ showing that tachyon potentials of the form $`1/\mathrm{cosh}(T)`$ and $`1/\mathrm{cosh}^2(T)`$ give very similar results.

### 3.3 Type-III models

Again, we first consider the case $`F(T)=1.`$ The investigation is similar to the former cases, and both the kink solutions and the energy give the very same results already obtained, Thus, we consider the next case of $`F(T)=1/\mathrm{cosh}(T).`$ The kink solutions are the same, but the energy changes to

$$\stackrel{~}{E}_{III}(r)=\frac{r}{\pi }_{\mathrm{}}^{\mathrm{}}𝑑x\frac{[1+\mathrm{arcsinh}^2(x)]^1}{(1+x^2)\sqrt{1+\frac{r^2}{1+x^2}}}$$
(21)
It vanishes for $`r=0`$, and converges to unit in the limit $`r\mathrm{}.`$ However, the convergence is very slow, due to the specific form of the tachyon potential in this case. In Fig.  we also plot $`\stackrel{~}{E}_{III}`$ as a function of $`r.`$ Its behavior is now distinct from the others, and this shows that the inverse power behavior of the tachyon potential leads to distinct energy behavior for tachyon kink, for $`F(T)1`$.

## 4 Periodic solutions

We now consider other possibilities, which appear when $`V_00.`$ As we have already seen, for $`V_00`$ there are no stable solutions. However, we can compactify the real line to investigate static, periodic and finite energy solutions. We follow Refs. , which has already investigated the presence of static, periodic and finite energy solutions in the model (1).

In order to study static, periodic and finite energy solutions in the modified model, we consider the case $`V(T)=V_{IIa}(T)=1/2\mathrm{cosh}^2(T),`$ and the case $`F(T)=1.`$ We get

$$T_p^{\mathrm{\hspace{0.17em}2}}(x)=\frac{1}{[1/\sqrt{1+r^2}+2V_0\mathrm{cosh}^2(T)]^2}1$$
(22)
The constant $`V_0`$ is now restricted to belong to an interval which depends on $`r.`$ A specific case is $`r=0,`$ and now we have $`1/2V_00,`$ with the tachyon field constrained to live in the interval $`T_0TT_0,`$ with $`T_0=\mathrm{arccosh}\sqrt{1/2V_0}.`$ This case corresponds to positive pressure.

We use $`r=0`$ to define the function

$$G(T)=\frac{1}{[1+2V_0\mathrm{cosh}^2(T)]^2}1$$
(23)
In this case, we notice that the points $`\pm T_0`$ are divergences for $`G(T),`$ and so the periodic solutions should end vertically, with divergent derivative. This behavior is not admissible. Indeed, there are no finite energy periodic solutions for $`V_0<0,`$ in the case of positive pressure. We see this using the energy density to write, for $`F(T)=1,`$ and for $`r=0:`$ $`T_{00}(x)=V_0/(1+V_0/V).`$ We take $`V=V_{IIa}`$ to get

$$T_{00}(x)=\frac{V_0}{1+2V_0\mathrm{cosh}^2(T)}$$
(24)
The constant $`V_0`$ should obey $`1/2V_00,`$ and the energy density diverges at the values $`\pm \mathrm{arccosh}\sqrt{1/2V_0}.`$ By the way, we notice that the energy vanishes in the limit $`V_00,`$ because the choice $`F(T)=1`$ gives rise to tachyon kinks which obey $`T^{}(x)=\pm r,`$ and for $`r=0`$ we get to trivial tachyon solutions with vanishing energy.

We now consider the case $`r\mathrm{},`$ which gives $`02V_0\mathrm{cosh}^2(T)1.`$ There are solutions for $`0V_01/2,`$ with $`\mathrm{arccosh}(\sqrt{1/2\mathrm{V}_0})T\mathrm{arccosh}(\sqrt{1/2\mathrm{V}_0}).`$ This case corresponds to negative pressure, and the solutions are similar to the periodic kinks found in Ref. . In the modified model, $`V_0`$ varies in the interval $`[1/2\sqrt{1+r^2},1/21/2\sqrt{1+r^2}],`$ which depends on $`r.`$ For $`V_0=0,`$ there are finite energy tachyon kinks which engender very nice profile, and for $`V_0`$ positive there are periodic solutions similar to the solutions found in Ref. .

We can illustrate both cases involving positive and negative pressure with simpler models. We consider the case of a single real scalar field to write the Lagrange density

$$=\frac{1}{2}_\mu \varphi ^\mu \varphi \frac{1}{2}\left(\frac{dW}{d\varphi }\right)^2$$
(25)
where $`W=W(\varphi )`$ is a smooth function of $`\varphi .`$ The case of periodic tachyon kinks for negative pressure is similar to the case described by

$$W(\varphi )=\frac{1}{2}\varphi \sqrt{1\varphi ^2}+\frac{1}{2}\mathrm{arcsin}(\varphi )$$
(26)
which requires that $`\varphi [1,1].`$ In this case the first-order equations are given by

$$\frac{d\varphi }{dx}=\pm \sqrt{1\varphi ^2}$$
(27)
They are solved by $`\varphi (x)=\pm \mathrm{sin}(x)`$ and this requires that $`x[\pi /2,\pi /2].`$

We can make an array of kink-antikink by alternating kinks and antikinks in the real line. The energy density of each kink or antikink is $`\epsilon (x)=\mathrm{cos}^2(x),`$ which can be integrated in the interval $`\pi /2x\pi /2`$ to give $`E_k=\pi /2.`$ Thus, for $`N`$ kink-antikink pairs we get $`E_k^N=N\pi ,`$ and the size $`L_k^N`$ of the array has to obey $`L_k^N=2N\pi .`$

The above kink or antikink is stable. We write $`\varphi (x,t)=\varphi (x)+_n\eta _n(x)\mathrm{cos}(w_nt)`$ in order to obtain the Schrödinger-like equation for stability

$$\frac{d^2\eta _n}{dx^2}\eta _n=w^2\eta _n$$
(28)
The energies are such that $`w_n=\sqrt{n(n+2)},`$ and the eigenfunctions are even or odd, for $`n`$ even or odd, respectively. They are given by

$$\eta _n(x)=\sqrt{2/\pi }\{\begin{array}{cc}\mathrm{cos}[(n+1)x]\mathrm{for}n=0,2,4,\mathrm{}\hfill & \\ & \\ \mathrm{sin}[(n+1)x]\mathrm{for}n=1,3,5,\mathrm{}\hfill & \end{array}$$
(29)
The gap $`w_{n+1}w_n`$ starts at $`\sqrt{3}`$, and converges to $`1`$ for increasing $`n.`$ This spectrum is similar to the spectrum found in Ref. .

The case of positive pressure is different. This phase is unstable, and the energy of kink or antikink diverges. We illustrate this situation with the model

$$V(\varphi )=\frac{1}{2}\mathrm{sec}^2(\varphi )$$
(30)
which is described by $`W(\varphi )=\mathrm{ln}[\mathrm{sec}(\varphi )+\mathrm{tan}(\varphi )]`$ and requires that $`\varphi [\pi /2,\pi /2].`$ In this case the first-order equations are

$$\frac{d\varphi }{dx}=\pm \mathrm{sec}(\varphi )$$
(31)
These equations are solved by $`\varphi (x)=\pm \mathrm{arcsin}(x)`$ for $`x[1,1].`$ The derivative diverges for $`x\pm 1.`$ Also, the energy density is $`\epsilon (x)=1/(1x^2),`$ which diverges in the limit $`x\pm 1,`$ leading to divergent energy. We also notice that $`1/\sqrt{1x^2}`$ would be the zero mode, but this is not normalizable in the interval $`x[1,1].`$

## 5 Ending comments

In this work we have modified the tachyon action (1) by changing the square root contribution as in (2). We have found stable, finite energy tachyon kinks in the case of vanishing pressure in several different models. We have also found a network of kink-antikink configurations in the case of negative pressure. Although the scenario one finds in the case of negative pressure is similar to other extensions that appeared recently, the case of vanishing pressure is new, and it supports regular, stable and finite energy tachyon kinks which nicely lend thenselves to Sen’s singular solutions in the appropriate limit.

The modification that we introduce gives rise to another phase, corresponding to the case of positive pressure. However, the phase with positive pressure is unstable, giving rise to tachyon kink and antikink which end with divergent derivative, signalling the presence of divergent energy. The cases concerning positive and negative pressure have interesting analogies with field-theoretic models, which allowed illustrating both possibilities within simpler scenarios.

We thank F.A. Brito for discussions, and CAPES, CNPq, PROCAD/CAPES and PRONEX/FAPESQ/CNPq for partial support.