Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change representation of the luminosity function #165

Closed
cschwan opened this issue Aug 18, 2022 · 5 comments
Closed

Change representation of the luminosity function #165

cschwan opened this issue Aug 18, 2022 · 5 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@cschwan
Copy link
Contributor

cschwan commented Aug 18, 2022

The current representation of the luminosity function, which is essentially the type LumiEntry, makes it very hard to convolute a grid for a single tuple of partons only, see also #150. We should:

  • add a new method Grid::lumis that returns simply a Vec/slice of tuples (a, b, factor, index) with a and b being the two partons and index being the same each tuple from the same LumiEntry the Grid was constructed with. The method Grid::lumi should be removed
  • change the Grid::convolute function to accept a slice of boolean that correspond now to the slice returned by Grid::lumis instead of the shorter vector of LumiEntry objects the Grid was constructed with. This will allow more fine-grained control over convolutions.
@cschwan cschwan added the enhancement New feature or request label Aug 18, 2022
@cschwan cschwan added this to the v0.6.0 milestone Aug 18, 2022
@cschwan cschwan self-assigned this Aug 18, 2022
@alecandido
Copy link
Member

This would be nice, such that we'll be able to do:

grid.convolute(
    ..., 
    grid.lumis().iter().map(|(a, b, _, _)| myfilter(a, b)).collect(), 
    ...
)

@cschwan
Copy link
Contributor Author

cschwan commented Aug 27, 2022

Exactly, that's the idea, it should become much simpler.

@cschwan
Copy link
Contributor Author

cschwan commented Jan 24, 2023

I'm no longer sure this is a good idea, and I'm closing this in favour of #149, which should allow implementing an operation that 'splits' each channel of a luminosity function that the new channels contain FK table-like entries, in the sense that we have a single tuple (a, b, f) with a and b initial-state partons and f and arbitrary factor. This allows `pineappl channels to show the size of each flavour-combination.

@cschwan cschwan closed this as completed Jan 24, 2023
@alecandido
Copy link
Member

an operation that 'splits' each channel of a luminosity function that the new channels contain FK table-like entries

At result level or at grid level? Because I would not recommend the second, I definitely want to avoid copying subgrids.

Now I really appreciate that the concept of LumiEntry is not the same as a parton tuple, because actual "channels" (mapping to diagrams and expressions) are much less than tuples.
In principle, it would be nice to apply also in DIS, but quark masses treatment (including intrinsic flavors) complicate enough the situation - you might end up with a similar number of channels (and DIS grids are small anyhow, making it less appealing).

@cschwan
Copy link
Contributor Author

cschwan commented Jan 24, 2023

See #149 (comment). That copies subgrids, which is unavoidable for duplication of them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants