text:
# An Object-Oriented Minimization Package for HEP

## I MOTIVATION

### I.1 Minuit

For many years, the gold standard in minimization packages used by High Energy Physicists has been the Fortran program Minuit minuit . This code contains algorithms which are well-suited for many HEP uses, especially when there is a large data set and minimization is needed to find a multi-parameter fit.

The principal algorithm, called migrad, is a variable metric method. This exploits the idea that althought a costly second derivative computation is needed to move to the function minimum, that matrix need not be computed accurately for early steps (since it will be changing significantly anyway). Instead, it can be iteratively improved, so that by the time the method gets near the actual minimum, the matrix is accurate and rapid convergence occurs.

Another prime capability is a set of routines for analyzing the solution: The hesse method of supplying the parameter error correlation matrix, the minos method of nonparabolic chi-suqare error intervals, and contour, which depicts the shape of a fixed-sigma error curve around the solution point for functions which may not be well-described as bi-linear forms.

### I.2 Is a New Minimization Package Needed?

Minuit, however, is getting a bit stale. It is written in Fortran, which is no longer the lingua franca of computing in HEP; it can be awkward to link C++ code with code from a different language. And modern users would like certain advantages relating to treating a minimization problem and its function, algorithms and domains, as objects. One such advantage is the option of performing multiple independant minimizations in tandem.

The Minuit code is difficult to maintain, as evidenced by the fact that there have been no enhancements since a major overhaul done by F. James about a decade ago, and no major algorithm improvements for some time before that. The HEP community knows of promising alternative methods, such as FUMILI fumili  and the related LEAMAX leamax , and certainly the field has advanced in these years, with simulated annealing and genetic algorithms maturing. The fact that nobody has seen fit to incorporate these as options in Minuit can be taken as evidence that such changes would be hard to make.

Even assuming that Minuit needs no maintenance because all bugs have been eliminated and that its capabilities are forever adequate, what happens when all the CERNLIB Fortran modules start becoming awkward to bring forward? There is reason to fear that Minuit might fall into functional obsolecence.

We asked a group of HEP physicists who work heavily with C++ computation whether it would be a good idea to produce a C++ object-oriented minimization package with Minuit’s capabilities. About 40% reacted positively: “it’s about time we had this.” Some of these physicists had faced a tougher time accomplishing an actual project, for lack of a good stand-alone C++ minimizer.

Others reacted with some variant of “are you out of your mind? Sombody must already have done this!” We will argue below that nobody actually has delivered an adequate object-oriented minimizer with the capabilities required.

### I.3 Other Minimizers

Most commercial minimization packages fall short in capability aspects. In some cases, their algorthms are not as appropriate as migrad for the sort of problems which occur in HEP; more often they lack solution analysis methods equivalent to contour and minos. Also, non-trivial licensing issues can hinder the adoption of commercial codes as de facto standards in the HEP community.

A more promising approach is to translate Minuit directly into C or C++. Several analysis packages, including ROOT root , provide fitting in this manner. Another approach is to place a wrapper around the Minuit code, to allow the interface to be expressed in C++, and package the compiled Fortran code along with the wrapper as an integrated library. Gemini gemini  does this, providing a shell over a choice of Minuit or the commercial NAG C minimizer.

Either approach solves the problem of inter-language awkwardness, but they do not address the issue of maintainability and ease of enhancement. And fundamentally, a minimization problem still cannot be treated as a first-class object.

The Root team, in particular, has done significant work both in cleaning up the f2c translation of Minuit and in removing deficiencies involving multiple minimizations. But not everybody welcomes the requirement of linking to the large body of Root code, when all that is needed is a minimizer.

One other C++ object-oriented minimizer is definitely worth mentioning. Matthias Winkler, mentored by Fred James at CERN, is working on an “object-oriented re-implementation of Minuit in C++” under the auspices of the SEAL programme. Clearly two nearly-identical good C++ minimizers are not needed. We have been in contact with Dr. James, and intend to coordinate the two parallel efforts, hoping to emerge with a single package of superior design and implementation quality.

### I.4 Minimizers vs. Fitters

It is worth saying a few things about the concept of a minimizer as opposed to a fitter. Since most applications of minimization in HEP are motivated by multi-parameter fits to data, the two can be confused.

Most of the packages which wrap Minuit tend to be fitters, that is, they present a convenient way to provide a function form and a data set, and go about using minimization to optimize the parameters in a fit to that data. When the function $`f`$ is a chi-squared sum, the resulting minimization procedure is specialized, in the sense that the nature of the fitting problem assigns a meaning and a natural scale for differences in values of $`f(\stackrel{}{v})`$. Algorithms (such as migrad) which yield a meaningful estimated distance above the true minimum can exploit a natural termination condition, since the value of $`f(\stackrel{}{v})`$ assumed to be accurate only to some small fraction of a unit in chi-squared. And analysis of the estimated shape of $`f(\stackrel{}{v})`$ can meaningfully be translated to statistical statements about correlations among the parameters.

However, the kernel operation of minimizing an arbitrary function is a valid capability to ask for. By design, the C++ minimization package under development is a minimizer, not a fitter. One can automate the steps to turn a fitting task into a minimization problem. Several others have done this in C++, and though it may become convenient to package such a fitter adaptor with the minimizer, this adaptor need not be considered part of the development of the minimizer.

## II PACKAGE REQUIREMENTS

The requirements guiding the developement of this package are driven by the goal of acceptance and widespread use in the HEP community. This will require providing a significant set of capabilities, discussed below. The package must not to be deficient, with respect to Minuit, in any capability. Also, attention must be paid to certain performance considerations. The package must be clean to use and self-contained, and should not depend on other packages. And stringent testing will be required, to ensure that the package is robust.

At the same time, we wish to provide interfaces which will encourage code which is clear and readable and which does not deviate from the classical C++ coding idioms accepted by top practitioners.

Our goal is to provide a package that can be used for many years. It is impractical to provide something which is “so good it will never need to change.” Instead, we strive to organize and code the package such that enhancements and maintenance changes will be as easy to incorporate as possible.

In order to stand the test of time, we feel the minimization package must include complete and easily understood user documentation, as well as full mathematical documentation of all algorithms used.

### II.1 Capabilities

The key requirement is that every capability present in Minuit must be matched in our minimization package.

It could be that Minuit is the ideal minimizer for HEP per se. Or perhaps the way physicists have grown accustomed to doing data analysis has evolved in tandem with Minuit to take advantage of its capabilities. The point is moot–any package which cannot match the capabilities present in Minuit will be unacceptable to the HEP community.

These capabilities lie in several areas. Clearly, the Minuit algorithms (migrad, simplex, minimize) must be present. And user code must be able to control steps taken and selection of (and switching among) algorithms. Code must be the able to establish limits on some or all of the function parameters, and fix and release their values. And the methods for error analysis, nonparabolic error intervals, and two-parameter contour lines (analogous to hesse, minos, and contour) must be provided.

