1. Introduction
pynja is a cross-platform meta-build system written in Python 3 that produces Ninja Build files.
When using pynja, it will help to be familiar with the Python language. But — if you don’t know Python, don’t worry. In this manual, we’ll be sharing plenty of recipes that you can copy/paste without worrying about too many Pythonic details.
1.1. Conventions
In this document, you might encounter these terms or variables:
-
VCS = Version Control System = Source Control. Programs like CVS, SVN, Git, Mercurial, Perforce are types of VCSs.
-
$YOUR_REPO = The root directory of your repository.
-
$PYNJA_REPO = The place where you downloaded or unzipped the pynja repository.
-
$BUILT_DIR = The base directory where intermediate files (like object files) are stored during a build.
-
Out-of-source build = Pointing your $BUILT_DIR at a location outside of your source repository. This has many benefits (like making your VCS easier to work with), and is highly encouraged.
1.2. Pynja and Ninja
pynja is a meta-build system. Its job is to help you generate a file-level dependency graph that ninja can execute efficiently.
In the end, pynja helps you create a build.ninja file in your $BUILT_DIR.
Once you have a build.ninja, you can actually perform your build by invoking ninja. For example:
pushd $BUILT_DIR ninja
or
ninja -C $BUILT_DIR
1.3. Basic Concepts
pynja makes you organize your build into Project classes. Each class should have a specific goal. Some common project types and outputs are:
-
CppProject
-
shared library aka DLL or dynamic shared object
-
JavaProject
In real life, you will find that you need to build the same project in multiple ways.
The most common example is a debug vs release build. Debug typically has optimizations disabled, more debug information output, special preprocessor defines for logging, etc. Some other common variations are compiler-toolchain, architecture, and C-runtime-linkage (static vs dynamic).
pynja lets you handle this variation by letting you define Variant classes, and then create one Project instance per Variant. A Variant class is composed of fields such as toolchain (gcc, msvc), arch (x86, x64), and config (debug, release). Variants have a canonical string form, which is useful for defining directory names for outputs, or when specifying targets on the commandline. For example, gcc-x86-debug speaks for itself.
| Pynja was specifically designed with multi-arch, multi-platform, multi-language development in mind — in contrast with most other build systems. Read here for more details. |
To support cross-platform, cross-toolchain builds, pynja has some standard abstractions for ToolChains and compilation Tasks. A ToolChain embodies the rules needed to invoke a specific compiler (like gcc), and a Task abstracts compiler options as fields of a python class. With C++ builds, each Project instance is associated with exactly one toolchain. The same Project may be instanced multiple times using multiple ToolChains.
Finally there’s the ProjectMan class. ProjectMan enforces the rule of "one Project instance per Variant", provides a central dictionary for ToolChain instances, and helps coordinate the write-out of build.ninja.
Here’s how these elements interact in code:
# $REPO_ROOT/packages/repo/cpp.py
class SimpleCppVariant(pynja.Variant): #
def __init__(self, string):
super().__init__(string, self.get_field_defs())
def get_field_defs(self):
fieldDefs = [
"toolchain", [ "gcc", "clang" ], #
"arch", [ "x86", "x64" ], #
"config", [ "dbg", "prof", "rel" ], #
]
return fieldDefs
class SimpleCppProject:
''' ... __init__ and other methods ... '''
def set_cpp_compile_options(self, task):
super().set_cpp_compile_options(task)
task.debugLevel = 2 #
if self.variant.config == "dbg":
task.optLevel = 0 #
else:
task.optLevel = 3 #
# $REPO_ROOT/code/program/program.py
@pynja.project
class program(repo.cpp.SimpleCppProject): #
def emit(self):
sources = [ #
"src/main.cpp",
"src/util.cpp",
]
self.cpp_compile(sources) #
self.add_input_library(repo.rootPaths.zlib) #
self.make_executable("prog0") #
# $REPO_ROOT/remake.py
def generate_ninja_build(projectMan):
cppVariants = []
''' ... create toolchain objects ... '''
cppVariants.append(repo.cpp.SimpleCppVariant("gcc-x86-dbg")) #
cppVariants.append(repo.cpp.SimpleCppVariant("gcc-x86-rel"))
for variant in cppVariants:
projectMan.get_project("program", variant) #
| Define a Variant class. Instances will be referred to as variant. | |
| variant.toolchain can be one of (gcc, clang, msvc11) | |
| variant.arch can be one of (x86, x64) | |
| variant.config can be one of (dbg, prof, rel) | |
| All compilations produce debug info. | |
| In dbg configuration, all optimizations are disabled. | |
| In other configurations, all optimizations are enabled. | |
| Define a Project to build the program executable. | |
| Declare source files in a regular python list. | |
| Declare C++ compilation targets, using the source files specified in the sources list. The project determines where the object files will be written (somewhere in the $BUILT_DIR). The project also "remembers" the list of generated object files. | |
| Cause the final target to link against zlib. Note that the order w.r.t. compilation is significant here. | |
| Declare an executable named prog0 (or prog0.exe on Windows). The executable will be created by linking all the object files from previous cpp_compile calls and any add_input_library calls. | |
| Declare global variants that we want to create targets for. | |
| Cause the program class to be instanced for all variants we created previously, causing all the relevant targets to be declared. |
Remember that no actual compilation occurs throughout this entire process. We are simply defining targets to be built later using ninja.
1.4. Prerequisites
You will need a copy of Python 3.3 or greater.
-
On Windows or Mac, download it from http://python.org .
-
On Linux, use your package manager.
-
On Ubuntu you can use e.g. sudo apt-get install python3.3
-
Download a copy of the pynja repository:
-
Or if you prefer, clone the git repository:
mkdir $PYNJA_REPO cd $PYNJA_REPO git clone https://github.com/fifoforlifo/pynja.git .
2. Brief Tour of the Components
There are 4 code categories in a pynja build:
-
The pynja package: you typically don’t modify this.
-
The repo package: you copy this and tweak this.
-
Project files: you write these in your source directories.
-
Root-level script remake.py: you copy and tweak this.
2.1. pynja package
Find this here: $PYNJA_REPO/packages/pynja .
I recommend copying this into your repository, so that a stable copy of pynja revisions along with your source code.
Then your remake.py can add the pynja package location to your sys.path.
2.2. repo package
Find this here: $PYNJA_REPO/test2/build/repo .
The repo package is intended to be specialized for your particular repository.
The repo package serves several purposes:
-
Define all the project directories in your repository.
-
This also provides support for micro-branching.
-
-
Define all the Variant types supported by your repository.
-
Define specializations of class CppProject, class JavaProject, etc. to be used as base classes throughout the rest of the build. These common base classes will set compiler flags based on your repository-specific Variant fields.
2.3. project files
Example file: $PYNJA_REPO/test2/code/a/a1/a1.py.
A project file is just a python source file that declares one or more Project classes. Each Project class may be instantiated once per Variant. A C++ Project will generate a single library or executable per instance.
You will typically define project files alongside your source code.
2.4. root-level script
Example file: $PYNJA_REPO/test2/remake.py.
This script is literally what causes the build.ninja file to be created. Its job is to instantiate all supported Variants, and all desired top-level projects and targets using those Variants.
3. C++ Build
3.1. Toolchains
pynja supports the following toolchain families out of the box:
-
Microsoft Visual C++ (msvc)
-
VC8 and above (that is, the version from VS2005 and later)
-
Works equally well with compilers from Visual Studio Pro, Visual Studio Express, and those that come with Windows SDKs.
-
-
GNU Compiler Collection (gcc) + binutils
-
Clang + binutils
-
NVIDIA CUDA Compiler (nvcc)
In all cases, there is no requirement that a toolchain be installed on the system performing the build. All environment handling is performed in pynja scripts. This allows you to submit a pared down toolchain into your source control, and build entirely without installation dependencies.
3.2. CppProject
CppProject is designed to create exactly one static library, shared library, or executable per instance. That is, a CppProject represents one linker invocation and all the sub-targets needed to feed the linker.
You will need to specialize pynja.CppProject into your own repo.cpp.Project, in order to translate your Variants to appropriate compiler flags.
The CppProject holds an internal list of inputs that need to be passed to the linker. You can directly add to that list as follows:
-
add_input : add an object file
-
add_input_lib : add a library dependency by filename
3.3. Compiling and CppTasks
The cpp_compile function can compile a single source file to an object file. The object file name is automatically computed based on the project.builtDir and then added via add_input.
Each compilation is represented by a CppTask instance. This class has a public field for each commonly used compiler option. It’s the ToolChain’s job to later translate the portable CppTask fields into toolchain-specific compiler flags and build directives.
3.3.1. Control Flow
CppTasks flow from a most-generic to a most-specific scope. At each step of the way, any option may be overridden. Lists may also be appended to or even completely replaced.
-
pynja.CppProject.cpp_compile: CppTask is created. The default options are geared towards an optimized build.
-
repo.CppProject.set_cpp_compile_options: Set compiler options based solely on the variant. Typically you control optimization settings, debug info, C runtime linkage, and other "generic" settings here.
-
YourProject.includePaths and YourProject.defines apply not only to C++ compilation, but many related build tasks. For example, protobuf, Qt, and custom preprocessing.
-
YourProject.set_cpp_compile_options: Set compiler options for all files in your project.
-
with statement body: Set source-file-specific options. Typically you control PCH usage, include paths and defines here. But you can also easily implement any other one-off quick-fixes you need.
# in emit method
# simple method -- no per-task customization
self.cpp_compile("aaa.cpp")
# flexible method -- control per-task options
with self.cpp_compile_ex("foo.cpp") as task:
task.defines.append("LOGLEVEL=50")
3.4. CppTask Compiler Options
- For the full list, look at the definition of `pynja/cpp.py
-
CppTask`.
Here’s a breakdown of the most useful flags. See the compiler’s manual for more details.
-
optLevel: Optimization level, on a scale of 0 - 3. Level 0 is recommended default for debug, 3 for release.
-
debugLevel: Controls how much debug info is emitted, on a scale of 0 - 3. Level 2 is the recommended default. DebugLevel should not affect optimization level, but certain compilers don’t implement this perfectly.
-
0: none
-
1: just line tables (enough to set breakpoints, see source correspondence)
-
2: level1 + debug symbols (scope and variable info)
-
3: level2 + advanced features, like "edit & continue" under msvc; note that this debug level may be incompatible with other compiler flags
-
-
warnLevel: Warning level on a scale of 0 - 3.
-
warningsAsErrors: If true, warnings are converted to errors.
-
includePaths: A list of ordered include paths for preprocessor header discovery. Translates to -I for gcc.
-
defines: A list of ordered preprocessor defines. Translates to -D for gcc.
-
addressModel: When using a toolchain that supports multi-arch, this field can be specified as either -m32 or -m64.
-
std: Selects the language standard using the -std flag as described here. You should only pass the language name here. For example, "c99" or "gnu99" for C99 compilation, and c++11 or gnu++11 for C++11.
-
lto: If true and optimizations are enabled, the compiler emits an object file that supports Link Time Optimization as described here.
-
Note that clang strives to be command-line compatible with gcc, but may add its own options as well.
-
dynamicCRT: If true, compile code that will link against the dynamic C runtime. If false, require the static C runtime. Translates to one of /MT, /MTd, /MD, /MDd depending on optimization level.
-
asyncExceptionandling: If true, then SEH exceptions are thrown as C++ exceptions. (note: you usually do NOT want to enable this for perf reasons) Translates to /EHa or /EHs.
-
externCNoThrow: If true, treat extern "C" functions as nothrow. Translates to /Ehc.
-
relocatableDeviceCode: If true, device code is statically linkable. Translates to -rdc.
-
deviceDebugLevel: Debug level on a scale of 0 - 2.
-
0: none
-
1: just line tables; useful for debug and profiler; translates to -lineinfo
-
2: full debug info; unfortunately forces optimization level of device code down to none; translates to -G
-
3.5. Library Dependencies
3.5.1. Typical case: Project-Project library dependencies
Typically, you will generate a library in one project and consume (link against) it in another. For this case, use add_lib_dependency as follows:
# in emit method
self.add_lib_dependency(self.get_project("logging", self.variant))
This causes the output library of project "logging" (typically logging.lib or liblogging.a) to be linked into the current project’s target, if the current project is producing an executable or shared library. add_lib_dependency actually does more than this; see the section on transitive dependencies for more details.
3.5.2. Atypical case: direct filename reference
Use the add_input_lib method to define a dependency by filename.
# in emit method
self.add_input_lib(someLibraryName)
3.6. Creating Libraries and Executables
After you’ve defined all your compilations and additional inputs, you can finally define the output of your project.
# in emit method
# explicit static library
self.make_static_lib("a0")
# explicit shared library
self.make_shared_lib("a1")
# create either static or shared library based on variant
self.make_library("a2")
# executable
self.make_executable("prog0")
After doing one of the above, your Project’s outputPath field will be defined to the absolute path of the resultant target.
Library projects will have an additional libraryPath field set. This points at the .lib file when building with MSVC, and the DSO or DLL when using other toolchains. Always use a project’s libraryPath when adding library dependencies.
3.7. PreCompiled Headers (PCH)
You can seriously speed up your build with PCHs. They’re highly recommended, especially when your C++ code uses lots of STL, Boost, and large system headers.
pynja supports PCHs in the most generic way possible while still remaining portable:
-
You can create a PCH at any time, from any project.
-
You can use a PCH at any time, from any project.
-
You can chain-create PCHs. That is, one PCH may include another PCH as its starting point.
-
You may disable PCH creation by passing an additional False parameter to make_pch. In this mode, the PCH is replaced by a force-include in order to guarantee identical behavior.
-
ToolChains that don’t support PCHs must emulate them using force-include.
-
Because some toolchains (MSVC) generate an object file for each PCH, any code that uses a PCH must also link against that object file. Since the object file is automatically added to the input list, the easiest and best way to chain-create PCHs is by creating a separate library project for each PCH. Sharing PCHs across projects is a good way to avoid repeatedly compiling the same code anyways, so it’s a win all around.
# in emit method
self.make_pch("source/a0_pch.h")
with self.cpp_compile(sources) as tasks:
tasks.usePCH = pchTask.outputPath
If you’re interested in the gory details of the PCH implementation, you can read more here .
| On some toolchains (MSVC), chain-creation of PCHs isn’t implemented as true chaining. Instead, each PCH is compiled "from scratch". Functionally it still works, but compilation speed isn’t as good as it ought to be. |
3.8. Code Generation Patterns
C++ code generators either generate includables (referenced by #include) or source files (primary input of a compilation). For optimal build speed, these need to be handled differently.
Generated source files are fully parallelizable, and create no implicit dependencies with other files in the build.
Generated includables are a problem when bootstrapping, i.e. during the first time you run your build. These dependencies need to be known to the build, so that any file that might #include it is scheduled to compile after the code generation.
To simplify build scripts, generated includables cause all subsequent tasks in the same project to depend on them.
The implicit dependencies only apply within the project instance; they do not cross variant boundaries.
If you have code that does not depend on these headers, make sure to declare their compilations before any such calls, to allow for better build parallelism.
3.9. Protobuf → C++ Code Generation
libprotobuf is a popular serialization library. It allows you to define Protocol Buffers messages in a custom DSL, which then require generated headers and source files to use from C++.
Protocol Buffers also have a concept of inclusion (just like C header files).
There is a pynja ToolChain for dealing with Protocol Buffers. It properly creates a dep file so that implicit dependencies cause rebuilds.
Using it is this simple:
# in emit method
self.proto_sources = []
self.proto_sources = self.protoc_cpp_compile("somefile.proto")
3.10. Working with Boost
There are helper functions to deal with both building boost and adding boost library dependencies to your own projects. These are part of the repo package. Example usage can be found in qt0.py and is as simple as:
self.add_boost_lib_dependency("thread")
self.add_boost_lib_dependency("chrono")
self.add_boost_lib_dependency("system")
3.11. Working with Qt
Qt has two custom tools, the moc compiler (generating code for QObject classes) and the uic compiler (generating code for UI designs). Both tools are supported in pynja, with appropriate dependency propagation.
See qt0.py for an example. The essence of the build code looks like this:
ui_sources = [
"source/main_window.ui",
]
self.qt_uic(ui_sources)
moc_inputs = [
"include/qbaz.h",
"source/qfizzle.h",
"source/qt0.cpp",
]
self.qt_moc_cpp_compile(moc_inputs)
As mentioned earlier, if you have code in the same project that does not depend on these generated headers, make sure to declare their compilations before any qt_uic/qt_moc calls, to allow for better build parallelism.
3.12. Runtime and Transitive Dependency Management
pynja automates transitive dependencies for both library linkage and for runtime dependencies.
The overall idea is for each project to declare its immediate link-time and runtime dependencies. Then propagate these dependencies to all consumers in the chain, so that final executables and shared libraries have accumulated all dependencies implicitly.
Using add_lib_dependency performs all of this propagation at the project level.
3.12.1. Runtime Dependencies
Runtime dependencies are used to indicate how binaries need to be "deployed" in a product’s directory layout. To illustrate:
-
Executable depending on shared library:
-
On Windows they are often placed in the same directory.
-
On linux they are often placed in separate bin and lib directories.
-
-
Shared library depending on another shared library: same as above.
-
Shared library depending on data file.
pynja allows you to specify a runtime dependency in any project, via the following methods, whose signatures are copied below.
def add_runtime_dependency(self, srcPath, destPath = None, destDir = None):
def add_runtime_dependency_project(self, project, destDir = None):
Runtime dependencies are best expressed in the project where the dependency is known. For example, if common.dll always depends on helper.dll, then the common project ought to add a runtime dependency on the helper project. This way, any time an additional project like user depends on common, the required dependency information is carried through.
3.12.2. Rationale with Examples
Transitive dependencies especially help when a user library is not a direct client of a helper library, and therefore it would not be logical or intuitive for user to directly state a dependency on helper. It also insulates the user project from all of common's dependencies, which may change over time.
A bigger example:
-
Initial State:
-
user → common
-
common -> A, B, C
-
-
Next Day:
-
user → common
-
common -> B, C, D
-
-
Next Day:
-
user → common
-
common -> B, D, F
-
In this example, only common.py ought to be updated daily with the new dependency list. In the meantime, the user project stays completely untouched, as do the product-level "deployment" scripts.
4. Repository and Source Organization
Here are some tips and suggestions for how to organize your source repository, with thought towards both workflow and VCS interaction. Pynja has been designed with all of these in mind.
4.1. Modular Repository
You don’t need to define all projects in repo/root_paths.py nor remake.py. If your repository is modular, and a subdirectory governs all projects contained within, you can define additional root paths as follows:
# remake.py
repo.import_dir("code/projectX")
# code/projectX/projectX.py
repo.import_subdir("a0")
repo.import_subdir("a1")
repo.import_subdir("a2")
There are actually 2 sets of functions:
-
Repository-relative import. These are effectively absolute imports within your branch.
-
repo.import_file() : import the specified file
-
repo.import_dir() : import the file whose name matches the specified directory
-
-
Script-relative import.
-
repo.import_subdir_file()
-
repo.import_subdir()
-
You are encouraged to follow the convention of naming the build script after the directory it resides in, and use the shorter and more-convenient import_dir and import_subdir.
| Script-relative import is analogous to CMake’s add_subdirectory, and should allow for easy porting. |
4.2. Micro-Branching
Micro-branching is a technique whereby you branch (copy) a single directory within your build, and automatically have all dependencies transfer to this branch. With pynja, this merely requires local modifications to your build scripts: add an altPath parameter to the appropriate import_file/import_dir/import_subdir_file/import_subdir call to point at your alternate location.
For example:
# original (in source control)
repo.import_subdir("threading")
# with altPath
repo.import_subdir("threading", altPath = "/home/you/ubranches/threading")
5. Pynja versus The World
In this section I’ll make bold and brash claims describing pynja’s technical, philosophical, and moral superiority as compared to every other build system that has ever been created. You’ll see how pynja has assimilated the best attributes of all other build systems while simultaneously avoiding all of their mistakes.
If you enjoy hyperbole and rhetoric, read on!
5.1. Pynja variants are better
pynja’s variants allow you to vary anything. This isn’t possible with most of the popular alternatives.
-
CMake:
-
Only one C++ Toolchain is usable per build! This makes developing multi-arch software absolutely torturous.
-
If you want two variations of a static-library, e.g. linked against static C runtime and dynamic C runtime, it’s more-or-less easy to do.
-
-
MSBuild:
-
Natively supports Platform and Configuration.
-
Adding additional C++ Toolchain support requires installing files to a system-global location! Otherwise, only Win32 and x64 are supported.
-
Woe unto the person who attempts to use AdditionalProperties on an MSBuildTask or a ProjectReference, for all indirectly-referenced projects must correctly handle the named properties; otherwise the same project will be instanced twice, leading to all kinds of output corruption.
-
-
Make:
-
It’s possible to support any kind of variant in Make. However, you must encode things like C++ Toolchain into variable names and write macros to make this work.
-
Common makefiles and tutorials are all geared towards single arch, single toolchain support.
-
5.2. Pynja uses a real programming langague
I find it strange that so many build systems use a custom DSL where every variable is global, its type is a string, and sane scoping rules are notably absent. Given the abundance of good scripting languages (like Python), this is really inexcusable.
Python also happens to have some good debuggers, which is sorely lacking in other build systems.
5.2.1. Case study: CMake’s parameter passing
CMake’s parameter passing is effectively broken. Every empty parameter and empty-string parameter in the caller is erased in the callee, shifting all subsequent parameters to lower argument positions in the callee scope.
A simple illustration of this would be:
function(Foo arg1 arg2)
message("arg1=${arg1} arg2=${arg2}")
endfunction()
Foo("a" "b") # arg1=a arg2=b
Foo("a" "" "c") # arg1=a arg2=c <--- empty string was erased!
set(VAR)
Foo("a" VAR) # ERROR: CMake complains of insufficient args [yeah]
5.3. Pynja is imperative, not declarative
Imperative logic is very, very necessary to allow factoring of logic.
Let’s say one day you write a piece of code that crashes the MSC9 C++ compiler only in x86 optimized builds. (true story)
The declarative way would require you to write the outer product of (toolchains x architectures). VC Projects from VS 2008 and earlier suffer from this syndrome.
With pynja, it’s as simple as this:
with self.cpp_compile("problem.cpp") as task:
if variant.toolchain == 'msvc9' and variant.arch == 'x86':
task.optLevel = 0
5.4. Pynja has no global ordering issues
In pynja, inter-project dependencies are expressed naturally, because you’re basically forced to instance a project from each place where you need it. Other environments are not so forgiving.
CMake requires everything to be globally ordered correctly. It is all too easy (and all too common) to define a library dependency before the actual library. It’s a big source of build bugs.
Ant, MSBuild, Gradle, Rake, and others fall in a different category. I call these cargo cult build systems, because they use all the same words as real build systems, only without the same meaning or usefulness.
For example, these software packages talk about Targets and Tasks, but Targets aren’t files; there is no automated file-level dependency ordering. Instead, Targets are just functions that can only execute once; and it’s up to you to sequence them correctly, globally, using before-target and after-target style wiring. If it sounds incredibly brittle, that’s because it is. The worst part is having to schedule your target before or after some other named target, because you need to know the name of that target. The only way to know the target to schedule yourself before or after is to read every other script in the entire build system — which is obviously a maintenance and usability nightmare, in addition to being fragile.
Cargo cult build systems also have no chance of keeping up with the build speed of Ninja, because they must iterate through every "Target" or "Task" on every incremental build. In the best cases, each "Target" is annotated with inputs and outputs that are used to determine "up-to-date" status. In remaining cases, the "Target"/"Task" must be invoked and is responsible for performing the "up-to-date" check itself.
I will also mention that because CMake is designed to emit scripts for various cargo cult build systems, its design philosophy is significantly compromised — to the point of making statements like "recursive make considered necessary" . The result is a huge amount of false serialization being introduced, such as "project level dependencies", in order to accomodate the lack of file-level checks in non-Ninja backends. Unfortunately this spills over even into the Ninja generator since implicit dependencies are not expressed correctly, being encompassed by project-level dependencies instead.
pynja is in large part a response to the rising tide of cargo cult build systems that threaten to push moden software development backwards.


Here's a sample Markdown document with weird headings
¶A level 2 heading to start
¶Followed by a level 4
¶Then a level 1
¶And another level 2
¶Then a level 5
¶Then a level 6
¶Then a level 5
¶Then a level 6
¶And then a level 3
¶Then a level 5
¶Then a level 2
¶Followed by a level 6
¶Then another level 3
¶Then level 5
¶Level 4
¶Level 3
¶Level 2
¶Level 4
¶Now for some "normal" headings to test going up and down the stack
¶Section 1
¶Section 1.1
¶Section 1.1.1
¶Section <IP_ADDRESS>
¶Section <IP_ADDRESS>.1
¶Section <IP_ADDRESS>.1.1
¶Section <IP_ADDRESS>.2
¶Section <IP_ADDRESS>
¶Section 1.1.2
¶Section 1.2
¶Section 2


Main classes and functions¶
foehnix.Foehnix |
Foehn Classification Based on a Two-Component Mixture Model |
foehnix.Family |
Common logic for the foehnix families |
foehnix.GaussianFamily |
Gaussian foehnix mixture model family |
foehnix.LogisticFamily |
Logistic foehnix mixture model family |
foehnix.foehnix.Control |
Foehnix Two-Component Mixture-Model Control Object |
foehnix.Foehnix.no_concomitant_fit |
Fitting foehnix Mixture Model Without Concomitant Model. |
foehnix.Foehnix.unreg_fit |
Fitting unregularized foehnix Mixture Model with Concomitant Model. |
foehnix.Foehnix.predict |
Predict method for foehnix Mixture Models |


--- title: 404 permalink: /404.html layout: page ---
Looks like we've stumbled upon a broken link. We can either: A) Report the broken link, or B) return to the home page and act like this never happened...


This package contains basic components 1D mechanical rotational drive trains.
| Name | Description |
|---|---|
| Fixed | Flange fixed in housing at a given angle |
| Inertia | 1D-rotational component with inertia |
| Disc | 1-dim. rotational rigid component without inertia, where right flange is rotated by a fixed angle with respect to left flange |
| Spring | Linear 1D rotational spring |
| Damper | Linear 1D rotational damper |
| SpringDamper | Linear 1D rotational spring and damper in parallel |
| ElastoBacklash | Backlash connected in series to linear spring and damper (backlash is modeled with elasticity) |
| ElastoBacklash2 | Backlash connected in series to linear spring and damper (backlash is modeled with elasticity; at start of contact the flange torque can jump, contrary to the ElastoBacklash model) |
| BearingFriction | Coulomb friction in bearings |
| Brake | Brake based on Coulomb friction |
| Clutch | Clutch based on Coulomb friction |
| OneWayClutch | Parallel connection of freewheel and clutch |
| IdealGear | Ideal gear without inertia |
| LossyGear | Gear with mesh efficiency and bearing friction (stuck/rolling possible) |
| IdealPlanetary | Ideal planetary gear box |
| Gearbox | Realistic model of a gearbox (based on LossyGear) |
| IdealGearR2T | Gearbox transforming rotational into translational motion |
| IdealRollingWheel | Simple 1-dim. model of an ideal rolling wheel without inertia |
| InitializeFlange | Initializes a flange with pre-defined angle, speed and angular acceleration (usually, this is reference data from a control bus) |
| RelativeStates | Definition of relative state variables |
| AngleToTorqueAdaptor | Signal adaptor for a Rotational flange with torque as output and angle, speed, and optionally acceleration as inputs (especially useful for FMUs) |
| TorqueToAngleAdaptor | Signal adaptor for a Rotational flange with angle, speed, and acceleration as outputs and torque as input (especially useful for FMUs) |
| GeneralAngleToTorqueAdaptor | Signal adaptor for a rotational flange with torque as output and angle, speed and acceleration as input (especially useful for FMUs) |
| GeneralTorqueToAngleAdaptor | Signal adaptor for a rotational flange with angle, speed, and acceleration as outputs and torque as input (especially useful for FMUs) |


I found this site while googling and am pleasantly surprised that it is covering a lot of things that I have been working on.
For the last few months I have been developing a sensor and associated collector to measure the parameters of electricity supply.
My sensor uses a PIC micro and 433 MHz radio to send to a Pi where the data is stored in RRD databases and displayed via a web page, data is stored for a year before being overwritten. There is normally one connected here http://<IP_ADDRESS>/ but as that is my home IP it is often not there or the sensors are not connected.
It is very much a work in progress but currently has a minimum measurement of about 100 ma and a resolution of 15 ma with a maximum current of about 150 amps. The range and resolution are related to the coil that is installed, I have coils that will go up to about 2000 amps but will not resolve below about 5 amps, horses for courses and all that.
There is little on here about Rogowski coils, it seems people consider them to be too difficult and needing integrators but that is not the case, they are very easy to wind and you do not need an integrator if you use the rate of change of the output to calculate the current.
Interesting to note that certainly on my LV supply in the UK the third harmonic is huge, my incoming waveform hasn't seen a sine wave for eons. For this reason I measure the voltage at 3.33 ms past zero cross over, this removes the third harmonic.
Interesting link if you are UK based. http://www.dynamicdemand.co.uk/grid.htm# My sensor will track that frequency which was a real buzz.
I made a LinuxCNC based machine to wind the Rogowski coils http://homepage.ntlworld.com/dknpower/winder.3gp best use for an inkjet printer ever.
The Raspi has problems for this sort of use. If power is lost it trashes the SD card (or USB stick) so I made a board with battery backup to auto start and shutdown the Pi.
Main problems currently are related to calibrating the measurements. My LV supply is not stable enough to allow accurate calibration so I am currently making a PIC based 50 Hz oscillator to provide stable voltage, current and phase in order to allow me to finalise the equations for accurate measurements. Phase is a real sticky one as the phase shift through the Rogowski coil and associated opamp circuit is dependent on current, a really horrible thing to solve.
Introduction
Submitted by Guest on Wed, 23/10/2013 - 07:35I found this site while googling and am pleasantly surprised that it is covering a lot of things that I have been working on.
For the last few months I have been developing a sensor and associated collector to measure the parameters of electricity supply.
My sensor uses a PIC micro and 433 MHz radio to send to a Pi where the data is stored in RRD databases and displayed via a web page, data is stored for a year before being overwritten. There is normally one connected here http://<IP_ADDRESS>/ but as that is my home IP it is often not there or the sensors are not connected.
It is very much a work in progress but currently has a minimum measurement of about 100 ma and a resolution of 15 ma with a maximum current of about 150 amps. The range and resolution are related to the coil that is installed, I have coils that will go up to about 2000 amps but will not resolve below about 5 amps, horses for courses and all that.
There is little on here about Rogowski coils, it seems people consider them to be too difficult and needing integrators but that is not the case, they are very easy to wind and you do not need an integrator if you use the rate of change of the output to calculate the current.
Interesting to note that certainly on my LV supply in the UK the third harmonic is huge, my incoming waveform hasn't seen a sine wave for eons. For this reason I measure the voltage at 3.33 ms past zero cross over, this removes the third harmonic.
Interesting link if you are UK based. http://www.dynamicdemand.co.uk/grid.htm# My sensor will track that frequency which was a real buzz.
I made a LinuxCNC based machine to wind the Rogowski coils http://homepage.ntlworld.com/dknpower/winder.3gp best use for an inkjet printer ever.
The Raspi has problems for this sort of use. If power is lost it trashes the SD card (or USB stick) so I made a board with battery backup to auto start and shutdown the Pi.
http://homepage.ntlworld.com/dknpower/hackaday/schPI.png
http://homepage.ntlworld.com/dknpower/hackaday/pcbPI.png
The PCB and schematic files are here if you want them
http://homepage.ntlworld.com/dknpower/hackaday/SCH_PCB_ASM.zip
Also on that PCB are a RTC and a temperature/humidity sensor, RTC using I2C and the DTH11 using one wire comms
Sample coil http://homepage.ntlworld.com/dknpower/Image-1.jpg
Some coils being tested http://homepage.ntlworld.com/dknpower/2.jpg
That copper bar is two turns on a transformer, it allows me to make a maximum of about 300 amps.
Prototype sensor http://homepage.ntlworld.com/dknpower/4.jpg
Main problems currently are related to calibrating the measurements. My LV supply is not stable enough to allow accurate calibration so I am currently making a PIC based 50 Hz oscillator to provide stable voltage, current and phase in order to allow me to finalise the equations for accurate measurements. Phase is a real sticky one as the phase shift through the Rogowski coil and associated opamp circuit is dependent on current, a really horrible thing to solve.
Anyway, enough for now, off to read the forum.


The multiselects on this page display all possible 'selected' styles for filtered items on the Dropdown:
left/top shows all selected items moved to the top of the filtered list.
middle shows all selected items moved to the top of their corresponding group headers.
right/bottom shows all selected items remaining in their original place when filtering.


Target: Login Bypass 1 This is a login page. Please try to get into the system. You'll get a key string if success.


| Interface | Description |
|---|---|
| ConnectionCreationListener |
Implementors of this interface will be notified when a new
XMPPConnection
has been created. |
| ConnectionListener |
Interface that allows for implementing classes to listen for connection closing
and reconnection events.
|
| ExceptionCallback | |
| MessageListener | |
| PacketListener | Deprecated
use
StanzaListener instead |
| PresenceListener | |
| StanzaListener |
Provides a mechanism to listen for packets that pass a specified filter.
|
| XMPPConnection |
The XMPPConnection interface provides an interface for connections to an XMPP server and
implements shared methods which are used by the different types of connections (e.g.
|
| Class | Description |
|---|---|
| AbstractConnectionClosedListener | |
| AbstractConnectionListener |
The AbstractConnectionListener class provides an empty implementation for all
methods defined by the
ConnectionListener interface. |
| AbstractXMPPConnection | |
| AbstractXMPPConnection.InterceptorWrapper |
A wrapper class to associate a stanza(/packet) filter with an interceptor.
|
| AbstractXMPPConnection.ListenerWrapper |
A wrapper class to associate a stanza(/packet) filter with a listener.
|
| ConnectionConfiguration |
Configuration to use while establishing the connection to the server.
|
| ConnectionConfiguration.Builder<B extends ConnectionConfiguration.Builder<B,C>,C extends ConnectionConfiguration> |
A builder for XMPP connection configurations.
|
| Manager | |
| PacketCollector |
Provides a mechanism to collect packets into a result queue that pass a
specified filter.
|
| PacketCollector.Configuration | |
| ReconnectionManager |
Handles the automatic reconnection process.
|
| SASLAuthentication |
This class is responsible authenticating the user using SASL, binding the resource
to the connection and establishing a session with the server.
|
| SmackConfiguration |
Represents the configuration of Smack.
|
| SmackInitialization | |
| SynchronizationPoint<E extends java.lang.Exception> | |
| UnparseableStanza |
Representation of an unparsable stanza.
|
| XMPPConnectionRegistry |
| Enum | Description |
|---|---|
| ConnectionConfiguration.SecurityMode |
An enumeration for TLS security modes that are available when making a connection
to the XMPP server.
|
| ReconnectionManager.ReconnectionPolicy |
Reconnection Policy, where
ReconnectionManager.ReconnectionPolicy.RANDOM_INCREASING_DELAY is the default policy used by smack and ReconnectionManager.ReconnectionPolicy.FIXED_DELAY implies
a fixed amount of time between reconnection attempts. |
| XMPPConnection.FromMode |


μPresent compiles Markdown into HTML5 for beautiful, light-weight presentations.
μPresent's syntax is elegant:
Sample Presentation Title
theme: Modern Dark
-----------
# My Presentation
Made with uPresent and love :)
-----------
# My Slide Header
~ A bullet point
~ Another bullet point
And μPresent's themes look beautiful and professional (try clicking it and using the arrow keys):
μPresent is tiny (under 700 line of code at the time of writing) and written in simple JavaScript code with nearley
Finally, μPresent is a true compiler, which means the resulting presentation will not contain the entire μPresent codebase like other HTML5 presentations solutions do, making for simpler, faster code. Presentations made with μPresent can be read with the links web browser!
Try the web-based IDE, use the web-based compiler, get it on npm, or star and read the docs!
Syntax
One underscore is _italics_. Two asterisks are **bold**.
One hashtag at the beginning of the line creates a header:
# Header
Brackets around a label followed by parantheses around a URL creates a [link](http://github.com/bobbybee/uPresent
Or, just put a link with nothing around it to make an unnamed link http://github.com/bobbybee/uPresent
~ Lists are constructed with a tilde character at the beginning of a line
~~ And for extra information, use two tildes
Last (but certainly not least), a bunch of hyphens make a new slide
-------------


Welcome to Erlang/OTP, a complete
development environment
for concurrent programming.
Some hints that may get you started faster
-
The complete Erlang language is described in the
Erlang Reference Manual.
An Erlang tutorial can be found in
Getting Started With Erlang.
In addition to the documentation here Erlang is described in the book "Programming Erlang", ISBN 978-1-934356-00-5, which we highly recommend as a start. During 2009 there are also new Erlang books from O'Reilly and Manning to be expected.
- Erlang/OTP is divided into a number of OTP applications. An application normally contains
Erlang modules. Some OTP applications,
such as the C interface erl_interface, are written in other languages and have no Erlang
modules.
Note that functions that are not imported or prefixed with a module name belong to the module erlang (in the Erts application).
- On a Unix system you can view the manual pages from the command
line using
% erl -man <module>
- You can of course use any editor you like to write Erlang
programs, but if you use Emacs there exists editing support such as
indentation, syntax highlighting, electric commands, module name
verification, comment support including paragraph filling, skeletons,
tags support and more. See the
Tools application for details.
There is also an Erlang plugin (ErlIde) for Eclipse if you prefer a more graphical environment. ErlIde still under active development with new features in almost every release.
- When developing with Erlang/OTP you usually test your programs
from the interactive shell (see
Getting Started With Erlang) where you can call individual
functions. There is also a number of tools available, such as the graphical Debugger, the process
manager Pman and table
viewer TV.
Also note that there are some shell features like history list (control-p and control-n), in line editing (emacs key bindings) and module and function name completion (tab) if the module is loaded.
- OpenSource users can ask questions
and share experiences on the
Erlang questions mailing list.
- Before asking a question you can browse the
mailing list archive and read the Frequently
Asked Questions.
- Additional information and links of interest for Erlang programmers can be found on the Erlang Open Source site
http://www.erlang.org.


Simulation of field- and frequency-sweep cw EPR spectra of tumbling spin systems in the slow-motional regime.
chili(Sys,Exp) spec = chili(...) [B,spec] = chili(...) ... = chili(Sys,Exp,Opt)
See also the user guide on how to use chili
.
chili
computes cw EPR spectra in the slow-motional regime. It uses rotational Brownian diffusion to model the rotational tumbling of the spin system. The simulation is based on solving the Stochastic Liouville equation in a basis of rotational eigenfunctions. chili
supports arbitrary spin systems.
chili
takes up to three input arguments
Sys
: static and dynamic parameters of the spin system
Exp
: experimental parameters
Opt
: options and settings
If no input argument is given, a short help summary is shown (same as when typing help chili
).
Up to two output arguments are returned:
B
: magnetic field axis, in mT
spc
: spectrum
If no output argument is requested, chili
plots the spectrum.
chili
can simulate field-swept spectra as well as frequency-swept spectra. For field-swept spectra, specify Exp.mwFreq
(in GHz) and Exp.Range
(in mT); for frequency-swept spectra specify Exp.Field
(in mT) and Exp.mwRange
(in GHz).
Sys
is a structure containing the parameters of the spin system. See the documentation on spin system structures for details. Most of the common spin system parameters are supported. However, chili
does not support strains (gStrain
, etc.).
For simulating a multi-component mixture, give a cell array of spin systems in Sys
, e.g. {Sys1,Sys2}
for a two-component mixture. Each of the component spin systems should have a field weight
that specifies the weight of the corresponding component in the final spectrum.
In addition to the static spin system parameters, Sys
should contain dynamic parameters relevant to the motional simulation. To specify the rate of rotational diffusion, give one of the fields tcorr
, logtcorr
, Diff
, or logDiff
.
tcorr
txyz
: isotopic diffusion, corresponding to [txyz txyz txyz]
[txy tz]
: anisotropic diffusion with axial diffusion tensor, corresponding to [txy txy tz]
[tx ty tz]
: anisotropic diffusion with rhombic diffusion tensor
For example,
Sys.tcorr = 1e-9; % isotropic diffusion, 1 ns correlation time Sys.tcorr = [5 1]*1e-9; % axial anisotropic diffusion, 5 ns around x and y axes, 1 ns around z Sys.tcorr = [5 4 1]*1e-9; % rhombic anisotropic diffusion
Instead of tcorr
, Diff
can be used, see below. The correlation time tcorr
and the diffusion rate Diff
are related by
tcorr = 1/(6*Diff); % tcorr in s, Diff in rad^2 s^-1
logtcorr
tcorr
, offering an alternative way to specify the rotational dynamics.
Use this instead of tcorr
for least-squares fitting with esfit.
Sys.logtcorr = -9; % corresponds to tcorr = 1e-9 s
Diff
Dxyz
: isotopic diffusion tensor, corresponding to [Dxyz Dxyz Dxyz]
[Dxy Dzz]
: axial tensor, corresponding to [Dxy Dxy Dzz]
[Dxy Dxy Dzz]
: rhombic tensor
logDiff
DiffFrame
[a b c]
containing the Euler angles, in radians, describing the orientation of the rotational diffusion tensor frame relative to the molecular frame. DiffFrame
gives the angles for the transformation of the molecular frame into the rotational diffusion tensor eigenframe. See frames for more details.
In addition to the rotational dynamics, convolutional line broadening can be included using Sys.lw
or Sys.lwpp
.
lwpp
GaussianPP
[GaussianPP LorentzianPP]
lw
GaussianFWHM
[GaussianFWHM LorentzianFWHM]
chili
can model hindered rotation using an orientational potential, which can be specified in Sys.Potential
.
Potential
An array of coefficients for the orientational potential, with four numbers per row: L, M, K, and λ. The potential is expressed as U(Ω) = - kB T ΣL,M,KλLM,KDLM,K, where the DLM,K are Wigner functions and λLM,K are the possibly complex-valued coefficients. L is a nonnegative integer, and both M and K are integers between -L and L.
Sys.Potential = [2 0 0 0.3]; % L=2, M=K=0 coefficient is 0.3 Sys.Potential = [2 0 0 0.3; 2 0 2 -0.1]; % two coefficients
Since the overall potential must be real-valued, there is a symmetry relation between coefficients with the same L, |M| and |K|: λL-M,-K = (-1)M-K (λLM,K)*. Therefore, chili
limits the input coefficients to: (1) those with positive K, (2) those with K=0 and positive M, (3) the one with M=K=0 which must be real-valued. All others are supplemented internally using the symmetry relation.
To plot the orientational potential, use the function oripotentialplot by calling oripotentialplot(Sys.Potential)
.
The frame of the orientational potential is assumed to be collinear with that of the rotational diffusion tensor (Sys.DiffFrame
).
The orientational symmetry of the potential reflects the symmetry of the paramagnetic molecule and the symmetry of the nanoenvironment in which it is tumbling:
chili
simulation performance varies greatly with the type of potential. The simulations are fastest if all potential terms have M=K=0, they are fast if all terms are M=0 or if all terms are K=0, and they are very slow if any term has both M and K different from zero.
For concentrated solutions, it is possible to include Heisenberg exchange:
Exchange
Effective Heisenberg spin exchange rate, in inverse microseconds. Implements a simple contact-exchange model, see eq. (A27) from Meirovitch et al, J.Chem.Phys.77, 3915-3938. See also Freed, in: Spin Labeling (ed. L.J. Berliner), 1976, p.68.
The experiment structure Exp
contains all parameters relating to the experiment. These settings are identical for all cw EPR simulation functions (pepper, chili, garlic). See the page on cw EPR experimental parameters.
Opt
, the options structure, collects all settings relating to the algorithm used and the behavior of the function. The most important settings are LLMK
, highField
, pImax
, and nKnots
, since they determine the basis size and the number of orientations for powder averaging. If any of these settings is too small, the spectrum will not be converged.
LLMK
[evenLmax oddLmax Mmax Kmax]
chili
uses a default basis. This is adequate only for common X-band spectra of nitroxides. In general, the basis needs to be larger for slower motions and can be smaller for faster motions. It is strongly advised to increase these four numbers until the simulated spectrum is converged. One approach is to start from [2 0 0 0]
and increase each of the four numbers in turn, run the simulation, and see if the spectrum changes. Once the spectrum doesn't change anymore, the basis is sufficiently large.
highField
false
, includes all transitions with pS = mS'-mS'' = -1 and +1. This is applicable in all cases. In certain situations, one can get away with setting highField
to true
. This indicates the high-field approximation, and that only transitions with pS = +1 are included. This reduces the basis and speeds up simulations, but can result in incorrect spectra under certain circumstances. It is important to always check such simulations against highField=false
.
pImax
pImax
, the spin basis is truncated, and the calculation runs faster. For nitroxides, truncation to Opt.pImax=1
often works and can yield spectra fairly close to the correct one. Truncation to Opt.pImax=0
rarely works and is generally not advisable.
pImaxall
Opt.pImax
.
nKnots
Exp.CrystalOrientation
is set, a powder simulation is performed. The default value for nKnots
is 19. Increase this value if the orientational potential coefficients in Sys.Potential
are large.
LiouvMethod
'fast'
and 'general'
. The fast method is very fast, but limited to one electron spin with S=1/2 coupled to up to two nuclei and to orientational potentials with even L≤4, zero M, even K ≤2, and real coefficients. On the other hand, the general method works for any spin system and any form of potential, but is significantly slower. By default, chili
uses the fast method if applicable and falls back to the general method otherwise.
FieldSweepMethod
'explicit'
, 'approxinv'
, and 'approxlin'
. 'explicit`
indicates that the spectral intensity should be calculated separately and explicitly for each field value. This is the accurate method. In many cases, using 'approxlin'
or 'approxinv'
results in much faster simulations. For these settings, a frequency-swept spectrum is calculated first and then converted to the field domain. This procedure is only approximate. 'approxinv'
works best if the g anisotropy dominates the spectrum, in all other cases (e.g. dominant hyperfine or zero-field splittings), 'approxlin'
is preferable.
PostConvNucs
Sys.Nucs = '14N,1H,1H,1H'
and Opt.PostConvNucs = [2 3 4]
, the only the nitrogen is used in the SLE simulation, and all the protons are included via post-convolution.
Post-convolution is useful for including the effect of nuclei with small hyperfine couplings in spin systems with many nuclei that are too large to be handled by the SLE solver. Nuclei with large hyperfine couplings should never be treated via post-convolution. Only nuclei should be treated by post-convolution for which the hyperfine couplings (and anisotropies) are small enough to put them in the fast-motion regime, close to the isotropic limit, for the given rotational correlation time in Sys.tcorr
etc.
Solver
'L'
,
'\'
,
'E'
,
'B'
, or
'C'
'L'
(Lanczos tridiagonalization with continued-fraction expansion), '\'
(MATLAB's backslash solver), 'E'
(via eigenvalues), 'B'
(biconjugate gradient stabilized method), and 'C'
(conjugate gradient tridiagonalization with continued-fraction expansion). If not given, a solver is selected automatically.
Symmetry
'Dinfh'
(default), 'D2h'
, 'C2h'
or 'Ci'
'Dinfh'
corresponds to a line from θ=0° to &theta=90° (with φ=0°), 'D2h'
to one octant, 'C2h'
to two octants, and 'Ci'
to one hemisphere (four octants). The default 'Dinfh'
is correct only for high-symmetry spin systems in high-symmetry potentials. In general, it is advised to run a simulation with Ci
, which is slower, but correct for any situation.
Verbosity
chili
prints to the command window. If Opt.Verbosity=0
, is is completely silent. 1 prints details about the progress of the computation.
The cw EPR spectrum of a nitroxide radical tumbling in solution on a time scale of nanoseconds can be simulated with the following lines.
clear Sys.g = [2.008 2.0061 2.0027]; Sys.Nucs = '14N'; Sys.A = [16 16 86]; % MHz Sys.tcorr = 3e-9; % 3 ns Exp.mwFreq = 9.5; % GHz chili(Sys,Exp);
chili
solves the Stochastic Liouville equation (SLE). It represents the orientational distribution of the spin system using normalized Wigner rotation functions DLK,M(Ω) with -L≤K,M≤L as basis functions. The number of basis functions is determined by maximum values of even L, odd L, K and M. The larger these values, the larger the basis and the more accurate the spectrum.
chili
computes EPR line positions to first order, which is appropriate for most organic radicals. It is inaccurate for transition metal complexes, e.g. Cu2+ or VO2+. For the diffusion, both secular and nonsecular terms are included.
If the spin system has S=1/2 and contains no more than two nuclei, chili
by default uses a fast method to construct the Liouvillian matrix that uses code based on the software from the Freed lab at Cornell (Opt.Method='fast'
). For all other cases, a general code is used to construct the Liouvillian matrix.
Post-convolution works as follows: First, the SLE is used to simulate the spectrum of all nuclei except those marked for post-convolution. Next, the isotropic stick spectrum due to all post-convolution nuclei is simulated and convolved with the SLE-simulated spectrum to give the final spectrum.
For full details of the various algorithms see


--- layout: default title: Winners section_id: portfolio works: - image: https://twitter.com/akmal_waheed/profile_image?size=bigger title: Akmal Waheed link_to: https://twitter.com/akmal_waheed klass: season1 desc: Season 1 - image: https://twitter.com/awschamp/profile_image?size=original title: Timothy Patterson link_to: https://twitter.com/awschamp klass: season2 desc: Season 2 - image: https://twitter.com/StevenViljoen/profile_image?size=original title: Steven Viljoen link_to: https://twitter.com/StevenViljoen klass: season3 desc: Season 3 - image: https://twitter.com/_KatkaW_/profile_image?size=original title: Katarina Wagnerova link_to: https://twitter.com/_KatkaW_ klass: season4 desc: Season 4 ---


{% extends "layout.html" %} {% block title %}Home{% endblock %} {% block main %}
As Computer Science students, using the labs in Lawson or in Haas was an essential part of succeeding in many classes. You can bounce ideas off of people for projects or find help in something you may be struggling with. However, sometimes it was difficult to find the labs when they were not completely full. This app will help minimize finding an open lab room or help with a project so students can waste less time finding a free computer during a busy time and more time being successful Purdue Computer Science students. Lab Broadcaster monitors the lab usage for all the computer labs in the Lawson and Haas buildings, showing current user capacities and schedules for the lab rooms. Our application also gives the user a list of users who are looking for help. This impact on Computer Science students will help students be more time efficient and successful at Purdue University.


Preparation time
less than 30 mins
Cooking time
30 mins to 1 hour
Serves
Makes 24 biscotti
Dietary
Pistachio nuts and coconut add incredible flavour to these biscotti. Make them extra special by serving them with a homemade coconut brittle.
Preheat the oven to 180C/160C Fan/Gas 4.
Put the coconut chips in a dry frying pan and toast them until golden-brown, stirring regularly. Toast the pistachios and fennel seeds in the same way, then transfer the pistachios and fennel seeds to a food processor and pulse until they are just broken. Set aside to cool.
In a large bowl, cream together butter and sugar until pale and fluffy. Mix in the eggs and coconut essence.
Combine the flour, baking powder, salt, toasted coconut, pistachios and three-quarters of the fennel seeds. Add to the butter mixture and mix until well combined (the mixture will be quite stiff so you will find it easier to use an electric mixer). Divide the dough into 2 equal mounds.
Line 2 baking trays with baking parchment. Place a mound of dough onto each tray and shape them into a rectangle approximately 25x8cm/10x3¼in. Bake for 35 minutes.
Remove the dough from the oven and set aside to cool on the tray for 15 minutes. Reduce the oven temperature to 160C/140C Fan/Gas 2.
Slice each log into pieces about 1cm/½in thick. Each log should produce about 12 biscotti.
Place the pieces cut-side down on the baking trays and return them to the oven. Bake for 10 minutes on each side, or until they are golden-brown and crisp. Leave to cool on a wire rack.
For the coconut brittle, line a baking tray with non-stick baking paper.
Add the sugar, butter and 125ml/4½oz water to a large saucepan. Heat gently until the sugar dissolves. Using a sugar thermometer, continue to heat the mixture to 160C, or until a caramel forms. Remove from the heat immediately and stir in the coconut. Stir in the bicarbonate of soda – the caramel will start to foam so take care not to burn yourself, melted sugar is very hot. Pour onto the prepared tray and leave to cool.
When cool, break the brittle into large pieces and add to a food processor. Add the reserved fennel seeds and pulse until broken into a coarse powder. Transfer to a shallow dish.
Melt the dark chocolate in a heatproof bowl over a pan of simmering water. Dip the long side of the biscotti in the melted chocolate and then into the coconut brittle. Set aside until the chocolate is set, then serve.


Toggle navigation
Home
Services
General Maintenance
Engine Repair
Tire Services
Brake Services
Transmission Repair
About us
Shop
Blog
Blog sidebar left
Blog sidebar right
Blog post
Contacts
+1-567-890-8900
get an estimate
Working Hours:
Mon - Fri: 7:30 am - 6:30 pm
Sat - Sun: 10:30 am - 5:30 pm
Location:
34 Grange Rd Fairfield VIC 3078
Skype: perfectgear
Whatsapp: +1-567-890-8900
Twitter: @perfectgear
Home page
Contacts
Contacts
Location
37 Grange Rd Fairfield VIC 3078
Phone
1<PHONE_NUMBER>
Fax
1<PHONE_NUMBER>
E-mail
<EMAIL_ADDRESS>Contact us
Send
Get directions


Form
Company Name
Name
Select Account Type
Account Type
Large
SME
Strategic
Number
Email
Title
Address
Key Notes
Convert to lead TAB


Reports JUnit 3 style test methods which are located inside a class which does not extend JUnit 3
TestCase
class and contains JUnit 4/JUnit 5
@Test
annotated methods. In addition to being confusing such test methods will not be run.


Updated: 2020-11-30 00:02:05 +0000
Like most people, I found crypto first. After a while some of the hype began to wear off, and I realized that all of these cryptocurrencies are trying to rise off of the success of Bitcoin. I began to focus a lot more on learning about Bitcoin, but still treated Bitcoin as part of the greater ecosystem of crypto projects.
While that approach was fine in the beginning, I started feeling that Bitcoin wasn’t getting the proper attention, mixed in with all of my crypto-content. I also decided to get a lot more serious about Curating Bitcoin.
Practical Bitcoin Info
One of my first really big projects around Bitcoin was to gather all the tools and practical information about Bitcoin into a google sheet. I decided the most well organized content I’d found online was about Bitcoin, and thought I could help make the information related to using Bitcoin easier to find.
There are two tabs, one for Bitcoin and one for the Lightning Network.
Bitcoinfo.xyz
Then, I began pulling all of my Bitcoin History from the SourceCrypto website, and made an organization on Github to organize all my Bitcoin related content and forked repositories.
- Bitcoinfo GitHub organization
Bitcoinfo Practical
- Info + Best Practices · Bitcoin Security
- Paper, Mobile, Desktop, and Hardware · Bitcoin Wallets and Utilities
- Tools and Apps · Bitcoin Trading
- 🛰 · Bitcoin Satellite Nodes
- Earn or Buy, don’t borrow! · Get Bitcoin!!!!!
- Validate the Blockchain · Bitcoin Full-Node
- Books, Resources and other Guides · Programming with Bitcoin
- Data data data · Bitcoin Data and Analytics
- Leveraging the Bitcoin blockchain · Layer One Applications
- Wallets, Applications, Guides and Development · Lightning Network Info
Bitcoin History
- Satoshi Nakamoto the Pseudonymous Creator of Bitcoin
- Darknet Market Histories
- Hacking and Hacker Culture.
- Bitcoin History Curated
- Histories of Digital Cryptography
While these can be found in the bitcoinfo website, bitcoin-history used to have its own independent website, with some followers on github, so I stripped that down to just the markdown files, to let that resource continue it’s distinct life.
What’s Next?
All in all, this is just the beginning of my inquiry into Bitcoin and related areas of study. It’s a deep subject, requiring extra attention.
Bitcoinfo could use some work in the way of, originally it was just a collection of links that I had saved, which didn’t really address the breadth of the subject.


To get started, try hitting the "Send to Pi" button and pasting in the link to a Youtube video.
You'll be able to use the remote once something is playing.
If you wanna use a bookmarklet to send stuff, here's one for you! Just drag it to your bookmarks bar. Send to Pi
{% endblock %}


galaxy_dive.analyze_data.simulation_data module¶
Class for analyzing simulation data.
@author: Zach Hafen @contact<EMAIL_ADDRESS>@status: Development
-
class
galaxy_dive.analyze_data.simulation_data.
SimulationData
(data_dir=None, halo_data_dir=None, ahf_index=None, averaging_frac=4.0, length_scale_used='Rstar0.5', z_sun=0.02, halo_data_retrieved=False, centered=False, vel_centered=False, hubble_corrected=False, ahf_tag='smooth', main_halo_id=0, center_method='halo', vel_center_method='halo', store_ahf_reader=False, **kwargs)[source]¶ Bases:
galaxy_dive.analyze_data.generic_data.GenericData
Class for handling simulation data.
Parameters: - data_dir (str) – Directory the simulation is contained in.
- halo_data_dir (str) – Directory simulation halo catalogs are contained in. Defaults to data_dir
- ahf_index (str) – What to index the snapshots by. Should be the last snapshot in the simulation if AHF was run backwards from the last snapshot. Required to put in manually to avoid easy mistakes.
- averaging_frac (dict) – There are some averaged quantities (e.g. COM velocity, total angular momentum) that we consider. This is the fraction of length_scale_used within which we calculate these.
- length_scale_used (str) – What length scale to use for the simulation. Will be used to put lengths in fractions.
- z_sun (float) – Used mass fraction for solar metallicity.
- halo_data_retrieved (bool) – Whether or not we retrieved relevant values from the AHF halo data.
- centered (bool) – Whether or not the coordinates are centered on the galaxy of choice at the start.
- vel_centered (bool) – Whether or not the velocities are relative to the galaxy of choice at the start.
- hubble_corrected (bool) – Whether or not the velocities have had the Hubble flow added (velocities must be centered).
- ahf_tag (str) – Identifying tag for the ahf merger tree halo files, looks for ahf files of type ‘halo_00000_{}.dat’.format( tag ).
- main_halo_id (int) – What is the halo ID of the main galaxy in the simulation?
- center_method (str or np.array) –
How to center the coordinates. Options are…
- ’halo’ (default) : Centers the dataset on the main halo
- (main_halo_id) using AHF halo data.
np.array : Array of coordinates on which to center the data
- vel_center_method (str or np.array of size 3) –
How to center the velocity coordinates, i.e. what the velocity is relative to. Options are…
- ’halo’ (default) : Sets velocity relative to the main halo
- (main_halo_id) using AHF halo data.
- np.array of size 3 :
- Centers the dataset on this coordinate.
Keyword Arguments: function_args (dict) – Dictionary of args used to specify an arbitrary function with which to generate data.
-
add_hubble_flow
()[source]¶ Correct for hubble flow movement.
- Modifies:
- self.data[‘V’] : Accounts for hubble flow, relative to origin
-
base_data_shape
¶ Property for simulation redshift.
-
calc_velocity_magnitude
()[source]¶ Calculate the velocity relative to an origin velocity for a given particle.
-
center_coords
()[source]¶ Change the location of the origin, if the data isn’t already centered.
- Modifies:
- self.data[‘P’] : Shifts the coordinates to the center.
-
center_vel_coords
()[source]¶ Get velocity coordinates to center on the main halo.
- Modifies:
- self.data[‘V’] : Makes all velocities relative to self.vel_origin
-
get_data
(data_key, sl=None)[source]¶ Get the data from within the class. Only for getting the data. No post-processing or changing the data (putting it in particular units, etc.) The idea is to calculate necessary quantities as the need arises, hence a whole function for getting the data.
Parameters: Returns: Requested data.
Return type: data (np.ndarray)
-
get_distance_to_point
(point)[source]¶ This is not unit tested.
Parameters: point (array-like of shape (3,)) – The point you want to find the distance to for each particle.
-
get_position_data
(data_key)[source]¶ Get position data (assuming the data starts with an ‘R’)
Parameters: data_key (str) – Key in the data dictionary for the key we want to get Returns: Requested data. Return type: data (np.ndarray)
-
get_potential
(point)[source]¶ This is not unit tested.
Parameters: point (array-like of shape (3,)) – The point you want to find the potential at
-
get_processed_data
(data_key, data_method=<object object>, *args, **kwargs)¶ Get post-processed data. (Accounting for fractions, log-space, etc.).
Parameters: Returns: Requested data, including formatting.
Return type: processed_data (np.ndarray)
-
get_selected_data
(*args, **kwargs)¶ Wrapper for getting masked data.
-
get_velocity_data
(data_key)[source]¶ Get position data (assuming the data starts with a ‘V’)
Parameters: data_key (str) – Key in the data dictionary for the key we want to get Returns: Requested data. Return type: data (np.ndarray)
-
halo_data
¶ Halo data used.
-
handle_data_key_error
(data_key)[source]¶ When get_data() fails to data_key in self.data, it passes the data_key to try and generate that data.
Parameters: data_key (str) – Key to try and generate data for - Modifies:
- self.data[data_key] (np.array) : If it finds a function to generate the data, it will do so
-
hubble_z
¶ Property for the hubble function at specified redshift.
-
iterate_over_method
(method_str, iter_arg, iter_values, method_args)¶ Iterate over a specified method, and get the results out.
Parameters: Returns: [ method( **used_args ) for used_args in all_variations_of_used_args ]
Return type: results (list)
-
length_scale
¶ Property for fiducial simulation length scale.
-
mask_data
(*args, **kwargs)¶ Wrapper for masking data.
-
metallicity_scale
¶ Property for fiducial metallicity scale. By default is z_sun However, a more advanced subclass might set this differently, or this might change in the future.
-
r_scale
¶ Property for scale radius.
-
r_vir
¶ Property for virial radius.
-
redshift
¶ Property for simulation redshift.
-
shift
(data, data_key)¶ Shift or multiply the data by some amount. Note that this is applied after logarithms are applied.
data : data to be shifted data_key : Data key for the parameters to be shifted Parameters are a subdictionary of self.kwargs ‘data_key’ : What data key the data is shifted for
-
v_c
¶ Property for circular velocity.
-
velocity_scale
¶ Property for fiducial simulation velocity scale.
-
class
galaxy_dive.analyze_data.simulation_data.
SnapshotData
(snum, *args, **kwargs)[source]¶ Bases:
galaxy_dive.analyze_data.simulation_data.SimulationData
Class for analysis of a single snapshot of data.
-
add_hubble_flow
()¶ Correct for hubble flow movement.
- Modifies:
- self.data[‘V’] : Accounts for hubble flow, relative to origin
-
base_data_shape
¶ Property for simulation redshift.
-
calc_abs_phi
(vector='total gas ang momentum')[source]¶ The angle (in degrees) from some vector, but don’t mirror it around 90 degrees (e.g. 135 -> 45 degrees, 180 -> 0 degrees).
-
calc_phi
(normal_vector='total ang momentum')[source]¶ Calculate the angle (in degrees) from some vector. By default the vector is the total angular momentum.
-
calc_radial_distance
()¶ Calculate the distance from the origin for a given particle.
-
calc_rho_xy
()¶ Calculate impact parameter in the xy-plane.
-
calc_rho_xz
()¶ Calculate impact parameter in the xz-plane.
-
calc_rho_yz
()¶ Calculate impact parameter in the yz-plane.
-
center_coords
()¶ Change the location of the origin, if the data isn’t already centered.
- Modifies:
- self.data[‘P’] : Shifts the coordinates to the center.
-
center_vel_coords
()¶ Get velocity coordinates to center on the main halo.
- Modifies:
- self.data[‘V’] : Makes all velocities relative to self.vel_origin
-
central_mask
¶ This mask is used when, for example, finding the velocity of the center of mass.
-
dN_halo
¶ Calculate dN_halo/dX/dlog10Mh or dN_halo/dz/dlog10Mh. X is absorption path length (see for example Ribaudo+11)
- time_units: ‘abs_length’- dN_halo/dX/dlog10Mh
- ‘redshift’ - dN_halo/dz/dlog10Mh
- R_vir: None - Default, assumes given.
- ‘BN’ Calculates R_vir from the mass and redshift
-
dist_to_point
(point, units='default')[source]¶ Calculate the distance to a point for all particles.
point : np array that gives the point
-
get_data
(data_key, sl=None)¶ Get the data from within the class. Only for getting the data. No post-processing or changing the data (putting it in particular units, etc.) The idea is to calculate necessary quantities as the need arises, hence a whole function for getting the data.
Parameters: Returns: Requested data.
Return type: data (np.ndarray)
-
get_distance_to_point
(point)¶ This is not unit tested.
Parameters: point (array-like of shape (3,)) – The point you want to find the distance to for each particle.
-
get_position_data
(data_key)¶ Get position data (assuming the data starts with an ‘R’)
Parameters: data_key (str) – Key in the data dictionary for the key we want to get Returns: Requested data. Return type: data (np.ndarray)
-
get_potential
(point)¶ This is not unit tested.
Parameters: point (array-like of shape (3,)) – The point you want to find the potential at
-
get_processed_data
(data_key, data_method=<object object>, *args, **kwargs)¶ Get post-processed data. (Accounting for fractions, log-space, etc.).
Parameters: Returns: Requested data, including formatting.
Return type: processed_data (np.ndarray)
-
get_selected_data
(*args, **kwargs)¶ Wrapper for getting masked data.
-
get_velocity_data
(data_key)¶ Get position data (assuming the data starts with a ‘V’)
Parameters: data_key (str) – Key in the data dictionary for the key we want to get Returns: Requested data. Return type: data (np.ndarray)
-
halo_data
¶ Halo data used.
-
handle_data_key_error
(data_key)¶ When get_data() fails to data_key in self.data, it passes the data_key to try and generate that data.
Parameters: data_key (str) – Key to try and generate data for - Modifies:
- self.data[data_key] (np.array) : If it finds a function to generate the data, it will do so
-
hubble_z
¶ Property for the hubble function at specified redshift.
-
iterate_over_method
(method_str, iter_arg, iter_values, method_args)¶ Iterate over a specified method, and get the results out.
Parameters: Returns: [ method( **used_args ) for used_args in all_variations_of_used_args ]
Return type: results (list)
-
length_scale
¶ Property for fiducial simulation length scale.
-
mask_data
(*args, **kwargs)¶ Wrapper for masking data.
-
metallicity_scale
¶ Property for fiducial metallicity scale. By default is z_sun However, a more advanced subclass might set this differently, or this might change in the future.
-
r_scale
¶ Property for scale radius.
-
r_vir
¶ Property for virial radius.
-
redshift
¶ Property for simulation redshift.
-
shift
(data, data_key)¶ Shift or multiply the data by some amount. Note that this is applied after logarithms are applied.
data : data to be shifted data_key : Data key for the parameters to be shifted Parameters are a subdictionary of self.kwargs ‘data_key’ : What data key the data is shifted for
-
total_ang_momentum
¶ Calculate the total angular momentum vector.
-
v_c
¶ Property for circular velocity.
-
v_com
¶ Property for the velocity of the center of mass.
-
velocity_scale
¶ Property for fiducial simulation velocity scale.
-
-
class
galaxy_dive.analyze_data.simulation_data.
TimeData
(data_masker=None, *args, **kwargs)[source]¶ Bases:
galaxy_dive.analyze_data.simulation_data.SimulationData
Class for analysis of a time series data, e.g. the worldlines of a number of particles.
-
add_hubble_flow
()¶ Correct for hubble flow movement.
- Modifies:
- self.data[‘V’] : Accounts for hubble flow, relative to origin
-
base_data_shape
¶ Property for simulation redshift.
-
calc_abs_phi
(normal_vector='total ang momentum')[source]¶ Calculate the angle (in degrees) from some vector, but mirror values past 90 degrees (e.g. 135 -> 45 degrees, 180 -> 0 degrees). This is useful when there’s symmetry above and below 90.
Parameters: normal_vector (str or array-like) – Vector that represents the vertical. Defaults to using the total stellar angular momentum of the main galaxy. - Modifies:
- self.data[‘AbsPhi’] (array-like):
- Angle from the vector, in many cases acting as the angle from the disk axis.
-
calc_ang_momentum
()[source]¶ The angular momentum (in the standard coordinates).
- Modifies:
- self.data[‘L’] (array-like):
- Angular momentum of each resolution element.
-
calc_enriched_metal_mass
()[source]¶ Calculate the metal mass that comes from enrichment for each resolution element, not counting mass that’s at the metallicity floor. Assumes that the there will always be at least one resolution element in the simulation that’s at the metallicity floor.
- Modifies:
- self.data[‘enriched_metal_mass’] (array-like):
- Metal mass from enrichment.
-
calc_metal_mass
()[source]¶ Calculate the metal mass held by each resolution element.
- Modifies:
- self.data[‘enriched_metal_mass’] (array-like):
- Metal mass from enrichment.
-
calc_phi
(normal_vector='total ang momentum')[source]¶ Calculate the angle (in degrees) from some vector. By default the vector is the total angular momentum.
Parameters: normal_vector (str or array-like) – Vector that represents the vertical.
-
calc_radial_distance
()¶ Calculate the distance from the origin for a given particle.
-
calc_rho_xy
()¶ Calculate impact parameter in the xy-plane.
-
calc_rho_xz
()¶ Calculate impact parameter in the xz-plane.
-
calc_rho_yz
()¶ Calculate impact parameter in the yz-plane.
-
calc_velocity_magnitude
()¶ Calculate the velocity relative to an origin velocity for a given particle.
-
center_coords
()¶ Change the location of the origin, if the data isn’t already centered.
- Modifies:
- self.data[‘P’] : Shifts the coordinates to the center.
-
center_vel_coords
()¶ Get velocity coordinates to center on the main halo.
- Modifies:
- self.data[‘V’] : Makes all velocities relative to self.vel_origin
-
get_data
(data_key, sl=None)¶ Get the data from within the class. Only for getting the data. No post-processing or changing the data (putting it in particular units, etc.) The idea is to calculate necessary quantities as the need arises, hence a whole function for getting the data.
Parameters: Returns: Requested data.
Return type: data (np.ndarray)
-
get_distance_to_point
(point)¶ This is not unit tested.
Parameters: point (array-like of shape (3,)) – The point you want to find the distance to for each particle.
-
get_position_data
(data_key)¶ Get position data (assuming the data starts with an ‘R’)
Parameters: data_key (str) – Key in the data dictionary for the key we want to get Returns: Requested data. Return type: data (np.ndarray)
-
get_potential
(point)¶ This is not unit tested.
Parameters: point (array-like of shape (3,)) – The point you want to find the potential at
-
get_processed_data
(data_key, sl=None, smooth_data=False, smoothing_window_length=9, smoothing_polyorder=3, a_power=None, scale_key=None, scale_a_power=None, scale_h_power=None, tile_data=False, tile_dim='auto', *args, **kwargs)[source]¶ Modified method for getting processed method. For the most part is equivalent to calling the method of the parent class, but is also capable of scaling the retrieved data by a column from the halo data.
Parameters: - data_key (str) – What to get out?
- sl (slice) – Slice of the data, if requested.
- smooth_data (bool) – If True, smooth the data.
- smoothing_polyorder (smoothing_window_length,) – Arguments for how to smooth the data.
- scale_key (str) – Halo data entry by which to divide the data by.
- scale_a_power (float) – The halo data that we are scaling processed_data by will be multiplied by a to this power. Useful for data in cosmological units (as is often normal).
- scale_h_power (float) – The halo data that we are scaling processed_data by will be multiplied by the hubble parameter to this power. Useful for data in cosmological units (as is often normal).
- tile_data (bool) – If True, tile data along a given direction. This is usually for data formatting purposes.
- tile_dim (str) –
If the data is tiled, what dimension of the data should match? Options:
- ’auto’ :
- Tiles according to data size.
- ’match_snaps’ :
- The data is tiled such that the new shape is (self.n_snaps, data_size).
- ’match_particles’ :
- The data is tiled such that the new shape is (data_size, self.n_particles).
- **kwargs (*args,) –
Passed to SimulationData.get_processed_data.
Returns: Requested data array.
Return type: processed_data (array-like)
-
get_selected_data
(*args, **kwargs)¶ Wrapper for getting masked data.
-
get_selected_data_over_time
(*args, **kwargs)[source]¶ Wrapper for geting masked data as a function of time.
-
get_velocity_data
(data_key)¶ Get position data (assuming the data starts with a ‘V’)
Parameters: data_key (str) – Key in the data dictionary for the key we want to get Returns: Requested data. Return type: data (np.ndarray)
-
halo_data
¶ Halo data used.
-
handle_data_key_error
(data_key)[source]¶ When get_data() fails to data_key in self.data, it passes the data_key to try and generate that data.
Parameters: data_key (str) – Key to try and generate data for - Modifies:
- self.data[data_key] (np.array) : If it finds a function to generate the data, it will do so
-
hubble_param
¶
-
hubble_z
¶ Property for the hubble function at specified redshift.
-
iterate_over_method
(method_str, iter_arg, iter_values, method_args)¶ Iterate over a specified method, and get the results out.
Parameters: Returns: [ method( **used_args ) for used_args in all_variations_of_used_args ]
Return type: results (list)
-
length_scale
¶ Property for fiducial simulation length scale.
-
mask_data
(*args, **kwargs)¶ Wrapper for masking data.
-
metallicity_scale
¶ Property for fiducial metallicity scale. By default is z_sun However, a more advanced subclass might set this differently, or this might change in the future.
-
n_particles
¶ Number of snapshots, i.e. data points on the time axis.
-
n_snaps
¶ Number of snapshots, i.e. data points on the time axis.
-
r_scale
¶ Property for scale radius.
-
r_vir
¶ Property for virial radius.
-
redshift
¶ Property for simulation redshift.
-
shift
(data, data_key)¶ Shift or multiply the data by some amount. Note that this is applied after logarithms are applied.
data : data to be shifted data_key : Data key for the parameters to be shifted Parameters are a subdictionary of self.kwargs ‘data_key’ : What data key the data is shifted for
-
snums
¶
-
v_c
¶ Property for circular velocity.
-
velocity_scale
¶ Property for fiducial simulation velocity scale.
-
-
class
galaxy_dive.analyze_data.simulation_data.
TimeDataMasker
(time_data)[source]¶ Bases:
galaxy_dive.analyze_data.generic_data.DataMasker
Data masker for worldline data.
-
clear_masks
(clear_optional_masks=False)¶ Reset the masks in total to nothing.
- Modifies:
- self.masks (lists) : Sets to empty
-
get_selected_data
(data_key, mask='total', optional_masks=None, sl=None, apply_slice_to_mask=True, fix_invalid=False, compress=True, mask_multidim_data=True, *args, **kwargs)¶ Get all the data that doesn’t have some sort of mask applied to it. Use the processed data.
Parameters: - data_key (str) – Data key to get the data for.
- mask (str or np.array of bools) – Mask to apply. If none, use the total mask.
- optional_masks (list-like) – List of names of optional masks to use (must be found in self.optional_masks).
- sl (slice) – Slice to apply to the data
- apply_slice_to_mask (bool) – Whether or not to apply the same slice you applied to the data to the mask.
- fix_invalid (bool) – Whether or not to also mask invalid data.
- compress (bool) – Whether or not to return compressed data.
- mask_multidim_data (bool) – Whether or not to change the mask to fit multidimensional data.
- **kwargs (*args,) –
Passed to get_proceesed_data.
Returns: - Compressed masked data. Because it’s compressed it may not have the same shape as the
original data.
Return type: data_ma (np.array)
-
get_selected_data_over_time
(data_key, snum, mask='total', optional_masks=None, n_samples=None, seed=None, *args, **kwargs)[source]¶ Get data over the full time history, based on its mask at one time.
Parameters:
-
get_total_mask
(optional_masks=None)¶ Get the result of combining all masks in the data.
Parameters: optional_masks (list-like) – List of names of optional masks to use (must be found in self.optional_masks). Returns: Result of all masks. Return type: total_mask (np.array of bools)
-
mask_data
(data_key, data_min=<object object>, data_max=<object object>, data_value=<object object>, custom_mask=<object object>, return_or_store='store', optional_mask=False, mask_name=<object object>, *args, **kwargs)¶ Get only the particle data within a certain range. Note that it retrieves the processed data.
Parameters: - data_key (str) – Data key to base the mask off of.
- data_min (float) – Everything below data_min will be masked.
- data_max (float) – Everything above data_max will be masked.
- data_value (float) – Everything except for data_value will be masked.
- custom_mask (bool) – If provided, take in a custom mask instead, using data_key as the label for the mask.
- return_or_store (str) – Whether to store the mask as part of the masks dictionary, or to return it.
- optional_mask (bool) – If True, store in the dictionary self.optional_masks instead.
- mask_name (str) – What name to associate with this mask? Currently only relevant if optional_mask is True. By default uses the data_key as the name.
- **kwargs (*args,) –
Passed to self.data_object.get_processed_data()
Returns: If requested, the mask for data in that range.
Return type: data_mask (np.array of bools)
- Modifies:
- self.masks (list of dicts) :
- Appends a dictionary describing the mask.
-


--- layout: post date: 2010-12-09 time: "09:00:00" authors: ["Greg Wilson"] title: Where Are My Keys? tags: ["Content"] ---
I was looking through some Python code a few days ago, and noticed that its author was using this:
if something in dict.keys(): dict[something] += 1
instead of:
if something in dict: dict[something] += 1
It seems like a small difference, but it's actually a very important one. The second form checks to see whether something
is a key in the dictionary dict
. The first form, on the other hand, creates a list of all the keys in the dictionary, then searches that list from start to finish to see if something
is there. They both produce the right answer, but the fast form does it in constant time, while the slow form (the one with the call to dict.keys()
) takes time proportional to the size of the dictionary. The really bad news is, the "error" is silent.
What other examples have you seen of people getting the right answer the wrong way? And what more could we do to teach people how to avoid these traps? Does it have to be done case by case, or is there something larger or more general we could try to convey?


Welcome to My Gallery
Home
(current)
About
Contact
After
the
Snow
Alone
in the
Mist
Autumn
Falls
Autumn
Twilight
Beautiful
Morning
Bow Hunter
Christmas
Eve
Country
Christmas
Country
Night
Day
Dreamer
Dreamer
Early
Mountain
Snow
Eye Over
the Waters
Fall in
LOVE
Fisherman's
Peace
For the
Fallen
Frozen in
Time
Fun in the
Snow
Happy
Snowman
Home
Church
Home Sweet
Home
Lake
Cabin
Light of
Life
Lover's
Lane
Old Home
Place
Old
Mountain
Home
Peace
in the
Valley
Perfect
Harmony
Pure
Country
Pure
Wilderness
Rustic
Falls
Safe
Haven
Serenity
Road
Shady
Grove
Still
Waters
Storytime
Sycamore
Stream
Tell me
a Story
The Angel
The Grand
9' x 12 ' Wall Mural
The Majestic
Tranquil
Daybreak
Tranquility
Twilight's
Chill
Vision
of Home
Waterfalls
Wayward
Passerby
Winter
Begins
Winter
Bliss
Winter
Valley
Wishing
Well
Previous
Next
All Paintings created and painted by Deborahj Ramey
I own the Copyright to all my paintings.


|
tclap
1.2.4
|
A simple switch argument. More...
#include <SwitchArg.h>
Public Member Functions | |
| SwitchArg (const std::string &flag, const std::string &name, const std::string &desc, bool def=false, Visitor *v=NULL) | |
| SwitchArg constructor. More... | |
| SwitchArg (const std::string &flag, const std::string &name, const std::string &desc, CmdLineInterface &parser, bool def=false, Visitor *v=NULL) | |
| SwitchArg constructor. More... | |
| virtual bool | processArg (int *i, std::vector< std::string > &args) |
| Handles the processing of the argument. More... | |
| bool | combinedSwitchesMatch (std::string &combined) |
| Checks a string to see if any of the chars in the string match the flag for this Switch. More... | |
| bool | getValue () const |
| Returns bool, whether or not the switch has been set. More... | |
| operator bool () const | |
| A SwitchArg can be used as a boolean, indicating whether or not the switch has been set. More... | |
| virtual void | reset () |
| Clears the Arg object and allows it to be reused by new command lines. More... | |
| Public Member Functions inherited from TCLAP::Arg | |
| virtual | ~Arg () |
| Destructor. More... | |
| virtual void | addToList (std::list< Arg *> &argList) const |
| Adds this to the specified list of Args. More... | |
| virtual bool | operator== (const Arg &a) const |
| Operator ==. More... | |
| const std::string & | getFlag () const |
| Returns the argument flag. More... | |
| const std::string & | getName () const |
| Returns the argument name. More... | |
| std::string | getDescription () const |
| Returns the argument description. More... | |
| virtual bool | isRequired () const |
| Indicates whether the argument is required. More... | |
| void | forceRequired () |
| Sets _required to true. More... | |
| void | xorSet () |
| Sets the _alreadySet value to true. More... | |
| bool | isValueRequired () const |
| Indicates whether a value must be specified for argument. More... | |
| bool | isSet () const |
| Indicates whether the argument has already been set. More... | |
| bool | isIgnoreable () const |
| Indicates whether the argument can be ignored, if desired. More... | |
| virtual bool | argMatches (const std::string &s) const |
| A method that tests whether a string matches this argument. More... | |
| virtual std::string | toString () const |
| Returns a simple string representation of the argument. More... | |
| virtual std::string | shortID (const std::string &valueId="val") const |
| Returns a short ID for the usage. More... | |
| virtual std::string | longID (const std::string &valueId="val") const |
| Returns a long ID for the usage. More... | |
| virtual void | trimFlag (std::string &flag, std::string &value) const |
| Trims a value off of the flag. More... | |
| bool | _hasBlanks (const std::string &s) const |
| Checks whether a given string has blank chars, indicating that it is a combined SwitchArg. More... | |
| void | setRequireLabel (const std::string &s) |
| Sets the requireLabel. More... | |
| virtual bool | allowMore () |
| Used for MultiArgs and XorHandler to determine whether args can still be set. More... | |
| virtual bool | acceptsMultipleValues () |
| Use by output classes to determine whether an Arg accepts multiple values. More... | |
Protected Attributes | |
| bool | _value |
| The value of the switch. More... | |
| bool | _default |
| Used to support the reset() method so that ValueArg can be reset to their constructed value. More... | |
| Protected Attributes inherited from TCLAP::Arg | |
| std::string | _flag |
| The single char flag used to identify the argument. More... | |
| std::string | _name |
| A single word namd identifying the argument. More... | |
| std::string | _description |
| Description of the argument. More... | |
| bool | _required |
| Indicating whether the argument is required. More... | |
| std::string | _requireLabel |
| Label to be used in usage description. More... | |
| bool | _valueRequired |
| Indicates whether a value is required for the argument. More... | |
| bool | _alreadySet |
| Indicates whether the argument has been set. More... | |
| Visitor * | _visitor |
| A pointer to a visitor object. More... | |
| bool | _ignoreable |
| Whether this argument can be ignored, if desired. More... | |
| bool | _xorSet |
| Indicates that the arg was set as part of an XOR and not on the command line. More... | |
| bool | _acceptsMultipleValues |
Additional Inherited Members | |
| Static Public Member Functions inherited from TCLAP::Arg | |
| static void | beginIgnoring () |
| Begin ignoring arguments since the "--" argument was specified. More... | |
| static bool | ignoreRest () |
| Whether to ignore the rest. More... | |
| static char | delimiter () |
| The delimiter that separates an argument flag/name from the value. More... | |
| static char | blankChar () |
| The char used as a place holder when SwitchArgs are combined. More... | |
| static char | flagStartChar () |
| static const std::string | flagStartString () |
| static const std::string | nameStartString () |
| static const std::string | ignoreNameString () |
| The name used to identify the ignore rest argument. More... | |
| static void | setDelimiter (char c) |
| Sets the delimiter for all arguments. More... | |
| Protected Member Functions inherited from TCLAP::Arg | |
| void | _checkWithVisitor () const |
| Performs the special handling described by the Visitor. More... | |
| Arg (const std::string &flag, const std::string &name, const std::string &desc, bool req, bool valreq, Visitor *v=NULL) | |
| Primary constructor. More... | |
A simple switch argument.
If the switch is set on the command line, then the getValue method will return the opposite of the default value for the switch.
Definition at line 41 of file SwitchArg.h.
|
inline |
SwitchArg constructor.
| flag | - The one character flag that identifies this argument on the command line. |
| name | - A one word name for the argument. Can be used as a long flag on the command line. |
| desc | - A description of what the argument is for or does. |
| def | - The default value for this Switch. |
| v | - An optional visitor. You probably should not use this unless you have a very good reason. |
Definition at line 144 of file SwitchArg.h.
|
inline |
SwitchArg constructor.
| flag | - The one character flag that identifies this argument on the command line. |
| name | - A one word name for the argument. Can be used as a long flag on the command line. |
| desc | - A description of what the argument is for or does. |
| parser | - A CmdLine parser object to add this Arg to |
| def | - The default value for this Switch. |
| v | - An optional visitor. You probably should not use this unless you have a very good reason. |
Definition at line 154 of file SwitchArg.h.
References TCLAP::CmdLineInterface::add(), and TCLAP::Arg::blankChar().
|
inline |
Checks a string to see if any of the chars in the string match the flag for this Switch.
Definition at line 176 of file SwitchArg.h.
References TCLAP::Arg::_alreadySet, TCLAP::Arg::_checkWithVisitor(), TCLAP::Arg::_flag, _value, TCLAP::Arg::_xorSet, TCLAP::Arg::blankChar(), TCLAP::Arg::delimiter(), TCLAP::Arg::flagStartString(), TCLAP::Arg::nameStartString(), and TCLAP::Arg::toString().
Referenced by processArg(), and TCLAP::MultiSwitchArg::processArg().
|
inline |
Returns bool, whether or not the switch has been set.
Definition at line 117 of file SwitchArg.h.
References _value.
|
inline |
A SwitchArg can be used as a boolean, indicating whether or not the switch has been set.
This is the same as calling getValue()
Definition at line 124 of file SwitchArg.h.
References _value, and reset().
|
inlinevirtual |
Handles the processing of the argument.
This re-implements the Arg version of this method to set the _value of the argument appropriately.
| i | - Pointer the the current argument in the list. |
| args | - Mutable list of strings. Passed in from main(). |
Implements TCLAP::Arg.
Reimplemented in TCLAP::MultiSwitchArg.
Definition at line 230 of file SwitchArg.h.
References TCLAP::Arg::_ignoreable, TCLAP::Arg::argMatches(), combinedSwitchesMatch(), TCLAP::Arg::ignoreRest(), and TCLAP::Arg::toString().
|
inlinevirtual |
Clears the Arg object and allows it to be reused by new command lines.
Reimplemented from TCLAP::Arg.
Reimplemented in TCLAP::MultiSwitchArg.
Definition at line 262 of file SwitchArg.h.
References _default, _value, and TCLAP::Arg::reset().
Referenced by operator bool().
|
protected |
Used to support the reset() method so that ValueArg can be reset to their constructed value.
Definition at line 54 of file SwitchArg.h.
Referenced by reset().
|
protected |
The value of the switch.
Definition at line 48 of file SwitchArg.h.
Referenced by combinedSwitchesMatch(), getValue(), operator bool(), and reset().


The beautiful city of Portland, Oregon will be the host city for Full Stack Conf!
Explore the future of JavaScript with a lineup of industry professionals. Discover new techniques to advance your career as a web developer.
Our expert speaker lineup was just announced, so don't wait too long before grabbing your tickets!
Want to meet the international JavaScript community and share skills with some of the world's top experts, hackers, and makers? Be the first to know what to expect for the future of JavaScript.
Full Stack Conf is committed to being inclusive and welcoming for everyone. We look forward to another intensive day of learning and sharing.
About Treehouse
Treehouse brings affordable technology education to people everywhere to help them achieve their dreams and change the world.
Stay up-to-date on Full Stack Conf


SpaceY was a public Belgian organization that focuses on delivering opensource projects based on new technologies.
These projects were from different areas, answer or redefine different needs and spontaneously break implicit standards in order to show the developer community
that we can still improve current applications but also create new things !
SpaceY was active during 2 long years between 2019 and 2021. Now the members are most of the time still working on open source but doesn't have time anymore to work on SpaceY.


Hints for SRM 607, D2, 250-pointer (BoundingBox)
James S. Plank
Mon Feb 3 19:24:45 EST 2014
Problem Statement.
Let's see if the examples can give us some inspiration. Example 0 is pretty obvious and
Example 1 is pretty clear from their picture. Let's look at example 2 drawn on graph paper:
See the pattern?
- The rectangle's left side will be on the minimum X value.
- The rectangle's right side will be on the maximum X value.
- The rectangle's bottom side will be on the minimum Y value.
- The rectangle's top side will be on the maximum Y value.
So, you need to calculate those minimum and maximum values and use them to calculate the area.


Clovis murder suspect to be held without bond
by Richard BullardCLOVIS, N.M. (KFDA) - A man accused of a murder that happened earlier this month will be held without bond.
A Curry County judge granted the state’s motion to hold Johnny Rae Vigil without bond.
Vigil was indicted by a grand jury for the shooting death of Jahmall Burge that happened on November 7.
Judge Tatum stated Vigil is a danger to the community, and no release conditions would protect the community.
The judge also stated that Vigil had been released from jail 36 hours before the murder.
Vigil has violated his probation in the past, and he has difficulty following conditions of release, according to the judge.


Some problems in probability theory.
A thesis submitted for the degree of Doctor of Philosophy at the University of Oxford
by
Wilfrid S. Kendall.
Linacre College