The increasing availability of computational resources is enabling more detailed, realistic modeling in computational neuroscience, resulting in a shift toward more heterogeneous models of neuronal circuits, and employment of complex experimental protocols. This poses a challenge for existing tool chains, as the set of tools involved in a typical modeler's workflow is expanding concomitantly, with growing complexity in the metadata flowing between them. For many parts of the workflow, a range of tools is available; however, numerous areas lack dedicated tools, while integration of existing tools is limited. This forces modelers to either handle the workflow manually, leading to errors, or to write substantial amounts of code to automate parts of the workflow, in both cases reducing their productivity. To address these issues, we have developed Mozaik: a workflow system for spiking neuronal network simulations written in Python. Mozaik integrates model, experiment and stimulation specification, simulation execution, data storage, data analysis and visualization into a single automated workflow, ensuring that all relevant metadata are available to all workflow components. It is based on several existing tools, including PyNN, Neo, and Matplotlib. It offers a declarative way to specify models and recording configurations using hierarchically organized configuration files. Mozaik automatically records all data together with all relevant metadata about the experimental context, allowing automation of the analysis and visualization stages. Mozaik has a modular architecture, and the existing modules are designed to be extensible with minimal programming effort. Mozaik increases the productivity of running virtual experiments on highly structured neuronal networks by automating the entire experimental cycle, while increasing the reliability of modeling studies by relieving the user from manual handling of the flow of metadata between the individual workflow stages.
One of the primary goals of computational neuroscience is to create models of neuronal structures and their function that as closely as possible adhere to the known anatomy of brain, while at the same time match as wide a range of experimental measurements as possible. In pursuit of this goal, supported by ever more plentiful computational resources, neuroscientists are building increasingly detailed, heterogeneous neuronal models and testing them under more and more elaborate experimental conditions. This process has accelerated in the last decade due to the increasing availability and capability of high-performance computing (HPC), enabling the simulation of neuronal structures at unprecedented levels of detail (Reimann et al., 2013), while expanding the simulations into multi-layer or even multi-areal contexts (Potjans and Diesmann, 2012; Nakagawa et al., 2013) and reproducing complex stimulation and recording experimental protocols (Shushruth et al., 2012).
This rapid increase in the overall complexity of simulation workflows has only partially been accompanied by development of the various software tools that support them. The main development has been in the adaptation of neuronal network simulators to the HPC and supercomputer environments (Plesser et al., 2007), but the rest of the simulation workflow has been largely ignored. Such a focus on the underlying network simulation software was reasonable in the past, as it constituted most of the software stack required for a given project, and was by far the most computationally demanding part of it. However, due to the recent increase in the complexity of the models, stimulation/recording protocols and the subsequent analysis and visualization of the results, the lack of software support for the full simulation workflow (see Figure 1) drives users to write increasing amounts of code to meet the requirements of their projects. It is our belief that this lack of support for the full simulation workflow greatly reduces the productivity of the field (Wilson, 2006) and constitutes a major challenge for future development of brain simulation infrastructure.
Figure 1. The typical workflow of a neuronal simulation modeling project. A user specifies the model using certain primitives such as neurons, the connections between them and the stimulation protocol. An instance of such a model is then simulated for a period of time, while being presented with stimuli specified by the experimental protocol. During the simulation a range of variables are recorded (e.g., spikes, membrane potential etc.); and typically stored for future processing. After the simulation is finished the data is; this data is then passed through the analysis and visualization protocols. At this point the user can inspect the results, which likely leads to modification of the model or experimental protocol (interrupted arrows), requiring another pass through the workflow cycle.
In this paper we address this problem by proposing a new integrated environment for the simulation of spiking neuronal networks, which attempts to unify the various aspects of the workflow involved in simulating heterogeneous spiking neuronal networks in realistic experimental contexts and the subsequent processing of the resulting data, into a single automated workflow. Even though the current state of tools in the field is rather fragmented, there are a number of software packages that cover certain aspects of the workflow very well. Consequently our goal was to reuse as many of these existing tools as possible, focusing mainly on writing intermediate code to facilitate seamless communication between them, although we still had to cover several unaddressed aspects of the workflow by developing new tools.
The first question we faced in the process of designing Mozaik was the choice of programming environment. Conveniently, this choice was made rather easy by the recent proliferation of neuroscience tools implemented in Python. Python itself is an ideal language for integration projects (Scripps and Sanner, 1999), and together with the packages such as PyNN (Davison et al., 2009) and Neo (Davison et al., 2011) it provides an ecosystem perfectly fitted for our needs. PyNN is a simulator-independent specification of neuronal models, that includes (among others) back-ends for the major simulators used today including NEST (Gewaltig and Diesmann, 2007) and NEURON (Hines and Carnevale, 1997). Using this tool as the low-level model specification language makes Mozaik more independent of the simulation environment, yielding a more universal tool. The Neo package defines a common object model for storing a wide range of data typically recorded in neuroscience experiments, and allows for its flexible labeling with additional metadata. Furthermore, Neo also contains an extensive number of back-ends that allow for conversion of a number of data formats to and from the Neo data structures.
Mozaik has a modular architecture, and a great deal of emphasis has been put on designing a hierarchy of interfaces that allow for replacing or adding modules at the desired level of abstraction, reducing the amount of new code required for implementing new or changing existing features. Mozaik currently covers the following aspects of the workflow: experiment and stimulation specification, simulation execution, data storage, data analysis and visualization. Even though the major added value of Mozaik is the specification of application programming interfaces (APIs) for the various steps of the workflow, it also provides a ready to use implementation of all these APIs. While the APIs are written in as general a manner as possible, and should encompass a very wide range of spiking neuronal network simulation projects, the components implemented are currently focused on the visual modality. In this paper we provide a general description of the Mozaik design, accompanied with several illustrative usage examples, and explain the reasoning behind the various design choices. We do not, however, provide here a full user guide; this can be found at https://github.com/antolikjan/Mozaik.
The motivation behind Mozaik is to increase the productivity of neuronal simulation workflows by means of automation and a reduction of the amount of boiler-plate code a user has to write. Most of the design principles discussed below are directly motivated by these two main goals.
A common way of writing modular software is to partition the project into several (usually roughly equal) components, at roughly the same level of abstraction, and defining an independent API for each of them. This means that users can replace each of these components with their own implementation as long as they adhere to that component's API. The downside of such a "flat" strategy is that even small changes to the functionality of a given component generally require it to be completely rewritten (albeit using mainly copy-and-paste). The alternative strategy is to define a hierarchy of APIs at different levels of abstraction, which allows the user to pick the lowest point in the hierarchy that encompasses the functionality he intends to add or override, and hence minimize the amount of new code. In designing Mozaik we have employed the latter strategy.
There are two principal ways of specifying dynamical systems: imperative, where a user specifies the algorithm that will perform the desired actions; and declarative, where a user specifies what should be the outcome of the desired actions. Each has its advantages and drawbacks, with imperative specification being more flexible, and declarative more succinct, simpler and more human readable. In Mozaik we combined both approaches to gain both advantages where most appropriate. Generally Mozaik is a programmatic API, implying its imperative nature, which is inevitable given the scope of problems it addresses. However, we have pushed a declarative configuration functionality into all aspects of Mozaik, and paid attention to designing it to be as flexible as possible. In practice this means that when creating a new project most users will almost exclusively deal with the declarative configuration mechanisms and will write at most a few small, well isolated pieces of code (such as new analysis or visualization routines).
As declared in the Introduction the principal goal of Mozaik is to automate the workflow of neuronal network simulation projects. However, as with most automation projects, there is a compromise between the level of automation that can be achieved and the flexibility of the underlying framework in terms of the range of projects/configurations it supports. In Mozaik a good level of both automation and flexibility is achieved via the dual system of programmatic API and configuration front-end described above. If for a given project all required modules are already present in Mozaik, the project can simply be configured and the whole workflow will be executed without user intervention. On the other hand if the current set of Mozaik modules does not support some aspect of the project, a new module can be added, and the amount of required code should be minimized thanks to the hierarchical design of the API. Furthermore, special attention was paid to designing the analysis and visualization APIs (which are most likely to be extended by users) to automate the flow of metadata and configuration information, allowing the user to write a minimal amount of new code to express the desired functionality.
One of the major problems Mozaik addresses is handling the flow of data between its various components. Even though it is usually clear what the main inputs and outputs of a given component are, it is very common that extra contextual information is needed at a given point of the workflow to correctly interpret the data, whether it is the units of a recorded variable or the stimulus that was presented. The most common way to deal with this contextuality is that each component in the framework specifies what context it requires (i.e., what units it assumes the voltage to be in). This approach is simple, but has several drawbacks: it prevents automation without an extra translation layer; it makes the component implicitly dependent on changes in components arbitrarily far away in the framework structure; it makes it hard to test the sanity of the input; and generally such implicit instead of explicit handling of information is more error prone.
For this reason in Mozaik we adopted the policy that as much contextual information as possible (in most cases all) is stored directly in the objects that are being passed around. This means not only that the level of automation in the Mozaik package can be high, but also that should a user need to add or modify any of the components he can be sure that all relevant metadata needed for processing within the component will be directly available in the given programmatic context, resulting in more localized code.
The most common way of designing programming APIs is to specify a narrow focus for each component, which translates into code containing functions or classes with very specifically defined inputs and outputs. This approach makes it much easier to write code given the fewer input options, and the code can be exhaustively tested against the narrow input/output specification, resulting in fewer bugs. The disadvantage is that the resulting library is less flexible and leaves the user with writing more code to incorporate its functionality into a given programming context.
Given the integrative nature of Mozaik and its focus on minimization of boilerplate code, in several parts of the framework we have opted for the opposite design strategy. Particularly in the analysis and visualization modules, where flexibility is paramount, we have designed the API so that the input to analysis and visualization methods is very general (essentially it is any collection of recordings and analysis objects) and it is the role of the given method to "apply" itself to as broad a subset of this collection as possible, given its specification. This in turn allows us to have a unified system for filtering of such recording and analysis collections, which serves as a powerful tool for modifying the behavior of the analysis and visualization methods. Altogether this results in a more flexible system, allowing for the expression of complex analysis and visualization paradigms with minimal code. The disadvantage is that it makes the implementation of new analysis or visualization classes somewhat more complicated, thus shifting the balance between flexibility and ease of implementation toward the former.
When designing a workflow one faces two basic options. Either it is fully automated, with a specification created in advance and then executed without user intervention, or the workflow is interactive, with the specification supplied on the fly. In Mozaik we chose the former option, as we believe it fits better the context of large-scale simulations, where the resource requirements make it rarely practical to run in an interactive fashion. One exception to this is the analysis and visualization modules, where users might in certain situations prefer interactive usage. While interactive use for these modules is in principle possible, the current design is focused on automation, making the process cumbersome. We hope to relieve this disadvantage in future with the addition of a dedicated GUI for these modules and/or integration of Mozaik with one of the analysis and visualization libraries that are taking shape in the field.
In several cases (especially in the model specification module) we have faced design problems where flexibility of specification was in conflict with optimization of the code. In most of these cases we have valued flexibility over optimization.
Mozaik being an integrative workflow API, is by design a package that is supposed to grow over time as new model components, stimuli, experimental protocols, analysis and visualization methods are added. Furthermore, even the core API is likely to be changed in future as some parts of Mozaik will be taken over by dedicated tools. Therefore to ensure backwards compatibility and support future development the API is versioned, so that users can always be sure that their code is fully functional with respect to a well defined version of the library.
models—specification of the high-level model API, and implementation of several basic models.
sheets—specification of the sheet API - Mozaik's basic model building block.
connectors—specification of API defining how neurons connect within and between sheets.
stimuli—stimulus specification API, unifies stimulus handling across the workflow.
experiments—API for implementation of experimental protocols.
storage—implementation of a data store, handling both raw recorded data and analysis results.
analysis—specification of the analysis API and implementation of a range of analysis methods.
visualization—specification of the visualization API and implementation of a range of plotting methods.
meta-workflow—code handling workflows involving multiple model instance execution (such as parameter searches).
It is our hope that several of these sub-packages will, in future, be separated out into stand-alone packages or replaced with third-party tools, as the software ecosystem in the field matures. In the remainder of this section we will first describe the high-level interaction between the components, and then discuss in more detail each of the sub-packages, focusing on the most important aspects of their design.
The flow of control between the Mozaik components roughly follows the typical user workflow depicted in Figure 1. The workflow is launched from a short script which points Mozaik to a specification of a model, a list of experiments to be run with the model, and a list of analyses and visualizations a user wishes to perform on the recorded data. From this point, control is handed to Mozaik and the rest of the process is automated, resulting in a collection of files containing the raw recorded data, results of the analyses, including any intermediate steps, and possibly a set of figures saved in a specified format.
To better understand the organization of Mozaik we will now give a brief account of how control flows between the components (see Figure 2). The user script hands control to the controller module, the control hub of Mozaik. The controller module creates a new data store, initializes the model instance (more on this in the following section), and proceeds to iterate over the experiment list. For each experiment it will ask for the list of stimuli that the experiment wishes to be presented to the model, and removes any that might have already been recorded in previously executed experiments, thus saving computing resources. After this it will hand over control to the experiment instance, together with the (possibly reduced) list of stimuli, which in turn will initiate the process of inserting the stimulus into the input space (see section 3.4) of the model and execute the simulation. In addition to specifying which stimuli will be presented to the model, an experiment can also add additional direct stimulation (for example current injection) of the model.
Figure 2. The flow of control between the individual Mozaik components. Continuous arrows indicate flow of control between components, while interrupted arrows indicate initialization of component instances. The workflow is initiated from a user script with a single command that hands control to the Mozaik control hub (the experiment controller), which in turn initializes the model and data store based on the parameter files specified on the command line and proceeds with executing the list of specified experiments one by one. Each experiment specifies a list of stimuli, which it sequentially presents to the model, executing the model simulation for each of them. At the end of each stimulus presentation the experiment module receives back the recorded data, which it passes into the data store module. Once all experiments are executed, a script specifying the list of analysis and visualization procedures to be run over the stored data is executed. The analysis and visualization routines directly communicate with the data store via a query interface in order to retrieve and manipulate the stored data.
During simulation execution all raw data and relevant metadata are recorded and stored in the data store, based on the recording specifications that are part of the model's initialization (see section 3.6). At the point when all experiments have been executed, the data store holds all the recordings made during the experiments. At this point control flow returns to the controller module, which proceeds by handing the data store to the analysis and visualization methods, which will add additional analysis data to the data store and visualize them. Once this is done control returns again to the controller module which saves the final data store as the last step of the workflow. At this point the user can find all data including any possible figures in a pre-specified directory. Should he wish he can modify the list of analyses or visualizations to be done and run them on the saved data store without re-executing either the simulations or any previously performed analysis.
In Mozaik we use two different systems for parameterizing components, each serving different roles: one for parameterizations of hierarchies of components using hierarchical configuration files, another for unified explicit parameterizations of data structures supporting a range of parameter specific operations. These parameterizations systems contribute significantly to the level of flexibility Mozaik offers, and play central roles in transmitting metadata between components—one of the major problems Mozaik addresses. The two systems are based around two external packages, (1) parameters (https://github.com/NeuralEnsemble/parameters) and (2) param (https://github.com/ioam/param), which Mozaik further extends.
The parameters package is used to parameterize hierarchies of objects for which the parameters are typically loaded from configuration files, and is thus used mainly in the components related to model specification. Each class in Mozaik that is parameterized via the parameters package has to specify a required_parameters attribute, a dictionary which holds the names and types of the required parameters. For such classes the presence of all the required parameters and the matching of their types with the supplied values is automatically checked. The type of a given parameter can also be ParameterSet, allowing for nesting of parameters, that can be then passed to other class instances created in the given class in a transparent fashion. Overall this allows configuring hierarchies of object in a transparent manner, separating the parameters from the code into human readable configuration files. Furthermore, the parameters package contains several useful operations with the parameter hierarchies, such as parameter references or parameter replacements, that greatly enhance the flexibility of working with such hierarchical specifications (see section 4.5).
The param package offers a way to explicitly declare attributes of a class as parameters, and associate additional information with them such as type, ranges or documentation strings. We extend it further in Mozaik to also declare units and periodicity. The advantage of the param package is that it allows for automation of processes dealing with the parameters due to their explicit declaration and the additional information associated with them, while retaining the standard Python attribute access in programatic context, resulting in more transparent and concise code. Specifically, in Mozaik there are several situations where we deal with large numbers of objects, each uniquely identified by a (potentially different) set of parameters. Often we want to refer to subsets of such collections of objects based on combinations of their parameter values. In Mozaik this happens when we deal with stimuli, with recordings and with analysis data structures. The param package facilitates common handling of these cases, and allows us to supply a single set of methods which provide powerful filtering of collections of such parameterized instances based on their parameter names and their values. As we will demonstrate in section 4 this system greatly enhances the flexibility of access to the records in the data store, allowing for simpler and more concise analysis and visualization code.
input space—defines the geometry of sensory inputs.
sensory input component—defines how sensory input is translated into spiking of the peripheral neurons.
sheet—a population of neurons distributed in 2D space, typically corresponding to a certain type of neurons in a cortical layer.
connectors—a specification of a projection between two sheets of neurons.
The high-level input space API is very general, it basically only stipulates that stimuli are presented to the model at some discrete time steps, are embedded in some kind of vector space and can be added and removed from it. Currently only a single input space is implemented—visual modality, which corresponds to a 2D space with visual field coordinates. For this input space, a range of convenience methods is implemented, making adding, translating and scaling stimuli straightforward.
Each model that contains an input space (it is possible to specify models with no sensory inputs) must also contain a sensory input component that translates the stimulus in input space into spiking of neurons. Each such component declares one or several sheet components that will become the most peripheral neurons of the model, and which can be treated from the perspective of the rest of the model like any other sheet of neurons. The declared sheets of neurons do not have to be the physiologically most peripheral neurons (i.e., photo-receptors), for example the retina/LGN model that is shipped with Mozaik implements an abstract model of the whole pathway from photo-receptors to LGN relay neurons, and it declares only two sheets of neurons, corresponding to LGN ON and LGN OFF cell classes.
The sheet API is also very general, essentially it only declares a population of neurons that are distributed in 2D space, with respect to some coordinates. Multiple classes are derived from the base class that give additional meaning to the coordinates, such as classes that allow specification of cortical magnification factors with respect to visual field coordinates. This allows for more convenient specification of models, using more natural units such as densities, millimeters of cortical space etc., and it ensures automatic conversion of these parameters with respect to connectors or other sheets. Importantly the top level sheet class also contains extensive utility code allowing for specification of what to record, whether to apply some background stimulation, the possibility of adding additional metadata to the sheet that can be later utilized during analysis and plotting and shields from the user all the recording and data handling code.
Finally the high-level Mozaik connector component essentially corresponds to PyNN connectors, however, it allows for utilization of the extra information that is associated with the sheets to parameterize the connectivity, for example the position of the neurons. Indeed, to provide users with optimized connectors, we have created wrappers for all the existing PyNN connectors, which are thus available through the Mozaik connector API. However, on top of this high level API, that allows for writing for any potentially highly optimized connector functionality, we have built a flexible modular connector design. It is composed of two main components—the ModularConnector class, and the ModularConnectorFunction. The latter class defines a distribution of probabilities of connections between the pairs of neurons in the source and target sheets. The former serves as a container that combines multiple ModularConnectorFunction instances into the final probability distribution from which the connections are drawn. Importantly, it also defines how the connections will be drawn from the distribution. The specification of how the different ModularConnectorFunctions are combined is done via a Python expression that contains references to the declared ModularConnectorFunctions, making it very flexible to express different combinations of modular functions (see section 4.1 for an example).
The role of the stimulus component is two-fold, first is the actual generation of the stimulus temporal stream, and second is preservation of the stimulus identity throughout the Mozaik workflow. As we will show below, thanks to the param package these two roles are conveniently unified in a single class.
In Mozaik, each stimulus is a regularly sampled temporal stream of vectors of a certain dimensionality (2D in the case of visual stimuli). Each stimulus explicitly declares all the parameters (using the param package) that uniquely identify the stimulus. Each stimulus overloads a method that returns the vector stream corresponding to the stimulus for an arbitrarily long period of time. Importantly, Mozaik provides mechanisms that allow any class that is parameterized only via the param package parameters to be seamlessly converted into a so called ID object, which is essentially a shell of the original class holding only the parameters identities, their values, and the identity of the original class. This ID object can in turn be seamlessly converted back and forth into a string or the original stimulus instance.
During the recording, all data recorded during a presentation of a given stimulus are annotated with the corresponding stimulus ID object. This means that while only the identity of the stimulus and its parameters are stored with the recordings, at any point during the future processing the original stimulus can be easily recreated down the original vector stream used during the simulation. The identity of the stimulus is further maintained throughout the Mozaik analysis system, when it is passed into all generated analysis structures (see section 3.7 for more details). Last but not least the usage of the param package allows for utilization of the unified filtering functionality to perform searches on sets of records or analysis data structures annotated with the stimuli, based on the stimuli parameters, which allows for easier and more concise expression of analysis and visualization algorithms.
As with most other Mozaik components, the high level experiments API is very simple and general. Each experiment is defined by the list of stimuli that it presents to the model and optionally a list of direct stimulations (i.e., current injection, etc.) that it administers during the duration of the experiment. Importantly, it is assumed that the stimuli are independent of each other—i.e., in real experiments they would be presented in randomized order and/or interleaved with presentation of blank stimuli. After presentation of each stimulus either a blank stimulus is presented or the simulation environment is reset (depending on the user's choice and availability of reset in the PyNN back-end simulator used), thus ensuring the independence of the responses on the order of the stimuli presentation. The length of the blank stimulus presentation is set by the user, and should reflect the dynamics of the model to ensure return of activity to background levels.
The independence of stimuli presentation is one of the central design decisions we took in Mozaik. It is based on the realization that the majority of stimulation protocols in neuroscience can be usefully subdivided into short presentations of independent stimuli, and that this allows for powerful conceptualization of the analysis and visualization code, leading to much more reusable code and a greater level of automation. Note that this does not prevent users from implementing experimental protocols where stimuli are not independent, but at the Mozaik level the user would have to concatenate all the dependent stimuli into one single longer Mozaik stimulus, thus losing some of the utility (but not all) of current Mozaik analysis and visualization components. It is possible that in future, a separate analysis package could be designed for analysis of such time dependent stimuli, but until now our usage of Mozaik did not indicate the necessity of this.
The main role of the storage component is to accumulate recorded data annotated with all relevant metadata, as well as data structures produced during the subsequent analysis. The data store is represented by the class DataStore and is very simple: it essentially maintains two lists to which the recordings and analysis data-structures are added as they are produced. This is done automatically without user intervention. The storage component offers a number of methods to access the stored recordings based on the associated metadata. The storage of recordings is build around data-structures provided by the Neo package, while the analysis data structures (ADSs) will be discussed in section 3.7.
Importantly, the storage component also introduces the concept of views, implemented by the class DataStoreView (DSV), that represents an arbitrary subset of the data in the data store. The DataStoreView interface is identical to a "read-only" version of the DataStore, and thus allows for identical operations to be performed on a data store and its views, while preventing the replication of raw data in memory. The concept of views is utilized in query components, which allow a user to create new views of the data store, based on a given data store or data store view and various criteria, mostly related to associated metadata. Overall the storage components accompanied by the query system offer a powerful way to organize and filter data, which allows for highly flexible and reusable implementation of analysis and visualization components, as will be demonstrated below.
A common way to implement analysis code is to specify methods that accept as input the data to be analyzed, in the form of data structures that are suitable for the given analysis. This allows for easier implementation of said analysis algorithm, but leaves a bigger burden to the future users as they will have to carefully study the input specification of each analysis method and often write a non-trivial amount of code that translates the data from their current form to the data structures required by the given analysis.
Given that the goal of Mozaik is automation and reduction of boiler-plate code, we have decided to shift the complexity from the usage of the analysis code to its implementation. Thus the high-level analysis API is extremely general—it essentially specifies that the input of each analysis is a DataStoreView instance. It is the role of the given analysis class to filter out the widest range of data from the data store view to which it can be applied. The results of analyses are ADSs that are stored back into the data store, to become potential future inputs to subsequent analysis or visualization steps.
identifier—which essentially corresponds to the given ADS class name.
analysis_algorithm—set to the algorithm that produces the specific ADSs instance.
sheet_name—sheet with which this ADS is associated.
neuron—neuron with which this ADS is associated.
stimulus_id—stimulus with which this ADS is associated.
The latter three parameters can also be set to None. For example if neuron is set to None it means that the ADS is not associated with a single neuron (i.e., when it holds population average results). Users can add new ADSs as required; however, they are encouraged to re-use existing ADSs whenever possible, as this allows for potentially more of the already implemented analysis and visualization methods to be applicable to the given results. So far our experience was that a wide range of analysis results can be expressed with very few different ADSs.
The parameters in the ADSs function as metadata that identify the content of the ADS. When specifying a new ADS it is important to think of all parameters that might be required to identify the results in the data store. In the same way, whenever a new analysis method is implemented, the developer has to make sure to use ADSs that are suitable for holding the results of the said analysis and set all parameters that are required to identify the results in the data store. Altogether this makes the process of writing new analysis methods somewhat more involved; however, as we will demonstrate in the following section, it leads to a very flexible and reusable analysis system, requiring a minimal amount of code from the end user.
The philosophy of the visualization package is similar to that of the analysis sub-package. The input of each visualization method is a DSV. The role of each visualization method is to extract as much data as possible from the provided DSV and display as much information as possible with respect to its visualization role. It is thus up to the user to filter the data store before passing it to the plotting function to select the information that is plotted.
Beyond the flexibility of input, the other major design goals were to support hierarchical definition of figures, and separation of the "appearance" aspects of plotting from the rest of the visualization functionality. To achieve this the visualization package is divided into two separate APIs, represented by two high-level classes Plotting and SimplePlot, the former representing the high-level hierarchical functionality, while the latter represents low-level plotting.
The implementation of the Plotting API is based on matplotlib (Hunter, 2007) and its GridSpec objects. The Plotting API is mainly responsible for hierarchical organization of figures with multiple plots, any mechanisms that require consideration of several plots at the same time, and the translation of the data from the general format provided by DSVs, to any specific format that the low-level SimplePlot classes require. In general the Plotting instances do not do any plotting of axes themselves, but instead call the SimplePlot instances to do the actual drawing. Each class that was derived from Plotting derived from plotting can itself contain several other Plotting or SimplePlot references. Essentially each figure in Mozaik is a tree, whose inner nodes are Plotting instances and leaves are SimplePlot instances. Each Plotting instance contains a GridSpec object, that defines how the figure space at that level of hierarchy is separated between the children components. This allows for very concise and flexible constructions of complex figures with multiple plots.
The SimplePlot API represent low-level plotting. Each SimplePlot represents only a single matplotlib axis that is drawn into the region defined by the GridSpec instance that is passed into it. The high-level SimplePlot API offers a range of mechanisms to control the detailed look of the plot. When defining a new SimplePlot class the user is encouraged to use, as much as possible, the decorating mechanisms provided by the high-level SimplePlot API. This ensures a unified look for all Mozaik figures, while maintaining a good appearance for new plots with a minimal amount of code.
We will now walk through an example Mozaik project to demonstrate how the design principles discussed in the previous sections translate into a real-world scenario. The following project creates a simple model of visual cortex (see Figure 3), probes it with a standard stimulation protocol using sinusoidal gratings, and applies several analysis and visualization algorithms commonly performed in visual cortex.
Figure 3. The architecture of the model presented in section 4. The model consists of two thalamic layers, corresponding to ON and OFF cell types (C), and a single cortical layer of excitatory and inhibitory cells, whose afferent receptive fields are generated drawn from a Gabor-shaped probabilistic distribution, whose parameters are based on an orientation map (B). The connectivity between cortical neurons is set to have push-pull connectivity, i.e., excitatory neurons selective to a certain orientation and phase connect with a higher likelihood to other excitatory or inhibitory neurons preferring the same orientation and phase, while inhibitory neurons are more likely to connect to excitatory and inhibitory cells preferring the same orientation but opposite phase (A).
Here we specify two connectors corresponding to the connections from neurons in the excitatory sheet to other neurons in the excitatory and inhibitory sheets (the parameters L4ExcL4ExcConnection and L4ExcL4InhConnection). Each connector allows the user to specify the short term plasticity model to be used for the synapses. The L4ExcL4ExcConnection connector uses the Mozaik modular connector specification, which allows the user to specify a number of connector functions to determine the weights and delays of connections (the weight_functions and delay_functions parameters). The connector functions are then combined in the weight_expression and delay_expression parameters to determine the distributions of delays and weights.
Here we define two connector functions for weights, one specifying that neurons are connected in a push–pull manner with respect to the orientation of their receptive field (see Figure 3A), while the second connector function specifies that the connection probability between neurons falls off with distance following a hyperbolic function (see Figure 3B). By specifying the weight_expression as a multiplication between the two connector functions we effectively say that the probability of the connections of neurons will be falling of with distance, while with respect to orientation similarly-oriented neurons will be more probably connected. In this connector we want to have all connection delays be a constant of 2 ms, which we can simply express by setting the delay_expression parameter to 2, without specifying any connector functions for delays.
The specification of the L4ExcL4InhConnection connector parameter demonstrates another feature of the configuration system: references. In this example we want the connections from excitatory to inhibitory neurons to follow the same rules. Therefore instead of repeating the whole configuration structure specified for the L4ExcL4InhConnection we simply give a reference to it.
Apart from supporting more concise model specifications, the references can also be combined in simple Python expressions as demonstrated in the parameter weight_factor of the AfferentConnection connector specification. Here we say that the weights of this connector should be twice as strong as those of the lateral connections. This provides a very flexible way of defining the most common relationships between model parameters and, as will be demonstrated in section 4.5, greatly simplifies the specification of parameter search protocols.
Essentially all this code does is to initialize the individual sheets and then use them to initialize the individual connectors. It should in principle be possible to automate the above code, and thus we plan that in future releases of Mozaik the user will be able to skip this configuration step altogether.
Here we tell Mozaik to perform three experiments: one during which there is no stimulation (which effectively means we measure spontaneous activity); one where we perform a full-field orientation tuning protocol; and one in which we show a natural image movie with simulated eye movements.
Running the above command hands control to Mozaik, which will proceed to execute each of the specified experiments while recording all the specified variables. All recorded data will be annotated with relevant metadata and stored in a central data-store that is handed back to the user for subsequent analysis and visualization. Mozaik will report the progress of the stimulation, by logging the number of already executed experiments and presented stimuli at the end of each stimulus presentation. This log is by default routed both to the standard output and a file.
Here we demonstrated simple filtering queries, but Mozaik offers a number of other query methods providing more complex data manipulation, such as collation of data with respect to selected parameters. These significantly simplify the expression of a range of visualization and analysis algorithms.
Now that we have explained how to access and filter data in data-store we can proceed to explain the analysis and visualization system. To remind the reader, the input to each analysis or visualization method is a DSV, they should always try to apply themselves to the largest possible subset of DSVs, and the analysis methods produce ADSs that are put back into the data store to become inputs for subsequent analysis and visualization. This, combined with rich annotation of recorded data, ADSs with metadata and the query system, allows for a powerful, flexible, and unified way of modifying the behavior of the analysis and visualization process.
Figure 4. The figures produced by the example visualization commands in section 4.4 (see text). (A) The result of the first command, plotting only the data acquired during presentation of vertically and horizontally-oriented gratings. (B) The result of the second command, plotting data acquired during presentation of all grating orientations (four, in this case). In both plots, each column shows recordings in response to a grating of the orientation indicated at the top. The top panels show the spike rasters for the five times each stimulus was presented. The middle panel shows the excitatory (red) and inhibitory (blue) conductances recorded during the stimulus presentation; the pale lines show single trial traces while the thick saturated lines show the trial average trace. The bottom panels show the membrane potential traces recorded during the stimulus presentation; the gray lines showing the single trial traces while the black line shows the trial averaged trace.
In the above two examples the first line restricts the data store to the set of responses we wish to visualize, while the second line is a basic visualization method that shows the raw responses to each stimulus recorded in the data store.
while this is how one would compute trial-averaged firing rates only for neurons in a sheet named V1_Exc_L4 and only due to a FullfieldDriftingSinusoidalGrating stimulation.
Behind the scenes, this code creates a number of ADSs—one per stimulus—holding the average firing rates of individual neurons, and adds them back into the data store. These analysis data structures are annotated with metadata such as the identity of the stimulus with which they are associated, allowing for their identification using the query system.
Figure 5. Example of tuning curve plotting. Responses of four neurons in responses to optimally oriented drifting sine-gratings disks confined to an aperture of varying diameter (A). Responses of the same four neurons as in (A) to optimally oriented full-field drifting sine-gratings of varying contrast (B). Firing rates were calculated as spike counts during the one second stimulus presentation and averaged over ten trials. The aperture diameter is in degrees of visual field.
Note that the PlotTuningCurve visualization function is agnostic to how the values it is plotting have been computed and through which parameter we want to plot the tuning curve. It simply expects a set of ADSs in the datastore view (specifically ADSs of type PerNeuronValue, which hold a single scalar value per neuron) which are associated with the same kind of stimulus but with varying values of its parameters. By telling it through which parameter we want to plot the tuning curve it has all the information required to perform the task. Furthermore, because the PerNeuronValue ADS holds other useful metadata, such as the name of the value that it stores, and the units in which it was measured, the PlotTuningCurve can use these to populate the plot with all this contextual information. This demonstrates how our system allows for specification of very general operations that can be used in a broad range of contexts, making them much more reusable.
Here the first parameter specifies which job scheduling back-end to use (here the back-end for Slurm (Jette et al., 2002)), and the second parameter is a dictionary with parameter paths as keys and lists as values. Thanks to the possibility of using references in parameter files, it is very easy to express relationships between parameters such as keeping a balance between excitatory and inhibitory weights constant while varying its magnitude, etc. The above code will schedule 25 simulations with all combinations of values of the two selected parameters. All the results will be stored in a master directory together with extra information about the parameter search that can be used for further processing of the data. Data from each simulation is stored in a separate sub-directory, together with any figures produced during the given simulation run.
Here the first two parameters identify the model that was run and the master directory in which the parameter search data were stored, the third parameter is a query instance that will be applied to filter out data from data-stores produced during each of the individual simulation runs, and the last parameter specifies the name of the file into which to save the resulting figure. The single_value_visualization method assumes that the individual data-stores were populated during the analysis with SingleValue ADSs (which, as the name indicates, hold a single scalar value). It will automatically collate the data and show the value held in the SingleValue ADSs as a function of the varied parameters. If multiple SingleValue ADSs with different value_name parameters were produced during the analysis, it will automatically create multiple subplots, one for each of the encountered values of the parameter value_name. If the analysis script for the model demonstrated in this section contained analyses that created SingleValue ADSs with value_names parameter set to "Mean(firing rate)" and "Mean(CV of ISI squared)", the above command would produce a figure such as the one shown in Figure 6.
Figure 6. Example of automatic plotting of parameter search results. Method single_value_visualization plots the values from SingleValue ADSs as a function of the parameters that were varied (see the axis labels in the plots which specify the full path of the parameter in the parameter hierarchy), creating one subplot for each value of parameter value_name (see titles of the subplots). In this specific example we ran a simulation of the Vogels and Abbott (2005) model, while varying the strength of excitatory and inhibitory synapses in the network. For each combination of values of these two parameters the network's mean firing rate and mean square of coefficient of variation of inter-spike intervals (CV of ISI) were calculated, thus providing a single value measure for each network parameterization. The plot on the left shows the mean firing rate as a function of the varied parameter values, while the plot on the right shows the mean square of CV of ISI measure.
Overall these examples demonstrate how seamlessly different components of Mozaik integrate, and the level of automation that is achievable thanks to this integration. We would like to emphasize that the extreme flexibility and broadness of the commands demonstrated in this sub-section critically depends on three of the defining features of Mozaik: the parameterizations system, the ADS system, and the rich metadata with which the various data structures are annotated throughout the Mozaik workflow.
In this article we have presented Mozaik, a Python-based integrated workflow framework for spiking neuronal simulations. Much of the effort in detailed modeling projects in computational neuroscience is in managing the workflow and moving data and metadata between different simulation, analysis and visualization tools. Mozaik eliminates much of this effort by providing a framework that takes care of most of these low-level details, leaving the modeler to focus on the high-level concepts of models and experiments.
Mozaik leverages several broadly used neuroscience Python tools, thus increasing interoperability between current and future tools as well as increasing the possibility of replacing in future some of the Mozaik components with dedicated tools. Long-term, conditional on the continued convergence of neuroscience tools around common standards, the goal is for Mozaik to serve only as a glue between existing dedicated tools.
Mozaik is being used in real life modeling projects, and its scalability has been tested in a distributed HPC environment, both with large-scale network models (>105 neurons and >108 synapses) and large parameter searches (106 independent simulation instances).
Since Mozaik uses PyNN to access simulator engines, the underlying speed of a Mozaik simulation run will inevitably depend on the performance of PyNN and, more importantly, the simulator backend selected for the given simulation. However, naturally, with the extra functionality Mozaik provides, it introduces extra overhead. To verify that this overhead is acceptably small, we have performed several test runs using the NEST simulator (currently the state of the art in large-scale point neuron simulation). As a benchmark we have selected the Vogels and Abbott (2005) model, an implementation of which is shipped with PyNN. This model does not require any sensory stimulation, which allows for a fair comparison between the pure PyNN and the Mozaik implementations, as sensory stimulation, which is handled by Mozaik, would in the case of a pure PyNN simulation have to be implemented by the user, thus not providing a well defined comparison reference. We ran both the Mozaik and pure PyNN simulations ten times with two different population sizes and the same number of synapses per neuron (10,000 and 100,000 neurons and ~200 synapses per neuron). For the smaller population size the mean run time of the pure PyNN implementation was 64.6 s (SD = 2.3) vs. 72.8 s (SD = 0.7) for the Mozaik implementation, indicating an overhead of about 13%. However, for the simulation of large populations the mean run time of the pure PyNN implementation was 1106.1 s (SD = 11.3) vs. 1123.5 s (SD = 5.8) for the Mozaik implementation, meaning that the overhead was now reduced to only 1%. Given that the Mozaik project is intended for large-scale simulations, we conclude that the overhead introduced is acceptable.
During the implementation of Mozaik it became clear that the most critical aspect of integrating the different aspect of the neuronal simulation workflow is the handling of metadata. In majority of Mozaik's components, notably in the analysis, visualization, and experimental protocol modules, the rich annotation of data-structures with metadata that flow between the components was instrumental in achieving the level of automation and flexibility demonstrated here. Unfortunately, there does not currently exist a common standard for interpretation of metadata in neuroscience (and more specifically in computational neuroscience). This lack of standard limits the ease of integration of current neuroscience tools, including Mozaik, as even though tools are able to exchange raw data thanks to common data formats such as those provided by the Neo package, the interpretation of metadata has to still be reconciled on an individual basis. It is the belief of the authors that creation of a common standard capturing the semantics of metadata is the next key technological advance that is required in the neuroscience community to achieve sufficient integration between the various tools.
As is clear from its architecture, Mozaik is a package that will be continuously developed and extended, and great care was put into its design to allow for ease of such incremental development. Specifically, the typical user will probably develop their own model components, stimuli, experimental protocols, analysis and visualization methods. We hope that users will contribute these additions back to the core Mozaik project, which will thus be able to provide a growing library of such resources. Furthermore, even the core API is likely to be changed in future as some parts of Mozaik will be taken over by dedicated tools, or forked out into independent packages. An example of such planned future changes is the replacement of the Mozaik datastore with dedicated database software, or linking of the Mozaik stimulus interface to one of the existing Python-based stimulation packages used in biological experiments. Finally, one of our short-term plans is the addition of a dedicated GUI for the analysis and visualization steps of the workflow and/or integration of Mozaik with one of the analysis and visualization libraries that are taking shape in the field.
This work was supported by European Union projects FP7-269921 (BrainScaleS) and FP6-015879 (FACETS).
Thanks to Domenico Guarino for comments on this manuscript and for assistance with some of the figures. Jens Kremkow made important contributions to an earlier version of the Mozaik concept.
Davison, A. P., Brizzi, T., Estebanez, L., Jaillet, F., Mahnoun, Y., Rautenberg, P., et al. (2011). "Neo: representing and manipulating electrophysiology data in Python," in Proceedings of EuroSciPy 2011 (Paris).
Jette, M. A., Yoo, A. B., and Grondona, M. (2002). "SLURM: simple linux utility for resource management," in Lecture Notes in Computer Science: Proceedings of Job Scheduling Strategies for Parallel Processing (JSSPP) 2003 (Berlin: Springer-Verlag), 44–60.
Scripps, S. T., and Sanner, M. F. (1999). Python: a programming language for software integration and development. J. Mol. Graph. Mod. 17, 57–61.
Accepted: 22 November 2013; Published online: 10 December 2013.
Copyright © 2013 Antolík and Davison. This is an open-access article distributed under the terms of the Creative Commons Attribution License (CC BY). The use, distribution or reproduction in other forums is permitted, provided the original author(s) or licensor are credited and that the original publication in this journal is cited, in accordance with accepted academic practice. No use, distribution or reproduction is permitted which does not comply with these terms.


For those who want to teach biblical worldview to home school students, this is for you. Your students will learn the foundations of their faith, how do identify worldviews through movies and books. They will be reading an outside book, writing papers and learn how to live out and effectively communicate the gospel. We require the teacher to become an Anchorsaway trained teacher before teaching it. You will then be able to purchase the curriculum here and then download it, print it and you are ready to go. Students will receive dual credit if desired.


Order of oil filter and oil cooler.
tarago diff question auto manual ???
AE82 Twinky and AE93 P/Steering pump assy the same?
Need long tie rod ends...... Suggestions?
Recaro rails - what do you think of these custom ones?


text:
class PlainHtmlController < ApplicationController
  def self.plain_html?; true; end
end

redpajama_set_name: RedPajamaGithub


Celebrate your fandom with this Cheer ponytail hair bow. This Southern Miss Golden Eagles-themed hair tie adds just the right amount of lovely team spirit to your outfit with team-inspired graphics on a pre-tied bow that's attached with corded band for a secure fit. With this sporty hair tie, your Southern Miss Golden Eagles game day outfit will finally be complete!
Southern_Miss_Golden_Eagles_Cheer_Ponytail_Hair_Bow http://images.fanatics.com/lf http://dmimages.ff.p10/chains/1805937.txt false We are unable to customize this item with the text you have entered. Please try a different entry again. Your current entry cannot be processed due to guidelines for past and present player names. Please create a new entry.


In response to repeated prodding by the General Accounting Office and other government watchdogs, the House Budget Committee is calling for creation of a special commission to crack down on improper payments by government agencies.
Among dozens of programs that are part of the federal social safety net, the EITC, Medicare for seniors and Medicaid for the poor and disabled accounted for 78 percent of total improper payments, according to the latest figures from GAO, with error rates of 24 percent, 11 percent and 10 percent respectively.
As part of a controversial $4 trillion budget blue print for fiscal 2018 unveiled by Republican House Budget Committee Chair Diane Black of Tennessee on Tuesday, a new special commission would be given oversight power with a mandate to slash future improper payments by 50 percent within five years.
The budget document estimates that the new commission could reduce improper payments and save taxpayers $700 billion over the coming decade. The House budget document also puts a premium on action by the new commission and other internal government watchdogs to streamline government to eliminate duplicative services and activities.
According to a House Budget Committee analysis, there are 92 anti-poverty programs with overlapping or duplicative responsibilities that spent a total of $843 billion in fiscal 2015. For example, the analysis found 25 duplicative education and job training programs, 17 overlapping food assistance programs and 21 veterans programs.
A 2014 study found that it took 10 different offices at the Department of Health and Human Services to operate programs that addressed AIDS in minority communities, while autism research was spread over 11 different agencies.
Whether a new commission can prove any more effective than the GAO and a multitude of federal agency inspectors general in reining in billions of dollars of wasteful spending – or whether it would be little more than political window dressing – remains to be seen.
Many of Trump's Democratic and Republican predecessors, including former presidents George W. Bush, Bill Clinton and Barack Obama, proposed major changes to improve the quality of government and reduce wasteful spending that had varying degrees of success.
However, changing the way the federal government does business and cracking down on fraud and waste is a herculean task that requires changes in politically sensitive programs like Medicare and Medicaid and an enormous amount of bipartisan cooperation and good will that is sorely lacking in Washington today.
A lack of bipartisanship was clearly on display on Wednesday, when Republican and Democratic Budget Committee members began debating the fiscal 2018 budget resolution, which calls for a major tax cut that would largely benefit the wealthy, a huge boost in defense spending and a sharp reduction in domestic programs important to the Democrats.
The most contentious provision seeks at least $203 billion of cuts over the coming decade in mandatory programs such as Medicare and Social Security.
Some Democrats have dismissed proposals for eliminating waste and fraud as Republican cover for attacking important entitlement programs.
"The enormity of these cuts and the severity of the consequences for American families cannot be overstated," he added.


text:
Lanthanum Strontium Cobaltite Ferrite (LSCF)- Gadolinium Doped Ceria (GDC)
La0.6-0.78Sr0.2-0.4Co0.2Fe0.8O3 / Gd2O3 / CeO2
LSCF-GDC Ink
LSCF-GDC-01-I
LSCF-GDC Powder
LSCF-GDC-01-P
CUSTOMER ADVISORY: American Elements does not supply gadolinium for use in ANY form of GBCA ("Gadolinium-Based Contrast Agents") or for ANY medical, pharmaceutical or nutritional use whatsoever or for the manufacture, testing, or development of ANY such products.
Lanthanum Strontium Cobaltite Ferrite (LSCF)- Gadolinium Doped Ceria (GDC) Health & Safety Information
About Lanthanum Strontium Cobaltite Ferrite (LSCF)- Gadolinium Doped Ceria (GDC)
American Elements specializes in producing lanthanum strontium cobaltite ferrite for fuel cell cathode applications utilizing solid state processing to produce single phase perovskite structures with various doping levels and surface areas (SSA) for use in thin film layers. Upon firing, American Elements' Lanthanum Strontium Cobaltite Ferrite will partially sinter to form well-defined necks and open gas paths to permit simultaneous gas and electrical transfer. Lanthanum Strontium Cobaltite Ferrite has an excellent thermal expansion match with Yttria Stabilized Zirconia (YSZ) electrolytes. It is highly electronically conductive and has proven long term stability. Lanthanum Strontium Cobaltite Ferrite belongs to a class of "A" site and "B" site doped perovskite structures with these properties. These include Lanthanum Strontium Manganite (LSM), Lanthanum Strontium Ferrite (LSF), Lanthanum Calcium Manganite (LCM), Lanthanum Strontium Chromite (LSC), and Lanthanum Strontium Gallate Magnesite (LSGM). Lanthanum Strontium Cobaltite Ferrite is available as a powder for tape casting, air spray/thermal spray/plasma spray, extrusion and sputtering fuel cell applications and as an ink for screen printing. Strontium doping levels are available at 10% and 20% and as specified by customer. Oxygen starved compositions are available. American Elements provides guidance on firing parameters, doping levels, and thermal expansion matching with American Elements' electrolyte and interconnect fuel cell layers. gadolinia doped ceria (GDC), cerium oxide stabilized by various doping levels of gadolinium oxide, a material that upon firing forms a highly ionically conductive thin film electrolyte layer for use in solid oxide fuel cell electrochemistry structures. Gadolinium Oxide doped Ceria belongs to a class of doped Ceria compounds with ionic conductivity exceeding Yttria Stabilized Zirconia (YSZ) electrolytes. These include Samarium doped Ceria (SDC) and Yttria doped Ceria (YDC). Even higher conductivity can be achieved with American Elements Scandia doped Zirconia (SCZ) and Yttria doped Bismuth Oxide. Gadolinium Oxide doped Cerium Oxide is available in a powder for tape casting, air spray, extrusion and sputtering fuel cell applications and as an ink for screen printing. Gadolinia doping levels are available at 10% and 20% and as specified by customer. American Elements provides guidance on firing parameters, doping levels, and thermal expansion matching with American Elements' cathode and anode cell layers.
Lanthanum Strontium Cobaltite Ferrite (LSCF)- Gadolinium Doped Ceria (GDC) Synonyms
LSCF-GDC, Lanthanum Strontium Cobalt Ferrite - Gadolinia doped ceria
Customers For Lanthanum Strontium Cobaltite Ferrite (LSCF)- Gadolinium Doped Ceria (GDC) Have Also Viewed
Lanthanum Strontium Cobalt Ferrite (LSCF)
Lanthanum Strontium Ferrite (LSF)
Lanthanum Strontium Manganite - Gadolinium Doped Ceria
Barium Strontium Cobalt Ferrite
Lanthanum Strontium Cobalt Ferrite Paste
Lanthanum Strontium Cobalt Ferrite Sputtering Target
Gadolinia doped Ceria (GDC)
Samarium Strontium Cobalt Oxide Nanoparticle Dispersion
Yttrium Iron Oxide Nanoparticle Dispersion
Related Applications, Forms & Industries for Lanthanum Strontium Cobaltite Ferrite (LSCF)- Gadolinium Doped Ceria (GDC)
Additive Manufacturing & 3D Printing Ceramics Ferrites
Fuel Cells Oxides Rare Earths
58 Ce 140.116000000 Cerium
See more Cerium products. Cerium (atomic symbol: Ce, atomic number: 58) is a Block F, Group 3, Period 6 element with an atomic weight of 140.116. The number of electrons in each of cerium's shells is 2, 8, 18, 19, 9, 2 and its electron configuration is [Xe]4f2 6s2. The cerium atom has a radius of 182.5 pm and a Van der Waals radius of 235 pm. In its elemental form, cerium has a silvery white appearance. Cerium is the most abundant of the rare earth metals. It is characterized chemically by having two valence states, the +3 cerous and +4 ceric states. The ceric state is the only non-trivalent rare earth ion stable in aqueous solutions. It is, therefore, strongly acidic and moderately toxic. It is also a strong oxidizer. The cerous state closely resembles the other trivalent rare earths. Cerium is found in the minerals allanite, bastnasite, hydroxylbastnasite, monazite, rhabdophane, synchysite and zircon. Cerium was discovered by Martin Heinrich Klaproth, Jöns Jakob Berzelius, and Wilh elm Hisinger in 1803 and first isolated by Carl Gustaf Mosander in 1839. The element was named after the asteroid Ceres.
27 Co 58.933195000 Cobalt
See more Cobalt products. Cobalt (atomic symbol: Co, atomic number: 27) is a Block D, Group 9, Period 4 element with an atomic weight of 58.933195. The number of electrons in each of cobalt's shells is 2, 8, 15, 2 and its electron configuration is [Ar] 3d7 4s2The cobalt atom has a radius of 125 pm and a Van der Waals radius of 192 pm. Cobalt was first discovered by George Brandt in 1732. In its elemental form, cobalt has a lustrous gray appearance. Cobalt is found in cobaltite, erythrite, glaucodot and skutterudite ores. Cobalt produces brilliant blue pigments which have been used since ancient times to color paint and glass. Cobalt is a ferromagnetic metal and is used primarily in the production of magnetic and high-strength superalloys. Co-60, a commercially important radioisotope, is useful as a radioactive tracer and gamma ray source. The origin of the word Cobalt comes from the German word "Kobalt" or "Kobold," which translates as "goblin," "elf" or "evil spirit." For more information on cobalt, including properties, safety data, research, and American Elements' catalog of cobalt products, visit the Cobalt element page.
64 Gd 157.250000000 Gadolinium
See more Gadolinium products. Gadolinium (atomic symbol: Gd, atomic number: 64) is a Block F, Group 3, Period 6 element with an atomic radius of 157.25. The number of electrons in each of Gadolinium's shells is [2, 8, 18, 25, 9, 2] and its electron configuration is [Xe] 4f7 5d1 6s2. The gadolinium atom has a radius of 180 pm and a Van der Waals radius of 237 pm. Gadolinium was discovered by Jean Charles Galissard de Marignac in 1880 and first isolated by Lecoq de Boisbaudran in 1886. In its elemental form, gadolinium has a silvery-white appearance. Gadolinium is a rare earth or lanthanide element that possesses unique properties advantageous to specialized applications such as semiconductor fabrication and nuclear reactor shielding. It is utilized for both its high magnetic moment (7.94μ B) and in phosphors and scintillator crystals. When complexed with EDTA ligands, it is used as an injectable contrast agent for MRIs. The element is named after the Finnish chemist and geologist Johan Gadolin.
26 Fe 55.845000000 Iron
See more Iron products. Iron (atomic symbol: Fe, atomic number: 26) is a Block D, Group 8, Period 4 element with an atomic weight of 55.845. The number of electrons in each of Iron's shells is 2, 8, 14, 2 and its electron configuration is [Ar] 3d6 4s2. The iron atom has a radius of 126 pm and a Van der Waals radius of 194 pm. Iron was discovered by humans before 5000 BC. In its elemental form, iron has a lustrous grayish metallic appearance. Iron is the fourth most common element in the Earth's crust and the most common element by mass forming the earth as a whole. Iron is rarely found as a free element, since it tends to oxidize easily; it is usually found in minerals such as magnetite, hematite, goethite, limonite, or siderite. Though pure iron is typically soft, the addition of carbon creates the alloy known as steel, which is significantly stronger.
38 Sr 87.620000000 Strontium
See more Strontium products. Strontium (atomic symbol: Sr, atomic number: 38) is a Block S, Group 2, Period 5 element with an atomic weight of 87.62 . The number of electrons in each of Strontium's shells is [2, 8, 18, 8, 2] and its electron configuration is [Kr] 5s2. The strontium atom has a radius of 215 pm and a Van der Waals radius of 249 pm. Strontium was discovered by William Cruickshank in 1787 and first isolated by Humphry Davy in 1808. In its elemental form, strontium is a soft, silvery white metallic solid that quickly turns yellow when exposed to air. Cathode ray tubes in televisions are made of strontium, which are becoming increasingly displaced by other display technologies pyrotechnics and fireworks employ strontium salts to achhieve a bright red color. Radioactive isotopes of strontium have been used in radioisotope thermoelectric generators (RTGs) and for certain cancer treatments. In nature, most strontium is found in celestite (as strontium sulfate) and strontianite (as strontium carbonate). Strontium was named after the Scottish town where it was discovered.
Fabrication of Lanthanum Strontium Cobalt Ferrite-Gadolinium-Doped Ceria Composite Cathodes Using a Low-Price Inkjet Printer.
Niobium Doped Lanthanum Strontium Ferrite as A Redox-Stable and Sulfur-Tolerant Anode for Solid Oxide Fuel Cells.
Highly transparent cerium doped gadolinium gallium aluminum garnet ceramic prepared with precursors fabricated by ultrasonic enhanced chemical co-precipitation.
Development of europium doped core-shell silica cobalt ferrite functionalized nanoparticles for magnetic resonance imaging.
Crystallographic and electronic evolution of lanthanum strontium ferrite (LaSrFeO) thin film and bulk model systems during iron exsolution.
Study of structural and magnetic properties and heat induction of gadolinium-substituted manganese zinc ferrite nanoparticles for in vitro magnetic fluid hyperthermia.
Doxorubicin hydrochloride - Loaded electrospun chitosan/cobalt ferrite/titanium oxide nanofibers for hyperthermic tumor cell treatment and controlled drug release.
Yeast-template synthesized Fe-doped cerium oxide hollow microspheres for visible photodegradation of acid orange 7.
Efficiencies and mechanisms of ZSM5 zeolites loaded with cerium, iron, or manganese oxides for catalytic ozonation of nitrobenzene in water.

redpajama_set_name: RedPajamaCommonCrawl


Last week we reviewed my 2015 goals (see post here) so today I'm back to share my goals for 2016. My main goal this year is just to focus on my happiness. Last July my boyfriend of 5+ years and I split up. It was mutual and the best thing for the both of us. Of course it was a hard decision, but I've been so much happier ever since. Not to sound cheesy, but it's been a great opportunity to discover myself and what I want in life. So for me, 2016 is about doing what makes me happy and bettering myself (for myself, not for anyone else). Of course I did make a few tangible goals this year too. They are mostly just a carryover from last year, but they are still applicable, so I'm keeping them.
Last year two of my goals were to landscape the backyard and finish at least one of the rooms I'd already started (living room, laundry room, office, craft room, and master bathroom). I didn't complete either of those goals, so I'm carrying them over to 2016.
Another goal from last year was to do more crafts and small projects. I didn't do very well on that goal last year, but I'm bringing it back this year because I really want to spend more time crafting and creating this year. I really do enjoy project time and want to focus more on it this year.
Like most people, my goal this year (and every year) is to be more active/eat healthier. Last summer I got a gym membership and started taking Zumba classes a couple times a week. I slacked off during the holidays, but I want to get back into that. This isn't just about traditional exercise and gym time though. It could be anything from hiking to walking the dogs around the neighborhood. For example, on Saturday I went to the zoo with my friend and we walked at least a couple miles. It was a fun way to spend the afternoon and get some extra steps in. I also started walking on the treadmill while I talk on the phone with my mom. It's been a great way to get an extra mile worth of steps in my day.
And of course eating healthier has to be on the list…I say this as I'm eating a cookie…Anyway, I really want to find the balance between eating healthy, but still making it enjoyable. I love food and I really enjoy going out to restaurants and trying new dishes. It's one of my favorite things, but I also enjoy fitting in my jeans. So I'm really going to work this year on finding healthier alternatives and eating smaller portions of those unhealthy dishes that I love, but probably shouldn't eat. This will also be a great chance to try out some new healthy recipes. I have a few that I really love, but I need more of a variety.
Darn, I'm sorry you and your boyfriend broke up. Even when it's mutual it's hard.
I've posted about Zumba a couple of times. I'm addicted!! We've gone through some very tough times in our family in the last three years. No matter how crappy my day is...Zumba makes it better.
I will love you long time no matter what! Dude. If you have a fit bit... we should be fit bit friends!
Also, I'm creeping on your blog deep because I've lost my life to work lately.


Small Business Branding: Is it a Luxury?
Every company is born as a small business. Many start out by creating a service or product, giving themselves a catchy name and perhaps a logo. They will try to save a few bucks by creating a "free" website themselves, run ads in the local newspaper, monthly magazine, and maybe even radio. Sometimes, they run an event or develop a promotion to spread the word of their existence.
any small businesses fall short when they develop their marketing efforts without a plan. They tend to hire a designer for their logo, find a web developer for their website and then choose a magazine design department to develop their ads for the magazine. The problem with this is that these marketing elements never integrate, and this leaves their brand scattered. The business owner does the best they can to manage these functions until they become large enough to hire a marketing manager and maybe an agency to develop all their marketing and advertising efforts.
A smarter, long term approach is invest in a branding or re-branding study that identifies who they are, what they stand for, and what their point of difference is to their competition.
Brand studies deliver a brand document consisting of the brand's DNA, a brand vision, and a brand position. The brand DNA is developed from the company's core values, products and/or services, and intended personality. All content is distilled into the brand's soul. The brand's DNA is what truly differentiates the small business from their competition.
The brand vision is who you are as a brand. It's developed from what you offer, what you stand for, what makes you unique, and how you will succeed within your category. It makes you relevant among your target customers, remains consistent with your vision of success, and leads you to a winning future. It is realistic, sustainable, focused, and provocative.
Once the brand vision has been developed, the business can begin to craft their marketing elements. These components include a name, logo, website, and advertising…all built, designed, and integrated to deliver a distinctive brand identity.
A cohesive brand is the one thing that uniquely identifies a company and its products. It differentiates a company from their competition and enhances perceived value, quality, and satisfaction experienced by the customer. Integrated branding provides a springboard for new products, contributes to long-term demand, and maximizes profitability.
Many small business owners never realize the importance of Brand Architecture and what it means to sustaining growth and creating synergy across the company. The question they should ask themselves is: am I a Master Brand, a Trustmark Brand or a Portfolio Brand? If they know the answer to that question, they are smarter that 90% of all small businesses.
The companies that make an investment in branding will take market share from their competition and find significant success as they grow their business.


Donald Trump's latest Cabinet pick may be his most important to date. Elaine Chao, who served as President George W. Bush's head of the Department of Labor, will be stepping into the role of secretary of Transportation, according to an email statement from the presidential transition team. And she'll have a lot of work to do under the new administration. She's made history as the first Asian-American woman to serve on a presidential Cabinet and proven herself a competent bureaucrat, but there's a high-stakes, trillion-dollar question looming over this newest announcement. Will Chao support Trump's infrastructure plan? It's very likely, since she's agreed to take the position, but how she follows through on Trump's plan will define her tenure.
As secretary of Transportation, Chao will have a huge job overseeing Trump's controversial proposal to invest $1 trillion in infrastructure over the next 10 years. Back in August, Trump said he wants to "build the next generation of roads, bridges, railways, tunnels, sea ports, and airports," which would generally fall under Chao's purview as head of the Department of Transportation.
As secretary, she'll oversee the Federal Aviation, Highway, Railroad, Transit, and Maritime Administrations in collecting data and making recommendations on how best to improve these resources. Preliminary recommendations on how to approach Trump's plan were almost certainly part of the discussion when the pair met at Trump Tower last week, so it's safe to say that Chao and Trump are in early agreement on a way to move forward with his policy proposal.
Though infrastructure is typically a nonpartisan issue in and of itself, the two dominant political parties have very different approaches to funding, which is the main concern for the president-elect's proposal. Trump's plan to give private investors massive tax cuts and ownership of investment projects is already drawing criticism from the left. The liberal Economic Policy Institute claimed that the plan will result in projects that profit private companies instead of badly needed public works that would be more likely accomplished under a direct spending program. Trump claims his plan is superior since it theoretically won't cost the government anything, but it will also create a dangerous precedent of privatizing public utilities and making roads unaffordable.
Chao's appointment to this post is so important because infrastructure is one of Trump's priorities that everyone should be able to get behind. Trump's controversial views on climate change, LGBTQ+ rights, and immigration are so unpopular that people are rooting for him to fail as president, but infrastructure is one of the few areas where all Americans should hope for successful change. The question now is how will that change come about, and will it happen in the best way to benefit everyone, not just a few. Chao should be an integral part in making sure that equality is achieved, and will hopefully fulfill her duty to the whole country.


BacardiThe rum brand is investing in a multi-million pound marketing campaign around its 'irrepressible spirit' in the UK.
The initiative, Bacardí Untameable since 1862, aims to showcase the brand and family heritage over the past 150 years though integrated TV, digital, out-of-home and PR activities.
Founded in 1862, in the city of Santiago de Cuba by Don Facundo Bacardí Massó, Bacardí rum is still family-owned. This campaign focuses on the brand's history, which saw the family survive earthquakes, fires, prohibition, revolution, and exile, to grow the business.
The campaign will feature 30 and 60-second TV ads, directed by award-winning Dante Ariola, starring actor Jordi Mollà. The ad was filmed on location the UNESCO World Heritage site of Ouro Preto, in Brazil, and Bacardí claims it has a "blockbuster" feel.
The out-of-home advertising will run headlines including, "We Remember Prohibition - It was a Blast;" "Some Men are Kicked Out of Bars - Others are Kicked Out of Countries;" and "Earthquakes, Fire, Exile, Prohibition - Sorry Fate, You Picked the Wrong Family."
Lisa Jazwinski, Bacardí UK & Ireland brand director, said: "The campaign is all the more relevant to millennials now. Our consumers are coming of age in an uncertain world but they remain fiercely optimistic and believe they can make a difference. In this, they are also 'Irrepressible Spirits', so Bacardí Untameable Since 1862 enables us to connect with millennials."
The brand has also updated its bat logo, inspired by hand-drawn designs from the early 1900s. The bat, in Cuban and Spanish heritage, represents good luck and family unity. The word Bacardí itself has been updated to match Cuban art deco style from the late 1920s and early 1930s, matching the sign still in place on the firm's former sales office in Havana.
Bacardí, which also owns Grey Goose vodka and Bombay Sapphire gin, employs more than 6,000 people, manufactures its brands at 27 facilities in 16 countries on four continents, and sells in more than 100 markets globally. Today, it is made in Puerto Rico and Mexico.


VIAJIYU's round toe ballet flat is a timeless, classic shape, designed for comfort. Structured at the toe, heel and sole, the VIAJIYU Roma provides a greater level of support than typical ballet flats. Extra padding under the insole provides an additional layer of comfort. Handmade in Italy from the finest goatskin, this flat features a navy grosgrain bow.
Take your fabulous flats and check out Via dei Serpenti and Via del Boschetto for cute cafés, traditional workshops, and a glimpse of Romans going about their daily lives.


In today's sermon, "Addressing the 'Why?' of Salvation –Transformation (Rom. 12:1-2; 2 Cor. 3:17-18), Part 1 of Romans 12-15 Exegetical Series", Pastor Craig Kuhlman shows that our calling isn't just for salvation alone, but also for transformation.


All ladies shopping for fashion clothes and audible promo code june 2017 bags like a discount.
That explains why Mozimo uses coupons and promotional offers to attract customers.
Not only can you shop our products online, but we also have three stores around the North West.You will find brands such as Peter Kaiser, Gabor, Birkenstock and Rieker, while they stock sandals, trainers and slippers.Buy shoes online today in complete confidence.Our average member earns over 300 cashback a year.Navigation, browse men's and women's designer shoes, boots and bags at Mozimo.Get below Mozimo Vouchers, Mozimo Voucher Codes, Mozimo Discount Vouchers and apply at checkout page to get discount.
Originally established in Nantwich, Cheshire in 1983, Mozimo is an independent retailer of both mens and womens designer shoes, boots and bags.
Sign up for free and just shop with Mozimo as normal.
Established for over 30 years, as the North Wests leading stockist.Our ladies collections offer an abundance of style staples and much more.Barker, Camel Active and, rieker.To keep up with our latest news and promotions, why not sign up to our mailing list?FitFlop, Peter Kaiser Shoes, Gabor Shoes, Anatomic Gel Shoes, Skechers amp; Timberland Boots.
Tank Paintball Battle, leicestershire - Lutterworth show on map, take control of the tank and fire the paintball cannon.Option B, price 70: 85,000 coverage; 5,000 deductible.Watch their videos online before you buy.LouisSep 29-30 SeattleOct 13-15 Northern New JerseyOct 20-22 PittsburghOct 26-29 ChicagoNov 10-12..
Consider auto transport companies that offer gap protection through the AFta plan.Valid through: Nov 3, 2018.All potential bidders must be registered to bid at least 15 minutes prior to auction time.Auto brokers consider the following, when estimating the cost to transport your graduation..


text:
Home/Advice/Formula One Betting – Part Two
Formula One Betting – Part Two
Michael Wilding October 11, 2010
Facebook Twitter LinkedIn WhatsApp Share via Email
(Last Updated On: October 3, 2010)
Guest post written by Paul Micelli
If you have read my first article on Formula One racing, then you will already be familiar with a multitude of different factors that can affect race outcomes. The discerning bettor will need to be particularly studious if they aim to make profits from one of the most marginal markets in the annual sporting calendar. Before placing a bet on an individual race, there are a series of key figures that need to be evaluated:
Crucial Factors in Formula One Racing
Fuel Loads – The fuel load being carried by a vehicle will have a huge effect on the outcome of an individual race. Constructors spend millions of pounds on keeping their vehicles as light as possible so that speeds, manoeuvrability and aerodynamic qualities can be maximised. The complex scientific research that goes into making a competitive Formula One car can be wiped away in seconds if excessive fuel loads are added to the vehicle as this will just make them heavier and slower.
Fuel loads have become even more important for the current 2010 campaign because the FIA have now outlawed refuelling during a race. This has left teams with a veritable headache when it comes to establishing the correct fuel load for a full event. Too much fuel and the car will go slower. Too little, and the car will run out before it reaches the finishing line.
Qualifying – Qualifying usually takes place on the day before the actual race and bettors can glean massive amounts of information from the performances of drivers and their machines during these sessions. Irregular lap times and mechanical failure are all signs of a Formula One car struggling to meet the standards set by other constructors and it is usually best to avoid wagering on these particular entrants. Erratic driving is also another indication of a racing team struggling for consistency.
Form – As with any other sport, winning can become a remarkably frequent habit and it's always wise to keep a cautious eye on drivers who continue to cross the line in first position irrespective of where they are racing and what the weather conditions are like. However, some drivers have excellent records at specific tracks so studying race results from previous years to establish likely candidates for victory is always advisable.
Pre-Race Interviews – Always pay attention to televisions interviews with drivers, constructors and other team members. It's often quite easy to glean relevant information from interviews and a relaxed, smiling driver is normally one that is bristling with confidence. Clarity is key and any team that continues to talk about potential changes to the vehicle is one that probably doesn't hold particularly high expectations for the coming event.
Conditions – Weather conditions can be particularly significant when it comes to making a betting selection in a Formula One race. As with horses, there are some drivers who perform much better in poor conditions. Sebastian Vettel is highly regarded for his ability to handle wet weather conditions and the enigmatic German has enjoyed several wins in races where heavy rain has persisted throughout.
Successfully Tracking Horses (A Regular Punters Authentic Guide)
Building Your Own 24/7 Betting Bot (Using A Raspberry Pi – Episode #3)
Inside the Rails Spectators Back At The Races
Michael started the Race Advisor in 2009 to help bettors become long-term profitable. After writing hundreds of articles I started to build software that contained my personal ratings. The Race Advisor has more factors for UK horse racing than any other site, and we pride ourselves on creating tools and strategies that are unique, and allow you to make a long-term profit without the need for tipsters. You can also check out my personal blog or my personal Instagram account.
Click the image to discover…
Today's Leaderboards
Top 10 Users for Points
Top 10 Users for Profit
positronic
grantoliver72
bburnsuk
Race Advisor Blog
How To Clear Cookies & Cache
Terms & Conditions | Privacy Policy | Disclaimer
Anonymous Ginger Ltd, International House, 14 Holborn Viaduct, London EC1A 2BN | Registered in England No. 8236514. VAT No. GB 143 5228 30.
Anonymous Ginger Ltd. does not encourages reckless gambling. This site is not intended for an audience under 18 years of age. We recommend that readers who engage in gambling do so responsibly and set financial limits. If you have a concern about problem gambling, you can contact GamCare on 0845 6000 133 or gamcare.org.uk
Anonymous Ginger © Copyright 2021, All Rights Reserved