It is tempting, along the way, to make any tweaks that are noticed to be pure improvements. Some of these are pure extensions, such as the ability to define parameters which have only an upper or lower limit. Others might be minor algorithm improvements, such as a theoretically superior finite difference step size when numerically computing derivatives. In such cases, it is required that default behavior precisely mimic the procedures used by Minuit.

The Minuit-matching requirement is a matter of capability, and not of interface. Minuit assumes one of two usage paradigms:

1. The minimizer is a static facility, which the user code explicitly initializes to embark on a problem. The user program then controls this facility by calling various subroutines.
2. A commanding minimizer program is supplied with “cards,” each directing an aspect of initialization or an element of control.

Clearly, both of these paradigms are obsolete in the context of a C++, object-oriented package. The experienced Minuit user may miss the mantra of calling mnexcm and the nine-argument calls to mnparm; these will be replaced by methods which are more readable and which assigns one easily understood purpose to each method called. Still, when the user constructs a minimization problem and invokes problem methods, she is logically employing capabilities which encompass the same set as was available in Minuit.

### II.2 Modern O-O Approach

To make best use of the object oriented abilities provided by C++, it is not enough merely to ensure that a minimization problem can be used as an independant entity. We must use the tools at our disposal to make the setup and control of a minimization problem as clear and flexible as possible. The focus is on user code readability, and on avoiding traps where the user can do something which looks sensible but may have disasterous (or worse, subtly incorrect) consequences.

This means isolating conceptually distinct areas of control, and providing ways of excercising control of one aspect of execution at a time. Thus the user will be able to interact with termination conditions associated with a problem, and separately with the domain restricting ranges of parameters, and with the selection of algorithms.

In each of these areas, the user controls behavior by interacting with specialized versions of objects. The minimization problem then interacts with these objects via by their base class interfaces. An example is in order:

To control how parameters are limited in range, the Problem will own an instance of a Domain. Domain methods takes care of such necessities as translating Points and Gradients between internal unrestricted Cartesian coordinates used by the algorithm, and external parameters known to the function. But Domain by itself is merely a base interface class; the actual Domain attached to the Problem would (by default) be a RectilinearDomain, which provides the capabilities present in Minuit: Restricting the upper and/or lower limits on each parameter individually. RectilinearDomain inherits from Domain. The user who desires to alter these limits would obtain a pointer to the Domain, and invoke methods of RectilinearDomain such as setUpperLimit(n,x).

Now suppose another user has a problem which should be restricted to a region delimited by arbitrary planes in parameter space. This user would provide a different sort of object inheriting from Domain–say LinearConstraintsRegion. And then she might call methods of that class, such as forceLessThan(coefficients, maximum). The algorithm does not care which type of Domain is in place.

In providing the user interface, it is tempting to parallel the control made available to Minuit. This is good only insofar as there aren’t opportunities to improve on the semantics provided by the Minuit subroutines. We are finding that there is a tendency to rely too heavily on doing what Minuit does, and we need to be careful to look for opportunities to provide interfaces which would be clearer to people who are not steeped in Minuit usage. To paraphrase Stroustrup, this package should be “as close to Minuit as possible, but no closer.”

### II.3 Extensibility and Maintainability

The design of the package must be such that as new algorithms and anaylsis methods are developed, or as new types of termination conditions or domains are required, they can be added either to the package itself, or to one’s local version of the package.

We cannot insist that the work associated with such an enhancement be small, because in principle coding some new algorithm might inherently involve a lot of effort. What we can, and do, insist on–and this drives the entire package design–is that the additional work imposed by being part of this minimizaztion package is a very small fraction of the typical work needed to create the new algorithm or domain itself. This “additional work” includes

* Understanding all the steps one needs to do.
* Following the logic of existing package code if necessary.
* Discovering precisely where modifications will be needed, and what the nature of any new classes must be.
* Coding any C++ boilerplate needed to support the enhancement.

These are the tasks which represent a barrier to putting an enhancement into any of the various C++ Minuit translations, and we must ensure that this barrier is small.

Moreover, we must see to it that the enhancer, who may well be an expert in algorithm coding, need not also be an expert in C++.

The way to accomplish these goals is to carefully design the system such that any two concepts that need not be logically intertwined, are expressed as distinct classes which interact as little as possible. The overall package must be split into distinct subsystems, and dependencies carefully controlled. If this is done properly, then the enhancer need only be concerned about the small corner of the package this enhancement will involve. Thus all the code to be examined in creating a new algorithm class would be in the Algorithm base class, and all the boilerplate involved would be found in classes in the Algorithm subsystem.

The same philosophy that leads to ease of enhancement without undue tracing through an entanglement of code, will also greatly reduce the burden of maintenance. Over the long term for a non-commercial package, one has to assume that any maintainer might well lose familiarity with the internals of the system. So it is crucial that proper coding idioms be employed, to avoid setting subtle traps. And good separation of functionality and control of dependencies are critical, so that when changes need to be introduced, they will be localized and not have tendrils of effect throughout the package.

Also, each class should have self-contained (and easy-to-automate) unit tests; each subsystem should have integration tests only involving it and any subsystems it depends on; and a good suite of regression integration tests should be provided to help catch any errors introduced.

Having set a goal of easy enhancement, we must recognize that there are different sorts of enhancements which will normally be performed by different levels of developers. A user might well want to create some new form of Termination condition; this must be very straightforward. More rarely, a more experienced coder might want to derive a new type of Domain (for example, a RectilinearDomain but replacing the arcsin mapping function with some sort of sigmoid). Still more rarely, adding a fundamentally new algorithm is the sort of ehancement which might be assisted by the principal package maintainers.

### II.4 Realm of Efficient Operation

In the “low-ceremony” tight design iteration process so often sucessfully used in High Energy Physics code development, certain fundamental design considerations are often overlooked. Two such considerations are the required levels of agility and efficiency under various circumstances. In the course of designing this package, there will be opportunities for tradeoffs among areas such as coding style, levels of agility when faced with minor changes in needs, and performance efficiency. An up-front grasp of the goals in these area will allow the developer to make intelligent choices.

We have discussed above the agility considerations, in terms of extensibility and maintainability goals. As to efficiency, the typical first reaction is to say “of course this should be as efficient as possible,” but that is an inappropriate goal for this package. Taken to the extreme, a total focus on efficiency might dictate unmaintainable coding tricks, avoidance of sound accepted C++ techniques, and ultimately abandoning the object-oriented paradigm. Some aspects of performance efficiency are critical, but the design goals should permit other forms of efficiency to be sacrificed in favor of better modularity, semantic clarity, or other desirable features.

The HEP minimization problem has a natural set of performance goals, and these induce an efficiency philosophy which is implied in Minuit, and which we state implicitly for our package: It is assumed that the work involved in an invocation of the function being minimized is very large compared to the overheads of bookkeeping, argument passing, and transformations of parameters. Thus tradeoffs which involve attaining beneficial properties at the cost of incuring extra work in these bookkeeping areas are considered positive.

Furthermore, it is also assumed that the number $`N`$ of parameters for tractable minimization problems of the nature we are considering will not be too large. By this, we mean that even in an algorithm which requires operations (such as inversion) involving $`N\times N`$ matrices, the time spent for such operations does not dominate the time needed to evaluate the fuction in forming those matrices.

#### II.4.1 Performance-based limitations

This minimization package will perform well on problems in which the dominant time cost is that of evaluating the function. Because of the tradeoffs between some forms of efficiency and other desirable features, this package may not perform efficiently for certain other classes of problems. It is tempting to say that such problems–which involve inexpensive function calls–are so low-cost that nobody should care about performance, so that this minimization package is suitable for all uses. We should realize that the above rationalization is a bit facile; there are actually at least four cases in which efficiency considerations may become important:

1. Each call to evaluate the function is expensive. This is the case in most HEP fitting applications, and is the case which our package will deal with well.
2. Some problems are potentially expensive not because each function call is costly, but because there are a large numbers of parameters, such that matrix operations or even variable transformations begin to become dominant.
3. When the number of parameters is huge, the algorithm may require a huge number of function calls. If function calls are inexpensive relative to the number of parameters, then bookkeeping overhead can become significant. The minimization problems appearing in Lattice QCD to find fermion propagators are of this nature.
4. The overall scientific problem being solved may involve solving large numbers of easy minimization problems. Thus, while no single minimization is costly, performance on each problem might remain a critical consideration. In that case, problem initialization costs can become important.

The efficiency requirement laid on this minimization package, or for that matter on Minuit, is that it is appropriate for efficient solution of problems in the first of the above categories. This has been found to meet the fitting and other minimization needs of most HEP applications other than Lattice QCD.

## III C++ CONSIDERATIONS

The immediate preferences of potential HEP users can come into tension with the desired use of classical C++ coding idioms accepted by top practitioners. Concepts which are legacies from the Fortran days lead physicsts to become comfortable with coding techniques which are today recognized as poor use of C++. In such cases, it is better to use the accepted modern idiom, rather than to deliver inferior–but temporarily more familiar–interfaces.

Thus for example, it would be unwise to shun the use of auto\_ptr when that is the appropriate way to convey the passing of responsibility for an object. The assumption is made that physicists who may at first be uncomfortable due to unfamiliarity with this idiom will quickly pick up on it. And the benefits in using concepts which have been battle-tested by the world of developers, and which match the understandings of skilled programmers, are considerable.

Few of the decisions discussed in this section were black and white, and some may change in the course of coordinating with the CERN effort, but after some consideration, the following principles were adopted:

### III.1 Function or Functor?

How does the user supply the function to be minimized? The naive mechanism is that the user passes to the Problem a global-scope function of some specified signature (for example, taking a vector of coordinates and returning a value). In fact, this notion is so obvious to the physicist coming from Fortran, that we must support it in some manner.

But there are considerable advantages to being able to supply a functor (a instance of a class that has an operator() so that it looks like it can be called as a function) instead. One advantage to suppying a functor is that unlike the global function, an instance of a functor may have internal state, and the class may provide methods to influence the function behavior. (For example, one may wish to sum errors over fewer data points early in a minimization problem, and more later.)

This natural concept in C++ replaces the awkward nature of fcn in Minuit, which contains six arguments. Only two arguments are fundamental to the notion of a function to be minimized: The vector xval of coordinates, and the result fval. By allowing for a functor class, we obviate the need for iflag and futil; and by separating the gradient method we eliminate the grad argument.

### III.2 Object Ownerhip and Responsibility

The package has several situations in which behavior is defined by hooking into user code. Two examples are the functor representing the function to be minimized, and a Domain object implementing limits on cooordinates.

The pattern of allowing a user to control behavior, by supplying a class which overrides one or more “hook” methods, resonates well with physicist coders. Were we to say that the user constructs a Problem supplying a reference or pointer to an instance of some class derived from Function, the HEP community would not complain. And if we further warned the user not to allow this function to go out of scope while the Problem still needs it, most users would find that an obvious caution.

However, the consequence of violating that stricture are dire: When the Problem calls (by pointer) the out-of-scope method, confusion will reign, with no sensible diagnostic to point out why. Good library developers protect against this by copying the vulnerable object. The Problem, then, will own the Function and Domain, and not risk having those objects “pulled out from under it.” This notion is expressed by the user passing an auto\_ptr to a new object (on the heap); the Problem assumes responsibility for deleting that object when it no longer needs it.

Having made that decision, we must provide a way for the user to invoke controlling methods on the instance of the functor owned by the Problem. The original object that the user supplied to the Problem won’t do, since the Problem will be using a copy of it; in fact, if the correct mantra was used to pass ownership to the Problem, the user code should no longer be able to access the original object. Instead, the correct recipe is:

* The user obtains a pointer to the base class (in this example, Function) by calling a method of Problem (in this case, getFunction()).
* This pointer is dynamic cast into the class the user needs to control. The user can then invoke any control methods applicable for that class.
* The pointer is now allowed to go out of scope, without the user calling delete on it.

The suggested syntax, which automatically obeys this recipe, involves using the returned pointer as a temprary variable which never is valid outside a single statement. The syntax can look like:

```
  dynamic_cast<RectilinearDomain>
    myProblem.getDomain()->
      setUpperLimit(paramNumber, 35.1);

```

Because this mantra may not be immediately familiar to our users, it is important that the package stick to the same rules (never use delete on a pointer which Problem has supplied) for every case of object access.

### III.3 Use of Templates

The powerful template facility in C++ would allow clever ways to improve the user interface and/or implementation of the Minimization package. To give one example, methods giving a choice of supplying a user function or functor to act as the minimization target could be unified by expressing Problem as a template, taking the function class as a template parameter.

The use of templates has several adverse consequences which we perfer to avoid where practical: It makes it a bit tougher for a user to comprehend a header file, it can make maintenance more difficult, it makes compilation error messages much less readable, it introduces quirky linking issues, and it risks harming portability on certain weak compilers. There are valid answers to each of these objections; still, absent compelling benefits, the package design avoids the use of templates.

On the other hand, existing templated classes in the standard library are used freely.

### III.4 Sophisticated Patterns

Our philosophy concerning clever and subtle patterns to which convey minor benefits is that it is sometimes possible to be too clever.

For example, the design of the Function base class (discussed in section IV.5) makes it possible to supply a gradient() method but forget to override gradientAvailable(). That is a bit of a trap–the algorithm would ignore the user-supplied method when it needed a gradient. (The same trap is present in Minuit, if the user forgets to call setgradient).

We could finesse this by using a variant on the visitor pattern: When the algorithm needs a gradient, it requests it from the Function object but the signature of the gradient() method also supplies the address of the algorithm’s finite difference gradient-computing method. The base class gradient() invokes this method; if the user’s functor class overrides gradient() that routine replaces the finite difference method behavior. This pattern incurs some efficiency loss, but since that is merely a matter of an extra argument passed around, and an extra subroutine call, that cost would (by the definition in section II.4) be acceptable. However, the pattern looks complicated and mysterious; it might make maintenance more difficult and it might worry potential users who haven’t put in the time to understand it. Since the gain is relatively slight, we have come down on the side of the simpler gradientAvaliable() solution.

### III.5 When to Introduce a Class

In many cases, there may be multiple concepts for which the natural expression in bits and bytes will look like identical data structures. For example, both the set of coordinates identifying a point, and the set of values representing the components of the gradient of a function, are underneath indexed collections of doubles. The question is, should the design introduce distinct classes to represent the distinct concepts, or should it use a vector of doubles for both?

Good C++ design takes the view that if two concepts are distinct, they should be represented by two distinct classes. The idea is that you can’t be sure in advance that you will never alter the way you work with one of the concepts, and if they are represented by distinct classes, making such a change will be much less of a maintenance headache. Introducing a distinct class to represent each distinct concept also provides some measure of type safety, in that you can’t accidently use one concept when you mean the other. And naming each concept leads to superior code readability. In a package that emphasizes extensibility, these three advantages are significant.

The disadvantage in introducing such classes is limited to the need to write some boilerplate code writing to provide their headers and near-trivial implementations. Therefore, especially concerning minimization package internals, we tend to introduce distinct classes for distinct concepts, particularly in the area of geometric concepts (see section IV.8) such as Point and Gradient.

### III.6 Namespace

The minimization package must be a good C++ citizen. By that, we mean it must not step on potential user symbols; we place everthing into a namespace to guard against this. Other items we avoid are the use, in headers, of macro definitions (which may clash with user defines) and of using statements (which defeat the purpose of the namespace protection if they appear in an included header).

Namespace use has been approved for the CLHEP library, which has severe portability requirements, so we are not concerned on that issue for the Minimization package.

## IV LOGICAL DESIGN

The package is divided into several subsystems. A subsystem is defined as some group of classes and responsibilities, such that each subsystem depends on a minimal number of other subsystems, and such that these dependencies can be expressed as cleanly as possible. The first step in logical design was to identify the concepts present in Minuit. It is no coincidence that each subsystem coresponds to one major concept in the minimization realm.

The benefit of a good separation into subsystems comes during development of various classes, and later during enhancement implementation, because the coder can have in mind a smaller “overall picture” when deciding how to do things. Good isolation of subsystems makes it possible to develop the more detailed package design one part at a time, without constantly having to consider the ramifications of each decision on every other part of the design. Finally, the up-front thought about subsystem components has yielded immediate benefits in the form of solidifying the collection of concepts involved in the minimization package.

In principle a “subsystem” need not be tied to a group of classes. However, each identified subsystem in the Minimization package is characterised by a key class embodying the interface of that subsystem to the user and/or to the other subsystems. This section will outline the responsibilities and dependancies of each subsystem, and discuss associated design issues.

### IV.1 Problem

The Problem subsystem has the responsibility for the user interface to a minimization process. It contains the Problem class, which takes ownership of Algorithm, Domain, and Termination objects, and contains the ProblemState.

Minimizing involves the Problem repeatedly requesting steps from the currently associated Algorithm. After each step, it determines whether the user-supplied termination condition is satisfied, or whether the algorithm itself has declared that it can’t profitably proceed further. If termination is reached, control returns to the user code, which may change the Algorithm, the Domain (for example, releasing some parameters and fixing others), and/or the Termination conditions, and again invoke the problem’s minimize() method.

### IV.2 ProblemState

ProblemState is a structure containing information about the state of solution which is not peculiar to any one algorithm or domain. For example, the concept of the current best guess is inherent in the nature of minimization; it is applicable whehter the algorithm producing it was migrad or simplex.

The user indirectly interacts with ProblemState, via methods of Problem, when she needs to inspect this information. Subsystems of the minimization package interact with ProblemState more directly. For example, Termination conditions inspect its data to decide whether to terminate, and the Algorithm subsystem is dependant upon ProblemState, reading and altering its data.

There is danger that ProblemState can act as a catch-all for data that violates reasonable encapsulation goals, effectively replicating–with all its flaws–the notion of a big global common area. There is some art in restricting the contents to those items genuinely inherent in the minimization concept, and keeping those items which are associated with an algorithm in the specific Algorithm classes.

### IV.3 Algorithm

The Algorithm base class provides interface between the Problem and subclasses implementing specific minimization algorithms. This base class also standardizes ways for its derived classes to access the function and domain objects. For example, the mantra for obtaining a function gradient involves finding out whether the Function object can provide it analytically, and if not, utilizing the algorithm’s own finite difference methodology; this mantra is encapsulated in Algorithm.

Any given algorithm class has an iterate() method, which “takes a step,” improving the state of solution. It also decides whether to declare that this algorithm is finished in the sense that no further meaningful improvement is forseen. Between steps, the Problem applies user-supplied Termination conditions which may declare victory well before the algorithm declares exhaustion.

This subsystem depends on the Function and Domain subsystems: Algorithms, of course, repeatedly requests values of the function (and if available its gradient and second derivatives), and utilize the Domain to map its internal coordinates into external parameters to supply to those function calls.

### IV.4 Analysis

This subsystem has the responsibility for the various solution analysis tools such as minos, hesse, and contour. Such tools have roughly the same needs and dependencies as algorithms, but a class derived from Analysis can in addition also depend on Algorithms which it needs to call.

### IV.5 Function

The Function subsystem has the responsibility for providing function values and, if available, analytic gradient and second derivatives. The primary class is the abstract interface Function.

Commonly, users will have an ordinary function (taking a constant refernce to a Point or to a vector of doubles, and returning a double) to minimize. Such users can make use of the free method UserFunction(), to supply this function when constructing the Problem, as in:

```
  double f(const vector<double> v) {
    assert (v.size()=nargs;
    // ... do work to return a value }
  Problem myprob ( UserFunction (nargs, f) );

```

An alternative signature would take both the function and a method to compute the gradient, if direct gradient computation is available. The user can also optionally supply global methods to compute second derivatives.

UserFunction() constructs a Function object on the heap, and returns an auto\_ptr to it; in the example code, this is immediately passed to the constructor of the Problem.

Alternatively, a user can inherit from Function to form his own “functor” class, and supply an instance of that when constructing a Problem. In that case the functor class must override the method which returns the function value at a point. It may also override the gradient() method, and if it does, it should override gradientAvailable() to return true–this replaces Minuit’s setgradient command, and more importantly, obviates the need for the user function to be passed an iflag argument to tell it what do do. Similarly, the functor class may override the hessian() and hessianAvailable() methods.

The functor is to be created on the heap and an auto\_ptr supplied to the Problem so that there is no danger of the user getting mysterious errors due to the functor going out of scope while the Problem is depending on it. The user can later recover a pointer to this function object and thus invoke its methods:

```
  class MyFunct : public Function {
    MyFunct() : Function(nargs){}
    double operator()(const Point& p);
    changeStuff(int c);
    ...};
  Problem myprob ( auto_ptr<Function>
                  (new MyFunct)       );
  (dynamic_cast<MyFunct*>
     (myprob.getFunction()))->changeStuff(3);Ψ

```

The Function subsystem depends only on the Geometric Concepts subsystem.

### IV.6 Domain

The Domain subsystem has the responsibility for providing mappings between the internal coordinates that an algorithm works with, and the external parameters that a function deals with. This solidifies the decoupling, already present in Minuit, between the algorithm and any restrictions on the parameter values. That is, it would be too difficult to invent an algorithm that could deal with any arbitrary sort of variable restrictions; instead, the algorithms themselves work with clean, unrestricted Cartesian coordinates, and all the complexity involving restrictions is separated off into the Domain classes. The Domain base class provides the interface for algorithms and other parts of the package to transform variables.

There is, of course, the complication that geometric objects of different kinds transform differently under the mappings provided by a Domain. Thus specific Domain derived classes provide methods to map various Geometric Concepts: Points, Gradients, Hessians, CharacteristicScales, (error) Correlations, and whatever else algorithms and analyses may need. The base Domain class supplies these methods in terms of virtual functions which supply the map’s value and derivatives.

Domain encapsulates the Minuit concepts of parameter limits and of fixing/releasing parameter values. Half the interface of Minuit is devoted to manipulating the way parameters can vary. Most of this control belongs in the Domain subsystem.

The exemplar of a Domain (and the one associated with a Problem by default) is the RectilinearDomain, which provides the mapping functions and capabilities present in Minuit. A user could fairly easily create a class inheriting from RectilinearDomain in order to modify the mapping functions used.

RectilinearDomain has the property that its individual components map in a separable way, that is, the map of each internal component depends on only one variable external parameter. Algorithms can query a Domain about this property. For example, when migrad utilizes diagonal second derivatives to avoid the need for computing the full Hessian, it relies on this separablity property; and in more complex Domains, additional work may be needed.

Unlike functors derived from Function, which need only supply the fundamental value-suppying method (and may optionally supply gradient etc.), each Domain subclass is required to supply all the Geometric Concepts mapping methods. While typical users are expected to create functors deriving from Function, we can assume that those who embark on defining new types of Domains are somehwhat more expert.

The Domain subsystem depends only on the Geometric Concepts subsystem.

### IV.7 Termination

The Termination subsystem has the responsibility for conditions conditions which the problem can apply, to determine whether to terminate the minimization iteration and return control to the user. The Termination base class also defines an interface for potential user-created termination conditions.

The subsystem contains Termination classes corresponding to each of the criteria applicable in Minuit, plus a time-based criterion. Time-based termination is often preferable to a count of function calls, but has a potential disadvantage with respect to portability. However, the standard library does provide for timing at the one-second granulaty level, and almost all systems are compliant in this respect.

Termination also comes with methods to build “compound” Termination objects as by logically combining (and, or) more basic Termination objects. Such a compound criterion could, without too much difficulty, be coded by each user as a class deriving from Termination. But the desire to apply a group of criteria, terminating (say) if either the accuracy criterion is met, or the number of function calls is excessive, will be a very common case. So it was decided to make life easy for such users by supporting these combinations. We supply the logical combiners and and or, as this will satisfy the vast majority of applications.

The Termination subsystem depends on ProblemState.

### IV.8 Geometric Concepts

The minimization process deals with a number of geometric concepts, which are logically distinct and not interchangeable. Most of these behave like a vector of doubles. For example, a Point in exterior coordinate space is not interchangeable with a Gradient of the function at some point, even though they both have the same number of components. And neither is the same as an “InteriorPoint” which is a set of coordinates in the Cartesian space in which the algorithm is working.

Although the package code utilizes these Geometric Concept classes, there is good reason to provide user interfaces for common operations which deal with the familiar vector of doubles. For example, the UserFunction() method can accept a function of a std::vector where a Point is logically called for:

```
  double f (const std::vector<double> params);
  Problem myprob ( UserFunction (nargs, f) );

```

The exterior concepts identified are Point, Gradient, SecondDerivatives, Hessian, CharacteristicScale, and Correlations. There are also classes corresponding to each of these, representing internal-coordinate concepts.

The Geometric Concepts subsystem contains the collection of such classes. It depends on no other subsystem.

## V IMMEDIATE ENHANCEMENTS

The initial release of the minimization package is, by definition, to include all Minuit functionality. Of course, the object nature of a minimization problem will allow modes of usage which would be awkward with the Fortran Minuit, but basically the capabilities will at that point be those of Minuit. However, certain extensions will be in the initial release. These appear in situations where the nature of a potential extension is obvious, and the implementation is straightforward. If the extension is clear in definition, and we have a firm idea of how it should by implemented, then there is no reason to delay that capability unitl a later release.

In the Domain subsystem, the RectilinearDomain class will immediately support half-open intervals for parameter limits (that is, having only an upper or lower limit for a paramenter). It will also be easy to substitute for the arcsin mapping functions.

In the Function subsystem, the package will allow supplying second derivatives (either diagonal or full matrix) along with the gradient.

In the Termination subsystem, several new basic choices will be provided, including a time-based termination, and arbitrary logical combinations of termination conditions will be supported.

## VI STATUS

A preliminary partial implementation of this package has been done, to obtain familiarity with the Minuit algorithms and concepts, and to get a feel for the design issues. (A spin-off of this work is a set of heavily-commented Minuit Fortran “source” code, and some mathematical documentation of the Minuit algorithms.)

The package design is completed (though not set in stone) and most interfaces have been defined and headers coded. Re-implementation of the classes, based on the actual design, is in progress.

The CERN effort (as discussed with F. James) is at the point where the minimization algorithms (but not all of the analysis algorithms) have first-pass implementions, again in a familiarization phase. Since the two efforts are at comparable stages, the prospects for coordination seem reasonable.

###### Acknowledgements.

The authors wish to acknowledge substantial assistance in package design and C++ technique from Walter Brown and Marc Paterno. This work was performed at Fermilab, which is operated by the Universities Research Association, under contract number DE-AC02-76CH03000 with the U.S. Department of Energy.


format: text

text:
# On contributions of fundamental particles to the vacuum energy

## 1 Introduction

Recently the problem of the contribution of different fermionic and bosonic fields to the vacuum energy was revived in relation to the cosmological constant problem (see e.g. ). The general form of the vacuum energy density under discussion was

$$\rho =a_4\mathrm{\Lambda }^4+a_2\mathrm{\Lambda }^2M^2+a_0M^4\mathrm{ln}\frac{\mathrm{\Lambda }^2}{M^2},$$
(1)
where $`M`$ is the mass of the corresponding field, and $`\mathrm{\Lambda }`$ is the ultraviolet energy cut-off. Different regularization schemes were suggested in order to obtain the dimensionless parameters $`a_i`$.

