Object ID FunctionsZOLTAN_NUM_OBJ_FNGeometry-Based Functions
ZOLTAN_OBJ_LIST_FN
ZOLTAN_FIRST_OBJ_FN (deprecated)
ZOLTAN_NEXT_OBJ_FN (deprecated)
ZOLTAN_PART_MULTI_FN or ZOLTAN_PART_FNZOLTAN_NUM_GEOM_FNGraph-Based Functions
ZOLTAN_GEOM_MULTI_FN or ZOLTAN_GEOM_FNZOLTAN_NUM_EDGES_MULTI_FN or ZOLTAN_NUM_EDGES_FNHypergraph-Based Functions
ZOLTAN_EDGE_LIST_MULTI_FN or ZOLTAN_EDGE_LIST_FNZOLTAN_HG_SIZE_CS_FNTree-Based Functions
ZOLTAN_HG_CS_FN
ZOLTAN_HG_SIZE_EDGE_WTS_FN
ZOLTAN_HG_EDGE_WTS_FN
ZOLTAN_NUM_FIXED_OBJ_FN
ZOLTAN_FIXED_OBJ_LIST_FNZOLTAN_NUM_COARSE_OBJ_FNHierarchical Partitioning Functions
ZOLTAN_COARSE_OBJ_LIST_FN
ZOLTAN_FIRST_COARSE_OBJ_FN
ZOLTAN_NEXT_COARSE_OBJ_FN
ZOLTAN_NUM_CHILD_FN
ZOLTAN_CHILD_LIST_FN
ZOLTAN_CHILD_WEIGHT_FNZOLTAN_HIER_NUM_LEVELS_FN
ZOLTAN_HIER_PART_FN
ZOLTAN_HIER_METHOD_FN
| C and C++: | typedef int ZOLTAN_NUM_OBJ_FN (void *data, int *ierr); |
| FORTRAN: | FUNCTION Get_Num_Obj(data, ierr)
INTEGER(Zoltan_INT) :: Get_Num_Obj <type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(OUT) :: ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_NUM_OBJ_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| ierr | Error code to be set by function. |
| Returned Value: | |
| int | The number of objects that are assigned to the processor. |
| C and C++: | typedef void ZOLTAN_OBJ_LIST_FN (void *data, int num_gid_entries, int num_lid_entries, ZOLTAN_ID_PTR global_ids, ZOLTAN_ID_PTR local_ids, int wgt_dim, float *obj_wgts, int *ierr); |
| FORTRAN: | SUBROUTINE Get_Obj_List(data, num_gid_entries, num_lid_entries, global_ids, local_ids,
wgt_dim, obj_wgts, ierr)
<type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(IN) :: num_gid_entries, num_lid_entries INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: global_ids INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: local_ids INTEGER(Zoltan_INT), INTENT(IN) :: wgt_dim REAL(Zoltan_FLOAT), INTENT(OUT), DIMENSION(*) :: obj_wgts INTEGER(Zoltan_INT), INTENT(OUT) :: ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_OBJ_LIST_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| num_gid_entries | The number of array entries used to describe a single global ID. This value is the maximum value over all processors of the parameter NUM_GID_ENTRIES. |
| num_lid_entries | The number of array entries used to describe a single local ID. This value is the maximum value over all processors of the parameter NUM_LID_ENTRIES. (It should be zero if local ids are not used.) |
| global_ids | Upon return, an array of unique global IDs for all objects assigned to the processor. |
| local_ids | Upon return, an array of local IDs, the meaning of which can be determined by the application, for all objects assigned to the processor. (Optional.) |
| wgt_dim | The number of weights associated with an object (typically 1), or 0 if weights are not requested. This value is set through the parameter OBJ_WEIGHT_DIM. |
| obj_wgts | Upon return, an array of object weights. Weights for object i are stored in obj_wgts[(i-1)*wgt_dim:i*wgt_dim-1]. If wgt_dim=0, the return value of obj_wgts is undefined and may be NULL. |
| ierr | Error code to be set by function. |
| C and C++: | typedef int ZOLTAN_FIRST_OBJ_FN (void *data, int num_gid_entries, int num_lid_entries, ZOLTAN_ID_PTR first_global_id, ZOLTAN_ID_PTR first_local_id, int wgt_dim, float *first_obj_wgt, int *ierr); |
| FORTRAN: | FUNCTION Get_First_Obj(data, num_gid_entries, num_lid_entries, first_global_id, first_local_id,
wgt_dim, first_obj_wgt, ierr)
INTEGER(Zoltan_INT) :: Get_First_Obj <type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(IN) :: num_gid_entries, num_lid_entries INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: first_global_id INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: first_local_id INTEGER(Zoltan_INT), INTENT(IN) :: wgt_dim REAL(Zoltan_FLOAT), INTENT(OUT), DIMENSION(*) :: first_obj_wgt INTEGER(Zoltan_INT), INTENT(OUT) :: ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_FIRST_OBJ_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| num_gid_entries | The number of array entries used to describe a single global ID. This value is the maximum value over all processors of the parameter NUM_GID_ENTRIES. |
| num_lid_entries | The number of array entries used to describe a single local ID. This value is the maximum value over all processors of the parameter NUM_LID_ENTRIES. (It should be zero if local ids are not used.) |
| first_global_id | The returned value of the global ID for the first object; the value is ignored if there are no objects. |
| first_local_id | The returned value of the local ID for the first object; the value is ignored if there are no objects. |
| wgt_dim | The number of weights associated with an object (typically 1), or 0 if weights are not requested. This value is set through the parameter OBJ_WEIGHT_DIM. |
| first_obj_wgt | Upon return, the first object's weights; an array of length wgt_dim. Undefined if wgt_dim=0. |
| ierr | Error code to be set by function. |
| Returned Value: | |
| 1 | If first_global_id and first_local_id contain valid IDs of the first object. |
| 0 | If no objects are available. |
| C and C++: | typedef int ZOLTAN_NEXT_OBJ_FN (void * data, int num_gid_entries, int num_lid_entries, ZOLTAN_ID_PTR global_id, ZOLTAN_ID_PTR local_id, ZOLTAN_ID_PTR next_global_id, ZOLTAN_ID_PTR next_local_id, int wgt_dim, float *next_obj_wgt, int *ierr); |
| FORTRAN: | FUNCTION Get_Next_Obj(data, num_gid_entries, num_lid_entries, global_id, local_id, next_global_id,
next_local_id, wgt_dim, next_obj_wgt, ierr)
INTEGER(Zoltan_INT) :: Get_Next_Obj <type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(IN) :: num_gid_entries, num_lid_entries INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: global_id INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: local_id INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: next_global_id INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: next_local_id INTEGER(Zoltan_INT), INTENT(IN) :: wgt_dim REAL(Zoltan_FLOAT), INTENT(OUT), DIMENSION(*) :: next_obj_wgt INTEGER(Zoltan_INT), INTENT(OUT) :: ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_NEXT_OBJ_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| num_gid_entries | The number of array entries used to describe a single global ID. This value is the maximum value over all processors of the parameter NUM_GID_ENTRIES. |
| num_lid_entries | The number of array entries used to describe a single local ID. This value is the maximum value over all processors of the parameter NUM_LID_ENTRIES. (It should be zero if local ids are not used.) |
| global_id | The global ID of the previous object. |
| local_id | The local ID of the previous object. |
| next_global_id | The returned value of the global ID for the next object; the value is ignored if there are no more objects. |
| next_local_id | The returned value of the local ID for the next object; the value is ignored if there are no more objects. |
| wgt_dim | The number of weights associated with an object (typically 1), or 0 if weights are not requested. This value is set through the parameter OBJ_WEIGHT_DIM. |
| next_obj_wgt | Upon return, the next object's weights; an array of length wgt_dim. Undefined if wgt_dim=0. |
| ierr | Error code to be set by function. |
| Returned Value: | |
| 1 | If next_global_id and next_local_id contain valid IDs of the next object. |
| 0 | If no more objects are available. |
| C and C++: | typedef void ZOLTAN_PART_MULTI_FN (void *data, int num_gid_entries, int num_lid_entries, int num_obj, ZOLTAN_ID_PTR global_ids, ZOLTAN_ID_PTR local_ids, int *parts, int *ierr); |
| FORTRAN: | SUBROUTINE Get_Part_Multi(data, num_gid_entries, num_lid_entries, num_obj, global_ids, local_ids,
ierr)
<type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(IN) :: num_gid_entries, num_lid_entries, num_obj INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: global_ids INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: local_ids INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: parts INTEGER(Zoltan_INT), INTENT(OUT) :: ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_PART_MULTI_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| num_gid_entries | The number of array entries used to describe a single global ID. This value is the maximum value over all processors of the parameter NUM_GID_ENTRIES. |
| num_lid_entries | The number of array entries used to describe a single local ID. This value is the maximum value over all processors of the parameter NUM_LID_ENTRIES. (It should be zero if local ids are not used.) |
| num_obj | The number of object IDs in arrays global_ids and local_ids. |
| global_ids | The global IDs of the objects for which the part numbers should be returned. |
| local_ids | The local IDs of the objects for which the part numbers should be returned. (Optional.) |
| parts | Upon return, an array of part numbers corresponding to the global and local IDs. |
| ierr | Error code to be set by function. |
| C and C++: | typedef int ZOLTAN_PART_FN (void *data, int num_gid_entries, int num_lid_entries, ZOLTAN_ID_PTR global_id, ZOLTAN_ID_PTR local_id, int *ierr); |
| FORTRAN: | FUNCTION Get_Part(data, num_gid_entries, num_lid_entries, global_id, local_id,
ierr)
INTEGER(Zoltan_INT) :: Get_Part <type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(IN) :: num_gid_entries, num_lid_entries INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: global_id INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: local_id INTEGER(Zoltan_INT), INTENT(OUT) :: ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_PART_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| num_gid_entries | The number of array entries used to describe a single global ID. This value is the maximum value over all processors of the parameter NUM_GID_ENTRIES. |
| num_lid_entries | The number of array entries used to describe a single local ID. This value is the maximum value over all processors of the parameter NUM_LID_ENTRIES. (It should be zero if local ids are not used.) |
| global_id | The global ID of the object for which the part number should be returned. |
| local_id | The local ID of the object for which the part number should be returned. |
| ierr | Error code to be set by function. |
| Returned Value: | |
| int | The part number for the object identified by global_id and local_id. |
| C and C++: | typedef int ZOLTAN_NUM_GEOM_FN (void *data, int *ierr); |
| FORTRAN: | FUNCTION Get_Num_Geom(data, ierr)
INTEGER(Zoltan_INT) :: Get_Num_Geom <type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(OUT) :: ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_NUM_GEOM_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| ierr | Error code to be set by function. |
| Returned Value: | |
| int | The number of values needed to express the geometry of an object. |
| C and C++: | typedef void ZOLTAN_GEOM_MULTI_FN (void *data, int num_gid_entries, int num_lid_entries, int num_obj, ZOLTAN_ID_PTR global_ids, ZOLTAN_ID_PTR local_ids, int num_dim, double *geom_vec, int *ierr); |
| FORTRAN: | SUBROUTINE Get_Geom_Multi(data, num_gid_entries,
num_lid_entries, num_obj, global_ids, local_ids, num_dim, geom_vec, ierr)
<type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(IN) :: num_gid_entries, num_lid_entries INTEGER(Zoltan_INT), INTENT(IN) :: num_obj, num_dim INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: global_ids INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: local_ids REAL(Zoltan_DOUBLE), INTENT(OUT), DIMENSION(*) :: geom_vec INTEGER(Zoltan_INT), INTENT(OUT) :: ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_GEOM_MULTI_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| num_gid_entries | The number of array entries used to describe a single global ID. This value is the maximum value over all processors of the parameter NUM_GID_ENTRIES. |
| num_lid_entries | The number of array entries used to describe a single local ID. This value is the maximum value over all processors of the parameter NUM_LID_ENTRIES. (It should be zero if local ids are not used.) |
| num_obj | The number of object IDs in arrays global_ids and local_ids. |
| global_ids | Array of global IDs of objects whose geometry values should be returned. |
| local_ids | Array of local IDs of objects whose geometry values should be returned. (Optional.) |
| num_dim | Number of coordinate entries per object (typically 1, 2, or 3). |
| geom_vec | Upon return, an array containing geometry values. For object i (specified by global_ids[i*num_gid_entries] and local_ids[i*num_lid_entries], i=0,1,...,num_obj-1), coordinate values should be stored in geom_vec[i*num_dim:(i+1)*num_dim-1]. |
| ierr | Error code to be set by function. |
| C and C++: | typedef void ZOLTAN_GEOM_FN (void *data, int num_gid_entries, int num_lid_entries, ZOLTAN_ID_PTR global_id, ZOLTAN_ID_PTR local_id, double *geom_vec, int *ierr); |
| FORTRAN: | SUBROUTINE Get_Geom(data, num_gid_entries, num_lid_entries, global_id, local_id, geom_vec,
ierr)
<type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(IN) :: num_gid_entries, num_lid_entries INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: global_id INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: local_id REAL(Zoltan_DOUBLE), INTENT(OUT), DIMENSION(*) :: geom_vec INTEGER(Zoltan_INT), INTENT(OUT) :: ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_GEOM_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| num_gid_entries | The number of array entries used to describe a single global ID. This value is the maximum value over all processors of the parameter NUM_GID_ENTRIES. |
| num_lid_entries | The number of array entries used to describe a single local ID. This value is the maximum value over all processors of the parameter NUM_LID_ENTRIES. (It should be zero if local ids are not used.) |
| global_id | The global ID of the object whose geometry values should be returned. |
| local_id | The local ID of the object whose geometry values should be returned. |
| geom_vec | Upon return, an array containing geometry values. |
| ierr | Error code to be set by function. |
| C and C++: | typedef void ZOLTAN_NUM_EDGES_MULTI_FN (void *data, int num_gid_entries, int num_lid_entries, int num_obj, ZOLTAN_ID_PTR global_ids, ZOLTAN_ID_PTR local_ids, int *num_edges, int *ierr); |
| FORTRAN: | SUBROUTINE Get_Num_Edges_Multi(data, num_gid_entries, num_lid_entries, num_obj, global_ids, local_ids, num_edges,
ierr)
INTEGER(Zoltan_INT) :: Get_Num_Edges <type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(IN) :: num_gid_entries, num_lid_entries, num_obj INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: global_ids INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: local_ids INTEGER(Zoltan_INT), INTENT(OUT),DIMENSION(*) :: num_edges INTEGER(Zoltan_INT), INTENT(OUT) :: ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_NUM_EDGES_MULTI_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| num_gid_entries | The number of array entries used to describe a single global ID. This value is the maximum value over all processors of the parameter NUM_GID_ENTRIES. |
| num_lid_entries | The number of array entries used to describe a single local ID. This value is the maximum value over all processors of the parameter NUM_LID_ENTRIES. (It should be zero if local ids are not used.) |
| num_obj | The number of object IDs in arrays global_ids and local_ids. |
| global_ids | Array of global IDs of objects whose number of edges should be returned. |
| local_ids | Array of local IDs of objects whose number of edges should be returned. (Optional.) |
| num_edges | Upon return, an array containing numbers of edges. For object i (specified by global_ids[i*num_gid_entries] and local_ids[i*num_lid_entries], i=0,1,...,num_obj-1), the number of edges should be stored in num_edges[i]. |
| ierr | Error code to be set by function. |
| C and C++: | typedef int ZOLTAN_NUM_EDGES_FN (void *data, int num_gid_entries, int num_lid_entries, ZOLTAN_ID_PTR global_id, ZOLTAN_ID_PTR local_id, int *ierr); |
| FORTRAN: | FUNCTION Get_Num_Edges(data, num_gid_entries, num_lid_entries, global_id, local_id,
ierr)
INTEGER(Zoltan_INT) :: Get_Num_Edges <type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(IN) :: num_gid_entries, num_lid_entries INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: global_id INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: local_id INTEGER(Zoltan_INT), INTENT(OUT) :: ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_NUM_EDGES_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| num_gid_entries | The number of array entries used to describe a single global ID. This value is the maximum value over all processors of the parameter NUM_GID_ENTRIES. |
| num_lid_entries | The number of array entries used to describe a single local ID. This value is the maximum value over all processors of the parameter NUM_LID_ENTRIES. (It should be zero if local ids are not used.) |
| global_id | The global ID of the object for which the number of edges should be returned. |
| local_id | The local ID of the object for which the number of edges should be returned. |
| ierr | Error code to be set by function. |
| Returned Value: | |
| int | The number of edges for the object identified by global_id and local_id. |
| C and C++: | typedef void ZOLTAN_EDGE_LIST_MULTI_FN (void *data, int num_gid_entries, int num_lid_entries, int num_obj, ZOLTAN_ID_PTR global_ids, ZOLTAN_ID_PTR local_ids, int *num_edges, ZOLTAN_ID_PTR nbor_global_id, int *nbor_procs, int wgt_dim, float *ewgts, int *ierr); |
| FORTRAN: | SUBROUTINE Get_Edge_List_Multi(data, num_gid_entries, num_lid_entries, num_obj, global_ids, local_ids, num_edges,
nbor_global_id, nbor_procs, wgt_dim, ewgts, ierr)
<type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(IN) :: num_gid_entries, num_lid_entries, num_obj INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: global_ids INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: local_ids INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: num_edges INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: nbor_global_id INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: nbor_procs INTEGER(Zoltan_INT), INTENT(IN) :: wgt_dim REAL(Zoltan_FLOAT), INTENT(OUT), DIMENSION(*) :: ewgts INTEGER(Zoltan_INT), INTENT(OUT) :: ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_EDGE_LIST_MULTI_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| num_gid_entries | The number of array entries used to describe a single global ID. This value is the maximum value over all processors of the parameter NUM_GID_ENTRIES. |
| num_lid_entries | The number of array entries used to describe a single local ID. This value is the maximum value over all processors of the parameter NUM_LID_ENTRIES. (It should be zero if local ids are not used.) |
| num_obj | The number of object IDs in arrays global_ids and local_ids. |
| global_ids | Array of global IDs of objects whose edge lists should be returned. |
| local_ids | Array of local IDs of objects whose edge lists should be returned. (Optional.) |
| num_edges | An array containing numbers of edges for each object in global_ids. For object i (specified by global_ids[i*num_gid_entries] and local_ids[i*num_lid_entries], i=0,1,...,num_obj-1), the number of edges is stored in num_edges[i]. |
| nbor_global_id | Upon return, an array of global IDs of objects sharing edges with the objects specified in global_ids. For object i (specified by global_ids[i*num_gid_entries] and local_ids[i*num_lid_entries], i=0,1,...,num_obj-1), edges are stored in nbor_global_id[sum*num_gid_entries] to nbor_global_id[(sum+num_edges[i])*num_gid_entries-1], where sum = the sum of num_edges[j] for j=0,1,...,i-1. |
| nbor_procs | Upon return, an array of processor IDs that identifies where the neighboring objects reside. For neighboring object i (stored in nbor_global_id[i*num_gid_entries]), the processor owning the neighbor is stored in nbor_procs[i]. |
| wgt_dim | The number of weights associated with an edge (typically 1), or 0 if edge weights are not requested. This value is set through the parameter EDGE_WEIGHT_DIM. |
| ewgts | Upon return, an array of edge weights, where ewgts[i*wgt_dim:(i+1)*wgt_dim-1]
corresponds to the weights for the ith edge. If wgt_dim=0, the return value of ewgts is undefined and may be NULL. |
| ierr | Error code to be set by function. |
| C and C++: | typedef void ZOLTAN_EDGE_LIST_FN (void *data, int num_gid_entries, int num_lid_entries, ZOLTAN_ID_PTR global_id, ZOLTAN_ID_PTR local_id, ZOLTAN_ID_PTR nbor_global_id, int *nbor_procs, int wgt_dim, float *ewgts, int *ierr); |
| FORTRAN: | SUBROUTINE Get_Edge_List(data, num_gid_entries, num_lid_entries, global_id, local_id,
nbor_global_id, nbor_procs, wgt_dim, ewgts, ierr)
<type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(IN) :: num_gid_entries, num_lid_entries INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: global_id INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: local_id INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: nbor_global_id INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: nbor_procs INTEGER(Zoltan_INT), INTENT(IN) :: wgt_dim REAL(Zoltan_FLOAT), INTENT(OUT), DIMENSION(*) :: ewgts INTEGER(Zoltan_INT), INTENT(OUT) :: ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_EDGE_LIST_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| num_gid_entries | The number of array entries used to describe a single global ID. This value is the maximum value over all processors of the parameter NUM_GID_ENTRIES. |
| num_lid_entries | The number of array entries used to describe a single local ID. This value is the maximum value over all processors of the parameter NUM_LID_ENTRIES. (It should be zero if local ids are not used.) |
| global_id | The global ID of the object for which an edge list should be returned. |
| local_id | The local ID of the object for which an edge list should be returned. |
| nbor_global_id | Upon return, an array of global IDs of objects sharing edges with the given object. |
| nbor_procs | Upon return, an array of processor IDs that identifies where the neighboring objects reside. |
| wgt_dim | The number of weights associated with an edge (typically 1), or 0 if edge weights are not requested. This value is set through the parameter EDGE_WEIGHT_DIM. |
| ewgts | Upon return, an array of edge weights, where ewgts[i*wgt_dim:(i+1)*wgt_dim-1]
corresponds to the weights for the ith edge. If wgt_dim=0, the return value of ewgts is undefined and may be NULL. |
| ierr | Error code to be set by function. |
| C and C++: | typedef void ZOLTAN_HG_SIZE_CS_FN (void *data, int *num_lists, int *num_pins, int *format, int *ierr); |
| FORTRAN: | SUBROUTINE Get_HG_Size_CS(data, num_lists, num_pins,
format, ierr)
<type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(OUT) :: num_lists INTEGER(Zoltan_INT), INTENT(OUT) :: num_pins INTEGER(Zoltan_INT), INTENT(OUT) :: format INTEGER(Zoltan_INT), INTENT(OUT) :: ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
The other format is compressed vertex (ZOLTAN_COMPRESSED_VERTEX). In this format a list of vertex global IDs is provided. Then a list of pins ordered by vertex and then by hyperedge is provided. The pin ID in this case is the global ID of the hyperedge in which the pin appears. In both formats, an array must be provided pointing to the start in the list of pins where each hyperedge or vertex begins.
The purpose of this query function is to tell Zoltan in which format the
application will supply the hypergraph, how many vertices and hyperedges
there will be, and how many pins. The actual hypergraph is supplied
with a query function of the type
ZOLTAN_HG_CS_FN_TYPE.
This query function is required by all applications using the hypergraph methods
of Zoltan (unless they are using the
graph-based
functions with hypergraph code instead).
| Function Type: | ZOLTAN_HG_SIZE_CS_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| num_lists | Upon return, the number of vertices (if using compressed vertex storage) or hyperedges (if using compressed hyperedge storage) that will be supplied to Zoltan by the application process. |
| num_pins | Upon return, the number of pins (connections between vertices and hyperedges) that will be supplied to Zoltan by the application process. |
| format | Upon return, the format in which the application process will provide the hypergraph to Zoltan. The options are ZOLTAN_COMPRESSED_EDGE and ZOLTAN_COMPRESSED_VERTEX. |
| ierr | Error code to be set by function. |
| C and C++: | typedef void ZOLTAN_HG_CS_FN (void *data, int num_gid_entries, int num_vtx_edge, int num_pins, int format, ZOLTAN_ID_PTR vtxedge_GID, int *vtxedge_ptr, ZOLTAN_ID_PTR pin_GID, int *ierr); |
| FORTRAN: | SUBROUTINE Get_HG_CS(data,
num_gid_entries, num_vtx_edge, num_pins, format,
vtxedge_GID, vtxedge_ptr, pin_GID, ierr)
<type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(IN) :: num_gid_entries, num_vtx_edge, num_pins, format INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: vtxedge_GID INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: vtxedge_ptr INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: pin_GID INTEGER(Zoltan_INT), INTENT(OUT) :: ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_HG_CS_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| num_gid_entries | The number of array entries used to describe a single global ID. This value is the maximum value over all processors of the parameter NUM_GID_ENTRIES. |
| num_vtx_edge | The number of global IDs that is expected to appear on return in vtxedge_GID. This may correspond to either vertices or (hyper-)edges. |
| num_pins | The number of pins that is expected to appear on return in pin_GID. |
| format | If format is ZOLTAN_COMPRESSED_EDGE, Zoltan expects that hyperedge global IDs will be returned in vtxedge_GID, and that vertex global IDs will be returned in pin_GIDs. If it is ZOLTAN_COMPRESSED_VERTEX, then vertex global IDs are expected to be returned in vtxedge_GID and hyperedge global IDs are expected to be returned in pin_GIDs. |
| vtxedge_GID | Upon return, a list of num_vtx_edge global IDs. |
| vtxedge_ptr | Upon return, this array contains num_vtx_edge integers such that the number of pins specified for hyperedge j (if format is ZOLTAN_COMPRESSED_EDGE) or vertex j (if format is ZOLTAN_COMPRESSED_VERTEX) is vtxedge_ptr[j+1]-vtxedge_ptr[j]. If format is ZOLTAN_COMPRESSED_EDGE, vtxedge_ptr[j]*num_gid_entries is the index into the array pin_GID where edge j's pins (vertices belonging to edge j) begin; if format is ZOLTAN_COMPRESSED_VERTEX, vtxedge_ptr[j]*num_gid_entries is the index into the array pin_GID where vertex j's pins (edges to which vertex j belongs) begin. Array indices begin at zero. |
| pin_GID | Upon return, a list of num_pins global IDs. This is the list of the pins contained in the hyperedges or vertices listed in vtxedge_GID. |
| ierr | Error code to be set by function. |
|
Compressed hyperedge storage: vtxedge_GID = {1, 2, 3} vtxedge_ptr = {0, 2, 4} pin_GID = {30, 40, 20, 30, 10, 50} Compressed vertex storage: vtxedge_GID = {10, 20, 30, 40, 50} vtxedge_ptr = {0, 1, 2, 4, 5} pin_GID = {3, 2, 1, 2, 1, 3} |
| C and C++: | typedef void ZOLTAN_HG_SIZE_EDGE_WTS_FN (void *data, int *num_edges, int *ierr); |
| FORTRAN: | SUBROUTINE Get_HG_Size_Edge_Wts(data, num_edges, ierr)
<type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(OUT) :: num_edges INTEGER(Zoltan_INT), INTENT(OUT) :: ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_HG_SIZE_EDGE_WTS_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| num_edges | Upon return, the number of hyperedges for which edge weights will be supplied. |
| ierr | Error code to be set by function. |
| C and C++: | typedef void ZOLTAN_HG_EDGE_WTS_FN (void *data, int num_gid_entries, int num_lid_entries, int num_edges, int edge_weight_dim, ZOLTAN_ID_PTR edge_GID, ZOLTAN_ID_PTR edge_LID, float *edge_weight, int *ierr); |
| FORTRAN: | SUBROUTINE Get_HG_Edge_Wts(data, num_gid_entries, num_lid_entries, num_edges, edge_weight_dim, edge_GID, edge_LID, edge_weight,
ierr)
<type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(IN) :: num_gid_entries, num_lid_entries, num_edges, edge_weight_dim INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: edge_GID INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: edge_LID REAL(Zoltan_FLOAT), INTENT(OUT), DIMENSION(*) :: edge_weight INTEGER(Zoltan_INT), INTENT(OUT) :: ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_HG_EDGE_WTS_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| num_gid_entries | The number of array entries used to describe a single global ID. This value is the maximum value over all processors of the parameter NUM_GID_ENTRIES. |
| num_lid_entries | The number of array entries used to describe a single local ID. This value is the maximum value over all processors of the parameter NUM_LID_ENTRIES. (It should be zero if local ids are not used.) |
| num_edges | The number of hyperedges for which edge weights should be supplied in the edge_weight array. |
| edge_weight_dim | The number of weights which should be supplied for each hyperedge. This is also the value of the EDGE_WEIGHT_DIM parameter. |
| edge_GID | Upon return, this array should contain the global IDs of the num_edges hyperedges for which the application is supplying edge weights. |
| edge_LID | Upon return, this array can optionally contain the local IDs of the num_edges hyperedges for which the application is supplying edge weights. |
| edge_weight | Upon return, this array should contain the weights for each edge listed in the edge_GID. If edge_weight_dim is greater than one, all weights for one hyperedge are listed before the weights for the next hyperedge are listed. |
| ierr | Error code to be set by function. |
| C and C++: | typedef int ZOLTAN_NUM_FIXED_OBJ_FN (void *data, int *ierr); |
| FORTRAN: | FUNCTION Get_Num_Fixed_Obj(data, ierr)
INTEGER(Zoltan_INT) :: Get_Num_Fixed_Obj <type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(OUT) :: ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran |
| Function Type: | ZOLTAN_NUM_FIXED_OBJ_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| ierr | Error code to be set by function. |
| Returned Value: | |
| int | The number of objects on this processor that are to be fixed to a specific part. |
| C and C++: | typedef void ZOLTAN_FIXED_OBJ_LIST_FN (void *data, int num_fixed_obj, int num_gid_entries, ZOLTAN_ID_PTR fixed_gids, int *fixed_parts, int *ierr); |
| FORTRAN: | SUBROUTINE Get_Fixed_Obj_List(data, num_fixed_obj, num_gid_entries, fixed_gids, fixed_parts, ierr)
<type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(IN) :: num_fixed_obj INTEGER(Zoltan_INT), INTENT(IN) :: num_gid_entries INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: fixed_gids INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: fixed_parts INTEGER(Zoltan_INT), INTENT(OUT) :: ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
A process should only fix the part of objects that it owns, that is,
objects that it had previously supplied in a
ZOLTAN_OBJ_LIST_FN query function. It is
an error to list the global ID of an object owned by another process.
| Function Type: | ZOLTAN_FIXED_OBJ_LIST_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| num_fixed_obj | The number of objects you will list in the two output arrays. |
| num_gid_entries | The number of array entries used to describe a single global ID. This value is the maximum value over all processors of the parameter NUM_GID_ENTRIES. |
| fixed_gids | Upon return, an array of unique global IDs for all objects assigned to the processor which are to be fixed to a part. |
| fixed_parts | Upon return, an array of part numbers, one for each object listed in the global ID array. These objects will not be migrated from this assigned part. |
| ierr | Error code to be set by function. |
| C and C++: | typedef int ZOLTAN_NUM_COARSE_OBJ_FN (void *data, int *ierr); |
| FORTRAN: | FUNCTION Get_Num_Coarse_Obj(data, ierr)
INTEGER(Zoltan_INT) :: Get_Num_Coarse_Obj <type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(OUT) :: ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_NUM_COARSE_OBJ_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| ierr | Error code to be set by function. |
| Returned Value: | |
| int | The number of objects in the coarse grid. |
| C and C++: | typedef void ZOLTAN_COARSE_OBJ_LIST_FN (void *data, int num_gid_entries, int num_lid_entries, ZOLTAN_ID_PTR global_ids, ZOLTAN_ID_PTR local_ids, int *assigned, int *num_vert, ZOLTAN_ID_PTR vertices, int *in_order, ZOLTAN_ID_PTR in_vertex, ZOLTAN_ID_PTR out_vertex, int *ierr); |
| FORTRAN: | SUBROUTINE Get_Coarse_Obj_List(data, num_gid_entries, num_lid_entries, global_ids, local_ids,
assigned, num_vert, vertices, in_order, in_vertex, out_vertex, ierr)
<type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(IN) :: num_gid_entries, num_lid_entries INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: global_ids INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: local_ids INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: assigned, num_vert, vertices, in_vertex, out_vertex INTEGER(Zoltan_INT), INTENT(OUT) :: in_order, ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_COARSE_OBJ_LIST_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| num_gid_entries | The number of array entries used to describe a single global ID. This value is the maximum value over all processors of the parameter NUM_GID_ENTRIES. |
| num_lid_entries | The number of array entries used to describe a single local ID. This value is the maximum value over all processors of the parameter NUM_LID_ENTRIES. (It should be zero if local ids are not used.) |
| global_ids | Upon return, an array of global IDs of all objects in the coarse grid. |
| local_ids | Upon return, an array of local IDs of all objects in the coarse grid. (Optional.) |
| assigned | Upon return, an array of integers indicating whether or not each object is currently assigned to this processor. A value of 1 indicates it is assigned to this processor; a value of 0 indicates it is assigned to some other processor. For elements that have been refined, it is ignored unless weights are assigned to interior nodes of the tree. |
| num_vert | Upon return, an array containing the number of vertices for each object. |
| vertices | Upon return, an array of global IDs of the vertices of each object. If the number of vertices for objects 0 through i-1 is N, then the vertices for object i are in vertices[N*num_gid_entries: (N+num_vert[i])*num_gid_entries] |
| in_order | Upon return, 1 if the user is providing the objects in the order in which they should be traversed, or 0 if Zoltan should determine the order. |
| in_vertex | Upon return, an array of global IDs of the vertices through which to enter each element in the user provided traversal. It is required only if the user is providing the order for the coarse grid objects (i.e., in_order==1) and allowing Zoltan to select the order of the children in at least one invocation of ZOLTAN_CHILD_LIST_FN. |
| out_vertex | Upon return, an array of global IDs of the vertex through which to exit each element in the user provided traversal. The same provisions hold as for in_vertex. |
| ierr | Error code to be set by function. |
| C and C++: | typedef int ZOLTAN_FIRST_COARSE_OBJ_FN (void *data, int num_gid_entries, int num_lid_entries, ZOLTAN_ID_PTR global_id, ZOLTAN_ID_PTR local_id, int *assigned, int *num_vert, ZOLTAN_ID_PTR vertices, int *in_order, ZOLTAN_ID_PTR in_vertex, ZOLTAN_ID_PTR out_vertex, int *ierr); |
| FORTRAN: | FUNCTION Get_First_Coarse_Obj(data, num_gid_entries, num_lid_entries, global_id, local_id,
assigned, num_vert, vertices, in_order, in_vertex, out_vertex, ierr)
INTEGER(Zoltan_INT) :: Get_First_Coarse_Obj <type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(IN) :: num_gid_entries, num_lid_entries INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: global_id INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: local_id INTEGER(Zoltan_INT), INTENT(OUT) :: assigned, num_vert, in_order, ierr INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: vertices, in_vertex, out_vertex <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_FIRST_COARSE_OBJ_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| num_gid_entries | The number of array entries used to describe a single global ID. This value is the maximum value over all processors of the parameter NUM_GID_ENTRIES. |
| num_lid_entries | The number of array entries used to describe a single local ID. This value is the maximum value over all processors of the parameter NUM_LID_ENTRIES. (It should be zero if local ids are not used.) |
| global_ids | Upon return, the global ID of the first object in the coarse grid. |
| local_ids | Upon return, the local ID of the first object in the coarse grid. (Optional.) |
| assigned | Upon return, an integer indicating whether or not this object is currently assigned to this processor. A value of 1 indicates it is assigned to this processor; a value of 0 indicates it is assigned to some other processor. For elements that have been refined, it is ignored unless weights are assigned to interior nodes of the tree. |
| num_vert | Upon return, the number of vertices for this object. |
| vertices | Upon return, an array of global IDs of the vertices of this object. |
| in_order | Upon return, 1 if the user is providing the objects in the order in which they should be traversed, or 0 if Zoltan should determine the order. |
| in_vertex | Upon return, the vertex through which to enter this element in the user provided traversal. It is required only if the user is providing the order for the coarse grid objects (i.e., in_order==1) and allowing Zoltan to select the order of the children in at least one invocation of ZOLTAN_CHILD_LIST_FN. |
| out_vertex | Upon return, the vertex through which to exit this element in the user provided traversal. The same provisions hold as for in_vertex. |
| ierr | Error code to be set by function. |
| Returned Value: | |
| 1 | If global_id and local_id contain valid IDs of the first object in the coarse grid. |
| 0 | If no coarse grid is available. |
| C and C++: | typedef int ZOLTAN_NEXT_COARSE_OBJ_FN (void *data, int num_gid_entries, int num_lid_entries, ZOLTAN_ID_PTR global_id, ZOLTAN_ID_PTR local_id, ZOLTAN_ID_PTR next_global_id, ZOLTAN_ID_PTR next_local_id, int *assigned, int *num_vert, ZOLTAN_ID_PTR vertices, ZOLTAN_ID_PTR in_vertex, ZOLTAN_ID_PTR out_vertex, int *ierr); |
| FORTRAN: | FUNCTION Get_Next_Coarse_Obj(data, num_gid_entries, num_lid_entries, global_id, local_id,
next_global_id, next_local_id,
assigned, num_vert, vertices, in_vertex, out_vertex, ierr)
INTEGER(Zoltan_INT) :: Get_Next_Coarse_Obj <type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(IN) :: num_gid_entries, num_lid_entries INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: global_id INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: local_id INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: next_global_id INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: next_local_id INTEGER(Zoltan_INT), INTENT(OUT) :: assigned, num_vertex, ierr INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: vertices, in_vertex, out_vertex <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_NEXT_COARSE_OBJ_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| num_gid_entries | The number of array entries used to describe a single global ID. This value is the maximum value over all processors of the parameter NUM_GID_ENTRIES. |
| num_lid_entries | The number of array entries used to describe a single local ID. This value is the maximum value over all processors of the parameter NUM_LID_ENTRIES. (It should be zero if local ids are not used.) |
| global_id | The global ID of the previous object in the coarse grid. |
| local_id | The local ID of the previous object in the coarse grid. |
| next_global_id | Upon return, the global ID of the next object in the coarse grid. |
| next_local_id | Upon return, the local ID of the next object in the coarse grid. |
| assigned | Upon return, an integer indicating whether or not this object is currently assigned to this processor. A value of 1 indicates it is assigned to this processor; a value of 0 indicates it is assigned to some other processor. For elements that have been refined, it is ignored unless weights are assigned to interior nodes of the tree. |
| num_vert | Upon return, the number of vertices for this object. |
| vertices | Upon return, an array of global IDs of the vertices of this object. |
| in_vertex | Upon return, the vertex through which to enter this element in the user provided traversal. It is required only if the user is providing the order for the coarse grid objects (i.e., in_order==1) and allowing Zoltan to select the order of the children in at least one invocation of ZOLTAN_CHILD_LIST_FN. |
| out_vertex | Upon return, the vertex through which to exit this element in the user provided traversal. The same provisions hold as for in_vertex. |
| ierr | Error code to be set by function. |
| Returned Value: | |
| 1 | If global_id and local_id contain valid IDs of the next object in the coarse grid. |
| 0 | If no more objects are available. |
| C and C++: | typedef int ZOLTAN_NUM_CHILD_FN (void *data, int num_gid_entries, int num_lid_entries, ZOLTAN_ID_PTR global_id, ZOLTAN_ID_PTR local_id, int *ierr); |
| FORTRAN: | FUNCTION Get_Num_Child(data, num_gid_entries, num_lid_entries, global_id, local_id,
ierr)
INTEGER(Zoltan_INT) :: Get_Num_Child <type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(IN) :: num_gid_entries, num_lid_entries INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: global_id INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: local_id INTEGER(Zoltan_INT), INTENT(OUT) :: ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_NUM_CHILD_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| num_gid_entries | The number of array entries used to describe a single global ID. This value is the maximum value over all processors of the parameter NUM_GID_ENTRIES. |
| num_lid_entries | The number of array entries used to describe a single local ID. This value is the maximum value over all processors of the parameter NUM_LID_ENTRIES. (It should be zero if local ids are not used.) |
| global_id | The global ID of the object for which the number of children is requested. |
| local_id | The local ID of the object for which the number of children is requested. |
| ierr | Error code to be set by function. |
| Returned Value: | |
| int | The number of children. |
| C and C++: | typedef void ZOLTAN_CHILD_LIST_FN (void *data, int num_gid_entries, int num_lid_entries, ZOLTAN_ID_PTR parent_gid, ZOLTAN_ID_PTR parent_lid, ZOLTAN_ID_PTR child_gids, ZOLTAN_ID_PTR child_lids, int *assigned, int *num_vert, ZOLTAN_ID_PTR vertices, ZOLTAN_REF_TYPE *ref_type, ZOLTAN_ID_PTR in_vertex, ZOLTAN_ID_PTR out_vertex, int *ierr); |
| FORTRAN: | SUBROUTINE Get_Child_List(data, num_gid_entries,
num_lid_entries, parent_gid, parent_lid,
child_gids, child_lids, assigned, num_vert, vertices, ref_type, in_vertex,
out_vertex, ierr)
<type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(IN) :: num_gid_entries, num_lid_entries INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: parent_gid INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: parent_lid INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: child_gids INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: child_lids INTEGER(Zoltan_INT), INTENT(OUT), DIMENSION(*) :: assigned, num_vert, vertices, in_vertex, out_vertex INTEGER(Zoltan_INT), INTENT(OUT) :: ref_type, ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_CHILD_LIST_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| num_gid_entries | The number of array entries used to describe a single global ID. This value is the maximum value over all processors of the parameter NUM_GID_ENTRIES. |
| num_lid_entries | The number of array entries used to describe a single local ID. This value is the maximum value over all processors of the parameter NUM_LID_ENTRIES. (It should be zero if local ids are not used.) |
| parent_gid | The global ID of the object whose children are requested. |
| parent_lid | The local ID of the object whose children are requested. |
| child_gids | Upon return, an array of global IDs of all children of this object. |
| child_lids | Upon return, an array of local IDs of all children of this object. (Optional.) |
| assigned | Upon return, an array of integers indicating whether or not each child is currently assigned to this processor. A value of 1 indicates it is assigned to this processor; a value of 0 indicates it is assigned to some other processor. For children that have been further refined, it is ignored unless weights are assigned to interior nodes of the tree. |
| num_vert | Upon return, an array containing the number of vertices for each object. |
| vertices | Upon return, an array of global IDs of the vertices of each object. If the number of vertices for objects 0 through i-1 is N, then the vertices for object i are in vertices[N*num_gid_entries: (N+num_vert[i])*num_gid_entries] |
| ref_type | Upon return, a value indicating what type of refinement was used to create the children. This determines how the children will be ordered. The values currently supported are: |
| ZOLTAN_TRI_BISECT Bisection of triangles. | |
| ZOLTAN_QUAD_QUAD Quadrasection of quadrilaterals. | |
| ZOLTAN_HEX3D_OCT Octasection of hexahedra. | |
| ZOLTAN_OTHER_REF All other forms of refinement. | |
| ZOLTAN_IN_ORDER Traverse the children in the order in which they are provided. | |
| in_vertex | Upon return, an array of global IDs of the vertex through which to enter each element in the user provided traversal. It is required only if the user is providing the order for the children of this element (i.e., ref_type==ZOLTAN_IN_ORDER) but does not provide the order for the children of at least one of those children. |
| out_vertex | Upon return, an array of global IDs of the vertex through which to exit each element in the user provided traversal. The same provisions hold as for in_vertex. |
| ierr | Error code to be set by function. |
| C and C++: | typedef void ZOLTAN_CHILD_WEIGHT_FN (void *data, int num_gid_entries, int num_lid_entries, ZOLTAN_ID_PTR global_id, ZOLTAN_ID_PTR local_id, int wgt_dim, float *obj_wgt, int *ierr); |
| FORTRAN: | SUBROUTINE Get_Child_Weight(data, num_gid_entries, num_lid_entries, global_id, local_id,
wgt_dim, obj_wgt, ierr)
<type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(IN) :: num_gid_entries, num_lid_entries INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: global_id INTEGER(Zoltan_INT), INTENT(IN), DIMENSION(*) :: local_id INTEGER(Zoltan_INT), INTENT(IN) :: wgt_dim REAL(Zoltan_FLOAT), INTENT(OUT), DIMENSION(*) :: obj_wgt INTEGER(Zoltan_INT), INTENT(OUT) :: ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_CHILD_WEIGHT_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| num_gid_entries | The number of array entries used to describe a single global ID. This value is the maximum value over all processors of the parameter NUM_GID_ENTRIES. |
| num_lid_entries | The number of array entries used to describe a single local ID. This value is the maximum value over all processors of the parameter NUM_LID_ENTRIES. (It should be zero if local ids are not used.) |
| global_id | The global ID of the object whose weight is requested. |
| local_id | The local ID of the object whose weight is requested. |
| wgt_dim | The number of weights associated with an object (typically 1), or 0 if weights are not requested. This value is set through the parameter OBJ_WEIGHT_DIM. |
| obj_wgt | Upon return, an array containing the object's weights. If wgt_dim=0, the return value of obj_wgts is undefined and may be NULL. |
| ierr | Error code to be set by function. |
| C and C++: | typedef int ZOLTAN_HIER_NUM_LEVELS_FN (void *data, int *ierr); |
| FORTRAN: | FUNCTION Get_Hier_Num_Levels(data, nbor_proc, ierr)
INTEGER(Zoltan_INT) :: Get_Hier_Num_Levels <type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(OUT) :: ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_HIER_NUM_LEVELS_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| ierr | Error code to be set by function. |
| Returned Value: | |
| int | the number of levels of balancing hierarchy for method HIER. |
| C and C++: | typedef int ZOLTAN_HIER_PART_FN (void *data, int level, int *ierr); |
| FORTRAN: | FUNCTION Get_Hier_Part(data, level, ierr)
INTEGER(Zoltan_INT) :: Get_Hier_Part <type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(IN) ::: level INTEGER(Zoltan_INT), INTENT(OUT) :: ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_HIER_PART_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| level | The level of a hierarchical balancing for which the part ID is requested. |
| ierr | Error code to be set by function. |
| Returned Value: | |
| int | The part number the process is to compute for this level. |
| C and C++: | typedef void ZOLTAN_HIER_METHOD_FN (void *data, int level, struct Zoltan_Struct * zz, int *ierr); |
| FORTRAN: | SUBROUTINE Get_Hier_Method(data, level, zz, ierr)
<type-data>, INTENT(IN) :: data INTEGER(Zoltan_INT), INTENT(IN) :: level TYPE(Zoltan_Struct), INTENT(IN) :: zz INTEGER(Zoltan_INT), INTENT(OUT) :: ierr <type-data> can be any of INTEGER(Zoltan_INT), DIMENSION(*) or REAL(Zoltan_FLOAT), DIMENSION(*) or REAL(Zoltan_DOUBLE), DIMENSION(*) or TYPE(Zoltan_User_Data_x) where x is 1, 2, 3 or 4. See the section on Fortran query functions for an explanation. |
| Function Type: | ZOLTAN_HIER_METHOD_FN_TYPE |
| Arguments: | |
| data | Pointer to user-defined data. |
| level | Level in the hierarchy being considered. |
| zz | Zoltan_Struct to use to set parameters. |
| ierr | Error code to be set by function. |


