Hello,

I noticed that Vevacious takes the potential to be minimized and creates a related rescaled potential (the arguments are divided by the energy scale and the returned value is divided by that scale to the fourth so that all the quantities are dimensionless) that is the one actually fed to Minuit. Also, the value of the potential at the origin is subtracted from the original function. Is there any rationale behind this choice?

I would expect that one should get the same results working with the dimensionfull potential function, which has the same minima. I checked this starting from a particular tree level minimum and I found that Vevacious does not roll to the same point. In this particular case, the value of the potential between the two minima was comparable to the quantity 'Minuit error', but I am not sure why this should always be the case.

Also, when minimizing a potential with rescaled arguments but dimensional return value, it rolled to a completely different point different point.

Maybe I am doing something wrong, but I hope I can understand the reason for the strategy followed in the code.

Thank you,

Francesc Ferrer

Yes, I expected that it would be fine to leave it in units of GeV too, but it did make a difference. I found that the documentation about initial step sizes and so forth was really rather unhelpful. There's apparently some step-size optimization that goes on internally as well, and it just seems to me that everything is tweaked to do a good job for numbers basically up to 10 or so. To the best of my understanding, by the way, MINUIT feels that it is close enough to the minimum when estimates that the depth of where it is, is within 'Minuit error' of what it guesses is the depth of the minimum (probably from approximating the function locally as quadratic in all arguments). I've never looked deeply into the MINUIT source code though.

I don't know exactly how you implemented the changes to the code (but I am glad that you did experiment!), but one has to be very careful about the renormalization scale as well. I set it up so that the same number was used for both re-scaling the field values AND as the renormalization scale used in the loop corrections. This might be the source of the odd behavior.

Oh, also the value of the loop corrections at the origin is subtracted for 2 reasons:
1: again, MINUIT seems to like numbers less than 10, and seems to do best when relative differences are order 1 (doesn't do well on differences of 10^4 GeV^4 differences on an absolute value of 10^13 GeV^4)
2: humans understand the values better if the large constant is removed, too.

Regards,
Ben

What I did is to replicate the steps of Vevacious.py within ipython. I am writing a python notebook that I'll post shortly. Thanks for your reply!

I am attaching the input slha file that I used to generate Vevacious.py and VevaciousParameterDependent.py and the ipython notebook with the comparison of the minimization with and without rescaling (had to add .txt extension otherwise it would not let me upload, just remove that). I'll extend it with other checks, but I thought you might want to see how I'm doing things in case I'm doing something wrong.

Thanks a lot,
Francesc

I tried a few more variations of the target function to minimize and I am attaching a more complete notebook. It seems that one can roll to a completely different minimum if either the function or the arguments are not rescaled or if the value at the origin is not subtracted.

These different minima are similar to others in the list (where Vevacious presumably rolled from other initial points), but I am a bit worried that this might not always be the case. I can try other initial points of the list of initial tree level minima.

Best,
Francesc