Enable W1's user.f90 again

[ohl]

Required by the ILC people

[Juergen Reuter]

After more discussions with the experimentalists, this really is of utmost importance. Just to stress it again...

[kilian]

So far, user cuts, observables etc. are available. Still missing: user spectra/strfun. Documentation also missing (but there is a test in the standard test suite).

[Juergen Reuter]

According to the phone call with WK this is almost ready and "only" needs some proper testing...

[kilian]

Current status: Implementation complete & works with a simple test structure function.

The user.90 check still fails, but apparently due to a gfortran 4.5 bug in an unrelated function. I'll have to find a workaround.

[kilian]

Checked in r3584.

There are now the following user plugin possibilities:

• user_cut (a function working on a subevent that returns a logical)
• user_event_shape (a function working on a subevent that returns a real value)
• user_obs (a function working on a particle or particle pair that returns a real value)
• user_strfun (a structure function or spectrum for a single beam or a beam pair)

For the latter, the user has to implement four procedures: info, states, kinematics, evaluation.

The test user_strfun.run fails with gfortran 4.5.0 on my machine. This is apparently a bug in the compiler memory management (leads to glibc double free panic etc.). It happens when I have two different beam setups in the same .sin file, as I did for comparing the user strfun with a known one.

Let's see if this was fixed in newer versions ...

[sschmidt]

A feature request: If a sin file with user code is executed, but the user omits the -u switch, whizard crashes with a strange error about compiler libraries. Both Daniel and I stumbled upon this.

For a public release there should be some meaningful errormessage. (Or the -u switch should be removed, for example compiling the user code if the <user>.f90 file is newer than the user library)

[sschmidt]

subevents not working when using user_event_shape

subevents are not evaluated when collecting the particles, e.g. changing the cuts in the user_cuts.sin example to

process user_p = e1, E1 => e2, E2
...
cuts = user_cut("ptcut") [incoming e1:E2]

or

cuts = user_event_shape("pt1") [incoming e1:E2] < 50

the particle array in the user-defined procedure only holds the final particle (n_prt is 1).

[Juergen Reuter]

Could someone remind me what -- after the workshop -- the status of that one is!?

[kilian]

As of r3610, most of the functionality is implemented and documented.

What is still missing is the ability to link user code to a static executable.

[kilian]

Regarding the supposed bug above (subevents not working ...):

I can't reproduce this with the current version. In both examples, I get n_prt=2 when I print it out from the user function, and the operation is applied to the incoming particles.

Could you check again?

[Juergen Reuter]

Ok, S.S. will have to check that... What about the static build. Is there a major obstacle?

[kilian]

Static build: the point is that all user-defined functions have to be hardcoded in order to be callable. The 'libmanager' module has to take care of that. It has to know about all function names explicitly.

[Juergen Reuter]

And this means now exactly what? --- just a reminder to our schedule..........

[sschmidt]

Replying to kilian:

Regarding the supposed bug above (subevents not working ...):

I can't reproduce this with the current version. In both examples, I get n_prt=2 when I print it out from the user function, and the operation is applied to the incoming particles.

Could you check again?

I just checked (r3612, both gfortran 4.6 and nagfor) and still get a particle array consisting of only one element (see the print statement in ticket429_user.f90)

I'll attach my files. My command line was

whizard -u --rebuild-events --user-src ticket429_user.f90 ticket429_ee.sin

for the e+e- case, replace ee with pp for the proton-proton case.

[kilian]

@jr: Whizard is run on the grid with the static build, requiring no compiler. This should also be the case for the user code, otherwise it can't be included. I'm working on this right now. When it is done (and Sebastian's issue clarified), I'll close the ticket.

[kilian]

The implementation is now complete, cf. r3616.

Problem with incoming particles in subevent still open.

[kilian]

Well, the subevt problem was a flaw in the SINDARIN code.

In the ee example I read

analysis = record hist3 (user_event_shape("cts") [incoming e1:u])

which for the process e+ e- => u U returns a single incoming electron.

If you were interested in a subevent of both incoming particles, the code should read

analysis = record hist3 (user_event_shape("cts") [incoming e1:E1])

If you were interested in a subevent consisting of the incoming electron and the outgoing u, you should write either of the two equivalent forms

analysis = record hist3 (user_event_shape("cts") [incoming e1 & u])
analysis = record hist3 (user_event_shape("cts") [join [incoming e1, u]])

With the change, the result looks ok. I close the ticket.