Problem with static variables in standalone_cpp

Hi,

> the problem is that the second time the function is being called, the static members already exist in the memory and the 0s are not being assigned as the constructors are not called.

That's exactly the expected behavior that we want for those three variables.

But by looking at that code, I'm surprise to see the line:
sum_hel = min(sum_hel, ngood);
while I would have expect
sum_hel = max(sum_hel, ngood);
This forces sum_hel to always stay at zero and therefore you never pass by the optimized part (summing only on the non zero helicities.

So clearly, I don't understand what your problem is.

Cheers,

Olivier

On Nov 27, 2013, at 6:50 PM, Aurelijus Rinkevicius <email address hidden> wrote:

> Public bug reported:
>
> In some cases while using standalone_cpp classes multiple times, the
> static variables start to cause problems. In particular, the following:
>
> in void CPPProcess::sigmaKin() { ...
> static int ntry = 0, sum_hel = 0, ngood = 0;
> ...}
>
> the problem is that the second time the function is being called, the static members already exist in the memory and the 0s are not being assigned as the constructors are not called. The possible solution could be:
> static int ntry, sum_hel, ngood;
> ntry = 0, sum_hel = 0, ngood = 0;
>
> ** Affects: madgraph5
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are a member of MadTeam,
> which is subscribed to MadGraph5.
> https://bugs.launchpad.net/bugs/1255632
>
> Title:
> Problem with static variables in standalone_cpp
>
> Status in The MadGraph Matrix Element Generator version 5:
> New
>
> Bug description:
> In some cases while using standalone_cpp classes multiple times, the
> static variables start to cause problems. In particular, the
> following:
>
> in void CPPProcess::sigmaKin() { ...
> static int ntry = 0, sum_hel = 0, ngood = 0;
> ...}
>
> the problem is that the second time the function is being called, the static members already exist in the memory and the 0s are not being assigned as the constructors are not called. The possible solution could be:
> static int ntry, sum_hel, ngood;
> ntry = 0, sum_hel = 0, ngood = 0;
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/madgraph5/+bug/1255632/+subscriptions

Hi Olivier,

The reason I wrote is the following:
If I change the model on the fly, say by using void CPPProcess::initProc(string param_card_name) and providing a new parameter file with different couplings set, I can arrive at a point, where the new calculations will be spoiled by the previous set of couplings, because of this memory effect.

In other words,
CPPProcess.initProc( "couplings1.dat" );
CPPProcess.sigmaKin();
.....
CPPProcess.initProc( "couplingsN.dat" );
CPPProcess.sigmaKin();

sequence may go wrong for some coupling combinations. In fact, this is exactly what I observe that some models are execution-order dependent.

Best,
Aurelijus

Let me try to isolate the problem just to be sure what's going on and if everything is fine. Thanks!

OK, here it is.

It matters which param_card is executed first. Simple renaming makes the difference. Here is what I get:
Scenario 1:
HEF_MEKD model couplings dependent on event kinematics:
 Matrix element = 7.6843276244561995e+21 GeV^-4
 -----------------------------------------------------------------------------
Opened slha file ../../Cards/param_card2.dat for reading
 Matrix element = 1.0168662873739916e-08 GeV^-4

Scenario 2:
HEF_MEKD model couplings dependent on event kinematics:
 Matrix element = 1.2856820372959568e-07 GeV^-4
 -----------------------------------------------------------------------------
Opened slha file ../../Cards/param_card2.dat for reading
 Matrix element = 7.6843276244561995e+21 GeV^-4

One calculation stays stable, while the other changes wrt execution order. In some cases, the effects are even more pronounced than here and can differ in many orders.

Hi,

I understand your problem but I'm not sure how to fix it. Since your fix is everything but efficient.
using ntry = 0 each time you call the matrix element slows down the code significantly since you compute again and again vanishing helicities.

I can see two possibilities:
1) if you make some sequential run (all call for one param_card, then all call for the second one) then we can include an option "reset".
2) if you call those in parralel, the correct way would be to modify the class to have those optimization variable linked to each param_card.dat (one way is to have one instance by param_card)

Cheers,

Olivier

Hi,

You are right about the optimization, loosing it is also not a victory. However, I have an option 3):

3) Why not to make the variables private in the whole class and then simply reset them inside CPPProcess::initProc(). They don't have to be static.

BTW, there is a problem with your 2) suggestion. The problem is that the static variables jump out of the object and will have a cross-talk in parallel calls, i.e., while declaring CPPProcess Model_1, Model_2; these two objects, Model_1 and Model_2 will see each other static variables as the statics are shared accross the same-type class and its derivatives (methods). Also, this is exactly where I have encountered the problem the first time and got surprised of this interference.

Option 3) would provide two benefits: (1) calling initProc() would reset a model, (2) there would be no interference (memory sharing) between the same-type class objects. Hope it makes sense.

Best regards,
Aurelijus

Hi,

Actually your solution 3) is what I was thinking for the solution 2)
But I'm a noob in C++, (The author of that part unfortunately left physics).
So I'll read a C++ manual before implementing the fix.
If you don't mind, I'll ask you to review my modification.

Cheers,

Olivier

On Dec 8, 2013, at 2:21 PM, Aurelijus Rinkevicius <email address hidden> wrote:

> Hi,
>
> You are right about the optimization, loosing it is also not a victory.
> However, I have an option 3):
>
> 3) Why not to make the variables private in the whole class and then
> simply reset them inside CPPProcess::initProc(). They don't have to be
> static.
>
> BTW, there is a problem with your 2) suggestion. The problem is that the
> static variables jump out of the object and will have a cross-talk in
> parallel calls, i.e., while declaring CPPProcess Model_1, Model_2; these
> two objects, Model_1 and Model_2 will see each other static variables as
> the statics are shared accross the same-type class and its derivatives
> (methods). Also, this is exactly where I have encountered the problem
> the first time and got surprised of this interference.
>
> Option 3) would provide two benefits: (1) calling initProc() would reset
> a model, (2) there would be no interference (memory sharing) between the
> same-type class objects. Hope it makes sense.
>
>
> Best regards,
> Aurelijus
>
> --
> You received this bug notification because you are a member of MadTeam,
> which is subscribed to MadGraph5.
> https://bugs.launchpad.net/bugs/1255632
>
> Title:
> Problem with static variables in standalone_cpp
>
> Status in The MadGraph Matrix Element Generator version 5:
> New
>
> Bug description:
> In some cases while using standalone_cpp classes multiple times, the
> static variables start to cause problems. In particular, the
> following:
>
> in void CPPProcess::sigmaKin() { ...
> static int ntry = 0, sum_hel = 0, ngood = 0;
> ...}
>
> the problem is that the second time the function is being called, the static members already exist in the memory and the 0s are not being assigned as the constructors are not called. The possible solution could be:
> static int ntry, sum_hel, ngood;
> ntry = 0, sum_hel = 0, ngood = 0;
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/madgraph5/+bug/1255632/+subscriptions