Here we consider this problem from the point of view of the effective relativistic quantum field theory emergent in the low-energy corner of the quantum vacuum, whose ultraviolet structure is known. It appears that the parameters $`a_i`$ depend on the details of the trans-Planckian physics. But in addition we find that even if the two vacua have completely identical structure throughout all the scales, the parameters $`a_i`$ depend on the arrangement and geometry of the vaccum state. In particular, if the vacuum is completely homogeneous and static, all the parameters vanish, $`a_4=a_2=a_0=0`$, which corresponds to zero cosmological constant. While in the presence of the interface between two different vacua, the energy density can depend not only on the mass $`M`$, but also on the mass of the quantum field in the neighboring vacuum.

As an example we consider two vacua, whose structure is identical in the high-energy limit, while in the low-energy corner they have the same fermionic content, but their low-energy fermions have slightly different masses. Let us assume that both vacua correspond to the local minima, and the route between these vacua lies only through the vacuum with Weyl fermions of zero mass. Then these vacua can coexist in the configuration shown in Fig. 1. The false vacuum occupies the whole Universe except for the bubble of the true vacuum separated from the false vacuum by the interface where the vacuum has zero-mass fermions. Let us consider the behavior of the vacuum energy density $`\rho `$ outside and inside the bubble, when this confiuration is static, i.e. when the bubble has the critical size $`R`$ corresponding to the saddle point of energy functional.

The picture, which is supported by the effective relativistic quantum field theory emerging in condensed matter systems, where the structure of the vacuum is known both at high and low energy (Sec. 2), is shown in Fig. 1. The energy density of the false vacuum outside the bubble does not contain any fermionic mass $`M`$, since this energy is simply zero;

$$\rho _{\mathrm{false}}=P_{\mathrm{false}}=0.$$
(2)
This corresponds to zero cosmological constant in any homogeneous vacuum, if the vacuum is stationary, corresponds to the extremum of the energy functional, and is isolated from the environment .

The energy density of the true vacuum inside the bubble,

$$\rho _{\mathrm{true}}=P_{\mathrm{true}}\mathrm{\Lambda }^2\left(M_{\mathrm{true}}^2M_{\mathrm{false}}^2\right)\sqrt{g}<0.$$
(3)
contains the quadratic in $`M_{\mathrm{true}}`$ term with negative sign, but it also depends quadratically on the fermionic mass $`M_{\mathrm{false}}`$ in the neighboring vacuum. On the other hand, if the true vacuum occupies the whole space and becomes equilibrium, its vacuum energy density is zero again, $`\rho _{\mathrm{true}}=P_{\mathrm{true}}=0`$.

All this can be obtained without invoking the microscopic (ultraviolet) structure of the quantum vacuum, using only the general arguments of the vacuum stability. However, here we shall use the microscopic model from which the relativistic quantum field theory with massive fermions emerges in the low-energy corner.

## 2 Vacuum energy in effective quantum field theory

### 2.1 Effective quantum field theory with Dirac fermions

Massive relativistic fermions are realized as the low-energy Bogoliubov quasiparticles in the class of the spin-triplet superfluids/superconductors (see section 7.4.9 of ). The Bogoliubov–Nambu Hamiltonian for fermionic quasiparticles (analog of elementary particles) is the $`4\times 4`$ matrix

$`H_𝐩=\stackrel{ˇ}{\tau }^3\left({\displaystyle \frac{p^2}{2m}}\mu \right)+\stackrel{ˇ}{\tau }^1\sigma ^\mu p_ie_\mu ^i,`$ (4)
$`e_\mu ^i={\displaystyle \frac{\mathrm{\Lambda }}{p_F}}\left(\widehat{x}_\mu \widehat{x}^i+\widehat{y}_\mu \widehat{y}^i\right)+{\displaystyle \frac{M}{p_F}}\widehat{z}_\mu \widehat{z}^i,{\displaystyle \frac{p_F^2}{2m}}=\mu .`$ (5)
Here $`\mu `$ is the chemical potential of the particles (atoms) forming the liquid (analog of the quantum vacuum); $`m`$ is their mass; $`\stackrel{ˇ}{\tau }^a`$ and $`\sigma ^\mu `$ are $`2\times 2`$ Pauli matrices describing the Bogoliubov-Nambu spin and the ordinary spin of particles correspondingly; $`\mathrm{\Lambda }`$ and $`M`$ are amplitudes of the order parameter $`e_\mu ^i`$.

One should not confuse particles which form the vacuum (atoms of the liquid) and quasiparticles – excitations above the vacuum – which form the analog of matter in quantum liquids and correspond to elementary particles. Quasiparticles do not scatter on the atoms of the liquid if the liquid is in its ground state, and thus for quasiparticles the ground state of the liquid is seen as an empty space – the vacuum – though this space is densly filled by atoms.

The energy spectrum of quasiparticles in this model is

$$E^2(𝐩)=H_𝐩^2=\left(\frac{p^2}{2m}\mu \right)^2+\mathrm{\Lambda }^2\frac{p_x^2+p_y^2}{p_F^2}+M^2\frac{p_z^2}{p_F^2}.$$
(6)
The case $`M=0`$ corresponds to the so-called planar phase, while $`M=\mathrm{\Lambda }`$ describes the isotropic B-phase of superfluid 3He.

We assume that the interaction of atoms in the liquid (or electrons in superconductors), which leads to the formation of the order parameter, is such that the locally stable vacuum states of the liquid have $`M\mathrm{\Lambda }`$. Then in the low-energy limit the Bogoliubov–Nambu Hamiltonian for quasiparticles transforms to the Dirac Hamiltonian

$`H_𝐩c_{}\stackrel{~}{p}_z\stackrel{ˇ}{\tau }^3+\stackrel{ˇ}{\tau }^1(c_{}p_x\sigma _x+c_{}p_y\sigma _y+M\sigma _z),`$ (7)
$`\stackrel{~}{p}_z=p_zp_F,c_{}={\displaystyle \frac{p_F}{m}},c_{}={\displaystyle \frac{\mathrm{\Lambda }}{p_F}},`$ (8)
with the relativistic spectrum

$`E^2(𝐩)g^{ik}\stackrel{~}{p}_i\stackrel{~}{p}_k+M^2,`$ (9)
$`\stackrel{~}{𝐩}=𝐩p_F\widehat{𝐳},g^{xx}=g^{yy}=c_{}^2,g^{zz}=c_{}^2.`$ (10)
Here $`c_{}`$ is the ‘speed of light’ propagating along the $`z`$-axis, while in transverse direction the ‘light’ propagates with the speed $`c_{}`$. Though in this model the effective speed of light depends on the direction of propagation, this anisotropy can be removed by rescaling along the $`z`$-axis. The speed of light is not fundamental, since it is determined by the material parameters of the microscopic system. However, it is fundamental from the point of view of all inner observers who consist of the low-energy quasiparicles. For them the speed of light does not depend on direction, and they believe in the laws of special relativity since these laws can be confirmed by all experiments (including the Michelson–Morley measurements of the speed of light) which use clock and rods made of the low-energy quasiparticles. The high-energy observer will not agree with that: for us the original model (4) has no Lorentz invariance, and the speed of light is anisotropic.

