coffee package

Subpackages

• coffee.actions package
  • Submodules
  • coffee.actions.actions module
  • coffee.actions.hdf_output module
  • coffee.actions.mpl_plotter module
  • Module contents
• coffee.backend package
  • Submodules
  • coffee.backend.backend module
    • Backend
      • Backend.abs()
      • Backend.absolute()
      • Backend.any()
      • Backend.apply_along_axis()
      • Backend.apply_over_axes()
      • Backend.arange()
      • Backend.around()
      • Backend.array()
      • Backend.array_equal()
      • Backend.asarray()
      • Backend.atleast_1d()
      • Backend.atleast_2d()
      • Backend.convolve()
      • Backend.copy()
      • Backend.cos()
      • Backend.diag()
      • Backend.dot()
      • Backend.dtype()
      • Backend.empty()
      • Backend.empty_like()
      • Backend.exp()
      • Backend.fromiter()
      • Backend.get_backend()
      • Backend.lib_stride_tricks_as_strided()
      • Backend.linspace()
      • Backend.log()
      • Backend.log2()
      • Backend.mat()
      • Backend.max()
      • Backend.meshgrid()
      • Backend.min()
      • Backend.ndarray()
      • Backend.nonzero()
      • Backend.ones()
      • Backend.ones_like()
      • Backend.power()
      • Backend.real()
      • Backend.reshape()
      • Backend.savetxt()
      • Backend.set_backend()
      • Backend.set_printoptions()
      • Backend.sin()
      • Backend.sqrt()
      • Backend.squeeze()
      • Backend.sum()
      • Backend.tan()
      • Backend.union1d()
      • Backend.vectorize()
      • Backend.where()
      • Backend.zeros()
      • Backend.zeros_like()
    • BackendBase
    • NumpyBackend
      • NumpyBackend.abs()
      • NumpyBackend.absolute()
      • NumpyBackend.any()
      • NumpyBackend.apply_along_axis()
      • NumpyBackend.apply_over_axes()
      • NumpyBackend.arange()
      • NumpyBackend.around()
      • NumpyBackend.array()
      • NumpyBackend.array_equal()
      • NumpyBackend.asarray()
      • NumpyBackend.atleast_1d()
      • NumpyBackend.atleast_2d()
      • NumpyBackend.convolve()
      • NumpyBackend.copy()
      • NumpyBackend.cos()
      • NumpyBackend.diag()
      • NumpyBackend.dot()
      • NumpyBackend.dtype()
      • NumpyBackend.empty()
      • NumpyBackend.empty_like()
      • NumpyBackend.exp()
      • NumpyBackend.fromiter()
      • NumpyBackend.lib_stride_tricks_as_strided()
      • NumpyBackend.linspace()
      • NumpyBackend.log()
      • NumpyBackend.log2()
      • NumpyBackend.mat()
      • NumpyBackend.max()
      • NumpyBackend.meshgrid()
      • NumpyBackend.min()
      • NumpyBackend.ndarray()
      • NumpyBackend.nonzero()
      • NumpyBackend.ones()
      • NumpyBackend.ones_like()
      • NumpyBackend.power()
      • NumpyBackend.real()
      • NumpyBackend.reshape()
      • NumpyBackend.savetxt()
      • NumpyBackend.set_printoptions()
      • NumpyBackend.sin()
      • NumpyBackend.sqrt()
      • NumpyBackend.squeeze()
      • NumpyBackend.sum()
      • NumpyBackend.tan()
      • NumpyBackend.union1d()
      • NumpyBackend.vectorize()
      • NumpyBackend.where()
      • NumpyBackend.zeros()
      • NumpyBackend.zeros_like()
  • Module contents
• coffee.diffop package
  • Subpackages
    • coffee.diffop.sbp package
      • Submodules
      • coffee.diffop.sbp.dissipation module
      • coffee.diffop.sbp.sbp module
      • Module contents
  • Submodules
  • coffee.diffop.fd module
  • Module contents
• coffee.grid package
  • Submodules
  • coffee.grid.grid module
  • Module contents
• coffee.io package
  • Submodules
  • coffee.io.simulation_data module
  • Module contents
• coffee.mpi package
  • Submodules
  • coffee.mpi.mpiinterfaces module
  • Module contents
• coffee.solvers package
  • Submodules
  • coffee.solvers.solvers module
  • Module contents
• coffee.tslices package
  • Submodules
  • coffee.tslices.tslices module
  • Module contents

Submodules

coffee.free_data module

The FreeData class describes the `free data’ of a system of equations.

This is a subclass of Abstract Base Class. It specifies an interface. All classes that are used to calculate initial data or free data for a simulation scheme are assumed to implement the methods below. In particular the object actions.hdf_output.SimOutputType.Exact uses the exact method.

It is not, in general, needed to implement all of the following methods. What you do implement should be determined by what additional objects interact with your subclass of the system.System class.

This object is subclassed from abc inorder to make you think twice about what you are doing. If your free data is sufficiently simple the code that corresponds to free data could be included directly into system.System since all calls to FreeData are mediated through system.System.

class coffee.free_data.FreeData

Bases: object

This is a simple abstract base class for the implementation of exact solutions.

All the ‘virtual’ functions must be defined, modulo the comments given in the module docstring.

abstract dirichlet(u, intStep=None)

Return dirichlet boundary conditions.

This is a poorly thought through addition to this class. The idea is that at certain steps during the evolution of data it might be necessary to call dirichlet boundary conditions. This method does that. Why is something different from left_boundary needed? I don’t know. That’s why it’s poorly thought through. The bottom line is that this method might be removed from this class at some point.

Originally this method was used to implement the intermediate boundary conditions for explicit RK routines during evolution. In order to do this knowledge of which intermediate step the boundary condition was being applied is necessary. This is the reason for the keyword argument.

Parameters:

• u (tslice.TimeSlice) – Stores data for which dirichlet boundary conditions are needed.

• intStep (int) – Giving which intermediate step the RK routine is currently in.

abstract exact(t, grid)

Returns the exact values of the functions being numerically found.

The idea is that this data can be calculated and stored in the hdf file during the simulation as a result of a call to the actions.hdf_actions.SimOutputType.Exact object.

Of course you don’t have to use this method that way…

Parameters:

• t (float) – The time at which to calculate the exact values.

• grid – The domain over which to calculate the exact values.

Return type:

The exact values of the functions being solved for in the simulation.

abstract initial_data(t, grid)

Returns the initial data for a simulation based on the initial time and grid.

Parameters:

• t (float) – The initial time at which the initial data is to be calculated.

• grid – The grid over which the initial data is to be calculated.

Returns:

the initial data of the simulation.

Return type:

tslice.TimeSlice

abstract left_boundary(tslice)

Returns the boundary values given on the left boundary over a one dimensional grid.

The currect FreeData object assumes that the simulation is being done over a one dimensional grid. Hence the call to ‘left_boundary’. this method will eventually be altered to bring it into line with the grid method, `boundary_slices’ which specifies the slices of the domain corresponding to the boundary in a mannor which is independent of assumptions about the number of dimensions.

Until then you’ll just have to cope.

Parameters:

tslice (tslice.TimeSlice) – The timeslice of the data which left boundary values need to given.

Returns:

• The values of the functions being numerically simulated on

• left boundary. The type of these values is up to you,

• inconjunction with your implementation of the tslices.TimeSlice

• and system.System classes.

abstract right_boundary(tslice)

Returns the boundary values given on the right boundary over a one dimensional grid.

Arguments and returned object are as for left_boundary.

Parameters:

tslice (tslice.TimeSlice) – The timeslice of the data which left boundary values need to given.

Returns:

left boundary. The type of these values is up to you, inconjunction with your implementation of the tslices.TimeSlice and system.System classes.

Return type:

The values of the functions being numerically simulated on

coffee.ibvp module

This is the class that handles the iterative step and actions of the simulation.

The name ibvp comes from the original design of this class as the iterative step in an initial boundary value problem solver. However, this class is general enough to handle numerical techniques that have, at their highest level, some iterative method.

