Rework process and process library handling

[kilian]

I started revising the modules that handle process libraries and processes. Several problems with the old code make this necessary.

The first check-in with work-in-progress is r4027.

Goals:

• Handle matrix elements of arbitrary kinds (internal, external, hand-written, etc.) by a common process object.
• Multiple components of a process (some of them may be automatically generated, such as dipole subtractions).
• Remove unnecessary hard-coded assumptions, such as the use of VAMP for integration.
• Separate interface from implementation. For instance, all OMega-specific stuff is now in a separate module that extends a couple of abstract generic types.
• All new code should be covered by unit tests from the beginning, as far as it makes sense.

The original motivation was:

For various applications (in particular, NLO), a process has multiple subprocesses with kinematics and event samples that are partly common, partly separate. The process object has to be extended such as to properly handle those.

[Juergen Reuter]

Somehow this ticket slipped through... Is that not done when we merge CSs branch?

[kilian]

No. We agreed that I'll review CS's mods and maybe rewrite the process object in a more transparent way.

[Juergen Reuter]

Ok, that changes priorities then...

[Juergen Reuter]

Would be great, WK, if you could revisit this. Because: then, we could go and merge this with the trunk while I'm visiting CS in Freiburg in 2 weeks.

[Juergen Reuter]

Actually, this becoming one of the major stumbling stones for the project! It should be resolved at best before the next meeting!!!

[kilian]

This issue is directly connected to the recent merge of the NLO infrastructure. The process object and its components have to be properly (re)structured, incorporating the NLO additions and allowing for present and future extensions. This task requires a major rewrite of (part of, at least) the process-object related code.

Until this is done, don't expect the system to function properly. Currently, WHIZARD compiles, and basic tests and processes do work, but the decay and structure-function parts are defective.

[kilian]

As long as #468 is under construction, this has to be postponed again.

[kilian]

Wrong ticket rated down, correction ...

[Juergen Reuter]

Any progress here ... ???

[kilian]

Since you're asking:

I have agreed (with myself) on a new, much better structured process record. The functionality won't really change, but it is tedious to go through all subobjects and sub-subobjects to implement that change. I'm working with a temporary GIT repository locally, as ThO suggested. This means that I will touch the svn repository only once in a while. If anybody has urgent unrelated changes to whizard.nw, I can pull them in and keep up to date.

[Juergen Reuter]

Progress? ...

[Juergen Reuter]

Happy New Year. Any progress? This is getting terribly urgent!