Comments (6)
I think @scarlehoff you're happy with the current layout in pineappl_py
, right? Please reopen if you don't agree
from pineko.
Concerning the C factors and other factors applied by apfelcomb, I'd like to know what they are used for. I know of the following uses:
- NNLO QCD and/or NLO EW K factors and
- to convert between different units: some grids are given femtobarn, or are in picobarn, therefore one had to add a factor 1000 somewhere
Are there more? @scarlehoff @scarrazza
The use of 1) should IMO be implemented in PineAPPL, see NNPDF/pineappl#7, because I don't like related data in different places. Different units as in 2) are already taken care of by metadata in PineAPPL, where y_unit
is either fb
or pb
(or pb/GeV
, ...).
from pineko.
@scarlehoff I've had a quick look at the FK tables and saw that they're text files where the numbers are written with the full double precision. PineAPPL grids instead are binary files, and I've made sure that zeros are not stored at all. Overall that makes me quite optimistic about the total size of all PineAPPL FKtables.
from pineko.
Input
I will ask for the fktable by giving the following information:
theoryid: 200 dataset_inputs: - {dataset: ATLAS_WZ_TOT_13TEV, cfac: [NRM, QCD]}
Ok fine, so there will be a dataset database somewhere and ATLAS_WZ_TOT_13TEV
works like an id
for it. Then also the pineapplgrids relative to yadism
will be generated ahead of time (even if they will be quite fast you could generate on the fly).
* `ndata`: number of experimental data points * `nx`: number of points in the x-grid * `nbasis`: number of non-zero channels * `hadronic`: boolean flag telling me whether the process is hadronic or not
3 out of 4 can be computed from the previous data (essentially calling len(ciao)
or len(ciao.shape()) == 3)
, nevertheless if it's convenient for you it costs us nothing to provide them as @property
.
Note that I don't put any constraints in the type of the different objects. To actually operate with them I will make them into tensorflow tensors so numpy arrays is the more natural choice but I can work with anything.
The only other option it's to provide some raw rust
structure (i.e. ndarray
== numrust), but then I would say that the only reasonable option it's numpy arrays.
Wishlist
I'm not entirely sure you can compress the current
.dat
files much more than they currently are (I don't know how much effort was put into compressing them back in the day) but it would make me much happier if instead of downloading 3 GB to do a fit I could download just 1.
We are using pineapplgrids as output format, and to my understanding @cschwan put already a lot of effort in compressing them, so if there was room for further compression they will be compressed, but we'll keep an eye.
from pineko.
3 out of 4 can be computed from the previous data (essentially calling
len(ciao)
orlen(ciao.shape()) == 3)
, nevertheless if it's convenient for you it costs us nothing to provide them as@property
.
All of them. If the basis is rank-2 then it is hadronic. This just makes my life easier. Mainly I won't have to remember whether the first dimension of the fktable is the ndata
or the nx
.
Are there more?
I don't know right now, but there might be "special" studies for which other cfactors-like objects are used @scarrazza ?
from pineko.
All of them. If the basis is rank-2 then it is hadronic. This just makes my life easier. Mainly I won't have to remember whether the first dimension of the fktable is the
ndata
or thenx
.
I was wondering just about the nbasis
since you said nonzero elements, but then I realized it was one of the dimensions of the array. Then yes: all will be provided as @property
.
from pineko.
Related Issues (20)
- Fix new `DAMP` convention HOT 1
- Generated renormalization SV does not work at N3LO (and beyond) HOT 14
- `mu0` scale is not updated correctly in the operator cards. HOT 4
- Load absolute paths from pineko.toml in nFONLL
- Drop `yamldb` as default HOT 5
- evolution of fragmentation function grids HOT 2
- `kfactor` module maintenance HOT 4
- Issue in the generation of the metadata of the fktables HOT 10
- Allow to run explicitly a grid / fktable HOT 2
- Save eko operator card and theory card in the fktable
- Cache of operators HOT 15
- Use `theories_slim` for the benchmark
- Raise an error when the number of iterations > 1 for truncated
- Don't generate intermediate theory cards for nfonll HOT 4
- Generalize evolve to accommodate two EKOs
- Rotate FK-tables instead of EKOs HOT 12
- Detect NaNs in FK tables HOT 27
- Don't print in library
- Weekly regression test and dependency check
- `kfactors` maintanence continued
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pineko.