Implement nullary observables

[sschmidt]

Up to now, all observables are unary or binary. Implementing nullary observables can be useful in two ways:

1. to provide event-wide observables, the most prominent being shat in hadron collisions. (This could also be implemented using a subevent-ary observable, #430)Implementing cuts on shat is very tedious. Take the process

   g g -> b b bbar bbar
   

as an example.

2. to provide bookkeeping information, for example the process name, making input-files like

   process p1 = <some signal process>
   process p2 = <some background process>
   
   analysis = record signal_dist ( ... [select if Process == p1])
         and background_dist ( ... [select if Process == p2])
   
   simulate(p1,p2)
   

The latter could also be achieved by using different simulate commands and doing the analysis separately. Implementing the first would make some things very much easier.

[Juergen Reuter]

This is a SINDARIN construct that needs to be documented etc. and affects directly the way the user steers WHIZARD. This should be done very quickly....

[kilian]

I'm implementing user-defined event-shape functions (cf. #429). Event shapes are not uniquely defined, so I haven't yet implemented them natively in Sindarin. We should discuss further.

[kilian]

Oops, the last comment should go to #430.

Regarding 'nullary' observables (in fact, just variables that vary event by event), there are already some: event_index, sqme, ...

It looks like sqrts is not among them. It can be computed as

   eval M [collect [particle]]

but I might add it to the list nevertheless. The process name could be included, when available.

[kilian]

As said above, there is a list of 'nullary' observables (actually event-specific variables), since some time already. Here they are:

event_index, process_index, process_num_id event_weight, event_excess_weight, event_sqme, event_sqme_ref,

I'd like to know what you would like to have in addition ...?

So far, I do S&P's and rate this down somewhat ...

[sschmidt]

For the two problems mentioned in the initial post:

1. A cut on shat can be defined using the

   eval M [collect [particle]]
   

construct. I don't know if the average user will figure that out (Dirk, Juergen and I didn't). To me it seems reasonable to add a "shat" observable to make it easier.

2. Separating signal from background events can be achieved using a construct like

   analysis = if process_index == 1 then
           record signal_distribution ( ... )
           endif; if process_index == 2 then
           record background_distribution ( ... )
           endif;
   

However process_index is not mentioned in the manual.

So I'd find it desirable to do:

• implement "shat" to make cutting on shat easier
  
• mention in the manual that the event_vars can be used during simulation
  
• maybe implement another event_vars member like process_name that gives the name assigned in the process declaration to make the selection more readable:

  process signal = ... => ...
  process background = ... => ...
  ...
  analysis = if process_name == "signal" then
          record signal_distribution ( ... )
          endif; if process_name == "background" then
          record background_distribution ( ... )
          endif;
  

[Juergen Reuter]

Along the lines of #430...

[kilian]

done in r3760. The variables available in cut and analysis expressions are documented in the updated manual.

Since some of the variables have to be stored in the raw event files, I had to extend the raw event file format. This is reflected in a file format version that is checked when reading. For a compatibility mode, one may use $event_file_version.

[Juergen Reuter]

Milestone v2.0.8 deleted