anderkve / gledeli

2 stars 0 forks source link

Implement further GSF models #28

Closed fzeiser closed 3 years ago

fzeiser commented 3 years ago

Currently "only" the GLO model is available for the GDR. From the runs I have performed, it seems impossible to match the Oslo data, Gg and D0, and the (g,n) data simultaneously with this. However, it is known that the EGLO for example better matches ARC data (which is similar to the Oslo data in this respect). It would be good to have more/other models available.

I will start with EGLO, which easily transforms to GLO with when two parameters are fixed. On the longer run, it would be good to have a more flexible structure of how the gsf models are called in gledeli. One could e.g. think of providing a dictionary at (the initialization?) with some content like this:

- res 1:
  - type: E1
  - form: EGLO
  - pars:
    - E = ..
    - width = ..
    - sigma = ..

- res 2:
  - type: E1
  - form: EGLO
  - pars:
    - E = ..
    - width = ..
    - sigma = ..

- res 2:
  - type: M1
  - form: GLO
  - pars:
    - E = ..
    - width = ..
    - sigma = ..

This should set up the gsf model.

The "only" reason to have this at initialization is that we might save a few calls to check which model we have every time we evaluate the likelihood.

fzeiser commented 3 years ago

For now, I will probably just implement a slightly more "hacky" variant.

fzeiser commented 3 years ago

@anderkve: (How) can I create a model with default parameters?

Say that I might like to have the following model, but by default set parameters 2-20 to 0.

https://github.com/anderkve/gambit_np/blob/5b33637e43c1075745cc2b7ad3bf20edd2ec09d5/Models/include/gambit/Models/models/GSFModels.hpp#L22-L25


I will also describe the overarching goal / idea. As stated above it would be nice to have a more flexible and better readable version of he input file. If I understand GAMBIT correctly, I should avoid having models with the same parameter name:

Although it is possible to scan two models containing a parameter with a common name, it is not possible to retrieve both parameters from the Param map in the same module function. By default, GAMBIT raises a runtime error if mod- els with common parameters are declared as allowed (by ALLOWED_MODELS or ALLOW_MODEL_DEPENDENCE ) in a sin- gle module function, and then activated together in a scan. More adventurous users may wish to deactivate this error and allow such parameter clashes in some very specific circum- stances (see Sect. 6.3.1).

So I guess the above pseudocode for a model description should rather have an identifier like the resonance number prepended, like this:

- res 1:
  - type: E1
  - form: EGLO
  - pars:
    - res1_E = ..
    - res1_width = ..
    - res1_sigma = ..

I currently consider two types of designs: Either the type (E1 or M1) and form (=model, so GLO, EGLO, ...) for e.g. the GSF should be settable in the yaml file via a parameter, or by the choice of the model name. So either just as above, or, something like

- E1_EGLO_res1:
  - pars:
    - E1_EGLO_res1_E = ..
    - E1_EGLO_res1_width = ..
    - E1_EGLO_res1_sigma = ..

Thinking about it, I guess the GAMBIT style would rather be to use the second option outlined here. If I used the first one, with a type and form variable, these should be saved/called only once, not saved as additional variable points each time (which I could achieve by having them as fixed parameters).

anderkve commented 3 years ago

@anderkve: (How) can I create a model with default parameters? Say that I might like to have the following model, but by default set parameters 2-20 to 0. https://github.com/anderkve/gambit_np/blob/5b33637e43c1075745cc2b7ad3bf20edd2ec09d5/Models/include/gambit/Models/models/GSFModels.hpp#L22-L25

A single GAMBIT model can't have default values (the idea is that all such parameter choices should be explicit in the yaml files), however there are two alternatives that achieve the same thing:

1) One yaml file can import the content of another with !import, so one way of setting some default values is to import a yaml file with those values. So you could do something like this in the yaml file:

GSFModel20:
  gsf_p1:
    prior: flat
    range: [0,10]

  !import path/to/other/yaml/file/GSFModel20_p2_p20_defaults.yaml

2) If you rather want a truly 1-parameter model, say GSModel1, but still want GAMBIT to interpret a point in this model as a point in the 20-dimensional GSFModel20 parameter space, you can use the GAMBIT model hierarchy. This means you can declare a restricted model as being derived from a more general model, with given translation functions that map one model to the other. So we can e.g. declare a model GSFModel1 to be a derived model from GSFModel20, with gsf_p2 = gsf_p3 = gsf_p4 = ... = gsf_p19 = gsf_T = 0. Then our yaml file can look like

GSFModel1:
  gsf_p1:
    prior: flat
    range: [0,10]

and the resulting sampled points be interpreted as 20-dim points (gsf_p1, gsf_p2, gsf_p3, ..., gsf_19, gsf_T) = (gsf_p1, 0, 0, ..., 0, 0)

I'm implementing an example of this now. Will push it shortly.

fzeiser commented 3 years ago

You don't need to implement an example, it's very straight forward. :+1:

anderkve commented 3 years ago

Ah, OK -- thanks! I did actually finish it, but forgot to test and push it. But now I won't bother, if you're already doing it. Let me know if there are any problems.

fzeiser commented 3 years ago

Ok, sorry for the late answer :)