WHIZARD 2: idiosyncracies when using two different models in the same input file

[Juergen Reuter]

When using processes from two (or maybe more) different models in the same input file (but even when running only processes of one of them), the following error message is issued: Warning: Masses of beam particle(s) differ from beam masses | Integrating process 'wzdu_ckm' * Error: Process 'wzdu_ckm': no valid phase-space channels found * Error: Process 'wzdu_ckm': phase space setup failed, skipped | Integrating process 'wzsc_ckm' * Error: Process 'wzsc_ckm': no valid phase-space channels found * Error: Process 'wzsc_ckm': phase space setup failed, skipped | Integrating process 'wzbt11_ckm' etc. Question is whether this setup is not possible in general, I would consider it at least desirable.

[Juergen Reuter]

It looks like that the second invocation of a (different) model resets somehow the input parameters. Looking at the difference in the output of the files when running only MSSM vs. MSSM and MSSM_CKM in the same file: 151,152c152,153 < al_h -> -0.11373192400000000 < mu_h -> 358.35532699999999 ---

al_h -> 0.0000000000000000 mu_h -> 1000.0000000000000

155c156 < | Integrating process 'wzdu' ---

| Integrating process 'wzdu_ckm'

163c164 < Model: MSSM ---

Model: MSSM_CKM

168c169 < n_groves = 2 ---

n_groves = 0

[Juergen Reuter]

I tested this with SM and SM_CKM. Looking for the error message from the cascade_set inside processes.f90 shows that phase space is tried to be constructed for the second model (SM_CKM in that case). Question is why the second process does not work which was generated for that model.

[kilian]

The errors are misleading; probably the input file was lacking 'model=...' commands before the integration commands that accessed the various processes.

With changeset [1236], the program issues a warning if the global model does not match the process setup, and the model is temporarily reset for this process. This should not just be done silently, since any parameter value that was modified for the global model is ignored in this case.

JR: Please check this with your sample input files.

[Juergen Reuter]

OK, this is now working. What should remember to read in input files if one changes the model e.g. from MSSM to MSSM_CKM one needs to read in again the SLHA input file. Otherwise the parameters are not taken over. I'm closing the ticket and will update the test files.

[Juergen Reuter]

OK, the MSSM files are NOT working, something with the SLHA accord probably!? When one runs processes from MSSM and from MSSM_CKM somehow the results of the MSSM processes are becoming incorrect.

[Juergen Reuter]

Where this seems to be working is with the following input file: model = SM process sm_sm = Wp -> u, dbar model = SM_CKM process sm_ckm_sm_ckm = Wp -> u, dbar compile !--------------------------------------------- me = 0 mH = 115 GeV integrate (sm_sm, sm_ckm_sm_ckm) {

iterations (5, 10000)

} which gives these combine results: me -> 0.0000000000000000 mH -> 115.00000000000000 sqrts = 200.00000000000000 | Integrating process 'sm_sm' Warning: Process 'sm_sm': temporarily resetting model from 'SM_CKM' to 'SM' |=============================================================================| | It Calls Integral[GeV] Error[GeV] Err[%] Acc Eff[%] Chi2 N[It] | |=============================================================================|

1 10000 6.8269218E-01 4.43E-10 0.00 0.00* 100.00 2 10000 6.8269218E-01 4.41E-10 0.00 0.00* 100.00 3 10000 6.8269218E-01 4.40E-10 0.00 0.00* 100.00 4 10000 6.8269218E-01 4.42E-10 0.00 0.00 100.00 5 10000 6.8269218E-01 4.41E-10 0.00 0.00* 100.00

|=============================================================================|

5 50000 6.8269218E-01 1.97E-10 0.00 0.00 100.00 0.00 5

|=============================================================================| | Integrating process 'sm_ckm_sm_ckm' |=============================================================================| | It Calls Integral[GeV] Error[GeV] Err[%] Acc Eff[%] Chi2 N[It] | |=============================================================================|

