Omitting beams statement changes data structure

[sschmidt]

Omitting the beams statement in the .sin file leads to different data structures. Consider a code snipplet like

    call state_iterator_init(it, process%eval_flows%int%state_matrix)
    do while(state_iterator_is_valid(it))
       call quantum_numbers_write(state_iterator_get_quantum_numbers(it))
       call state_iterator_advance(it)
    end do

inserted (in my case) in call event_generate between call decay_tree_generate_event and call event_factorize_process. In case the beams statement is explicitly given, the quantum numbers of the process are printed out, in case the beams statement is omitted no quantum numbers are printed out (the state_iterator is invalid directly after call state_iterator_init).

As the beams statement is optional, there should be no difference?

[sschmidt]

original sin file

[sschmidt]

additional remark: The same goes for hadron collisions, e.g.

process uudd = u, U => d, D

without beams statement gives no quantum numbers, including a beams statement for quark or proton beams gives the correct quantum numbers.

[Juergen Reuter]

That is something I already noted several times that there are differences whether the user specifies beams or not, because there are several branches if (beams_are_used) then bla bla bla which are only active when the user explicitly sets beams.

[kilian]

I hacked the no-beam case so that it works where it is supposed to work. I took care not to introduce redundancies. If there is no beam, the relevant evaluators/interactions are in the hard_interaction subobject. If there are beams, the hard interaction is insufficient, and the complete info is in the process object. The helper functions (something like process_get_eval_flows_ptr) take care of that, they return the correct info in both cases. Here object-orientation is actually useful, the internal representation is irrelevant.

If I didn't misunderstand something, there is no issue here.