Updates for v0.2 #8

swertz · 2016-11-30T14:28:27Z

I've taken some time to update the website for the coming second release.

This is not final since there might be still some changes, but don't hesitate if you already have some comments.

I've added @BrieucF to our team since he's contributed to the blocks!

blinkseb

That's really awesome thanks a million for that! I just noticed two small typos 👍

blinkseb · 2016-11-30T17:14:38Z

docs/in-depth/calling-momemta.md

+momemta::Particle part2 { "part2", p2, 0 };
+std::vector<std::pair<double, double>> weights = weight.computeWeights({part1, part2}, met);
 ```
+> *The `momemta::Particle` type consists of tree parts: a name (string) allowing to identify the particle in the configuration file, a 4-vector object, and a type (int). The type is not used by MoMEMta but can help the user configure the computation. It could be a PDG ID code, or any other code defined by the user.*


three instead of tree

blinkseb · 2016-11-30T17:18:22Z

docs/in-depth/configuration-file.md

+BreitWignerGenerator.m_prop = {
+  ps_point = add_dimension(),
+  mass = parameter('my_mass'), -- Access the value through the "parameter" function, allowing it to be modified from the C++ code
+  width = parameter.my_width -- Access the value as a regular Lua table. It will NOT be possible to modify it later on


parameters

swertz · 2017-05-04T15:28:14Z

I've added a few things. Two obvious things are missing:

the release notes
the validation page with all the blocks's results

I think we have the minimum required for the next release? Unless I've missed something obvious.
And then if we want to add more information we can do so later.

blinkseb · 2017-05-04T15:56:13Z

Many thanks! I'll try to read the documentation tomorrow see if I have some feedback!

swertz · 2017-05-04T15:57:49Z

Ok, I can do a serve from ingrid if that's easier for you!

blinkseb

Thanks a lot!! Those additions are really awesome! I have a few comments nonetheless 😄

blinkseb · 2017-05-06T09:51:16Z

docs/in-depth/calling-momemta.md

 In MoMEMta, the integration is defined by linking modules together in a Lua script. MoMEMta is shipped with a set of modules covering the most common needs and whose parameters, inputs and outputs are documented [here](https://momemta.github.io/MoMEMta/dev/group__modules.html). For more information on how to write the configuration file, see [here](configuration-file.md).

-> *A module is just a C++ class deriving from the `Module` virtual class. How to write a new module and make it available for the calculation is described (here).*
+> *A module is just a C++ class deriving from the `Module` virtual class.*


Can probably be a !!! note instead of a quote

blinkseb · 2017-05-06T09:52:37Z

docs/in-depth/calling-momemta.md

-At this point, the user might wish to modify some parameters defined in the file from the code itself:
+At this point, the user might wish to modify some parameters defined in the file from the code itself (see also [here](parameters)):
 ```cpp
 configuration.getGlobalParameters().set("top_mass", 173.);


configuration is not defined here, it should be my_reader

blinkseb · 2017-05-06T09:53:21Z

docs/in-depth/calling-momemta.md

 ```

-> *MoMEMta is instantiated using a `Configuration` object, describing a fixed configuration: parameters cannot be modified at this stage. Parameters can be changed in the ConfigurationReader, and a new `MoMEMta` instance must then be constructed by calling `ConfigurationReader::freeze()` again.*
+> *MoMEMta is instantiated using a `Configuration` object, describing a frozen configuration: parameters cannot be modified at this stage, the execution flow of the computation is fully fixed. Parameters can however be changed in the ConfigurationReader, and a new `MoMEMta` instance must then be constructed by calling `ConfigurationReader::freeze()` again.*


Maybe here also a !!! note is better than a quote?

blinkseb · 2017-05-06T09:56:09Z

docs/in-depth/calling-momemta.md


-!!! note ""
-    The LorentzVectors are expected to be expressed in the `PxPyPzE<double>` basis
+> *The `momemta::Particle` type consists of three parts: a name (string) allowing to identify the particle in the configuration file, a 4-vector object, and a type (int). The type is not used by MoMEMta but can help the user configure the computation. It could be a PDG ID code, or any other code defined by the user.*


The type part can be a bit misleading. There's currently no way to use it, even in the configuration file. It'll be in the future tho. And maybe it can be a !!! note too 😬

blinkseb · 2017-05-06T09:56:59Z

docs/in-depth/calling-momemta.md

+    MoMEMta provides the useful typedef `LorentzVector` for Lorentz Vectors in the file `momemta/Types.h`

-`computeWeights()` returns a vector of pairs (weight, uncertainty) (at the moment, this vector only has one entry) which can then be stored by the user.
+!!! note


A !!! warning may be more suitable in this situation.

blinkseb · 2017-05-06T10:10:12Z

docs/in-depth/configuration-file.md

+```Lua
+P4Printer.printer1 = { input = "tf_part1::output" }
+P4Printer.printer2 = { input = l_part1.gen_p4 }
+```


This part is really nice, thanks, but think we should do things the way around: you first define inputs in the configuration file, and then pass them to the computeWeights function. It's mandatory to defines inputs, you cannot longer directly use hardcoded input tags. I'd also explicitly write that you access the reco input tag using the reco_p4 variable: currently, it's only written in the lua snippet, not in the text.

Maybe it's worth specify also that gen_p4 points by default to the same value that reco_p4: that's helpful if you don't need / want transfer function on the input, so that reco and gen quantities are the same thing.

blinkseb · 2017-05-06T10:11:22Z

docs/in-depth/configuration-file.md

+Finally, the missing transverse energy 4-vector (passed optionally to `computeWeights()`) can either be accessed directly through the `met::p4` input tag, or declared as a Lua object as above:
+```Lua
+local met = declare_input("met")
+```


I did not test, but I'm prettry sure this won't work. The met input is always declared, you don't need to do anything to access it.

blinkseb · 2017-05-06T10:16:00Z

docs/in-depth/parameters.md

+BreitWignerGenerator.m_prop = {
+  ps_point = add_dimension(),
+  mass = parameter('my_mass'), -- Access the value through the "parameter" function, allowing it to be modified from the C++ code
+  width = parameters.my_width -- Access the value as a regular Lua table. It will NOT be possible to modify it later on


It can be worth IMO to add a !!! danger block below insisting on this fact: you have to pass through the parameter function if you want the parameter to be editable

blinkseb · 2017-05-06T10:17:15Z

docs/in-depth/parameters.md

+}
+```
+Four different integration algorithms are available, and each has several parameters than can be tweaked to adjust their behaviour, tweak the precision of the calculations, ...
+The integration parameters can be changed from the C++ in a manner similar to the "global" parameters (previous section), using the method `ConfigurationReader::getCubaConfiguration()`.