TUESDAY
CHRISTMAS TIME FROM 2 JANUARY
ENTRANCE ANTIPHON
Blessed is he who comes in the name of the Lord: The
Lord is God and has given us light.
COLLECT
Before Epiphany
O God, who in the blessed child-bearing of the holy
Virgin Mary kept the flesh of your Son free from the sentence incurred by the
human race, grant, we pray, that we, who have been taken up into this new
creation, may be freed from the ancient taint of sin. Through our Lord Jesus
Christ, your Son, who lives and reigns with you in the unity of the Holy
Spirit, one God, for ever and ever.
COLLECT
After Epiphany
O God, whose Only Begotten Son has appeared in our
very flesh, grant, we pray, that we may be inwardly transformed through him
whom we recognize as outwardly like ourselves. Who lives and reigns with you in
the unity of the Holy Spirit, one God, for ever and ever.
PRAYER OVER THE OFFERINGS
Receive with favour, O Lord, we pray, the offerings of
your people, that what they profess with devotion and faith may be theirs through
these heavenly mysteries. Through Christ our Lord.
Preface of Christmas
I-III or Epiphany
COMMUNION ANTIPHON
Because of that great love of his with which God loved
us, he sent his Son in the likeness of sinful flesh.
PRAYER AFTER COMMUNION
O God, who touch us through our partaking of your
Sacrament, work, we pray, the effects of its power in our hearts, that we may
be made fit to receive your gift through this very gift itself. Through Christ
our Lord.


