Mu2 struct and grids

[alecandido]

What is the meaning of the Mu2 struct and mu2_grids if they are consistently set to q2:

pineappl/pineappl/src/import_only_subgrid.rs

Lines 62 to 68 in 1955056

	fn mu2_grid(&self) -> Cow<[Mu2]> {
	self.q2_grid
	.iter()
	.copied()
	.map(|q2| Mu2 { ren: q2, fac: q2 })
	.collect()
	}

pineappl/pineappl/src/lagrange_subgrid.rs

Lines 862 to 869 in 1955056

	fn mu2_grid(&self) -> Cow<[Mu2]> {
	(0..self.ntau)
	.map(|itau| {
	let q2 = fq2(self.gettau(itau));
	Mu2 { ren: q2, fac: q2 }
	})
	.collect()
	}

pineappl/pineappl/src/lagrange_subgrid.rs

Lines 582 to 589 in 1955056

	fn mu2_grid(&self) -> Cow<[Mu2]> {
	(0..self.ntau)
	.map(|itau| {
	let q2 = fq2(self.gettau(itau));
	Mu2 { ren: q2, fac: q2 }
	})
	.collect()
	}

pineappl/pineappl/src/lagrange_subgrid.rs

Lines 228 to 235 in 1955056

	fn mu2_grid(&self) -> Cow<[Mu2]> {
	(0..self.ntau)
	.map(|itau| {
	let q2 = fq2(self.gettau(itau));
	Mu2 { ren: q2, fac: q2 }
	})
	.collect()
	}

and it is also assumed that they are doing so:

pineappl/pineappl/src/lumi.rs

Lines 339 to 347 in 1955056

	Some(subgrid.mu2_grid().into_owned())
	}
	})
	.flatten()
	.flat_map(|Mu2 { ren, .. }| {
	xi.iter()
	.map(|(xir, _)| xir * xir * ren)
	.collect::<Vec<_>>()
	})

pineappl/pineappl/src/lumi.rs

Lines 359 to 365 in 1955056

	Some(subgrid.mu2_grid().into_owned())
	}
	})
	.flatten()
	.flat_map(|Mu2 { fac, .. }| {
	xi.iter()
	.map(|(_, xif)| xif * xif * fac)

(because ren is an object supposed to be multiplied by xir * xir and fac by xif * xif).

[alecandido]

@cschwan I don't want to be overly critic, but the code above seems to be also a bit redundant (e.g. the code generating muf2_grid and mur2_grid is pretty much the same).

I would try, sooner or later, to refactor to avoid repetitions, splitting repeated code in stand-alone functions (of course with minimal "publicity", i.e. as minimal as possible).

[cschwan]

@alecandido This was needed to support fastNLO flexible-scale grids, see here: #25 (comment). Only in this instance we support renormalization and factorization having different functional forms. We might want to consider adding support for this also for filling grids in the future.

[alecandido]

Ok, then you store only the different function, but scaled as if it were the central scale, and you finally rescale with xif and xir provided at convolution time.

I understand the last point is required, because you don't know xif and xir values ahead of time (i.e. you want to work for any value, that's why you store the central scale), but then I have a request and a proposal.

The request is: I consider ren and fac a bit misleading, since it is not intuitive to me that to obtain, e.g., ren scale I have to multiply ren by xir * xir, so I would use more explicit names, that reminds somehow that is a different "central value"-like, and update accordingly the comments:

pineappl/pineappl/src/subgrid.rs

Lines 34 to 41 in 1955056

	/// Structure denoting renormalization and factorization scale values.
	#[derive(Debug, Deserialize, Clone, PartialEq, PartialOrd, Serialize)]
	pub struct Mu2 {
	/// The (squared) renormalization scale value.
	pub ren: f64,
	/// The (squared) factorization scale value.
	pub fac: f64,
	}

At the moment I would infer that ren is mur...

Coming to the proposal, I would suggest to change Mu2 attributes, from f64 to Option<f64>, in such a way that it is clear that both ren and fac individually do not have to be different from the central scale.
The other option is storing central and ratios:

/// Support for different functional shapes for renormalization and factorization scales.
/// Only the "pretending" central values are stored, while actual values are recovered when user specified `xir` and `xif` are available
 pub struct Mu2 { 
     /// The (squared) process scale value. 
     pub mu2: f64,
     /// The ratio of central value to "central" renormalization scale value (not accounting for `xir` value). 
     pub xic_ren: Option<f64>, 
     /// The ratio of central value to "central" factorization scale value (not accounting for `xif` value)
     pub xic_fac: Option<f64>, 
 } 

But also in this case I would use Options, to explicitly pass the information that no difference from central scale is present. Sugar can be provided with accessors (e.g. cren and cfac, or more telling names) always returning an f64, possibly the central scale, instead of an Option.

[cschwan]

The values ren and fac usually aren't different, but in general they can be. To test that you can use comparison operators, but internally it doesn't matter to PineAPPL.

If I choose

• $\mu_\text{R}^2 = Q^2 + p_\text{T}^2$ and
• $\mu_\text{F}^2 = Q^2$

what would you choose for mu2? There's no good choice here.

[alecandido]

Ok, now I see your point and I agree. It seemed to me that a q2 value still existed, but I overlooked the code (I'm just too used to fully inclusive DIS).

Then, I drop the proposal, no more optional values, it is unpractical.
But I'm still convinced to improve names and comments. cren for "central ren" (or something similar) with possibly a ren accessor:

 pub struct Mu2 { 
     cren: f64, 
     cfac: f64, 
 } 

impl Mu2 {
    pub fn ren(&self, xir: Option<f64>) {
        if let Some(xir) = xir {
            return self.cren * xir * xir
        }
        self.cren
    }
}

Also here Option is just a proposal, f64 and passing 1. is also perfectly fine. But I like to be able to distinguish an explicit 1. from a non-specified object, even though here is actually useless...
(the best would be a default argument/no-argument overloading, but in Rust is not yet allowed)

[cschwan]

The documentation can be improved, that's absolutely true.

Note that the ren method will not be useful everywhere, because the log contributions only depend on the scale-variation factors xir/xif, not on the actual scales. I like to keep them separate because they're a different thing: there's the central renormalization/factorization scales, and then there are variations around that choice. They're also kept in different locations: the central scales are a process-specific choice, whereas the scale variations depend on the user. They might not need it, or they wish a 3-, 7-, 9- or whatever point variation.

[alecandido]

Point is that you need both of them to evaluate $\alpha_s(\mu_R)$ and $f(z, \mu_F)$. So, essentially, all users need all of them (both central scales and ratios), even though not in every place, and ratios might be trivial.

However, I did not propose to put xir in the central scale, but passing it as a value to the accessor. If you only need the central value, you can pass None (that was the meaning of Option<f64>).

[alecandido]

The difference between:

• mu2.cren and
• mu2.ren(None)

is that in the second case you can't forget that you might need to account for xir. Deciding not to use any ratio is a more explicit choice.