Please link to in-depth/parameters/#defining-parameters

blinkseb · 2017-05-06T10:18:34Z

docs/in-depth/parameters.md

+| `seed` | integers | `0` |
+| `min_eval` | integers | `0` |
+| `max_eval` | integers | `500000` |
+| `grid_file` | paths | `` |


IMO either put nothing as default value or something like <empty>

swertz · 2017-05-08T09:36:37Z

Many thanks for the comments, I've updated the PR!

blinkseb · 2017-05-08T09:43:25Z

docs/in-depth/configuration-file.md

+
+In C++, that input's 4-vector can then be passed through the `computeWeights()` function (see [Calling MoMEMta](calling-momemta)) by defining a `momemta::Particle` object whose name attribute is the same as the one used in the configuration, e.g. `momemta::Particle m_part1 { "part1", p1, 0 }`.
+
+The Lua object `l_part1` contains the input tag needed to access the particle's 4-vector. For instance, defining a transfer function on the energy of `part1` can be done as:


maybe adding something like via the ``reco_p4`` attribute at the end of the first sentence?

blinkseb · 2017-05-08T09:48:16Z

Thanks a lot it's awesome!

swertz · 2017-05-10T13:13:22Z

Updated again, addressing your last comment.

I've also added a new page to document the phase-space parametrisations. It's still very much WIP, and could be skipped if we want to release earlier.

blinkseb · 2017-05-15T09:06:29Z

Since the new page added by @swertz is not complete yet, I'd propose to remove it from this PR and PR it later on when it's done, so we can merge this. Any objections?

blinkseb · 2017-05-15T14:46:59Z

I removed the page and opened #12 instead. This is ready to be merged, thanks a lot!

swertz added the do NOT merge label Nov 30, 2016

blinkseb requested changes Nov 30, 2016

View reviewed changes

blinkseb force-pushed the updatesForV0.2 branch from d474066 to 780aefc Compare March 30, 2017 09:33

blinkseb approved these changes Mar 30, 2017

View reviewed changes

Sebastien Wertz added 2 commits May 2, 2017 10:23

Updated block validation

2a674f6

First round of updates

96cfa72

swertz force-pushed the updatesForV0.2 branch from 780aefc to 3c5888f Compare May 4, 2017 09:38

Add Cuba parameters; python bindings

d2474fd

swertz force-pushed the updatesForV0.2 branch from 3c5888f to d2474fd Compare May 4, 2017 15:26

blinkseb requested changes May 6, 2017

View reviewed changes

Address comments

20a926b

blinkseb reviewed May 8, 2017

View reviewed changes

blinkseb approved these changes May 8, 2017

View reviewed changes

Further comments

e98a45e

blinkseb force-pushed the updatesForV0.2 branch from 8e62f2e to e98a45e Compare May 15, 2017 14:44

blinkseb mentioned this pull request May 15, 2017

Phase space parametrisation doc #12

Open

blinkseb removed the do NOT merge label May 15, 2017

blinkseb merged commit 2f14d8f into website Jun 20, 2017

blinkseb deleted the updatesForV0.2 branch June 20, 2017 12:09


		In C++, that input's 4-vector can then be passed through the `computeWeights()` function (see [Calling MoMEMta](calling-momemta)) by defining a `momemta::Particle` object whose name attribute is the same as the one used in the configuration, e.g. `momemta::Particle m_part1 { "part1", p1, 0 }`.

		The Lua object `l_part1` contains the input tag needed to access the particle's 4-vector. For instance, defining a transfer function on the energy of `part1` can be done as:

Updates for v0.2 #8

Updates for v0.2 #8

Uh oh!

Conversation

swertz commented Nov 30, 2016

Uh oh!

blinkseb left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

swertz commented May 4, 2017

Uh oh!

blinkseb commented May 4, 2017

Uh oh!

swertz commented May 4, 2017

Uh oh!

blinkseb left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

swertz commented May 8, 2017

Uh oh!

blinkseb May 8, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

blinkseb commented May 8, 2017

Uh oh!

swertz commented May 10, 2017

Uh oh!

blinkseb commented May 15, 2017

Uh oh!

blinkseb commented May 15, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

blinkseb left a comment •

edited

Loading

blinkseb May 8, 2017 •

edited

Loading