Add photos of your facilities or games. You can always add more later.
+ Add Photo
+ Add Video
You can edit information about your court here.


Cookies
GOV.UK puts small files (known as ‘cookies’) onto your computer to collect information about how you browse the site.
Cookies are used to:
- measure how you use the website so it can be updated and improved based on your needs
- remember the notifications you’ve seen so that we don’t show them to you again
GOV.UK cookies aren’t used to identify you personally.
You’ll normally see a message on the site before we store a cookie on your computer.
Find out more about how to manage cookies.
How cookies are used on GOV.UK
Measuring website usage (Google Analytics)
We use Google Analytics software to collect information about how you use GOV.UK. We do this to help make sure the site is meeting the needs of its users and to help us make improvements.
Google Analytics stores information about:
- the pages you visit on GOV.UK - how long you spend on each GOV.UK page
- how you got to the site
- what you click on while you’re visiting the site.
We don’t collect or store your personal information so this information can’t be used to identify who you are. For more information visit our Terms and conditions and privacy policy page.
We don’t allow Google to use or share our analytics data.
Google Analytics sets the following cookies:
| Name | Purpose | Expires |
|---|---|---|
_ga
and
_gat
|
This is a google analytics cookie that helps us understand how the service is being used in detail. Your data is anonymised. | 2 years |
You can opt out of Google Analytics cookies.
Our introductory message
You may see a pop-up welcome message when you first visit GOV.UK. We’ll store a cookie so that your computer knows you’ve seen it and knows not to show it again.
| Name | Purpose | Expires |
|---|---|---|
seen_cookie_message
|
Saves a message to let us know that you have seen our cookie message | 1 month |
Cross Site Request Forgery token
We add a cookie to check calls made to form pages to ensure the requests come from a valid source.
| Name | Purpose | Expires |
|---|---|---|
_csrf
|
Prevent Cross Site Request Forgery attacks | When you close your browser |
Already registered
We add a cookie to temporarily hold parameters when you enter your existing reference details to avoid saving them in your browsing history for security.
| Name | Purpose | Expires |
|---|---|---|
apvs-start-already-registered/apvs-start-already-registered.sig
|
Stores returning users parameters | When you close your browser |
You can read more about how cookies are used on gov.uk.


GCTC 2016 Sponsors and Partners
Collaborate with leading developers of IoT technologies and accelerate the deployment of solutions designed to address some of the most pressing challenges facing cities today.
US Federal Agency Partners
Corporate Partners
Non-profit Partners
{% comment %}
National Government Partners
{% endcomment %}


We have deployed Suma Crm version v.1.0
We are introducing following new feature in this deployment :
-
Company feed : You will get this on login and you can post your thoughts.
-
Reset Password / Forgot Password : This is on sign in/login page.
-
Auto Completer : This is on Article list page as of now.
-
Profile Pic enhancement : Edit Your account and upload profile pic.
Please visit our application : http://suma-crm.herokuapp.com/
You are welcome with your suggestions
SumaSoft Development Team


It is hard for me to learn this module because there are many things from the hardware domain. And I’m a computer science student from the software domain and I had never done about electronics, so it’s difficult to study the hardware. Firstly, I needed to use the software KiCad. Actually, it was the first time that I had heard about this software. I didn’t know how to use it. What’s more, I didn't know how to draw circuit diagrams with this software. When I did the Arduino Uno project with my partner, we needed to make all the tracks in the same side. But we didn’t success. We have tried so many times, but every time there was always one track in another side. Because all the tracks can’t cross each other is a big constraint. So it was really difficult for us.
I had never used KiCad before. So I have followed what the teacher explained during the course to start using the kiCad. The teacher usually made an example, in the screen, so I could learn about how to use KiCad. Sometimes the teacher did examples really quick so that I couldn't follow him. Then I found a specification about KiCad on the Internet. When I did the project Arduino Uno with my partner, this specification helped us a lot. So I think that listening to teacher and finding more information in the Internet both are useful. The last problem is to make all tracks in the same side. However, we have done it many times. But each time we can’t do that. Because all the tracks can’t cross each other. Finally, there was a track in another side.
During this module, the skills I mobilized are mainly operational knowledge. The theoretical and technological skills that I have acquired concerning the electronic part. From all courses of this module, I can learn some knowledge about electronic, open-source and hardware. What’s more, during the Arduino Uno project with my partner, we have learned how to draw the circuit diagram, import a library and draw the routing. So I have acquired mainly about the electronic part and the operation of the circuit.
I think this module is useful because I have learned some knowledge about the electronic part which I had never known. Actually, it’s the first time for me to know about the electronic and the Arduino. My partner and me have almost overcome all the difficulties during the project. I think the best way to learn is solving the problem by yourselves. As we come from computer science, we had many difficulties during this module. So we always ask the teacher, ask the peers and search on the Internet to solve the problems.
In the module of Communication, my project group and me had to calculate the exercise about how far a ZigBee wireless transmitter could transmit without exceeding the threshold of detection for the receiver. At first, without interference and then with the interference of the second transmitter Wi-Fi. It was then nearly the same to the second exercise, but we needed to calculate the maximum distance between the Wi-Fi disturber and ZigBee transmitter for a fixed distance between the transmitter and the receiver. This goal is to keep the power of the signal in reception always above the threshold of detection of a signal. We had two weeks to do this exercise.
For me, it’s really difficult to resolve this exercise, because I had never learned about the telecommunication. To realize these calculations, firstly I needed to understand the formulas in the slide. Then I have chosen to use the model of propagation of type One Slop with my project group to do this exercise. We have done a table to calculate the Path loss during this transmission with the interference of Wi-Fi.
Then we have calculated the interference of Wi-Fi and we can deduce the loss of power from the formula given in the table of the calculation. What’s more, the model One Slop gives us the formula to calculate the loss power between the transmitter and the receiver.
The second question is the reverse of the first one. We know the distance between the transmitter and the receiver and we need to calculate the maximal distance between the ZigBee transmitter and the Wi-Fi. We have calculated the power of the received signal ZigBee. Then we can calculate the interference of Wi-Fi with the formula. Lastly, we can calculate the maximal distance.
We have looked the slide provided by the teacher to know the formula and to understand the course better. When we did the exercise, we have also searched information on the web. Because we did not know clearly how to calculate the maximal distance while giving a fixed distance. What’s more, the calculations are not easy as there are many math formulas.
This exercise mainly allowed me to acquire theoretical skills on wireless communication. I know how to use the model of propagation of type of One Slop. I understand the formulas which for calculating these two questions. This course has broadened my knowledge in the telecommunication domain.
I think I have clearly understood the given problem and answered the questions, even if I have spent a lot of time on it than necessary. I find it quite entertaining and I have some knowledge about the wireless communication for the connected objects.
I also think the best way to learn is to do the exercise by yourselves. Before this course I had known nothing about the wireless communication. After listening to the course and doing the exercise, I knew better about that.
This year at INSA, I have taken the course of protocol for connected objects. I have learned about UMTS, GSM, 3G, 4G, 5G, LoRa, ZigBee, Sigfox, NB-IoT, MAC Layer, etc. I think it’s interesting because I have learned about protocols for connected objects on several levels. After that, we did research for the report under the given topics and we had also presentations during this course.
Actually, during this course I had to prepare the presentation about 5G in developing countries, my partner and me we have done the report about the NB-IoT, and I have done the report to compare the different MAC Layer protocols. So I had many things to look for on the web, write the report and prepare for the presentation. Firstly, I identified the definition on Wikipedia, that gives me a little idea about the knowledge. Then I found article resources that contain the information for each work. Finally, to go faster, I looked the articles and wrote the useful information into my report or prepare for the presentation.
This course has helped me improve my skills in protocol domain. All those things were learned thanks to lectures, researches, reading and discussions. You will be able to consult the work I did on this course in the annexes below.
Searching information for 5G, NB-IoT and MAC Layer and editing the report is really a good way to learn. I sensed that I learned a lot. Because each time, I prepared and looked for the information on the Internet. I need to understand and write the report. Then we came to class and we discussed with other students and our teacher, which allowed me to broaden my knowledge in the telecommunication network domain.
During last year, I have followed a course called energy for connected objects. An embedded system is an electronic system benefiting from limited resources in term of signal processing and of limited energy resources. In this course, I have learned about the electrochemical energy storage, the electrostatic storage and energy harvesting.
Actually, there nearly didn’t have encountered problem during this course. The only thing to do is to listen and understand during each lecture. This course allowed me to understand other problems in other subjects. Such as the main project in ISS, the social network for pollution, when the question about the energy source of sensors came up, I wondered that our sensors can get energy from solar panel.
The knowledge that I have acquired in this course is mainly theoretical and on the term of storage of energy.
Normally we should have a QCM for this course said by the teacher, but actually we didn’t have. For this course, I have learned the knowledge about the storage of energy and the energy harvesting. That has improved my skills in the domain of the energy.
This year I have followed a course called security for network of connected objects. Security brings in concerns for confidentiality, in addition to availability and integrity. I have been informed to some definitions such as reliability, availability, safety, integrity in the security domain. I know that for most distributed systems, the security objectives of confidentiality, integrity and availability of information apply. A loss of confidentiality is the unauthorized disclosure of information. A loss of integrity is the unauthorized modification or destruction of information. A loss of availability is the disruption of access to or use of information or an information system.
A fault can activate an error, then an error can propagate a failure. Physique fault, fault of conception, single event latch-up and intrusions are examples of the type of fault. There are many different types of attacks, such as passive listening, interception, relay attack, masquerade, covert channels, side channels, backdoor, malware and DOS (denial of service). And we have different defenses for the fault, for example, fault prevention, fault tolerance, fault elimination and fault prevision. For the fault treatment, there are diagnostic, passivation, reconfiguration and reinitialization.
Finally, we have learned about the analysis of risks. The method EBIOS, attack trees, attack defense trees (ADT) and Honeypot.
This course has given me some knowledge in the security domain. Actually, I have already followed a course about security last year. So I have the base knowledge for the security. This time I have learned about the attributes of security, the type of fault, the type of attack and analysis of risk. This course is easy to understand even if you don't have the base knowledge. It can be shown to non-scientific people.
During this course I have done two exercises. The first one is about LISP (Locator Identifier Separation Protocol).
The question is how an IPv6 packet, leaving S can reach its destination D, then detail the flow of actions that follows a loss of IP connectivity due to a failure of router R2 interface. The second one is about SDN (Software Defined Network).
The question is that what are the necessary openflow rules to install on the SDN switch to let the UDP CoAP traffic flow from the Gateway to Device 1 and let the Gateway open the ssh session on both devices.
For the first question: S generates IPv6 packet to D, IPv6 network forwards IPv6 packet to R1. ITR: looks the dest@, checks if it’s a LISP site, verifies on the mapping or ask to the EID-RLOC mapping resolution system, the MR (Map-Resolver) sends the request to MS (Map-Server) (to know the RLOC of an EID). R3 tells to MS2 that if MS2 wants to reach 2001:db8:1::/48 he has to pass to R3, R3 answers to R1 the RLOC related to EID.
Firstly, R1 sends an IPv4 packet with: @dest = <IP_ADDRESS>, @src = <IP_ADDRESS>, the IPv6 packet encapsulated. Secondly, R2 decapsulated the Ipv6 packet with: @dest = 200:db8:2:1, @src = 2001:db8:1:1 Finally, R2 sends the packet to D.
For the second question: We need to identify the match rules.
I have acquired theoretical skills during each lecture and operational skills during the two labs. I have learned about the SDN and LISP and that has broadened my knowledge in the domain of the network and the openflow. For the two labs, I have really configured the network by myself and I had a better understand about what I learned during this course.
I think this course is interesting, especially the two labs. We just had two labs and I wonder it’s not enough. Because when I finished the first lab, I didn’t have much time to do the second one. Maybe I have taken so much time for the first one. Anyway, this course has improved my skills about network knowledge and configuration about the network.
This course brought me a general knowledge about team leading, project management and market studies. During this course, I was able to discuss topics such as design thinking, anticipating technological developments, spreading innovation, management, etc. It shows that many inventions do not reach the status of innovations for marketing issues, marketing not well planned or because the public is not yet ready to receive them. So they will not succeed and disappear in the market. Because there are some key constraints for product diffusion. What’s more, we have to manage our group and project well. If we have a conflict in a group, we need to fix as soon as possible. Before we begin to work, we need to know about each other well.
The skills that I have acquired is more about relationship and management in a group. It seems to me that what have been done during this course will be directly reusable in the work. That is what I’m going to do now.
I think this course is interesting. I have learned about the group management, the difference between invention and innovation, business, etc. This course has improved my knowledge in the design thinking, innovation and business domain.
As we talk about creativity and innovation, learning about the TRIZ method is a kind of way to know about creativity and innovation. During this course, I have thought about several evolutions of systems, such as the bike or the calculator. And then I have been demanded to use the nine laws and the cyclic model of my project, the social network for pollution.
When I practiced the cyclic model for my project, I realized that my project is still in the growth phase. As there are birth, growth, maturity and decline phases. Because air quality monitor is not really deployed by each city for people to access easily. And the platforms of air quality today are mainly expensive. We need to do a platform with low cost and can be accessible at anytime for anyone. The purpose is to make people be informed about the air quality. So our project is still growing.
The skills that I have learned during this course is mainly theoretical and practical. I have learned about the cycle model on biological systems, from birth to decline, and nine laws about evolution. I have known about the contradiction model and resolution methods. If we didn’t have a contradiction, we would not have a problem.
In summary, this course brought me a good knowledge in the creativity and innovation domain. During this course, we just know a little about the TRIZ method so there still are many potential things need to learn. It’s good that we know more about the TRIZ method so that we can practice it during future work.
During the course of software engineering, I have learned about the method of project management and different type of test for software testing.
For the models of development, such as waterfall model, V model, Incremental model, Spiral model, unified process and Agile model. What's more, I have learned one of the most important Agile methods is Scrum, which produces business values with short time period. A functional software is produced each 3 to 4 weeks is called sprints. At the end of each sprint, everyone can see the software running and decide whether to deliver or improve it during an additional sprint.
For the test, I have learned unit tests, integration tests, system tests, validation tests, functional tests and technical tests. I have practiced mainly about technical tests, for which I have used two approaches, write box and black box.
This course has broadened my knowledge in the software engineering and testing domain. I think is critical to know that for a computer science student. Actually, I have already the base knowledge about this domain. This time I have been more improved and I will practice the useful methods and tests during the future working.
I think this course is mainly about theoretical in software engineering and software testing domain. This course introduces me the knowledge about the project management method and test process. And we have practiced one of the project management methods into one of our projects. We have used the method Scrum to do the SOA (Software Oriented Architecture) project. That I have written in the descriptive part.
Autonomic computing is self-managing computing model. It maintains comprehensive and specific knowledge about all its components. It monitors all its components. It automatically detects prospective issues, such as security, performance degradation. It fixes the issues in an autonomic way with no need for interactions with humans.
Then I learned about the hypervisor. It is a hardware virtualization technique that allows multiple OS to run on a single host system at the same time. A hypervisor is also a software that allows creating, managing and terminating Virtual Machines (VM).
I have known about IaaS (Infrastructure as a Service), PaaS (Platform as a Service) and SaaS (Software as a Service).
During the labs of this course, I have used the VirtualBox VM to create different VMs and tested the connectivity between the created VMs and outside.
I have connected to the Proxmox to create a CT (container). Then I have developed Java code to manage the creation of CTs under the constraint of the memory usage, to make a balance between the two servers we have and to stop the oldest CT when we need to create a new CT and the memory usage is already exceeded.
After that, I have used Google plugin, Pivotal Web Services and Jelastic during the last session lab to provision end-user application in Cloud platforms.
This course has improved my knowledge in the Cloud domain. Actually, it is the first time for me to learn about Cloud Computing and use is during the labs. I think this course is interesting and important, especially the labs. I can create the VM, code and use some platform or google plugin to understand well the course.


