Error calculating Fisher information in MadMiner(v0.9.3)

[roshan-mammen-abraham]

Error calculating Fisher information in MadMiner(v0.9.3)

[roshan-mammen-abraham]

Hello,

Thank you for the resonse. Regarding In 4b_fisher_information, while loading the "lhe_data_shuffled.h5" it says "Did not find nuisance morphing setup" I mentioned it only as I had thought it could be a cause for the latter issue. Nothing more.

Thank you.

[Sinclert]

👋🏻 Hi Roshan.

Thanks for reporting all these problems. I will address them in order:

---

In 2A_parton_level_analysis, while loading the "setup.h5" file it throws some errors (attached screenshots). I am not explicitly setting any nuisance parameters for systematics.

These error messages are "expected". When MadMiner jumped from version 0.8.3 to 0.9.0 a huge refactor of the HDF5 interface was made (see this PR for complete context), and these messages were introduced. This was done in order to add visibility when the MadMiner.load method call the load_madminer_settings function (reference) to load settings from a HDF5 file, as it eagerly tries to load every possible setting.

I see how labelling these messages as ERROR is confusing. They should be INFO messages.

---

In 4b_fisher_information, while loading the "lhe_data_shuffled.h5" it says "Did not find nuisance morphing setup".

That is expected, and as far as I know, that part of the code preserves the same behaviour has < 0.9.0 versions.

Could you elaborate on why this behaviour surprised you?

---

It then fails at the fisher.histo_information function.

This is the real bug 🐛

I can see that on MadMiner v0.8.3 the DataAnalyzer class was hardcoding False for its include_nuisance_parameters attribute when there were no nuisance parameters (reference), serving as a safe-guard for avoiding nuisance_morpher withing the FisherInformation class (reference).

Even if this approach is the one @rbarrue mentioned on Gitter as option A to fix the problem, it does not feel natural to me, as the class would be overriding the value the user provided, which is not good for traceability purposes.

I will think about a solution to this problem that does not involve overriding the user input.

[rbarrue]

I believe we could start with a controlled crash with a message informing that the settings should be consistent, e.g. "you asked for systematics, but did not define any in your setup file, confirm your settings and rerun. Exiting..."

@Sinclert is this how it's done in the SW dev. world ?

[Sinclert]

I proposed a fix in PR #519. @rbarrue check the description + code changes for the details.

[rbarrue]

Looks great, thanks for the ping @Sinclert !

[Sinclert]

Just released version 0.9.5 with the fix.

I will close this issue for now. Feel free to open it if the problem persist.