Opened 9 years ago
Closed 9 years ago
#702 closed defect (fixed)
HepMC reading: recalculation of ME
Reported by: | kilian | Owned by: | kilian |
---|---|---|---|
Priority: | P0 | Milestone: | v2.2.5 |
Component: | core | Version: | |
Severity: | blocker | Keywords: | |
Cc: |
Description
This is unit test hepmc_7. Re-reading HepMC events, the recalculation of the matrix element crashes due to some missing data.
Change History (7)
comment:1 follow-up: 2 Changed 9 years ago by
comment:2 Changed 9 years ago by
Replying to jr_reuter:
What actually are the missing data?
Not entirely trivial:
| Rescanning unweighted events (process parameters updated) ... Runtime Error: mci_vamp.f90, line 1845: Reference to disassociated POINTER MCI%GRIDS%GRIDS Program terminated by fatal error mci_vamp.f90, line 1845: Error occurred in MCI_VAMP:MCI_VAMP_INSTANCE_COMPUTE_WEIGHT mci_base.f90, line 687: Called by MCI_BASE:MCI_INSTANCE_FETCH processes.f90, line 2498: Called by PROCESSES:PROCESS_MCI_ENTRY_RECOVER_EVENT processes.f90, line 1488: Called by PROCESSES:PROCESS_RECOVER_EVENT events.f90, line 673: Called by EVENTS:EVENT_RECALCULATE simulations.f90, line 1473: Called by SIMULATIONS:SIMULATION_RECALCULATE simulations.f90, line 1301: Called by SIMULATIONS:SIMULATION_RESCAN commands.f90, line 4341: Called by COMMANDS:CMD_RESCAN_EXECUTE commands.f90, line 5508: Called by COMMANDS:COMMAND_LIST_EXECUTE whizard.f90, line 438: Called by WHIZARD:WHIZARD_PROCESS_STREAM whizard.f90, line 413: Called by WHIZARD:WHIZARD_PROCESS_FILE main.f90, line 401: Called by MAIN Aborted (core dumped)
comment:3 Changed 9 years ago by
Priority: | P3 → P0 |
---|---|
Severity: | normal → blocker |
Distcheck fails with 4.7.4 BLOCKER!!!!
comment:4 Changed 9 years ago by
IF SOME PEOPLE WERE THINKING A BIT MORE THEY WOULD NOT PRODUCE SUCH A FUCKING HEAP OF STINKING GARBAGE!!!!
comment:5 Changed 9 years ago by
This even goes into VAMP:
Program received signal SIGSEGV, Segmentation fault. vamp_rest::vamp_probability (g=<error reading variable: Cannot access memory at address 0x0>, x=...) at vamp.f90:830 830 p = product (probability (g%div, x)) (gdb) bt #0 vamp_rest::vamp_probability (g=<error reading variable: Cannot access memory at address 0x0>, x=...) at vamp.f90:830 #1 0x00007ffff6791ed5 in mci_vamp::mci_vamp_instance_compute_weight (mci=..., c=1) at mci_vamp.f90:1845 #2 0x00007ffff6763920 in mci_base::mci_instance_fetch (mci=..., sampler=..., c=1) at mci_base.f90:687 #3 0x00007ffff60e9da0 in processes::process_mci_entry_recover_event (mci_entry=..., instance=..., i_term=1) at processes.f90:2498 #4 0x00007ffff60ea1cd in processes::process_recover_event (process=..., instance=..., i_term=1) at processes.f90:1488 #5 0x00007ffff62621a1 in events::event_recalculate (event=..., update_sqme=.TRUE., weight_factor=<error reading variable: Cannot access memory at address 0x0>, recover_beams=.FALSE.) at events.f90:673 #6 0x00007ffff6370db3 in simulations::simulation_recalculate (simulation=...) at simulations.f90:1475 #7 0x00007ffff63834ae in simulations::simulation_rescan (simulation=..., n=1, es_array=..., global=...) at simulations.f90:1301 #8 0x00007ffff6415fb8 in commands::cmd_rescan_execute (cmd=..., global=...) at commands.f90:4341 #9 0x00007ffff63ff35e in commands::command_list_execute (cmd_list=..., global=...) at commands.f90:5508 #10 0x00007ffff645909c in whizard::whizard_process_stream (whizard=..., stream=..., lexer=..., quit=.FALSE., quit_code=0) at whizard.f90:438 #11 0x00007ffff6458d7a in whizard::whizard_process_file (whizard=..., file=..., quit=.FALSE., quit_code=0) at whizard.f90:413 #12 0x00007ffff7d91712 in MAIN__ () at main.f90:401 #13 0x00007ffff7d925df in main (argc=<optimized out>, argv=<optimized out>) at main.f90:35 #14 0x000000319181ed5d in __libc_start_main () from /lib64/libc.so.6 #15 0x0000000000400729 in _start ()
comment:6 Changed 9 years ago by
Status: | new → assigned |
---|
The segfault produced by the gfortran-compiled exe is clearly caused by the bad pointer that NAG detected. I'll have a look now.
comment:7 Changed 9 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Was trivial after all: any event reader has to call event%set_weight_ref () at some point. This call was missing for HepMC. Added in r6552.
I assume that all HepMC events have weight 1 by definition, so the routine now is called with argument (1._default).
We might think of abusing the arbitrary extra weight containers that HepMC offers, for storing sqme values and such. Is there any convention for this?
@JR: what is the status with LCIO? At first glance, the same issue applies there.
What actually are the missing data?