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
comment:2 Changed 15 years ago by
Milestone: | v2.0.0final → v2.0-rc4 |
---|
comment:3 Changed 15 years ago by
Milestone: | v2.0-rc4 → v2.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
Component: | documentation → vamp |
---|---|
Owner: | changed from ALL to ohl |
comment:5 Changed 15 years ago by
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
Milestone: | v2.0.0final → v2.0.1 |
---|
Sorry, this will have to be fixed in milestone:2.0.1 (where #2 is due anyway).
comment:8 Changed 15 years ago by
Try around a little bit: it is easy to reproduce, e.g. set the iterations to 30:1000.
comment:10 Changed 15 years ago by
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
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
Milestone: | v2.0.1 → v2.1 |
---|---|
Status: | new → assigned |
Summary: | Catch NaNs in the efficiency calculation in VAMP → VAMP: 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
Milestone: | v2.1.0 → v2.1.1 |
---|
comment:14 Changed 14 years ago by
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
Milestone: | v2.1.1 → golden-classics |
---|
wait for proper IEEE/2003 implementations ...
comment:16 Changed 13 years ago by
Priority: | P3 → P5 |
---|---|
Severity: | normal → trivial |
Type: | defect → enhancement |
comment:17 Changed 11 years ago by
-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
Component: | vamp → documentation |
---|---|
Milestone: | golden-classics → v2.2.0 |
Owner: | changed from ohl to Juergen Reuter |
Priority: | P5 → P4 |
Status: | assigned → new |
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
Status: | new → assigned |
---|
comment:20 Changed 11 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Part of the manual in r5736. Closing.
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?: