Monoceros: a Wave Function Collapse plug-in for Grasshopper by Subdigital
Monoceros is a Grasshopper plug-in that fills the entire world with Modules, respecting the given Rules.
Monoceros is a legendary animal living in the huge mountains in the interior of India. Monoceros has the body of a horse, the head of a stag, the feet of an elephant and the tail of a boar. from Unicorn Wiki
It is also a plug-in for Grasshopper, which is a visual programming platform for Rhinoceros 3D CAD software. Monoceros was developed at studio Subdigital by Ján Toth and Ján Pernecký. Monoceros is an implementation of the Wave Function Collapse (WFC) algorithm developed for game design by Maxim Gumin and extended and promoted by Oskar Stålberg with his game Townscaper.
Monoceros serves to fill the entire world with Modules, respecting the given Rules. The plug-in wraps WFC into a layer of abstraction, which makes WFC easily implemented in architectural or industrial design. It honors the principles of WFC and Grasshopper at the same time - offering a full control of the input and output data in a Grasshopper way and their processing with a pure WFC.
Before we delve deeper, let's shortly explain the WFC algorithm itself. Note that Monoceros extends some concepts over the vanilla WFC, but it is very helpful to understand the original version of the algorithm first. To that end, it might also be helpful to watch the excellent explanatory talk by Oskar Stålberg at EPC2018.
Wave Function Collapse (WFC) is a procedural generation algorithm that essentially attempts to satisfy constraints on a world (see CSP for more). Its name is inspired by quantum mechanics, but the similarity is just at the surface level - WFC runs completely deterministically.
In its simplest form the algorithm works on an orthogonal grid. We initially have:
A world defined by a mathematical graph, in our case represented as an orthogonal 3D grid.
A set of Rules describing what can occupy each tile on the grid depending on what its neighbors are.
The grid tiles are graph nodes, also called Slots in WFC (and in Monoceros). Graph edges are implicitly derived from Slot adjacency: two Slots are connected by an edge, if they are adjacent to each other on the grid. Every Slot contains a list of Modules that are allowed to reside in it. Conceptually, Modules could have any meaning that we assign to them, some usual meanings being that the Slots populated by them contain geometry, images, navigation meshes, or other high-level descriptions of a space.
The algorithm is defined as follows:
Initialize the world to a fully non-deterministic state, where every Slot allows every defined Module.
Repeat following steps until every Slot allows exactly one Module (a valid, deterministic result), or any Slot allows zero Modules (a contradiction):
Observation (Slot choice): Pick a Slot at random from the set of Slots with the smallest Module count that are still in non-deterministic state (allow more than one Module),
Observation (Module choice): Randomly pick a Module from the set of still available Modules for the chosen Slot and remove all other Modules from this Slot, making it deterministic (allowing exactly one Module),
Constraint Propagation: Remove Modules from neighboring Slots based on the Rules. Repeat recursively in depth-first order for each Slot modified this way.
If WFC generated a contradictory result, start over again with a different random state.
WFC does not necessarily always find a solution. If (and how quickly) a valid solution is computed very much depends on the set of provided Rules. There are sets of Rules for which WFC always converges in just a single attempt regardless of the random state, but also sets of Rules for which the simulation always results in a contradictory world state, and also everything in between. Rule design is a challenging part of working with Wave Function Collapse.
This repository contains the Grasshopper wrapper for the main WFC solver and comprehensive supplemental tools.
The solver itself is written in Rust and compiled as a .dll
library linked to
this wrapper. The source code of the solver and a simple wrapper component for
Grasshopper lives in a separate repository.
The Monoceros Grasshopper plug-in is written in C## and revolves around three main data types:
The Monoceros plug-in offers various Grasshopper components (functions) for constructing and parsing the data, the solver itself and postprocessing and rendering tools.
The core of Monoceros is a Wave Function Collapse (WFC) solver. WFC is an algorithm that fills the entire discrete envelope with Modules with no remaining empty Slot. In case of Monoceros, the envelope is a collection of rectangular cuboid Slots, each with 6 neighbors in orthogonal directions, not taking diagonal neighbors into account. In the original WFC algorithm, the Modules are exactly the size of a single Slot. WFC then picks which Module should be placed into which Slot, leaving no Slot non-deterministic (with more than one Module allowed to be placed into the Slot) or empty / contradictory (no Module allowed to be placed into the Slot). Usually, there are less Modules (Module types) than Slots, which means each Module can be placed into Slots more times or not at all.
The Monoceros implementation of WFC internally works like this too, on the outside it presents the Modules as a continuous coherent compact collection of such cuboid cages (Module Parts), each fitting into one Slot.
Like Grasshopper itself, also Monoceros revolves around data and serves for its immutable processing. Immutability means, that no existing data is being changed but rather transformed and returned as a new instance of the data. In most cases it is even possible to construct the data with valid values right away with no need to re-define already existing data.
There are three main data types: Slots, Modules and Rules.
Slot and Rule both reference to Module, its Part or its Connector. This reference is done only through user defined strings (for Modules and their Parts) or integer indices (for Module Connectors). This is an intention, so that the data sets (Modules, Rules or Slots) can be replaced or shared across more Monoceros setups.
| Construct | Solve | Post process | ||
|---|---|---|---|---|
| Modules | -> | |||
| Rules | -> | WFC Solver | -> | Materialize |
| Slots | -> | |||
| Aggregate | ||||
| Preview |
Most of the Monoceros plug-in components serve for constructing, analyzing and processing data. The components try not to bring redundancy, therefore it does not do anything, that could be easily done with vanilla Grasshopper components. The three new Monoceros data types are seamlessly integrated into Grasshopper and cast from and to all relevant existing data types. All Monoceros components are compatible with the existing Grasshopper data types and ready to be used with existing Grasshopper components.
Slot is a cuboid (orthogonal box) that represents the basic unit of the Monoceros rigid discrete grid. The Slots do not overlap and their position coordinates are defined in discrete numerical steps. The Slots are stacked next to each other, preferably forming a coherent continuous blob or more separate blobs that should become filled with Modules. Such blob will be called an Envelope.
Slot is a container that allows placement of certain Modules or their Parts. The Slot can be in several states:
The collection of Slots forming an Envelope is considered Canonical if the adjacent Slots allow placement of such Modules or their Parts, that are allowed to be neighbors by the Rules. Canonical Envelope does not have to be also deterministic. For non-deterministic Slots to form a Canonical Envelope, each allowed Module or its Part in one Slot must be allowed to be a neighbor of each allowed Module or its Part in its adjacent Slot in the given direction by the Rule set.
The Monoceros implementation of the WFC algorithm can automatically clean a Non-Canonical Envelope into Canonical, which takes a lot of responsibility from the user and enables future development of Monoceros features.
The WFC algorithm (the original one and the Monoceros implementation) work with a full regular three-dimensional box-like Envelope. Monoceros allows the user to define any set of Slots (as long as they are compatible and non-repetitive), which form any arbitrary blob.
Therefore the Monoceros WFC Solver component automatically wraps the user-defined Slots into a slightly larger bounding box and adds the missing Slots. These Slots are dubbed Out-enabled and are pre-determined to allow only one type of a Module to be placed inside them: the Out Module. Out Module is automatically generated by the Monoceros WFC Solver, it has the same diagonal as the Envelope Slots, has just a single Part and contains no geometry. The Out Module has all connectors defined as Indifferent, therefore it is allowed to be adjacent to itself and with any other Module Indifferent in the respective direction. The Out Module and an Empty Module are distinguished so that it is possible to set a Rule for a Module Connector to be adjacent to Out Module (while not being Indifferent), which allows the Module to be placed at the boundary of the Envelope.
All boundary Slots are ensured to be surrounded by Out-enabled Slots. The Out-enabled Slots are not being displayed in the Rhinoceros viewport.
The Monoceros Modules may consist of more Parts. Each Part is of the size of a single Slot, therefore a larger Module occupies more Slots. For valid Modules it is ensured that the Module Parts always hold together and all of the Module Parts are always placed into Slots in the original order. Internally, the Slots refer to Module Parts, for the user of Monoceros Grasshopper plug-in are the Module Parts inaccessible and the Module appears as the smallest unbreakable unit. Therefore it is only possible to define entire Modules to be allowed by a Slot, even when such Module consists of more Parts. Internally this means, that all Parts of the Module are allowed to be placed into a Slot. In practice this should not cause any problems or imprecisions. It is being automatically handled by the WFC Solver and offers some buffer zone for complex Module placement.
A Slot renders in the viewport as a wire frame box. The box is slightly smaller than the actual Slot, so that it is possible to distinguish colors of two adjacent Slots from one another.
A Slot bakes as a regular Rhino box, with dimensions matching the Slot size.
A Slot renders and bakes in different colors, indicating the level of Slot's entropy:
The Casts are meant to shorten the de-construction and re-construction of a Slot. With the following casts it is possible to use one instance of a Slot to construct a new one with the same properties by passing the Slot into individual input Slots of a Slot constructor component.
Slot allows placement of XY Modules. Slot dimensions are XYZ, center is at XYZ, Base Plane is XYZ X Y.
Module is a unit, which is being distributed over the specified Envelope. The main purpose of the WFC and Monoceros is to decide, which Module or its Part can be placed into which Slot, so that the adjacencies of Modules follows the specified Rule set. If this requirement is met, it means the Envelope is Canonical. If there is exactly one Module or its Part allowed to be placed into every Slot, the Envelope is Deterministic and solved.
offers a possibility for Modules to span over (occupy) more Slots. In such case, In the original WFC algorithm, the Module occupies exactly one Slot. Monoceros the Module consists of more Parts, each of a size of a single Slot. If the Module is compact (continuous, consistent) then the Parts always hold together (this is secured by the Monoceros WFC Solver). The Module Parts are not accessible individually, the Module is rather presented as a single element.
A Module can consist of a single Part or more Parts. The Parts that are entirely surrounded by other Parts in all 6 orthogonal directions, are not being presented to the user at all. Only the boundary walls of Module Parts are visible and form an orthogonal discrete unit cage of a Module.
The Module cages are subdivided to match the size of Envelope Slots in their
respective directions. The outer walls of a Module cage are considered to be
Connectors. Connectors are numbered from 0
to n-1
, where n
stands for the
number of (outer) Connectors of the respective Module.
The Monoceros Modules are designed to connect to each other through their Connectors. To enable such connection it must be described by a Monoceros Rule. A Connector can occur in multiple Rules, allowing it to connect to multiple counter-Connectors, out of which one will be chosen by the WFC Solver. Each Connector must occur in at least one Monoceros Rule, otherwise the Connector cannot have any neighbor, therefore such Module cannot be placed into the Solution.
Monoceros Rules may allow connection of Connectors from the same Module or from two distinct Modules. A Rule, therefore also a connection, is only valid when the two Connectors are in opposite orientation of the same axis (i.e. negative Y can connect only to positive Y).
Monoceros Rules are referring to Module names and Connector Indices. The supplemental Monoceros components for constructing Rules use visual representation of Connectors (rectangles or dots) to identify the Rule being created.
The purpose of a Monoceros Module is to place geometry into dedicated Slots. The Module data type is not bound to its geometry, which means the shape, size and location of Module geometry has no relation to the Parts of the Module or Slots it may occupy. This is an intentional feature because in real-life architectural and design applications, the Modules will need to posses extending parts (physical connectors) that would not fit the cages of Module Parts and therefore would compromise the WFC solution.
Therefore, the Module Geometry may be small, larger, different than the Module cage or remain completely empty.
Therefore a Module is being constructed from different input data than its Geometry. To mark Module Parts (Slots the Module may occupy) the user specifies Points inside these Parts. For convenience, it is possible to use Slicer helper component, that analyzes input geometry (no matter whether it is the same geometry that is being held by the Module or a different one) and returns exact centers of Slots that may be occupied by Module Parts.
A Module has a fixed orientation. When it is being placed into Slots it is only being translated (moved) and never rotated. There are maximum of 24 different discreet 90 degree rotations of an object. Rotating all Modules automatically would take a lot of control from the user. Therefore, if any rotation is desired, it has to be done manually by creating a new, different rotated version of the Module. The best way to do this it to rotate and adjust all input data (Module Part Points, Module Geometry) and give it a different name.
There are two reserved Module names in Monoceros: Out and Empty. It is not allowed to manually construct a Module with such name, because they are being constructed automatically.
The Out Module is present in each solution. It is a Module with a single Part, exactly the size of a single Slot and holds no Geometry. It is automatically placed into Slots outside the user-defined Envelope. All Out Module Connectors are marked with Indifferent Rules, so any Module with an Indifferent Rule marked Connectors can be placed next to it - in other words, it enables the Indifferent Modules to be on the boundary of the Envelope. The Out Module does not render in preview, nor bakes.
The Empty Module with a single Part, exactly the size of a single Slot, no Geometry and all Connectors marked with Indifferent Rules has to be constructed manually with a dedicated Monoceros component. It behaves as any other Module because it is a regular Module that can be constructed also without the special Monoceros component. It render in viewport, it can be baked, so that individual Rules can be assigned to it. The Empty Module helps complex Monoceros setups to find a solution, because it fills the gaps between complex Modules and their Parts.
Module preview renders in Rhinoceros viewport with many helper items:
The helper geometry preview does not follow the Grasshopper convention of a transparent green material for selected items and red for unselected.
The purpose of Module baking is to provide helper geometry and anchors for defining Monoceros Rules. It is possible to snap to Connectors or Cages to define a Rule graphically.
Module casts help using the Module directly as an input to various components, even when they require a Module name, i.e. Rule or Slot Constructors.
Module "XY" has XY connectors and has XY parts with dimensions XYZ.
and
either The Module is compact.
or
WARNING: The Module is not compact, contains islands and therefore will not hold together.
Monoceros Rule is a distinct data type describing an allowed adjacency of two Modules by aligning their Connectors facing opposite direction. The Monoceros WFC Solver parses the Slots so that they only allow placement of Modules or their Parts that can become adjacent neighbors according to the Rule set.
Internally, the WFC Solver only works with Explicit Rules, but for convenience Monoceros offers also a Typed Rule. A Typed Rule is automatically unwrapped into one or more Explicit Rules by the WFC Solver and other supplemental components. Both types of Rules manifest as a single data type, can be processed together.
The Rule refers to Modules via their string (text) names and to Connectors via their integer indices. This allows the same Rule set to be used with a different (yet fully compatible) set of Modules.
A single Module Connector can be referred to by multiple Rules but at least one referring Rule is required.
In some cases the Modules cannot connect even though a Rule allows it because their Parts collide. Monoceros does not for check such cases because the WFC Solver itself prevents such situations from happening. That means that even though a Rule is valid, it may never occur in the solution.
Explicit Rule is closest to the original WFC Rule. It refers to a Connector of
one Module that can connector to a Connector of another Module. Its textual
representation follows a pattern module:connector -> module:connector
, i.e.
pipe:1 -> bulb:4
, which translates to: Module "pipe" can become a neighbor of
Module "bulb" if their connectors 1 and 4 touch.
An Explicit Rule should only allow connection of two non-opposing Connectors, which makes the Rule invalid. Because Connector indices do not indicate their direction, it is only possible to check this when the respective Modules are provided. Therefore a full validity check is performed only when both data is available, most importantly in the Monoceros WFC Solver. When the Explicit Rule is created, it is only checked whether it refers to two different Connectors.
Explicit Rule is bi-directional, therefore a:1 -> b:4
equals b:4 -> a:1
.
An Explicit Rule can be cast from a text (string) that has format identical to
the user-friendly Explicit Rule text report:
module:connector -> module:connector
. An Explicit Rule does not casts to any
other data type.
An Explicit Rule cannot be displayed on its own. Following a precedent of Vector display component in Grasshopper, there is a Rule Preview component in Monoceros. When provided with all Modules, it displays an Explicit Rule as a line between the connectors described by the Rule. The color of the line indicates the direction of the connectors (and therefore also of the Rule): red means the connectors are facing X direction, green represents Y direction and blue indicates Z direction.
An Explicit Rule preview can be baked.
Typed Rule is a convenience data type introduced by Monoceros. It assigns a
"connection type" to a Connector of one Module, which then can connect to any
opposite Connector of any Module with the same "connection type" assigned by
another Typed Rule. Its textual representation follows a pattern
module:connector = type
, i.e. player:1 = jack
, which translates to ` Module
"player" can become a neighbor of any Module if its connector 1 touches the
other Module's opposing connector if both connectors are assigned type "jack".
A Typed Rule needs to be unwrapped into one or more Explicit Rules before entering the WFC Solver. This is done automatically by the Monoceros WFC Solver component and by supplemental components such as Unwrap Typed Rules or Collect Rules. For Typed Rule unwrapping it is necessary to provide all Modules so that only opposing Connectors of the same type can unwrap into valid Explicit Rules. Even non-opposing Connectors can be assigned the same type. In such case, only valid (opposing) couples will be unwrapped into Explicit Rules.
As the Typed Rule is in fact a half-rule, it is always valid as long as it refers to an existing Module and its Connector.
A Typed Rule can be cast from a text (string) that has format identical to the
user-friendly Typed Rule text report: module:connector = type
. A Typed Rule
does not casts to any other data type.
A Typed Rule cannot be displayed on its own. Following a precedent of Vector display component in Grasshopper, there is a Rule Preview component in Monoceros. When provided with all Modules, it displays a Typed Rule as a line between all couples of opposing Connectors assigned the connection Type. The color of the line indicates the direction of the connectors (and therefore also of the Rule): red means the connectors are facing X direction, green represents Y direction and blue indicates Z direction. In 1/3 (to prevent collision because in real-life use cases lines cross in their middle) of the line there is a dot with a text label indicating the connection Type.
A Typed Rule preview can be baked.
For convenience, Monoceros introduces a built-in Rule type: indifferent
. When
a Connector is marked Indifferent, it can connect to any other Indifferent
connector of any Module. The purpose of such Typed Rule is to indicate, that the
user does not care about specific adjacency of the given Connector and at the
same time to satisfy the WFC requirement, to describe each Connector with at
least one Rule.
Even the indifferent Rules need to be constructed manually using the Construct Typed Rule or simpler Indifferent Rule From Point. In the usual use case, the Indifferent Rule is assigned to those Connectors, that have not been described by any other intentional Rule. For such cases, there is a shorthand constructor component Indifferent Rules For Unused Connectors.
Just like any other Rule, Typed or Explicit, also the Indifferent Rule can be assigned to a Connector that already is described by another Rule. It can also be used as a disallowed Rule with the Collect Rules component.
Over the course of multiple iterations (called observations) occurring internally inside the WFC Solver, Wave Function Collapse gradually changes the state of Slots from non-deterministic (allowing multiple Modules) to deterministic (allowing exactly one Module). This iterative process happens in the Solver component, where the Slots are observed based on pseudo-random numbers until either every Slot ends up in a deterministic state (success), or any Slot ends up in a contradictory state (failure). If the result is contradictory, the Solver component internally re-tries up to a predefined number of attempts, each attempt using the already modified random state and thus producing a different result each try.
As mentioned earlier, Monoceros builds on top of the original Wave Function Collapse to make it more useful for architecture and industrial design. The essence of the Monoceros extension is how it treats Modules. In original Wave Function Collapse a Module always has the dimensions to occupy exactly one Slot. While Monoceros Modules are aligned to the same discrete grid, they can span multiple Slots and be of any voxel-based shape as long as their Parts connect in a continuous fashion - i.e. they touch with faces and not just edges. A Monoceros Module Part (not available as public data type) is equivalent to a vanilla WFC Module.
Because it is not immediately clear how to implement a solver for Modules as defined by Monoceros, Monoceros utilizes a technique called lowering (sometimes also called desugaring) to change their representation into lower-level, vanilla WFC Modules and also produce metadata necessary to reconstruct the Monoceros Modules from the vanilla Modules.
Even though not visible to the user, Module Parts are carefully tracked throughout the plug-in, and since Rules effectively work with Module Parts already, the Grasshopper Solver lowers the Module and Rule definitions into their low-level forms and feeds those into the Rust solver over the C API. After the Rust solver finishes successfully, Monoceros Modules are reconstructed from its output thanks to the backwards mapping metadata generated by lowering.
Because Monoceros allows us to modify and customize the initial state of the world and vanilla WFC has an opinion on how valid world state looks like, the Rust solver needs to detect whether the world is Canonical (valid in terms of vanilla WFC).
A world is Canonical if:
Every Slot allows every Module (this is the initial WFC world state),
The world is a result of applying both the observation and subsequent constraint propagation phases on an already Canonical world.
For example, running an observation without subsequently propagating does not produce a Canonical world and WFC does not define how this world should behave if observed or propagated any further.
Setting the state of the world manually rarely produces a Canonical world. Therefore the Rust solver always Canonicalizes the world before running an observe/propagate operation. Canonicalization is implemented by starting the constraint propagation phase on every Slot as though it was just observed. This process can in theory be expensive, but fortunately needs to run just once per invocation of the Solver component. The Rust solver provides the information whether the world needed canonicalizing as part of its output.
Explicit Rules describe a one-to-one connection between two Module Connectors. The Connectors may come from a single or from more Modules.
An Explicit Rule is valid when the two Connectors are opposite in the same axis (i.e. positive X connects to negative X). The validity check is only performed in components that require both, Modules and Rules as an input. Invalid Rules are being omitted.
An Explicit Rule can be constructed as a literal (from Grasshopper text Panel), from its components (source and target Module and Connector Index) using Construct Explicit Rule component, from a Curve connecting source and target Connector using Explicit Rule from Curve component or with Rule at boundary from Point component, that creates an Explicit Rule connecting the Module Connector with an implicit Out Module residing outside the Envelope.
Note: It is possible to use Module type data as Module Name.
Monoceros WFC Solver, Unwrap Typed Rules and Collect Rules generate Explicit Rules for all opposing Module Connectors marked with the same connection Type in the set of Typed Rules.
A Typed Rule is valid if it refers to an existing Module and its Connectors. The validity check is only performed in components that require both, Modules and Rules as an input. Invalid Rules are being omitted.
Typed Rules can be constructed from a literal (Grasshopper text Panel), from its components (name, Connector Index, connection Type) using Construct Typed Rule, from a Point tag (point inside the geometry of a Connector) using Typed Rule from Point or with shortcut components Indifferent Rule from Point and Indifferent Rule for unused Connectors. The second output of the Construct Empty Module component is also a list of Typed (Indifferent) Rules.
Note: It is possible to use Module type data as Module Name.
Indifferent Rules are ordinary Typed Rules with a predefined Type indifferent
.
It is a reserved Type because the Out and
Empty Modules have all connectors
automatically described with Indifferent Typed Rules (in case of Empty Module,
the Rules need to be added manually to the Rule set). Any Connector described
with the Indifferent Rule can connect to any opposite Connector described by an
Indifferent Rule. This is mostly used for those Connectors that represent
geometrical back or side (do not have a physical connector) of a Module and the
user does not have any specific intention with them. Indifferent Connectors can
be placed on the boundary of the
Envelopebecause the Out Module has all 6
Connectors described as Indifferent.
The Monoceros WFC Solver requires each Module Connector to be described by at least one Rule and the Indifferent Rule is a good option for those Connectors that do not have any other purpose.
A connector can be described as indifferent even if it is described by another Explicit or Typed Rule. In most cases, only the unused Connectors are being described as Indifferent. There are several ways of constructing Indifferent Rules for unused Connectors.
For the Monoceros WFC Solver component you need to Collect or simply Merge all Rules - the manually assigned ones with the generated Indifferent and Rules coming along with the Empty Module.
If the Module geometry does not naturally fit into cubic grid, it is possible to define a non-uniform grid for Module Parts as well as for the Slots. The dimensions of Part and Slot are defined as a Vector representing a diagonal of the basic grid unit. The axial dimensions of the Vector are aligned with the Module's or Slot's Base Plane.
The Diagonal also defines the discrete step of the world, in which the Modules and Slots reside. Therefore components Construct Module, Construct Slot with all Modules allowed, Construct Slot with listed Modules allowed and Slice Geometry consider the defined Base Plane as the world origin and orientation and the Diagonal as the basic unit, into which they should slice the WFC data.
All Modules and Slots used in one solution must have identical Diagonal dimensions!
A Base Plane defines element's (Module or Slot) coordinate system origin and orientation. All their coordinates and directions will be measured from the Base Plane.
During Materialization of the solution, the Module Geometry will be oriented from the Module Parts' Pivots (planes in the center of Module Parts aligned to the Module's Base Plane) to the respective Slot's Pivot (plane in the center of the Slot aligned to the common Base Plane of all Slots).
Even though in Monoceros it is possible to set individual Base Planes for each element, all Slots entering the Monoceros WFC Solver must share an identical Base Plane. The Modules can have individual Base Planes that do not need to be identical across the solution.
The Monoceros WFC Solver only works with allowed Rules, however sometimes it may be useful to disallow certain connection. This is especially useful when Typed or Indifferent Rules are being used. Such rules unwrap into one or more Explicit Rules, out of which some may be unwanted. In such case it is possible to remove the unwanted Rules from the rule set using the Collect Rules component and effectively disallowing them. If a Rule is not present in the collection of allowed Rules, it is not necessary to manually disallow it.
To disallow a Rule, it first needs to be created. Only then it is decided, whether the Rule will be allowed or disallowed:
Both, Explicit and Typed Rules can be disallowed. The Collect Rules component can be used repeatedly but in most cases it is enough to use it right before passing the Rules into the Monoceros WFC Solver because at hat time the list of all allowed Rules should be already complete.
The output of the Collect Rules component completely replaces any previous Rule set and should not be merged with any previous lists of Rules.
The Monoceros WFC Solver requires all Module Connectors to be described by at least one Rule. Disallowing Rules may result in removing all Rules for certain Connectors, which makes the solution impossible. In such case the Monoceros WFC Solver throws an error.
Note: The Collect Rules component automatically unwraps Typed Rules and adds Rules for Out Modules.
| Allowed Rules | Disallowed Rules | Resulting Rules |
|---|---|---|
A Module can consist of more Parts which always hold together in Materialized result of the Monoceros WFC Solver. Each Part should occupy one Slot of the world Envelope. The Construct Module component requires a list of Module Part Points inside the created Module Parts.
Potential Module Parts are boxes of a size specified as Diagonal filling the entire world, starting with a Part which has its center at the world origin defined by the Module's Base Plane, aligned to match the Base Plane orientation. Those potential Parts, which contain one or more Module Part Points will become Parts of the created Module. It means, that even more Points may mark a single Module Part and therefore the Points do not have to be deduplicated.
The Module Parts and therefore also the Module Part Points do not need to match the Module Geometry. In many cases the Module Geometry extends, occupies only some Module Parts or does not exist at all.
Module Part Points can be created manually, come from manually populated input geometry or from Slice Geometry component. It is recommended to create the Module Part Points manually whenever possible because it is the conscious way, whereas the Slice Geometry component is a brute force approach with many limitations and potentially inconsistent results.
It is recommended to keep the number of Module Parts meaningfully low. Too many Parts result in slow performance of the Monoceros WFC Solver and lower probability of finding a valid solution. The current version of the Monoceros WFC Solver also only supports solutions with maximum of 256 Parts from all Modules together. If this number is exceeded with a single Module, the Module is marked Invalid an the user gets notified by the Constructor and by all components and floating parameters receiving the invalid Module. If this number is exceeded only when all Modules are passed into the Monoceros WFC Solver, the user gets notified by the Solver component.
If the Modules consist of more Module Parts it is often possible that the Modules cannot be stacked together without leaving blank Slots, which is considered a contradictory and therefore invalid result.
Monoceros therefore introduces a convenient
Empty Module
constructor. It is a shortcut for creating a
Module named empty
with a single Part, with no
Geometry and all Connectors described
as Indifferent. Since the name empty
of the
default Empty Module cannot be changed, only one Empty Module can be used for a
solution.
Note: An Empty Module with a different name can be also constructed manually, which in some cases may be useful, when more types of empty Modules are required.
The Rules generated by the Empty Module constructor component need to be added to the Rule set.
An Empty Module does have a geometrical representation and does appear in the Rhinoceros viewport just like any other Module. Its helper geometry (cage and Connector anchor points) can be baked and used to define additional Rules involving the Empty Module, i.e. an Explicit Rule allowing adjacency of the Empty Module to a specific (non-indifferent) Connector or a Typed Rule.
Note: It is recommended to construct the Empty Module with a Base Plane shifted away from the world XY origin because in most cases there already is a custom module at {0,0,0} coordinate. If the Module inputs overlap, the Rules from Points or Curves may be mixed.
It is convenient to try to generate Explicit Rules from Curve from the desired Connectors to all six Connectors of the Empty Module. The Explicit Rule from Curve component, the Monoceros WFC Solver or other components will remove the invalid Rules that connect non-opposite Connectors and only keep the valid ones.
Note: This strategy can be applied onto any collection of Modules, not only onto the Empty Module.
If the Empty Module should be larger than a single Part, it is convenient to generate custom Modules with no geometry with the required properties and allow them to be adjacent to the Modules that require more Empty space next to them.
Note: The Empty Module is often a way to make the setup valid. Replacing it with a custom empty module with multiple Parts may make the setup unsolvable.
The Envelope Slots are
automatically wrapped into a layer of Slots
containing exclusively an out
Module. It is being generated
implicitly automatically in the
Monoceros WFC Solver component and in
Unwrap Typed Rules and
Collect Rules components. The Out Module has one Part and
automatically comes with all 6 connectors described as
Indifferent.
This way the Out Module can be adjacent to itself and to all Indifferent Connectors. That means that all Modules with Indifferent Connectors can be at the boundary of the Envelope because their Indifferent Connectors can be adjacent to the Out Module, which is certainly placed outside of the Envelope.
Some sets of Modules and Rule sets, however, require additional way of allowing some Modules to be at the boundary of the Envelope. THis typically happens when the Modules create an open linear (i.e. pipes) or a branching (i.e. growing tree) structure. Ins such case a Module that can appear in the middle of an assembly, should be also able to appear at its beginning and end - at the boundary of the Envelope. Such Module's Connector should not be described as Indifferent because then it could appear next to any other Indifferent Connector, which would break the structure of the aggregate. For such cases there is Rule at boundary from Point component, which creates an Explicit Rule, allowing adjacency of a Connector tagged with the input Point and an opposite Out Module's Connector. This is the most convenient way of creating such Rule because there is no need to specify the correct opposite Connector of the Out Module.
Note: The Out Module module does not have any geometrical representation in the Rhinoceros viewport and therefore it is impossible to create an Explicit Rule from Curve with it.
It is also possible to disallow certain Indifferent Module Connectors from appearing at the boundary of the Envelope by generating respective rules with the Rule at boundary from Point component and disallow them using the Collect Rules component.
Monoceros Slots are cuboid (box-like) chunks of space, delimiting a single basic discrete gid unit, which can contain certain Module Part. A flat list of Slots forms an Envelope. The Envelope can have any shape, be full or hollow, one, two or three-dimensional, form a single or multiple blobs.
Each individual Slot is created by defining (any) point inside the respective chunk of space delimited by the potential Slot. Each input point generates one Slot, therefore duplicate input points create duplicate Slots.
Slot input points can be constructed either manually, manually from geometry, using the Slice Geometry component or employing a combination of these methods. It is recommended to generate the input points manually or manually from geometry whenever possible because it offers better control. The Slice Geometry component is a brute force approach with many limitations and potentially inconsistent and imprecise results.
All described slicing methods apply also to constructing the Modules.
The fastest way to deduplicate manually generated points is to use the Slice Geometry component.
Monoceros Slots are constructed via components Construct Slot with all Modules allowed or Construct Slot with listed Modules allowed per single Slot. That means each input point generates one Slot even if a Slot at that discrete grid position already exists. That will not only result in too many Slots but also cause an error of the Monoceros WFC Solver. To prevent that, the input points need to be properly deduplicated, so that each Slot is marked by a single point, located unambiguously inside the Slot.
This can be done manually, but more conveniently it is possible to use the Slice Geometry component to process the input collection of points into a list of distinct Slot centers.
| Fill method 0: wrap geometry surface. Output Slots count = 2187. | Fill method 1: fill geometry volume. Output Slots count = 2010. | Fill method 2: wrap surface and fill volume. Output Slots count = 4165. | Fill method 3: wrap geometry surface (experimental). Output Slots count = 1784. |
|---|---|---|---|
Slots are distinct discrete cuboid chunks of space, that allow placement of certain ]Module or their Parts into the respective portion of space.
In the initial state of the solution, the Slots can either allow placement of any Module or its Part or a specified list of Modules. The latter is especially useful if certain areas of the Envelope should or should not contain certain Modules. The list of allowed Modules needs to be specified manually for each Slot, but this can be effectively achieved with the existing Grasshopper tools.
| Complete setup | Slots allowing placement of all Modules, including the "selected" Modules | Slots allowing placement of Modules without the "selected" Modules |
|---|---|---|
| Complete setup | Slots allowing placement of all Modules, including the "selected" Modules | Slots allowing placement of Modules without the "selected" Modules |
|---|---|---|
The Slots do not allow weighted probability of placing certain Modules but the weight can be simulated and distributed discretely. That means, allowing placement of a certain Module will be allowed in Slots more or less often in Slots of certain area. For each individual Slots there will have to be a decision to be made, whether it should or should not allow placement of a Module based on the probability factor.
Technically, this can be achieved by a roulette method: a random item will be chosen from a list of possibilities but the items will be multiplied in the list based on their probability.
For example, the algorithm should choose from two options a
and b
, with
probability 3:2
in favour of option a
, the list of options will contain
items a, a, a, b, b
, out of which one random option will be chosen.
For more items, the probability can defined as a number from range 0.0 to 1.0
with probabilities a=0.3
, b=0.1
, c=0.8
, then the list of items will
contain a, a, a, b, c, c, c, c, c, c, c, c
, out of which one random item will
be chosen.
It the random weighted selection expects results with more items, it is possible
to use the same strategy. The
previous example
could describe a Slot, that can contain 3
Modules, witch probabilities
a=0.3
, b=0.1
, c=0.8
. The list of items will be extended to
a, a, a, b, c, c, c, c, c, c, c, c
and randomly reduced back to 3
options.
Such result will most probably contain c, c, c
, which then will be
deduplicated to c
or a, c, c
deduplicated to a, c
. This way it is possible
to keep only the most probable modules in a Slot.
Employing the roulette approach, it is possible to use gradient values calculated from vertical position to a probability of Module placement.
| Slots allowing placement of "module-1" | Slots allowing placement of "module-2" | Slots allowing placement of "module-3" | Slots allowing placement of "module-4" |
|---|---|---|---|
Employing the roulette approach, it is possible to use gradient values calculated from distance of an attractor to a probability of Module placement.
Example based on binary roulette Download
| Slots allowing placement of "module-1" | Slots allowing placement of "module-2" | Slots allowing placement of "module-3" | Slots allowing placement of "module-4" | Slots allowing placement of "module-5" |
|---|---|---|---|---|
Example based on multiple weighted options roulette Download
| Slots allowing placement of "module-1" | Slots allowing placement of "module-2" | Slots allowing placement of "module-3" | Slots allowing placement of "module-4" | Slots allowing placement of "module-5" |
|---|---|---|---|---|
In certain cases it is desired to place certain Modules into certain Slots even before running the Monoceros WFC Solver. The solution will then respect the position of such placed Modules and the rest of the solution will follow according to the given Rule set.
In Monoceros it is possible to achieve this by constructing the respective Slots with the list of Allowed Modules containing only the desired Module. If the Module consists of more Parts it is sufficient to construct a single Slot with the list of allowed Modules containing exclusively the desired Module. Monoceros will place one of the Module Parts into the Slot and the rest into the adjacent Slots as long as they are allowed to be place there, too.
Note: Due to the way Monoceros exposes the vanilla Wave Function Collapse algorithm, it is not possible to place a specific Module Part into an exact position. The Monoceros WFC Solver picks any Module Part to be placed into a Slot allowing placement of the Module.
Note: Placing Modules manually may cause longer search for a valid solution or completely eliminate an existence of a valid solution.
Similarly to allowing certain Modules to be placed into certain Slots, it is possible to disallow placement of certain Modules into certain Slots.
Because Monoceros does not recognize disallowing, it is necessary to remove the disallowed Module name from the list of allowed modules for the respective Slots. For newly created Slots the list of allowed Modules should contain only the allowed Module names - the disallowed Module's name should be removed from the list manually prior to constructing the Slot.
Existing Slots can be deconstructed and reconstructed with a reduced list of allowed Modules. The original Slots should be replaced with the reconstructed ones.
If specific Modules are allowed to be placed at the boundary of the Envelope but their placement should be enforced, it is possible to identify Slots at the boundary of the Envelope using the Are Slots Boundary component, deconstructing the boundary Slots and allowing or disallowing the desired Modules from these Slots.
Note: The example shows a 2D setup. Monoceros is inherently 3D and so is the Are Slots Boundary component, therefore the setup is first constructed in 3D (5 horizontal layers of Slots) but only the middle horizontal layer of Slots enters the Solver. The two bottom and top layers consist entirely of boundary Slots.
If more than one boundary layer of Slots should be isolated, the Are Slots Boundary component can be used multiple times, each time on Slots identified as inner (non-boundary).
It is possible to wrap the existing Envelope of Slots into another layer of Slots. The Add Boundary Layer component generates a collection of Slot center points that can be converted into Slots, which will form a single added layer to the existing Envelope.
A correct result of the Monoceros WFC Solver is a collection of deterministic Slots, which allow exactly one Module Part to be placed. This is still not the final stage of the discrete assembly process because the solution is not yet Materialized, which is a process of placing Module Geometry into its respective Slots.
The output of Materialize Slots component is a data
tree with paths { module index, slot index }
, where module index
is the
order of the placed Module in the input list of Modules and slot index
is the
order of the target Slot in the input list of Slots. Each branch then contains
all geometry items of the respective Module.
Note: Due to the way Monoceros treats Module Parts, only the first Part of each Module is placed into its Slot, leaving the remaining Slots containing the Module empty (their index will not even appear in the Materialize Slots component output data tree).
The geometry output of the Materialize Slots component is intended for further use in Grasshopper. Therefore, if the intention is to bake the output of the WFC already in this stage, it is recommended to bake the Materialize Slots component. The result of such bake is a collection of block instances, which are significantly smaller than full-fledged geometry and all blocks of one type can be edited at once.
Note: The viewport rendering of materialized geometry may be slow on some computers. This makes the Materialize Slots component one of the slowest part of a Grasshopper Monoceros definition. To speed it up, it is recommended to disable preview of the Materialize Slots component prior to connecting wires to its inputs.
In some cases the final geometry of a Grasshopper definition does not have to be the one stored in the Monoceros Modules. The Modules can contain some proto-geometry instead and the final geometry is then constructed in Grasshopper after materialization.
A typical case may be structures that are not meant to be discrete, but rather continuous. The Modules should then contain only the skeleton of such structure, which will be joined and wrapped into volumes after the materialization of the WFC assembly.
The usual approach would be to embed the final version of the geometry into the Modules themselves. The materialized geometry is organized in data tree representing the Slot and Module order, rather than any semantic logic. Each element of the result is a separate geometry.
Download example based on the Mondieu example and its Rhino file.
Modules with embedded final version of the geometry
Single element of the result
Instead it is possible to use a proto-geometry and process it after Materialization. In this case, the pipes are represented by their skeleton curves, which can be eventually joined into continuous curves and only then turned into valid continuous pipes.
Download example based on the Mondieu example and its Rhino file.
Modules with proto-version of the geometry
Single element of the result
In very special cases, the geometry does not have to enter the
Modules at all. Instead, the
Monoceros WFC Solver runs on the Rule set
an Modules with no geometry and so does the
Materialize Slots component. Its Transform
output
contains transformation data, that can be used to place any geometry from the
original Module location into all the Slots which should contain the
respective geometry.
This is especially useful if there are various geometry sets that could be used as the Module Geometry. These sets can be interchanged without the need of recalculating the entire Monoceros WFC solution.
Note: The geometry that should be placed using the Transform
output needs to
be located and aligned properly: it should share the same location and Base
Plane orientation with the original Module.
During the Wave Function Collapse calculation, there are several moments when a random decision has to be made: if a Slot allows placement a equally valid Modules, the Monoceros WFC Solver chooses one random Module to be placed. Such situation can occur at several Slots at a time, therefore the Solver chooses a random Slot to process.
Like Grasshopper, also Monoceros uses seeded pseudo-random function. That means that the Monoceros WFC Solver generates the same solution for a constant Rule set and constant Modules and Slots every time and at every computer, as long as the seed is the same and vice versa, different seeds generate different outputs even on the same computer.
The WFC algorithm does not ensure there will always be a solution. Throughout the processing it can happen that the setup may not result in a valid output - some Slots may end up contradictory and allow placement of no Modules whatsoever. Such situation cannot be anticipated rr prevented, therefore it is necessary to make several attempts with different random decisions. The Monoceros WFC Solver component lets the user to define how many unsuccessful attempts should it make until it pronounces the setting unsolvable.
There is no good value for maximum attempts. For simple and well defined setups the Solver usually finds the solution in the first attempt but it is not rare that it takes more than a thousand attempts to find a solution in some cases. The mere fact that it requires more than one attempt shows, that the setup is problematic and may not be solvable at all.
There is no good value for the random seed. Changing the random seed for setups that produce solutions will result in various, yet equally good solutions. The properties and qualities of a solution are not related to the value of the random seed, therefore it makes no sense to compare one seed to another. For solutions that are hard to find it may happen, that for some random seeds the Solver requires less attempts than for others. This is only true until other inputs (Modules, Rules and Slots) remain unchanged.
The Rules can be displayed in Rhinoceros viewport and baked using Rule Preview component. The Rule is shown as a line, connecting two Connectors that are allowed to be adjacent.
The color of the preview line indicates the orientation of the Connectors: red means X, green means Y and blue means Z. If the Rule allowing adjacency is Typed, the line carries also a label with the Type name.
Note: It is not always necessary to display all Rules or Rules for all Modules. The inputs can vary depending on the information that should be displayed.
An Explicit Rule can be displayed also as an assembly of two Modules that are allowed to be adjacent.
Note: A Typed Rule can be converted into a collection of Explicit Rules prior to assembling.
The Module mentioned in the Rule first is considered a source, the second one a target. The source Module's Pivot is aligned to the assembly Base Plane, the target Module is aligned to source Module so that their adjacent Connectors are touching.
Note: The Assemble Rule component does not check the two modules for overlapping but the architecture of the WFC Solver prevents the overlaps in the actual solution.
If more Rules should be assembled at once, it is necessary to define an individual Base Plane for each assembly. The Base Planes need to be manually distributed so that the assemblies do not overlap.
The Wave Function Collapse is a very powerful tool but requires a lot of patience to learn. It is recommended to read the Subdigital WFC Book and understand the principles of WFC and its implementation in Monoceros before trying the first experiments in Grasshopper. It is especially important to understand that WFC is not a growth algorithm and how does it differ from other seemingly similar discrete assembly tools.
When learning Monoceros and building intuitive sensitivity, the following steps are recommended:
It means there is no potential solution for the current setup. It can have several reasons:
Most probably because the Rule set is too specific and the solution is rare. Try making the Envelope significantly smaller without causing a a contradictory world state and increase the number of attempts.
Try changing the random seed, even though it only forces the Monoceros WFC Solver to try different random set of attempts.
If there is no solution even after 5000 attempts and several different random seeds, it is recommended to start over and build up the setup Module by Module.
It is also possible that the setup has no solution at all.
The safest Module has only one Part but such Modules also generate unsurprising and simple outputs. A Module can consist of maximum 256 Parts, but it is recommended to keep the number of Module Parts under 10.
The Module has to be consistent and all its Connectors need to be described by at least one Rule, even if it should be an Indifferent Rule.
To achieve interesting results, the Module's content (in most cases its Geometry) should be semantically heterogenous or in other words, the boundaries of semantical parts should not match the boundaries of Modules. Said simply, the whole should be cut through the middle of a distinct part, rather than along its boundary. If the Modules should represent urban elements, they should not contain individual houses but rather a part of a house, part of a garden, part of a pavement and a bit of a road. If the WFC should compose a world map, good Modules are those that contain a coast line, not those that contain only the sea or the land.
A good Envelope is aware of the size and shape of the Modules that should be placed into it.
If the Modules do not allow it, the Envelope should not have small parts sticking out, forming thin shells otherwise already the inital state of the Envelope may be contradictory.
If the sliced geometry or its part reaches the boundary, edge or vertex of a potential Slot or a Module Part, it means that the part may belong into two (if on surface), four (if on edge) or even eight (if on vertex) neighboring grid cells. It is difficult for the component to decide into which one it should be placed. Any approach would be only approximating and could give wrong results in edge cases.
Therefore the Slice Geometry component completely resigns on any decision making in unambiguous situations. Therefore it is strongly recommended to generate Slot Points and Module Part Points manually whenever possible.
It is not possible. The Monoceros Wave Function Collapse implementation allows to specify only immediate adjacency.
For specific cases of 1D and 2D aggregates it is possible to use the remaining dimension to specify Modules with no Geometry spanning over more Parts / Slots with Rules at Connectors farther apart.
No. These data types are not part of the usual geometrical hierarchy in Grasshopper.
Construct Module and Slice Geometry components support the following geometry types and their derivatives:
The architecture of Monoceros expects a small number of lightweight Modules. In such case it should not be a performance problem to embed the geometry into the Modules. The geometry itself is not being used for any calculations until the Modules reach the Materialize Slots component.
Two things are happening in the Materialize Slots component:
{ module index, slot index}
, where module index
is the order in which the
Modules were passed into the Materialize Slots component and slot index
is
the order in which the Slots were passed into the Materialize Slots component.
Each branch contains a complete list of geometry brought by the respective
Module into its Slot. Note: Only the Slots containing the first
Part of each Module contain the Module Geometry
to prevent duplicate geometry entries for multi-part Modules. Displaying all
materialized geometry in Rhinoceros viewport may be slow, therefore it is
recommenced to disable preview for the Materialize Slots component. The
output geometry may be used for further Grasshopper processing or evaluation..3dm
file.Developed at Subdigital.
Supported using public funding by Slovak Arts Council.
Copyright (c) 2021 Subdigital | Ján Pernecký, Ján Tóth
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


WITNESS LIST
County Affairs Committee
September 18, 2012 - 10:00 AM
Interim Charge #1
For:
Rendl, Alan (North Harris County Regional Water Authority)
On:
Carlton, John (Texas State Association of Fire and Emergency Districts)
Katz, Howard (HCESD 9,7,4,8)
Prestage, Grady (Self; Fort Bend County)
Radack, Steve (Harris County)
Waterworth, Len (Port of Houston Authority)
Wiley, Jeff (Greater Fort Bend Economic Development Council)
Registering, but not testifying:
For:
Gay, Clifford (Self)
On:
Gee, Charles (Texas Logging Council)
Wilson, Don (Texas Commission on Fire Protection)
Interim Charge #3
For:
Buck, David (Healthcare for the Homeless - Houston)
Garcia, Adrian (Harris County Sheriff's Office)
Jiles, Mona Lisa (MHMRA of Harris County)
On:
Parker, Mayor Annise (City of Houston)
Seale, Michael (Harris County Sheriff's Office)
Stephens, Clarissa (Harris County Office of Criminal Justice Coordination)
Wood, Brandon (TX Commission on Jail Standards)
Interim Charge #4
On:
Caldwell, Katy (Legacy Community Health Services)
Hawkins, John (Texas Hospital Assn.)
Janek, Jim (Rice Medical Center, Rice Hospital District, TORCH)
Janek, Kyle (Health and Human Services Commission)
Kirsch, Lisa (Health and Human Services Commission)
Laas, Harvey (Texas Rural Health Association and Fort Bend Family Health Center, Inc.)
Lopez, David (Harris Health System)
Schnee, Steven (MHMRA of Harris Co)
Sports Authority
On:
Friedman, J. Kent (Harris County - Houston Sports Authority)
1
WITNESS LIST
On:
Schmees, Janis (Harris County - Houston Sports Authority)
2


ABSTRACT
Lisoval A.A. Research opportunities of Rotrex supercharger for application in exhaust systems. Visnyk National Transport University. Series «Technical sciences». Scientific and Technical Collection. - Kyiv: National Transport University, 2020. - Issue 1 (46).
The purpose of the article is to describe the design and research of the new Rotrex superchargers of C15 series. In superchargers to ensure high boost pressure and efficiency centrifugal compressor wheel, shockless planetary gear of the original design, a special lubrication-cooling system were used.
The article describes the design features of Rotrex centrifugal superchargers and the results of experimental researches of the C15 series supercharger on a motor less stand.
The design feature of the C15 series superchargers is compactness and high speed - the compressor wheel speed reaches 200 000 rpm. In a planetary gear, cylindrical rollers on ball bearings are used instead of gear satellites. The gear ratio from the shaft of the stand motor to the shaft of the compressor wheel was 43.
Tests of the C15-20 supercharger are performed in static modes. Characteristics of the consumer of boost air were modeled with special washers with minimum diameters of 10,1 ... 14,0 mm. The maximum overpressure of 1.1 ... 1.3 MPa was achieved at a flow rate of 460 ... 250 kg/h, respectively. The tests confirmed the efficiency of the stand for gas-dynamic research of centrifugal compressors, the electronic control system of the electric motor current frequency reliably worked.
Characteristics of the C15-20 supercharger, test results confirmed its purpose for spark-ignition car engines. They can be used in combined boost systems of both gasoline engines and diesel engines.
KEY WORDS: INTERNAL COMBUSTION ENGINE, BOOST, CENTRIFUGAL SUPERCHARGER, BOOST TESTS.
REFERENCES
AUTHOR
Lisoval Anatoliy A., Doctor of Technical Science, Professor, National Transport University, Professor of the Department of engines and heat engineering, e-mail<EMAIL_ADDRESS>tel. +380442804716, Ukraine, 01010, Kyiv, Omeliyanovicha-Pavlenko St. 1, of. 303a, orcid.org/0000-0001- 6168-4010
REVIEWER
Sakhno V.P., Doctor of Technical Science, Professor, National Transport University, Head of the Automobile department, Kyiv, Ukraine.
Mayboroda A.N., Doctor of Technical Science, Professor, State University of Infrastructure and Technology, Head of the Navigation and vessel control department, Kyiv, Ukraine.
Article language: Ukrainian
Open Access: http://publications.ntu.edu.ua/visnyk/46/183.pdf
Print date: 15.04.2020
Online publication date: 27.10.2020


assignment_ind
Membership System
Sign in
Sign up
Sign in
Sign up
menu
Login Membership
person_pin
Username
lock_outline
Password
Sign In


American IS suspect awaits repatriation from Turkey
ANKARA, Turkey (AP) - Turkey’s state-run media says an American man suspected of being an Islamic State group member remains in no man’s land on the border between Turkey and Greece for a fifth day.
Anadolu Agency reported the man was seen Friday between Turkey’s Pazarkule border gate and the Greek frontier at Kastanies. On Thursday, Turkey’s Interior Ministry said repatriation was underway after the U.S. agreed to accept him and provided travel documents.
He has been identified by local media as 39-year-old Muhammad Darwis B., a U.S. citizen of Jordanian origin.
TOP STORIES
Kevin McCarthy accuses Adam Schiff of lying about the whistleblower
'It will go crazy': Finland close to 1st major soccer finals
Franklin Graham calls on nation to pray for Trump as impeachment effort gains speed
The man has been waiting in the heavily militarised border zone since Nov. 11. He initially asked to be sent to Greece from Turkey, but Athens refused to take him in.
Sign up for Daily Newsletters
Copyright © 2019 The Washington Times, LLC.
Please read our comment policy before commenting.


Investigators trying to find the cause of the crash of Ethopian Fight 302, has located the aircraft's flight data recorder.
Ethopian 302, was a scheduled passenger flight from the Ethopian capital, Addis Ababa, to the Kenyan capital, Nairobi. The aircraft crashed six minutes after take-off, near the town of Bishoftu, this resulted in the deaths of all 157 passengers and crew.
Remaining parts of the crashed 737 MAX 8.
The aircraft, a Boeing 737 MAX 8, registered as ET-AVJ, was delievered to Ethopian on the 15th of November, making it around four months old at the time of the incident. Boeing stated in a press release that;
"Boeing is deeply saddened to learn of the passing of the passengers and crew on Ethiopian Airlines Flight 302, a 737 MAX 8 airplane. We extend our heartfelt sympathies to the families and loved ones of the passengers and crew on board and stand ready to support the Ethiopian Airlines team. A Boeing technical team will be travelling to the crash site to provide technical assistance under the direction of the Ethiopia Accident Investigation Bureau and U.S. National Transportation Safety Board."It is known that the pilot of the aircraft has been flying for the airline since 2010 and is a "senior pilot" with more than 8,000 flight hours and an "excellent record," according to Gebre Mariam.
Mutiple governments around the world have prohibited the 737 MAX from flying within their airspace, most noticably the EASA and the CAA.
The FAA has prohibited the Boeing 737 MAX Family from operating within American airspace, this is after President Trump stated that "airliners are becoming too complex" and after vowing to "ban" the aircraft till the issues are fixed.


*** User 2017-05-05 20:40:20.109 ***
20:40:20.109 [info] Disabling blocking sync...
*** User 2017-05-05 20:40:20.113 ***
20:40:20.113 [info] Configured peer_service_manager partisan_default_peer_service_manager on node 'node-1@MacBook-Pro-de-Anne-France'
*** User 2017-05-05 20:40:21.586 ***
20:40:21.586 [info] Enabling membership...
*** User 2017-05-05 20:40:21.587 ***
20:40:21.587 [info] Disabling blocking sync...
*** User 2017-05-05 20:40:21.592 ***
20:40:21.592 [info] Configured peer_service_manager partisan_default_peer_service_manager on node 'node-2@MacBook-Pro-de-Anne-France'
*** User 2017-05-05 20:40:23.077 ***
20:40:23.076 [info] Enabling membership...
*** User 2017-05-05 20:40:23.078 ***
20:40:23.078 [info] Disabling blocking sync...
*** User 2017-05-05 20:40:23.082 ***
20:40:23.082 [info] Configured peer_service_manager partisan_default_peer_service_manager on node 'node-3@MacBook-Pro-de-Anne-France'
*** User 2017-05-05 20:40:23.321 ***
Joining node: 'node-3@MacBook-Pro-de-Anne-France' to 'runner@MacBook-Pro-de-Anne-France' at port 60368
*** User 2017-05-05 20:40:23.321 ***
Joining issued: 'node-3@MacBook-Pro-de-Anne-France' to 'runner@MacBook-Pro-de-Anne-France' at port 60368
*** User 2017-05-05 20:40:23.322 ***
Joining node: 'node-2@MacBook-Pro-de-Anne-France' to 'runner@MacBook-Pro-de-Anne-France' at port 60351
*** User 2017-05-05 20:40:23.322 ***
Joining issued: 'node-2@MacBook-Pro-de-Anne-France' to 'runner@MacBook-Pro-de-Anne-France' at port 60351
*** User 2017-05-05 20:40:23.322 ***
Joining node: 'node-1@MacBook-Pro-de-Anne-France' to 'runner@MacBook-Pro-de-Anne-France' at port 60339
*** User 2017-05-05 20:40:23.324 ***
Joining issued: 'node-1@MacBook-Pro-de-Anne-France' to 'runner@MacBook-Pro-de-Anne-France' at port 60339
*** User 2017-05-05 20:40:23.385 ***
Waiting for join to complete with manager: partisan_default_peer_service_manager
*** User 2017-05-05 20:40:23.386 ***
Finished.
*** CT 2017-05-05 20:40:23.386 *** COVER INFO
Adding nodes to cover test: ['runner@MacBook-Pro-de-Anne-France']
*** CT 2017-05-05 20:40:23.395 *** COVER INFO
Successfully added nodes to cover test: []
*** User 2017-05-05 20:40:23.430 ***
Tokens: [{select,1,select},
{var,1,title},
{',',1},
{var,1,rating},
{from,1,from},
{var,1,classics},
{where,1,where},
{var,1,year},
{comparator,1,'=>'},
{integer,1,1960},
{intersection,1,'and'},
{var,1,year},
{comparator,1,'<='},
{integer,1,1965}]
*** User 2017-05-05 20:40:23.430 ***
Parse Tree: {query,
{select,[title,rating]},
{from,classics},
{where,
{intersection,
{predicate,{var,year},'=>',1960},
{predicate,{var,year},'<=',1965}}}}
*** User 2017-05-05 20:40:23.532 ***
Tokens: [{select,1,select},
{var,1,title},
{from,1,from},
{var,1,filtered},
{where,1,where},
{var,1,rating},
{comparator,1,'=>'},
{integer,1,80}]
*** User 2017-05-05 20:40:23.533 ***
Parse Tree: {query,{select,[title]},
{from,filtered},
{where,{predicate,{var,rating},'=>',80}}}
*** User 2017-05-05 20:40:23.634 ***
Case finished: sql_combined_view_test
*** User 2017-05-05 20:40:30.680 ***
20:40:30.680 [info] Application lasp exited with reason: stopped
*** User 2017-05-05 20:40:30.681 ***
20:40:30.681 [info] Application partisan exited with reason: stopped
=== Ended at 2017-05-05 20:40:30
=== successfully completed test case
=== Returned value: ok
Test run history
| Top level test index


Released March 21, 2011
Additions
jqGrid
Added TreeGrid component
Added new search module. For all features see
Search Options and Events
Added keyboard navigation in the grid and treegrid. This is achieved with the grid method
bindKeys
Added new grid column event -
cellattr - this function can add attributes and properties to a given cell. Ideal for merge cells by condition.
Improve Subgrid speed and options.
Added new grid options
cmTemplate, which allow to overwrite the default options for the columns.
Added new javaScript method - getLocalRow which return the data from the local data array. Usually used with TreeGrid.
In all database drivers is added ErrorMessage method which return the last error.
Added PHP variable
showError. If set to true all error messages are send to the client and shown in modal window.
Added PHP
performcount variable. If set to false does nnot perform a counting query.
Added PHP method
setBeforeCrudAction - now we can define sql commands before we do a CRUD into the main table.
Added new PHP method buildSearch - the method accept as parameter the search string from grid and return the SQL where clause. Also the methos can return array which first element is the string which can be used in prepare statement and the second is the array of values
Added Arabic translation
Added Lithuanian translation
Added isNull operator when searching
Updated Finnish translation
Add new event 'onClickGroup'. This event fires after clicking group (to expand or collapse group).
See grid events.
jqChart
SQL Data now can contain two columns - to set X and Y values
Added
setTheme method - which can be used to change the chart theme dynamically. A url can be used
Fixes
jqGrid
Fix Micrsoft SQL driver to support right queries when a paging is used and the query contain DISTINCT operator
Fix bug determining the type of the returned data from the summary information
Fix custom button now have right id attached
Fix error when strict reporting is set in PHP
Fix echo parameter in editGrid PHP method
Fix get accessor method
Fix for Microsoft date formatter
Fix multiselectwhen all rows are selected with click.
Support of Unix timestamp in date formatter.
Ability to add modal in column chooser
Fix for date formatter
Fox when ShrinkToFit = false
Prevent navigator, navButtonAdd and filterToolbar methods to be executed several times. Usually this happen in jQuery UI modal which append the content and script and script is executed again.
Fix for double quotes and backslach when searching
Fixes in toJson javascript funcion
Fixes for local searching
Fix saveRow javascriopt and formatter of type actions to accept righ errors from the server.
Fix local searching when column names contain dot, semicolon.
Fix position of the modal when the option overlay is set to 0
jqChart
Fix autodetecting column types when SQL command is used to obtain data.
Fix Left to Rigth texts in FireFox
Fix for exporting Pie charts
Fixed issue with charts not displaying in IE on pages with large background images or external resources
Fixed issue Safari Mobile crashing after removing a series dynamically.


| F_2_panel.smoothScatter {lattice} | R Documentation |
This function allows the user to place smoothScatter
plots in
lattice graphics.
panel.smoothScatter(x, y = NULL, nbin = 64, cuts = 255, bandwidth, colramp, nrpoints = 100, transformation = function(x) x^0.25, pch = ".", cex = 1, col="black", range.x, ..., raster = FALSE, subscripts, identifier = "smoothScatter")
x |
Numeric vector containing x-values or n by 2 matrix containing x and y values. |
y |
Numeric vector containing y-values (optional). The length of |
nbin |
Numeric vector of length 1 (for both directions) or 2 (for x and y separately) containing the number of equally spaced grid points for the density estimation. |
cuts |
number of cuts defining the color gradient |
bandwidth |
Numeric vector: the smoothing bandwidth. If missing,
these functions come up with a more or less useful guess. This
parameter then gets passed on to the function
|
colramp |
Function accepting an integer |
nrpoints |
Numeric vector of length 1 giving number of points to
be superimposed on the density image. The first |
transformation |
Function that maps the density scale to the color scale. |
pch, cex |
graphical parameters for the |
range.x |
see |
col |
|
... |
Further arguments that are passed on to
|
raster |
logical; if |
subscripts |
ignored, but necessary for handling of ... in certain situations. Likely to be removed in future. |
identifier |
A character string that is prepended to the names of grobs that are created by this panel function. |
This replicates the display part of the smoothScatter
function by replacing standard graphics calls by grid-compatible ones.
The function is called for its side effects, namely the production of the appropriate plots on a graphics device.
Deepayan Sarkar<EMAIL_ADDRESS>ddf <- as.data.frame(matrix(rnorm(40000), ncol = 4) + 3 * rnorm(10000)) ddf[, c(2,4)] <- (-ddf[, c(2,4)]) xyplot(V1 ~ V2 + V3, ddf, outer = TRUE, panel = panel.smoothScatter, aspect = "iso") splom(ddf, panel = panel.smoothScatter, nbin = 64, raster = TRUE)


To get the number of seconds, we can generate a date using the current day and time 00:00:00, then substract it from “now”.
The difference is the number of milliseconds from the beginning of the day, that we should divide by 1000 to get seconds:
```js run function getSecondsToday() { let now = new Date();
// create an object using the current day/month/year let today = new Date(now.getFullYear(), now.getMonth(), now.getDate());
let diff = now - today; // ms difference return Math.round(diff / 1000); // make seconds }
alert( getSecondsToday() ); ```
An alternative solution would be to get hours/minutes/seconds and convert them to seconds:
```js run function getSecondsToday() { let d = new Date(); return d.getHours() * 3600 + d.getMinutes() * 60 + d.getSeconds(); }
alert( getSecondsToday() ); ```


The children() method returns all direct children of the selected element.
The DOM tree: This method only traverse a single level down the DOM tree. To traverse down multiple levels (to return grandchildren or other descendants), use the find() method.
Tip: To traverse a single level up the DOM tree, or all the way up to the document's root element (to return parents or other ancestors), use the parent() or parents() method.
Note: This method does not return text nodes. To return all children including text nodes, use the contents() method.
$(selector).children(filter)
| Parameter | Description |
|---|---|
| filter | Optional. Specifies a selector expression to narrow down the search for children |
Return elements that are direct children of <ul>:
$(document).ready(function(){
$("ul").children().css({"color": "red", "border": "2px solid red"});
});
Result:
body (great-grandparent)
div (grandparent)
ul (parent)
- li (child)
span (grandchild)


Panels
Discover the Panels features below
Basic
By default, all the .panel
does is apply some basic border and padding to contain some content.
Panel with heading
Easily add a heading container to your panel with .panel-heading
. You may also include any

-

with a .panel-title
class to add a pre-styled heading. However, the font sizes of

-

are overridden by .panel-heading
. For proper link coloring, be sure to place links in headings within .panel-title
.
Panel title
Panel with footer
Wrap buttons or secondary text in .panel-footer
. Note that panel footers do not inherit colors and borders when using contextual variations as they are not meant to be in the foreground.
Contextual alternatives
Like other components, easily make a panel more meaningful to a particular context by adding any of the contextual state classes.
Primary
.panel-primary
class.
Success
.panel-success
class.
Info
.panel-info
class.
Warning
.panel-warning
class.
Danger
.panel-danger
class.
Basic
.panel-default
class.


Shared Science is a website that allows children to improve their scientific knowledge by providing them with information on various scientific subjects. This includes articles, videos, and instructions on how to do their own scientific experiments. Our website will provide kids with a basic understanding of scientific topics. We hope to make science more fun and interesting for kids so that they will be more enthusiastic about learning.


---
layout: page
title: "Activities"
description: "Wherever you go, Whatever you do"
header-img: "img/about-bg.jpg"
---
Michael - Timeline
International Youth Leadership Finance Summit (2019)
The International Youth Leadership Finance Summit (IYLFS 2019) is a global summit held by
Shanghai Avanced Institution of Finance (SAIF).
During the competition days of the 2019 IYLFS, 24 teams with top students from around the world gathered at SAIF and delivered interesting presentations and insightful discussions on AI and Capital Markets. The competition projects range from E-commerce/Consumption, Education, Big Data Application, Smart City/Agriculture, and Healthcare/Pharmaceutical.
Our Team presented an excellent project on brand new building management system -- CREAMS --
as well as some advanced AI implements that could be applied on it.
We were rewarded the Third Prize of the summit project.
1st UBS Global Quantitative Investment competition
The 1st UBS Global Quantitative Investment competition is held by UBS China,
aiming to provide college students an oppotunity to get involved in quantitative trading.
This year, the main topic of the competition is about machine learning strategies in asset management and economic indicatation.
Our Team handed in a comprehensive report on constructing macro-economic indicators through machine learning methods.
We presented two indicators and a trading strategy based on them, which has an annul return of 40% and a sharpe ratio of 1.31.
We were rewarded the Final List (top 14 out of 200+ teams).
My role is to develop, optimize and backtest the trading strategy.
Our team consists of both Chinese students and foreign students of Antai College of Economic and Management.
We are highly diversified but full of cohesion.
We once won a 6:1 against another college of SJTU at group stage, but were knocked out at the quarter final.
Soccer
Guitar Performance on Stages
During my fresh year I played several times on stages for varies occasions.
I play acoustic guitar (rhythm) and sometimes sing along.
The photo captures a moment of me playing the song "Chengdu" on the College Christmas Festival.


Please configure the widget
Passed
Quality Gate
Failed
Quality Gate
Warning
Quality Gate
unknown
Quality Gate
{{vm.coverage||"unknown"}}
Code Coverage
{{vm.blocker||"unknown"}}
Blocker Issues


from collections import defaultdict
import numpy
from ..BaseClass import BaseSpOptHeuristicSolver
from .base import (
w_to_g,
move_ok,
ok_moves,
region_neighbors,
_centroid,
_closest,
_seeds,
is_neighbor,
)
def region_k_means(X, n_clusters, w):
"""Solve the region-K-means problem, the K-means with the constraint
that each cluster forms a spatially connected component.
Parameters
----------
X : {numpy.ndarray, list}
The observations to cluster shaped ``(n_samples, n_features)``.
n_clusters : int
The number of clusters to form.
w : libpysal.weights.W
...
Returns
-------
label : numpy.ndarray
Integer array with shape ``(n_samples,)``, where ``label[i]`` is the
code or index of the centroid the ``i``th observation is closest to.
centroid : numpy.ndarray
Floating point array of centroids in the shape of ``(k, n_features)``
found at the last iteration of ``region_k_means``.
iters : int
The number of iterations for the reassignment phase.
"""
data = X
a_list = w.to_adjlist(remove_symmetric=False)
areas = numpy.arange(w.n).astype(int)
k = n_clusters
seeds = _seeds(areas, k)
# initial assignment phase
label = numpy.array([-1] * w.n).astype(int)
for i, seed in enumerate(seeds):
label[seed] = i
to_assign = areas[label == -1]
c = 0
while to_assign.size > 0:
assignments = defaultdict(list)
for rid in range(k):
region = areas[label == rid]
neighbors = region_neighbors(a_list, region)
neighbors = [j for j in neighbors if j in to_assign]
if neighbors:
d_min = numpy.inf
centroid = data[region].mean(axis=0)
for neighbor in neighbors:
d = ((data[neighbor] - centroid) ** 2).sum()
if d < d_min:
idx = neighbor
d_min = d
assignments[idx].append([rid, d_min])
for key in assignments:
assignment = assignments[key]
if len(assignment) == 1:
r, d = assignment[0]
label[key] = r
else:
d_min = numpy.inf
for match in assignment:
r, d = match
if d < d_min:
idx = r
d_min = d
label[key] = idx
to_assign = areas[label == -1]
# reassignment phase
changed = []
g = w_to_g(w)
iters = 1
# want to loop this until candidates is empty
regions = [areas[label == r].tolist() for r in range(k)]
centroid = _centroid(regions, data)
closest = numpy.array(_closest(data, centroid))
candidates = areas[closest != label]
candidates = ok_moves(candidates, regions, label, closest, g, w, areas)
while candidates:
# make moves
for area in candidates:
label[area] = closest[area]
regions = [areas[label == r].tolist() for r in range(k)]
centroid = _centroid(regions, data)
closest = numpy.array(_closest(data, centroid))
candidates = areas[closest != label]
candidates = ok_moves(candidates, regions, label, closest, g, w, areas)
iters += 1
return centroid, label, iters
[docs]class RegionKMeansHeuristic(BaseSpOptHeuristicSolver):
"""Solve the region-K-means problem, the K-means with the constraint
that each cluster forms a spatially connected component.
Parameters
----------
data : {numpy.ndarray, list}, required
The observations to cluster shaped ``(n_samples, n_features)``.
n_clusters : int
The number of clusters to form.
w : libpysal.weights.W, required
Weights object created from given data.
Attributes
----------
labels_ :
...
centroids_ :
...
iters_ :
...
"""
[docs] def __init__(self, data, n_clusters, w):
self.data = data
self.w = w
self.n_clusters = n_clusters
[docs] def solve(self):
"""Solve the region k-means heuristic."""
centroid, label, iters = region_k_means(self.data, self.n_clusters, self.w)
self.labels_ = label
self.centroids_ = centroid
self.iters_ = iters


To the Editor: Zika virus (ZIKV), a member of the family Flaviviridae, genus Flavivirus, was first isolated from the blood of a sentinel rhesus monkey from the Zika Forest of Uganda in 1948 ( 1 ). Since that time, serologic studies and virus isolations have demonstrated that the virus has a wide geographic distribution, including eastern and western Africa; the Indian subcontinent; Southeast Asia; and most recently, Micronesia ( 2 – 5 ). The virus is transmitted primarily through the bite of infected mosquitoes and most likely is maintained in a zoonotic cycle involving nonhuman primates ( 1 ), although recent evidence suggests the possibility of occasional sexual transmission in humans ( 4 ). Few case reports have described the clinical characteristics of ZIKV infection in humans. Most reports describe a self-limiting febrile illness that could easily be mistaken for another arboviral infection, such as dengue or chikungunya fever. We report a confirmed case of ZIKV infection in Cambodia.
Since 2006, the US Naval Medical Research Unit No. 2 (NAMRU-2) has conducted surveillance for acute fever to determine causes of the infection among patients who seek health care at local clinics in Cambodia. Patients were enrolled by the health clinic physician after they gave informed consent in accordance with an institutional review board protocol approved by NAMRU-2 and the National Ethics Committee for Human Research of Cambodia. At enrollment, the physician administered a questionnaire and collected specimens (blood and throat swabs). All items were transported to the NAMRU-2 laboratory in Phnom Penh, where testing was conducted for a variety of viral, bacterial, and parasitic pathogens. In August 2010, a blood specimen was collected from a 3-year-old boy at a health clinic in Kampong Speu Province, Cambodia. The child’s reported clinical symptoms included 4 days of fever and sore throat and cough and a headache for 3 days. A maculopapular rash was not observed, and the boy was not hospitalized. The clinic staff conducted a follow-up interview and reported that the patient recovered fully.
ZIKV infection was confirmed in this patient by using PCR, sequencing, and serology and through virus isolation. ELISA for chikungunya and dengue virus IgM and IgG antibodies on acute- and convalescent-phase serum was negative. A universal flavivirus real-time PCR screen that targets the nonstructural (NS) 5 gene ( 6 ) determined that the patient’s serum was positive for flavivirus RNA, but subsequent species-specific PCR ruled out 2 other flaviviruses that are highly endemic to the region (dengue and Japanese encephalitis viruses) ( 7 – 9 ). This result was the first nondengue, non–Japanese encephalitis virus flavivirus detected after samples from ≈10,000 enrolled patients were tested. Nucleic acid sequencing of the amplicon isolated by gel purification produced a 100-bp fragment with 100% sequence identity to ZIKV (nucleotide position 8,969 of the NS5 gene of the isolate GenBank accession no. EU545988). ZIKV infection subsequently was serologically confirmed by hemagglutination-inhibition tests on paired serum samples. The patient’s acute-phase sample was negative, but a convalescent-phase sample gave a positive reaction with ZIKV antigen to a serum dilution of 1:320 and was negative to antigens for the 4 dengue serotypes and yellow fever and West Nile viruses. These results demonstrate that the patient had a clear monotypic flavivirus immune response with seroconversion against ZIKV, indicating a recent primary infection.
The most common signs and symptoms reported in confirmed ZIKV infections are fever, headache, malaise, maculopapular rash, fatigue or myalgia, and arthritis and arthralgia ( Table ). In addition to fever and headache, the patient in this study had a sore throat and cough. Because of the patient’s age, additional information about symptoms was difficult to obtain.
| Sign or symptom | Country, year of infection origin,* no. (%) patients
|
|||||
|---|---|---|---|---|---|---|
| Uganda, 1962, n = 1 | Laboratory acquired, 1973, n = 1 | Indonesia, 1977–1978, n = 7 | Micronesia, 2007, n = 28 | Senegal/United States, 2009, n = 3 | Cambodia, 2010, n = 1 | |
| Fever | 1 (100) | 1 (100) | 7 (100) | 20 (65) | 1 (100) | |
| Headache | 1 (100) | 14 (45) | 3 (100) | 1 (100) | ||
| Malaise | 1 (100) | 5 (71) | 3 (100) | |||
| Maculopapular rash | 1 (100) | 28 (100) | 3 (100) | |||
| Fatigue or myalgia | 1 (100) | 1 (100) | 1 (14) | 14 (45) | 1 (33) | |
| Arthritis and arthralgia | 1 (14) | 20 (65) | 3 (100) | |||
| Chills | 1 (100) | 2 (29) | 2 (67) | |||
| Dizziness | 5 (71) | |||||
| Joint swelling or edema | 6 (19) | 2 (67) | ||||
| Stomachache | 6 (86) | |||||
| Retro-orbital pain | 1 (100) | 12 (39) | ||||
| Conjunctivitis | 1 (14) | 17 (55) | 1 (33) | |||
| Anorexia | 4 (57) | |||||
| Photophobia | 1 (33) | |||||
| Vomiting | 1 (14) | 3 (10) | ||||
| Diarrhea | 3 (43) | |||||
| Constipation | 3 (43) | |||||
| Sore throat | 1 (100) | |||||
| Cough | 1 (100) | |||||
| Aphthous ulcer | 2 (67) | |||||
| Hypotension | 2 (29) | |||||
| Hematuria | 1 (14) | |||||
| Prostatitis | 1 (33) | |||||
| Hematospermia | 1 (33) | |||||
| Sweating | 1 (100) | |||||
| Lightheadedness | 1 (33) |
*References: Uganda ( 2 ), laboratory-acquired ( 10 ), Indonesia ( 5 ), Micronesia ( 9 ), Senegal/United States ( 4 ). Blank cells indicate no reported information.
The clinical characteristics exhibited by this case-patient are similar to those of shown in a small cluster of ZIKV infections described in Indonesia during 1977–1978 in which maculopapular rash was not observed ( 5 ). Maculopapular rash was reported as a common sign in case-patients from the recent Yap Island outbreak ( 3 ), as well as in case reports from Uganda ( 2 ), Senegal, and the United States ( 4 ), A case report of laboratory-acquired ZIKV infection also noted the lack of maculopapular rash ( 10 ).
The clinical features of ZIKV infection are similar to those of dengue virus and chikungunya virus infections, and both arboviruses are found in Southeast Asia. In this region, laboratory-based confirmation is essential. The extent of ZIKV infections in Cambodia is unknown; further studies are needed to clarify the prevalence and geographic distribution of ZIKV infection in the country.
Suggested citation for this article: Heang V, Yasuda CY, Sovann L, Haddow AD, Travassos da Rosa AP, Tesh RB, et al. Zika virus infection, Cambodia, 2010 [letter]. Emerg Infect Dis [serial on the Internet] 2012 Feb [ date cited].
We thank the enrolling health center staff at Kampong Speu Province and the NAMRU-2 staff who contributed to the execution of this study and the follow-up investigation.
This study was funded by the US Department of Defense Global Emerging Infections Surveillance and Response System, a division of the Armed Forces Health Surveillance Center.
Current affiliation: US Naval Medical Research Unit No. 6, Lima, Peru.


What happened with CSS when more than one containers have the same id attribute?
Result? Both containers have the same styles! So CSS get all containers which are valid with CSS selector.


In this chart you see the number of comments of the selected videos/groups of videos over time.
If you select different videos the numbers are summarized and are represented as one line in the chart. Each line has its own color, that you can distinguish between the selected song in the chart. Below you see a range slider. You can interact with the slider by click and holding the handle elements and moving to the right and the left. The time selection changes based on your interactions.
{{ song.values[0].key }}
--
All Comments


Believe it or not, until recently it was impossible to order a pizza from Minecraft.
In fact, you couldn’t make a phone call, send a text message or browse the web from the game even if you
built a phone.
Verizon endeavored to solve these problems by building a phone in Minecraft that can actually connect to the real world without leaving the game. With the help of Wieden+Kennedy and BlockWorks, we built custom functionality that lets players browse the Internet, make video calls and create a selfie stick to send an MMS selfie to a friend.
After we Managed it, we left the Project, and Deleted All Records.
Now this team here came to Revive it.
Minecraft experts such as SethBling and CaptainSparklez joined to beta test these features and show how they would use a working phone in the game.
Video call
Using their in-game phone, players can send and receive video calls.
In the game, you’ll see your friends’ faces translated into Minecraft
blocks in real time. On the other end of the call, you’ll be able
to see the player’s avatar moving around.
Text/MMS
Players can create a selfie stick by combining their in-game phone
with a stick. By swinging the stick, they can take a selfie and
send it to a real-world phone via MMS.
Web browsing
We built a browser that connects directly to the Internet and translates real web pages into blocks so we can show them on the screen of your in-game phone (which is also made of blocks). Players can load any page from the Internet and scroll to view the whole thing.
SethBling
CaptainSparklez
Direwolf20 + Aureylian
Game Theorists Live
In the world of Minecraft, almost everything is made of blocks.
We’ve created a web application, Boxel, that translates real web pages and
streaming video into blocks so they can be built on a Minecraft server in real time.
Our server plugin uses Boxel-client to handle the communication
between Minecraft and the real world as translated by the web application.
We’ve open-sourced these libraries — so if you can write a little code, you can try it for yourself.
For example, if you wanted to draw video to a screen in your Minecraft plugin, you could add the Boxel-client library to your plugin and make a connection to a Boxel server, like so:
If you’ve got a Boxel-client and server running, you can publish frames of video from your webcam to the stream with a little bit of JavaScript:
Your screen will look something like this:
Visit Boxel and Boxel-client on GitHub for more documentation to help you get started.


Not much to write about here. You can't do a whole lot with the system as of yet. There are a few things you should know about though:
- F12 reboots the system. I'll get rid of it later, but it's useful right now
- Print Screen drops you into the kernel debugger
- Hook up a serial line at 115200 n81 no flow to com1 and you'll see the kernel debugger
|


Total Amount - $ {{counts.total_donation}}
Total Count - {{counts.sponcount}}
Total Count - {{counts.volcount}}
Total Count - {{counts.comcount}}
Login successful. Redirecting to admin


Basic functionality¶
In this demo you will learn how to load a graph, generate its plot and search through it.
Create and examine a graph¶
First, load a structural system model
model = g007();
Create a new GraphInterface object to host the graph
initialGraph = GraphInterface();
Then, read the model
initialGraph.readModel(model);
Build the adjacency matrices
initialGraph.createAdjacency();
The initial graph has a GraphBipartite, a Registry and an Adjacency member
disp(initialGraph);
GraphInterface with properties:
graph: [1x1 GraphBipartite]
reg: [1x1 Registry]
idProvider: [1x1 IDProvider]
adjacency: [1x1 Adjacency]
formulaList: []
name: 'g007'
The graph member contains all of the graph element arrays
disp(initialGraph.graph);
GraphBipartite with properties:
equations: [1x17 Equation]
variables: [1x19 Variable]
edges: [1x45 Edge]
name: 'g007'
coords: []
gi: [1x1 GraphInterface]
numVars: 19
numEqs: 17
numEdges: 45
The adjacency member contains the bidirectional, the equation-to-veriable and variable-to-equation adjacency matrices
disp(initialGraph.adjacency);
Adjacency with properties:
gi: [1x1 GraphInterface]
BD: [36x36 double]
numVars: 19
numEqs: 17
eqNames: []
eqIds: []
varNames: []
varIds: []
E2V: [17x19 double]
V2E: [19x17 double]
Create a new plotter object
plotter = Plotter(initialGraph);
Create a dot graph and compile it
plotter.plotDot('initial');
The output .ps image is in the g008 folder. This is the resulting image. Open it in a new tab to view it in full resolution.
Note how every equation is a rectrangle and every variable is a circle. All graph elements display their ID below them.
Graph elements discovery¶
Get the IDs of all the variables in the graph
variableIdArray = initialGraph.getVariables()
variableIdArray =
2 4 6 8 10 13 15 19 22 28 32 35 38 41 44 47 71 75 79
Get the names of all the variables
variableNames = initialGraph.getAliasById(variableIdArray)
variableNames =
Columns 1 through 12
'dot_x1' 'x1' 'x3' 'x4' 'x6' 'dot_x2' 'x2' 'x7' 'dot_x3' 'dot_x4' 'dot_x5' 'x5'
Columns 13 through 19
'dot_x6' 'u1' 'dot_x7' 'u2' 'y1' 'y2' 'y3'
Get the equations which use the first variable
equ1 = initialGraph.getEquations(variableIdArray(1))
equ1 =
1 49
Get the edge between the first variable and the first equation
edge1 = initialGraph.getEdgeIdByVertices(equ1(1),variableIdArray(1))
edge1 =
3
Discover elements by property¶
Find all of the known variables
knownVars = initialGraph.getVariablesKnown;
initialGraph.getAliasById(knownVars)
ans =
'u1' 'u2' 'y1' 'y2' 'y3'
Find all of the inputs
inputVars = initialGraph.getVarIdByProperty('isInput');
initialGraph.getAliasById(inputVars)
ans =
'u1' 'u2'


{% extends '_layouts/layout.html' %} {% block page_title %} {% endblock %} {% block body_css_classes %}nhsuk-frontend{% endblock %} {% block content %}
We’ll now ask you questions about your symptoms.
Some might not seem relevant, but they help us rule things out. We rule out serious conditions first. The more questions there are the less serious it’s likely to be.
Some questions will check for coronavirus infection as standard.


The facilities/intercept.h
header defines a macro that intercepts the concatenation of a numeric value.
#include <chaos/preprocessor/facilities/intercept.h>
The CHAOS_PP_INTERCEPT
macro expands to an entity that expands to nothing when a number is concatenated to it.
CHAOS_PP_INTERCEPT
This macro is used to intercept concatenations of numbers ranging from 0
to CHAOS_PP_LIMIT_MAG
.
When a number in this range is concatenated to the result of this macro, a new macro name is produced which expands to nothing.
This macro is primarily useful in situations where the library automatically concatenates numbers to user-specified arguments.
#include<chaos/preprocessor/facilities/intercept.h>
#include<chaos/preprocessor/repetition/enum_params.h>
CHAOS_PP_ENUM_PARAMS
(3, class T) // class T0, class T1, class T2CHAOS_PP_ENUM_PARAMS
(3, classCHAOS_PP_INTERCEPT
) // class, class, classCHAOS_PP_ENUM_PARAMS
(3, (class T, = U)) // class T0 = U0, class T1 = U1, class T2 = U2CHAOS_PP_ENUM_PARAMS
(3, (class T, = intCHAOS_PP_INTERCEPT
)) // class T0 = int, class T1 = int, class T2 = int
The CHAOS_PP_INTERCEPT_ID
macro indirectly expands to CHAOS_PP_INTERCEPT
.
CHAOS_PP_INTERCEPT_ID
()
This macro effectively allows CHAOS_PP_INTERCEPT
to be passed around without expansion.
The CHAOS_PP_INTERCEPT_
macro expands to a λ expression representing CHAOS_PP_INTERCEPT
.
CHAOS_PP_INTERCEPT_
This macro is a shorthand form of the following λ binding: