On boundary terms from variational derivatives

321 views
Skip to first unread message

Leo Stein

unread,
Jun 11, 2015, 3:20:38 PM6/11/15
to Jose M. Martin-Garcia, Alfonso Garcia-Parrado, Kartik Prabhu, xAct Tensor Computer Algebra
Hi all,

Kartik (CCed) pointed out to me that VarD currently assumes that all boundary terms vanish. This assumption is fine for most settings, but it may be quite useful to include boundary terms (e.g. to get at the symplectic structure of some Lagrangian theory). This can also be an opportunity to improve xTensor's formulation of variational derivatives.

In the attached notebook I have included a (very hacky) example of keeping the boundary terms around when performing the variational derivative. The current formulation of VarD is, in my opinion, not ideal for keeping around these boundary terms.

Questions for the list: Should we include code for boundary terms in xTensor? Should we reformulate VarD?

One potential reworking would introduce "chains" (regions) and symbolic integrals. Then you could imagine writing an action integral (rather than just the Lagrangian) e.g.
  action = Integral[ Lagrangian, region ].
Regions naturally admit the boundary operation ∂, and ∂^2 =0. Boundaries naturally have normals associated with them. It would then be natural to include boundary integrals as well, e.g. to include the Gibbons-Hawking-York boundary term to the Einstein-Hilbert action,
  action = Integral[ bulkLagrangian, bulkRegion ] +
                   Integral[ GHY, Boundary[bulkRegion] ]
It is very simple to introduct the generalized Stokes' theorem, etc.

Any thoughts on this topic from the list?

Leo
ForKartik.nb

Jose

unread,
Jun 11, 2015, 6:44:35 PM6/11/15
to xa...@googlegroups.com, leo....@gmail.com, alf...@math.uminho.pt, kar...@uchicago.edu, jo...@xact.es
Hi,

This looks like a great idea, Leo. I like the BoundaryTerm object. We could write

VarDBoundaryTerm[head_[___]][expr_, nrest_] := BoundaryTerm[(expr /. head[inds___] :> Perturbation[head[inds]]) nrest]

VarD[tensor_, covd_][covd_?CovDQ[ind_][expr_], rest_] :=
 - VarD[tensor, covd][expr, covd[ind][rest]]
 + If[$BoundaryTerms, VarDBoundaryTerm[tensor][expr, n[ind] rest], 0]

with default $BoundaryTerms = False to preserve backwards compatibility. Note that the first line of the RHS is identical to the formula we use right now, and that if $BoundaryTerms is False then there is no time lost in Perturbation computations. I guess we have to remove the perturbed field from the argument of BoundaryTerm, right?

We have discussed in the past the idea of introducing an Integral construction, and I know that in particular Alfonso has considered this possibility, at least in relation to differential forms. I would suggest to introduce a separate command, to avoid confusion. Something like IntegralVarD, which differentiates Integral objects and returns Integral objects. We would have two alternative representations (VarD and IntegralVarD) of the same operation.

How would we handle the abstract manifolds with boundary? Would we need an extension of DefManifold? Perhaps a new type of object?

Can we have Integral already in xTensor, or is it better to construct it in xTerior? Perhaps we can have a basic form Integral[Lagrangian, region] and an extended version Integral[scalar, volumeForm, region] in xTerior.

Cheers,
Jose.

Alfonso García-Parrado Gómez-Lobo

unread,
Jun 12, 2015, 4:32:03 PM6/12/15
to Jose, xa...@googlegroups.com, leo....@gmail.com, kar...@uchicago.edu
Hi,



> We have discussed in the past the idea of introducing an Integral
> construction, and I know that in particular Alfonso has considered
> this possibility, at least in relation to differential forms. I would
> suggest to introduce a separate command, to avoid confusion. Something
> like IntegralVarD, which differentiates Integral objects and returns
> Integral objects. We would have two alternative representations (VarD
> and IntegralVarD) of the same operation.
>

I did consider it but only restricted to the integration of differential
forms over mesh regions. In the end I abandoned because mesh regions in
Mathematica do not carry an orientation (even though in those cases
where an orientation is possible).

>
> How would we handle the abstract manifolds with boundary? Would we
> need an extension of DefManifold? Perhaps a new type of object?
>
In principle I don't think an extension of DefManifold is needed. One
can define two manifolds M1 and M2 and then do some declaration which
states that, say M2, is the boundary of M1. If necessary, a command
called "Boundary" can be created in such a way that Boundary[M1] returns
M2.


