whizard is hosted by Hepforge, IPPP Durham

Opened 15 years ago

Closed 11 years ago

#234 closed enhancement (fixed)

VAMP: properly handle IEEE exceptional values produced by the sampling function

Reported by: Juergen Reuter Owned by: Juergen Reuter
Priority: P4 Milestone: v2.2.0
Component: documentation Version: 2.0.0rc2
Severity: trivial Keywords: DOKU
Cc:

Description

Using the input file (much the same as for #232)

process proc3 = g, g -> g, g
compile
sqrts = 7 TeV
integrate (proc3) { iterations = 10:10000 }

produces

| Loading process library 'processes'
| Process 'proc3': updating configuration
sqrts =    7000.0000000000000     
| Integrating process 'proc3'
| Generating phase space configuration ...
| ... found 5 phase space channels.
| Wrote phase-space configuration file 'proc3.phs'.
Warning: No cuts have been defined.
| Using partonic energy as event scale.
| iterations = 10:10000
| Creating grids
| 10000 calls, 5 channels, 2 dimensions, 20 bins, stratified = T
|=============================================================================|
| It      Calls  Integral[fb]  Error[fb]   Err[%]    Acc  Eff[%]   Chi2 N[It] |
|=============================================================================|
   1      10000  7.2964767E+11  4.13E+11   56.55   56.55*   0.07
   2      10000  7.3067373E+11  4.13E+11   56.47   56.47*   0.05
   3      10000  7.3072496E+11  4.13E+11   56.47   56.47*   0.05
   4      10000  7.3083000E+11  4.13E+11   56.46   56.46*   0.03
   5      10000  7.3083016E+11  4.13E+11   56.46   56.46*   0.05
   6      10000  7.3093205E+11  4.13E+11   56.45   56.45*   0.00
   7      10000  7.3093353E+11  4.13E+11   56.45   56.45*   0.01
   8      10000  7.3093361E+11  4.13E+11   56.45   56.45*   0.04
   9      10000  7.3093397E+11  4.13E+11   56.45   56.45*   0.01
  10      10000  7.3093398E+11  4.13E+11   56.45   56.45*   0.06
|=============================================================================|
  10     100000  7.3073737E+11  1.30E+11   17.86   56.47    0.06    0.00  10
|=============================================================================|
| Process 'proc3': time estimate for 10000 unweighted events = 0h 18m 12s
|-----------------------------------------------------------------------------|
| Contributing Helicity Combinations:     6 of    16
| Threshold: amp / avg >  0.22E-05 =  0.10E+11 * epsilon()

OK, there are no cuts, so it is clear that this academically partonic process cannot integrate very well, but at least this should be documented somehow.

Change History (20)

comment:1 Changed 15 years ago by Juergen Reuter

This should be rechecked with the NAG compiler. Basically the reason for it is that there are no more any magical cuts as in WHIZARD 1. But nevertheless it should not run into NaNs?. And actually here is an example with NaNs?:

| Loading process library 'processes'
| Process 'proc3': updating configuration
sqrts =    7000.0000000000000     
| Integrating process 'proc3'
| Generating phase space configuration ...
| ... found 5 phase space channels.
| Wrote phase-space configuration file 'proc3.phs'.
Warning: No cuts have been defined.
| Using partonic energy as event scale.
| iterations = 10:10000
| Creating grids
| 10000 calls, 5 channels, 2 dimensions, 20 bins, stratified = T
|=============================================================================|
| It      Calls  Integral[fb]  Error[fb]   Err[%]    Acc  Eff[%]   Chi2 N[It] |
|=============================================================================|
   1      10000  4.9068761E+11  1.55E+11   31.61   31.61*   0.10
   2      10000  4.9245669E+11  1.55E+11   31.50   31.50*   0.05
   3      10000  4.9538494E+11  1.55E+11   31.31   31.31*   0.04
   4      10000  4.9549916E+11  1.55E+11   31.30   31.30*   0.06
   5      10000  4.9549917E+11  1.55E+11   31.30   31.30*   0.05
   6      10000  4.9550026E+11  1.55E+11   31.30   31.30*   0.00
   7      10000  4.9550113E+11  1.55E+11   31.30   31.30*   0.00
   8      10000  4.9550119E+11  1.55E+11   31.30   31.30*   0.01
   9      10000  4.9550119E+11  1.55E+11   31.30   31.30*   0.06
  10      10000  4.9550119E+11  1.55E+11   31.30   31.30*    NaN
|=============================================================================|
  10     100000  4.9470337E+11  4.90E+10    9.91   31.35     NaN    0.00  10
|=============================================================================|
| Process 'proc3':
|    time estimate for 10000 unweighted events = 0h 14m 14s
|-----------------------------------------------------------------------------|

comment:2 Changed 15 years ago by Juergen Reuter

Milestone: v2.0.0finalv2.0-rc4

comment:3 Changed 15 years ago by Juergen Reuter

Milestone: v2.0-rc4v2.0.0final

The NaN comes from the vamp_grids%grids%mu data type. I will debug it once VAMP is there in its final form.

comment:4 Changed 15 years ago by Juergen Reuter

Component: documentationvamp
Owner: changed from ALL to ohl

comment:5 Changed 15 years ago by Juergen Reuter

If there is no comment until 1800 GST+0100 about this, this ticket will be moved to 2.0.1 and the trunk closed w.r.t. to this task.

comment:6 Changed 15 years ago by ohl

Milestone: v2.0.0finalv2.0.1

Sorry, this will have to be fixed in milestone:2.0.1 (where #2 is due anyway).

comment:7 Changed 15 years ago by ohl

Currently, I can NOT reproduce this with gfortran/64bit.

comment:8 Changed 15 years ago by Juergen Reuter

Try around a little bit: it is easy to reproduce, e.g. set the iterations to 30:1000.

comment:9 Changed 15 years ago by ohl

I see.

comment:10 Changed 15 years ago by Juergen Reuter

TO, maybe if you have a look at the calculation of the efficiency, you could already have in mind the possibility of negative weights (i.e. indefinite integration functions).

comment:11 Changed 15 years ago by Juergen Reuter

Summary: Adaption freezes and runs finally into a NaN (with gfortran)Catch NaNs in the efficiency calculation in VAMP

comment:12 Changed 15 years ago by ohl

Milestone: v2.0.1v2.1
Status: newassigned
Summary: Catch NaNs in the efficiency calculation in VAMPVAMP: properly handle IEEE exceptional values produced by the sampling function

The NaNs in question are not generated by VAMP, but are produced by the function being sampled. As mentioned above, this is caused by missing cuts and integrating a singular region.

There is no reason to catch these NaNs in the efficiency calculation.

At the moment they are reported as a negative weight (since "NaN > 0" is false per IEEE standard), but WHIZARD doesn't check the corresponding exception. Once the optional IEEE modules of Fortran 2003 are widely available, I can check portably and reliably for NaNs and !Infinity and handle both properly. I could test for "x != x" but that's a hack.

I leave this open for milestone:v2.1.

comment:13 Changed 14 years ago by Juergen Reuter

Milestone: v2.1.0v2.1.1

comment:14 Changed 14 years ago by Juergen Reuter

Do we check for IEEE functions in the configure, actually? So we could screen over the status within the compiler world. As TO started to implement IEEE checks in VAMP, maybe we could boost this ticket a little bit.

comment:15 Changed 13 years ago by ohl

Milestone: v2.1.1golden-classics

wait for proper IEEE/2003 implementations ...

comment:16 Changed 13 years ago by ohl

Priority: P3P5
Severity: normaltrivial
Type: defectenhancement

comment:17 Changed 11 years ago by Juergen Reuter

-ffpe-trap=invalid,zero,overflow is the gfortran compiler to do this. This should be mentioned in the manual.

comment:18 Changed 11 years ago by Juergen Reuter

Component: vampdocumentation
Milestone: golden-classicsv2.2.0
Owner: changed from ohl to Juergen Reuter
Priority: P5P4
Status: assignednew

It has been agreed upon to do mention this in the manual, but not to set it as a default. Will do that soon.

comment:19 Changed 11 years ago by Juergen Reuter

Status: newassigned

comment:20 Changed 11 years ago by Juergen Reuter

Resolution: fixed
Status: assignedclosed

Part of the manual in r5736. Closing.

Note: See TracTickets for help on using tickets.