Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions .github/workflows/regression.yml
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,12 @@ jobs:
with:
# tags needed for dynamic versioning
fetch-depth: 0
- name: Setup pixi 📦
uses: prefix-dev/setup-pixi@v0.8.8
with:
pixi-version: v0.65.0
cache: true
activate-environment: true

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'm totally in favour of dropping poetry for pixi.

But I'm against having two competing lock files in the repository. Either one or the other.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I don't think I agree with this. The point of the pixi config here is to simply and easily provide LHAPDF for the regression in an isolated environment. It doesn't do anything more than that. And as you can see in the CI, poetry is still the one that orchestrates the build/installation.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

So, in this sense, there isn't a competing lock files at all. Of course we might say we want to fully switch to pixi but that'll involve a non-negligible amount of changes that should not be part of this PR.

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.

Then I would not commit the lockfile to the repo nor I would add a global pixi.toml file.

You can add a pixi subfield to the pyproject.toml if you want to use it for the tests.

- name: Install and configure Poetry
uses: snok/install-poetry@v1
with:
Expand Down
3 changes: 3 additions & 0 deletions .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -133,3 +133,6 @@ dmypy.json
# Benchmark files
benchmarks/data_files
benchmarks/fakepdfs
# pixi environments
.pixi/*
!.pixi/config.toml
303 changes: 303 additions & 0 deletions pixi.lock

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

13 changes: 13 additions & 0 deletions pixi.toml
Original file line number Diff line number Diff line change
@@ -0,0 +1,13 @@
[workspace]
authors = ["Tanjona R. Rabemananjara <tanjona.hepc@gmail.com>"]
channels = ["conda-forge"]
name = "pineko"
platforms = ["linux-64"]
version = "0.1.0"

[tasks]

[dependencies]
python = "3.13.*"
lhapdf = ">=6.5.6,<7"
pip = ">=26.1.2,<27"
17 changes: 16 additions & 1 deletion src/pineko/evolve.py
Original file line number Diff line number Diff line change
Expand Up @@ -27,6 +27,16 @@

logger = logging.getLogger(__name__)

# EKO marks any heavy quark flavor with index > nf as "intrinsic" (i.e. frozen,
# identity-evolved) at every scale. However, intrinsic bottom and top must never
# leak into the FK table, so their flavor-basis columns are masked whenever EKO
# would otherwise treat them as intrinsic (flavor index > nf). Charm is excluded
# here, since intrinsic charm is the supported feature.

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 think I disagree with this.
Leaking into the fktable is not a problem if they are hit with a PDF that is 0 at the fitting scale, like would be the case for the bottom.
If this is the way we want to fix it, it should be fixed at the level of yadism (so no bottom in the grid) rather than removing it here.

Either that or the removal should be informed by the theory card.

@Radonirinaunimi Radonirinaunimi Jun 22, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

In hindsight, I would tend to agree with that for the main reason that doing it in this way will make PineAPPL grids and EKOs (by themselves) completely useless without pineko.

_INTRINSIC_HEAVY_FLAVOR_IDX = {
5: tuple(basis_rotation.flavor_basis_pids.index(pid) for pid in (-5, 5)),
6: tuple(basis_rotation.flavor_basis_pids.index(pid) for pid in (-6, 6)),
}


def sv_scheme(tcard):
"""Infere the factorization scale_variation scheme to be used from the theory card.
Expand Down Expand Up @@ -479,14 +489,19 @@ def evolve_grid(

def prepare(operator, convolution_types):
"""Match the raw operator with its relevant metadata."""
for (q2, _), op in operator.items():
for (q2, nf), op in operator.items():
# reshape the x-grid output
op = manipulate.xgrid_reshape(
op,
operator.xgrid,
opcard.configs.interpolation_polynomial_degree,
targetgrid=XGrid(x_grid),
)
# mask out intrinsic bottom/top before they get mixed into the
# evolution basis by `to_evol`
for intr_fl, flavor_idx in _INTRINSIC_HEAVY_FLAVOR_IDX.items():
if intr_fl > nf:
op.operator[:, :, flavor_idx, :] = 0.0
# rotate the input to evolution basis
op = manipulate.to_evol(op, source=True)
check.check_grid_and_eko_compatible(grid, x_grid, q2, xif, max_as, max_al)
Expand Down
Loading