aspecd.tasks module

Constituents of a recipe-driven data analysis.

One main aspect of tasks is to provide the constituents of a recipe-driven data analysis, i.e. aspecd.tasks.Recipe and aspecd.tasks.Chef. In its simplest form, a recipe gets cooked by a chef, resulting in a series of tasks being performed on a list of datasets.

From a user’s perspective, a recipe is usually stored in a YAML file. This allows to easily create and modify recipes without knowing too much about the underlying processes. For an accessible overview of the YAML syntax, see the introduction provided by ansible .

Recipe-driven data analysis by example

Recipes always consist of two major parts: A list of datasets to operate on, and a list of tasks to be performed on the datasets. Of course, you can specify for each task on which datasets it should be performed, and if possible, whether it should be performed on each dataset separately or combined. The latter is particularly interesting for representations (e.g., plots) consisting of multiple datasets, or analysis steps spanning multiple datasets.

To give a first impression of how such a recipe may look like:

datasets:
  - loi:xxx
  - loi:yyy

tasks:
  -
    kind: processing
    type: ProcessingStep
    properties:
      parameters:
        param1: bar
        param2: foo
      prop2: blub
  -
    kind: analysis
    type: SingleAnalysisStep
    properties:
      parameters:
        param1: bar
        param2: foo
      prop2: blub
    apply_to:
      - loi:xxx
    result: new_dataset

Here, tasks is a list of dictionary-style entries. The key kind determines which kind of task should be performed. For each kind, a class subclassing aspecd.tasks.Task needs to exist. For details, see below. The key type stores the name of the actual class, such as a concrete processing step derived from aspecd.processing.ProcessingStep. The dictionary properties contains keys corresponding to the attributes of the respective class. Depending on the type of task, additional keys can be used, such as apply_to to determine the datasets this task should be applied to, or result providing a label for a dataset created newly by an analysis task.

Note

The use of loi: markers in the example above points to a situation in which every dataset can be accessed by a unique identifier. For details, see the LabInform documentation.

Types of tasks

Each task is internally represented by an aspecd.tasks.Task object, more precisely an object instantiated from a subclass of aspecd.tasks.Task. This polymorphism of task classes makes it possible to easily extend the scope of recipe-driven data analysis. Currently, the following subclasses are implemented:

For each task, you can set all attributes of the underlying class using the properties dictionary in the recipe. Therefore, to know which parameters can be set for what type of task means simply to check the documentation for the respective classes. I.e., for a task represented by an aspecd.tasks.ProcessingTask object, check out the appropriate class from the aspecd.processing module. The same is true for packages derived from ASpecD.

Furthermore, depending on the type of task, you may be able to set additional parameters controlling in more detail how the particular task is performed. For details, see the documentation of the respective task subclass.

Todo

There is a number of things that are not yet implemented, but required for a working recipe-driven data analysis that follows good practice for reproducible research. This includes (but may not be limited to):

  • Store history of each task (in a way the result can be used as a recipe again).

  • Parser for recipes performing a static analysis of their syntax. Useful particulary for larger datasets and/or longer lists of tasks.

Prerequisites for recipe-driven data analysis

To be able to use recipe-driven data analysis in packages derived from the ASpecD framework, a series of prerequisites needs to be met, i.e., classes implemented. Besides the usual suspects such as aspecd.dataset.Dataset and its constituents as well as the different processing and analysis steps based on aspecd.processing.ProcessingStep and aspecd.analysis.SingleAnalysisStep, two different factory classes need to be implemented in particular, subclassing

respectively. Actually, only aspecd.dataset.DatasetFactory is directly used by aspecd.tasks.Recipe, however, internally it relies on the existence of aspecd.io.DatasetImporterFactory to return a dataset based solely on a (unique) ID.

Besides implementing these classes, the facilities provided by the aspecd.tasks module should be fully sufficient for regular recipe-driven data analysis. In particular, normally there should be no need to subclass any of the classes within this module in a package derived from the ASpecD framework. One particular design goal of recipe-driven data analysis is to decouple the actual tasks being performed from the general handling of recipes. The former is implemented within each respective package built upon the ASpecD framework, the latter is taken care of fully by the ASpecD framework itself. You might want to implement a simple proxy within a derived package to prevent the user from having to call out to functionality provided directly by the ASpecD framework (what might be confusing for those unfamiliar with the underlying details, i.e., most common users).

exception aspecd.tasks.Error

Bases: Exception

Base class for exceptions in this module.