Good question. Apparently, as someone who is in the business of writing and creative technology, a blog is a good idea. I figured that now (I just finished my junior year at CU Boulder) is as good of a time as any to get this thing off the ground. I'll be using this space as essentially a journal while I travel this summer, a photo library, and a general repository for my creative work.


This is a PVE server. PVP actions will not be tolerated and will result in jail time or a kick/ban.
NO WHINING, BEGGING, GREIFING, HARRASSING, or BEING DISRESPECTFUL TO OTHER PLAYERS.
Being a bother to other players will result in a kick or ban. This includes refusing to leave a players property when asked to do so.
No Building or Claiming (LCB) within 250 blocks of Cities and Traders. Period.
Use the map to determine your base position. 1 block = 1 meter = 1 coordinate.
Any Build-Work or Land Claim Blocks (LCB) found in these areas, will be deleted, and your items will be given away.
No Building or Claiming of ANY Game-Made Structure.
This includes: Houses, Camps, Army Camps, Army Bases, Bunkers or Anything that contains loot for players. This is the ensure there will be loot available as the game progresses in days.
Any Build-Work or Land Claim Blocks (LCB) found in these areas, will be deleted, and your items will be given away.
Do Not Build On or Block Roads.
Legal Raiding
Defined on this server as the looting of another players personal items, base, or land, that IS NOT protected by a Land Claim Block (LCB). This is so players may take over bases of players no longer playing on the server. Players who befriend each other, are to treat each others base as if full LCB protection applies. Players found "raiding" bases of "friends" will be banned.
Land Claim Blocks are set to expire after 7 days of being offline. At this time your base is subject to legal raiding. Any areas where LCB's are not placed is subject to looting.
Dropped backpacks from player deaths and Bases in the Community City, are the exception to this rule!!
Players are responsible for thier own land and base protection.
LCB size is set to 41 blocks. Meaning 20 blocks in every direction from where it is placed. The admin will not provide assistance to people who fail to lay LCB and protect their property. If a player needs to be offline for longer than 7 real-time days, and wishes for their base to be protected, you must contact and inform an admin.
Player backpacks are NOT to be touched by anyone other than the person who dropped it.
Stealing another persons bag will result in an One hour kick, and a deduction in zCoins.
The use of minibikes is allowed.
However, this is at the discretion of the admin and is subject to change, according to the needs of the server.
Zgates are allowed to be created in cities, however they must be made public, and named properly.
Do not name it anything like: zgate1, #2, m4x2k, etc. Public zGate must identify to what they are (exp HubCity1, DesertCity, TraderHugh, SnowTrader...etc).
While the practice of making city and trader zGates is allowed, it is strongly discouraged by the admin. zGates are intended to be used as a personal means of continued exploration of the map and environment.
Explosives are not allowed at the Pit!

