Further details
Using live points
Live points in nessai
are stored in numpy structured arrays. These are array have fields which can be accessed like the values of dictionaries but they can also be indexed. nessai
include various functions for constructing live point arrays and also converting these arrays to other common python formats, see mod:nessai.livepoint
Here’s an example of constructing a live point:
>>> from nessai.livepoint import parameters_to_live_point
>>> x = parameters_to_live_point([1, 2], ['a', 'b'])
>>> print(x) # the live point
(1., 2., 0., 0.)
>>> print(x.dtype.names)
('a', 'b', 'logP', 'logL')
>>> print(x['a']) # the value of parameter 'a'
1.0
Importantly the structured arrays used for live points can also contain multiple live points:
>>> from nessai.livepoint import numpy_array_to_live_points
>>> x = np.random.rand(10, 2) # 10 live points with 2 parameters
>>> print(x)
[[0.72451217 0.1788154 ]
[0.31549832 0.55898106]
[0.74000576 0.73103116]
[0.37362176 0.25791271]
[0.61056168 0.05940721]
[0.33988486 0.54106604]
[0.82653691 0.14523437]
[0.62390321 0.32606928]
[0.21743918 0.23915047]
[0.45478996 0.09699358]]
>>> y = numpy_array_to_live_points(x, ['a', 'b']) # call the parameters a and b
>>> print(y)
array([(0.72451217, 0.1788154 , 0., 0.), (0.31549832, 0.55898106, 0., 0.),
(0.74000576, 0.73103116, 0., 0.), (0.37362176, 0.25791271, 0., 0.),
(0.61056168, 0.05940721, 0., 0.), (0.33988486, 0.54106604, 0., 0.),
(0.82653691, 0.14523437, 0., 0.), (0.62390321, 0.32606928, 0., 0.),
(0.21743918, 0.23915047, 0., 0.), (0.45478996, 0.09699358, 0., 0.)],
dtype=[('a', '<f8'), ('b', '<f8'), ('logP', '<f8'), ('logL', '<f8')])
>>> y['a'] # all the values of a
array([0.72451217, 0.31549832, 0.74000576, 0.37362176, 0.61056168,
0.33988486, 0.82653691, 0.62390321, 0.21743918, 0.45478996])
>>> y[0] # the first live point
(0.72451217, 0.1788154, 0., 0.)
Using analytic priors
nessai
includes the option for sampling from analytic priors. This should be enabled when the method nessai.model.Model.new_point()
draws directly from the priors. This eliminates the need for additional rejection sampling to ensure new points are correctly distributed.
To use this setting, the user must re-define new_point
when defining the model as described in running the sampler. This method must return samples as live points, see using live points. Once the method is redefined, set analytic_priors=True
when calling FlowSampler
.
Checkpointing and resuming
Both the standard and importance nested samplers support checkpointing and resuming. By default, the samplers periodically checkpoint to pickle file based on the time elapsed since the last checkpoint. This behaviour can be configured via various keyword arguments.
Configuration
The following options are available in all the sampler classes:
checkpointing: bool
: Boolean to toggle checkpointing. If false, the sampler will not periodically checkpoint but will checkpoint at the end of sampling.checkpoint_on_iteration: bool
: Boolean to enable checkpointing based on the number of iterations rather than the elapsed time.checkpoint_interval: int
: The interval between checkpointing, the units depend on the value ofcheckpoint_interval
; if it false, is value the interval is specified in seconds; if it is true, the interval is specified in iterations.checkpoint_callback: Callable
: Callback function to be used instead of the default function. See Checkpoint callbacks for more details.
The following options are available when creating an instance of
FlowSampler
:
resume: bool
: Boolean to entirely enable or disable resuming irrespective of if there is a file or data to resume from.resume_file: str
: Name of the resume file.resume_data: Any
: Data to resume the sampler from instead of a resume file. The data will be passed to theresume_from_pickled_sampler
of the relevant class.
Resuming a sampling run
A sampling run can be resumed from either an existing resume file, which is loaded automatically, or by specifying pickled data to resume from. We recommended using the resume files, which are produced automatically, for most applications.
The recommended method for resuming a run is by calling FlowSampler
with
the same arguments that were originally used to start run; ensuring
resume=True
and resume_file
matches the name of the
.pkl
file in the output directory (the default is
nested_sampler_resume.pkl
).
Note
Depending on how the sampling was interrupted, some progress may be lost and the sampling may resume from an earlier iteration.
Alternatively, you can specify the resume_data
argument which takes
priority over the resume file.
This will be passed to the resume_from_pickled_sampler
of the
corresponding sampler class.
Checkpoint callbacks
Checkpoint callbacks allow the user to specify a custom function to use for checkpointing the sampler. This allows, for example, for the sampler to checkpoint an existing file rather.
The checkpoint callback function will be called in the checkpoint
method
with the class instance as the only argument, i.e.
checkpoint_callback(self)
.
All the sampler classes define custom __getstate__()
methods that are
compatible with pickle and can be used to obtain a pickled representation of
the state of the sampler. Below is an example of a valid callback
import pickle
filename = "checkpoint.pkl"
def checkpoint_callback(state):
with open(filename, "wb") as f:
pickle.dump(state, f)
This could then passed as a keyword argument when running or resuming a sampler
via FlowSampler
.
Warning
The checkpoint callback is not included in the output of __getstate__
and must be specified when resuming the sampler via FlowSampler
.
Detailed explanation of outputs
Note
This section has not been completed yet