Hi Valentin,

Thanks a lot for those very useful comments.
And for the time on Skype. I'm so happy that it is working on your computer now.


 > But the problem is that if I set it to false then it will still be
> automatically be reassigned to True if I try to launch again. The user will
> certainly don't expect his run_card.dat to be changed on his behalf when it
> does a new run.
> So I'm not sure I like this behavior....

Ok you have a point, I will not do that then.

I have then apply the following.
When the user quit the edition of the card interface. 
I check the consistency between the run_card and the reweight_card. and if the user request explicitly the NLO reweighting type, then I force the keep_rwgt_info to True.

I have modified the default reweight_card to always request explicitly the NLO accurate reweighting.
Such that by default, I have the same behavior.


> The cross-sections aren't identical, so this is purely an effect of the
> kamikaze reweighting right?

No you also have an statistical effect. Even if you set all the reweighting factor to be 1
(which is the case of your kamikaze in this case) you will face that the sum of the weights is not equal to the cross-section. This is an effect partly due to the of the negative weights.

Since kamikaze reweighting
> is so fast, I would consider to *always* use this "central reweighting" so
> as to be able to automatically provide the user with an assessment of how
> reliable he can expect the kamikaze reweighting to be for this case.

This is equivalent to simply compute the sum of the weights (up to normalisation) which is ... so much faster than running such kamikaze reweighting. Printing the sum of the weights for the sample is actually an interesting idea.
  
> Unfortunately, it still crashes at compilation time when doing the exact
> reweighting with lhapdf reweighting. The error being:

Ok we will need to settle that via Skype.


> Ok, that would do I guess. So how would a user do a reweight in LO mode
> with an event that *includes the extra weight*?

You have to put in your reweight_card the line
change mode LO
The fact that the line 
"change mode NLO" is now present by default in the reweight_card should clear your confusion on this.

> Also, speaking of this command, its help is a bit minimal, i.e.:
> 
>  PROCNLO_loop_sm_3>help reweight
>  Allow to reweight the events generated with a new choices of model
>             parameter.

OK DONE
 
> And its auto-completion is broken (with a debug statement left in by the
> way).

OK DONE
 
> Sure this is why I stressed *relative* error. All my comments above
> referred to a *relative* error, so please reconsider my comments with that
> in mind.
> I think this goes along the way of giving more info to the user on the
> reliability of the reweighting

I think that this is too much. They have the information printed it should be the user task to check if it looks correct or not. Actually I do not trust that much the error quoted but this is the best estimator that I have found. 

> Did you check this out?
> http://stackoverflow.com/questions/10929162/how-can-i-catch-a-seg-fault-while-
> importing-an-f2py-module


Just did and this is an invalid/unsave syntax (you can read this topic for more information:
http://bugs.python.org/issue1215)

>  Doesn't seem to work for me. I can try to turn off lhapdf all I want, it
> will still try to do exact reweighting (if I have keep_weight=true in the
> run_card) and crash when trying to compile with lhapdf...

I think you are confused here.
Your events can be generated either with internal pdf or lhapdf. Both are fine.
But the reweighting will always use LHAPDF. So in order to turn-off lhapdf you need to set it to None in the mg5_configuration.txt.

>  Maybe then one could automatically produce a plot
> that overlays the curves of the first few extra weights when present?

Actually why not. But we should do that together then.


> I simply meant to call this initialization before your start the
> reweigthing so as to have the HelFilter and LoopFilter ready already and a
> nice error message if there is a problem at this level.
> But it's not crucial, it will do it automatically anyway, but I typically
> find it best to do it as part of some setup than we the first event that
> come in for the reweighting.

Since this follows closely the standalone setup, then I guess it is done...

> I guess just bypass this attempted recovery on linux, because it would
> anyway crash right away on this and the LINUX user would be confused seeing
> that MG5aMC tries to access a .dylib no?

DONE.

> Wait, don't you need to evaluated the ratio at the same renormalization
> scale as the one specified in the event record?

As long as it is the same for both matrix-element, it should be enough.
I agree that it will be safer, I will look how difficult it is to do it.


Thanks so much,


Olivier