Hi,

I run (some of) the test this morning (actually 630 of thoses)
and this one sounds quite bad:

ERROR: test_generate_fks_ew (tests.unit_tests.fks.test_extra_ew.TestAMCatNLOEW)
check that the generate command works as expected.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/omattelaer/Documents/workspace/3.0.1/tests/unit_tests/fks/test_extra_ew.py", line 112, in test_generate_fks_ew
    self.assertEqual(set(split), self.interface._fks_multi_proc['splitting_types'])
  File "/Users/omattelaer/Documents/workspace/3.0.1/madgraph/core/base_objects.py", line 69, in __getitem__
    self.is_valid_prop(name) #raise the correct error
  File "/Users/omattelaer/Documents/workspace/3.0.1/madgraph/core/base_objects.py", line 86, in is_valid_prop
    Valid property are %s""" % (name,self.__class__.__name__, self.keys())
PhysicsObjectError: splitting_types is not a valid property for this object: FKSMultiProcess

    Valid property are ['has_isr', 'use_numerical', 'amplitudes', 'born_processes', 'pdgs', 'ignore_six_quark_processes', 'collect_mirror_procs', 'process_definitions', 'OLP', 'real_amplitudes', 'init_lep_split', 'diagram_filter', 'ncores_for_proc_gen', 'has_fsr', 'loop_filter']

some other crashes like this one:

======================================================================
FAIL: testIO_test_wprod_fksew (tests.unit_tests.iolibs.test_export_fks.IOExportFKSTest)
target: SubProcesses/[P0.*\/.+\.(inc|f)]
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/omattelaer/Documents/workspace/3.0.1/tests/IOTests.py", line 257, in __wrapper
    testKeys=[(testGroup, newTestName)])
  File "/Users/omattelaer/Documents/workspace/3.0.1/tests/IOTests.py", line 700, in runIOTests
    self.assertFileContains(open(file_path), goal)
  File "/Users/omattelaer/Documents/workspace/3.0.1/tests/IOTests.py", line 389, in assertFileContains
    self.assertEqual(a,b)
AssertionError: '      CALL FFV1_2(W(1,4),W(1,2),GC_3,DCMPLX(ZERO),W(1,8))' != '      CALL FFV1_2(W(1,4),W(1,2),-GC_4,DCMPLX(ZERO),W(1,8))'


Which should be related to model optimization include in 2.6.3. I believe that this is fine (amy does not agree?)

Cheers,

Olivier

On 4 Oct 2018, at 23:24, Olivier Mattelaer <<email address hidden><mailto:<email address hidden>>> wrote:

Hi Rikkert,

The display is actually perfect for QED (see below):


The following switches determine which programs are run:
/================== Description ==================|=========== values ===========|================ other options ================\
| 1. Type of perturbative computation             |            order = NLO       |     LO                                        |
| 2. No MC@[N]LO matching / event generation      |      fixed_order = ON        |     No NLO+PS available for EW correction     |
\================================================================================================================================/
Either type the switch number (1 to 6) to change its setting,
Set any switch explicitly (e.g. type 'madspin=onshell' at the prompt)
Type 'help' for the list of all valid option
Type '0', 'auto', 'done' or just press enter when you are done.[60s to answer]


Maybe are you referring to the display in debug mode, which include the hidden line (madspin/...)
which are important to see (but only in debug mode). [Also for the hidden option of MadSpin]
In that case, formatting is indeed weird.
I have (slightly) improve it
1) passing the color to green (more consistent with debug coloring in general)
2) fixing the change of length due to the presence of the coloring
This is still not perfect since the length of each column does not take into account those hidden line.
and therefore they can go to overflow.


Cheers,

Olivier



On 4 Oct 2018, at 17:16, Rikkert Frederix <<email address hidden><mailto:<email address hidden>>> wrote:

Hi,

A small change means that the switches are okay now for the QCD stuff. However, for QED, the formatting looks off. I'm not sure we should be too worried about this, since it works correctly. If there is a simple fix, we might apply it.

Cheers,
Rikkert

--
https://code.launchpad.net/~maddevelopers/mg5amcnlo/3.0.1/+merge/356133
You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.


--
https://code.launchpad.net/~maddevelopers/mg5amcnlo/3.0.1/+merge/356133
You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.