default cuts

Hi Yehia
(first of all there is still the other open issue, https://answers.launchpad.net/whizard/+question/705947, shall/can I close that one?).
to the answer for this one: there are _no_ default cuts in WHIZARD, all cuts have to be set explicitly by the user.
Yes, there is an option to automatically calculate the width within the model,
writing
unstable <particle_name> () { ?auto_decays = true }
You can also reset
auto_decays_multiplicity = 3
etc. if you want to consider also three-body decays in that.
Regarding the dependence of the cross section on the mass of the Zp, this is hard to tell without details on the model. Naively, you are right, if there is more phase space, the cross section should be larger. Of course, things also depend on the width of the Zp. What order of magnitude is it? Is the dominant resonant process e+e- -> Z Zp, or is it a different process?
Cheers,
   JRR

In the manual, I saw this:

Note that the default cuts are taken into account only if there is no appropriate entry in the user cut file whizard.cut1.

It seems has default cut. If so, where to find it?

Thank you,
Si

Where did you get that from? That is from the manual of WHIZARD version 1 which was made obsolete with the advent of v2.2 in May 2014. In WHIZARD v2 and v3, there is some sort of emulation of the "default cuts" from WHIZARD v1 which you find in the functional test share/tests/functional_tests/defaultcuts.sin, including the file share/cuts/default_cuts.sin.

There is an error that comes up when I add the lines
 unstable vx () { ?auto_decays = true }
 unstable n2 () { ?auto_decays = true }

which is
******************************************************************************
******************************************************************************
*** FATAL ERROR: Process 'ee_n1n1z_isr' not found in library 'default_lib_dp56'
******************************************************************************
******************************************************************************

The thing is I have tried to generate the same process using madgraph and the cross section behaved normally but with madgraph the width of the decaying particles was set to be computed automatically as instructed by the author of the model. So I am trying to figure out how to calculate it automatically with WHIZARD to see if this is the reason why it behaves abnormally.

Also the open issue you mentioned is not mine.

Thank you for your time

Yes, sorry, you are right, of course, regarding the other open issue. The error message you see comes from an unclean workspace.
You should run your input file in a clean folder or erase your .libs folder in the workspace.

I ran the file from a new folder and it still gives me the same error. IF I remove the unstable vx () { ?auto_decays = true } lines it works normally.

The following works for me (for the SM):
me = 0
mmu = 0
mtau = 0

seed = 0
error_threshold = 1E-8

auto_decays_multiplicity = 2
?auto_decays_radiative = false

unstable Wp () { ?auto_decays = true }
unstable Wm () { ?auto_decays = true }

sqrts = 200 GeV

process eeww = e1, E1 => Wp, Wm

integrate (eeww)

This worked for me too but it doesn't work for my signal

===========================================================================
model=LightVector1 (ufo)

seed = 0
error_threshold = 1E-8
gxl = 0.1
MVdark = 80 GeV
Mn1 = 1 GeV
Mn2 = 106 GeV

unstable n2 () {?auto_decays=true}
?auto_decays_radiative = false

process ee_n1n1z = "e-", "e+" => n1, n2
compile

sqrts = 500 GeV

integrate(ee_n1n1z)
============================================================================================
It gives the same error

*** FATAL ERROR: Process 'ee_n1n1z' not found in library 'default_lib_dp1000023'
==============================================================================================

Can I send you my ufo model to check for yourself?

No need for that: the problem is the order of statements: you should either remove the compile statement (it will be explicitly done with the integrate statement anyways), or you should move the unstable statement after the compile statement.
The compile statement makes Whizard recompiles the process libraries, and then it accidentally searches the main scattering process in the decay process library.

It now works thank you!

I have one more question though.

I am using the restrictions method so the output of the process is the cross section times branching ratio not the cross section and the decay widths individually.

 When I use auto method to calculate the decay widths, will the cross section times branching ratio be calculated using the auto computed decay widths or the preset width? I have noticed that it still uses the preset widths. How can make it use the auto computed widths to evaluate the cross section times branching ratio?

With restrictions, this is a full matrix element, not the narrow-width approximation. And yes, the couplings taken there would lead to partial widths from the auto decays.

I am sorry but this hasn't answered my question. How can I instruct WHIZARD to calculate the cross-section x Br using the auto computed widths?

Yehia, this is a completely different question that has nothing to do with the original one on 'default cuts', please for the next time
consider closing a question and open a new one.
Whizard does not give out sigma * BR as one quantity, as event samples are always given w.r.t. to the production cross section.
When there is only one decay, the BR is 1, and the xsec is the one of the production, are there more/all, then all events according to the production xsec are generated and distributed in a mixed sample according to the different BRs (coming from the recalculated ones). The BRs are shown both as screen output and in the log file together with the production xsec, so getting these numbers are trivial.
Maybe Wolfgang who coded that part might add a bit further.

Ok I will open a new issue that accurately describes the sigma x br question and close this one.