The rules and conventions governing how the nodes in a CGNS file are organized, including their names and labels, are specified in the SIDS document, with additional details in the SIDS File Mapping Manual. These documents also specify in detail how CFD information is to be stored within the nodes in a standardized fashion so that other users can easily access and read it. When a CGNS file strictly adheres to the rules given in the SIDS document, it is said to be "SIDS-compliant." A CGNS file must be SIDS-compliant in order for other users to be able to properly interpret it. A brief overview of the most commonly used aspects of the SIDS is included in the current document.
However, to get started with CGNS, it is not necessary for the user to fully understand the SIDS document. The mid-level, or API calls have been created to aid users in writing and reading CGNS files that are SIDS-compliant. [There are currently two levels of programming access to CGNS. The lowest level consists of CGIO-level calls which interact directly with the database manager. These calls perform the most basic functions, such as creating a child node, writing data, reading data, etc. However, these low-level calls know nothing at all about the SIDS, so the user is responsible for putting data in the correct place, to make the CGNS file SIDS-compliant. The mid-level, or API calls, which always begin with the characters "cg_", were written with knowledge of the SIDS. Therefore, it is easier to adhere to the SIDS standards when writing a CGNS file using the API calls, and some checks for SIDS-compliance are also made by the API calls when accessing a CGNS file (SIDS compliance is not guaranteed, but the API calls go a long way toward facilitating it). The API calls also drastically shorten the calling sequences necessary to perform many of the functions needed to create and read CGNS files.] Using the API, most CFD data of interest to the majority of users can be written into or read from a CGNS file very easily with only an elementary understanding of the SIDS.
In the following sections, we give detailed instructions on how to create typical CGNS files or portions of files. These instructions are given in the form of simple examples. They make use of the mid-level API calls, although not all API calls are covered in this document (a complete list of available API calls can be found in the Mid-Level Library document). We recommend that the user read through the examples in this section in order, because some information in the later sections depends on being familiar with information given in the earlier ones. Hopefully, users should be able to easily extend these simple examples to their own applications. Additional applications are covered in a later section. For those users already familiar with the PLOT3D format for CFD data [Walatka, P. P., Buning, P. G., Pierce, L., Elson, P. A., "PLOT3D User's Guide," NASA TM 101067, March 1990], we include a detailed description on reading and writing PLOT3D-type variables in a CGNS file.
Also note that we have delayed the discussion of units and nondimensionalization until later. For now, all examples simply store and retrieve pure numbers, and it is assumed that the user knows what the dimensions or nondimensionalizations of each variable are.
This first section gives several structured grid examples, whereas the following section gives unstructured grid examples. However, we recommend that the current section be read first, in its entirety, even if the user is only interested in unstructured grid applications. This is because much of the organization of the CGNS files is identical for both grid types, and later sections of this document assume that the user is familiar with information given in earlier sections.
This first example is for a very simple 3-D Cartesian grid of size
21 × 17 × 9. The grid points themselves are created
using the following FORTRAN code snippet:
do k=1,nk do j=1,nj do i=1,ni x(i,j,k)=float(i-1) y(i,j,k)=float(j-1) z(i,j,k)=float(k-1) enddo enddo enddo
A complete FORTRAN code that creates this grid and
uses API calls to write it
to a CGNS file called grid.cgns is shown here
(note that a FORTRAN line continuation
is denoted by a +). This (and all later) coded examples
are available from the
CGNS site
,
and summarized in this document in the section
Example Computer Codes.
program write_grid_str c c Creates simple 3-D structured grid and writes it to a c CGNS file. c c This program uses the fortran convention that all c variables beginning with the letters i-n are integers, c by default, and all others are real c c Example compilation for this program is (change paths!): c c ifort -I ../CGNS_CVS/cgnslib -c write_grid_str.f c ifort -o write_grid_str write_grid_str.o -L ../CGNS_CVS/cgnslib/LINUX -lcgns c c (../CGNS_CVS/cgnslib/LINUX/ is the location where the compiled c library libcgns.a is located) c c cgnslib_f.h file must be located in directory specified by -I during compile: include 'cgnslib_f.h' c c dimension statements (note that tri-dimensional arrays c x,y,z must be dimensioned exactly as (21,17,N) (N>=9) c for this particular case or else they will be written to c the CGNS file incorrectly! Other options are to use 1-D c arrays, use dynamic memory, or pass index values to a c subroutine and dimension exactly there): real*8 x(21,17,9),y(21,17,9),z(21,17,9) dimension isize(3,3) character basename*32,zonename*32 c c create gridpoints for simple example: ni=21 nj=17 nk=9 do k=1,nk do j=1,nj do i=1,ni x(i,j,k)=float(i-1) y(i,j,k)=float(j-1) z(i,j,k)=float(k-1) enddo enddo enddo write(6,'('' created simple 3-D grid points'')') c c WRITE X, Y, Z GRID POINTS TO CGNS FILE c open CGNS file for write call cg_open_f('grid.cgns',CG_MODE_WRITE,index_file,ier) if (ier .ne. CG_OK) call cg_error_exit_f c create base (user can give any name) basename='Base' icelldim=3 iphysdim=3 call cg_base_write_f(index_file,basename,icelldim,iphysdim, + index_base,ier) c define zone name (user can give any name) zonename = 'Zone 1' c vertex size isize(1,1)=21 isize(2,1)=17 isize(3,1)=9 c cell size isize(1,2)=isize(1,1)-1 isize(2,2)=isize(2,1)-1 isize(3,2)=isize(3,1)-1 c boundary vertex size (always zero for structured grids) isize(1,3)=0 isize(2,3)=0 isize(3,3)=0 c create zone call cg_zone_write_f(index_file,index_base,zonename,isize, + Structured,index_zone,ier) c write grid coordinates (user must use SIDS-standard names here) call cg_coord_write_f(index_file,index_base,index_zone,RealDouble, + 'CoordinateX',x,index_coord,ier) call cg_coord_write_f(index_file,index_base,index_zone,RealDouble, + 'CoordinateY',y,index_coord,ier) call cg_coord_write_f(index_file,index_base,index_zone,RealDouble, + 'CoordinateZ',z,index_coord,ier) c close CGNS file call cg_close_f(index_file,ier) write(6,'('' Successfully wrote grid to file grid.cgns'')') stop end
For FORTRAN code, an include statement pointing to cgnslib_f.h must be present. (The cgnslib_f.h file comes with the CGNS software.) Also, it is imperative that the x, y, and z arrays be dimensioned exactly as (21,17,N), where N ≥ 9 (or else as a one-dimensional array of at least size 21*17*9) for this particular example; this is because the cg_coord_write_f routine writes the first 21*17*9 values contained in the array as it is stored in memory. If x, y, and z are tri-dimensional arrays and the first two indices are dimensioned larger than 21 and 17, respectively, then incorrect values will be placed in the CGNS file. In a real working code, one would probably either (a) use one-dimensional arrays, (b) dynamically allocate appropriate memory for x, y, and z, or else (c) pass the index values to a subroutine and write via an appropriately dimensioned work array.
In this case, the cell dimension (icelldim) is 3 (because the grid is made up of volume cells), and the physical dimension (iphysdim) is 3 (because 3 coordinates define 3-D). (See the section Overview of the SIDS for a more detailed description.) The isize array contains the vertex size, cell size, and boundary vertex size for each index direction. For a 3-D structured grid, the index dimension is always the same as the cell dimension, so this means there are 3 vertex sizes, 3 cell sizes, and 3 boundary vertex sizes (one each for the i, j, and k directions). For structured grids, the cell size is always one less than the corresponding vertex size, and the boundary vertex size has no meaning and is always zero. When writing the grid coordinates, the user must use SIDS-standard names. For example, x, y, and z coordinates must be named CoordinateX, CoordinateY, and CoordinateZ, respectively. Other standard names exist for other possible choices. Finally, basename and zonename must be declared as character strings, and the integer array isize must be dimensioned appropriately.
The grid coordinate arrays can be written in single or double precision. The desired data type is communicated to the API using the keywords RealSingle or RealDouble. The user must insure that the data type transmitted to the API is consistent with the the one used in declaring the coordinates arrays. When it is compiled, the code must also link to the compiled CGNS library libcgns.a. Instructions for compiling the CGNS library are given in README files that come with the CGNS software.
A complete code written in C that performs the same task of
creating grid coordinates and writing them to a CGNS file is given here.
/* Program write_grid_str.c */ /* Creates simple 3-D structured grid and writes it to a CGNS file. Example compilation for this program is (change paths!): cc -I ../CGNS_CVS/cgnslib -c write_grid_str.c cc -o write_grid_str_c write_grid_str.o -L ../CGNS_CVS/cgnslib/LINUX -lcgns (../CGNS_CVS/cgnslib/LINUX/ is the location where the compiled library libcgns.a is located) */ #include <stdio.h> #include <string.h> /* cgnslib.h file must be located in directory specified by -I during compile: */ #include "cgnslib.h" #if CGNS_VERSION < 3100 # define cgsize_t int #else # if CG_BUILD_SCOPE # error enumeration scoping needs to be off # endif #endif int main() { /* dimension statements (note that tri-dimensional arrays x,y,z must be dimensioned exactly as [N][17][21] (N>=9) for this particular case or else they will be written to the CGNS file incorrectly! Other options are to use 1-D arrays, use dynamic memory, or pass index values to a subroutine and dimension exactly there): */ double x[9][17][21],y[9][17][21],z[9][17][21]; cgsize_t isize[3][3]; int ni,nj,nk,i,j,k; int index_file,icelldim,iphysdim,index_base; int index_zone,index_coord; char basename[33],zonename[33]; /* create gridpoints for simple example: */ ni=21; nj=17; nk=9; for (k=0; k < nk; ++k) { for (j=0; j < nj; ++j) { for (i=0; i < ni; ++i) { x[k][j][i]=i; y[k][j][i]=j; z[k][j][i]=k; } } } printf("\ncreated simple 3-D grid points"); /* WRITE X, Y, Z GRID POINTS TO CGNS FILE */ /* open CGNS file for write */ if (cg_open("grid_c.cgns",CG_MODE_WRITE,&index_file)) cg_error_exit(); /* create base (user can give any name) */ strcpy(basename,"Base"); icelldim=3; iphysdim=3; cg_base_write(index_file,basename,icelldim,iphysdim,&index_base); /* define zone name (user can give any name) */ strcpy(zonename,"Zone 1"); /* vertex size */ isize[0][0]=21; isize[0][1]=17; isize[0][2]=9; /* cell size */ isize[1][0]=isize[0][0]-1; isize[1][1]=isize[0][1]-1; isize[1][2]=isize[0][2]-1; /* boundary vertex size (always zero for structured grids) */ isize[2][0]=0; isize[2][1]=0; isize[2][2]=0; /* create zone */ cg_zone_write(index_file,index_base,zonename,*isize,Structured,&index_zone); /* write grid coordinates (user must use SIDS-standard names here) */ cg_coord_write(index_file,index_base,index_zone,RealDouble,"CoordinateX", x,&index_coord); cg_coord_write(index_file,index_base,index_zone,RealDouble,"CoordinateY", y,&index_coord); cg_coord_write(index_file,index_base,index_zone,RealDouble,"CoordinateZ", z,&index_coord); /* close CGNS file */ cg_close(index_file); printf("\nSuccessfully wrote grid to file grid_c.cgns\n"); return 0; }
The CGNS file grid.cgns that is created by the code above is a binary file that, internally, possesses the tree-like structure shown below. As mentioned in the Introduction, each node has a name, a label, and may or may not contain data. In the example in the figure, all the nodes contain data except for the GridCoordinates node, for which MT indicates no data.
However, the user really does not need to know the full details of
the tree-like structure in this case. The API has automatically
created a SIDS-compliant CGNS file! Now, the user can
just as easily read the CGNS file using the API.
The FORTRAN code segment used to read the CGNS file
grid.cgns that we just created is given here:
c READ X, Y, Z GRID POINTS FROM CGNS FILE include 'cgnslib_f.h' c open CGNS file for read-only call cg_open_f('grid.cgns',CG_MODE_READ,index_file,ier) if (ier .ne. CG_OK) call cg_error_exit_f c we know there is only one base (real working code would check!) index_base=1 c we know there is only one zone (real working code would check!) index_zone=1 c get zone size (and name - although not needed here) call cg_zone_read_f(index_file,index_base,index_zone,zonename, + isize,ier) c lower range index irmin(1)=1 irmin(2)=1 irmin(3)=1 c upper range index of vertices irmax(1)=isize(1,1) irmax(2)=isize(2,1) irmax(3)=isize(3,1) c read grid coordinates call cg_coord_read_f(index_file,index_base,index_zone, + 'CoordinateX',RealSingle,irmin,irmax,x,ier) call cg_coord_read_f(index_file,index_base,index_zone, + 'CoordinateY',RealSingle,irmin,irmax,y,ier) call cg_coord_read_f(index_file,index_base,index_zone, + 'CoordinateZ',RealSingle,irmin,irmax,z,ier) c close CGNS file call cg_close_f(index_file,ier)
As before, the x, y, and z arrays in this case must be dimensioned correctly: for a tri-dimensional array, (21,17,N), where N ≥ 9. (In a real working code, one would probably either (a) use one-dimensional arrays, (b) dynamically allocate appropriate memory for x, y, and z after reading isize, or else (c) pass the isize values to a subroutine and dimension a work array appropriately prior to reading.) Also note that, regardless of the precision in which the grid coordinates were written to the CGNS file (single or double), one can read them either way; the API automatically performs the translation. (The arrays x, y, and z in the code above must be declared as single precision if RealSingle is used and as double precision if RealDouble is used.) Finally, isize should be dimensioned appropriately, zonename should be declared as a character variable, and irmin and irmax should be dimensioned appropriately.
In this section, we now write a flow solution associated with
the grid from the previous section.
We assume that
we have two flow solution arrays available: static density and
static pressure. To illustrate three important options, we will
show how to write the flow solution (a) at vertices, (b) at
cell centers, and (c) at cell centers plus rind cells.
(a) Flow Solution at Vertices
The first option is illustrated schematically in 2-D in the figure below. Simply stated, a Vertex flow solution is located at the same location as the grid points. Assuming that the grid points have already been written to a CGNS file, the following FORTRAN code segment adds the flow solution at vertices:
c WRITE FLOW SOLUTION TO EXISTING CGNS FILE include 'cgnslib_f.h' c open CGNS file for modify call cg_open_f('grid.cgns',CG_MODE_MODIFY,index_file,ier) if (ier .ne. CG_OK) call cg_error_exit_f c we know there is only one base (real working code would check!) index_base=1 c we know there is only one zone (real working code would check!) index_zone=1 c define flow solution node name (user can give any name) solname = 'FlowSolution' c create flow solution node call cg_sol_write_f(index_file,index_base,index_zone,solname, + Vertex,index_flow,ier) c write flow solution (user must use SIDS-standard names here) call cg_field_write_f(index_file,index_base,index_zone,index_flow, + RealDouble,'Density',r,index_field,ier) call cg_field_write_f(index_file,index_base,index_zone,index_flow, + RealDouble,'Pressure',p,index_field,ier) c close CGNS file call cg_close_f(index_file,ier)
In this code, the density (r) and pressure (p) variables must be dimensioned correctly for this particular case: for a tri-dimensional array, (21,17,N), where N ≥ 9 (see discussion in the previous section). Note that the API, knowing that the flow solution type is Vertex, automatically writes out the correct index range, corresponding with the zone's grid index range. Also note that we opened the existing CGNS file and modified it (CG_MODE_MODIFY) - we knew ahead of time that only one base and only one zone exist; a real working code would make appropriate checks. Finally, solname should be declared as a character variable and r and p must be declared as double precision variables when RealDouble type is used.
The layout of the CGNS file with the flow solution at vertices included is shown in the figure below. The three nodes under GridCoordinates_t have been left out to conserve space in the figure, but they exist as indicated by the three unconnected lines.
The vertex flow solution can be read in using the following
FORTRAN code segment (can read in as single or double precision - see
discussion in the previous section):
c READ FLOW SOLUTION FROM CGNS FILE include 'cgnslib_f.h' c open CGNS file for read-only call cg_open_f('grid.cgns',CG_MODE_READ,index_file,ier) if (ier .ne. CG_OK) call cg_error_exit_f c we know there is only one base (real working code would check!) index_base=1 c we know there is only one zone (real working code would check!) index_zone=1 c we know there is only one FlowSolution_t (real working code would check!) index_flow=1 c get zone size (and name - although not needed here) call cg_zone_read_f(index_file,index_base,index_zone,zonename, + isize,ier) c lower range index irmin(1)=1 irmin(2)=1 irmin(3)=1 c upper range index - use vertex dimensions c checking GridLocation first (real working code would check c to make sure there are no Rind cells also!): call cg_sol_info_f(index_file,index_base,index_zone,index_flow, + solname,loc,ier) if (loc .ne. Vertex) then write(6,'('' Error, GridLocation must be Vertex!'')') stop end if irmax(1)=isize(1,1) irmax(2)=isize(2,1) irmax(3)=isize(3,1) c read flow solution call cg_field_read_f(index_file,index_base,index_zone,index_flow, + 'Density',RealSingle,irmin,irmax,r,ier) call cg_field_read_f(index_file,index_base,index_zone,index_flow, + 'Pressure',RealSingle,irmin,irmax,p,ier) c close CGNS file call cg_close_f(index_file,ier)
The option for outputting the flow solution at cell centers is illustrated schematically in 2-D in the figure below. The flow solutions are defined at the centers of the cells defined by the four surrounding grid points. In 3-D, the cell centers are defined by eight surrounding grid points.
c create flow solution node (NOTE USE OF CellCenter HERE) call cg_sol_write_f(index_file,index_base,index_zone,solname, + CellCenter,index_flow,ier)
The layout of the CGNS file with the flow solution at cell centers is shown (below the FlowSolution_t node only) in the next figure. Note that the indices over which the flow solutions are written are now from (1,1,1) to (20,16,8) (contrast with the FlowSolution part of the figure with the flow solution at vertices
The FORTRAN code segment to read in the solution at cell centers
is the same as that given above for vertices, except that the section that
defines irmax is replaced by:
c upper range index - use cell dimensions c checking GridLocation first (real working code would check c to make sure there are no Rind cells also!): call cg_sol_info_f(index_file,index_base,index_zone,index_flow, + solname,loc,ier) if (loc .ne. CellCenter) then write(6,'('' Error, GridLocation must be CellCenter!'')') stop end if irmax(1)=isize(1,2) irmax(2)=isize(2,2) irmax(3)=isize(3,2)
Rind data is additional flow solution data exterior to a grid, at "ghost" locations. Rind data can be associated with other GridLocation values beside CellCenter, although we only show an example using CellCenter here. Furthermore, this example is for structured grids only, for which Rind data can be defined implicitly (via indexing conventions alone). The option for outputting the flow solution at cell centers with additional rind data is illustrated schematically in 2-D in the figure below. In this diagram, we show one layer of rind cell data in the row below the grid itself. There could be rind data at other sides of the grid, or there could be more than one row at a given side.
In CGNS, the flow solution at rind cells is not stored as separate entities, but rather the flow solution range is extended to include the rind cells. For example, in the 2-D schematic of the above figure, instead of an index range of p(3,2) for pressures stored at the cell centers, the flow solution would now have an index range of p(3,0:2) or p(3,3). See the SIDS document for details.
For our 3-D example, we assume that we have one row of rind data
at 4 faces of the zone (ilo, ihi, jlo, jhi, where these
represent the low and high ends of the i and j
directions, respectively), and
no rind cells at klo or khi (at either end of the k
direction).
The code segment to write the flow solution and rind data is as
follows:
c WRITE FLOW SOLUTION TO EXISTING CGNS FILE include 'cgnslib_f.h' c open CGNS file for modify call cg_open_f('grid.cgns',CG_MODE_MODIFY,index_file,ier) if (ier .ne. CG_OK) call cg_error_exit_f c we know there is only one base (real working code would check!) index_base=1 c we know there is only one zone (real working code would check!) index_zone=1 c define flow solution node name (user can give any name) solname = 'FlowSolution' c create flow solution node (NOTE USE OF CellCenter HERE) call cg_sol_write_f(index_file,index_base,index_zone,solname, + CellCenter,index_flow,ier) c go to position within tree at FlowSolution_t node call cg_goto_f(index_file,index_base,ier,'Zone_t',index_zone, + 'FlowSolution_t',index_flow,'end') c write rind information under FlowSolution_t node (ilo,ihi,jlo,jhi,klo,khi) irinddata(1)=1 irinddata(2)=1 irinddata(3)=1 irinddata(4)=1 irinddata(5)=0 irinddata(6)=0 call cg_rind_write_f(irinddata,ier) c write flow solution (user must use SIDS-standard names here) call cg_field_write_f(index_file,index_base,index_zone,index_flow, + RealDouble,'Density',r,index_field,ier) call cg_field_write_f(index_file,index_base,index_zone,index_flow, + RealDouble,'Pressure',p,index_field,ier) c close CGNS file call cg_close_f(index_file,ier)
For this case of cell center flow solution with rind data, the density (r) and pressure (p) are written to the CGNS file with the following index ranges: from i = 0 to i = 20 + 1 = 21 (or a total i length of 22), from j = 0 to j = 16 + 1 = 17 (or a total j length of 18), and from k = 1 to k = 8. The variables r and p must be dimensioned appropriately to reflect these index ranges modified by the rind values.
The layout of the CGNS file for this example (below the FlowSolution_t node only) is shown below. Compare this figure with the figures for the flow solution at vertices and for the flow solution at cell centers without rind data.
A FORTRAN code segment to read the flow solution for this example is:
c READ FLOW SOLUTION FROM CGNS FILE include 'cgnslib_f.h' c open CGNS file for read-only call cg_open_f('grid.cgns',CG_MODE_READ,index_file,ier) if (ier .ne. CG_OK) call cg_error_exit_f c we know there is only one base (real working code would check!) index_base=1 c we know there is only one zone (real working code would check!) index_zone=1 c we know there is only one FlowSolution_t (real working code would check!) index_flow=1 c get zone size (and name - although not needed here) call cg_zone_read_f(index_file,index_base,index_zone,zonename, + isize,ier) c go to position within tree at FlowSolution\_t node call cg_goto_f(index_file,index_base,ier,'Zone_t',index_zone, + 'FlowSolution_t',index_flow,'end') c read rind data call cg_rind_read_f(irinddata,ier) c lower range index irmin(1)=1 irmin(2)=1 irmin(3)=1 c upper range index - use cell dimensions and rind info c checking GridLocation first: call cg_sol_info_f(index_file,index_base,index_zone,index_flow, + solname,loc,ier) if (loc .ne. CellCenter) then write(6,'('' Error, GridLocation must be CellCenter!'')') stop end if irmax(1)=isize(1,2)+irinddata(1)+irinddata(2) irmax(2)=isize(2,2)+irinddata(3)+irinddata(4) irmax(3)=isize(3,2)+irinddata(5)+irinddata(6) c read flow solution call cg_field_read_f(index_file,index_base,index_zone,index_flow, + 'Density',RealSingle,irmin,irmax,r,ier) call cg_field_read_f(index_file,index_base,index_zone,index_flow, + 'Pressure',RealSingle,irmin,irmax,p,ier) c close CGNS file call cg_close_f(index_file,ier)
To illustrate the use of boundary conditions, we again use the
same single-zone Cartesian grid.
Referring back to the grid figure,
we wish to apply the following:
ilo - BCTunnelInflow
ihi - BCExtrapolate
jlo - BCWallInviscid
jhi - etc.
klo - etc.
khi - etc.
where BCTunnelInflow, BCExtrapolate, and
BCWallInviscid are data-name identifiers for boundary
conditions.
The complete list of boundary condition
identifiers is found in the SIDS document.
In this example, we take the approach of
using the lowest-level BC implementation allowed - see the figure
showing the general hierarchical
structure of ZoneBC_t in the SIDS
overview section.
In this section, we show two different approaches for defining the
region over which each boundary condition acts.
The first is with type PointRange, meaning that we define the
minimum and maximum points on a face that define a logically
rectangular region (this method is usable only for faces that are
capable of being defined in this way).
The second is with type PointList, which gives
the list of all the points for
which the boundary condition applies.
This latter method is generally used for any
zone whose defined region is not logically rectangular.
(a) Boundary Conditions Specifying Range
A FORTRAN code segment to write the boundary condition
information of type PointRange
to the existing CGNS file from the previous two sections
is given here:
c WRITE BOUNDARY CONDITIONS TO EXISTING CGNS FILE include 'cgnslib_f.h' c open CGNS file for modify call cg_open_f('grid.cgns',CG_MODE_MODIFY,index_file,ier) if (ier .ne. CG_OK) call cg_error_exit_f c we know there is only one base (real working code would check!) index_base=1 c we know there is only one zone (real working code would check!) index_zone=1 c get zone size (and name - although not needed here) call cg_zone_read_f(index_file,index_base,index_zone,zonename, + isize,ier) ilo=1 ihi=isize(1,1) jlo=1 jhi=isize(2,1) klo=1 khi=isize(3,1) c write boundary conditions for ilo face, defining range first c (user can give any name) c lower point of range ipnts(1,1)=ilo ipnts(2,1)=jlo ipnts(3,1)=klo c upper point of range ipnts(1,2)=ilo ipnts(2,2)=jhi ipnts(3,2)=khi call cg_boco_write_f(index_file,index_base,index_zone,'Ilo', + BCTunnelInflow,PointRange,2,ipnts,index_bc,ier) c write boundary conditions for ihi face, defining range first c (user can give any name) c lower point of range ipnts(1,1)=ihi ipnts(2,1)=jlo ipnts(3,1)=klo c upper point of range ipnts(1,2)=ihi ipnts(2,2)=jhi ipnts(3,2)=khi call cg_boco_write_f(index_file,index_base,index_zone,'Ihi', + BCExtrapolate,PointRange,2,ipnts,index_bc,ier) c write boundary conditions for jlo face, defining range first c (user can give any name) c lower point of range ipnts(1,1)=ilo ipnts(2,1)=jlo ipnts(3,1)=klo c upper point of range ipnts(1,2)=ihi ipnts(2,2)=jlo ipnts(3,2)=khi call cg_boco_write_f(index_file,index_base,index_zone,'Jlo', + BCWallInviscid,PointRange,2,ipnts,index_bc,ier) ... etc... c close CGNS file call cg_close_f(index_file,ier)
The layout of the CGNS file for this example is shown below. Four of the children nodes of ZoneBC_t are left off for clarity.
Reading the boundary conditions can also be easily accomplished using
API calls, but we do not show an example of this here.
Because there are multiple BC_t children nodes under the
ZoneBC_t node, the user must first read in the number
of children nodes
that exist, then loop through them and retrieve the information
from each.
(b) Boundary Conditions Specifying Points
The FORTRAN code segment to write the boundary conditions using
PointList is the same as that for PointRange except
that the following segment, for example,
c write boundary conditions for ilo face, defining range first c (user can give any name) ipnts(1,1)=ilo ipnts(2,1)=jlo ipnts(3,1)=klo ipnts(1,2)=ilo ipnts(2,2)=jhi ipnts(3,2)=khi call cg_boco_write_f(index_file,index_base,index_zone,'Ilo', + BCTunnelInflow,PointRange,2,ipnts,index_bc,ier)
c write boundary conditions for ilo face, defining pointlist first c (user can give any name) icount=0 do j=jlo,jhi do k=klo,khi icount=icount+1 ipnts(1,icount)=ilo ipnts(2,icount)=j ipnts(3,icount)=k enddo enddo call cg_boco_write_f(index_file,index_base,index_zone,'Ilo', + BCTunnelInflow,PointList,icount,ipnts,index_bc,ier)
For the case of a multi-zone structured grid, each zone is handled individually in the same way as the examples in the preceding sections. However, multi-zone grids also require additional information about how the zones are connected to one another. A discussion of different types of zone-to-zone connectivity can be found in the SIDS overview section. For the example in this section, we show only a simple 1-to-1 connectivity example. We assume that we have a two-zone grid, each identical to the single zone used previously (21 × 17 × 9), except that zone 2 is offset in the x-direction by 20 units. Thus, the ilo face of zone 2 abuts the ihi face of zone 1, and each abutting point in the two zones touches a point from the neighboring zone. A picture of the grid is shown below.
The overall layout of this two-zone CGNS file is not shown here. It is similar to those shown earlier, except now there are two zones rather than one. See the SIDS overview for an additional example.
Now, 1-to-1 connectivity information must be written into
each of the zones. There are two ways to record this 1-to-1
information.
The first (specific)
method is valid only for 1-to-1 interfaces, and the regions
must be logically rectangular (because they are recorded
via PointRange and PointRangeDonor
nodes, for which only two points define
the entire region).
The second way is more general. It uses
PointList nodes in combination with PointListDonor.
(A third method, used to describe interfaces that are
not point-matched - such as mismatched or overset zones -
employs CellListDonor and InterpolantsDonor.)
Refer to the SIDS document for details
on the various methods for describing connectivity.
(a) Connectivity Using Specific 1-to-1 Method
The 1-to-1 connectivity information for the current example
can be written to a CGNS file using the following
FORTRAN code segment (assuming that all grid information has
already been written):
c WRITE 1-TO-1 CONNECTIVITY INFORMATION TO EXISTING CGNS FILE include 'cgnslib_f.h' c open CGNS file for modify call cg_open_f('grid.cgns',CG_MODE_MODIFY,index_file,ier) if (ier .ne. CG_OK) call cg_error_exit_f c we know there is only one base (real working code would check!) index_base=1 c get number of zones (should be 2 for our case) call cg_nzones_f(index_file,index_base,nzone,ier) c loop over zones to get zone sizes and names do index_zone=1,nzone call cg_zone_read_f(index_file,index_base,index_zone, + zonename(index_zone),isize,ier) ilo(index_zone)=1 ihi(index_zone)=isize(1,1) jlo(index_zone)=1 jhi(index_zone)=isize(2,1) klo(index_zone)=1 khi(index_zone)=isize(3,1) enddo c loop over zones again do index_zone=1,nzone c set up index ranges if (index_zone .eq. 1) then donorname=zonename(2) c lower point of receiver range ipnts(1,1)=ihi(1) ipnts(2,1)=jlo(1) ipnts(3,1)=klo(1) c upper point of receiver range ipnts(1,2)=ihi(1) ipnts(2,2)=jhi(1) ipnts(3,2)=khi(1) c lower point of donor range ipntsdonor(1,1)=ilo(2) ipntsdonor(2,1)=jlo(2) ipntsdonor(3,1)=klo(2) c upper point of donor range ipntsdonor(1,2)=ilo(2) ipntsdonor(2,2)=jhi(2) ipntsdonor(3,2)=khi(2) else donorname=zonename(1) c lower point of receiver range ipnts(1,1)=ilo(2) ipnts(2,1)=jlo(2) ipnts(3,1)=klo(2) c upper point of receiver range ipnts(1,2)=ilo(2) ipnts(2,2)=jhi(2) ipnts(3,2)=khi(2) c lower point of donor range ipntsdonor(1,1)=ihi(1) ipntsdonor(2,1)=jlo(1) ipntsdonor(3,1)=klo(1) c upper point of donor range ipntsdonor(1,2)=ihi(1) ipntsdonor(2,2)=jhi(1) ipntsdonor(3,2)=khi(1) end if c set up Transform itranfrm(1)=1 itranfrm(2)=2 itranfrm(3)=3 c write 1-to-1 info (user can give any name) call cg_1to1_write_f(index_file,index_base,index_zone, + 'Interface',donorname,ipnts,ipntsdonor,itranfrm, + index_conn,ier) enddo c close CGNS file call cg_close_f(index_file,ier)
Using a more general method, for which each connectivity pair is
listed (rather than ranges),
the connectivity information for the current example
can be written to a CGNS file using the following
FORTRAN code segment:
c WRITE GENERAL CONNECTIVITY INFORMATION TO EXISTING CGNS FILE include 'cgnslib_f.h' c open CGNS file for modify call cg_open_f('grid.cgns',CG_MODE_MODIFY,index_file,ier) if (ier .ne. CG_OK) call cg_error_exit_f c we know there is only one base (real working code would check!) index_base=1 c get number of zones (should be 2 for our case) call cg_nzones_f(index_file,index_base,nzone,ier) c loop over zones to get zone sizes and names do index_zone=1,nzone call cg_zone_read_f(index_file,index_base,index_zone, + zonename(index_zone),isize,ier) ilo(index_zone)=1 ihi(index_zone)=isize(1,1) jlo(index_zone)=1 jhi(index_zone)=isize(2,1) klo(index_zone)=1 khi(index_zone)=isize(3,1) enddo c loop over zones again do index_zone=1,nzone c set up point lists if (index_zone .eq. 1) then icount=0 do j=jlo(index_zone),jhi(index_zone) do k=klo(index_zone),khi(index_zone) icount=icount+1 ipnts(1,icount)=ihi(1) ipnts(2,icount)=j ipnts(3,icount)=k ipntsdonor(1,icount)=ilo(2) ipntsdonor(2,icount)=j ipntsdonor(3,icount)=k enddo enddo donorname=zonename(2) else icount=0 do j=jlo(index_zone),jhi(index_zone) do k=klo(index_zone),khi(index_zone) icount=icount+1 ipnts(1,icount)=ilo(2) ipnts(2,icount)=j ipnts(3,icount)=k ipntsdonor(1,icount)=ihi(1) ipntsdonor(2,icount)=j ipntsdonor(3,icount)=k enddo enddo donorname=zonename(1) end if c write integer connectivity info (user can give any name) call cg_conn_write_f(index_file,index_base,index_zone, + 'GenInterface',Vertex,Abutting1to1,PointList,icount,ipnts, + donorname,Structured,PointListDonor,Integer,icount, + ipntsdonor,index_conn,ier) enddo c close CGNS file call cg_close_f(index_file,ier)
This section gives several unstructured grid examples. The user should already be familiar with the information covered in the previous section, which gives structured grid examples. Because much of the organization of the CGNS files is identical for both grid types, many of the ideas covered in the structured grid section are not repeated again here.
This example uses the exact single-zone grid
shown earlier. However, it is now written
as an unstructured grid, which is made up of a series
of 6-sided elements (cubes in this case).
A FORTRAN code segment that uses API calls to write this grid
to a CGNS file called grid.cgns is shown here (note that it
does not matter
how the nodes are ordered in an unstructured zone, but in this
example they are ordered sequentially for simplicity of presentation):
c WRITE X, Y, Z GRID POINTS TO CGNS FILE include 'cgnslib_f.h' c open CGNS file for write call cg_open_f('grid.cgns',CG_MODE_WRITE,index_file,ier) if (ier .ne. CG_OK) call cg_error_exit_f c create base (user can give any name) basename='Base' icelldim=3 iphysdim=3 call cg_base_write_f(index_file,basename,icelldim,iphysdim, + index_base,ier) c define zone name (user can give any name) zonename = 'Zone 1' c we use the same grid as for the structured example with ni=21, c nj=17, nk=9. The variables ni, nj, and nk are still used later, c for convenience when numbering the unstructured grid elements. ni=21 nj=17 nk=9 c vertex size (21*17*9 = 3213) isize(1,1)=3213 c cell size (20*16*8 = 2560) isize(1,2)=2560 c boundary vertex size (zero if elements not sorted) isize(1,3)=0 c create zone call cg_zone_write_f(index_file,index_base,zonename,isize, + Unstructured,index_zone,ier) c write grid coordinates (user must use SIDS-standard names here) call cg_coord_write_f(index_file,index_base,index_zone,RealDouble, + 'CoordinateX',x,index_coord,ier) call cg_coord_write_f(index_file,index_base,index_zone,RealDouble, + 'CoordinateY',y,index_coord,ier) call cg_coord_write_f(index_file,index_base,index_zone,RealDouble, + 'CoordinateZ',z,index_coord,ier) c set element connectivity: c do all the HEX_8 elements (this part is mandatory): c maintain SIDS-standard ordering ielem_no=0 c index no of first element nelem_start=1 do k=1,nk-1 do j=1,nj-1 do i=1,ni-1 ielem_no=ielem_no+1 c in this example, due to the order in the node numbering, the c hexahedral elements can be reconstructed using the following c relationships: ifirstnode=i+(j-1)*ni+(k-1)*ni*nj ielem(1,ielem_no)=ifirstnode ielem(2,ielem_no)=ifirstnode+1 ielem(3,ielem_no)=ifirstnode+1+ni ielem(4,ielem_no)=ifirstnode+ni ielem(5,ielem_no)=ifirstnode+ni*nj ielem(6,ielem_no)=ifirstnode+ni*nj+1 ielem(7,ielem_no)=ifirstnode+ni*nj+1+ni ielem(8,ielem_no)=ifirstnode+ni*nj+ni enddo enddo enddo c index no of last element (=2560) nelem_end=ielem_no c unsorted boundary elements nbdyelem=0 c write HEX_8 element connectivity (user can give any name) call cg_section_write_f(index_file,index_base,index_zone, + 'Elem',HEXA_8,nelem_start,nelem_end,nbdyelem,ielem, + index_section,ier) c close CGNS file call cg_close_f(index_file,ier)
Note that for unstructured zones, the index dimension is always 1 (because only one index value is required to identify a position in the mesh), so the isize array contains the total vertex size, cell size, and boundary vertex size for the zone. In this example, the ielem array must be dimensioned exactly as (8,N), where N is greater than or equal to the total number of elements. The node points that lie in the lower left corner of the grid are shown schematically for two elements in the figure below. Here it can be seen, for example, that node numbers 1, 2, 23, 22, 358, 359, 380, and 379 make up element 1.
The overall layout of the CGNS file created by the above code segment is shown below. The nodes for y and z are left off due to lack of space. Compare this figure with the layout for the structured version of this grid.
For unstructured zones, the user may also wish to separately list the boundary elements in the CGNS file. This may be useful for assigning boundary conditions, as we will show later. In the current example, assume that the user wishes to assign three different types of boundary conditions: inflow at one end, outflow at the other end, and side walls on the four faces in-between. To accomplish this, it would be helpful to have three additional Elements_t nodes in the CGNS file, each of which lists the corresponding faces as elements (QUAD_4 in this case).
A FORTRAN code segment that accomplishes a part of this is given here. It may
be a part of the same code (above) that defined the grid and HEXA_8
connectivity.
c do boundary (QUAD) elements (this part is optional, c but you must do it if you eventually want to define BCs c at element faces rather than at nodes): c INFLOW: ielem_no=0 c index no of first element nelem_start=nelem_end+1 i=1 do k=1,nk-1 do j=1,nj-1 ielem_no=ielem_no+1 ifirstnode=i+(j-1)*ni+(k-1)*ni*nj jelem(1,ielem_no)=ifirstnode jelem(2,ielem_no)=ifirstnode+ni*nj jelem(3,ielem_no)=ifirstnode+ni*nj+ni jelem(4,ielem_no)=ifirstnode+ni enddo enddo c index no of last element nelem_end=nelem_start+ielem_no-1 c write QUAD element connectivity for inflow face (user can give any name) call cg_section_write_f(index_file,index_base,index_zone, + 'InflowElem',QUAD_4,nelem_start,nelem_end,nbdyelem, + jelem,index_section,ier) c OUTFLOW: ... etc...
In this example, the jelem array must be dimensioned exactly as (4,N), where N is greater than or equal to the total number of elements. Note that the nelem_start and nelem_end range is defined subsequent to the range of any other elements (i.e., the HEXA_8 elements) already defined in this zone. In other words, all elements in a given zone must have a different number.
The layout of the CGNS file in this case is exactly the same as that shown in the previous figure, except that there are now three additional Elements_t nodes under Zone_t. These are shown separately below.
To add a flow solution to an unstructured zone, the procedure is identical to that for a structured zone. However, the Rind field for unstructured grids indicates additional points rather than planes. Example of Rind capability for unstructured grids is not covered here. Considering the vertex and cell-center examples shown previously, the only difference for unstructured zones is that all arrays are one-dimensional (there is only one index), as opposed to three indices for 3-D structured arrays. A vertex solution indicates that the solution is stored at vertices or nodes. In the above example, there would be lists of 3213 data array items per solution variable. A cell center solution implies that the solution is stored at the center of each element. In the above example, there would be lists of 2560 data array items per solution variable.
The overall layout of the CGNS file is the same as that shown previously, except that there would also be a FlowSolution_t node under Zone 1, and this node would have the children nodes GridLocation, Density, and Pressure.
When writing boundary conditions to a CGNS file for an unstructured zone, one can follow the same general procedure outlined previously for a structured zone. In other words, the boundary conditions can be defined for point ranges or for individual points, where the points refer to nodes (vertices) of the grid. Coding would be essentially the same as that presented before, except that the points and/or ranges are now one-dimensional (there is only one index), as opposed to three indices for 3-D structured arrays.
However, for unstructured zones this is generally not the recommended method. Usually, for unstructured zones one has also already defined additional Elements_t nodes that define the boundary face elements. Therefore, it is best for the boundary conditions to be associated with these elements rather than with the nodes.
Because this concept is quite different from what was done with the
structured zone
earlier, we illustrate it with an example.
We earlier showed
how to create the additional
Elements_t nodes defining the boundary faces. The face-center
boundary conditions now can be written using the following code segment.
c WRITE BOUNDARY CONDITIONS TO EXISTING CGNS FILE include 'cgnslib_f.h' c open CGNS file for modify call cg_open_f('grid.cgns',CG_MODE_MODIFY,index_file,ier) if (ier .ne. CG_OK) call cg_error_exit_f c we know there is only one base (real working code would check!) index_base=1 c we know there is only one zone (real working code would check!) index_zone=1 c we know that for the unstructured zone, the following face elements c have been defined as inflow (real working code would check!): nelem_start=2561 nelem_end=2688 icount=0 do n=nelem_start,nelem_end icount=icount+1 ipnts(icount)=n enddo c write boundary conditions for ilo face call cg_boco_write_f(index_file,index_base,index_zone,'Ilo', + BCTunnelInflow,PointList,icount,ipnts,index_bc,ier) c we know that for the unstructured zone, the following face elements c have been defined as outflow (real working code would check!): nelem_start=2689 nelem_end=2816 icount=0 do n=nelem_start,nelem_end icount=icount+1 ipnts(icount)=n enddo c write boundary conditions for ihi face call cg_boco_write_f(index_file,index_base,index_zone,'Ihi', + BCExtrapolate,PointList,icount,ipnts,index_bc,ier) c we know that for the unstructured zone, the following face elements c have been defined as walls (real working code would check!): nelem_start=2817 nelem_end=3776 icount=0 do n=nelem_start,nelem_end icount=icount+1 ipnts(icount)=n enddo c write boundary conditions for wall faces call cg_boco_write_f(index_file,index_base,index_zone,'Walls', + BCWallInviscid,PointList,icount,ipnts,index_bc,ier) c c the above are all face-center locations for the BCs - must indicate this, c otherwise Vertices will be assumed! do ibc=1,index_bc c (the following call positions you in BC_t - it assumes there c is only one Zone_t and one ZoneBC_t - real working code would check!) call cg_goto_f(index_file,index_base,ier,'Zone_t',1, + 'ZoneBC_t',1,'BC_t',ibc,'end') call cg_gridlocation_write_f(FaceCenter,ier) enddo c close CGNS file call cg_close_f(index_file,ier)
Note that we assume here that we know in advance the element numbers associated with each of the boundaries. We have written these element numbers as a PointList, but, because they are in order, we could just as easily have used PointRange instead. In that case, only two ipnts values would be needed, equal to nelem_start and nelem_end, and icount would be 2. Finally, note that the GridLocation_t node under BC_t must be written using the API call cg_goto_f (which positions you correctly in the tree) followed by cg_gridlocation_write_f.
Note that the use of ElementList and ElementRange (recommended in previous versions of CGNS) has been deprecated and should not be used in new code. These are still accepted, but will be internally replaced with the appropriate values of PointList/PointRange and GridLocation_t.
A portion of the layout of the CGNS file for the ZoneBC_t node and its children is shown below. The ZoneBC_t node lies directly under Zone_t.
The three figures, showing the general layout of a CGNS file for an unstructured grid, the layout of additional Elements_t boundary face nodes, and the layout at and below the ZoneBC_t node, taken together, constitute the entire layout of the file.


SRR TENNEY ELL ETP I TSP PY TERE TEN PRET TT EL BAST PT GE REI
AN EXPERIMENTAL INVESTIGATION OF SPHERICAL CAP BUBBLES IN LIQUIDS
Robert E. Sundell
1971
A Dissertation Presented to the Faculty of the Graduate School of Yale University in Candidacy for the Degree of
Doctor of Philosophy
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.


| DOSE: |
30 mg |
oral |
2C-C |
(powder / crystals) |
| |
20 mg |
oral |
2C-E |
(powder / crystals) |
| |
|
oral |
Dimenhydrinate |
(pill / tablet) |
I combined 30mg of 2C-C with 20mg of 2C-E. I was going into unknown territory. I took a precautionary Dramamine along with the dose.
Set and Setting: I was excited to be experimenting with the combination. I stayed in my apartment the entire time.
The come-up was very jittery; far more so than either compound had been alone (I had taken 50mg 2C-C and 20mg 2C-E on two separate occasions).
I had an intense hour or so that must have been the combination peak. Everything was morphing out of control - which was cool, except that I felt too tense and jittery to enjoy it. I could feel the relaxing effect of the 2C-C, but it was almost as if it were in the background. I don't know how it's possible to feel both tense and relaxed, but I did. My mind raced out of control; I wasn't freaking out, but I didn't feel like I was really thinking, either. This frenetic thought pattern led to no insight.
The rest of the trip was indistinguishable from my previous 2C-E trip. The 2C-C didn't seem to have any lasting effect.
Overall, I think this combination is unnecessary. 2C-C is a decent substance in its own right, but doesn't seem to add anything useful to the 2C-E experience.
Perhaps 40mg 2C-C and 10mg 2C-E would have been better.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


Ask the Ruby Novice: Arrays vs. Hashes
Or, what I learned in week 3 at Dev Bootcamp
So this week we covered arrays and hashes. You may be saying, what the ? Well, let me fill you in: arrays and hashes are Ruby objects that hold collections. You may still be saying, what the ? Well let me fill you in some more: computers use collections to keep track of things. What kind of things? Everything. Take a look at some baseball stats:
What is this? This is Babe Ruth's career stat line. Babe Ruth was the greatest baseball player to ever live. How do I know this? Because he has a candy bar named after him.
Anyway, The top line are his career totals, the second line are his 162 game averages, and the third line gives the abbreviation for each stat. (R = runs scored; H = hits, doubles, triples, home runs, RBIs, you get the idea.)
Now let's say we want to program a computer to hold each of Babe's career stats in such a way that we could access them when desired. A great way to do that would be to utilize a hash, which can store pairs of information, like this:
See the code? The stat abbreviations serve as the keys, and the stat totals serve as the values. The last line of code will display on the screen Babe's total runs scored ("R", which is 2,174). We could access any of Babe's stats like this. Also, this hash could store a lot more information. We could track all of Babe's stats. We could track anything!
Arrays are another type of collection object in Ruby, which are simpler than hashes. Arrays track a group of objects and automatically assign ID numbers (called indexes) to each object.
Let's say you have a bunch of numbers and want to determine which number is the smallest. An array would do the job:
The above code contains an array of several numbers, then displays on the screen the smallest number in the array (that's what the .min does). So -3 will display on the screen.
The array is not as dynamic as the hash, and it also takes longer for the array code to run than the hash code (because the .min method has to cycle through the entire array to determine which number is the smallest, while in the hash code all the computer has to do is locate a specific hash). But arrays are used often to collect and manipulate data. In fact, you could store arrays inside hashes, and hashes inside arrays! Hello! Maybe we will get into that next time.
Ruby novice Phil signing off. Good night and God bless America.


class: title-slide, left, middle background-image: url("images/tidymodels.svg") background-position: 85% 50% background-size: 30% background-color: #F9F8F3 .pull-left[ # Model Tuning ## Max Kuhn ### New York R Conference ### Repo: [https://github.com/topepo/2021-nyr-workshop](https://github.com/topepo/https://github.com/topepo/2021-nyr-workshop) ] --- layout: false class: inverse, middle, center # [`tidymodels.org`](https://www.tidymodels.org/) # _Tidy Modeling with R_ ([`tmwr.org`](https://www.tmwr.org/)) --- # Tuning parameters These are model or preprocessing parameters that are important but cannot be estimated directly form the data. Some examples: .pull-left[ * Tree depth in decision trees. * Number of neighbors in a K-nearest neighbor model. * Activation function (e.g. sigmoidal, ReLu) in neural networks. * Number of PCA components to retain ] .pull-right[ * Covariance/correlation matrix structure in mixed models. * Data distribution in survival models. * Spline degrees of freedom. ] --- # Optimizng tuning parameters The main approach is to try different values and measure their performance. This can lead us to good values for these parameters. The main two classes of optimization models are: * _Grid search_ where a pre-defined set of candidate values are tested. * _Iterative search_ methods suggest/estimate new values of candidate parameters to evaluate. Once the value(s) of the parameter(s) are determine, a model can be finalized but fitting the model to the entire training set. --- # Measuring tuning paramters We need performance metrics to tell us which candidate values are good and which are not. Using the test set, or simply re-predicting the training set, are very bad ideas. Since tuning parameters often control complexity, they can often lead to [_overfitting_](https://www.tmwr.org/tuning.html#overfitting-bad). * This is where the model does very well on the training set but poorly on new data. Using _resampling_ to estimate performance can help identify parameters that lead to overfitting. The cost is computational time. --- # Overfitting with a support vector machine  --- # Choosing tuning parameters Let's take our previous model and add a few changes: ```r lm_spec <- linear_reg() %>% set_engine("lm") chi_rec <- recipe(ridership ~ ., data = chi_train) %>% step_date(date, features = c("dow", "year")) %>% step_holiday(date) %>% update_role(date, new_role = "id") %>% step_dummy(all_nominal_predictors()) %>% step_zv(all_predictors()) %>% step_normalize(all_numeric_predictors()) %>% step_corr(all_numeric_predictors(), threshold = 0.9) chi_wflow <- workflow() %>% add_model(lm_spec) %>% add_recipe(chi_rec) ``` --- # Use regularizaed regression ```r lm_spec <- linear_reg() %>% * set_engine("glmnet") chi_rec <- recipe(ridership ~ ., data = chi_train) %>% step_date(date, features = c("dow", "year")) %>% step_holiday(date) %>% update_role(date, new_role = "id") %>% step_dummy(all_nominal_predictors()) %>% step_zv(all_predictors()) %>% step_normalize(all_numeric_predictors()) %>% step_corr(all_numeric_predictors(), threshold = 0.9) chi_wflow <- workflow() %>% add_model(lm_spec) %>% add_recipe(chi_rec) ``` --- # Add model parameters ```r lm_spec <- * linear_reg(penalty, mixture) %>% set_engine("glmnet") chi_rec <- recipe(ridership ~ ., data = chi_train) %>% step_date(date, features = c("dow", "year")) %>% step_holiday(date) %>% update_role(date, new_role = "id") %>% step_dummy(all_nominal_predictors()) %>% step_zv(all_predictors()) %>% step_normalize(all_numeric_predictors()) %>% step_corr(all_numeric_predictors(), threshold = 0.9) chi_wflow <- workflow() %>% add_model(lm_spec) %>% add_recipe(chi_rec) ``` --- # Mark them for tuning ```r lm_spec <- * linear_reg(penalty = tune(), mixture = tune()) %>% set_engine("glmnet") chi_rec <- recipe(ridership ~ ., data = chi_train) %>% step_date(date, features = c("dow", "year")) %>% step_holiday(date) %>% update_role(date, new_role = "id") %>% step_dummy(all_nominal_predictors()) %>% step_zv(all_predictors()) %>% step_normalize(all_numeric_predictors()) %>% step_corr(all_numeric_predictors(), threshold = 0.9) chi_wflow <- workflow() %>% add_model(lm_spec) %>% add_recipe(chi_rec) ``` --- # Remove unneeded step ```r lm_spec <- linear_reg(penalty = tune(), mixture = tune()) %>% set_engine("glmnet") chi_rec <- recipe(ridership ~ ., data = chi_train) %>% step_date(date, features = c("dow", "year")) %>% step_holiday(date) %>% update_role(date, new_role = "id") %>% step_dummy(all_nominal_predictors()) %>% step_zv(all_predictors()) %>% step_normalize(all_numeric_predictors()) chi_wflow <- workflow() %>% add_model(lm_spec) %>% add_recipe(chi_rec) ``` --- # Add a spline step (just for demonstration) ```r lm_spec <- linear_reg(penalty = tune(), mixture = tune()) %>% set_engine("glmnet") chi_rec <- recipe(ridership ~ ., data = chi_train) %>% step_date(date, features = c("dow", "year")) %>% step_holiday(date) %>% update_role(date, new_role = "id") %>% step_dummy(all_nominal_predictors()) %>% step_zv(all_predictors()) %>% * step_ns(temp, deg_free = tune()) %>% step_normalize(all_numeric_predictors()) chi_wflow <- workflow() %>% add_model(lm_spec) %>% add_recipe(chi_rec) ``` --- # Grid search This is the most basic (but very effective) way for tuning models. tidymodels has pre-defined information on tuning parameters, such as their type, range, transformations, etc. A grid can be created manually or automatically. The `parameters()` function extracts the tuning parameters and the info. The `grid_*()` functions can make a grid. --- # Manual grid - get parameters .pull-left[ ```r chi_wflow %>% parameters() ``` This type of object can be updated (e.g. to change the ranges, etc) ] .pull-right[ ``` ## Collection of 3 parameters for tuning ## ## identifier type object ## penalty penalty nparam[+] ## mixture mixture nparam[+] ## deg_free deg_free nparam[+] ``` ] --- # Manual grid - create grid .pull-left[ ```r set.seed(2) grid <- chi_wflow %>% parameters() %>% grid_latin_hypercube(size = 25) grid ``` This is a type of _space-filling design_. It tends to do much better than random grids and is (usually) more efficient than regular grids. ] .pull-right[ ``` ## # A tibble: 25 × 3 ## penalty mixture deg_free ## <dbl> <dbl> <int> ## 1 0.124 0.309 2 ## 2 0.0000000474 0.269 5 ## 3 0.0000000101 0.810 4 ## 4 0.0000140 0.527 11 ## 5 0.172 0.897 3 ## 6 0.0000329 0.701 3 ## # … with 19 more rows ``` ] --- # The results .pull-left[ ```r set.seed(2) grid <- chi_wflow %>% parameters() %>% grid_latin_hypercube(size = 25) grid %>% ggplot(aes(penalty, mixture, col = deg_free)) + geom_point(cex = 4) + scale_x_log10() ``` Note that `penalty` was generated in log-10 units. ] .pull-right[  ] --- # Grid search The `tune_*()` functions can be used to tune models. `tune_grid()` is pretty representative of their syntax (and is similar to `last_fit()`): ```r ctrl <- control_grid(save_pred = TRUE) set.seed(9) chi_res <- chi_wflow %>% tune_grid(resamples = chi_rs, grid = grid, control = ctrl) # 'grid' = integer for automatic grids chi_res ``` ``` ## # Tuning results ## # Sliding period resampling ## # A tibble: 16 × 5 ## splits id .metrics .notes .predictions ## <list> <chr> <list> <list> <list> ## 1 <split [5463/14]> Slice01 <tibble [50 × 7]> <tibble [0 × 1]> <tibble [350 × 7]> ## 2 <split [5467/14]> Slice02 <tibble [50 × 7]> <tibble [0 × 1]> <tibble [350 × 7]> ## 3 <split [5467/14]> Slice03 <tibble [50 × 7]> <tibble [0 × 1]> <tibble [350 × 7]> ## 4 <split [5467/14]> Slice04 <tibble [50 × 7]> <tibble [0 × 1]> <tibble [350 × 7]> ## 5 <split [5467/14]> Slice05 <tibble [50 × 7]> <tibble [0 × 1]> <tibble [350 × 7]> ## 6 <split [5467/14]> Slice06 <tibble [50 × 7]> <tibble [0 × 1]> <tibble [350 × 7]> ## # … with 10 more rows ``` --- # Grid results ```r autoplot(chi_res) ```  --- # ENHANCE ```r autoplot(chi_res, metric = "rmse") + ylim(c(1.7, 1.85)) ```  --- # Returning results ```r collect_metrics(chi_res) ``` ``` ## # A tibble: 50 × 9 ## penalty mixture deg_free .metric .estimator mean n std_err .config ## <dbl> <dbl> <int> <chr> <chr> <dbl> <int> <dbl> <chr> ## 1 0.124 0.309 2 rmse standard 2.11 16 0.266 Preprocessor… ## 2 0.124 0.309 2 rsq standard 0.924 16 0.0249 Preprocessor… ## 3 0.491 0.817 2 rmse standard 2.95 16 0.402 Preprocessor… ## 4 0.491 0.817 2 rsq standard 0.848 16 0.0502 Preprocessor… ## 5 0.0000000474 0.269 5 rmse standard 1.74 16 0.241 Preprocessor… ## 6 0.0000000474 0.269 5 rsq standard 0.947 16 0.0213 Preprocessor… ## # … with 44 more rows ``` ```r collect_metrics(chi_res, summarize = FALSE) ``` ``` ## # A tibble: 800 × 8 ## id penalty mixture deg_free .metric .estimator .estimate .config ## <chr> <dbl> <dbl> <int> <chr> <chr> <dbl> <chr> ## 1 Slice01 0.124 0.309 2 rmse standard 4.20 Preprocessor01_Mode… ## 2 Slice01 0.124 0.309 2 rsq standard 0.722 Preprocessor01_Mode… ## 3 Slice02 0.124 0.309 2 rmse standard 1.96 Preprocessor01_Mode… ## 4 Slice02 0.124 0.309 2 rsq standard 0.961 Preprocessor01_Mode… ## 5 Slice03 0.124 0.309 2 rmse standard 2.30 Preprocessor01_Mode… ## 6 Slice03 0.124 0.309 2 rsq standard 0.915 Preprocessor01_Mode… ## # … with 794 more rows ``` --- # Metrics over time .pull-left[ ```r chi_res %>% add_date_to_metrics("date") %>% filter(.metric == "rmse") %>% ggplot(aes(x = date, y = .estimate, group = .config, col = .config)) + geom_line(show.legend = FALSE, alpha = .3) + labs(y = "RMSE") ``` ] .pull-right[  ] --- # Picking a parameter combination You can create a tibble of your own or use one of the `tune::select_*()` functions: ```r show_best(chi_res, metric = "rmse") ``` ``` ## # A tibble: 5 × 9 ## penalty mixture deg_free .metric .estimator mean n std_err .config ## <dbl> <dbl> <int> <chr> <chr> <dbl> <int> <dbl> <chr> ## 1 1.01e- 8 0.810 4 rmse standard 1.72 16 0.241 Preprocessor03_M… ## 2 3.29e- 5 0.701 3 rmse standard 1.73 16 0.241 Preprocessor05_M… ## 3 3.11e- 3 0.869 15 rmse standard 1.74 16 0.242 Preprocessor12_M… ## 4 2.41e- 4 0.949 7 rmse standard 1.74 16 0.240 Preprocessor09_M… ## 5 5.41e-10 0.633 6 rmse standard 1.74 16 0.241 Preprocessor07_M… ``` ```r smallest_rmse <- select_best(chi_res, metric = "rmse") smallest_rmse ``` ``` ## # A tibble: 1 × 4 ## penalty mixture deg_free .config ## <dbl> <dbl> <int> <chr> ## 1 0.0000000101 0.810 4 Preprocessor03_Model1 ``` --- # Updating the workflow and final fit ```r chi_wflow <- chi_wflow %>% finalize_workflow(smallest_rmse) test_res <- chi_wflow %>% last_fit(split = chi_split) test_res ``` ``` ## # Resampling results ## # Manual resampling ## # A tibble: 1 × 6 ## splits id .metrics .notes .predictions .workflow ## <list> <chr> <list> <list> <list> <list> ## 1 <split [5684/14]> train/test split <tibble [2 × 4]> <tibbl… <tibble [14… <workflo… ``` The workflow, fit using the training set: ```r final_chi_wflow <- test_res$.workflow[[1]] ``` --- # Two-week test set results ```r collect_metrics(test_res) ``` ``` ## # A tibble: 2 × 4 ## .metric .estimator .estimate .config ## <chr> <chr> <dbl> <chr> ## 1 rmse standard 0.976 Preprocessor1_Model1 ## 2 rsq standard 0.990 Preprocessor1_Model1 ``` ```r # Resampling results show_best(chi_res, metric = "rmse", n = 1) ``` ``` ## # A tibble: 1 × 9 ## penalty mixture deg_free .metric .estimator mean n std_err .config ## <dbl> <dbl> <int> <chr> <chr> <dbl> <int> <dbl> <chr> ## 1 0.0000000101 0.810 4 rmse standard 1.72 16 0.241 Preprocessor… ``` --- # Two-week test set results .pull-left[ ```r test_res %>% collect_predictions() %>% ggplot(aes(ridership, .pred)) + geom_abline(col = "green", lty = 2) + geom_point(cex = 3, alpha = 0.5) + coord_obs_pred() ``` ] .pull-right[  ] --- # Two-week test set results .pull-left[ ```r library(lubridate) test_values <- final_chi_wflow %>% augment(testing(chi_split)) %>% mutate(day = wday(date, label = TRUE)) test_values %>% ggplot(aes(ridership, .pred, col = day)) + geom_abline(col = "green", lty = 2) + geom_point(cex = 3, alpha = 0.5) + coord_obs_pred() + scale_color_brewer(palette = "Dark2") ``` ] .pull-right[  ] --- # Two-week test set results .pull-left[ ```r test_values %>% ggplot(aes(date, ridership)) + geom_point(aes(col = day), cex = 3, alpha = 0.5) + geom_line(aes(y = .pred)) + scale_color_brewer(palette = "Dark2") ``` ] .pull-right[  ]


{if ('' !== $name)} [t]Dear {$name}[/t] {else} [t]Dear Sir or Madam[/t] {/if}
{if $accept_offer} {if $initiated_by == 'seller'}[t]Buyer {$sender_consultant_name} from {$r.buyer_name} has accepted your former offer to sell the candidate {$r.candidate_uid}.[/t]
{else}[t]Seller {$sender_consultant_name} from {$r.seller_name} has accepted your former offer to buy the candidate {$r.candidate_uid}.[/t]
{/if}[t]This is the offer that was accepted:[/t]
{elseif $reject_offer} {if $initiated_by == 'seller'}[t]Buyer {$sender_consultant_name} from {$r.buyer_name} has rejected your former offer to sell the candidate {$r.candidate_uid}.[/t]
{else}[t]Seller {$sender_consultant_name} from {$r.seller_name} has rejected your former offer to buy the candidate {$r.candidate_uid}.[/t]
{/if} {if $r.status == 'negotiation_rejected'} [t]The request has been closed for further negotiation.[/t] {else} [t]The request is still open for further negotiation as not all offers within this request have been rejected yet. Use Mail history in cvCentral application to display the list of offers which are still open for negotiation.[/t] {/if}[t]This is the offer which was rejected:[/t]
{elseif $counteroffer} {if $initiated_by == 'seller'}[t]Seller {$sender_consultant_name} from {$r.seller_name} proposes a counteroffer to your former offer to buy the candidate {$r.candidate_uid}.[/t]
{else}[t]Buyer {$sender_consultant_name} from {$r.buyer_name} proposes a counteroffer to your former offer to sell the candidate {$r.candidate_uid}.[/t]
{/if} {else}[t]{$buyer_consultant_name} from {$r.buyer_name} wants to buy details of the candidate {$r.candidate_uid}.[/t]
{/if} {if (!$accept_offer && !$reject_offer)}{if $initiated_by == 'seller'} [t]The seller proposes following offer:[/t] {else} [t]The buyer proposes following offer:[/t] {/if}
{/if}| [t]Candidate nr.[/t]: | {$r.candidate_uid} |
| [t]Payment scheme[/t]: | {if $o.payment_type == 'direct'}[t]direct payment[/t]{/if} {if $o.payment_type == 'fee'}[t]percentage fee[/t]{/if} |
| [t]Payment amount[/t]: | {if $o.payment_type == 'direct'} €{$o.payment_amount} {/if} {if $o.payment_type == 'fee'} {$o.payment_fee_percentage}% {if $o.payment_amount}([t]from expected fee[/t] €{$o.payment_amount}){/if} {/if} |
| {if $initiated_by == 'seller'} [t]Message from the buyer[/t]: {else} [t]Message from the seller[/t]: {/if} | "{$o.message_reply|escape}" |
| {if $initiated_by == 'seller'} [t]Message from the seller[/t]: {else} [t]Message from the buyer[/t]: {/if} | "{$o.message|escape}" |
[t]Please use cvCentral application to accept or reject the offer or to propose a counteroffer.[/t]
{/if}[t]Kind regards[/t]
[t]cvCentral Team[/t]


 They say, "Raise taxes!" You say whatever is the opposite and you will win.
- Mike "in Tokyo" Rogers
From:
http://www.lewrockwell.com/rogers/rogers238.html


Malaysia's last Sumatran rhinoceros dies
The 25-year-old female rhino, named Iman, who has been cared for in a wildlife reserve since her capture in 2014, died of cancer in the state of Sabah on the island of Borneo.
The last Sumatran rhinoceros in Malaysia died on Saturday, leaving the smallest species of rhino, which once roamed across Asia, surviving in small numbers mostly in Indonesia.
The 25-year-old female rhino, named Iman, who has been cared for in a wildlife reserve since her capture in 2014, died of cancer in the state of Sabah on the island of Borneo.
"Iman's death came rather sooner than we had expected, but we knew that she was starting to suffer significant pain," said Augustine Tuuga, director of the Sabah Wildlife Department.
The Sumatran rhino was declared extinct in the wild in Malaysia in 2015. Malaysia's last male Sumatran rhino died in May this year.
The species has now almost disappeared from the wild, and conservationists estimate that only about 30 to 80 Sumatran rhinos survive, mostly on the Indonesian island of Sumatra and on the Indonesian side of Borneo.
Their isolation, caused by habitat loss and poaching, means they rarely breed and may become extinct in a matter of decades, according to conservation group International Rhino Foundation.
Since 2011, Malaysia has tried to breed the species in captivity through in-vitro fertilization, but without success.


Try out our Premium Member services: Virtual Legal Assistant, Query Alert Service and an ad-free experience. Free for one month and pay only if you like it.
IN THE HIGH COURT OF JUDICATURE AT PATNA Criminal Miscellaneous No.37113 of 2012 ====================================================== 1. Ajay Sah 2. Raghubir Sah 3. Shambhu Prasad @ Shambhu Sah .... .... Petitioner/s Versus The State Of Bihar .... .... Opposite Party/s ====================================================== CORAM: HONOURABLE MR. JUSTICE DINESH KUMAR SINGH ORAL ORDER
02/ 10-10-2012 Heard learned counsels for the petitioners and the State.
The petitioners are apprehending their arrest in Motihari Town P.S. Case No. 174 of 2012 registered for the offences punishable under Sections 420 and 201 of the Indian Penal Code lodged by the Sub-divisional Judicial Magistrate, Motihari.
It is alleged that earlier the petitioners were accused in a case registered under Sections 379, 420 of the Indian Penal Code, 15 of Pollution Act, 1966 and 40 of Bihar Minor Minerals Concession Rules, 1972 when Adapur P.S. Case No. 05 of 2012 was registered when the petitioners filed anticipatory bail application vide A.B.P. No. 363 of 2012 but subsequently the petitioners surrendered and got regular bail. The surrender -cum- bail Patna High Court Cr.Misc. No.37113 of 2012 (2) dt.10-10-2012 2/3 applications have been brought on record as Annexure-5 and 5/1 which were filed on 14.02.2012 and 15.02.2012, which suggest that the petitioners made averment in the petition that they are going to withdraw the anticipatory bail application. The applications for withdrawal of anticipatory bail were filed before the learned Sessions Judge on 14.02.2012 and 15.02.2012, which have been brought on record as Annexure-4 and 4/1. This case was registered with the accusation that without withdrawing the anticipatory bail applications the regular bail applications were filed and regular bail was obtained.
Since the withdrawal applications were filed for seeking regular bail, in view of this Court, it is a fit case for consideration of regular bail by the learned court below, preferably on the same day, if the petitioners surrender before the learned court below within a period of eight weeks from today in connection with Motihari Town P.S. Case No. 174 of 2012 pending in the court of learned CJM, Motihari.
With the aforesaid observation, this Patna High Court Cr.Misc. No.37113 of 2012 (2) dt.10-10-2012 3/3 application is disposed of.
Let the order be transmitted to the learned court below through fax at the cost of the petitioners.
(Dinesh Kumar Singh, J.) DKS/ .


Shared Expense Tracker
Total to pay
£0
Download CSV
CSV from local store
Josh Balance
£0.00
Income
+£0.00
Expense
-£0.00
History
Add new transaction
Text
Amount
Enter Date
Add transaction
Other Balance
£0.00
Income
+£0.00
Expense
-£0.00
History
Add new transaction
Text
Amount
Enter Date
Add transaction


The class had our first exposure to bootstrap. We used bootstrap to style a generic website. Please notice that, compared to some of my other projects, this one actually could pass for a website (thank you bootstrap!)
On this project we were starting to incorporate css stylesheets, and images into our very basic web pages
This was our first foray into building multi-page websites. All the links work, but styling is nonexsistent. Par for the course for day two.


This is an example of the CSS overide code to have a full screen div in your Troop Webhost site.

When you do this make the
"Maximum Width"
of the section
1920 pixels


China wants US trade deal but ‘not afraid’ to fight: Xi
- Advertisement -
by Laurent Thomet and Helen Roxburgh
President Xi Jinping said Friday that China wants to reach an initial trade deal with the United States but is “not afraid” to fight back when necessary.
It is rare for Xi to speak so directly about the trade war, and his comments come two days after US President Donald Trump complained that Beijing had not made sufficient concessions so far, making him reluctant to conclude a bargain.
The world’s two biggest economies have been locked in a bruising trade conflict for more than a year, hitting each other with volleys of tariffs on hundreds of billions of dollars worth of goods.
- Advertisement -
“As we always said we don’t want to start the trade war but we are not afraid,” Xi told former US officials and other foreign dignitaries at a meeting at Beijing’s Great Hall of the People.
“When necessary we will fight back but we have been working actively to try not to have a trade war,” he told the group, which included former US secretary of state Henry Kissinger, former US treasury secretary Henry Paulson and former Australian prime minister Kevin Rudd.
Trump on October 11 announced a “phase one” deal resolving important US grievances about Chinese trade and currency practices.
But more than a month later, the two sides have yet to finalise the text of any agreement. American officials want large purchases of US farm exports.
Top trade negotiators spoke on the phone on Saturday in what the Chinese commerce ministry described as “constructive” discussions on a preliminary deal.
China has insisted on a rollback of existing tariffs, which Trump said he has not agreed to.
“I can tell you this. China would much rather make a trade deal than I would,” Trump said Wednesday.
“I don’t think they’re stepping up to the level that I want.”
‘China’s not going to budge’
US Congress approval this week of legislation supporting pro-democracy protesters in Hong Kong has also cast a shadow on the negotiations.
“We want to work for a phase-one agreement on the basis of mutual respect and equality,” Xi told the foreign visitors, who were in town for the Bloomberg New Economy Forum.
The Chinese leader warned that the trade talks “may affect the future prospects of the world economy” but China holds a “positive attitude”.
Diana Choyleva, chief economist at Enodo Economics, said Xi’s comments do not mean that Beijing is about to go on the offensive.
“But it certainly reaffirms my expectation that China’s not going to budge,” Choyleva told AFP at the New Economy Forum.
“The negotiation style and lack of trust that Trump has created … has made him (Xi) …very determined that there is no point to really give up much,” she said.
Dire warnings
Kissinger warned at the forum on Thursday that the trade war could potentially lead to armed conflict if it goes unresolved.
If the two sides keep seeing “every issue in the world in terms of conflict” with each other, it could be “dangerous for mankind”, he said.
Paulson warned that the two countries were heading in the wrong direction.
The former treasury secretary warned of growing barriers on visas and the movement of people, restrictions on trade and technology, and that the ongoing economic tensions would “leave our countries and the entire world worse off.”
© Agence France-Presse
- Advertisement -


KA Lite is software that allows users without Internet access to engage with Khan Academy videos and exercises in completely offline settings, bringing the flipped classroom model to some of the most remote areas in the world. Users can track their progress through videos and exercises, and coaches can log in and check up on their progress to identify which areas the students need the most help in. If KA Lite ever reaches an Internet connection, it can sync this usage data with the KA Lite Hub, an online data repository that allows project administrators to view data and manage accounts remotely of offline deployments.
//probably will not need this part with all the ref links? it will go in sidebar ^^


If you or someone you know are in immediate danger, please call 911.
The Trevor Project - 1-866-488-7386
The Trevor Project also has a live chatroom or text options avaliable in order to help you. They are avaliable 24/7.
National Suicide Prevention Lifeline-1-800-273-8255
The National Suicide Prevention Lifeline is a national network of local crisis centers that provides free and confidential emotional support to people in suicidal crisis or emotional distress 24 hours a day, 7 days a week.
Provides housing programs and other resources to LGBT+ youth. Link includes more shelters for Arkansas, California, Colorado, Florida, Georgia, Illinois, Indiana, Iowa, Maine, Massachusetts, Michigan, Minnesota, New Jersey, New York, North Carolina, Oklahoma, Oregon, Pennsylvania, Texas, Utah, Vermont, Washington, and Wisconsin. You can also find resources for LGBT+ families and ways to volunteer/help on their site.
They have a 24/7 phoneline, a live chat, email, and a forum. They are LGBT+ friendly and all information will remain confidential.
National Coalition for the Homeless
The National Coalition for Homelessness has resources for homeless or soon to be homeless people, as well as advocacy programs and ways you can help. They are LGBT+ friendly.
Lambda Legal, a LGBT+ advocacy group put together this list of resources by state. Note this is mostly for the major cities of each state. You can find their main site here if you are in search of legal help.
A directory of LGBT+ centers, including an interactive & searchable map with centers throughout the US as well as 3 internationally. You can add centers here.
Financial aid provided by LGBT Support.
RAINN/National Sexual Assault Hotline
Hotline: 1-800-656-4673, or use their online chat service. Avaliable 24/7.
New York City Anti-Violence Project
Report violence you experience or witness to their free and confidential 24-hour bilingual (English/Spanish) hotline at<PHONE_NUMBER> where you can speak with a trained counselor and seek support, or you can report violence anonymously online, or to ask for a counselor to reach out to you.
Serves transgender and gender non-conforming surviviors of domestic and sexual violence, provides referrals to local counselers.
Hotline-<PHONE_NUMBER>. Bilingual, supports LGBTQ, polyamourous, and kink/BDSM survivors.
Hotline-<PHONE_NUMBER>. Serves LGBT survivors of abuse; can provide local referrals.


We emphasize the facts by spreading knowledge through a professional standpoint. Driven by studies through research organizations such as MAPS (Multidisciplinary Association for Psychedelic Studies), Johns Hopkins Medicine, and the Naropa Alliance for Psychedelic Studies, we hope to point out how psychedelics could be used for PTSD, depression, personality growth, and spirituality. We welcome anyone to help, but thrive on the passionate ones.
"A super-worthy group: Boulder Psychedelic Club"
— Rick Strassman
"Fantastic site design!
— Bryan Connelly
Boulder, CO, USA | Hello@Psychedeliclub.com


Tsunamis of Low Quality Scientific Publications
-
With "peer-reviewed" web journals, it is now easier than ever to
publish low quality scientific articles
-
There are 2M scientific articles published every year, most
or closed source and closed data
-
A large fraction of those will be found to be irreproducible
-
Instead of accelerating, science is slowing down


| elementary_algorithms {pomp} | R Documentation |
In pomp, elementary algorithms perform POMP model operations. These operations do not themselves estimate parameters, though they may be instrumental in inference methods.
There are six elementary algorithms in pomp:
simulate
which simulates from the joint distribution of latent and observed variables,
pfilter
, which performs a simple particle filter operation,
wpfilter
, which performs a weighted particle filter operation,
probe
, which computes a suite of user-specified summary statistics on actual and simulated data,
spect
, which performs a power-spectral density function computation on actual and simulated data,
trajectory
, which iterates or integrates the deterministic skeleton according to whether the latter is a (discrete-time) map or a (continuous-time) vectorfield.
Help pages detailing each elementary algorithm component are provided.
basic model components, workhorse functions, estimation algorithms.
More on pomp elementary algorithms:
kalman
,
pfilter()
,
pomp-package
,
probe()
,
simulate()
,
spect()
,
trajectory()
,
wpfilter()


If people like you frequent our store, we'd be sure to lose all our customers.


Describes an elliptical conical joint limit. Note that very small or highly elliptical limit cones may result in jitter.
More...
#include <PxJointLimit.h>
|
| PxReal | yAngle |
| | the maximum angle from the Y axis of the constraint frame. More...
|
| |
| PxReal | zAngle |
| | the maximum angle from the Z-axis of the constraint frame. More...
|
| |
| PxReal | restitution |
| | Controls the amount of bounce when the joint hits a limit. More...
|
| |
| PxReal | bounceThreshold |
| |
| PxReal | stiffness |
| | if greater than zero, the limit is soft, i.e. a spring pulls the joint back to the limit More...
|
| |
| PxReal | damping |
| | if spring is greater than zero, this is the damping of the limit spring More...
|
| |
| PxReal | contactDistance |
| | the distance inside the limit value at which the limit will be considered to be active by the solver. As this value is made larger, the limit becomes active more quickly. It thus becomes less likely to violate the extents of the limit, but more expensive. More...
|
| |
Describes an elliptical conical joint limit. Note that very small or highly elliptical limit cones may result in jitter.
- See also
- PxD6Joint PxSphericalJoint
◆ PxJointLimitCone() [1/2]
| PxJointLimitCone::PxJointLimitCone |
( |
PxReal |
yLimitAngle, |
|
|
PxReal |
zLimitAngle, |
|
|
PxReal |
contactDist = -1.0f |
|
) |
| |
|
inline |
Construct a cone hard limit.
- Parameters
-
| [in] | yLimitAngle | The limit angle from the Y-axis of the constraint frame |
| [in] | zLimitAngle | The limit angle from the Z-axis of the constraint frame |
| [in] | contactDist | The distance from the limit at which it becomes active. Default is the lesser of 0.1 radians, and 0.49 * the lower of the limit angles |
- See also
- PxJointLimitParameters
References PxJointLimitParameters::contactDistance, and PxMin().
◆ PxJointLimitCone() [2/2]
| PxJointLimitCone::PxJointLimitCone |
( |
PxReal |
yLimitAngle, |
|
|
PxReal |
zLimitAngle, |
|
|
const PxSpring & |
spring |
|
) |
| |
|
inline |
Construct a cone soft limit.
- Parameters
-
| [in] | yLimitAngle | The limit angle from the Y-axis of the constraint frame |
| [in] | zLimitAngle | The limit angle from the Z-axis of the constraint frame |
| [in] | spring | The stiffness and damping of the limit spring |
- See also
- PxJointLimitParameters
References damping, spring, and stiffness.
◆ isValid()
| PX_INLINE bool PxJointLimitCone::isValid |
( |
| ) |
const |
|
inline |
◆ yAngle
| PxReal PxJointLimitCone::yAngle |
the maximum angle from the Y axis of the constraint frame.
Unit: Angular: Radians Range: Angular: (0,PI)
Default: PI/2
◆ zAngle
| PxReal PxJointLimitCone::zAngle |
the maximum angle from the Z-axis of the constraint frame.
Unit: Angular: Radians Range: Angular: (0,PI)
Default: PI/2
The documentation for this class was generated from the following file:


I speedcube. I used to participate in WCA (World Cube Association) competitions pretty frequently, and organized some as well. In my youth, I held few state records in Iowa and was top 100 NR for 5x5.
I speedcube. I used to participate in WCA (World Cube Association) competitions pretty frequently, and organized some as well. In my youth, I held few state records in Iowa and was top 100 NR for 5x5.


Socket.IO-Client-Swift
Socket.IO-client for iOS/OS X.
Example
import SocketIO
let socket = SocketIOClient(socketURL: URL(string: "http://localhost:8080")!, config: [.log(true), .forcePolling(true)])
socket.on(clientEvent: .connect) {data, ack in
print("socket connected")
}
socket.on("currentAmount") {data, ack in
if let cur = data[0] as? Double {
socket.emitWithAck("canUpdate", cur).timingOut(after: 0) {data in
socket.emit("update", ["amount": cur + 2.50])
}
ack.with("Got your currentAmount", "dude")
}
}
socket.connect()
Objective-C Example
@import SocketIO;
NSURL* url = [[NSURL alloc] initWithString:@"http://localhost:8080"];
SocketIOClient* socket = [[SocketIOClient alloc] initWithSocketURL:url config:@{@"log": @YES, @"forcePolling": @YES}];
[socket on:@"connect" callback:^(NSArray* data, SocketAckEmitter* ack) {
NSLog(@"socket connected");
}];
[socket on:@"currentAmount" callback:^(NSArray* data, SocketAckEmitter* ack) {
double cur = [[data objectAtIndex:0] floatValue];
[[socket emitWithAck:@"canUpdate" with:@[@(cur)]] timingOutAfter:0 callback:^(NSArray* data) {
[socket emit:@"update" withItems:@[@{@"amount": @(cur + 2.50)}]];
}];
[ack with:@[@"Got your currentAmount, ", @"dude"]];
}];
[socket connect];
Features
- Supports socket.io 1.0+
- Supports binary
- Supports Polling and WebSockets
- Supports TLS/SSL
- Can be used from Objective-C
Installation
Requires Swift 3/Xcode 8.x
If you need swift 2.3 use the swift2.3 tag (Pre-Swift 3 support is no longer maintained)
If you need swift 2.2 use 7.x (Pre-Swift 3 support is no longer maintained)
If you need Swift 2.1 use v5.5.0 (Pre-Swift 2.2 support is no longer maintained)
If you need Swift 1.2 use v2.4.5 (Pre-Swift 2 support is no longer maintained)
If you need Swift 1.1 use v1.5.2. (Pre-Swift 1.2 support is no longer maintained)
Manually (iOS 7+)
- Copy the Source folder into your Xcode project. (Make sure you add the files to your target(s))
- If you plan on using this from Objective-C, read this on exposing Swift code to Objective-C.
Swift Package Manager
Add the project as a dependency to your Package.swift:
import PackageDescription
let package = Package(
name: "YourSocketIOProject",
dependencies: [
.Package(url: "https://github.com/socketio/socket.io-client-swift", majorVersion: 9)
]
)
Then import import SocketIO
.
Carthage
Add this line to your Cartfile
:
github "socketio/socket.io-client-swift" ~> 9.0.0 # Or latest version
Run carthage update --platform ios,macosx
.
CocoaPods 1.0.0 or later
Create Podfile
and add pod 'Socket.IO-Client-Swift'
:
use_frameworks!
target 'YourApp' do
pod 'Socket.IO-Client-Swift', '~> 9.0.0' # Or latest version
end
Install pods:
$ pod install
Import the module:
Swift:
import SocketIO
Objective-C:
@import SocketIO;
CocoaSeeds
Add this line to your Seedfile
:
github "socketio/socket.io-client-swift", "v9.0.0", :files => "Source/*.swift" # Or latest version
Run seed install
.
Docs
Detailed Example
A more detailed example can be found here
An example using the Swift Package Manager can be found here
License
MIT


Learning How to Program Conversationally
Experiments
Voice Only
Voice + Program
Voice + Conversation
Voice + Text + Conversation
Text + Conversation


This page demonstrates form validation using AngularJS and javascipt, with a regular expression test for each input box. Both input boxes are character restricted, using AngularJS custom directives. The submit button only becomes active when both input boxes are valid. The submit button is used to send a http post request to a test server, with the reply message displayed when a response is received.


breindycodes
Documentation for the progress of my coding journey
about
.
progress
.
projects
.
guides
.
what’s next
.
About
more content coming soon, please stay tuned.
back


{% extends "../../layout.html" %} {% block sectionClasses %}plugins hasBreadCrumb plugins-spincast-jackson-json{% endblock %} {% block meta_title %}Plugins - Spincast Jackson Json{% endblock %} {% block meta_description %}Spincast Jackson Json plugin provides Json functionalities using Jackson.{% endblock %} {% block scripts %} {% endblock %} {% block body %}
This plugin provides Json
functionalities
using Jackson. It contains an implementation
of the JsonManager
interface : SpincastJsonManager.
Make sure you read the JsonObjects section for more information. The Jackson documentation can also be very useful.
If you use the spincast-default
artifact and the standard Bootstrapper,
this plugin is already installed by default so you have nothing to do!
If you start from scratch, using the spincast-core
artifact, you can use the
plugin by :
1. Adding this Maven artifact to your project:
<dependency> <groupId>org.spincast</groupId> <artifactId>spincast-plugins-jackson-json</artifactId> <version>{{spincast.spincastCurrrentVersion}}</version> </dependency>
2. Installing the provided SpincastJacksonJsonPluginModule module to your Guice context.
The class implementing the SpincastPlugin interface is SpincastJacksonJsonPlugin.
json()
Route Handlers
access to Json
functionalitites.
Example :
public void myRouteHandler(DefaultRequestContext context) { // Creates a new JsonObject JsonObject obj = context.json().create(); //... }
This add-on is already installed by default on the Request Context type.
You can bind a SpincastJsonManagerConfig implementation to tweak the default configurations used by the components this plugin provides. By default, the SpincastJsonManagerConfigDefault class is used as the implementation.
Jackson allows some configuration when serializing and deserializing an object.
Most of those configurations
are defined using annotations.
You can annotate the objects directly, or you can use mix-ins
.
If you don't minds annotating your objects with Jackson specific annotations,
this is maybe the simplest thing to do. For example, let's say you have a User
class that has two fields, name
and title
, and you don't want
to keep the title
field when you
serialize an instance of this class:
public class User implements User { private String name; private String title; @Override public String getName() { return this.name; } @Override public void setName(String name) { this.name = name; } @Override public String getTitle() { return this.title; } @Override public void setTitle(String title) { this.title = title; } }
To ignore the title
field to be included during the serialization, you can simply
annotate the getTitle()
method with
@JsonIgnore
:
public class User implements User { private String name; private String title; @Override public String getName() { return this.name; } @Override public void setName(String name) { this.name = name; } @Override @JsonIgnore public String getTitle() { return this.title; } @Override public void setTitle(String title) { this.title = title; } }
If you serialize an instance of this class using the Json Manager
,
only the name
property would be kept:
User user = new User(); user.setName("Stromgol"); user.setTitle("alien"); String jsonString = getJsonManager().toJsonString(user); assertEquals("{\"name\":\"Stromgol\"}", jsonString);
Many developers (us included) don't like to pollute their model classes with too many annotations. Lucky us, Jackson provides a way to configure objects from the outside, without annotating the objects directly, by using what is called mix-ins annotations.
Let's start with the same User
class, without any Jackson annotations:
public class User implements User { private String name; private String title; @Override public String getName() { return this.name; } @Override public void setName(String name) { this.name = name; } @Override public String getTitle() { return this.title; } @Override public void setTitle(String title) { this.title = title; } }
To use Json mix-ins in a Spincast application, you first need to create the mix-in abstract class. Interfaces work too, but only to annotate methods, not fields.
An example mix-in for our User
objects:
public abstract class UserMixin implements User { // Ignore this property! @Override @JsonIgnore public abstract String getTitle(); }
As you can see, a mix-in extends the class/interface to configure, and adds the Jackson annotations on the overriding fields or methods declarations.
Once the mix-in is defined, you have to register it, in your custom Guice module:
public class AppModule extends SpincastDefaultGuiceModule { public AppModule(String[] mainArgs) { super(mainArgs); } @Override protected void configure() { super.configure(); bindJsonMixins(); //... } protected void bindJsonMixins() { Multibinder<JsonMixinInfo> jsonMixinsBinder = Multibinder.newSetBinder(binder(), JsonMixinInfo.class); jsonMixinsBinder.addBinding().toInstance(new JsonMixinInfo(User.class, UserMixin.class)); } }
Explanation :
JsonMixinInfo
instance, which specifies the class to configure, and the
class of the mix-in used to configure it.
With this in place, Spincast will automatically configure Jackson so it uses your mix-ins, and
you would have the exact same result than annotating the User
class directly:
User user = new User(); user.setName("Stromgol"); user.setTitle("alien"); String jsonString = getJsonManager().toJsonString(user); assertEquals("{\"name\":\"Stromgol\"}", jsonString);