1 10000 6.4742762E-01 1.00-146 0.00 0.00* 100.00 2 10000 6.4742762E-01 1.00-146 0.00 0.00 100.00 3 10000 6.4742762E-01 1.00-146 0.00 0.00* 100.00 4 10000 6.4742762E-01 9.35E-12 0.00 0.00 100.00 5 10000 6.4742762E-01 1.00-146 0.00 0.00* 100.00

|=============================================================================|

5 50000 6.4742762E-01 5.01-147 0.00 0.00 100.00 * 5

|=============================================================================| |========================= Results Summary =========================|

sm_sm: 6.82692178E-01 +- 1.97E-10 GeV

sm_ckm_sm_ckm: 6.47427624E-01 +- 5.01-147 GeV

|=============================================================================|

in agreement with the results if you run them singly. Where it seems to fail is for scattering processes, e.g. for c cbar -> W+,W-

model = SM process sm_sm = c, C -> Wp, Wm model = SM_CKM process sm_ckm_sm_ckm = c, C -> Wp, Wm compile !--------------------------------------------- me = 0 mH = 115 GeV sqrts = 200 GeV integrate (sm_sm, sm_ckm_sm_ckm) {

iterations (5, 10000)

|========================= Results Summary =========================|

sm_sm: 1.03905448E+04 +- 2.19E+00 fb

sm_ckm_sm_ckm: 6.41050278E+03 +- 1.94E+00 fb

|=============================================================================|

When I run the things separately, I get

sm_foo: 6.40981489E+03 +- 1.96E+00 fb

and

sm_ckm_foo: 6.40984068E+03 +- 1.96E+00 fb

Astonishingly, the two results are the same. I don't understand what the hell is going on.

[Juergen Reuter]

For sure, when using e.g. an MSSM and an MSSM_CKM model file one needs to invoke the SLHA input file in both cases. Otherwise WHIZARD fails for the process of the second process with the error message: no phase space channels found.

[Juergen Reuter]

JR: it seems that if one repeats the changes in the setting of the model prarameters for each model, then one gets the desired results (please cross-check!). We have to think whether we want to include an option to set parameters for all models. Besides this I already included a comment in the manual.

[kilian]

OK, this is actually not a bug, but the nonexistence of a proper documentation.

Explicit parameter settings always apply to the currently active model. If the model is temporarily changed for integration, the parameter set for that model is used, which may be unmodified.

However, this raises an important issue about the implementation of model parameter lists. This has to be improved for various reasons, so I leave the ticket open.

[kilian]

Changeset [1289] essentially resolves the problem.

Under the hood, variable lists are now dynamically reassigned when the command list is executed, not at compile time as it was before. Name clashes between parameters and particles are now avoided. (They were actually happening in the MSSM and some other model, but got unnoticed so far.)

The user will see the current model in the command-line echo whenever he changes a parameter.

Possible enhancements would be: set/access parameters outside the current model directly, syntax could be MSSM.A0 = .... Or set a parameter in all loaded models. These are not implemented yet; therefore I leave the ticket open for now, but reduce the priority.

[kilian]

The current implementation (improved again in [1301]) should be sufficient for the 2.0 release, if properly documented. More convenience functions may be added in future versions. Therefore, I postpone this to 2.1.

[Juergen Reuter]

This is a Methusalem ticket, try to push it a little earlier now.

[Juergen Reuter]

There is a strange thing if you look into the log file of the model selftests, i.e. models_ccww_MODEL.log etc. There the array of colored and charged particles is only the one from the SM, maybe that is by design, but I do not understand it fully.

[Juergen Reuter]

Once, the SINDARIN extensions discussed today are implemented, this problem is solved and we can close this ticket. The comment from 24/03/11 is unrelated to this.

[Juergen Reuter]

One famous example is the selftest qedtest_1.sin (and the others probably as well): when not running with the --no-model option (i.e. with preloading model SM) the value ee (the electric coupling constant) is not user-definable in the model QED switched on by the command model = "QED" because in the GF-MZ-MW scheme in the EW SM it is a derived quantity. WK had the idea of name spaces ... we have to think about that...

[Juergen Reuter]

Duplicate to #508.