|
As a computational physicist using Fortran for decades, I
summarize what I know about Fortran and what features are
frequently used in practical programming.
Fortran is a language tailored to the specific task of numerical computation. Most programming languages will have a flavor of Fortran if they are used to perform numerical computation. Fundamental support for multi-dimensional arrays in Fortran makes it convenient to write numerical programs, in which arrays are often the only data structure needed. Practical reasons why a computational physicist should learn Fortran include (1) Fortran is dominant in parallel computing (only C can compete with Fortran in this regard since MPI only supports C and Fortran). Fortran programs are using most of the resources of the largest supercomputers in the world. This is a strong indication that Fortran is dominant in the high performance computing area; (2) Fortran is still the most widely used programming language in the computational physics community so that one can not totally avoid reading or revising Fortran codes if one wants to communicate with people in the computational physics community.
Compilers are our friends, helping us find bugs earlier.
For debug purpose, I primarily use open source compiler
gfortran
. The compiler options mentioned below will be
for gfortran
by default. The following are some useful
gfortran
compiler options that can help find bugs:
-std=f2008 -fcheck=all -Wall -Wextra -fbounds-check
-fimplicit-none
Fortran is case-insensitive (this is different from most popular languages).
Use either newline or semicolon to complete an statement (this is different from C which neglects newline). For example:
int i real j
is equivalent to
int i; real j
Use exclamation mark (!
) for one line comment, which
tells the compiler to discard everything from where the mark is found
up to the end of the same line. Fortran does not have a keyword for
defining block comment (multi-line comment) similar to C (/*
*/
).
The recommended way of organizing Fortran code is to use only two top
units: program
and module
. And place
function
/subroutine
in modules
,
which makes the full interfaces of the procedures available to a
calling unit and thus makes it possible for compilers to check
argument match at compiling time. This helps to find all bugs related
to argument mismatch before actually running the code.
program your_name use your_modules implicit none real :: x x = 1.0 !assignment, this is a comment call some_subroutine end program your_name
Define subroutines:
subroutine p(arg1, arg2, more_arguments) some codes here end subroutine p
Define functions:
function myfunc(arg1, arg2, more_arguments) result (myval) some codes here end function myfunc
Use keyword call
to invoke a subroutine:
call p(arg1, arg2, more_arguments)
Functions can be used in all expressions, e.g.,
a = myfunc(1,2)*1.0
Fortran pass arguments by reference (not by values). A subroutine or function knows the memory location of the actual arguments passed to them via the argument list. Generally no copying in and copying out of an array, but sometimes, copying in and copying out may be involved.
A module contains specifications and definitions that can be accessed from other program units. These definitions include data object definitions, namelist groups, derived-type definitions, procedure definitions, and procedure interface blocks. For example:
module mod_name use some_module implicit none real:: x contains !the following must be subroutine/function subroutine p(arg1,…) some_codes_here end subroutine p end module mod_name
As mentioned above, placing
function
/subroutine
in modules
(by using keyword contains
) can make the full interfaces
of the procedures available to a calling unit and thus makes it
possible for compilers to check argument match at compiling time. This
helps to find all bugs related to argument mismatch before actually
running the code.
All variables in a modules are assumed by most fortran compilers to
have save
attribute, but this is not required by the
fortran standard. One way to make sure that all variables in a module
retain their values throughout the runtime is to use
that
module in the main program, so that the module never goes out of scope
and thus the values of the variables are retained throughout the
runtime.
if
constructif (logical_expression1) then some_codes elseif (logical_expression2) then some_codes else some_codes endif
where elseif
and else
clauses can be absent.
A single branch if
construct can be simplified as
if (logical expr) one_statement
Table 1 summarizes the relation operators and logical operators used in forming logical expressions:
Fortran Do
loop:
do i = nstart, nfinal, stride print *, 'i=', i enddo
If you change the value of the loop index i
inside the
above loop structure, e.g. i=i+1
, the compiler will
complain:
Error: Variable 'i' at (1) cannot be redefined inside loop beginning at (2)
The above loop is similar to the for
loop in C. For
comparison, consider the following for
loop of C:
for(j=0;j<10;j=j+1){ printf("hello,%d\n",j); j=j+1; }
where we also modify the value of loop index variable j
inside the loop and this is allowed by C compilers. This comparison
indicates that C is flexible and, as a side effect, more prone to
possible bugs.
Another loop structure using while
:
do while(i<10) write(*,*) 'i=',i i=i+1 enddo
The above while
loop can also be implemented by using
if
and goto
:
10 if (i<10) then write(*,*) 'i=',i i=i+1 goto 10 endif
The while
loop can also be implemented by using
do
and exit
:
do write(*,*) 'i=',i i=i+1 if(i>=10) exit enddo
Here the exit
statement will transfer control outside the
do
loop before the enddo
is reached. After
an exit
statement has been executed, control is passed to
the first statement after the loop. In passing, we note that there is
a cycle
statement that transfer control back to the
beginning of the loop to allow the next iteration of the loop to
begin.
Fortran is a statically typed language, which means that the type of
values that a variable can take is fixed at compile time and does not
change during runtime. Fortran does not have the type inference
capability available in some languages such as haskell, which means
that we need to manually declare the type of all variables used in a
program. The implicit
rule that enables us to omit type
declaration is “syntactic sugar” that we should avoid
using in practice because it is bug-prone. To totally avoid the
problematic “implicit rules” of fortran, using either
implicit none
or the compiler option
-fimplicit-none
, or using both for safety.
Fortran has five basic data types, namely integer
,
real
, complex
, logical
and
character
.
|
||||||||||||
Each data type has some attributes that can be further specified. For
example, the length of a character
variable is an
attribute, which can be specified by using
character (len = 40) :: name
Without specifying the value of len
parameter, the length
of the variable is default to one.
To specify the number of bytes for storing a real
variable, we can use the kind
parameter:
real(kind=4) :: xs ! 4 byte float real(kind=8) :: xd ! 8 byte float real(kind=16) :: xq ! 16 byte float
However the meaning of the value of the kind
parameter
depends on the compiler. For example, some compilers may use the
following scheme:
real(kin=1) :: xs ! 4 byte float real(kind=2) :: xd ! 8 byte float real(kind=3) :: xq ! 16 byte float
I used to use
integer,parameter:: p_=kind(1.0d0) !return the kind value of a double precison constant real(kind=p_) :: xd !use this value as the kind value
to define a double-precision variable (8 byte float). However, a more
convenient way is NOT to specify the kind
value of
real
variable in source code and use compiler options to
specify the precision we want. For example, we write in the code:
real :: abc
and then compile the code by using the
compiling option -fdefault-real-8
(for
gfortran
) to specify a 8 byte float number. For
ifort
, the corresponding option is -r8
.
Scientific computing often deals with simple data structures with homogeneous elements, such as arrays, which are often the only data structure used in a numerical code. This makes derived types not so frequently needed. We first discuss arrays. Derived types are discussed later.
Use dimension
to declare arrays. For example:
real, dimension(0:2, 1:4, -1:3) :: A
defines a real
-type array A
with
dimensionality being 3; the lower
bound and upper bound of the 1st dimension
are 0
and 2
, respectively; the
extent along each dimension is equal to
upper_bound-lower_bound+1
, and for this case, is 3, 4,
and 5, respectively. The dimensionality of an array is often called as
“rank” in Fortran (although this name can
be confused with the rank of a matrix in linear algebra, which
corresponds to the maximal number of linearly independent columns of a
matrix).
The combination of the rank and corresponding
extents, is called the shape of an
array. In the above case the shape of the array is
(3,4,5)
. Two arrays are conforming with each other if
they have the same shape.
The following is a shortcut of defining an array (which omits the
dimension
keyword):
real :: A(0:2, 1:4, 2:6)
We need specify bounds in each dimension in order to completely specify a multidimensional array. If we do not specify the lower bound of the array, lower bound of array in Fortran is by default 1. The following declaration:
real :: B(1:3, 1:4, 1:6)
can be simplified as
real :: B(3, 4, 6)
In summary:
Rank is the number of dimensionality of an array
Extent is the number of elements along a dimension
Bound is the upper or lower index along a dimension
Shape is the combination of rank and extents.
Using index to access single element of an array. For example
B(1,2,1) = 1.0
Use the index range (start:end) to access multiple elements of an array (sub-array or array-slice). For example:
write(*,*) B(1:2, 1:3, 3)
When referring to an array slice, both lower bound and upper bound can be omitted and they defaul to the declared array bounds . For example:
write(*,*) B(:, :, 3)
Since memory is laid out in one-dimension (each location has a single address index, not a set of indices), a compiler must decide how to map multi-dimensional arrays to memory locations. Different language use different conventions. In Fortran, arrays are stored “by column” in memory, which means putting each column of a 2D matrix in contiguous memory, as is illustrated in Fig. 1.
Figure 1. Fortran arrays are stored
in memory “by column”. This layout is often called
“column-major order”. As a comparison, C and Python
use the “row-major order” layout, which puts each
row of a matrix in contiguous memory.
|
The above illustration is for 2D array. It is obvious how to generalize the “column-major order” layout to higher dimensional arrays: when traversing memory continuously, the first index of an array is the fastest changing, the second index is the second fastest changing, and so on.
Why do we care the memory layout of an array?
Firstly, knowing the layout enables us to calculate the memory offset
of an array element. For example, for an array declared with
real(kind=8) :: a(m,n)
, the memory distance of an element
a(i,j)
from a(1,1)
is [m
×(j - 1) + i -
1]×8byte if the layout is the column-major order. The
distance would be [n×(i - 1) +
j - 1]×8byte if the layout was the
row-major order.
Secondly, the array layout is important to CPU cache and thus to code performance. A CPU views the memory as in 1D layout. When a CPU fetches an element from memory to operate on, it will guess that future operations may need some elements near that memory location. Therefore, a CPU will load a contiguous memory block near that location to CPU cache in order to make it comparatively quick to access elements potentially needed in future operations.
Thirdly, vectorized instructions of modern CPUs also requires consecutive access. (The vector processing can either be done with intrinsics, syntax hints of a Language, or by relying on the compiler's auto-vectorizer.)
So, to get good code performance, always traverse data in the order they are laid out in memory.
Layout of multi-dimensional arrays in memory is just a logical abstraction of the 1D linear memory. Different choices of layout can be simply considered as personal preference of the designers of a language. The personal preference of a language designer is related to the data structure and the type of operation on the data frequently used in his/her routine work. If we try, we can always find some reasons why a language prefers one layout over the another. For Fortran, I believe the reason is related to multiplication of a matrix with a vector, which can be arranged as
In this form, it is an operation over individual columns of the matrix. Then it is beneficial to store a column in contiguous memory.
For C and Python, which choose the “row-major order” layout, I believe the reason is related to the view that a multi-dimensional array is considered as a nested 1D array. Using Python list as an example:
In [3]: mylist = [[1,2,3], [4,5,6]]
which is a nested list corresponding a 2×3 matrix.
Since the first row of the matrix corresponds to a 1D sub-list
mylist[0]
, it is natural to store these elements in
contiguous memory (list elements are not necessary in continuous
memory, here we assume that a 1D list is a 1D array).
Let us see a real example in Fortran, which clearly demonstrates the performance improvement thanks to the spatial locality in memory access patterns:
program main implicit none integer, parameter:: m=10000, n=30000 real :: a(m,n), b(n), c1(m), c2(m) integer :: i, j real:: tarray(3) !record the cputime CALL RANDOM_NUMBER(a) CALL RANDOM_NUMBER(b) call cpu_time(tarray(1)) !f95 intrinsic subroutine returning the cpu clock c1=0.0 do i=1,m !switching the two loops can improve the efficiency do j=1,n c1(i)=c1(i)+a(i,j)*b(j) enddo enddo call cpu_time(tarray(2)) write (*,*) 'CPU time used (seconds) in inefficent algorithm', tarray(2)-tarray(1) c2=0.0 do j=1,n c2(:)=c2(:)+a(:,j)*b(j) enddo call cpu_time(tarray(3)) write (*,*) 'CPU time used (seconds) in efficient algorithm', tarray(3)-tarray(2) end program main
The above code multiplies a matrix by a vector. Two methods are implemented, one is the naive way, another is using operation over individual columns of the matrix, as discussed above. Compile and run the code:
$ gfortran c_r.f90 && ./a.out CPU time used (seconds) in inefficent algorithm 1.08469510 CPU time used (seconds) in efficient algorithm 0.208189011
There is a factor of 5 performance gain due to the spatial locality in memory access patterns. In this example, the spatial locality help both cache and vectorized instructions, since we use Fortran array slice syntax, which usually enables vector processing. In the naive method, if we switch the order of the two loops, then we obtain spatial locality in memory access patterns, but the vector processing may not be enabled because we do not provide sufficient syntax hints to the compiler. In this case, the result is as follows:
$ gfortran c_r.f90 && ./a.out CPU time used (seconds) in inefficent algorithm 0.621351004 CPU time used (seconds) in efficient algorithm 0.207148075
The performance of the naive method improves but still 3 factor slower
than the vectorized version. Let us add -O3
optimization,
which may try to vectorize any codes than can be vectorized. The
result is as follows:
$ gfortran -O3 c_r.f90 && ./a.out CPU time used (seconds) in inefficent algorithm 7.00249672E-02 CPU time used (seconds) in efficient algorithm 7.00830221E-02
Finally, we obtain the same performance.
In passing, I would like to mention another important tip that can
improve spatial locality of memory access and hence code performance:
avoid using fine-grained derived datatypes or many small arrays,
instead, try to gather them together into an array to improve locality
in memory access. To demonstrate this, let us consider a famous
example in particle simulations, where each particle has three spatial
coordinates, say x,y,z. The intuitive
method would use three arrays, x(n),y(n),z(n)
, to store
these coordinates for each particle, where n
is the total
particle number, which is usual a large number, e.g. 106.
The jth elements of the three arrays will be frequently used together
in a computation, for example s=x(j)**2+y(j)**2+z(j)**2
.
In this case, a better way of organizing the data is to combine the
three arrays into one array, e.g., cor(3,n)
, with the
first index of the 1st dimension corresponding to x, second
index to y, and third to z. Then the above
expression would be
s=cor(1,j)**2+cor(2,j)**2+cor(3,j)**2
, where the three
elements are contiguous in memory and thus can help the cache and
speedup the computation.
We define static arrays as arrays whose shape and bounds are known at compile time, i.e., fully-declared-at-compile-time arrays.
If a static array is declared in a local scope, typically in a
subroutine/function
, its values are not retained between
different calls to the subroutine/function
(i.e., the
array is automatically deallocated when the procedure returns, as
automatic arrays (discussed later) would be). To retain the value, we
can specify save
attribute when declaring the array.
Static arrays with save
attribute are not allocated on
the stack. They actually exist in neither the stack nor the heap. The
are part of what's called the “data segment”. Similar
situation applies to the static
variables in
C
.
Static arrays without save
attribute are usually
allocated on stack. However the size of stack is limited, large arrays
have to be allocated in heap in order to avoid the stack overflow
(this can be achieved by declaring an array as allocatable and
allocating it manually, which usually imply that the allocation
happens on the heap. However the Fortran standard has no concept of
stack and heap, so this will be implementation (i.e. compiler)
dependent.)
We define a dynamic array as an array whose extent along each dimension is not fully declared when they are defined. Partially declared extent includes two cases: (1) the extent is not specified, which corresponds to an allocatable array or (2) the extent is specified with variables, which corresponds to an automatic array.
The rank of a dynamic array is always known at compile time since the notation of array declariation does not allow un-specified rank.
Dynamic arrays are created at particular run times (by programmers explicitly or by compilers implicitly) with sizes determined by computed (or input) values. Fortran 90 has three varieties of dynamic arrays, namely:
allocatable arrays
automatic arrays
pointer arrays
In high performance computing (HPC), it is usually recommended that we avoid using pointer arrays because they may prevent possible optimization by the compiler.
Allocatable arrays are arrays whose bounds along each dimension are
unknown at compile time (the rank is known), with their
creation/deletion and their bounds/size being controlled by
programmers at runtime. Use keyword allocatable
to
declare a allocatable array. In this case, only the rank needs to be
specified. For example:
real, dimension(:,:), allocatable :: A
To allocate a dynamic array:
allocate(A(-1:3,4))
[Besides using allocate
statement, there is another way
in which an allocatable array will get (re-)allocated: assigning an
array or array slice to an allocatable array name (rather than its
slice). For example:
real, allocatable :: A(:,:) real :: B(3,4), C(5,6) A = B !A will get allocated, with the same shape and bounds as B write(*,*) size(A,1), size(A,2), lbound(A,1) A = C !A will be de-allocated and then re-allocated to the same shape and bounds as C write(*,*) size(A,1), size(A,2), lbound(A,1)
This is informally called “(re-)allocation on assignment”, which makes dynamic arrays looks more like a variables in a dynamically typed language. However, there is overhead here because lots of checks/actions need to be done at runtime (e.g., is the allocatable array already allocated?, if allocated, is the shape and bounds are the same as the right-hand side array? if they differ, the allocated array will be de-allocated and then re-allocated to the same shape and bounds of the right-hand side).
Therefore, I usually try to avoid using this kind of automatic (re-)allocation on assignment. One can always suppress the (re-)allocation checks/actions of an array by using an array section (rather than an array name) in an assignment:
A(:,:) = B
In this case, if the allocatable array A
is not allocated
or already allocated but its shape does not match B
,
runtime error will appear.]
To de-allocate a dynamic array:
deallocate(A)
The creation and deletion of dynamic arrays are under full control of
a programmer, with one exception that a dynamic array without
save
attribute will be automatically deleted if the
declaration of the dynamic array goes out of scope. For example, an
allocatable array without save
attribute defined in a
subroutine will be automatically deleted when the subroutine returns
(i.e., the declaration of the allocatable array goes out of scope).
The automatic deletion of dynamic array can be prevented by specifying
save
attribute when declaring the array. For most fortran
compilers, dynamic arrays declared in a module
are
assumed to have save
attribute by default.
An automatic array is a local array (not a dummy
argument) of a subroutine/function
and its definition
involves variables whose values are unknown at compile time. Automatic
arrays can not be delcared in program
or
module
units.
This kind of arrays are called automatic arrays because their
allocation (usually on stack) and de-allocation are automatically
handled without explicit instructions from programmers. Specifically,
a automatic array will be de-allocated automatically when it goes out
of scope. We can not use save
attribute to an automatic
array. Otherwise, we will get compiling errors such as follows:
Error: Automatic object cannot have the SAVE attribute
If we really want to have a persitent arary, we should use
allocatable arrays or static arrays,
for which a save
attribute is allowed. Note in passing
that an allocatable array (not a dummy argument) defined in a
subroutine/function
without the save
attribute will be automatically deallocated upon
subroutine/function
return, which is the same as an
automatic array. (As a general rule, if an array/scalar is local to
the routine, memory is allocated on entry to the routine and
deallocated on return to the caller.)
Automatic arrays are usually allocated on the stack whereas allocatable arrays are allocated on the heap. But this behavior is not specified in the Fortran standard, and can depend on specific implementations. Does this difference between automatic arrays and allocatable arrays results in any difference in performance? (need to be examined)
Since automatic arrays can have different sizes between different
calling to the subroutine/function
, they are a kind of
adjustable arrays.
In summary, automatic arrays are local arrays
declared in a subroutine/function/block
with definition
involving variables whose values are unknown at compile time.
Automatic arrays are not allowed to have the save
attribute.
The specification of an automatic array is allowed to contain function
calls, which can be either built-in or user-defined functions, with
the only requirement that the functions must be pure
,
i.e., no side effects. One often used function in this case is the
built-in inquiry function size
, which is used to query
the size of other arrays, and then the returned value is used in
defining the automatic array. For example:
real :: myarray(size(a,1), size(a,2))
Local non-constant variables in a subroutine are not allowed to appear in the specification expression of automatic arrays. The reason is that an automatic arry needes to be allocated at the begining of the procedure, but a local variable does not have a defined value just on entry to the routine. Even if we initialize the value of the local variable when declaring it, this value is available only when the first executable statment in the procedure is executed because initialization is an assignment (an executable statement), which is not a pure function.
The specification expression of automatic arrys is allowed to use dummy arguments of the procedure and variables from modules (including its host module if the subroutine is contained in a module).
These rules are also applicable to the dummy argument arrays discussed in Sec. 7.6.
If a dummy argument of a procedure is declared as an array, then generally no array is actually allocated on entry to the procedure. It just refers to the actual argument arrays passed in from the calling unit. So dummy argument arrays are not new type of arrays, but the syntax of declaring them may be different from that of declaring static/automatic/allocatable arrays. And the syntax is used to determine what information of the actual argument array is passed in from the calling units. There are four syntaxes of declaring a dummy argument array:
real :: a(m,n) !explicit shape array real :: b(m,*) !assumed size array, not recomended now. real :: c(2:,3:) !assumed shape array real, allocatable :: d(:,:) !allocatable (dummy argument) array
Let us discuss these four types in turn.
In the first two cases, i.e., explicit shape array
and
assumed size array
, usually just a pointer to the first
element of the actual argument array is passed in. Since only a
pointer is available with no stride being available, the compiler has
to assume that the stride is 1, i.e., the array is contiguous in
memory. If we pass an array slice that is not contiguous in memory to
a dummy argument declared as an explicit shape array/assumed
size array
, a temporary array will be created and the data of
the array slice is copied in (and copied out when the subroutine
returns) in order to guarantee that the resulting array is contiguous
in memory so that the subroutine is doing right to the actual argument
array. For this case, gfortran
will give the following
warning:
Fortran runtime warning: An array temporary was created for argument 'a' of procedure 'p'
If the dummy array is declared as an explicit shape array, rank mismatch between actual array and dummy array is allowed. However, this kind of use is error prone. Most time we prefer that the actual and dummy array have the same shape.
In the above example, the variables m,n
appearing in the
specification expression of the explicit shape array can be dummy
argument variables or module variables, but can not be a local
variable of the procedure. The following is an example of
explicit array:
subroutine p(u,m) use some_module, only : n real :: u(m,n) !explicit shape array end
A common bug when using explicit array is that the rank/extent/bound declared in a procedure are different from those of the actual argument array. As mentioned above, this mismatch is allowed by the compiler. If the mismatch is not intended by the programmer (i.e., the programmer made a mistake in the declaration), then the code usually will not work correctly.
An assumed-size array is an array that is a dummy argument and has an asterisk as the upper bound of the last dimension:
subroutine p( A, B, C ) Integer :: A(*), B(5, *) !lower-bound of the last dimension default to 1 Integer :: C(0:1, 2:*) !explicitly specify the lower-bound of the last dimension end
The extent of the last dimension does not need to be specified because it is not needed (by the compiler) in calculating the memory address offset of an array element with respect to the first element. However, I prefer to use explicit-shape arrays over assumed-sized array since it is not a big deal to just omit a single bound. Omitting the last upper bound also makes bounds checking difficult since the last upper bound is not defined in the subroutine.
To declare an argument as an assumed shape array
, we only
need to specify the rank and the lower bounds along each dimension
(lower bounds default to 1 if not specified). The upper bounds will be
automatically inferred during runtime from the length in each
dimension of the actual array passed in. The following are examples of
assumed shape array:
subroutine p1(A, B) real :: A(0:,2:) !upper bounds will be inferred from the length of the actual array real :: B(:,:) !lower bounds are not specified and are default to 1 end
For the third case, i.e., assumed shape array
, an array
descriptor structure will be passed in, which contains the pointer to
the first element of the actual argument array plus information on the
length of each dimension and stride.
As is mentioned above, if the dummy array is declared as an explicit shape array and we pass in an array slice that is not contiguous in memory, an array temporary will be created and the data of the array slice is copied in and then copied out. On the other hand, if the dummy array is declared as an assumed shape array, no array temporary will be created. However, this does not mean the performance will be better than the case of using explicit shape array, where an temporary array is created and data be copied in and out. This is because the latter case can improve spatial locality in memory access pattern, although involving additional allocations and copying in and out operations. Therefore, which methods will win in terms of performance depends on specific applications.
If the dummy array is declared as an assumed shape array, the compiler will check agreement between the the rank of actual array and dummy array, giving error information if they mismatch. This kind of mismatch is allowed if explicit shape array is used. However, this kind of use is error prone. Most time we prefer that the actual and dummy array have the same shape.
In summary, assumed-shape arrays are dummy argument arrays where the
extent of a dimension is inherited from the corresponding actual
array. The dimensionality (i.e., rank) of the array is known and must
be specified in the subroutine, for example, a(:,:,:)
specifies that the rank is 3. If the actual array and the assumed
shape array have different ranks, a compiler usually complains at
compiling time, for example, gfortran
raises the error
information: Rank mismatch in argument
.
Summary 2: we have two choices in declaring a dummy array in a
subroutine. One choice is to declare it as an explicit shape
array
(using formal argument variables, or modules, or
constants to specify the shape of the array). Another choice is to
define assumed (implicit) shape array
, for which we
specify only the rank and lower bound (the lower bound is 1 if not
specified) of the array and we do not specify the length along each
dimension. The unspecified information will be inferred automatically
from the actual argument array during runtime.
For the fourth case, an dummy argument is declared as an allocatable
array. In this case, the corresponding actual argument must also be an
allocatable array, otherwise gfortran
will raise
Error: Actual argument for ‘a' must be ALLOCATABLE at
(1).
The actual argument allocatable array passed in can be already
allocated, or not allocated yet and it can be allocated in the
subroutine. One can use inquiry function allocated()
to
get the allocation status of an allocatable array passed in.
To define a pure function (functions with no side effects), we use the
keyword pure
. For example:
pure function f(x) result(z) integer, intent(in):: x integer :: z z=x*2 end function f
All dummy argument variables of a pure function must be
intent(in)
. Pure subroutines can be defined in a similar
way, except that the dummy argument variables can have
intent(out)
.
Since pure procedures do not allow side effects (i.e., do not change
the state of the outer world), the compiler will raise error if we try
to modify the value of a variable of a module
that is
used in this procedure:
Error: Variable 'tmp' can not appear in a variable definition context (assignment) in PURE procedure
Fortran pure functions can use module variables as (invisible) input, which can change between function invocations. Therefore fortran pure functions can not guarantee “same argument, same result”. This is different from the pure function concept in funtional programming languages, e.g. Haskell, where “same argument, same result” is guaranteed.
Local variables within the scope of a pure
procedure
cannot have the save
attribute, which implies that they
cannot be initialized when declared, or by a DATA statement.
Any procedures that are invoked from a pure
procedure
must be pure
. No external I/O operations may occur within
a PURE procedure since these change the stae of the outer world, i.e.,
side effects.
Elemental
functions are pure functions defined with a
single scalar dummy argument and a scalar return value, but they can
be invoked with arrays as actual arguments, in which case the function
will be applied element-wise, with a conforming array return value.
This kind of function is indicated with the elemental
prefix. Since it is implied that an elemental function is also pure,
the pure
prefix is not necessary.
module test_mod contains elemental real function square(x) real, intent(in) :: x square = x*x end function end module
Elemental subroutines may be defined in a similar way
(intent(out)
or intent(inout)
arguments are
allowed). The main benefit of elemental procedures is just for syntax
convenience, it does not have semantics that lend themselves to
effective parallelization.
Not all variables are accessible from all parts of our program, and not all variables exist for the same amount of time. Where a variable is accessible and how long it exists depend on how it is defined. We call the part of a program where a variable is accessible its scope, and the duration for which the variable exists its lifetime.
The scope of a variable, more accurately the scope of a naming binding (an association of a name to an entity) is the region of a computer program where the binding is valid: where the name can be used to refer to a value. Such a region is referred to as a scope block. In other parts of the program the name may refer to a different entity (it may have a different binding), or to nothing at all (it may be unbound).
The scope of a binding is also known as the visibility of an entity. In other words, which parts of your program can see or use it. In practice, for most programming languages, “part of a program” refers to “part of the source code”, and is known as lexical scope (another kind of scope called dynamic scope will be discussed later). The lexical scope for a set of bindings in practice largely corresponds to a block, a function, or a file, depending on languages and types of entity.
Unlike C/C++, Fortran before 2008 standard does not have source code
blocks where new variables can be defined. Fortran 2008 introduces the
keyword block
to define blocks, where local variables can
be declared. For examples, the following code defines two nested
blocks in which local variables res1
and
res2
are defined.
PROGRAM foo implicit none INTEGER :: a a=3.0 write(*,*) 'a=',a BLOCK INTEGER :: res1 res1 = a + 1 write(*,*) 'res1=',res1 BLOCK INTEGER :: res2 res2 = res1 + 1 write(*,*) 'res2=',res2,'res1=',res1 ENDBLOCK ENDBLOCK END PROGRAM foo
In summary, the block
creates its own name space.
I use block
to add temporary diagnostic codes to existing
programs. Doing this way allow all temporary local variables to be
gathered together near the diagnostic codes and thus easy to read and
easy to remove. This is more convenient than adding and calling new
external diagnostic subroutines. In passing, adding diagnostic
internal subroutines using contains
is as convenient as
using block
and may be more elegant.
In C/C++, variables defined outside of all functions are global
variables. Fortran does not have such kind of global variables. To
pass information between subroutines, besides using subroutine
parameter lists, one way is to use variables in a module
which can be shared between subroutines.
save
attribute
A local variable defined in a procedure can have the save
attribute, which will make the local variable retain its value between
different procedure calls. These variables are called persistent
variables. For example:
function f() integer, save :: i=1 i = i+1 print *, i end function
However, for multiple-thread applications, this kind of local variable will be shared among different threads, which means that racing problem will appear if the procedure is called in multiple threads. Considering this situation, computer guys often say that this kind of local variables are “thread unsafe”.
A local variables with save
attribute is hidden input to
the procedure in which the variable is defined.
Variables with save
attribute will be alive from their
creation to the end of the program, i.e., they are not automatically
destroyed when they go out of scope. As a result, if the variables
with save
attribute is a local variable defined in a
subroutine, then its value will be retained between different
revocations of the subroutine. In contrast, local variables without
save
attribute will be automatically destroyed when they
go out of scope. As a result, their values can not be retained between
different revocations of the subroutine.
In C language, variables declared outside functions are global
variables, which can be assessed from any functions. Fortran does not
have this kind of global variables, but variables in
modules
are accessible to other program units if the
modules are imported to that unit. In principle, a variable defined in
a module
is a local variable to that module, and will be
destroyed when the program unit that uses the module
returns. However, two situations (often appear in practice) can make
the module variables not be destroyed during the entire runtime: (1)
the module
is used in the main program and thus never
goes out of scope during the runtime, (2) save
attribute
is used for the variables in the module
, so they retain
their values. Most fortran compilers will treat variables defined in a
module
as with save
attribute even if no
save
attribute is specified. But for safety, we should
specify save
attribute for variables in a
module
if we want their values to be retained when they
go out of scope.
The above practice makes module
variables look like
global variables. For this reason, we often simply say that modules
define global data.
Due to the global nature of module
variables, they are
shared across threads and are therefore thread-unsafe. To make an
application thread-safe, we must declare the global data as
THREADPRIVATE or THREADLOCAL.
New syntaxes in a language seldom benefit performance. That is, “code with new syntax” doesn't imply “better compiler optimizations", and even F77 is a “high level” language. Efficient Fortran codes should stick to F77 features at their core for high performance, most of newer features would usually result in less efficient executables. F90 and newer would be mainly useful for readablity, maintainability and extensibility of the code
Do you have some strong evidence to support such statements?
Well, yes, there is evidence for this strategy. I do not claim, that all newer features have a negative impact on performance, or that you should not use them at all. Just in the very kernel, the F77 style is generally a good guide to produce efficient code. (Staying away from pointer and target attributes, do not use fine-grained derived datatypes, there was even a time when array syntax statements are slower than explicit do-loops, though compilers seem to have much improved). I am actually using F2003 features heavily, my point is just in the very kernel, there is probably little benefit.
Vectorization, if by this you mean the F90+ array syntax, is mostly a programmer convenience issue rather than allowing faster code. A competent compiler will vectorize the equivalent DO loop just as well.
There is one major reason why Fortran 77 programs might be faster: Allocated arrays (Fortran 90) are much slower than declared-at-compile-time arrays. Both are not put at the same place in memory (stack vs heap). The difference in memory management of stack and heap in Fortran can change the performance. The Fortran standard has no concept of stack and heap, so this will be implementation (i.e. compiler) dependent.
After Fortran 2008, the recommended way of opening file is as follows:
integer :: myunit open(newunit=myunit, file='myfile.txt') write(myunit, *) 'hello world' !use the unit number to write to the file
Here newunit
is an intent(out)
keyword
argument, which returns an available unit number.
Object-oriented programming style is not often used in numerical codes. Here I discuss this just for my curiosity.
Fortran, the oldest high-level programming language, was designed and used mainly for the purpose of numerical computation. Although Fortran is also claimed as a general-purpose programming language, it lies behind other popular general-purpose Language, such as C/C++ and Python, in some aspects. One of these aspects is the supporting to the object-oriented programming.
Why is the object-oriented programming not widely adopted in scientific computing? Scientific computing often deal with simple data structures with homogeneous elements, such as arrays, which are often the only data structure used in a numerical code. This makes derived types not so frequently needed. Derived types are generalization of arrays and can contain inhomogeneous elements, which provide a more powerful organizing capability than arrays. Classes in object-oriented programming are a special kind of derived types that have procedures bound to.
Fortran's module
can contain both data and procedures.
But we can not use the name of a module to define an object. On the
other hand, module
can contain derived type definition
and this derived type can be used to define an object. Therefore a
Fortran module
containing both derived type definitions
and procedures can be used as the counterpart of class
in
object-oriented languages. However the binding between a derived type
object and its procedures must be implemented manually by programmers
before Fortran 2003. The following is a Fortran 95 example emulating
object-oriented programming style.
module class_point implicit none type, public :: point real :: x real :: y end type point contains function distance(this) result(z) !distance from origin type(point), intent(in) :: this real :: z z = sqrt((this%x)**2+(this%y)**2) end function distance subroutine add(this,another,my_sum) type(point), intent(in) :: this, another type(point):: my_sum my_sum%x=this%x+another%x my_sum%y=this%y+another%y end subroutine add subroutine print_point(this) class(point), intent(in) :: this real :: tmp tmp = distance(this) print *, 'Point: (x,y) = ', this%x, this%y, ' distance from orig = ', tmp end subroutine print_point end module class_point program point_test use class_point,only: point, distance,add, print_point implicit none type(point) :: p1,p2,p3 ! Declare variables of type point. p1 = point(3.0,4.0) ! Use the implicit constructor call print_point(p1) !pass the object to the procedure via a argument p2 = point(1.0,0.5) ! Use the implicit constructor call add(p1,p2,p3) call print_point(p3) end program point_test
The above is not real object-oriented programming because the
procedures are not actually bound to the object. Fortran 2003 provides
type-bound procedures: those procedures that appear in the definition
of the derived type following the contains
statement. The
following is a revised version of the above program.
module class_point implicit none private !set the default as private type, public :: point real :: x real :: y contains procedure:: distance procedure:: printp procedure:: add procedure:: add_func end type point contains function distance(this) result(z) !distance from origin class(point), intent(in) :: this real :: z z = sqrt((this%x)**2+(this%y)**2) end function distance subroutine add(this,another,my_sum) class(point), intent(in) :: this, another class(point):: my_sum my_sum%x=this%x+another%x my_sum%y=this%y+another%y end subroutine add function add_func(this,another) result(my_sum) class(point), intent(in) :: this type(point), intent(in):: another type(point):: my_sum my_sum%x=this%x+another%x my_sum%y=this%y+another%y end function add_func subroutine printp(this) class(point), intent(in) :: this real :: tmp tmp = this%distance() ! Call the type-bound function print *, 'Point: (x,y) = ', this%x, this%y, ' distance from orig = ', tmp end subroutine printp end module class_point program test use class_point implicit none type(point) :: p1,p2,p3 ! Declare a variable of type point. p1 = point(3.0,4.0) !Use the implicit constructor call p1%printp !Call the type-bound subroutine p2 = point(1.0,0.5) ! Use the implicit constructor call p2%printp call p1%add(p2,p3) call p3%printp print *, p1%add_func(p2) end program test
Three things need to be noted. First, two contains
appear
here, one of which bounds the procedures names to the derived type and
another is the same as the above, i.e., contains the definition of the
procedures. Second, in the definition of the procedure, the first
argument must be of the same type of the derived type and the
declaration using the class
keyword, instead of the
type
keyword. This a fundamental requirement for
type-bound procedures. If declared using type
, gfortran
compiler would raise the following error: Non-polymorphic
passed-object dummy argument. This is required by compilers to
consider this procedure as a type-bound procedure rather than an
ordinary one. Third, when calling the type-bound procedure, the object
is passed to the procedure in the object-oriented way, e.g.,
p1%print_point
rather than print_point(p1)
.
Viktor K. Decyk's paper on this.
The code which modifies a given data structure should be localized or confined to one location in the program and not spread, uncontrollably, throughout the program. This property is called an encapsulation. In a sense, it is a generalization of the familiar notion of a function or subroutine.
http://www.cs.rpi.edu/~szymansk/OOF90/F90_Objects.html
It is a good practice to place procedures in modules (instead of internal procedures or external procedures) as it helps the compiler to detect programming errors and to optimize the code.
Subroutines should be kept reasonably short (e.g. about 50 lines (usually difficult) so that they can fill in one screen and thus are easy to read).
We now usually do not need to worry about the start up overheads involved in calling a subroutine, because some short subroutines can be “inlined” by compilers so that the inefficiency is generally not a problem.
Each module
should be in a separate file.
Any code that introduces new physics to a code should have a switch to enable it to be turned off. This makes it possible to run the model in a configuration that is identical to the model before the new physics went in, in order to check that nothing unexpected has been broken.
Code should be accompanied by technical documentation describing the physical processes that the additional code is intended to model and how this is achieved. Any equations used should be documented (in their continuous form where appropriate) along with the methods used to discretise these equations.
Always bear in mind that somebody will have to maintain your code in the future. That person could be you several years later. Commenting the source lines that are not obvious from common senses. But do not make too extensive/detailed/specific comments because the details have good chance to become out-dated when codes are updated, which will make the comments inconsistent with the codes, causing confusion rather than clarification to code maintainers. Also, note that it is the code itself rather than the comment that is the final and absolute definition of what is exactly done in the code (i.e., every source code is self-documenting if you understand it). Therefore rather than investing much time in writing comments, we should spend more time in making the algorithm and code easy to understand even if there is no comment. Comments should be used to state the reason for doing something, instead of repeating the Fortran logic in words.
The goal of all these practice is to reduce the chance of introducing bugs.
All routines and documentation must be written using SI units. Standard SI prefixes may be used. Where relevant, the units used must be clearly stated in both code and documentation.
Try to find some ways to test your code. Do not ignore compiler warnings, as they may point you to potential problems.
http://jules-lsm.github.io/coding_standards/guidelines/best_practices.html
We tend to criticize other's coding style when we see a messy code. But think twice before criticizing.
At first glance of a code, your judgment of its readability is often false because it is based on the simple appearance of the code, i.e., whether the code is neat enough rather than whether its logical is clear/straightforward or not, ==>psychological reasons.
But we should realize that work and life seem to be always in a hurry.
http://annefou.github.io/Fortran/modules/modules.html
Ref:
https://www.phy.ornl.gov/csep/pl/node1.html(this is very good)
Where are the stack and heap stored? They are both stored in the computer's RAM (Random Access Memory). Using RAM is faster than using virtual memory (paging file/swap file).
Stack frame access is easier than the heap frame as the stack allocation happens on contiguous blocks of memory and hence is cache friendly, but in case of heap frames which are dispersed throughout the memory so it cause more cache misses. Note that the above being continugous or dispersed in memory refers to the storage of different variables, For a single array, all the data element are gauranteed to be continous in memory regardless they are on stack or heap.
In a stack, the allocation and deallocation is automatically done, whereas, in heap, it needs to be done by the programmer manually.
However, it is generally better to consider “scope” and “lifetime” rather than “stack” and “heap”.
Scope refers to what parts of the code can access a variable. Generally we think of local scope (can only be accessed by the current function) versus global scope (can be accessed anywhere).
Lifetime refers to when a variable is allocated and deallocated during program execution. Usually we think of static allocation (variable will persist through the entire duration of the program, making it useful for storing the same information across several function calls) versus automatic allocation (variable only persists during a single call to a function, making it useful for storing information that is only used during your function and can be discarded once you are done) versus dynamic allocation (variables whose duration is defined at runtime, instead of compile time like static or automatic).
Although most compilers and interpreters implement this behavior similarly in terms of using stacks, heaps, etc, a compiler may sometimes break these conventions if it wants as long as behavior is correct. For instance, due to optimization a local variable may only exist in a register or be removed entirely, even though most local variables exist in the stack. You are free to implement a compiler that doesn't even use a stack or a heap, but instead some other storage mechanisms (rarely done, since stacks and heaps are great for this).
A particularly poignant example of why it's important to distinguish between lifetime and scope is that a variable can have local scope but static lifetime. In the context of lifetime, “static” always means the variable is allocated at program start and deallocated when program exits.
The value of a local scalar can be retained between different calls to
the subroutine/function
(by using save
keyword or compiler option to save all local variables) but automatic
arrays can not have the save
attribute.


Loream ipsu dolor sit amet, consectetur adipisicing elit.
Innovate and moderm responsive web design and development
Mobile application development and its marketing
We analyse ypur product in current market and look for the growth opportunity
Loream ipsu dolor sit amet, consectetur adipisicing elit.
Market compatiable price with other benefits
This is our bronze packages
This is our silver packages
This is our gold packages
Loream ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
Loream ipsum dolot sit amet, consectetur adipisicing elit, sed do eiusmod


Zend_Console_Getopt is a class to parse options for command-line applications.
LICENSE
This source file is subject to the new BSD license that is bundled with this package in the file LICENSE.txt. It is also available through the world-wide-web at this URL: http://framework.zend.com/license/new-bsd If you did not receive a copy of the license and are unable to obtain it through the world-wide-web, please send an email to<EMAIL_ADDRESS>so we can send you a copy immediately.
Zend_Console_Getopt is a class to parse options for command-line applications.
Terminology: Argument: an element of the argv array. This may be part of an option, or it may be a non-option command-line argument. Flag: the letter or word set off by a '-' or '--'. Example: in '--output filename', '--output' is the flag. Parameter: the additional argument that is associated with the option. Example: in '--output filename', the 'filename' is the parameter. Option: the combination of a flag and its parameter, if any. Example: in '--output filename', the whole thing is the option.
The following features are supported:
The format for specifying options uses a PHP associative array. The key is has the format of a list of pipe-separated flag names, followed by an optional '=' to indicate a required parameter or '-' to indicate an optional parameter. Following that, the type of parameter may be specified as 's' for string, 'w' for word, or 'i' for integer.
Examples: - 'user|username|u=s' this means '--user' or '--username' or '-u' are synonyms, and the option requires a string parameter. - 'p=i' this means '-p' requires an integer parameter. No synonyms. - 'verbose|v-i' this means '--verbose' or '-v' are synonyms, and they take an optional integer parameter. - 'help|h' this means '--help' or '-h' are synonyms, and they take no parameter.
The values in the associative array are strings that are used as brief descriptions of the options when printing a usage message.
The simpler format for specifying options used by PHP's getopt() function is also supported. This is similar to GNU getopt and shell getopt format.
Example: 'abc:' means options '-a', '-b', and '-c' are legal, and the latter requires a string parameter.
MODE_ZEND
= 'zend'
The options for a given application can be in multiple formats.
modeGnu is for traditional 'ab:c:' style getopt format. modeZend is for a more structured format.
CONFIG_RULEMODE
= 'ruleMode'
These are constants for optional behavior of this class.
ruleMode is either 'zend' or 'gnu' or a user-defined mode. dashDash is true if '--' signifies the end of command-line options. ignoreCase is true if '--opt' and '--OPT' are implicitly synonyms. parseAll is true if all options on the command line should be parsed, regardless of whether an argument appears before them.
array
$_argv= 'array'
Stores the command-line arguments for the calling applicaion.
array
Details
$_getoptConfig= 'array'
Defaults for getopt configuration are: ruleMode is 'zend' format, dashDash (--) token is enabled, ignoreCase is not enabled, parseAll is enabled.
array
Detailsarray
$_options= 'array'
Stores options given by the user in the current invocation of the application, as well as parameters given in options.
array
Detailsboolean
$_parsed= 'false'
State of the options: parsed or not yet parsed?
false
Detailsarray
$_remainingArgs= 'array'
Stores the command-line arguments other than options.
array
Detailsarray
$_ruleMap= 'array'
Stores alternate spellings of legal options.
array
Details__construct(
array $rules, array $argv
=
null, array $getoptConfig
=
array
)
:
void
The constructor takes one to three parameters.
The first parameter is $rules, which may be a string for gnu-style format, or a structured array for Zend-style format.
The second parameter is $argv, and it is optional. If not specified, $argv is inferred from the global argv.
The third parameter is an array of configuration parameters to control the behavior of this instance of Getopt; it is optional.
| Name | Type | Description |
|---|---|---|
| $rules | array | |
| $argv | array | |
| $getoptConfig | array |
__get(
string $key
)
:
string
Return the state of the option seen on the command line of the current application invocation. This function returns true, or the parameter to the option, if any. If the option was not given, this function returns null.
The magic __get method works in the context of naming the option as a virtual member of this class.
| Name | Type | Description |
|---|---|---|
| $key | string |
| Type | Description |
|---|---|
| string |
__isset(
string $key
)
:
boolean
Test whether a given option has been seen.
| Name | Type | Description |
|---|---|---|
| $key | string |
| Type | Description |
|---|---|
| boolean |
__set(
string $key, string $value
)
:
void
Set the value for a given option.
| Name | Type | Description |
|---|---|---|
| $key | string | |
| $value | string |
__toString(
)
:
string
Return the current set of options and parameters seen as a string.
| Type | Description |
|---|---|
| string |
_addRulesModeGnu(
string $rules
)
:
void
Define legal options using the gnu-style format.
| Name | Type | Description |
|---|---|---|
| $rules | string |
_addRulesModeZend(
array $rules
)
:
void
Define legal options using the Zend-style format.
| Name | Type | Description |
|---|---|---|
| $rules | array |
| Exception | Description |
|---|---|
| \Zend_Console_Getopt_Exception |
_checkParameterType(
string $flag, string $param
)
:
bool
Return true if the parameter is in a valid format for the option $flag.
Throw an exception in most other cases.
| Name | Type | Description |
|---|---|---|
| $flag | string | |
| $param | string |
| Type | Description |
|---|---|
| bool |
| Exception | Description |
|---|---|
| \Zend_Console_Getopt_Exception |
_parseLongOption(
mixed $argv
)
:
void
Parse command-line arguments for a single long option.
A long option is preceded by a double '--' character. Long options may not be clustered.
| Name | Type | Description |
|---|---|---|
| $argv | mixed | &$argv |
_parseShortOptionCluster(
mixed $argv
)
:
void
Parse command-line arguments for short options.
Short options are those preceded by a single '-' character. Short options may be clustered.
| Name | Type | Description |
|---|---|---|
| $argv | mixed | &$argv |
_parseSingleOption(
string $flag, mixed $argv
)
:
void
Parse command-line arguments for a single option.
| Name | Type | Description |
|---|---|---|
| $flag | string | |
| $argv | mixed |
| Exception | Description |
|---|---|
| \Zend_Console_Getopt_Exception |
addArguments(
array $argv
)
:
\Zend_Console_Getopt
Define additional command-line arguments.
These are appended to those defined when the constructor was called.
| Name | Type | Description |
|---|---|---|
| $argv | array |
| Type | Description |
|---|---|
| \Zend_Console_Getopt | Provides a fluent interface |
| Exception | Description |
|---|---|
| \Zend_Console_Getopt_Exception | When not given an array as parameter |
addRules(
array $rules
)
:
\Zend_Console_Getopt
Define additional option rules.
These are appended to the rules defined when the constructor was called.
| Name | Type | Description |
|---|---|---|
| $rules | array |
| Type | Description |
|---|---|
| \Zend_Console_Getopt | Provides a fluent interface |
getOption(
string $flag
)
:
mixed
Return the state of the option seen on the command line of the current application invocation.
This function returns true, or the parameter value to the option, if any. If the option was not given, this function returns false.
| Name | Type | Description |
|---|---|---|
| $flag | string |
| Type | Description |
|---|---|
| mixed |
getOptions(
)
:
array
Return a list of options that have been seen in the current argv.
| Type | Description |
|---|---|
| array |
getRemainingArgs(
)
:
array
Return the arguments from the command-line following all options found.
| Type | Description |
|---|---|
| array |
getUsageMessage(
)
:
string
Return a useful option reference, formatted for display in an error message.
Note that this usage information is provided in most Exceptions generated by this class.
| Type | Description |
|---|---|
| string |
parse(
)
:
\Zend_Console_Getopt|null
Parse command-line arguments and find both long and short options.
Also find option parameters, and remaining arguments after all options have been parsed.
| Type | Description |
|---|---|
| \Zend_Console_Getoptnull | Provides a fluent interface |
setAliases(
array $aliasMap
)
:
\Zend_Console_Getopt
Define aliases for options.
The parameter $aliasMap is an associative array mapping option name (short or long) to an alias.
| Name | Type | Description |
|---|---|---|
| $aliasMap | array |
| Type | Description |
|---|---|
| \Zend_Console_Getopt | Provides a fluent interface |
| Exception | Description |
|---|---|
| \Zend_Console_Getopt_Exception |
setArguments(
array $argv
)
:
\Zend_Console_Getopt
Define full set of command-line arguments.
These replace any currently defined.
| Name | Type | Description |
|---|---|---|
| $argv | array |
| Type | Description |
|---|---|
| \Zend_Console_Getopt | Provides a fluent interface |
| Exception | Description |
|---|---|
| \Zend_Console_Getopt_Exception | When not given an array as parameter |
setHelp(
array $helpMap
)
:
\Zend_Console_Getopt
Define help messages for options.
The parameter $help_map is an associative array mapping option name (short or long) to the help string.
| Name | Type | Description |
|---|---|---|
| $helpMap | array |
| Type | Description |
|---|---|
| \Zend_Console_Getopt | Provides a fluent interface |
setOption(
string $configKey, string $configValue
)
:
\Zend_Console_Getopt
Define one configuration option as a key/value pair.
These are not program options, but properties to configure the behavior of Zend_Console_Getopt.
| Name | Type | Description |
|---|---|---|
| $configKey | string | |
| $configValue | string |
| Type | Description |
|---|---|
| \Zend_Console_Getopt | Provides a fluent interface |
setOptions(
array $getoptConfig
)
:
\Zend_Console_Getopt
Define multiple configuration options from an associative array.
These are not program options, but properties to configure the behavior of Zend_Console_Getopt.
| Name | Type | Description |
|---|---|---|
| $getoptConfig | array |
| Type | Description |
|---|---|
| \Zend_Console_Getopt | Provides a fluent interface |
toArray(
)
:
array
Return the current set of options and parameters seen as an array of canonical options and parameters.
Clusters have been expanded, and option aliases have been mapped to their primary option names.
| Type | Description |
|---|---|
| array |
toJson(
)
:
string
Return the current set of options and parameters seen in Json format.
| Type | Description |
|---|---|
| string |
toString(
)
:
string
Return the current set of options and parameters seen as a string.
| Type | Description |
|---|---|
| string |


%- include('../common/css-container.html') -%>
<%- include('../common/head.html')%>
<%- include('../common/js-container.html') -%>


Basic example
Quick links
-
Project structure -
Installation -
Create entry.js -
Create index.html -
Create our fist page -
Create another page -
Create component -
Setup development environment -
Lets run it - Basic example Github repo
A quick note
This is a bare bones example, if you want an example with a production build process check out the Quick start
If you looking for a real world example, you can check out the repo for this website. The PAX documentation website is built using itself. GitHub Repo
Project structure
Installation
You can install pax-core through NPM
Create entry js
Create entry js app/entry.js
Create index html
Create index html app/index.html
Create our fist page
Create page file app/pages/home.js
Create another page
Create another page file app/pages/another.js
Create component
Create component file app/components/custom-button.js
Setup development environment
We are using snowpack for this, but you can use your preferred local dev setup.
Create snowpack config file /snowpack.config.json
Lets run it
We are using snowpack for this example


Strong engineering professional with a Master’s Degree focused on Computer Science from Georgia Institute of Technology.
Experienced Machine Learning Engineer with a demonstrated history of working in the Identity & Access Management (IAM), software deployments and services industry. Skilled in Machine Learning, Deep Learning, Keras, PyTorch, Tensorflow, scikit-learn, NLTK, Python, Java, and MEAN Stack.
March 2020 - Present
Vancouver, Canada
VISO PRISM: Currently working on inappropriate content detection in Youtube as per BBTV Trust and Safety policy for enhanced Brand Safety in advertising by using ML classifier system.
VISO Spotlight: Led the Research team to improve search of relevant content for Ad Sales and Content Discovery Team by generating summaries of videos using keyword extraction and named entities recognition algorithms from youtube video meta-data like Title, Description, transcripts, and comments
VISO Score: Build DL based system to provide a unique ranking score to each youtube video based on brand safety, performance metrics and perceived sentiment of viewers. Trained and put into production Sentiment analysis models on noisy youtube video comments, models for offensive content detection in youtube videos and ML models on metadata statistics to give youtube videos a performance metric score.
Tools: Python, PyTorch, Transformers, SimpleTransformers,NLTK, Spacy, Flair, Vader, AllenNLP, scikit-learn, NER-D, PKE toolkit, HuggingFace NLP, Wandb, AWS Cloud Training
July 2018 - Feb 2020
Project VerifAI 360: Lead designer and developer of VerifAI 360, a testing framework for Deep Learning (DL) Models against metrics like accuracy, model bias, adversarial robustness, sensitivity, and explainability supporting intelligent test case generation techniques for text data, image data, audio data, structured data, watson conversation data, and time series data. Lead new client engagements and supported Business Development team with POCs. Now part of IBM’s Ignite Automation Testing Platform.
Data Augmentation for NLP Applications: Worked on novel data augmentation strategies to improve data volume and variety to improve the model’s robustness like typos, paraphrase, tense variation, adding noise, voice variations, adjective variations, sentence ordering, and etc. Filed a disclosure & published a paper.
Creative Generation of Fashion Images: Intelligent augmentation using external common-sense knowledge to generate new fashion images instead of random transforms. Worked on various GAN formulations and implemented state-of-art GAN models. Filed a disclosure.
Tools: Python, Java, Keras, PyTorch, Tensorflow, Flask, Swagger, NLTK, Spacy, scikit-learn, StanfordNLP, Gensim, OpenCV, Watson Machine Learning, IBM Cloud Object Store,MongoDB
May 2016 - July 2016
Taught 20 High school students Scratch, Python basics, pygame & turtle library, HTML, CSS, Javascript, bootstrap, Algorithms and Robotics using Arduino.
Feb 2011 - May 2013
Customer Support Engineer: Provided functional & technical support for NERC CIP, SOX audit compliance, IT OT convergence and Access & Identity management to US Utility companies (FPL, Duke Energy, NIPSCO, SRP, CPS Energy, ITC) that use Alert Enterprise’s (a subsidiary of Start Up Farms) Identity and Access Management solutions for Critical Infrastructure protection. Provided technical support and configuration change management to customer & onsite teams.
Specialist Developer: Prototyping, developing, testing and supporting new features and functions with focus on enabling and implementing unique client-side behaviors into Enterprise Sentry solution which leverages unique Security Convergence capabilities that combine cyber security and physical security for enterprises following agile development methodologies. Developed various Java APIs for populating data in reports and integrating with other applications. Developed features and unit test code as per new customer requirements
July 2009 - March 2011
Travel website development: Used ASP.Net, ADO.Net, SQL Server 2008, C#, VSS, Ajax and VSS.
CGC Oracle Consolidation Assessment & Migration: Oracle 11g, .Net Applications, Sun Solaris Platform Analyzed and migrated Capital Group of Companies’ legacy servers from HP to Sun Solaris. Developed a .Net program to analyze data and generate server, database, and application migration reports.
2014 - 2016
Master of Computer Science
GPA - 3.90/4
Specialized in Interactive Intelligence. Project advisors: Dr. David Joyner and Dr. Ashok Goel
2009 - 2013
Bachelor of Engineering in Information Technology
GPA - 3.93/4
- Deep Learning, a 5-course specialization by deeplearning.ai on Coursera. Specialization Certificate
- Keras, PyTorch, Tensorflow, scikit-learn
- NLTK, Spacy, Transformers, AllenNLP, StanfordNLP
- Watson Studio
- MEANStack
- AngularJS
- JavaScript
- SQL
- MongoDB
- Ruby on Rails
- Android Development
- IBM Bluemix
- IBM Cloud Object Store
- Python
- Java (J2EE)
- Ruby
- C/C++
- Python-Flask
- Java Springs
- Swagger
- SDLC - Agile & Waterfall Methodology
- Identity & Access Management
- Project Management Foundations Certification
WiML 2020
Authors: J. Kaur, R. Lui, F. Faradji, G. Mercey, G. Ohashi, M. Fatourechi
2019
Authors: U. Desai, J. Kaur, S. Khare, S. Tamilselvam, S. Mani
2019
Authors: J. Kaur, A. Sankaran, N. Panwar, T. Tater
2019
Authors: J. Kaur, A. Sankaran, S. Tamilselvam, S. Mani, U. Desai, S. Khare, N. Panwar, A. Sethi
2019
Authors: J. Kaur, A. Sankaran, S. Suri, S. Tamilselvam, S. Mani, U. Desai


|
Party ID
|
Standard Price Schedule
|
Replenishment Price Schedule
|
|
|---|---|---|---|
| {{assignment.UserID || assignment.UserGroupID || assignment.BuyerID}} (Buyer) | {{assignment.StandardPriceScheduleID}} None | {{assignment.ReplenishmentPriceScheduleID}} None |


Choose the Username and Password from the list to authenticate to the Hub server.
Alternatively, choose the Api Token from the list to authenticate to the Hub server.
If the credentials you are looking for are not in the list then you can add them with the Add button.


Contact Us
We are excited to hear from you, please contact us with any information you would like to share regradless if it is a dog or cat info, we want to here about it.
Below is our contact info, please feel free to reach out to us anytime
Dog & Cat1145 W Wilson Ave.
Chicago IL, 60640 Call:<PHONE_NUMBER> Email: dog&cat@example.com


@* * Copyright 2023 HM Revenue & Customs * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. *@ @import config.{ApplicationConfig} @import include._ @import models.asp._ @import include.forms2._ @this(main: include.main) @(f: forms.Form2[_],model: Asp)(implicit request: Request[_],m:Messages, lang: Lang, appConfig: ApplicationConfig) @header = { @heading("title.cya", "summary.asp") } @main( title = Messages("title.cya") + " - " + Messages("summary.asp"), heading = header ) {


vignettes/calibration-data.Rmd
calibration-data.Rmd
A multiproxy calibration dataset to estimate PDFs from a global collection of geolocalised presence-only data (hereafter proxy distributions) was first presented in [1]. These data were obtained from the Global Biodiversity Information Facility (GBIF) database, an online collection of geolocalised observations of biological entities. The calibration dataset (hereafter gbif4crest) contains the species distributions of six common palaeoecological fossil: the five taxa presented in the original version of the dataset — plants [2-12] for fossil pollen and macrofossils, chironomids [13], beetles [14], diatoms [15] and foraminifera [16] – to which rodents [17] were recently added (Fig. 1).
The coordinates of all the presence records of these six common
palaeoecological fossil proxies were upscaled at a spatial resolution of
0.25 x 0.25° (hereafter QDGC for Quarter-Degree Grid Cell) and
subsequently associated with terrestrial and oceanic environmental
variables at the same resolution [18-24] (see details in Table 1).
The QDGC spatial resolution is an empirical trade-off between numerous
factors, including the resolution of the presence data, the quality of
the data or the spatial representativity of the studied proxy. However,
this tradeoff may be suboptimal in some situations, and for that reason,
crestr
can also be used with the raw GBIF data and even
alternative calibration datasets.
In its current version (V2), the gbif4crest calibration
dataset contains about 25.3 million unique presence data for the six
proxies. Unfortunately, the density of available data varies strongly
between proxies and regions (Fig. 1). Plant data
dominate the calibration dataset (>22 million unique occurrences) and
allow for the use of crestr
across all landmasses where
vegetation currently grows. For the five other proxies, the datasets are
still incomplete in many regions, restricting the use of
crestr
(e.g. chironomids). However, these datasets
are regularly updated by GBIF. For example, the first version of the
gbif4crest dataset released in 2018 contained about 17.5
million QDGC entries, but the new version presented here contains nearly
25.3 million entries (~44% increase). The range of ‘reconstructible’
areas is thus rapidly broadening (see, for instance, the coverage of
Russia by plant data compared to the first version of the
gbif4crest dataset [1].
Table 1 List of terrestrial and marine variables available in the gbif4crest database. Each one can be selected in crestr using its associated code. List of abbreviations: (Temp.) Temperature, (Precip.) Precipitation, (SST) Sea Surface Temperature, (SSS) Sea Surface Salinity.
| Code | Full name | Source |
|---|---|---|
| bio1 | Mean Annual Temp. (°C) | [18] |
| bio2 | Mean Diurnal Range (°C) | [18] |
| bio3 | Isothermality (x100) | [18] |
| bio4 | Temp. Seasonality (standard deviation x100) (°C) | [18] |
| bio5 | Max Temp. of the Warmest Month (°C) | [18] |
| bio6 | Min Temp. of the Coldest Month (°C) | [18] |
| bio7 | Temp. Annual Range (°C) | [18] |
| bio8 | Mean Temp. of the Wettest Quarter (°C) | [18] |
| bio9 | Mean Temp. of the Driest Quarter (°C) | [18] |
| bio10 | Mean Temp. of the Warmest Quarter (°C) | [18] |
| bio11 | Mean Temp. of the Coldest Quarter (°C) | [18] |
| bio12 | Annual precip. (mm) | [18] |
| bio13 | Precip. of the Wettest Month (mm) | [18] |
| bio14 | Precip. of the Driest Month (mm) | [18] |
| bio15 | Precip. Seasonality (Coefficient of Variation) (mm) | [18] |
| bio16 | Precip. of the Wettest Quarter (mm) | [18] |
| bio17 | Precip. of the Driest Quarter (mm) | [18] |
| bio18 | Precip. of the Warmest Quarter (mm) | [18] |
| bio19 | Precip. of the Coldest Quarter (mm) | [18] |
| ai | Aridity Index (unitless) | [19] |
| sst_ann | Mean Annual SST (°C) | [20] |
| sst_jfm | Mean Winter SST (°C) | [20] |
| sst_amj | Mean Spring SST (°C) | [20] |
| sst_jas | Mean Summer SST (°C) | [20] |
| sst_ond | Mean Fall SST (°C) | [20] |
| sss_ann | Mean Annual SSS (PSU) | [21] |
| sss_jfm | Mean Winter SSS (PSU) | [21] |
| sss_amj | Mean Spring SSS (PSU) | [21] |
| sss_jas | Mean Summer SSS (PSU) | [21] |
| sss_ond | Mean Fall SSS (PSU) | [21] |
| diss_oxy | Dissolved Oxygen Concentration (mol/L) | [22] |
| nitrate | Nitrate Concentration (mol/L) | [23] |
| phosphate | Phosphate Concentration (mol/L) | [23] |
| silicate | Silicate Concentration (mol/L) | [23] |
| icec_ann | Mean Annual Sea Ice Concentration (%) | [24] |
| icec_jfm | Mean Winter Sea Ice Concentration (%) | [24] |
| icec_amj | Mean Spring Sea Ice Concentration (%) | [24] |
| icec_jas | Mean Summer Ice Concentration (%) | [24] |
| icec_ond | Mean Fall Sea Ice Concentration (%) | [24] |
All these data were curated in a relational database to ensure the
consistency of the data (Fig. 2). The
gbif4crest database is composed of three main types of data:
taxonomic data (TAXA
table on Fig. 2),
distribution data (DISTRIB
and DISTRIB_QDGC
tables) and diverse geopolitical, climatological and environmental data
(DATA_QDGC
table). Its structure is slightly different from
the first version, with a grouping of all the distinct QDGC tables in a
unique DATA_QDGC
table to enable a faster data extraction.
Additional environmental and geographical descriptors were added to
characterise each grid cell and enable a more refined data selection.
These include elevation and elevation variability [25], the country (www.naturalearthdata.com) or ocean (www.marineregions.org) names, as well as different
levels of ecological classification for the terrestrial [26] and marine [27]
realms. The first and last observation dates are also now included,
along with the type of observation, as reported by GBIF (see
DISTRIB_QDGC
table on Fig. 2). Finally,
the DATA
table was entirely recalculated using a new
protocol that better accounts for coastal margins. Climate values at
some locations are thus expected to be slightly different from the first
version of the gbif4crest dataset.
Due to its large size (about 23 Gb), this database is not downloaded
when installing the package, but it can be assessed differently. First,
the data are stored in an open-access, cloud-based PostgreSQL database
that can be dynamically accessed via crestr
. Second, the
database can also be downloaded as a SQLite3 file format from here to work offline. No a priori SQL
knowledge is required to use any of these two options, so that users can
benefit from the package’s interface to automatically query the database
simply by providing study-specific parameters, such as the name of the
taxa or boundaries for the study area, to import all the necessary data
in the correct format to the R environment. Alternatively, advanced
users can also directly query the database to extract and curate data
from the DISTRIB
or DISTRIB_QDGC
tables using
the dbRequest()
function, and subsequently associate these data with climate
variables.
[1] Chevalier, M., 2019. Enabling possibilities to quantify past climate from fossil assemblages at a global scale. Global and Planetary Change, 175, pp. 27–35. doi:10.1016/j.earscirev.2020.103384.
[2] GBIF, 2020, Anthocerotopsida occurrence data downloaded on September 24th, 2020. doi:10.15468/dl.t9zenf.
[3] GBIF, 2021, Bryophyta occurrence data downloaded on August 2nd, 2021. doi:10.15468/DL.WD527G.
[4] GBIF, 2020, Cycadopsidae occurrence data downloaded on September 24th, 2020. doi:10.15468/dl.sfjzxu.
[5] GBIF, 2020, Gingkoopsidae occurrence data downloaded on September 24th, 2020. doi:10.15468/dl.da9wz8.
[6] GBIF, 2020, Gnetopsidae occurrence data downloaded on September 24th, 2020. doi:10.15468/dl.h2kjnc.
[7] GBIF, 2020, Liliopsida occurrence data downloaded on September 24th, 2020. doi:10.15468/dl.axv3yd.
[8] GBIF, 2020, Lycopodiopsida occurrence data downloaded on September 24th, 2020. doi:10.15468/dl.ydhyhz.
[9] GBIF, 2020, Magnoliopsida occurrence data downloaded on September 24th, 2020. doi:10.15468/dl.ra49dt.
[10] GBIF, 2021, Marchantiophyta occurrence data downloaded on August 2nd, 2021. doi:10.15468/DL.M2SSE4.
[11] GBIF, 2020, Pinopsidae occurrence data downloaded on September 24th, 2020. doi:10.15468/dl.x2r7pa.
[12] GBIF, 2020, Polypodiopsida occurrence data downloaded on September 24th, 2020. doi:10.15468/dl.87tbp6.
[13] GBIF, 2020, Chironomids occurrence data downloaded on September 24th, 2020. doi:10.15468/dl.jv3wsh.
[14] GBIF, 2020, Beetles occurrence data downloaded on September 24th, 2020. doi:10.15468/dl.nteruy.
[15] GBIF, 2020, Diatoms occurrence data downloaded on September 24th, 2020. doi:10.15468/dl.vfr257.
[16] GBIF, 2020, Foraminifera occurrence data downloaded on September 24th, 2020. doi:10.15468/dl.692yg6.
[17] GBIF, 2020, Rodentia occurrence data downloaded on September 24th, 2020. doi:10.15468/dl.fscw6q.
[18] Fick, S.E. and Hijmans, R.J., 2017, WorldClim 2: new 1-km spatial resolution climate surfaces for global land areas. International Journal of Climatology, 37, pp. 4302–4315. doi:10.1002/joc.5086.
[19] Zomer, R.J., Trabucco, A., Bossio, D.A. and Verchot, L. V., 2008, Climate change mitigation: A spatial analysis of global land suitability for clean development mechanism afforestation and reforestation. Agriculture, Ecosystems & Environment, 126, pp. 67–80. doi:10.1016/j.agee.2008.01.014.
[20] Locarnini, R.A., Mishonov, A.V., Baranova, O.K., Boyer, T.P., Zweng, M.M., Garcia, H.E., Reagan, J.R., Seidov, D., Weathers, K.W., Paver, C.R., Smolyar, I.V. and Others, 2019, World ocean atlas 2018, volume 1: Temperature. NOAA Atlas NESDIS 81, pp. 52pp. data access.
[21] Zweng, M.M., Seidov, D., Boyer, T.P., Locarnini, R.A., Garcia, H.E., Mishonov, A.V., Baranova, O.K., Weathers, K.W., Paver, C.R., Smolyar, I.V. and Others, 2018, World Ocean Atlas 2018, Volume 2: Salinity. NOAA Atlas NESDIS 82, pp. 50pp. data access.
[22] Garcia, H.E., Weathers, K.W., Paver, C.R., Smolyar, I.V., Boyer, T.P., Locarnini, R.A., Zweng, M.M., Mishonov, A.V., Baranova, O.K., Seidov, D. and Reagan, J.R., 2019, World Ocean Atlas 2018, Volume 3: Dissolved Oxygen, Apparent Oxygen Utilization, and Dissolved Oxygen Saturation.. NOAA Atlas NESDIS 83, pp. 38pp. data access.
[23] Garcia, H.E., Weathers, K.W., Paver, C.R., Smolyar, I.V., Boyer, T.P., Locarnini, R.A., Zweng, M.M., Mishonov, A.V., Baranova, O.K., Seidov, D., Reagan, J.R. and Others, 2019, World Ocean Atlas 2018. Vol. 4: Dissolved Inorganic Nutrients (phosphate, nitrate and nitrate+nitrite, silicate). NOAA Atlas NESDIS 84, pp. 35pp. data access.
[24] Reynolds, R.W., Smith, T.M., Liu, C., Chelton, D.B., Casey, K.S. and Schlax, M.G., 2007, Daily high-resolution-blended analyses for sea surface temperature. Journal of Climate, 20, pp. 5473–5496. doi:10.1175/2007JCLI1824.1.
[25] Amante, C. and Eakins, B.W., 2009, Etopo1 1 Arc-Minute Global Relief Model: Procedures, Data Sources and Analysis. NOAA Technical Memorandum NESDIS NGDC-24. National Geophysical Data Center, NOAA. doi:10.7289/V5C8276M.
[26] Olson, D.M., Dinerstein, E., Wikramanayake, E.D., Burgess, N.D., Powell, G.V.N., Underwood, E.C., D’amico, J.A., Itoua, I., Strand, H.E., Morrison, J.C., Loucks, C.J., Allnutt, T.F., Ricketts, T.H., Kura, Y., Lamoreux, J.F., Wettengel, W.W., Hedao, P. and Kassem, K.R., 2001, Terrestrial Ecoregions of the World: A New Map of Life on Earth: A new global map of terrestrial ecoregions provides an innovative tool for conserving biodiversity. BioScience, 51, pp. 933. doi:10.1641/0006-3568(2001)051[0933:TEOTWA]2.0.CO;2.
[27] Costello, M.J., Tsai, P., Wong, P.S., Cheung, A.K.L., Basher, Z. and Chaudhary, C., 2017, Marine biogeographic realms and species endemicity. Nature Communications, 8, pp. 1–9. doi:10.1038/s41467-017-01121-2.


Beside that, is there a good longsword or bastard sword soulknife build? Seems like a cool class, if I could see how to make it even powerful it would be great. If that is impossible, could you suggest an equally cool build? I know this is a very vague request but don't know much about PRC.
I am not sure how much help we can be for you. I am really one of the few that play PRC and, even that, i am limited on (prc is big). It seems that your best bet is to check the forum for the server.
Once you do that, it is not a big deal to check the build search for a similar build using nwn classes. The PRC doesnt have a search.
Sorry i cant be of any more help than that, as i have no idea what you are refering too.


ITypeConfig
.
So that in 99% of cases, one would have to call just one method, e.g.
Core.GetTypeObj<TInterface, TClassToExtend, TWrapper>()
to get the object of the type. ITypeConfig
should be used
in less than 1% of cases.
Of course most of the information will be contained in TWrapper and the classes that it refers to and a lot of information will be provided by the attributes.
In particular I need to create the following functionality based on attributes of the wrapper:
It should be possible to use the IoC container outside of roxy as a stand alone container without code generation.
It should cover the most used MEF2 functionality, but should be much simpler.
The IoC Container will be called IoC?
Here are some methods:
Core.Map(Type rypeToResolve, Type resolutionType, object resolutionKey = null, bool allowMultipleResolutions = false )
Core.Map<TypeToResolve, ResolutionType>(object resolutionKey = null, bool allowMultipleResolutions = false)
Core.MapSingleton(Type typeToResolve, object objToResolve, object resolutionKey = null)
Core.MapSingleton<TypeToResolve>(TypeToResolve objToResolve, object resolutionKey)
Core.CreateAndMapSingleton(Type typeToResolve, Type resolutionType, object resolutionKey = null)
Core.MapSingleton<TypeToResolve, ResolutionType>(object resolutionKey)
Type Core.ResolveType(Type typeToResolve);
T Core.ResolveType<TypeToResolve>();
object Core.Resolve(Type typeToResolve)
TypeToResolve Core.Resolve<TypeToResolve>()
List<object> Core.ResolveMany(Type typeToResolve)
List<TypeToResolve> Core.ResolveMany<TypeToResolve>()


SpACe EXPLORATION
All from the very beginning to the future
Know the
PRESENT
Have a glimse of
FUTURE
Time travel to
The PAST
About
Us


Basic example
Username:
Invalid:
Username is required.
Email:
Invalid:
Email is required.
Please, write a valid email address.


Timed Practice Assessment
Please follow the instructions below carefully and accurately. This assessment will be timed, please complete it as quickly as you can while still being accurate. Accuracy is more important than speed.
- Create a Google Docs document named
MyName01
where “MyName” is your first name. For example, if your name is John your file will be called John01
.
- On the first line of the document, type the time you started this assessment.
- Find a resource online that teaches HTML. Paste a link to that resource into the next line of the document.
- Take this one minute typing test.
- Copy your results from the page, be sure to include your Typing Speed, Accuracy and Net Speed. Paste it into your Google Docs document.
- Share the document with
<EMAIL_ADDRESS>. (Be sure to leave "Notify people" checked.)
- Download the document as a PDF.
- From your email account, email the document as an attachment to<EMAIL_ADDRESS>with the subject line "Refcode Assessment" and with the current time written in the body of the email.


20 February 2002
Disease Outbreak Reported
As of 19 February 2002, the Ministry of Health, India has reported a total of 16 cases of pneumonic plague including 4 deaths in Hat Koti village, Shimla district, Himachal Pradesh state, since the onset of the outbreak on 4 February 2002. The series of tests carried out by the National Institute of Communicable Diseases (NICD) confirm the presence of Yersinia pestis in clinical samples.
A team from the NICD visited the village, and found that all the cases could be linked to residents of one hamlet. Under the guidance of the team, the local health administration has taken the following measures: administration of chemoprophylaxis to contacts of the patients, to residents of the affected and neighbouring village and to doctors/paramedics and health workers; fumigation in the affected villages and transport vehicles; public education campaign.
The last reported case had a date of onset of 8 February. Careful surveillance in the area and in the state is continuing.
WHO recommends no special restrictions on travel or trade to or from India.


All event locations are on the Ozarks Technical Community College Springfield campus.
OTC campus and building maps
| Time | Location | Event |
| Friday 4:00PM | Lincoln Hall 211 | Check In Begins |
| Friday 5:30PM | Lincoln Hall 211 | Kickoff Presentation |
| Friday 6:00PM - Saturday 3:00PM | Norman K Myers Building | Hackathon Participation |
| Saturday 3:00PM | Lincoln Hall 211 | Presentation of Demos / Judging |
| Saturday 4:30PM | Lincoln Hall 211 | Wrap-Up and Close |
Late check-in will be available at the desk in the atrium of the Norman K Myers building until 6:30PM
Participants are welcome to come and go throughout the night or stay as they like.


BREAKING: Former Niger Delta militants protest non-payment of allowances
by Chukwudi AkasikeChukwudi Akasike, Port Harcourt
SCORES of former Niger Delta militants have protested the alleged non-payment of their allowances by the Presidential Amnesty Office.
The ex-fighters, who are undergoing training in manufacturing and repairs of electric transformers, said they had not been paid their allowances since August.
The placard-carrying protesters were at the Presidential Amnesty Office in Port Harcourt at 10am on Monday, chanting war and solidarity songs.
Details later…


{% extends 'base.html' %} {% block content %} HTTP 404 It seems you are looking for something that I don't have. {% if config.extra.author.avatar %} {% endif %} {{ macros:: social_links( social_config=config.extra.social) }} Home {% endblock %}
It seems you are looking for something that I don't have.
Home


JPG, GIF or PNG. Max size of 800K
公司/設計師名稱須經實名驗證，一經驗證，無法更改
不超過一千字的簡介
網站，粉絲專頁，博客，個人網站等等
可以分享給所有人
設定後，則只能用密碼登入
你的公司專頁為：http://dazzle.gallery/henry930
最少6個字母或數字
One-click sign in
Google
One-click sign in only (not shown on profile)
Send me:
Get Dribbble news, announcements, and product updates
Get important notifications about you or activity you've missed
Get an email when a Dribbble Meetup is posted close to my location
Email me when:
Subscribe me to:
Monday: New career opportunities
Tuesday: Latest design news & community highlights
Wednesday: Witty, engaging, and educational, hosted by Meg Lewis
Thursday: Curated design inspiration straight to your inbox
Friday: Can’t miss shots from designers you follow
As part of our ongoing commitment to your privacy, you may request to download your data from Dribbble. This data will include your profile and shot information. Once you have requested your data, you will receive an email (at<EMAIL_ADDRESS>with a link to the archive.
Requested on May 2, 2020


This page is were I pretty much inform you about all the cool stuff that im doing. Now, I will delete some blogs in updates so this page can load faster, but if you want to save the blogs, just download the source code to this page, or take a screenshot of the blog that you want to save. If it is a video blog... welp, good luck finding out how to save that too. This is FroxserFox saying, im outa here(this phrase is the sonic cd "im outa here" phrase. If sega finds out im using it, then I gatta say, sorry sega for using it but im still ganna use it till i get my own catchphrase.)


Utilities¶
EXOSIMS provides multiple utilities for mission construction and ensemble analysis. Some of these are accessible via methods in the MissionSim
object, and some as standalone modules.
MissionSim Utilities¶
genWaypoint¶
Generates a ballpark estimate of the expected number of star visits and the total completeness of these visits for a given mission duration
- Args:
- duration (int):
- The length of time in days allowed for the waypoint calculation, defaults to 365
- tofile (string):
- Name of the file containing a plot of total completeness over mission time, by default genWaypoint does not create this plot
- Returns:
- out (dictionary):
- Output dictionary containing the number of stars visited, the total completness achieved, and the amount of time spent integrating.
genWaypoint is intended to be run prior to a simulation to provide a general idea of what to expect within the simulation. By default, genWaypoint outputs a structure that looks like:
{'numStars': 191, 'Total Completeness': 88.439895817937568, 'Total intTime': <Quantity<PHONE_NUMBER>032982 d>}
containing the number of stars visited, the total completeness of all the stars visited, and the total time spent integrating, which is bounded by the duration.
If “tofile” is specified, genWaypoint also generates a graph of total completeness over total integration time.
To run genWaypoint:
sim = EXOSIMS.MissionSim.MissionSim(scriptfile)
sim.genWaypoint(tofile="mygraph.png")
OR
sim.genWaypoint(duration=730, tofile="mygraph.png")
checkScript¶
Calls CheckScript and checks the script file against the mission outspec.
- Args:
- scriptfile (string):
- The path to the scriptfile being used by the sim
- prettyprint (boolean):
- Outputs the results of Checkscript in a readable format.
- tofile (string):
- Name of the file containing all output specifications (outspecs). Default to None.
- Returns:
- out (String):
- Output string containing the results of the check.
checkScript takes in a scriptfile and examines it in comparison to the mission outspec. It identifies any inconsitancies it finds between the two. The possible warnings are:
WARNING 1: Catches parameters that are never used in the sim or are not in the outspec
WARNING 2: Catches parameters that are unspecified in the script file and notes default value used
WARNING 3: Catches mismatches in the modules being imported
WARNING 4: Catches cases where the value in the script file does not match the value in the outspec
checkScript has several output options. By default, it will retunr a string containing all information. If “prettyprint” is specified, then checkscript will output this information to the commandline in a readble format. if “tofile” is specified, then the method will save this information to a file.
To run checkScript:
sim = EXOSIMS.MissionSim.MissionSim(scriptfile)
sim.checkScript(scriptfile)
OR
sim.checkScript(scriptfile, prettyprint=True)
OR
sim.checkScript(scriptfile, tofile="check.txt")


The dominance of mobile internet use means that users are searching for the right business as they travel, shop, or sit on their couch at home. Search Engine Optimization (SEO) allows you to increase your visibility and find the right customers for your business.
The web is full of opinions, and some of these can be negative. Social media allows anyone with an internet connection to say whatever they want about your business. Online Reputation Management gives you the control over what potential customers see when they search for your business.
Social media continues to have a sizable influence on buying habits. Social media marketing helps you determine which platforms are suited to your brand, using analytics to find the right markets and increase your lead generation.
Inbound strategies for lead generation require less work for your business, bringing customers directly to your website.
Users find your business through paid and organic searches, increasing the search ranking and visibility for your business.
As the search ranking for your business increases, your advertising costs decrease, and you no longer need to advertise your page.