exception aspecd.tasks.MissingRecipeError(message='')

Bases: aspecd.tasks.Error

Exception raised trying to cook without recipe

message

explanation of the error

Type

str

exception aspecd.tasks.MissingDictError(message='')

Bases: aspecd.tasks.Error

Exception raised when expecting a dict but none is provided

message

explanation of the error

Type

str

exception aspecd.tasks.MissingImporterError(message='')

Bases: aspecd.tasks.Error

Exception raised when no Importer instance is provided

message

explanation of the error

Type

str

exception aspecd.tasks.MissingExporterError(message='')

Bases: aspecd.tasks.Error

Exception raised when no Importer instance is provided

message

explanation of the error

Type

str

exception aspecd.tasks.MissingDatasetFactoryError(message='')

Bases: aspecd.tasks.Error

Exception raised when no ImporterFactory instance is provided

message

explanation of the error

Type

str

exception aspecd.tasks.MissingTaskFactoryError(message='')

Bases: aspecd.tasks.Error

Exception raised when no TaskFactory instance is provided

message

explanation of the error

Type

str

exception aspecd.tasks.MissingTaskDescriptionError(message='')

Bases: aspecd.tasks.Error

Exception raised when no description for creating a task is provided

message

explanation of the error

Type

str

exception aspecd.tasks.MissingDatasetIdentifierError(message='')

Bases: aspecd.tasks.Error

Exception raised when no dataset id is provided

message

explanation of the error

Type

str

exception aspecd.tasks.MissingPlotterError(message='')

Bases: aspecd.tasks.Error

Exception raised when no Plotter instance is provided

message

explanation of the error

Type

str

class aspecd.tasks.Recipe

Bases: object

Recipes get cooked by chefs in recipe-driven data analysis.

A recipe contains a list of tasks to be performed on a list of datasets. To actually carry out all tasks in a recipe, it is handed over to a aspecd.tasks.Chef object for cooking using the respective aspecd.tasks.Chef.cook() method.

From a user’s perspective, recipes reside usually in YAML files from where they are imported into an aspecd.tasks.Recipe object using its respective import_into() method and an object of class aspecd.io.RecipeYamlImporter. Similarly, a given recipe can be exported back to a YAML file using the export_to() method and an object of class aspecd.io.RecipeYamlExporter.

In contrast to the persistent form of a recipe (e.g., as file on the file system), the object contains actual datasets and tasks that are objects of the respective classes. Therefore, the attributes of a recipe are normally set by the respective methods from either a file or a dictionary (that in turn will normally be created from contents of a file).

Retrieving datasets is delegated to an aspecd.dataset.DatasetFactory instance stored in dataset_factory. This provides a maximum of flexibility but makes it necessary to specify (and first implement) such factory in packages derived from the ASpecD framework.

Todo

Can recipes have LOIs themselves and therefore be retrieved from the extended data safe? Might be a sensible option, although generic (and at the same time unique) LOIs for recipes are much harder to create than LOIs for datasets and alike.

Generally, the concept of a LOI is nothing a recipe needs to know about. But it does know about an ID of any kind. Whether this ID is a (local) path or a LOI doesn’t matter. Somewhere in the ASpecD framework there may exist a resolver (factory) for handling IDs of any kind and eventually retrieving the respective information.

datasets

Ordered dictionary of datasets the tasks should be performed for

Each dataset is an object of class aspecd.dataset.Dataset.

The keys are the dataset ids.

Type

collections.OrderedDict

tasks

List of tasks to be performed on the datasets

Each task is an object of class aspecd.tasks.Task.

Type

list

results

Ordered dictionary of results originating from analysis tasks

Results can be of any type, but are mostly either instances of aspecd.dataset.Dataset or aspecd.metadata.PhysicalQuantity.

The keys are those defined by aspecd.tasks.SingleanalysisTask.result and aspecd.tasks.MultianalysisTask.result, respectively.

Type

collections.OrderedDict

figures

Ordered dictionary of figures originating from plotting tasks

Each entry is an object of class aspecd.tasks.FigureRecord.

Type

collections.OrderedDict

dataset_factory

Factory for datasets used to retrieve datasets

If no factory is set, but a recipe imported from a file or set from a dictionary, an exception will be raised.

Type

aspecd.dataset.DatasetFactory

task_factory

Factory for tasks

Defaults to an object of class aspecd.tasks.TaskFactory.

If no factory is set, but a recipe imported from a file or set from a dictionary, an exception will be raised.

Type

aspecd.tasks.TaskFactory

Raises
from_dict(dict_=None)

Set attributes from dictionary.

Loads datasets and creates aspecd.tasks.Task objects that are stored as lists respectively.

Parameters

dict (dict) – Dictionary containing information of a recipe.

Raises
to_dict()

Return dict from attributes.

Returns

dict_ – Dictionary with fields “datasets” and “tasks”

Return type

dict

import_from(importer=None)

Import recipe using importer.

Importers can be created to read recipes from different sources. Thus the recipe as such is entirely independent of the persistence layer.

Parameters

importer (aspecd.io.RecipeImporter) – importer used to actually import recipe

Raises

aspecd.tasks.MissingImporterError – Raised if no importer is provided

export_to(exporter=None)

Export recipe using exporter.

Exporters can be created to write recipes to different targets. Thus the recipe as such is entirely independent of the persistence layer.

Parameters

exporter (aspecd.io.RecipeExporter) – exporter used to actually export recipe

Raises

aspecd.tasks.MissingExporterError – Raised if no exporter is provided

get_dataset(identifier='')

Return dataset corresponding to given identifier.

In case of having a list of identifiers, use the similar method aspecd.tasks.Recipe.get_datasets().

Parameters

identifier (str) – Identifier matching the aspecd.dataset.Dataset.id attribute.

Returns

dataset – Dataset corresponding to given identifier

If no dataset corresponding to the given identifier could be found, None is returned.

Return type

aspecd.dataset.Dataset

Raises

aspecd.tasks.MissingDatasetIdentifierError – Raised if no identifier is provided.

get_datasets(identifiers=None)

Return datasets corresponding to given list of identifiers.

In case of having a single identifier, use the similar method aspecd.tasks.Recipe.get_dataset().

Parameters

identifiers (list) – Identifiers matching the aspecd.dataset.Dataset.id attribute.

Returns

datasets – Datasets corresponding to given identifier

Each dataset is an instance of aspecd.dataset.Dataset.

If no datasets corresponding to the given identifiers could be found, an empty list is returned.

Return type

list

Raises

aspecd.tasks.MissingDatasetIdentifierError – Raised if no identifiers are provided.

class aspecd.tasks.Chef(recipe=None)

Bases: object

Chefs cook recipes in recipe-driven data analysis.

As a result, they create some kind of history of the tasks performed. In this respect, they make the history independent of a singe dataset and allow to trace processing and analysis of multiple datasets. One necessary prerequisite is therefore the LOI as a persistent and unique identifier for each dataset.

Todo

Decide about the way this kind of history gets stored and persisted. One reasonable idea might be to persist it in a form that can be used as a recipe again. The file format for persistence will most probably be YAML for the time being.

Parameters

recipe (aspecd.tasks.Recipe) – Recipe to cook, i.e. to carry out

recipe

Recipe to cook, i.e. to carry out

Type

aspecd.tasks.Recipe

Raises

aspecd.tasks.MissingRecipeError – Raised if no recipe is available to be cooked

cook(recipe=None)

Cook recipe, i.e. carry out tasks contained therein.

A recipe is an object of class aspecd.tasks.Recipe and contains both, a list of datasets and a list of tasks to be performed on these datasets.

Parameters

recipe (aspecd.tasks.Recipe) – Recipe to cook, i.e. tasks to carry out on particular datasets

Raises

aspecd.tasks.MissingRecipeError – Raised if no recipe is available to be cooked

class aspecd.tasks.Task(recipe=None)

Bases: aspecd.utils.ToDictMixin

Base class storing information for a single task.

Different underlying objects used to actually perform the respective task have different requirements and different signatures. In order to generically perform a task, for each kind of task – such as processing, analysis, plotting – this class needs to be subclassed. For a number of basic tasks available in the ASpecD package, this has already been done. See:

Note that imports of datasets are usually not handled using tasks, as this is taken care of automatically by defining a list of datasets in a aspecd.tasks.Recipe.

Usually, you need not care to instantiate objects of the correct type, as this is done automatically by the aspecd.tasks.Recipe using the aspecd.tasks.TaskFactory.

kind

Kind of task.

Usually corresponds to the module name the type (class) is defined in. See the note below for special cases.

Type

str

type

Type of task.

Corresponds to the class name eventually responsible for performing the task.

Type

str

properties

Properties necessary to perform the task.

Should have keys corresponding to the properties of the class given as type attribute.

Generally, all keys in aspecd.tasks.Task.properties will be mapped to the underlying object created to perform the actual task.

In contrast, all additional attributes of a given task object subclassing aspecd.tasks.Task that are specific to the task object as such and its operation, but not for the object created by the task object to perform the task, are not part of the aspecd.tasks.Task.properties dict. For a recipe, this means that these additional attributes are at the same level as aspecd.tasks.Task.properties.

Type

dict

apply_to

List of datasets the task should be applied to.

Defaults to an empty list, meaning that the task will be performed for all datasets contained in a aspecd.tasks.Recipe.

Each dataset is referred to by the value of its aspecd.dataset.Dataset.source attribute. This should be unique and can consist of a filename, path, URL/URI, LOI, or alike.

Type

list

recipe

Recipe containing the task and the list of datasets the task refers to

Type

aspecd.tasks.Recipe

Note

A note to developers: Usually, the aspecd.tasks.Task.kind attribute is identical to the module name the respective class resides in. However, sometimes this is not the case, as with the plotters. In this case, an additional, non-public attribute aspecd.tasks.Task._module can be set in classes derived from aspecd.tasks.Task.

Raises
from_dict(dict_=None)

Set attributes from dictionary.

Parameters

dict (dict) – Dictionary containing information of a task.

Raises

aspecd.tasks.MissingDictError – Raised if no dict is provided.

perform()

Call the appropriate method of the underlying object.

The actual implementation is contained in the non-public method aspecd.tasks.Task._perform().

Different underlying objects have different methods used to actually perform the respective task. In order to generically perform a task, classes derived from the aspecd.tasks.Task base class need to override aspecd.tasks.Task._perform() accordingly.

Use aspecd.tasks.Task.get_object() to get an instance of the actual object necessary to perform the task, and afterwards call its appropriate method.

Similarly, to get the actual dataset using the dataset id stored in aspecd.tasks.Task.apply_to, use the method aspecd.tasks.Recipe.get_dataset() of the recipe stored in aspecd.tasks.Task.recipe.

Raises

aspecd.tasks.MissingRecipeError – Raised if no recipe is available.

get_object()

Return object for a particular task including all attributes.

Returns

obj – Object of a class defined in the type attribute of a task

Return type

object

class aspecd.tasks.ProcessingTask(recipe=None)

Bases: aspecd.tasks.Task

Processing step defined as task in recipe-driven data analysis.

Processing steps will always be performed individually for each dataset.

For more information on the underlying general class, see aspecd.processing.ProcessingStep.

For an example of how such a processing task may be included into a recipe, see the YAML listing below:

kind: processing
type: ProcessingStep
properties:
  parameters:
    param1: bar
    param2: foo
  comment: >
    Some free text describing in more details the processing step
apply_to:
  - loi:xxx

Note that you can refer to datasets and results created during cooking of a recipe using their respective labels. Those labels will automatically be replaced by the actual dataset/result prior to performing the task.

class aspecd.tasks.AnalysisTask(recipe=None)

Bases: aspecd.tasks.Task

Analysis step defined as task in recipe-driven data analysis.

Analysis steps can be performed individually for each dataset or the results combined, depending on the type of analysis step.

An AnalysisTask should not be used directly but rather the two classes derived from this class, namely:

For more information on the underlying general class, see aspecd.analysis.AnalysisStep.

result

Label for the dataset resulting from an analysis step.

This label will be used to refer to the dataset later on when further processing the recipe.

Type

str

class aspecd.tasks.SingleanalysisTask(recipe=None)

Bases: aspecd.tasks.AnalysisTask

Analysis step defined as task in recipe-driven data analysis.

Singleanalysis steps can only be performed individually for each dataset. For analyses combining multiple datasets, see aspecd.tasks.MultianalyisTask.

For more information on the underlying general class, see aspecd.analysis.SingleAnalysisStep.

For an example of how such an analysis task may be included into a recipe, see the YAML listing below:

kind: singleanalysis
type: SingleAnalysisStep
properties:
  parameters:
    param1: bar
    param2: foo
  comment: >
    Some free text describing in more details the analysis step
apply_to:
  - loi:xxx
result: label

Note that you can refer to datasets and results created during cooking of a recipe using their respective labels. Those labels will automatically be replaced by the actual dataset/result prior to performing the task.

class aspecd.tasks.MultianalysisTask(recipe=None)

Bases: aspecd.tasks.AnalysisTask

Analysis step defined as task in recipe-driven data analysis.

