whizard is hosted by Hepforge, IPPP Durham

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 Changed 9 years ago by Juergen Reuter

What actually are the missing data?

comment:2 in reply to:  1 Changed 9 years ago by kilian

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 Juergen Reuter

Priority: P3P0
Severity: normalblocker

Distcheck fails with 4.7.4 BLOCKER!!!!

comment:4 Changed 9 years ago by Juergen Reuter

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 Juergen Reuter

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 kilian

Status: newassigned

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 kilian

Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.