Scan over varying cuts doesn't work.

[kilian]

A construct such as

scan real ptcut = (10, 20, 30) {
   integrate (foo) { cuts = all Pt > ptcut [...] }
}

doesnt' work; the r.h.s. of the cuts assignment is evaluated only once.

(This needs to be checked!)

[Juergen Reuter]

Since this is a possible bug, should be the next one.

[Juergen Reuter]

Confirmed this. Take the example:

model = SM

process foo = e1, E1 => e2, E2

compile 

sqrts = 500 GeV

 scan real ptcut = (200,220,240) {
      integrate (foo) { cuts = all Pt > ptcut [e2] }
 }

The values for the cross sections are 215 fb, 164 and 92 fb. Only the first value of the cuts is taken in the scan loop.

[Juergen Reuter]

Funnily, this works as intended:

model = SM

process foo = e1, E1 => e2, E2

compile 

sqrts = 500 GeV

 scan real ptcut = (200,220,240) {
      cuts = all Pt > ptcut [e2]
      integrate (foo) 
 }

[kilian]

That was a red herring.

It doesn't matter whether it's a scan or an explicit list, or where the cut assignment is located.

The real point is: in the first run, all is well, but when the results are read from file, the system doesn't notice the change of cuts and just repeats the last result over and over. It's clear why: The expression defining the cuts doesn't change, and this is used for determining whether cuts have changed. The numerical value ptcut is not part of the cut definition.

So, we learn that the MD5sum for cuts has to include the numerical values. It would also be helpful to have tags for individual runs.

[Juergen Reuter]

I also recognized that recently that even without a scan changing the cuts is not recognized by WHIZARD and the grids are not redone.

[kilian]

OK, the immediate fix turned out to be simple. Done in r3112.

Independently, it would be useful to store/retrieve grids for individual runs, not just one per process.