After rescaling along the $`z`$-axis the quasiparticles become the complete analog of the Standard Model fermions with mass $`M`$: the left-handed and right-handed chiral quasiparticles of the planar state with $`M=0`$ are hybridized to form the Dirac particles with the mass $`M`$. Note, that together with the effective Dirac fermions, also the effective gravity and effective $`U(1)`$ and $`SU(2)`$ gauge fields (with ‘photons’ and ‘gauge bosons’) emerge in the low-energy corner of this model, with all the accompaning phenomena, such as chiral anomaly, running couplings, etc. . The reason for such close analogy is the momentum space topology of the quantum vacuum, which is common for the ground state of the considered liquid and for the quantum vacuum of the Standard Model. The parameter $`\mathrm{\Lambda }`$ plays the role of the Planck energy scale in the effective theory.

### 2.2 Vacuum energy

This model can serve for the consideration of the contribution of the Dirac fermions to the energy density of the vacuum in equilibrium. In the many body system (superfluid liquid which contain many particles) the relevant vacuum energy whose gradient expansion gives rise to the effective quantum field theory for quasiparticles at low energy is $`\mu 𝒩_{\mathrm{eq}\mathrm{vac}}`$,  where $``$ is the Hamiltonian of the system, $`𝒩`$ is the particle number operator for atoms forming the liquid, and $`\mu `$ is their chemical potential. The energy density of the superfluid/superconducting ground state (analog of the quantum vacuum) with the order parameter $`e_\mu ^i`$ is given by (see e.g. Eq.(5.38) in )

$$\rho =\frac{1}{V}\mu 𝒩_{\mathrm{vac}}=\frac{1}{V}\mu 𝒩_{\mathrm{vac}e_\mu ^i=0}\frac{p_F^3m}{12\pi ^2\mathrm{}^3}e_\mu ^ie_\mu ^i,$$
(11)
where $`V`$ is the volume of the system. For the order parameter (5) which gives rise to the relativistic fermions at low energy one has

$$\rho =\rho (0)\frac{\sqrt{g}}{12\pi ^2\mathrm{}^3}\left(2\mathrm{\Lambda }^4+\mathrm{\Lambda }^2M^2\right),$$
(12)
where $`\sqrt{g}=c_{}^1c_{}^2`$ according to Eq.(10); and $`\rho (0)\rho (e_\mu ^i=0)`$ is the energy density in the normal (non-superfluid) state of the liquid, in which $`e_\mu ^i=0`$. The equation (12) demonstrates that the amplitude $`\mathrm{\Lambda }`$ in the order parameter expression (5) is the proper ultraviolet cut-off for the estimation of the vacuum energy related to the effective relativistic fermions, while the contribution $`\rho (0)`$, which does not depend on $`\mathrm{\Lambda }`$ and $`M`$, comes from the more fundamental physics of the normal state of the liquid at energies well above the energy scales $`\mathrm{\Lambda }`$ and $`M`$. In this model the term $`M^4\mathrm{ln}(\mathrm{\Lambda }^2/M^2)`$ is absent, though it naturally appears in all the regularization schemes discussed in .

The dimensionless factors in front of $`\mathrm{\Lambda }^4`$ and $`\mathrm{\Lambda }^2M^2`$ were obtained using the microscopic model in Eqs. (5) and (6). In principle, the low-energy fermions in Eq.(9) can be obtained from different microscopic theories, and one finds that the dimensionless factors in front of $`\mathrm{\Lambda }^4`$ and $`\mathrm{\Lambda }^2M^2`$ depend on the details of the Planck physics. In other words, they depend on the regularization imposed by the ultraviolet physics, which cannot be found within the effective low-energy theory.

It is rather natural to think that the equation (12) reflects the general structure (1) of the vacuum energy in terms of the massive fields discussed in . Moreover, from the point of view of the low-energy observers who are made of quasiparticles and live in the liquid and for whom the effective theory is fundamental, the cosmological constant in their world must have the natural value of order $`\mathrm{\Lambda }^4`$. However, this is not so. The vacuum energy contains the contribution $`\rho (0)`$ from the vacuum degrees of freedom with energies well above $`\mathrm{\Lambda }`$ and $`M`$. Together with the sub-Planckian modes these high-energy modes determine the behavior of the whole vacuum, and in particular the stability of the static vacuum configurations. If something happens in the low-energy corner, so that the vacuum configuration changes, the high-energy degrees of freedom respond to restore the stability of the whole vacuum in the new configuration. As a result $`\rho (0)`$ is tuned to the low-energy degrees of freedom and thus becomes dependent on $`\mathrm{\Lambda }`$ and $`M`$ after the adjustment of the trans-Planckian degrees to the sub-Planckian ones. This dependence is different for different realizations of the equilibrium vacuum state. Moreover, the adjustment can cancel completely or almost completely the low-energy contributions. Below we consider how this occurs in the geometry of Fig. 1.

### 2.3 Energy density of the false vacuum

Let us assume now that the situation is similar to that of the Ising ferromagnet in applied small magnetic field which slightly discriminates between spin-up and spin-down vacua. This means that there are two vacuum states, false and true, corresponding to two nearly degenerate local minima whose fermionic masses are almost the same:

$$0<M_{\mathrm{true}}^2M_{\mathrm{false}}^2M_{\mathrm{true}}^2\mathrm{\Lambda }^2.$$
(13)
Then we can apply this to the vacuum states in the geometry of Fig. 1, where the false vacuum is separated by the domain wall (the interface) from the spherical domain containing the true vacuum.

Let us start with the external domain occupied by the false vacuum. This domain is open and it occupies the whole space except for the finite volume. That is why one can apply to this domain the results known for the infinite homogeneous vacuum. First, we note that any equilibrium macroscopic system consisting of the identical elements (atoms in the case of quantum liquids) obeys the Gibbs-Duhem relation

$$E\mu NTS=PV,$$
(14)
where $`P`$ is the pressure and $`S`$ the entropy (see Chapter 10.9 in Ref. ). Applying this to the equilibrium ground state of the system at $`T=0`$ (the quantum vacuum), one has for the energy density of the vacuum:

$$\rho =\frac{1}{V}\mu 𝒩_{\mathrm{vac}}=\frac{E\mu N}{V}=P.$$
(15)
This equation of state, $`\rho =P`$, is valid for any homogeneous vacuum irrespective of whether the system is relativistic or not. If the effective relativistic quantum field theory emerges in the low-energy corner of the system, this $`\rho `$ becomes the cosmological cosntant in the low-energy world.

Second, if the system (the Universe) is isolated from the environment, the external pressure $`P_{\mathrm{external}}=0`$. Thus for the false vacuum in Fig. 1 one has $`P_{\mathrm{false}}=P_{\mathrm{external}}=0`$, which gives the vanishing energy density of the false vacuum in this geometry:

$$\rho _{\mathrm{false}}=P_{\mathrm{false}}=0.$$
(16)
Thus the cosmological constant in the vacuum outside the bubble is zero. This property does not depend on the low-energy physics, and is determined by the physics of the whole vacuum including the degrees of freedom at energies well above the scales $`\mathrm{\Lambda }`$ and $`M`$. These high-energy degrees of freedom respond to any change in the low-energy corner exactly compensating the contribution from the low-energy degrees of freedom to ensure the zero value of the cosmological constant in the equilibrium homogeneous vacuum.

### 2.4 Energy and pressure of the true vacuum

Now let us turn to the inner domain occupied by the true vacuum. If the domain is big enough, $`R\mathrm{\Lambda }^1`$, the vacuum can be considered as homogeneous, and thus the equation of state $`\rho =P`$ in (15) is applicable. However, this vacuum is not isolated from the environment, and as a result its vacuum energy density is non-zero. This energy density $`\rho _{\mathrm{true}}`$ can be found by comparison with the energy density of the false vacuum using Eq.(12). Since $`\rho _{\mathrm{false}}=0`$ one has

$$\rho _{\mathrm{true}}=P_{\mathrm{true}}=\rho _{\mathrm{true}}\rho _{\mathrm{false}}=\frac{1}{12\pi ^2\mathrm{}^3}\sqrt{g}\mathrm{\Lambda }^2\left(M_{\mathrm{true}}^2M_{\mathrm{false}}^2\right)<0.$$
(17)
In this geometry, the true vacuum has the negative cosmological constant proportional to the difference of $`M^2`$ in two vacua. The quartic term $`\mathrm{\Lambda }^4`$ does not appear in the considered model; it appears if the two vacua have different physics at energies below $`\mathrm{\Lambda }`$. Note that if the true vacuum is outside and is in equilibrium, the cosmological constant in this vacuum will be zero again.

Let us now estimate the radius $`R`$ of the static bubble – the saddle-point critical bubble – which is obtained when the vacuum pressure inside the bubble is compensated by the effect of the surface tension. Since the external pressure is zero, the pressure $`P_{\mathrm{true}}`$ within the domain is determined by the surface tension and the curvature of the domain wall:

$$P_{\mathrm{true}}=P_{\mathrm{true}}P_{\mathrm{false}}=\frac{2\sigma }{R}.$$
(18)
Comparing equations (17) and (18) one obtains the radius of the static bubble critical bubble. The order of magnitude of the surface tension is $`\sigma \rho (M=0)\xi `$, where $`\xi `$ is the thickness of the domain wall; and $`\rho (M=0)`$ is the energy density of the vacuum with massless fermions. This energy can be obtained by comparing it with the energy density of either of the domains, and it appears to be positive:

$$\rho (M=0)=\rho (M=0)\rho _{\mathrm{false}}=\frac{\sqrt{g}}{12\pi ^2\mathrm{}^3}\mathrm{\Lambda }^2M_{\mathrm{false}}^2>0.$$
(19)
This gives the following estimation for the radius of the critical bubble:

$$R\xi \frac{M_{\mathrm{false}}^2}{M_{\mathrm{true}}^2M_{\mathrm{false}}^2}\xi .$$
(20)
Here $`\xi \mathrm{}c_{}/\mathrm{\Lambda }`$ in our model, and $`\xi \mathrm{}c/\mathrm{\Lambda }`$ in its relativistic counterpart.

## 3 Conclusion

In general, the energy density of the quantum vacuum is determined by all the vacuum degrees of freedom. They act coherently as the elements of the same medium, which results in the zero value of the cosmological constant if the vacuum is equilibrium, homogeneous and is isolated from the environment. Thus the contribution of the zero-point motion of the low-energy fermionic and bosonic fields to the vacuum energy cannot be singled out from the ultrviolet contributions and thus it cannot be obtained from the low-energy theory by any regularization scheme. The low-energy physics is capable to describe only the contribution of different ifrared perturbations of the vacuum to the vacuum energy density, such as dilute matter, space curvature, expansion of the Universe, rotation, Casimir effect, etc. . This gives rise to induced vacuum energy which is proportional to the energies of the infrared perturbations, including the energy density of matter, which is in agreement with observations . If the Universe evolves in time, cosmological ‘constant’ becomes an evolving physical quantity, which responds to the combined action of the evolving perturbations of the vacuum state.

The example which we considered here is somewhat similar to the Casimir effect, where the difference in energy density between two neghbouring vacua, in the restricted and unrestricted domains, are calculated using the low-energy physics. In our case, the two vacua across the interface (domain wall) also have identical ultraviolet (microscopic) structure and also have very close low-energy theories, whose fermionic and bosonic contents are the same, but the masses of the fields are slightly different. That is why, for the estimation of the difference one can try to explore the low-energy physics. One can use, for example, the regularized equation for the contribution of the massive quantum field to the energy-momentum tensor of the vacuum – the equation (9) in Ref.  with minus sign when applied to the fermionic field:

$$t_{\mu \nu }=g_{\mu \nu }M^2\frac{d^4p}{(2\pi )^3}\delta (p^2M^2)\theta (p_0).$$
(21)
Then for the difference in energy and pressure between the true and false vacua one obtains:

$`\rho _{\mathrm{true}}\rho _{\mathrm{false}}=P_{\mathrm{false}}P_{\mathrm{true}}`$ (22)
$`=\left(M_{\mathrm{true}}^2M_{\mathrm{false}}^2\right){\displaystyle \frac{d^3p}{2(2\pi )^3}\frac{1}{cp}}\sqrt{g}\mathrm{\Lambda }^2\left(M_{\mathrm{true}}^2M_{\mathrm{false}}^2\right),`$ (23)
where $`\sqrt{g}=c^3`$. This gives for the energy and pressure difference the correct dependence on masses, the correct sign and even the correct Gibbs-Duhem relation $`\mathrm{\Delta }\rho =\mathrm{\Delta }P`$. However, the numerical factor is still missing because of the quadratic divergence, and this factor depends on details of the microscopic physics. This demonstrates that the regularization schemes are not applicable in a strict sense even when the difference in the vacuum energies is calculated.

As for the energy density itself (the cosmological constant), it is determined (as in the case of the Einstein and Gödel Universes ) by the equilibrium properties of the whole system and depends on the geometry. In particular, for the equilibrium homogeneous vacuum one obtains $`\rho =P=0`$, irrespective of whether this vacuum is true or false, and whether it contains massive or massless fermions. On the other hand, the vacuum inside the bubble is not isolated from the environment, as a result the energy density of this vaccum is non-zero and is given by the difference of the quadratic terms in Eq.(3). Except for the numerical factor, this result can be reproduced without consideration of the microscopic theory. In addition to the general arguments of the vacuum stability, including the Gibbs-Duhem relation, one can use the effective low-energy theory for the order-of-magnitude estimation of the energy and pressure difference of two neighboring vacua. For our particular problem, we can use the regularization presented in Eq.(21).

This work was supported by ESF COSLAB Programme and by the Russian Foundations for Fundamental Research.