astrojarred/grbsens

Pipeline to run ctools' cssens on different models in parellel.

grbsens's Issues

Implement parallelization

Implement parallelization, specifically in the execute function of the grb class.

• Use with python's built-in multiprocess tool
  • See some multiprocess notes here
• Or use with ctools built-in parallelization commands?

Evaluate the run time of various simulations

Once parallelization is set up (issue #1), evaluate the runtime of simulations of various observation durations.

• use the timeit python package

Automatically create output folders

Currently, if the output and log folders do not exist, it raises an error. This is especially a problem when running in parallel where it just starts lagging.

Solution:
Automatically create the folders if the do not already exist.

Use gammapy

Use gammapy instead of ctools.

Add a visual progress bar

Add a progress bar with the tqdm package.

It would have to play nice with multiprocessing as well as work in both the notebook and command line.

Add variable time step

Since the range of times that will be looped over is quite large (e.g. four orders of magnitude), we need to implement a variable time step.
Possible solutions include:

• Add a log time step (easy, consistent, but not that flexible)
• Specify regions in the time domain and what the time step should be in each region
• both

Fluctuations in the sensitivity vs time output curves

We've seen some strange fluctuations in the grbsens output.

For example, here are the sensitivities with integration times from 1-60s using the North_z60_0.5h IRF:

There is a strange dip from 8-9s and again from 16-17s. In crosschecks by others, this issue has not been encountered.

I have a hunch it might have something to do with ctools and python's multiprocessing package together, as I've noticed the two don't always play nice together.

I plan to run the following tests in order to better understand the situation:

• Try running the setup exactly as is on a different machine
• Try running the same setup in series on the both the same and different machines
• Try rewriting the parallelization using the ray package

Update output csv formatting

Update formatting to match original outputs form B. Patricelli.

• include units in comment line
• spaces, not commas
• remove unnecessary information
• change order of columns

Give custom names for ctools output and log files

Now if you run a simulation in the same cwd, cssens output and log files will get overwritten. This isn't great if you're running multiple similar simulations in a loop (i.e. changing one input parameter).

Let's try and add the ability to name output files manually.

Perhaps the same string can be used for both the ctools automatic outputs as for the grbsens table outputs.

Add command line functionality

What the title says. Right now, a series of functions must be called, but it would be nice to add a command line functionality as well.

Update documentation

In the documentation, include:

• installation instructions
• overview of simulation chain and outputs
• use cases
• user functions, their input parameters and outputs

Render the plotting feature more versatile

Currently there is a very simple plot_results function. Ideally you could:

• select what to plot on the axes
• select the scale of the axis (linear or log)

Add a log-scale timestep.

Following Issue #3, it might be useful to add an automatic log-scale time step. Perhaps the user would need to specify how many simulations to calculate within each decade.

Load results from file instead of executing simulations again

Sometimes if you're running a large number of different simulations, some have already been run another time. Or maybe you just want to reload the classes for plotting purposes.

Add a read_results or load_results option to grb.execute in order to read the a csv file matching the outfile name.

Broken handling input parameters

When setting the trio of input parameters related to the time steps, namely num_jobs, total_time and delta_t, there should be a more consistent check between the three.

Possible solutions include:

• Update the input checks
• Remove the num_jobs parameter (leave it to be inferred by the user)
  • In any case, this might get confusing once parallelization is implemented (See #1)