RUB-EP1 / amplitude-serialization

Prototype for the amplitude model serialization format
https://rub-ep1.github.io/amplitude-serialization
MIT License
2 stars 1 forks source link

Serialize lineshape functions #22

Open redeboer opened 2 weeks ago

redeboer commented 2 weeks ago

The section functions defines the lineshapes that should be inserted into parametrization of the propagators. Example:

https://github.com/RUB-EP1/amplitude-serialization/blob/9fcd26e8c7cd487d93f902529c5513c977e03e62/Lc2ppiK.json#L42

https://github.com/RUB-EP1/amplitude-serialization/blob/9fcd26e8c7cd487d93f902529c5513c977e03e62/Lc2ppiK.json#L756-L776

Currently, the format specifications do not yet include an exact definition of the function tree, only a type description (here: BreitWigner). Some solution ideas:

In either case, we preferably serialize to a common mathematical markup language. Afaics, for JSON, there is only MathJSON, which is not widely adopted. OpenMath and MathML are more widely adopted (especially in web applications), but use XML, which is hard to read. But then again, lineshape expressions can be large and JSON won't be pretty either.

redeboer commented 2 weeks ago

Note: HS3 specifications probably won't help us here yet, because complex-valued functions are not supported.

mmikhasenko commented 1 week ago

I see great benefits in defining all functions fully in the format, there are cons as well. It would make it possible for different files to have different "BreitWigner"s, which is something I would not want.

I see that it might be challenging to convince the community to stick with a single definition of the BW. But it would be nice. For now, I would like to try that, i.e. treat all non-standard parametrization as exceptions

mmikhasenko commented 1 week ago

Btw, there is already a way to code simple functions in HS3. They are strings.

  "distributions": [
    {
      "expression": "1/((m*m-s)^2+(m*G)^2)",
      "name": "BreitWigner",
      "type": "generic_dist"
    }
  ],