This is not a PVP server and PVP actions will not be tolerated. Players are however allowed to protect their base with the stranger kill mode, if and only if
the turrets are placed behind walls, and in a location to where it is blatantly obvious that a person has broke into your property. Players should not be getting killed for walking past a base.
Once that player decides to find a way over the protection wall and enters your plot, they are then subject to SKM of the turret. Example placement would be inside a house, or within a high retaining wall that is sealed of with locked doors.

1. DO NOT be in the city during or at the start of a bloodmoon. Doing so will result in a 24 hour ban from the server. Continued violations will result in a permanent ban."
This is to protect the property and player bases in the community. Being in the community during a bloodmoon causes a very high chance of zombies spawning inside of someones base and causing damage while trying to escape.
For this, anyone found in the Community City During a bloodmoon, will be banned for 24 Hours and will pay a fine with zCoins.
2. NO TUNNELS. Underground activity must be confined to your plot!
When you build in the community city you are building within close proximity to others. In every situation so far a player defines out the amount of land they want and then protects it with LCB's. At this point this is your defined community plot.
Any digging or mining done should be confined to your LCB area. Digging out of your area takes away resources from other players. What may be open land now may soon be someones plot. And while building a base a player discovers that someone has already dug out their land
frustrates and inconveniences both the admin and the player.
3. Raiding of any base or destroying anything in the Community City will result in a ban.
The community city is under full protection of the Admin. When a players LCB expires their bases is still protected and is NOT to be touched or raided. The plot will be given away or sold by the admin for zCoins, at
the appropriate time. Any player found tampering with ANY base will be permanently banned.
4. If your LCB expires, there is a high chance for your property to be given away.
building in the community City mean you are and active player and plan to be on the server for a while and would like to contribute to the building of the city. If you are offline for 14 days, you plot will be sold or given away by the admin.
If you require to be offline for linger than this, please inform the admin, so the he can lay additional protection.
5. The admin must assign a plot for players to build in.
In order to actually build what looks to be a functioning city, players must ask the admin before trying to build a base. When laying a LCB the player should try
to line the edges of their LCB with the 2 edges of the sidewalk in their property. Each city square allows for 4 plots. 1 LCB should cover a players entire base.
Be mindful that we are building a city!
When laying out your land and building your bases, please try to think about how this will affect the city layout. Things like roads, street lights, pois, and lootables, are hard to place when there is no
structure or organization to the build. Use your map and decide if you should scoot over a bit to allow a road, or to line up with another building. We want a city, not a clusterf***.
These are not the indefinite set of rules and can be changed, taken away, added or modified at the need or will of the Admin. Common Sense Rules do apply.
{% endblock %}