class coffee.ibvp.IBVP(sol, eqn, grid, action=[], maxIteration=10000, minTimestep=1e-08)

Bases: object

Handles computation of the solution to initial boundary value problems.

This class manages the interative process of simulations and interleaves interative steps with calls to a list of actions. Information about events during the simulation are writen to logging.getLogger(“IBVP”).

iteration = 0

maxIteration = None

run(tstart, tstop=inf, thits=None)

Go for it! Starts the simulation.

Parameters:

• tstart (float) – A number giving the time at the initial interation.

• tstop (float) – A number giving the time to finish the simulation at.

• thits (list, float) – A list of times that the simulation is forced to hit exactly.

theActions = None

theGrid = None

theSolver = None

coffee.settings module

A settings file that is initialised by the user to configure the backend class.

Should be easily generalised to other settings that have similar requirements.

coffee.settings.init(backend_obj)

coffee.system module

The abstract base class (abc) for System objects.

This class serves to specify the interface that System classes are assumed to have. These assumptions are made by virtually all classes that call the system. For example, ibvp.IBVP, subclasses of solver.Solver, almost all actions.hdf_actions.SimOutType subclasses.

While you don’t need to actually implement all the methods below, it really is recommended. You may get errors about the methods missing as a consequence.

system.System has abc.ABCMeta as a meta class. This serves as a warning to really think about what you are doing if you don’t implement all methods below.

class coffee.system.System

Bases: object

The System class that specifies the interface for all other system classes.

You don’t need to implement everything below, but you can expect errors if you don’t. The main purpose of this class is to document the API that classes that describe a system of equations are expected to provide.

evaluate(t, tslice)

Returns the data needed by the solver.Solver subclass needed to calculate the values of the functions at the next time step.

For example, in a IBVP problem using an RK sover this method will return the values of the derivatives of the functions being evolved.

Yes I know it all sounds a bit vague. But really, this method is the heart and soul of coffee. You need to know what you’re doing, how the solver is implemented and what data the system is meant to pass to the solver.

Parameters:

• t (float) – The time at which the ‘derivatives’ need to be calculated. NOTE THAT THIS TIME MAY BE DIFFERENT FROM THE TIME STORED IN u. The time stored in u is the time for the values of the functions stored in u, not the time at which the derivatives of the functions stored in u are needed. In the case of RK methods t and u.time can be different. YOU HAVE BEEN WARNED.

• tslice (tslice.TimeSlice) – Contains the data from which the ‘evaluate’ method is meant to calculate data from.

Returns:

data needed for the solver.Solver subclass to calculate the values of the functions being evolved at the next time slice.

Return type:

tslice.TimeSlice

initialValues(t, grid)

Returns initial data for the simulation.

Parameters:

• t (float) – The time at which the initial data is to be calcualted.

• grid (ABCGrid) – The grid over which the data is to be calculated.

Returns:

The initial values for the functions to be evolved.

Return type:

tslice.TimeSlice

left(t)

Returns the boundary data on the ‘left’ boundary.

Yes this also makes the assumption that left is well defined. See the documentation for free_data.FreeData. To be honest I’m not sure that this method needs to be defined here. After all: does any class other than the system class need to access this method? If not there there is no need for it.

As no grid object is passed as an argument the boundary value must be independent of current function data. This is an obvious defect. Also: this doesn’t seem to be a problem: boundary data can be manually handled in the evaluate routine. Still this issue should be changed when it actually becomes a problem.

Parameters:

t (float) – The time for which the left data needs to be calculated.

Return type:

The boundary data.

right(t)

Returns the boundary data on the ‘right’ boundary.

See the documentation for the function system.System.left

Parameters:

t (float) – The time for which the left data needs to be calculated.

Return type:

The boundary data.

timestep(tslice)

Returns a number giving the time step for the next iteration.

Parameters:

tslice (tslices.TimeSlice) – A time slice with the current data.

Returns:

A number giving the dt for which the next data will be calculated in the next iteration.

Return type:

float

Module contents