'Cannot allocate memory' situation for large decays

[Juergen Reuter]

Lukas Mitzka reported for a SARAH-generated model file of an extended SUSY model, that in the process of event generation, the C system library could not allocate memory. This is possibly due to an overflow of a matrix element counter. cf. below

[Juergen Reuter]

In qft.nw, the following code lines:

  subroutine evaluator_init_qn_sum (eval, int, qn_mask, drop)
    ...
    n_me_old = int%get_n_matrix_elements ()
    allocate (pairing_proto(n_me_old, n_me_old))
    ...

are screweg up, the variable N_ME_OLD gets the value 69632, which leads to a crash. Hence, get_n_matrix_elements() doesn't deliver the correct values.

Debug output:

 ...
 [tho] subroutine simulation_generate ():           13  of        25000
 [tho] evaluator_init_qn_sum: allocate (pairing_proto) success: n_me_old =           17
 [tho] subroutine simulation_generate ():           14  of        25000
 [tho] evaluator_init_qn_sum: allocate (pairing_proto) success: n_me_old =           68
 [tho] subroutine simulation_generate ():           15  of        25000
 [tho] evaluator_init_qn_sum: allocate (pairing_proto) success: n_me_old =           68
 [tho] subroutine simulation_generate ():           16  of        25000
 [tho] evaluator_init_qn_sum: allocate (pairing_proto) success: n_me_old =           17
 [tho] subroutine simulation_generate ():           17  of        25000
 [tho] function state_matrix_get_n_matrix_elements () =>         8704
 [tho] function state_matrix_get_n_matrix_elements () =>         8704
 [tho] evaluator_init_qn_sum: allocate (pairing_proto) success: n_me_old =         4352
 [tho] subroutine simulation_generate ():           18  of        25000
 [tho] evaluator_init_qn_sum: allocate (pairing_proto) success: n_me_old =           68
 [tho] subroutine simulation_generate ():           19  of        25000
 [tho] evaluator_init_qn_sum: allocate (pairing_proto) success: n_me_old =          272
 [tho] subroutine simulation_generate ():           20  of        25000
 [tho] function state_matrix_get_n_matrix_elements () =>         8704
 [tho] function state_matrix_get_n_matrix_elements () =>         8704
 [tho] function state_matrix_get_n_matrix_elements () =>        17408
 [tho] function state_matrix_get_n_matrix_elements () =>        17408
 [tho] function state_matrix_get_n_matrix_elements () =>         8704
 [tho] function state_matrix_get_n_matrix_elements () =>        34816
 [tho] function state_matrix_get_n_matrix_elements () =>        34816
 [tho] function state_matrix_get_n_matrix_elements () =>        17408
 [tho] function state_matrix_get_n_matrix_elements () =>        69632
 [tho] function state_matrix_get_n_matrix_elements () =>        69632
 [tho] function state_matrix_get_n_matrix_elements () =>        34816
 [tho] function state_matrix_get_n_matrix_elements () =>       139264
 [tho] function state_matrix_get_n_matrix_elements () =>       139264
 [tho] function state_matrix_get_n_matrix_elements () =>        69632
 [tho] evaluator_init_qn_sum: allocate (pairing_proto) failed: n_me_old =        69632

[Juergen Reuter]

This is TO's dump of the process

[Juergen Reuter]

Seems that this is a 2->32 process.... seriously?

[kilian]

@tho: thanks for the debugging info.

This is not a 2->32 process, it is the state matrix for a decay chain.

There is, first, the decay algorithm that accumulates all possible branches and thus lets the state matrix grow and grow. However, the size of 69632 should not pose a problem, maybe an inefficiency.

But then this pairing_proto array is allocated with the number of matrix elements squared. Crash.

It should be possible to avoid an array with the size squared. I'll try.

[kilian]

Should be fixed in r7009. Simplified the caching for the pairing algorithm in evaluator_init_qn_sum.