> Can we have Integral already in xTensor, or is it better to construct
> it in xTerior? Perhaps we can have a basic form Integral[Lagrangian,
> region] and an extended version Integral[scalar, volumeForm, region]
> in xTerior.
>
>
I favour the second possibility but we need to think what sort of
regions can be admitted. In xTensor I can only think of a manifold as a
valid region but in xTerior there are more possibilities. The mesh
region which I mentioned above is one of them but there's the problem of
the undefined orientation. Other possibilities are all the Region
objects which already exist in Mathematica but probably this will result
in many possibilities and so a basic choice would have to be made.

Alfonso.


Leo Stein

unread,
Jun 14, 2015, 6:40:41 PM6/14/15
to Alfonso García-Parrado Gómez-Lobo, Jose, xAct Tensor Computer Algebra, Kartik Prabhu, Guillaume Faye
Hi all,

> I would suggest to introduce a separate command, to avoid confusion. Something like IntegralVarD

Agreed.

Let's discuss what sort of structures we want to be able to handle, and then discuss the notation associated with it.

Do we want to be able to represent integrals on regions R ↪ M of dimension r <= m? This is quite general and it might open up a big can of worms.

> How would we handle the abstract manifolds with boundary? Would we need an extension of DefManifold? Perhaps a new type of object?

Every manifold is a region, including submanifolds (currently xTensor only allows a submanifold to be strictly lower in dimension than the ambient manifold, so this would mean we couldn't integrate over top-dimension submanifolds---perhaps should be weakened). However, maybe not all regions are manifolds. It is nice to be able to consider a vector space of regions over Z, Q, R, or C. It is also nice to consider the complex of chains by having the boundary operator, with Boundary[Boundary[_]] = 0.

Perhaps this means we should create an abstract Region type (not to be confused with the new builtin Region; discuss later if we should try to connect with this).

As mentioned by Alfonso, we can set UpValues for Boundary[M]. DefManifold could handle an additional option Boundary, e.g. we could say something like Boundary->None for a manifold with vanishing boundary, Boundary[M]^=0. Otherwise, Boundary[M] could just be treated as a d-1 dimensional manifold or chain.

I think it's clear that we should have a notation for the natural pairing between p-forms and p-chains (or p-dimensional (sub)manifolds). If we're doing this on the xTerior side, we should also do it on the xTensor side and allow for integration of scalars on regions of arbitrary dimension—if we have the right density to integrate against.

The natural density to integrate against is the volume element of an induced metric (or more weakly just and induced volume form) for the region. For now let's just talk about metrics and ignore the case of volume element without metric. There are several structures related to this. If we are performing an integral over region R ↪ M of dimension r <= m then we want something like
  InducedMetric[g,R][-a,-b],
the metric induced on R from the ambient metric g. The indices -a,-b should really live in Tangent[R] (which is a subbundle of Tangent[M] along R). How do we even know what the rank (<= R) of this metric is, and if it is full rank, what the sign of its determinant is? Do we then introduce
  Determinant[InducedMetric[g,R]]
and allow
  CovDOfMetric[InducedMetric[g,R]][-a]?
Do we need Gauss-Codazzi equations for this connection relative to the ambient connection of g? In general we need to understand the r+s decomposition, not just the r+1 decomposition. Maybe Guillaume will comment on this.

Back to the reason this is all coming up, including the boundary terms. You'll notice in my example notebook that I just defined some vector n[a]. xTensor would have to pre-define some object to represent the normal vector associated to the boundary of some region. If we have R and Boundary[R], we probably want an object like
   NormalVector[Boundary[R]][a].
Of course this could pretty-print as n_{\pd R}^{a} or anything you'd like. This object only makes sense for NormalVector[Boundary[ _ ] ], not for NormalVector[R]. If R is dimension r, then in fact its normal bundle has dimension m-r=s; so there is not a normal vector, but rather an entire bundle. For the special case of the boundary of a region, it has codimension-1 with respect to R, so the normal bundle is 1 dimensional within Tangent[R].
------------------------------------------------------------
This turned out to be a long email. Let me summarize a bit.
1. Should we allow integration of regions of arbitrary dimension?
2. I think regions should have their own type, so we can take formal linear combinations with coefficients in (say) reals.
3. We should have a Boundary[] operator to act on chains (regions), and Boundary[Boundary[_]] = 0.
4. We should have a function to associate a manifold and its boundary. This may also be an option to DefManifold.
5. The right density to integrate against is the volume element of an induced metric on a submanifold.
6. This motivates something like
  InducedMetric[g,R][-a,-b],  Determinant[InducedMetric[g,R]],  CovDOfMetric[InducedMetric[g,R]][-a],
and many related structures, indices in Tangent[R], so on.
7. This requires an understanding of the r+s decomposition (Guillaume's help required :).
8. Need Gauss-Codazzi for r+s?
9. For boundary terms, need object like
   NormalVector[Boundary[R]][a].

That's it for now.
Leo
Reply all
Reply to author
Forward
0 new messages