next-exp/icaros

Krypton Calibrations

icaros's Issues

Fix time bin width

@ausonandres and I have been discussing time slices and we got to the conclusion it might be interesting to fix by default the time width as it is done in the current version of non-official time parameters (each time bin is 30 min) as a way of providing some consistency among different runs with their own duration. Is there anything we are missing in this argument?

Cleaning up the repository

I suggest the following course of action:

• Make version release for the current state of master (previous to the last commit that is breaking Travis).

• Merge KrCalib2.0 at and make a minor change tag.

This way all the notebook by @jjgomezcadenas, @jahernando and @jmhaefner can still be used with the corresponding version checkout.
The next steps will be:

• add tests to automatic_script and merge it to master asap

• open a PR that cleans up the code, removing all unnecessary functions, making sure the automatic script tests still work

• open smaller PRs to add missing test, maybe some useful functions that were removed during the cleaning ... etc

If nobody complains I will start the process later today :)

Failing tests

Running the tests for PR #44, it has been found that there are some of them that fail depending on where they are run. Then, this issue is meant to collect all the tests that suffer this problem.

• Every time Travis tests are run with MACOS, test_fit_slices_2d_gauss_fixed_example (in krcal.core.fit_functions_test.py) fails, however running this same test locally, or with Travis' Linux there are not any problems.

• Running the tests in neutrinos with a MACOS machine, test_fit_yields_expected_mean_std_and_chi2 (krcal.NB_utils.fit_energy_functions_test.py) also fails.

@mmkekic & @bpalmeiro will post as well the tests that fail in their cases.

Producing MC maps

The time-slicing, as it is now implemented, does not allow the production of MC maps, as all the time masks are filled with falses. So far, a local version commenting out all the selections seems to work.

Add new monitoring plots

As suggested by Pau, new monitoring plots may be added, as they are already computed. So, @mmkekic, @ausonandres, and I agreed to proceed the following way:

• Add plotting scripts already in use and convert them to functions in a new module in the map_builder folder.
• Add calls to this new functions and make sure code is adapted to this
• Get rid of the hist file nowadays is produced as it is only meant for monitoring purposes. This way, the plots stored in the folder will be created and stored anywhere else as convened by the script uploading them into the monitoring webpage.
• Add tests
  If no complaint, we will start a PR in order to make this happen. We are open to any suggestions about new plots or proceedings.