strcasestr
—case-insensitive character string search#include <string.h> char *strcasestr(const char *s, const char *find);
Description
strcasestr
searchs the string s for
the first occurrence of the sequence find. strcasestr
is identical to strstr
except the search is
case-insensitive.
Returns
A pointer to the first case-insensitive occurrence of the sequence
find or NULL
if no match was found.
Portability
strcasestr
is in the Berkeley Software Distribution.
strcasestr
requires no supporting OS subroutines. It uses
tolower() from elsewhere in this library.


This document links 2 css files: base.css & customized.css. Under chrome, browser will try to merge the styles they described, while under FireFox, they are separated and can be shifted by clicking "View->Page Style".


TeeChart for JavaScript
To PNG and JPEG
PNG Image
This is a PNG image:
JPEG Image
This is a JPEG image:


{{ partial "head" . }}
Percentage and condition based routing for A/B testing and canary releasing. Prevent performance issues and service disruption with gradual rollouts and upgrades.
Graphical UI and dashboards for clear information and easy management
Integrated javascript based workflow system for flexible automation
Integrated metrics and events system exposed through API, SSE and websockets.
Automatic load balancing of scaled out services and containers
API gateway features such as URL rewrites and conditional redirects
CLI and REST API for integration with CI/CD pipelines


Opening: June 18, 1972
Refurbishment
- March 3, 1998 (green line reopening)
- March 19, 1998 (red line opening)
Architectural design
- Dinis Gomes (original project)
- Manuel Tainha (refurbishment)
Art work
- Maria Keil (original project, refurbishment)
- Noronha da Costa, Costa Pinheiro, Juahana Bloomstedt and Alberto Carneiro (refurbishment)
Platform length: 105 m
Code: AM
Wikipedia page


hp-scan(1) User Manuals hp-scan(1) NAME hp-scan - Scan Utility DESCRIPTION SANE-based scan utility for HPLIP supported all-in-one/mfp devices. SYNOPSIS hp-scan [DEVICE_URI|PRINTER_NAME] [MODE] [OPTIONS] PRINTER|DEVICE-URI To specify a device-URI: -d<device-uri> or --device=<device-uri> To specify a CUPS printer: -p<printer> or --printer=<printer> MODE Run in interactive mode: -i or --interactive OPTIONS Set the logging level: -l<level> or --logging=<level> <level>: none, info*, error, warn, debug (*default) Run in debug mode: -g (same as option: -ldebug) This help information: -h or --help OPTIONS (GENERAL) Scan destinations: -s<dest_list> or --dest=<dest_list> where <dest_list> is a comma separated list containing one or more of: 'file'*, Scan mode: -m<mode> or --mode=<mode>. Where <mode> is 'gray'*, 'color' or 'lineart'. Scanning resolution: -r<resolution_in_dpi> or --res=<resolution_in_dpi> or --resolu‐ tion=<resolution_in_dpi> where 300 is default. Image resize: --resize=<scale_in_%> (min=1%, max=400%, default=100%) Image contrast: --contrast=<contrast> ADF mode: --adf (Note, only PDF output is supported when using the ADF) OPTIONS (SCAN AREA) Specify the units for area/box measurements: -t<units> or --units=<units> where <units> is 'mm'*, 'cm', 'in', 'px', or 'pt' ('mm' is default). Scan area: -a<tlx>,<tly>,<brx>,<bry> or --area=<tlx>,<tly>,<brx>,<bry> Coor‐ dinates are relative to the upper left corner of the scan area. Units for tlx, tly, brx, and bry are specified by -t/--units (default is 'mm'). Use only commas between values, no spaces. Scan box: --box=<tlx>,<tly>,<width>,<height> tlx and tly coordinates are relative to the upper left corner of the scan area. Units for tlx, tly, width, and height are specified by -t/--units (default is 'mm'). Use only commas between values, no spaces. Top left x of the scan area: --tlx=<tlx> Coordinates are relative to the upper left corner of the scan area. Units are specified by -t/--units (default is 'mm'). Top left y of the scan area: --tly=<tly> Coordinates are relative to the upper left corner of the scan area. Units are specified by -t/--units (default is 'mm'). Bottom right x of the scan area: --brx=<brx> Coordinates are relative to the upper left corner of the scan area. Units are specified by -t/--units (default is 'mm'). Bottom right y of the scan area: --bry=<bry> Coordinates are relative to the upper left corner of the scan area. Units are specified by -t/--units (default is 'mm'). Specify the scan area based on a paper size: --size=<paper size name> where <paper size name> is one of: 5x7, photo, a2_env, b4, b5, 3x5, 4x6, higaki, flsa, c6_env, legal, no_10_env, exec, a3, a5, a4, letter, a6, super_b, oufufu-hagaki, dl_env, japan_env_4, japan_env_3 OPTIONS ('FILE' DEST) Filename for 'file' destination: -o<file> or -f<file> or --file=<file> or --output=<file> OPTIONS ('PDF' DEST) PDF viewer application: --pdf=<pdf_viewer> OPTIONS ('VIEWER' DEST) Image viewer application: -v<viewer> or --viewer=<viewer> OPTIONS ('EDITOR' DEST) Image editor application: -e<editor> or --editor=<editor> OPTIONS ('EMAIL' DEST) From: address for 'email' dest: --email-from=<email_from_address> (required for 'email' dest.) To: address for 'email' dest: --email-to=<email__to_address> (required for 'email' dest.) Email subject for 'email' dest: --email-subject="<subject>" or --subject="<subject>" Use double quotes (") around the subject if it contains space characters. Note or message for the 'email' dest: --email-msg="<msg>" or --email-note="<note>" Use double quotes (") around the note/message if it contains space characters. OPTIONS ('PRINTER' DEST) Printer queue/printer: --printer=<printer_name> OPTIONS (ADVANCED) Set the scanner compression mode: -x<mode> or --compression=<mode>, <mode>='raw', 'none' or 'jpeg' ('jpeg' is default) ('raw' and 'none' are equivalent) SEE ALSO AUTHOR HPLIP (Hewlett-Packard Linux Imaging and Printing) is an HP developed solution for printing, scanning, and faxing with HP inkjet and laser based printers in Linux. REPORTING BUGS The HPLIP Launchpad.net site https://launchpad.net/hplip is available to get help, report bugs, make suggestions, discuss the HPLIP project or otherwise contact the HPLIP Team. COPYRIGHT Copyright (c) 2001-14 Hewlett-Packard Development Company, L.P. This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to distribute it under certain conditions. See COPY‐ ING file for more details. Linux 2.2 hp-scan(1)


You can add arbitrary metadata to your instance so that you can more easily identify it among other running instances. Metadata is a collection of key-value pairs associated with an instance. The maximum length for each metadata key and value is 255 characters.
The maximum number of key-value pairs that can be supplied per instance is determined by the compute provider. This limit is currently set to {$ model.novaLimits.maxServerMeta $}. This limit is currently not set.


Clean, powerful code for projects big and small.
My name is Joshua Kevin Goldberg, and I am a member of Rennselaer Polytechnic Institute's Class of 2015, majoring in Computer Science. This is my website, which showcases some of the bigger projects I've done. I've been doing code work since middle school, and a side of graphic design since high school.
I'm also the Microsoft Student Ambassador for RPI, the president of our Upsilon Pi Epsilon (UPE) honor society chapter, the Community Service chair for RPI's CS Club, and the V.P. of Publications for our chapter of Phi Gamma Delta (FIJI, Tau Nu chapter).


Mushrooms - P. cubensis & Cannabis
The setting was a large festival in England June 2004, mushrooms are openly on sale there so I bought 15 g of fresh Thai cubensis. About a year earlier I had grown a lot of cubensis and one night did a very large dose of fried mushrooms, probably about 10 grams of dried mushrooms. During the experience, most of which I still canít remember, I 'saw' my life/self explained in the world around me in a way that was staggering, it was truth. I tell you this because this latest trip builds on that experience.
At the festival I had taken the fresh mushrooms and wandered off to see a band. As I sat awaiting the performance to start I smoked some bud in a pipe and by the time the band came on I was grinning like a loon and really getting into the music. Then all of a sudden I found myself wandering amongst the crowds shuffling between the various acts and market places, no memory of getting there. I wasnít sure if I was awake or dreaming and was treating it like a lucid dream, but somehow knowing that it wasnít. I began to play with the dream, and as I wandered about I found that I could manipulate it and make anything I wanted to happen, happen.
Then I noticed that in the direction I was going that it was getting much nastier looking and the thick stormy clouds lay ahead. I continued and had visions of accidents, medics stabbings, and general chaos. I also noticed a distinct unrest from a large group of people (or beings) that were watching my exploits. I could not see these beings, but was intimately connected with them and like I said sensed there unease about the current path I was on. I then realised that it was up to me which direction I went and when I did this I got a few helpful cheers and claps from the unseen crowd.
As I turned around the sky was clear and the moon hung brilliantly in the sky, the crowd cheered. I turned again to the stormy sky, the crowd began to boo and become restless again. I turned this way and that and as I did so I 'saw' my life layed out before me, then endless possiblities, and I walked them. I explored them all, listening to my heart as I went, eliminating all the crap until I finally saw what I wanted out of it, as I did so the crowd roared and cheered and clapped and I began to tread that path and the sky cleared up and I was on my way home, I knew what was important to me and what I must do to make it be.
The festival site is huge and I covered most of it that night, but the great thing was I knew I was on my way home (to my tent) during the last leg of the trip. I found myself standing looking at some hills in the distance. The visuals where very minimal during both this and the last trip I had. Having just thought about the guys I went with, whom I had left before I took the mushrooms, when I turned around and they popped out of the endless crowds where pleased to see me and took me back to the camp which was only 50 yards away.
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.


Home
ToDoList
Create ToDoList
Update List Name
Display List
Find List By Name
Delete List
Tasks
Create Task & Add to ToDoList
Update Task
Display Task
Find Task By Colour
Find Task By Name
Delete Task
Remove Task from list
Task ID
Get Task ID
Retrieved Task ID
New Task Name
New Task Colour
New Task Description
Update Task


Welcome to Stephen's Article This article is written from "ATOM" This article is cool .This is Stephen writing HTML and CSS Combined


Crux developer's documentation
How to guides
- A description of the typical work cycle: change-test-review-commit. This is a good place to start for developers new to Crux.
- How to conduct a code review.
- How CMake is used to build Crux.
- The Crux GitHub repository and build action.
- How to administer the Crux website.
- How to release a new version of Crux.
Reference
- The Crux coding standards.
- The Crux API.
- The Doxygen code documentation Run '
make doc
' to produce it.- Notes on regression, smoke and unit testing.
- Notes on generating documentation
- Issues used to be tracked on Bugzilla but are now tracked on SourceForge.


--- template: example.html title: Modify features test shortdesc: Example for testing feature modification. docs: > Example for testing feature modification. tags: "modify, edit, vector" ---