Multianalysis steps are performed on a list of datasets and combine them in one single analysis. For analyses performed on individual datasets, see aspecd.tasks.SingleanalysisTask.

For more information on the underlying general class, see aspecd.analysis.MultiAnalysisStep.

For an example of how such an analysis task may be included into a recipe, see the YAML listing below:

kind: multianalysis
type: MultiAnalysisStep
properties:
  parameters:
    param1: bar
    param2: foo
  comment: >
    Some free text describing in more details the analysis step
apply_to:
  - loi:xxx
result:
  - label1
  - label2

Note that you can refer to datasets and results created during cooking of a recipe using their respective labels. Those labels will automatically be replaced by the actual dataset/result prior to performing the task.

In case such a multianalysis step results in a list of resulting datasets, result should be a list of labels, not a single label.

Raises

IndexError – Raised if list of result labels and results are not of same length

class aspecd.tasks.AnnotationTask(recipe=None)

Bases: aspecd.tasks.Task

Annotation step defined as task in recipe-driven data analysis.

Annotation steps will always be performed individually for each dataset.

For more information on the underlying general class, see aspecd.processing.Annotation.

class aspecd.tasks.PlotTask

Bases: aspecd.tasks.Task

Plot step defined as task in recipe-driven data analysis.

A PlotTask should not be used directly but rather the two classes derived from this class, namely:

For more information on the underlying general class, see aspecd.plotting.Plotter.

label

Label for the fighure resulting from a plotting step.

This label will be used to refer to the plot later on when further processing the recipe. Actually, in the recipe’s aspecd.tasks.Recipe.figures dict, this label is used as a key and a aspecd.tasks.FigureRecord object stored containing all information necessary for further handling the results of the plot.

Type

str

perform()

Call the appropriate method of the underlying object.

For details, see the method aspecd.tasks.Task.perform() of the base class.

Additionally to what is done in the base class, a PlotTask adds a aspecd.tasks.FigureRecord object to the aspecd.tasks.Recipe.figures property of the underlying recipe in case an aspecd.tasks.PlotTask.label has been set.

save_plot(plot=None)

Save the figure of the plot created by the task.

Parameters

plot (aspecd.plotting.Plotter) – Plot whose figure should be saved

class aspecd.tasks.SingleplotTask

Bases: aspecd.tasks.PlotTask

Singleplot step defined as task in recipe-driven data analysis.

Singleplot steps can only be performed individually for each dataset. For plots combining multiple datasets, see aspecd.tasks.MultiplotTask.

For more information on the underlying general class, see aspecd.plotting.SinglePlotter.

For an example of how such a analysis task may be included into a recipe, see the YAML listing below:

kind: singleplot
type: SinglePlotter
properties:
  parameters:
    param1: bar
    param2: foo
  caption:
    title: >
      Ideally a single sentence summarising the intend of the figure
    text: >
      More text for the figure caption
    parameters:
      - a list of parameters
      - that shall (additionally) be listed
      - in the figure caption
  filename: fancyfigure.pdf
apply_to:
  - loi:xxx
label: label

Note that you can refer to datasets and results created during cooking of a recipe using their respective labels. Those labels will automatically be replaced by the actual dataset/result prior to performing the task.

Note

As soon as you provide a filename in the properties of your recipe, the resulting plot will automatically be saved to that filename, inferring the file format from the extension of the filename. For details of how the format is inferred see the documentation for the matplotlib.figure.Figure.savefig() method.

class aspecd.tasks.MultiplotTask

Bases: aspecd.tasks.PlotTask

Multiplot step defined as task in recipe-driven data analysis.

Multiplot steps are performed on a list of datasets and combine them in one single plot. For plots performed on individual datasets, see aspecd.tasks.SingleplotTask.

For more information on the underlying general class, see aspecd.plotting.MultiPlotter.

For an example of how such a analysis task may be included into a recipe, see the YAML listing below:

kind: multiplot
type: MultiPlotter
properties:
  parameters:
    param1: bar
    param2: foo
  caption:
    title: >
      Ideally a single sentence summarising the intend of the figure
    text: >
      More text for the figure caption
    parameters:
      - a list of parameters
      - that shall (additionally) be listed
      - in the figure caption
  filename: fancyfigure.pdf
apply_to:
  - loi:xxx
  - loi:yyy
label: label

Note that you can refer to datasets and results created during cooking of a recipe using their respective labels. Those labels will automatically be replaced by the actual dataset/result prior to performing the task.

Note

As soon as you provide a filename in the properties of your recipe, the resulting plot will automatically be saved to that filename, inferring the file format from the extension of the filename. For details of how the format is inferred see the documentation for the matplotlib.figure.Figure.savefig() method.

class aspecd.tasks.ReportTask

Bases: aspecd.tasks.Task

Reporting step defined as task in recipe-driven data analysis.

For more information on the underlying general class, see aspecd.report.Reporter.

For an example of how such an analysis task may be included into a recipe, see the YAML listing below:

kind: report
type: LaTeXReporter
properties:
  template: my-fancy-latex-template.tex
  filename: some-filename-for-final-report.tex
  context:
    general:
      title: Some fancy title
      author: John Doe
    free_text:
      intro: >
        Short introduction of the experiment performed
      metadata: >
        Tabular and customisable overview of the dataset's metadata
      history: >
        Presentation of all processing, analysis and representation
        steps
    figures:
      title: my_fancy_figure
compile: True
apply_to:
  - loi:xxx

Note that you can refer to datasets, results, and figures created during cooking of a recipe using their respective labels. Those labels will automatically be replaced by the actual dataset/result prior to performing the task.

Whatever fields you set as property context can be accessed directly from within the template using the usual Python syntax for accessing keys of dictionaries. The fields shown here assume a certain structure of your template containing user-supplied free text for the introduction to several sections.

Additionally, the task will provide the key dataset containing the result of the aspecd.dataset.Dataset.to_dict() method, thus the full information contained in the dataset.

compile

Option for compiling a template.

Some types of templates need an additional “compile” step to create output, most prominently LaTeX templates. If the Reporter class does not support compiling, but compile is set to True, it gets silently ignored.

Type

bool

class aspecd.tasks.TaskFactory

Bases: object

Factory for creating task objects based on the kind provided.

The kind reflects the name of the module the actual object required for performing the task resides in. Furthermore, two ways are available for specifying the kind, either directly as argument provided to aspecd.tasks.TaskFactory.get_task() or as key in a dict used as an argument for aspecd.tasks.TaskFactory.get_task_from_dict().

The classes for the different tasks follow a simple convention: “<Module>Task” with “<Module>” being the capitalised module name the actual class necessary for performing the task resides in. Therefore, for each new module tasks should be available for, you will need to create an appropriate task class deriving from aspecd.tasks.Task.

Raises
get_task(kind=None)

Return task object specified by its kind.

Parameters

kind (str) –

Kind of task to create

Reflects the name of the module the actual object required for performing the task resides in.

Returns

task – Task object

The actual subclass depends on the kind.

Return type

aspecd.tasks.Task

Raises

aspecd.tasks.MissingTaskDescriptionError – Raised if no description is given necessary to create task.

get_task_from_dict(dict_=None)

Return task object specified by the “kind” key in the dict.

Parameters

dict (dict) –

Dictionary containing “kind” key

The “kind” key reflects the name of the module the actual object required for performing the task resides in.

Returns

task – Task object

The actual subclass depends on the kind.

Return type

aspecd.tasks.Task

Raises
class aspecd.tasks.FigureRecord

Bases: aspecd.utils.ToDictMixin

Information about a figure created by a PlotTask.

Figures created during recipe-driven data analysis may need to be added, e.g., to a report. Therefore, the information contained in the PlotTask needs to be accessible by the recipe and other tasks in turn.

caption

User-supplied information for the figure caption.

Has three fields: “title”, “text”, and “parameters”.

“title” is usually one sentence describing the intent of the figure and often plotted bold-face in a figure caption.

“text” is additional text directly following the title, containing more information about the plot.

“parameters” is a list of parameter names that should be included in the figure caption, usually at the very end.

Type

dict

parameters

All parameters necessary for the plot, implicit and explicit

Type

dict

label

Label the figure should be referred to from within the recipe

Similar to the aspecd.tasks.SingleanalysisTask.result attribute of the aspecd.tasks.SingleanalysisTask class.

Type

str

filename

Name of file to save the plot to

Type

str

Raises

aspecd.tasks.MissingPlotterError – Raised if no plotter is provided

from_plotter(plotter=None)

Set attributes from plotter

Usually, a plotter contains all information necessary for an aspecd.tasks.FigureRecord object.

Parameters

plotter (aspecd.plotting.Plotter) – Plotter the figure record should be created for.

Raises

aspecd.tasks.MissingPlotterError – Raised if no plotter is provided