Hello Olivier, Many thanks for your comments. > >I have redone the implementation in a minimal manner. This way, none of our > previous >functionality is affected, which I believe is the most safe way to > do it (especially >considering > >the *enormous* amount of time I have spent on getting the fermion flow > correct for all cases).I > >certainly don't dare touch that part of the code unless it's absolutely > necessary. > > At the end this is quite similar to what I did. > - one modification to need_hermitian (both). > - one modification to need_charge_conjugate (both). > So I don't understand your comment above. You also touched check_and_fix_fermion_flow, which is very dangerous (this I know from experience - as I said, this part of the code is among the most complicated and I have been working this over many times already without managing to simplify it, fixing many bugs). This, and the host of failing tests, and the obvious problem that you had to touch the sign for gluinos made me prefer to redo the implementation in a way that made more sense to me. Of course, the honor for solving the problem (using conjugate wfs) all goes to you. :-) > The main differences between those two versions are > 1) that I didn't veto the Conjugate on identical majorana (which creates the > trouble with the tests that you mention) > 2) that you factorize everything in one function (see below) > 3) that you treat 4 fermion case, (Excellent that you did) > > But I really consider my implementation much more simpler to understand. (Off > course I'm biased) My solution exactly mirrors what is done in sorted_mothers, so basically, if you understand one you understand the other. So clearly also sorted_mothers is not clear (see below). > I would strongly suggest to split majorana_conjugates > in two separate functions. One for the wavefunctions and one for the > amplitudes. > the number of if in this case checking in which case we are (and some of them > quite implicit) > makes the code un-readable. Do you want me to do this also for sorted_mothers? The idea was to make the code as DRY as possible, but indeed the repetition is quite minor at this point (since I already at some point extracted sort_by_pdg_codes from this function). > Please also split the long if. This will make the code more readable. > some if test in fact two completely different things > 1) if both particle are majorana > 2) if the flow is correct > make two if is maybe longer (and with additional else) but much more clear. Ok, sure. > Another problem, but with wich we can life with, is that they the structure is > now quite un-efficient. > > in get_call_key: > 1) it check if it need the hermitian > --> one call the majorana_conjugates > 2) it ask for the conjugate index > --> call to get_conjugate_index > This one check first if if need the hermitian conjugate > --> second call to majorana_conjugates > Then call itself majorana_conjugates > --> third call to majorana_conjugates > > Then at a point we will call get_used_lorentz > which will make a call to get_conjugate_index > So two additional call to majorana_conjugates > > So five calls to this functions this is a bit pointless. Certainly true. Note however that if there are no Majorana particles among the mothers, the time is negligible. So it's only for a small number of wavefunctions that this could be a problem. > We can: > 1) store the data (forbids the static method but fine if you split the routine > in two as suggested above) such that the data is compute only once. I think this is the right way to go in fact. I'll look at it. > Finally, your test is about MG4 Model, which are in fact insensitive to this > problem in mg5. > (Since the call for such routine are not implemented) Are they a good reason > for not using UFO syntax in your tests? It's just a matter of switching the helas_call_writer. Since I don't test the 4F functionality here (might be good to do though), it doesn't make any difference. So I just did the same as the other tests. I'd be happy to switch if you prefer, since you are more used to reading ALOHA call syntax. (I'm still slightly more used to reading the HELAS call syntax, hence my choice). Many thanks, Johan