Skip to content

feat: extend a tangent vector for a locally smooth vector field#30339

Closed
grunweg wants to merge 12 commits intoleanprover-community:masterfrom
grunweg:localframes-3
Closed

feat: extend a tangent vector for a locally smooth vector field#30339
grunweg wants to merge 12 commits intoleanprover-community:masterfrom
grunweg:localframes-3

Conversation

@grunweg
Copy link
Copy Markdown
Contributor

@grunweg grunweg commented Oct 8, 2025

Given a vector bundle V over M and a vector X in the fibre E x some point x,
construct a section of V which is smooth near x and has value X at x.

This will be used to prove the tensoriality of covariant derivatives.

From the path towards geodesics and the Levi-Civita connection.

Co-authored-by: Patrick Massot patrickmassot@free.fr


Open questions I'd like a second opinion on:

  • should this definition be generalised to any local frame (on some set U ∋ x)? this would be easy; at the moment, I don't see how we would need that seems not necessary

  • should the new definition be namespaced, e.g. in the Trivialization namespace?

  • order of the explicit arguments: first e then b, or the other way around? might be resolved by the previous point

  • depends on: [Merged by Bors] - feat: local frames in a vector bundle #30083

Open in Gitpod

@github-actions github-actions bot added the t-differential-geometry Manifolds etc label Oct 8, 2025
@github-actions
Copy link
Copy Markdown

github-actions bot commented Oct 8, 2025

PR summary 0b5d4bb20c

Import changes for modified files

No significant changes to the import graph

Import changes for all files
Files Import difference

Declarations diff

+ contMDiffOn_localExtensionOn
+ localExtensionOn
+ localExtensionOn_apply_self
+ localExtensionOn_localFrame_coeff

You can run this locally as follows
## summary with just the declaration names:
./scripts/declarations_diff.sh <optional_commit>

## more verbose report:
./scripts/declarations_diff.sh long <optional_commit>

The doc-module for scripts/declarations_diff.sh contains some details about this script.


No changes to technical debt.

You can run this locally as

./scripts/technical-debt-metrics.sh pr_summary
  • The relative value is the weighted sum of the differences with weight given by the inverse of the current value of the statistic.
  • The absolute value is the relative value divided by the total sum of the inverses of the current values (i.e. the weighted average of the differences).

@grunweg grunweg mentioned this pull request Oct 8, 2025
35 tasks
@mathlib4-dependent-issues-bot mathlib4-dependent-issues-bot added the blocked-by-other-PR This PR depends on another PR (this label is automatically managed by a bot) label Oct 8, 2025
@mathlib4-merge-conflict-bot mathlib4-merge-conflict-bot added the merge-conflict The PR has a merge conflict with master, and needs manual merging. (this label is managed by a bot) label Oct 23, 2025
@mathlib4-merge-conflict-bot
Copy link
Copy Markdown
Collaborator

This pull request has conflicts, please merge master and resolve them.

@github-actions github-actions bot removed the merge-conflict The PR has a merge conflict with master, and needs manual merging. (this label is managed by a bot) label Oct 23, 2025
@mathlib4-merge-conflict-bot mathlib4-merge-conflict-bot added the merge-conflict The PR has a merge conflict with master, and needs manual merging. (this label is managed by a bot) label Nov 19, 2025
@mathlib4-merge-conflict-bot
Copy link
Copy Markdown
Collaborator

This pull request has conflicts, please merge master and resolve them.

@github-actions github-actions bot removed the merge-conflict The PR has a merge conflict with master, and needs manual merging. (this label is managed by a bot) label Feb 22, 2026
@mathlib-dependent-issues mathlib-dependent-issues bot removed the blocked-by-other-PR This PR depends on another PR (this label is automatically managed by a bot) label Feb 24, 2026
@mathlib-dependent-issues
Copy link
Copy Markdown

This PR/issue depends on:

@mathlib-merge-conflicts mathlib-merge-conflicts bot added the merge-conflict The PR has a merge conflict with master, and needs manual merging. (this label is managed by a bot) label Feb 24, 2026
@mathlib-merge-conflicts
Copy link
Copy Markdown

This pull request has conflicts, please merge master and resolve them.

@grunweg grunweg removed the merge-conflict The PR has a merge conflict with master, and needs manual merging. (this label is managed by a bot) label Feb 24, 2026
@grunweg grunweg added the awaiting-CI This PR does not pass CI yet. This label is automatically removed once it does. label Feb 24, 2026
@grunweg grunweg added WIP Work in progress and removed awaiting-CI This PR does not pass CI yet. This label is automatically removed once it does. labels Feb 28, 2026
@grunweg
Copy link
Copy Markdown
Contributor Author

grunweg commented Mar 1, 2026

@ocfnash Would you also like to take a look at the next piece in the local frames saga?

@ocfnash ocfnash self-assigned this Mar 1, 2026
@ocfnash
Copy link
Copy Markdown
Contributor

ocfnash commented Mar 1, 2026

@grunweg Yes of course happy to review: should I wait for the WIP label to disappear or look already tomorrow?

@grunweg grunweg removed the WIP Work in progress label Mar 1, 2026
@grunweg
Copy link
Copy Markdown
Contributor Author

grunweg commented Mar 1, 2026

Oh, I wasn't aware that label was still present. I do have three higher-level questions (which are also in the PR description) --- depending on their answer, this PR will become WIP again --- but otherwise, this is ready for a look.

Comment on lines +602 to +607
The details of this extension are unspecified (and could be subject to change).
Currently, we construct this extension using a local frame induced by a choose of basis of the
fibre `F` and a compatible trivialisation `e` of `V` around `x`.
(Allowing any local frame near `x` would be easy to implement.)
Our construction has constant coefficients on `e.baseSet` w.r.t. this local frame, and is zero
otherwise. In particular, it is smooth on `e.baseSet`, and (globally) linear in `v`.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given this, I tend to think we should make this an existential lemma rather than a definition. E.g., something like:

lemma exists_foo [CompleteSpace 𝕜] [FiniteDimensional 𝕜 F] [ContMDiffVectorBundle ∞ F V I]
    (e : Trivialization F (TotalSpace.proj : TotalSpace F V → M)) [MemTrivializationAtlas e]
    {x : M} (hx : x ∈ e.baseSet) :
    ∃ s : V x →ₗ[𝕜] ((x' : M) → V x'), ∀ v, s v x = v ∧ CMDiff[e.baseSet] ∞ (T% (s v)) := by
  sorry

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be really really inconvenient. We want to use this definition as input to other definitions. Your proposal would result in lots of letI on top of definition bodies. A typical use is https://github.com/leanprover-community/mathlib4/pull/36128/changes#diff-3f270ece139d7bb1abd8287dd1aed17f07e2434ca37578061c60fecca1db925bR416

Comment on lines +613 to +614
-- XXX: we could generalise this definition to any local frame on `U ∋ x`, with smoothness on `U`.
-- Would this be useful? Should do this?
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does sound like it would be worth having. If there is a very good API for passing from a local frame to a trivialization then probably that is what we should do here instead. OTOH if not (and if there cannot be such API), we might just want both (and the local frame version could happen later).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don’t think it’s worth having this. Using local frame here was already a mistake we made because we didn’t know enough about existing stuff. The extension using another frame would have no extra property at all.

@ocfnash ocfnash added the awaiting-author A reviewer has asked the author a question or requested changes. label Mar 4, 2026
@grunweg
Copy link
Copy Markdown
Contributor Author

grunweg commented Mar 5, 2026

-awaiting-author

@github-actions github-actions bot removed the awaiting-author A reviewer has asked the author a question or requested changes. label Mar 5, 2026
@PatrickMassot
Copy link
Copy Markdown
Member

Closing in favor of #36234

@grunweg grunweg deleted the localframes-3 branch March 6, 2026 11:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants