K6Bar, K6 and T6 cannot be simplified to a number!

Hi Francesco,

The color structure information for the sextet are not consistent. I will suggest to contact FR author to see what the problem is.
Are you using the latest version of FR?

Cheers,

Olivier

> On 16 May 2017, at 12:33, Francesco <email address hidden> wrote:
>
> New question #632739 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/632739
>
> Hi guys,
> this is the UFO model I am working with
>
> https://www.dropbox.com/sh/l3w41pf8qeslc46/AACEeyEMufgQQRNPrD9P8RUSa?dl=0
>
> I added a new fermion transforming in the 6 of the color SU(3).
>
> When I try to generate the processes and then the output I get the following error
>
> ValueError : String 1 K6Bar(-1006,-1004,1) K6(-1005,-1004,2) T6(-1005,-1000) T6(-1002,-1006) K6(-1002,10000,1) K6Bar(-1000,10000,2) cannot be simplified to a number!
>
> The command I use to generate the processes is
>
> generate u u~ > X1u X1u~, X1u > j j, X1u~ > j j
>
> How can I solve?? Thanks,
>
> F.
>
>
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Dear Olivier,
Thank you. I am using the last versione of FR. I tried to modify the contraction of the color indexes but I do not manage to get the correct one. How can I contact the FR author??

Thanks again,
F.

You can open ticket on their website:
http://feynrules.irmp.ucl.ac.be/

Or contact them directly by email.

Cheers,

Olivier
> On 16 May 2017, at 17:13, Francesco <email address hidden> wrote:
>
> Question #632739 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/632739
>
> Status: Answered => Open
>
> Francesco is still having a problem:
> Dear Olivier,
> Thank you. I am using the last versione of FR. I tried to modify the contraction of the color indexes but I do not manage to get the correct one. How can I contact the FR author??
>
> Thanks again,
> F.
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

I modified the UFO Model, it seems Feynrules do not copy the expression K6Bar into the UFO Mode. I just did the replacement K6 -> K6Bar. Now, the error does not appear anymore.
Here the new UFO model https://www.dropbox.com/sh/13k8bvrqx34spty/AAB-r8JD8g6S0QqFtDi-7ss7a?dl=0
It seems to be better to work with the UFO model directly.

However, even if that error does not appear anymore, when I try to generate new events including the new vertex I wrote (which is of order QCD^2), I get the following error

Command "output trial" interrupted with error:
KeyError : 2
Please report this bug on https://bugs.launchpad.net/mg5amcnlo
More information is found in 'MG5_debug'.
Please attach this file to your report.

For example, the command

generate X1u~ u > X1u~ u

generates only a QCD process and the simulation is in agreement with my theoretical expectation.

Instead, when I type

 generate X1u~ u > X1u~ u QCD=4

I get the error of before. So, it seems there is something wrong with the new interaction vertex, but the error is not useful to understand which kind of correction I have to make.

Thanks
F.

This is the Madgraph debug https://pastebin.com/hikPcP4x

BTW, I am not able to open a ticket on the FR website. The registration of new users seems to be closed.

UPDATE:

I defined a new coupling which weight my interaction, in order to try to isolate and understand the problem. Now, the vertex is multiplied by a new coupling defined with interactionOrder NP.

When I processes involving this new vertex, I get a very long compiling error which I attach at the end of the message.

I tried to compile by myself the process by removing the specification -mmacosx-version-min=10.7 to the compiler.

cd SubProcesses/P1_x1uux_x1uux/
gfortran -o madevent driver.o myamp.o genps.o unwgt.o setcuts.o get_color.o cuts.o cluster.o reweight.o initcluster.o addmothers.o setscales.o idenparts.o auto_dsig.o auto_dsig1.o matrix1.o -L../../lib/ -ldhelas -ldsample -lmodel -lgeneric -lpdf -lcernlib -lbias -lc++ -mmacosx-version-min=10.7

What I get now is

Undefined symbols for architecture x86_64:
  "_ffv8_9c1p0_3_", referenced from:
      _matrix1_ in matrix1.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

What is happening??

Thank you againg.

---------------------------------------------------
FIRST ERROR:

Error detected in "generate_events run_01 -f"
write debug file /Users/francescosgarlata/ColliderPhysics/madgraph/prova/run_01_tag_1_debug.log
If you need help with this issue please contact us on https://answers.launchpad.net/mg5amcnlo
MadGraph5Error : A compilation Error occurs when trying to compile /Users/francescosgarlata/ColliderPhysics/madgraph/prova/SubProcesses/P1_x1uux_x1uux.
 The compilation fails with the following output message:
     gfortran -O -w -fbounds-check -fPIC -ffixed-line-length-132 -w -c driver.f -I../../Source/
     gfortran -O -w -fbounds-check -fPIC -ffixed-line-length-132 -w -c myamp.f -I../../Source/
     gfortran -O -w -fbounds-check -fPIC -ffixed-line-length-132 -w -c genps.f -I../../Source/
     gfortran -O -w -fbounds-check -fPIC -ffixed-line-length-132 -w -c unwgt.f -I../../Source/
     gfortran -O -w -fbounds-check -fPIC -ffixed-line-length-132 -w -c setcuts.f -I../../Source/
     gfortran -O -w -fbounds-check -fPIC -ffixed-line-length-132 -w -c get_color.f -I../../Source/
     gfortran -O -w -fbounds-check -fPIC -ffixed-line-length-132 -w -c cuts.f -I../../Source/
     gfortran -O -w -fbounds-check -fPIC -ffixed-line-length-132 -w -c cluster.f -I../../Source/
     gfortran -O -w -fbounds-check -fPIC -ffixed-line-length-132 -w -c reweight.f -I../../Source/
     gfortran -O -w -fbounds-check -fPIC -ffixed-line-length-132 -w -c initcluster.f -I../../Source/
     gfortran -O -w -fbounds-check -fPIC -ffixed-line-length-132 -w -c addmothers.f -I../../Source/
     gfortran -O -w -fbounds-check -fPIC -ffixed-line-length-132 -w -c setscales.f -I../../Source/
     gfortran -O -w -fbounds-check -fPIC -ffixed-line-length-132 -w -c auto_dsig.f -I../../Source/
     gfortran -O -w -fbounds-check -fPIC -ffixed-line-length-132 -w -c auto_dsig1.f -I../../Source/
     gfortran -O -w -fbounds-check -fPIC -ffixed-line-length-132 -w -c matrix1.f -I../../Source/
     gfortran -o madevent driver.o myamp.o genps.o unwgt.o setcuts.o get_color.o cuts.o cluster.o reweight.o initcluster.o addmothers.o setscales.o idenparts.o auto_dsig.o auto_dsig1.o matrix1.o -L../../lib/ -ldhelas -ldsample -lmodel -lgeneric -lpdf -lcernlib -lbias -lc++ -mmacosx-version-min=10.7
     ld: warning: object file (driver.o) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (myamp.o) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (genps.o) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (unwgt.o) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (setcuts.o) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (get_color.o) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (cuts.o) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (cluster.o) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (reweight.o) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (initcluster.o) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (addmothers.o) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (setscales.o) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (idenparts.o) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (auto_dsig.o) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (auto_dsig1.o) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (matrix1.o) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libdsample.a(DiscreteSampler.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libgeneric.a(alfas_functions.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libbias.a(dummy.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libdhelas.a(aloha_functions.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libgeneric.a(basecode.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libgeneric.a(dgauss.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libgeneric.a(kin_functions.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libdhelas.a(FFV3C1_0.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libdhelas.a(FFV4C1_0.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libdhelas.a(FFV9C1P0_3.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libgeneric.a(getissud.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libgeneric.a(invarients.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libpdf.a(opendata.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libpdf.a(pdg2pdf.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libmodel.a(printout.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libdsample.a(dsample.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libdsample.a(ranmar.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libgeneric.a(rw_events.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libgeneric.a(readgrid.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libgeneric.a(run_printout.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libmodel.a(rw_para.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libgeneric.a(setrun.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libgeneric.a(transpole.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libmodel.a(couplings.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libgeneric.a(ran1.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libdsample.a(StringCast.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libmodel.a(couplings1.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libmodel.a(couplings2.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libpdf.a(cteq3.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libpdf.a(Ctq4Fn.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libpdf.a(Ctq5Par.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libpdf.a(Ctq5Pdf.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libpdf.a(Ctq6Pdf.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libcernlib.a(dlsqp2.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libpdf.a(PhotonFlux.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libgeneric.a(pawgraphs.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libpdf.a(pdfwrap.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libpdf.a(pdf.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libpdf.a(mrs98.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libpdf.a(mrs98ht.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libpdf.a(mrs98lo.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libpdf.a(mrs99.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libpdf.a(mrst2001.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libpdf.a(mrst2002.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libpdf.a(NNPDFDriver.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libpdf.a(Partonx5.o)) was built for newer OSX version (10.12) than being linked (10.7)
     ld: warning: object file (../../lib//libpdf.a(jeppe02.o)) was built for newer OSX version (10.12) than being linked (10.7)
     Undefined symbols for architecture x86_64:
       "_ffv8_9c1p0_3_", referenced from:
           _matrix1_ in matrix1.o
     ld: symbol(s) not found for architecture x86_64
     collect2: error: ld returned 1 exit status
     make: *** [madevent] Error 1

 Please try to fix this compilations issue and retry.
 Help might be found at https://answers.launchpad.net/mg5amcnlo.
 If you think that this is a bug, you can report this at https://bugs.launchpad.net/mg5amcnlo

Hi Francesco,

Concerning your first error (the keyerror), it seems to be related to a leading-color flow problem.
Having a new coupling seems indeed the safest way to solve the problem.
Otherwise, I have tried the following fix in madgraph, but it is far from easy to validate this.
Note that this will not impact the cross-section/ distribution but it can have impact on the parton-shower (via the choice of the starting dipole).

=== modified file 'madgraph/iolibs/export_v4.py'
--- madgraph/iolibs/export_v4.py 2017-05-16 15:19:50 +0000
+++ madgraph/iolibs/export_v4.py 2017-05-18 13:33:17 +0000
@@ -1093,6 +1093,8 @@
                     # Add this JAMP number to this diag_num
                     diag_jamp[diag_num] = diag_jamp.setdefault(diag_num, []) + \
                                           [ijamp+1]
+ else:
+ diag_jamp[diag_tuple[0] + 1] = []

         colamps = ijamp + 1
         for iconfig, num_diag in enumerate(mapconfigs):

Concerning the second problem (the missing of one function), here is the appropriate patch:

=== modified file 'aloha/aloha_writers.py'
--- aloha/aloha_writers.py 2017-05-13 00:25:29 +0000
+++ aloha/aloha_writers.py 2017-05-18 16:54:14 +0000
@@ -1205,6 +1205,14 @@
 def combine_name(name, other_names, outgoing, tag=None, unknown_propa=False):
     """ build the name for combined aloha function """

+ if tag and any(t.startswith('P') for t in tag[:-1]):
+ # propagator need to be the last entry for the tag
+ for i,t in enumerate(tag):
+ if t.startswith('P'):
+ tag.pop(i)
+ tag.append(t)
+ break
+
     # Two possible scheme FFV1C1_2_X or FFV1__FFV2C1_X
     # If they are all in FFVX scheme then use the first
     p=re.compile('^(?P<type>[RFSVT]{2,})(?P<id>\d+)$')

Oliver, thank you for your patience. This patch solved my problem! Thanks

Sorry Oliver, now madgraph is giving me no zero result for a specific process.

I start by generating x1u > j j, where x1u is the new particle of my model. Everything is ok, my new interaction works good and Madgraph gives me the Width.

Then, I generate u u~ > x1u x1u~ , x1u > j j , x1u~ > j j and I use the SAME param_card and run_card of the previous simulation ( x1u > j j). What I get is

1) A massive s-channel particle has a width set to zero.
   2) The pdf are zero for at least one of the initial state particles
      or you are using maxjetflavor=4 for initial state b:s.
   3) The cuts are too strong.

Then,

a) I Checked the width. Its value is different from zero, I read it from the param_card. The mass of the particle is well below the sqrt(s)/2 of the initial partons.
b) I Turned off the pdfs
c) The cuts are already turned off, since I am usign the run_card of the decay process x1u > j j.

What's going on?
There is a way to understand why madgraph gives me this error?

* is giving me a zero result for a specific process.

Run_card: https://pastebin.com/YPXFD6B5

Param_card : https://pastebin.com/WfVHmcgV

I thought that maybe the coupling was set to zero, but since the process x1u > j j goes through the same interaction and the param_card is the same, this is not possible. Anyway, the coupling is gS * Ep where Ep is the parameter set in the param_card.

Thanks

Hi,

Can I have your new model?
I have check with your old model and both patch, and the first patch does not seem to do the job.
It goes further but then the color information is wrongly setup and makes the code to crash at generation time.

Since adding that coupling was fixing the first problem in your case. I’m not sure that you face the same problem as the one I face.

Cheers,

Olivier

> On 19 May 2017, at 04:25, Francesco <email address hidden> wrote:
>
> Question #632739 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/632739
>
> Francesco gave more information on the question:
> Run_card: https://pastebin.com/YPXFD6B5
>
> Param_card : https://pastebin.com/WfVHmcgV
>
> I thought that maybe the coupling was set to zero, but since the process
> x1u > j j goes through the same interaction and the param_card is the
> same, this is not possible. Anyway, the coupling is gS * Ep where Ep is
> the parameter set in the param_card.
>
> Thanks
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

You are right, here the model https://www.dropbox.com/sh/9gqn17g2o0sc839/AAB9sTv83M7zElmxSyHSE-a8a?dl=0

With this model, i needed only to add the second patch, since I defined a new interaction order for the new vertex.

Thanks,
Francesco

Hi,

By looking at your model, I realised that the LO width of x1u is extremely large.
This is surprising since you use a syntax which force x1u to be on shell (and you set the width to a quite small value)
This has nothing to do with this crash, but I need to know if I can use NWA to find work-around.

The main problem seems that your color-flow has some funny property related to the fact that both decay are color-connected via this product of epsilon/K6 structure.
Such connection can not be correctly represented in the LHEF file.
So do you plan to run a pardon-shower of those events? If not, then it should be possible to find some hacky way to write the LHEF file. Such that the code goes trough.

Another option, is to use MadSpin for the decay (maybe with the “onshell” mode) but that would work only if you can restrict yourself to NWA.

Cheers,

Olivier

> On 19 May 2017, at 09:53, Francesco <email address hidden> wrote:
>
> Question #632739 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/632739
>
> Status: Answered => Open
>
> Francesco is still having a problem:
> You are right, here the model https://www.dropbox.com/sh/9gqn17g2o0sc839
> /AAB9sTv83M7zElmxSyHSE-a8a?dl=0
>
> With this model, i needed only to add the second patch, since I defined
> a new interaction order for the new vertex.
>
> Thanks,
> Francesco
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hi Oliver,
Thanks for your interest. Looking at the log in the Subprocesses/P1..../G1 folder, MadGraph complains about the colour structure. This is strange since the problem does not rise for the other processes I mentioned above.

Actually, the big value of the width is just a random value which I have to set depending on the parameters of my theory. So, don't care about that big value. I will work in NWA. Maybe I can try to use MadSpin (which I have never used... So, I should learn to use it).

Which is the other hacky way you were thinking about?

Cheers,

Francesco

Hi,

Thanks for your interest. Looking at the log in the Subprocesses/P1..../G1 folder, MadGraph complains about the colour structure. This is strange since the problem does not rise for the other processes I mentioned above.

When combining the different process, the color face a K6(m,i,j)K6Bar(m,k,l)
Which gives a mixing between the two decay. This is this mixing that is the problem. Each piece separately is indeed fine.

 Actually, the big value of the width is just a random value which I have
to set depending on the parameters of my theory. So, don't care about
that big value.

The problem is that I can not test MadSpin due to the value of the width (Since that code does not work out of NWA)
I have check that if you use the
Following card for madspin:
set spinmode onshell
decay x1u > j j
decay x1u~ > j j
launch

Then you have a decay and color information which is sensible. Now they are probably only pythia8 which can decay such event (not even sure they can).

Cheers,

Olivier

On 20 May 2017, at 04:19, Francesco <<email address hidden><mailto:<email address hidden>>> wrote:

Question #632739 on MadGraph5_aMC@NLO changed:
https://answers.launchpad.net/mg5amcnlo/+question/632739

   Status: Answered => Open

Francesco is still having a problem:
Hi Oliver,
Thanks for your interest. Looking at the log in the Subprocesses/P1..../G1 folder, MadGraph complains about the colour structure. This is strange since the problem does not rise for the other processes I mentioned above.

Actually, the big value of the width is just a random value which I have
to set depending on the parameters of my theory. So, don't care about
that big value. I will work in NWA. Maybe I can try to use MadSpin
(which I have never used... So, I should learn to use it).

Which is the other hacky way you were thinking about?

Cheers,

Francesco

--
You received this question notification because you are an answer
contact for MadGraph5_aMC@NLO.

Hi Oliver,
I am not sure to have understood.

I tried to use Madspin with the card you gave me, but nothing changes. I don't need to shower the process, I just need the matrix element.

The width can be set to be of order 10^-4 GeV, there is no special requirement on this value.

Hi,

To use madspin, you have to generate only the production (i.e. generate p p > x1u x1u~)
Then the madspin card should work.
(Note that the madspin card that I created was keeping x1u exactly on shell)

Cheers,

Olivier

> On 21 May 2017, at 15:23, Francesco <email address hidden> wrote:
>
> Question #632739 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/632739
>
> Status: Answered => Open
>
> Francesco is still having a problem:
> Hi Oliver,
> I am not sure to have understood.
>
> I tried to use Madspin with the card you gave me, but nothing changes. I
> don't need to shower the process, I just need the matrix element.
>
> The width can be set to be of order 10^-4 GeV, there is no special
> requirement on this value.
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hi Oliver,
Thank you. I managed to generates the 4jets events.

However, the process is very slow. To generate g g > x1u x1u~ and then the decay x1u > jj and x1u~>jj, it tooks more than 1 hour par running.

I see a multitude of INFO: generate 50000 decay event for particle x1u~ .
50000 seems a very huge number of events.
It is normal?

Thanks again,

Francesco

I noticed that it takes a long time for a small value of the mass of this new particle, for example, m=600 GeV. For m=6TeV, the process proceeds at normal speed.

Hi,

> I see a multitude of INFO: generate 50000 decay event for particle x1u~ .
> 50000 seems a very huge number of events.
> It is normal?

I typically expect that around 70k decay events are needed for doing 10k events.
(You roughly need 50k to compute the max-weight and then 2 event for each event you want to decay)

If you need much more, it just means that you have a large variance in the weight and that the un-weighting efficiency is quite low.
The physical explanation of that is that you have huge spin-correlation.

Cheers,

Olivier

> On 21 May 2017, at 21:57, Francesco <email address hidden> wrote:
>
> Question #632739 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/632739
>
> Status: Answered => Open
>
> Francesco is still having a problem:
> Hi Oliver,
> Thank you. I managed to generates the 4jets events.
>
> However, the process is very slow. To generate g g > x1u x1u~ and then
> the decay x1u > jj and x1u~>jj, it tooks more than 1 hour par running.
>
> I see a multitude of INFO: generate 50000 decay event for particle x1u~ .
> 50000 seems a very huge number of events.
> It is normal?
>
> Thanks again,
>
> Francesco
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hi Oliver,

my last run took more than 12hours. I runned the job in a cluster and after 12hours, it was killed by the server.
Madspin was almost at the end of the simulation, the generation of the last decays was occurring.
Is there any way to recover the simulation from that point, without restarting it from scratch??

this is the output
....
....
...
INFO: generate 50000 decay event for particle x1u
INFO: generate 50000 decay event for particle x1u~
INFO: generate 50000 decay event for particle x1u
INFO: generate 50000 decay event for particle x1u~
cn06-21 : flushing filesystem cache...
cn06-21 : filesystem cache flushed

Hi,

We do not have anything automatic. But in this case, this is conceptually simple.
1) you save your decayed_events output
2) you create a new production events sample without all the events who have been decayed
3) you run madspin in standalone mode on this new events file
4) you merge the two decayed files.
5) you continue as usual on this file

Cheers,

Olivier

PS: I'm really surprised that the unweighting is so bad in your case. What is the value for the width of your particle?
Did you set that one to exactly 0? If that's the case, the code can be numerically sensitive to the propagator leading to huge un-efficiency.
The second option for bad efficiency is if the width is very large since in that case, the NWA (and the method) does not apply and then you can have some funny behaviour.

> On 24 May 2017, at 12:03, Francesco <email address hidden> wrote:
>
> Question #632739 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/632739
>
> Status: Answered => Open
>
> Francesco is still having a problem:
> Hi Oliver,
>
> my last run took more than 12hours. I runned the job in a cluster and after 12hours, it was killed by the server.
> Madspin was almost at the end of the simulation, the generation of the last decays was occurring.
> Is there any way to recover the simulation from that point, without restarting it from scratch??
>
> this is the output
> ....
> ....
> ...
> INFO: generate 50000 decay event for particle x1u
> INFO: generate 50000 decay event for particle x1u~
> INFO: generate 50000 decay event for particle x1u
> INFO: generate 50000 decay event for particle x1u~
> cn06-21 : flushing filesystem cache...
> cn06-21 : filesystem cache flushed
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

I think the problem is related to the value of the width. How small it has to be wrt the mass, in order to have a good result??

width/mass <= 10^(-4) is ok?

Hi,

I would say that it should be in this range:
> 10^(-10) <= width/mass <= 10^(-2)

Cheers,

Olivier

> On 24 May 2017, at 12:59, Francesco <email address hidden> wrote:
>
> Question #632739 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/632739
>
> Status: Answered => Open
>
> Francesco is still having a problem:
> I think the problem is related to the value of the width. How small it
> has to be wrt the mass, in order to have a good result??
>
> width/mass <= 10^(-4) is ok?
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

For example, do you think are these values ok?

set MX1u 1000 #mass
set wxu 1.989e-05 #width

Hi,

 I think that it should be ok.

Cheers,

Olivier

> On 24 May 2017, at 17:02, Francesco <email address hidden> wrote:
>
> Question #632739 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/632739
>
> Status: Answered => Open
>
> Francesco is still having a problem:
> For example, do you think are these values ok?
>
> set MX1u 1000 #mass
> set wxu 1.989e-05 #width
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

I sent the job to the cluster. It is still running... after one hour he has only decayed 1k events

decaying event number 1000. Efficiency: 1365.51951952 [3051.53562498 s]

If you think this is strange, can we try to identify the problem?
If it is normal, I'll just wait :)

Thanks,
Francesco

Hi Francesco,

I have try with the latest model that you send me and for the mass/width that you choose.

I have an (obvious) warning since I did not change the model parameter to be consistent with that width:
WARNING: partial width (19894000.0) larger than total width (1.989e-05) --from param_card--

But otherwise, I have a reasonable speed and generation efficiency.

INFO: Estimating the maximum weight
INFO: *****************************
INFO: Probing the first 75 events with 400 phase space points
INFO: Event 1/75 : 0.461438s
INFO: Event 6/75 : 2.054677s
INFO: Event 11/75 : 3.541619s
INFO: Event 16/75 : 4.855628s
INFO: Event 21/75 : 6.234468s
INFO: Event 26/75 : 7.760740s
INFO: Event 31/75 : 9.118150s
INFO: Event 36/75 : 10.482250s
INFO: Event 41/75 : 11.828342s
INFO: Event 46/75 : 13.233212s
INFO: Event 51/75 : 14.692691s
INFO: Event 56/75 : 16.158660s
INFO: Event 61/75 : 17.605376s
INFO: Event 66/75 : 19.117598s
INFO: Event 71/75 : 20.659473s
decaying event number 1000. Efficiency: 6.85685685686 [5.78353190422 s]
decaying event number 2000. Efficiency: 6.81090545273 [11.0364789963 s]
decaying event number 3000. Efficiency: 6.55751917306 [15.8290820122 s]
decaying event number 4000. Efficiency: 6.36834208552 [20.4663388729 s]
INFO: generate 35653 decay event for particle x1u
decaying event number 5000. Efficiency: 6.42908581716 [44.2077810764 s]
decaying event number 6000. Efficiency: 6.34939156526 [49.2830140591 s]
decaying event number 7000. Efficiency: 6.29189884269 [54.1901409626 s]
decaying event number 8000. Efficiency: 6.27565945743 [59.7715570927 s]
decaying event number 9000. Efficiency: 6.29047671964 [65.0889010429 s]
INFO: The decayed event file has been moved to the following location:
INFO: /Users/omattelaer/Documents/workspace/2.5.5/PROC_6pletProduction_UFO-1_1/Events/run_01_decayed_1/unweighted_events.lhe
INFO: MadSpin Done

Cheers,

Olivier

> On 24 May 2017, at 17:44, Francesco <email address hidden> wrote:
>
> Question #632739 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/632739
>
> Status: Answered => Open
>
> Francesco is still having a problem:
> I sent the job to the cluster. It is still running... after one hour he
> has only decayed 1k events
>
> decaying event number 1000. Efficiency: 1365.51951952 [3051.53562498 s]
>
> If you think this is strange, can we try to identify the problem?
> If it is normal, I'll just wait :)
>
> Thanks,
> Francesco
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.