WHIZARD

Event generation not proceeding for CEPC 91.2GeV

Asked by Saumyen Kundu

Hi Experts,

I was trying to simulate the radiative Bhabha scattering and generate some events for the CEPC 91.2 GeV mode. However even if the integration is completing successfully, no events are getting generated. I believe that is because of the convergence problem. However, I tried with stricter generation-level cuts to tackle this, but no help. Earlier I generated events for the 160 and 240 GeV with far more relaxed cuts and they were generated successfully but not in this case.

Could any of you guide me on what is wrong I am doing here? The SINDARIN scripts with strong and weak cut and the log file (for strong cut) can be found at the following link:
https://www.dropbox.com/sh/ue9tcnhmpkcda22/AACwebpsWkFzkvra0T9aSCAOa?dl=0

Will really appreciate any help with this.

Thanks and regards,
Saumyen

Question information

Language:
English Edit question
Status:
Solved
For:
WHIZARD Edit question
Assignee:
Krzysztof Mekala Edit question
Solved by:
Krzysztof Mekala
Solved:
Last query:
Last reply:
Revision history for this message
Krzysztof Mekala (krzysztofmekala) said : 		#1

Dear Saumyen,
your files seem to work on my machine. I was able to generate 300k events in about 7 minutes. You can try to use another seed and run Whizard in a new folder.
Indeed, the integration does not look sufficiently converging and I would suggest the same solution as to your previous question (https://answers.launchpad.net/whizard/+question/703873). It is advised to separate 1-, 2- and 3-photon runs and to use higher numerical precision for the 3-photon sample. In this particular case when you consider the Z-pole run, the ISR is strongly suppressed but the emission is still possible from the final state. However, the energy is quite low as for the 5 particles you expect in the final state and they become soft naturally which may lead to some numerical instabilities. Switching to higher precision should help to solve the problem.

Regards,
Krzysztof

Revision history for this message
Saumyen Kundu (saumyen.k) said (last edit ): 		#2

Dear Krzysztof,
Thank you so much for your comments.

I tried it on my machine in two folders and repeated runs (automatically changing the seed) for the past 3-4 days with light to tight cuts. But with the same result. I will try it on another machine.

In the meantime let me understand the separate run thing. So, suppose I am getting cross-sections for 1-, 2- and 3-photon runs as 5 fb, 3 fb, and 2 fb and I want to generate a total of 10K events. So for that, I need to generate 5 K 1-photon, 3 K 2-photon, and 2 K 3-photon events, right? And how do I combine the 3-type of events; I mean it should be fine, right, if I combine them at the detector simulation level. I have put a new SINDARIN script in the above folder, could you comment if I have done it correctly?

And regarding the enhanced precision for the 3-photon run, I tried that it generated fine. But the run with the 1- and 2-photons together got stuck. Then, I separated the three of them. And what I saw is the 1-photon run is the one getting stuck. So I enhanced its precision too. But I saw that it is still getting stuck or very slow. I have kept a new script and a new log-file.

Another point: I gave both 'relative_error_goal' and 'accuracy_goal' but it is considering only the 'relative_error_goal'. Also, how to implement the 'quadruple precision'?

Will wait for your comments.

Thanks and regards,
Saumyen

Additional info: It was not proceeding so I cancelled and re-ran. Then it shows 380 events generated and got stuck. Then again I cancelled and re-run and it says 443 events already generated and starts generating the rest. But again it got stuck after generating 27 more events.

Revision history for this message
Best Krzysztof Mekala (krzysztofmekala) said : 		#3

Dear Saumyen,
yes, in principle your new SINADRIN looks fine but personally, I would just split it into 3 files, one for each photon multiplicity, and run Whizard 3 times; in such a case, you can easily adjust internal Whizard settings (e.g. the number of integration steps) for each particular case. Then, as you said, it is enough to combine your samples at the detector-simulation level. A useful feature of Whizard is that instead of setting the number of events to be generated, you can specify the luminosity (luminosity = ...) and Whizard will generate the corresponding numbers of events.

By running Whizard separately for each photon multiplicity, you can also change the precision you want to use. As you require very high precision of the integration for the 1-photon sample, the run with extended precision might be very slow. Then, I would recommend starting the 1- and 2-photon runs with standard precision and only the 3-photon one with extended precision. The precision of your Whizard installation is determined at the building stage (./configure –with-precision=...). In other words, to obtain quadruple precision, you have to install Whizard once again and then use this particular version for your 3-photon run. As using higher precision is always more time-consuming, people tend to use it only for some particular cases when it might be useful for integration, like in this case.

Regarding 'relative_error_goal' and 'accuracy_goal', I would use the first one, since this one is interesting from the experimental perspective.

Furthermore, if your integration/event generation gets stuck and you decide to change some settings, it is advised to run Whizard again in a new folder to make sure no previous files will be used. You can also change the seed (seed = ...) by hand to make sure it is an independent run.

Regards,
Krzysztof

Revision history for this message
Saumyen Kundu (saumyen.k) said (last edit ): 		#4

Dear Krzysztof,
Thank you so much for your comments.

So following your suggestion I ran the 3 multiplicities in 3 different folders. Before that, I uninstalled and reinstalled Whizard with the latest version with 'extended' precision and openMP. After that, it ran well. All the events were generated successfully as per
the given luminosity value.

Thank you so much for all the help.

Thanks and regards,
Saumyen

Revision history for this message
Saumyen Kundu (saumyen.k) said : 		#5

Thanks Krzysztof Mekala, that solved my question.