This document describes how to build and install the netCDF library, version 4.0 on Unix and Windows systems. This document was last updated on 18 May 2008.
Instructions for installing earlier versions of netCDF can be found at http://www.unidata.ucar.edu/software/netcdf/old_docs.
For a brief introduction to the netCDF format and utilities see The NetCDF Tutorial (The NetCDF Tutorial).
For a complete description of the netCDF format and utilities see The NetCDF Users Guide (The NetCDF Users Guide).
Programming guides are available for C (see The NetCDF C Interface Guide (The NetCDF C Interface Guide)), C++ (see The NetCDF C++ Interface Guide (The NetCDF C++ Interface Guide)), Fortran 77 (see The NetCDF Fortran 77 Interface Guide (The NetCDF Fortran 77 Interface Guide)), and Fortran 90 (see The NetCDF Fortran 90 Interface Guide (The NetCDF Fortran 90 Interface Guide)). All of these documents are available from the netCDF website http://www.unidata.ucar.edu/software/netcdf.
Separate documentation for the netCDF Java library can be found at the netCDF-Java website, http://www.unidata.ucar.edu/software/netcdf-java.
To learn more about netCDF, see the netCDF website http://www.unidata.ucar.edu/software/netcdf.
--- The Detailed Node Listing ---
Building and Installing NetCDF on Unix Systems
Building and Installing NetCDF on Windows
If Something Goes Wrong
Perhaps the easiest way to get netCDF is to get a pre-built binary distribution. To get them, see http://www.unidata.ucar.edu/software/netcdf/binaries.html.
To install the binary distribution, uncompress and unpack the tar file. You will end up with 4 subdirectories, lib, include, man, and bin.
The lib subdirectory holds the netCDF libraries (C, Fortran, and C++). The include directory holds the necessary netcdf.h file (for C), netcdf.inc (for Fortran), netcdfcpp.h (for C++), and the .mod files (for Fortran 90). The bin directory holds the ncgen and ncdump utilities, and the man directory holds the netCDF documentation.
You can have these directories anywhere you like, and use netCDF. But when compiling a netCDF program, you will have to tell the linker where to find the library (e.g. with the -L option of most C compilers), and you will also have to tell the C pre-processor where to find the include file (e.g. with the -I option).
If you are using shared libraries, you will also have to specify the library location for run-time dynamic linking. See your compiler documentation. For some general information see the netCDF FAQ “How do I use shared libraries” at http://www.unidata.ucar.edu/software/netcdf/faq.html#using_shared_p.
Who has time to read long installation manuals these days?
To install netCDF, uncompress and unpack the tar file, then change to the distribution directory:
gunzip netcdf-3.6.2.tar.gz tar -xf netcdf-3.6.2.tar cd netcdf-3.6.2
Now run the usual configure, make check, make install cycle:
./configure make check make install
The configure script will try to find necessary tools in your path. When you run configure you may optionally use the –prefix argument to change the default installation directory. For example, the following will install the library in /usr/local/lib, the header file in /usr/local/include, and the utilities in /usr/local/bin.
./configure --prefix=/usr/local
The default install root is /usr/local (so there's no need to use the prefix argument if you want the software installed there).
By default the netCDF configuration will build static libraries only. For shared libraries as well, use the –enable-shared option to configure.
If all this doesn't work, then you might have to read the next chapter. Better luck next time!
The latest version of this document is available at http://www.unidata.ucar.edu/software/netcdf/docs/netcdf-install.
This document contains instructions for building and installing the netCDF package from source on various platforms. Prebuilt binary releases are (or soon will be) available for various platforms from http://www.unidata.ucar.edu/software/netcdf/binaries.html.
Depending on the platform, you may need up to 25 Mbytes of free space to unpack, build, and run the tests. You will also need a Standard C compiler. If you have compilers for FORTRAN 77, FORTRAN 90, or C++, the corresponding netCDF language interfaces may also be built and tested. Compilers and associated tools will only be found if they are in your path, or if you specify the path and compiler in the appropriate environment variable. (Example for csh: setenv CC=/some/directory/cc).
If you want to run the large file tests, you will need about 13 GB of free disk space, as some very large files are created. The created files are immediately deleted after the tests complete. These large file tests are not run as part of the normal “make check” step; they are only run if you use the –enable-large-file-tests option with configure.
If you wish to build from source on a Windows (Win32) platform, different instructions apply. See Windows.
The netCDF configure script searches your path to find the compilers, tools, and settings it needs to build netCDF. If you wish to change the default choices of the configure script, you may do so by setting environment variables.
Environment variables are a feature of Unix shells, and each shell may handle them in a slightly different manner. (To see which shell you are using, type: echo $SHELL).
For users of the C-shell (csh) and derived shells, use the setenv command to set environment variables. For the Bourne shell (sh), use the export command to set an environment variable.
For example, to use compilers that can't be found in your path, set the appropriate CC, CXX, F77, or F90 environment variables. In the Bourne shell:
export CC=/some/strange/place/cc export F77=/some/strange/place/f77 ./configure make check
To accomplish the same thing from the C-shell:
setenv CC /some/strange/place/cc setenv F77 /some/strange/place/f77 ./configure make check
When searching for compilers the configure script will prefer vendor compilers to GNU compilers. Its not because we don't like GNU, but because we assume if you purchased a compiler, you want to use it. Setting CC allows you to over-ride this preference. (Alternatively, you could temporarily remove the compiler's directories from your PATH.)
For example, on an AIX system, configure will first search for xlc, the AIX compiler. If not found, it will try gcc, the GNU compiler. To override this behavior, set CC to gcc (in sh: export CC=gcc). (But don't forget to also set CXX to g++, or else configure will try and use xlC, the AIX C++ compiler to build the netCDF C++ API.)
By default, the netCDF library is built with assertions turned on. If you wish to turn off assertions, set CPPFLAGS to -DNDEBUG (csh ex: setenv CPPFLAGS -DNDEBUG).
If GNU compilers are used, the configure script sets CPPFLAGS to “-g -O2”. If this is not desired, set CPPFLAGS to nothing, or to whatever other value you wish to use, before running configure.
| CC | C compiler | If you don't specify this, the configure script will try to
find a suitable C compiler such as cc, c89, xlc, or gcc.
|
| FC | Fortran compiler (if any) | If you don't specify this, the configure script will try to find a
suitable Fortran 90 or Fortran 77 compiler. Set FC to "" explicitly,
or provide the –disable-f77 option to configure, if no Fortran
interface is desired.
|
| F90 | Fortran 90 compiler (if any) | If you don't specify this, the configure script will try to find a
suitable Fortran 90 compiler. Not needed if FC specifies a Fortran 90
compiler. Set F90 to "" explicitly, or use the –disable-f90 option to
configure, if no Fortran 90 interface is desired. For a vendor F90
compiler, make sure you're using the same vendor's F77 compiler. Using
Fortran compilers from different vendors, or mixing vendor compilers
with g77, the GNU F77 compiler, is not supported and may not work.
|
| CXX | C++ compiler | If you don't specify this, the configure script will try to find a
suitable C++ compiler. Set CXX to "" explicitly, or use the
–disable-cxx configure option, if no C++ interface is desired. If
using a vendor C++ compiler, use that vendor's C compiler to compile
the C interface. Using different vendor compilers for C and C++ may
not work.
|
| CFLAGS | C compiler flags | "-O" or "-g", for example. If you don't set this, configure may
set it based on your platform's needs (unless you have used the
–disable-flag-setting option is used with configure).
|
| CPPFLAGS | C preprocessor options | "-DNDEBUG" to omit assertion checks, for example. If you don't
set this, configure may set it based on your platform's needs (unless
you have used the –disable-flag-setting option is used with
configure).
|
| FFLAGS | Fortran compiler flags | "-O" or "-g", for example. If you don't set this, configure may
set it based on your platform's needs (unless you have used the
–disable-flag-setting option is used with configure).
|
| F90FLAGS | Fortran 90 compiler flags | "-O" or "-g", for example. If you don't specify this, the value of
FFLAGS will be used. Configure may set it based on your platform's
needs (unless you have used the –disable-flag-setting option is used
with configure).
|
| CXXFLAGS | C++ compiler flags | "-O" or "-g", for example. If you don't set this, configure may
set it based on your platform's needs (unless you have used the
–disable-flag-setting option is used with configure).
|
| ARFLAGS, NMFLAGS, FPP, M4FLAGS, LIBS, FLIBS, FLDFLAGS | Miscellaneous | One or more of these were needed for some platforms, as specified
below. Unless specified, you should not set these environment
variables, because that may interfere with the configure script.
|
The section marked Tested Systems below contains a list of systems on which we have built this package, the environment variable settings we used, and additional commentary.
Some platforms support special options to build in 64-bit mode.
NetCDF 4.0 has been tested as 64-bit builds on SunOS, Irix, and AIX. The options needed to build in 64-bit mode on these platforms are described below.
AIX
IRIX
SunOS
To create the Makefiles needed to build netCDF, you must run the provided configure script. Go to the top-level netCDF directory.
Decide where you want to install this package. Use this for the "–prefix=" argument to the configure script below. The default installation prefix is “/usr/local,” which will install the package's files in usr/local/bin, usr/local/lib, and usr/local/man. The default can be overridden with the –prefix argument to configure.
(Note that this is a new default location for version 3.6.2 of netCDF. Previous versions used the directory in which netCDF was built as the default install directory).
Here's how to execute the configure script with a different installation directory:
./configure --prefix=/whatever/you/decided
The above would cause the netCDF libraries to be installed in /whatever/you/decided/lib, the header files in /whatever/you/decided/include, the utilities (ncdump/ncgen) in /whatever/you/decided/bin, and the man pages in /whatever/you/decided/man.
There are other options for the configure script. The most useful ones are listed below. Use the –help option to get the full list.
--prefix
--enable-shared
--enable-docs-install
You can change the directory that documents are installed to. Run ./configure –help for more information.
The this option does not affect the netCDF man pages, which are always installed. This option applies only to the texinfo documentation files in the man directory (netcdf.texi, netcdf-c.texi, and so on).
The latest documentation is also available on-line at the the netCDF website. http://www.unidata.ucar.edu/software/netcdf.
Installing the documentation does not cause the documentation to be built from source; it causes the documentation which was shipped with the distribution to be installed.
Users who wish to contribute to the documentation development are
urged to make any suggested changes to the documentation source files,
which have the .texi filename extension (netcdf.text, netcdf-c.texi,
etc.). Building the netCDF documentation from source requires recent
versions of the open-source tools sed, m4, texinfo, and tex.
--disable-flag-setting
--disable-largefile
--disable-f77
--disable-f90
--disable-cxx
--disable-v2
--disable-utilities
--enable-c-only
--enable-large-file-tests
--with-temp-large
--disable-fortran-compiler-check
--disable-fortran-type-check
--disable-compiler-recover
--disable-examples
--enable-separate-fortran
--disable-extreme-numbers
The configure script will examine your computer system – checking for attributes that are relevant to building the netCDF package. It will print to standard output the checks that it makes and the results that it finds.
The configure script will also create the file "config.log", which will contain error messages from the utilities that the configure script uses in examining the attributes of your system. Because such an examination can result in errors, it is expected that "config.log" will contain error messages. Therefore, such messages do not necessarily indicate a problem (a better indicator would be failure of the subsequent "make"). One exception, however, is an error message in "config.log" that indicates that a compiler could not be started. This indicates a severe problem in your compilation environment – one that you must fix.
Run "make". This will build one or more netCDF libraries. It will build the basic netCDF library libnetcdf.a. If you have Fortran 77 or Fortran 90 compilers, then the Fortran library will also be built (libnetcdff.a). If you have a C++ compiler, then the C++ interface will be built (libnetcdf_c++.a.)
A “make” will also build the netCDF utilities ncgen(1) and ncdump(1).
Run make like this:
make
Run “make check” to verify that the netCDF library and executables have been built properly (you can instead run “make test” which does the same thing).
A make check will build and run various test programs that test the C, Fortran, and C++ interfaces as well as the "ncdump" and "ncgen" utility programs.
Lines in the output beginning with "***" report on success or failure of the tests; any failures will be reported before halting the test. Compiler and linker warnings during the testing may be ignored.
Run the tests like this:
make check
If you plan to use the 64-bit offset format (introduced in version 3.6.0) to create very large files (i.e. larger than 2 GB), you should probably specify the –enable-large-file-tests to configure, which tests the large file features. You must have 13 GB of free disk space for these tests to successfully run.
If you are running the large file tests, you may wish to use the –with-temp-large option to specify a temporary directory for the large files. (You may also set the environment variable TEMP_LARGE before running configure).
The default is to create the large files in the nc_test subdirectory of the netCDF build.
Run the large file tests like this:
./configure --enable-large-file-tests --with-temp-large=/home/ed/tmp make check
All of the large files are removed on successful completion of tests. If the test fails, you may wish to make sure that no large files have been left around.
If any of the the large file tests test fail, check to ensure that your file system can handle files larger than 2 GiB by running the following command:
dd if=/dev/zero bs=1000000 count=3000 of=$(TEMP_LARGE)/largefile
If your system does not have a /dev/zero, this test will fail. Then you need to find some other way to create a file larger than 2 GiB to ensure that your system can handle them.
To install the libraries and executables, run "make install". This will install to the directory specified in the configure step.
Run the installation like this:
make install
The install will put files in the following subdirectories of the directory you provided as a prefix, creating the subdirectories if needed:
lib
Static library users should ignore the .la files, and link to the .a files.
Shared library builds will add some .so files to this directory, as
well.
include
bin
man
share
Try linking your applications. Let us know if you have problems (see Reporting Problems).
The following platform-specific note may be helpful when building and installing netCDF. Consult your vendor manuals for information about the options listed here. Compilers can change from version to version; the following information may not apply to your platform.
Full output from some of the platforms of the test platforms for netCDF 4.0 can be found at http://www.unidata.ucar.edu/software/netcdf/builds.
We found the vendor compilers in /usr/vac/bin, and included this in our PATH. Compilers were xlc, xlf, xlf90, xlC.
The F90 compiler requires the qsuffix option to believe that F90 code files can end with .f90. This is automatically turned on by configure when needed (we hope):
F90FLAGS=-qsuffix=f=f90
We had to use xlf for F77 code, and xlf90 for F90 code.
To compile 64-bit code, set the correct environment variables for your platform (documented below).
The environment variable OBJECT_MODE can be set to 64, or use the -q64 option on all AIX compilers by setting CFLAGS, FFLAGS, and CXXFLAGS to -q64.
The following is also necessary on an IBM AIX SP system for 64-bit mode:
ARFLAGS='-X64 cru' NMFLAGS='-X64'
There are thread-safe versions of the AIX compilers. For example, xlc_r is the thread-safe C compiler. The NetCDF configure script ignores these compilers. To use thread-safe compilers, override the configure script by setting CC to xlc_r; similarly for FC and CXX.
For large file support, AIX requires that the macro _LARGE_FILES be defined. The configure script does this using AC_SYS_LARGEFILES. Unfortunately, this misfires when OBJECT_MODE is 64, or the q64 option is used. The netCDF tries to fix this by turning on _LARGE_FILES anyway in these cases.
The GNU C compiler does not mix successfully with the AIX fortran compilers.
Cygwin is a Linux-like environment for Windows. NetCDF builds under Cygwin tools on Windows just as with Linux. For more information see the Cygwin web site: http://www.cygwin.com.
Building under Cygwin will yield a DLL on windows (as long as –enable-shared is used with configure). However this DLL will not work without the Cygwin POSIX emulation DLL as well. For a stand-alone DLL, use MinGW (below).
MinGW, or Minimalist GNU for Windows, is a set of GNU Unix tools ported to Windows. The NetCDF C and Fortran APIs builds under MinGW tools on Windows just as with Linux.
Those diving into netCDF and MinGW should be familiar with the information at the web page “Different Ways of Building Woe32 DLLs” at: http://www.haible.de/bruno/woe32dll.html, the MinGW FAQ at: http://www.mingw.org/mingwfaq.shtml, and the peculiarities of the win32 environment as explained by this helpful Red Hat document at: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/win32.html.
The netCDF C++ API does not (yet) build DLLs cleanly under MinGW. Any knowledgeable user who can make this work should send results to the netCDF support email address<EMAIL_ADDRESS>Using MinGW it is possible to produce stand-alone windows DLLs. First build netCDF in the usual way, with –enable-shared and –enable-dll as configure options.
This builds the DLL for compatibility with g77. Set FC to the command line invocation of your fortran compiler. To build for other fortran compilers (i.e. ones you don't have), change the config.h file to select another fortran and recompile (without rerunning configure).
The fortran tests will not, of course, work for these other fortrans, because you don't have the compiler to compile the test program!
FC=g77 ./configure --enable-dll --disable-cxx --enable-shared make check
Due to the magic of libtool, the output files are found in the libsrc/.libs directory.
To get a MS compatible export library, open an MS DOS window, change directory to libsrc/.libs and run the following command:
lib /machine:i386 /def:libnetcdf.def
The above command uses the Microsoft LIB tool, which comes with Visual C++.NET, and perhaps other Microsoft development tools. (To get this in my path, I open the “Visual Studio 2003 Command Prompt” in my Windows program menu.)
This command creates the .lib file, the import library, needed (or at least used) by MicroSoft (and other) build environments on Windows.
For more information about MinGW, see the MinGW web site: http://www.mingw.org. For more information about producing stand-alone windows DLLs with MinGW, see the MinGW FAQ: http://www.mingw.org/mingwfaq.shtml.
For the c89 compiler to work, CPPFLAGS must include -D_HPUX_SOURCE. This isn't required for the cc compiler.
Our HPUX machine has two C compilers. Only the one in /opt/ansic/bin/ works for netCDF.
For large file support, HP-UX requires _FILE_OFFSET_BITS=64. The configure script sets this automatically.
The HPUX C++ compiler (on our machine) doesn't work on netCDF code. It's too old for that. So either use GNU to compile netCDF, or skip the C++ code by setting CXX to ” (in csh: setenv CXX ”), or using the –disable-cxx option.
Building a 64 bit version may be possible with the following settings:
CC=/bin/cc CPPFLAGS='-D_HPUX_SOURCE -D_FILE_OFFSET_BITS=64' # large file support CFLAGS='-g +DD64' # 64-bit mode FC=/opt/fortran90/bin/f90 # Fortran-90 compiler FFLAGS='-w +noppu +DA2.0W' # 64-bit mode, no "_" suffixes FLIBS=-lU77 CXX='' # no 64-bit mode C++ compiler
Sometimes quotas or configuration causes HPUX disks to be limited to 2 GiB files. In this cases, netCDF cannot create very large files. Rather confusingly, HPUX returns a system error that indicates that a value is too large to be stored in a type. This may cause scientists to earnestly check for attempts to write floats or doubles that are too large. In fact, the problem seems to be an internal integer problem, when the netCDF library attempts to read beyond the 2 GiB boundary. To add to the confusion, the boundary for netCDF is slightly less than 2 GiB, since netCDF uses buffered I/O to improve performance.
A 64-bit version can be built by settin the appropriate environment variables.
Set CFLAGS, FCFLAGS, FFLAGS, and CXXFLAGS to -64.
On our machine, there is a /bin/cc and a /usr/bin/cc, and the -64 option only works with the former.
The f2cFortran flag is turned on by the configure script when GNU fortran is used.
CPPFLAGS=-Df2cFortran
For Portland Group Fortran, set pgiFortran instead:
CPPFLAGS=-DpgiFortran
Portland Group F90/F95 does not mix with GNU g77.
The netCDF configure script should notice which fortran compiler is being used, and set these automatically.
For large file support, _FILE_OFFSET_BITS must be set to 64. The netCDF configure script should set this automatically.
The f2cFortran flag is required with GNU fortran (CPPFLAGS=-Df2cFortran). The NetCDF configure script should and set this automatically.
For IBM compilers on the Mac, the following may work (we lack this test environment):
CC=/usr/bin/cc CPPFLAGS=-DIBMR2Fortran FC=xlf F90=xlf90 F90FLAGS=-qsuffix=cpp=f90
For the g95 compiler, you must set LIBS to -lSystemStubs before running configure.
NetCDF builds out of the box on OSF1.
PATH should contain /usr/ccs/bin to find make, nm, ar, etc.
For large file support, _FILE_OFFSET_BITS must be 64. Configure will turn this on automatically.
Large file support doesn't work with c89, unless the -Xa option is used. The netCDF configure script turns this on automatically where appropriate.
To compile in 64-bit mode, set -xarch=v9 on all compilers (i.e. in CFLAGS, FFLAGS, and CXXFLAGS).
When compiling with GNU Fortran (g77), the -Df2cFortran flag is required for the Fortran interface to work. The NetCDF configure script turns this on automatically if needed.
The first thing to try is to set nothing and see if the netCDF configure script finds your fortran compiler, and sets the correct flags automatically.
If it doesn't find the correct fortran compiler, you can next try setting the FC environment variable to the compiler you wish to use, and then see if the configure script can set the correct flags for that compiler.
If all that fails, you must set the flags yourself.
Intel has provided a helpful web page on “Building netCDF with the Intel compilers” at http://www.intel.com/support/performancetools/sb/CS-027812.htm, providing configuration and set-up information, and instructions for building netCDF on Linux and Mac OS.
As an alternative, netCDF can be built successfully with CPPFLAGS set to pgiFortran. Configure can handle this automatically if your fortran compiler is named “ifort.”
The Portland Group fortran compiler requires that netCDF be built with the pgiFortran flag. It will be automatically turned on by configure if your fortran compiler is named “pgf90.”
The Portland Group also has a “PGI Guide to NetCDF” at http://www.pgroup.com/resources/netcdf/netcdf362_pgi71.htm.
The GNU Fortran 77 compiler (g77) requires that netCDF be built with the f2cFortran flag. This is turned on automatically by configure. Since g77 can't build Fortran 90 code, the F90 API will not be built if g77 is the only available fortran compiler.
The version 4 series of gcc, the GNU Compiler Collection, offers a F95 compiler, usually called gfortran. NetCDF requires the pgiFortran flag to build with gfortran, and this is turned on automatically by configure.
g95 is a Fortran 95 compiler which is different from the Free Software Foundation's gfortran. The netCDF configure script sets the f2cFortran flag when g95 is used.
Some g95 users recommend instead setting the following, which handles the underscores differently, and reportedly works better when integrating with other packages or libraries:
CC=gcc FC=g95 CPPFLAGS=-DpgiFortran FFLAGS=-fno-second-underscore FCFLAGS=-fno-second-underscore
If this approach is taken, all fortran programs which use netCDF must be compiled with the -fno-second-underscore flag.
One the Macintosh, g95 requires environment variables LIBS and FLIBS to be set to -lSystemStubs.
Older versions of the GNU C++ compiler don't handle large files well. A version 3.2 installation of g++ fails to build for me without –disable-largefile. This turns off the ability of netCDF to handle files larger than about 2 GiBytes. Users should upgrade their g++, or learn to live with small files.
The configure and build system should work on any system which has a modern "sh" shell, "make", and so on. The configure and build system is less portable than the "C" code itself, however. You may run into problems with the "include" syntax in the Makefiles. You can use GNU make to overcome this, or simply manually include the specified files after running configure.
Instruction for building netCDF on other platforms can be found at http://www.unidata.ucar.edu/software/netcdf/other-builds.html. If you build netCDF on a new platform, please send your environment variables and any other important notes to<EMAIL_ADDRESS>and we will add the information to the other builds page, with a credit to you.
If you can't run the configure script, you will need to create config.h and fortran/nfconfig.inc. Start with ncconfig.in and fortran/nfconfig.in and set the defines as appropriate for your system.
Operating system dependency is isolated in the "ncio" module. We provide two versions. posixio.c uses POSIX system calls like "open()", "read()" and "write(). ffio.c uses a special library available on CRAY systems. You could create other versions for different operating systems. The program "t_ncio.c" can be used as a simple test of this layer.
Note that we have not had a Cray to test on for some time. In particular, large file support is not tested with ffio.c.
Numerical representation dependency is isolated in the "ncx" module. As supplied, ncx.m4 (ncx.c) supports IEEE floating point representation, VAX floating point, and CRAY floating point. BIG_ENDIAN vs LITTLE_ENDIAN is handled, as well as various sizes of "int", "short", and "long". We assume, however, that a "char" is eight bits.
There is a separate implementation of the ncx interface available as ncx_cray.c which contains optimizations for CRAY vector architectures. Move the generic ncx.c out of the way and rename ncx_cray.c to ncx.c to use this module. By default, this module does not use the IEG2CRAY and CRAY2IEG library calls. When compiled with aggressive in-lining and optimization, it provides equivalent functionality with comparable speed and clearer error semantics. If you wish to use the IEG library functions, compile this module with -DUSE_IEG.
Most users will not be interested in working directly with the netCDF source code. Rather, they will write programs which call netCDF functions, and delve no further. However some intrepid users may wish to dig into the netCDF code to study it, to try and spot bugs, or to make modifications for their own purposes.
To work with the netCDF source code, several extra utilities are required to fully build everything from source. If you are going to modify the netCDF source code, you will need some or all of the following Unix tools.
m4
flex and yacc
makeinfo
tex
The user generally will just want to download the latest version of
netCDF documents at the netCDF website. http://www.unidata.ucar.edu/software/netcdf/docs.
autoconf
automake
libtool
sed
NetCDF has a large and enterprising user community, and a long history of accepting user modifications into the netCDF code base. Examples include the 64-bit offset format, and the F90 API.
All suggested changes and additions to netCDF code can be sent to<EMAIL_ADDRESS>NetCDF can be built and used from a variety of development environments on Windows. The netCDF library is implemented as a Windows dynamic link library (DLL). The simplest way to get started with netCDF under Windows is to download the pre-built DLL from the Unidata web site.
Building under the Cygwin port of GNU tools is treated as a Unix install. See Platform Specific Notes.
Instructions are also given for building the netCDF DLL from the source code using Microsoft's Visual Studio and VC++.NET.
VC++ documentation being so voluminous, finding the right information can be a chore. There's a good discussion of using DLLs called “About Dynamic-Link Libraries” at (perhaps) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dynamic_link_libraries.asp.
From the .NET point of view, the netCDF dll is unmanaged code. As a starting point, see the help topic “Consuming Unmanaged DLL Functions” which may be found at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconConsumingUnmanagedDLLFunctions.asp, unless the page has been moved.
We have pre-built Win32 binary versions of the netcdf dll and static library, as well as ncgen.exe and ncdump.exe (dll and static versions). You can get them from ftp://ftp.unidata.ucar.edu/pub/netcdf/contrib/win32/netcdf-3.6.1-beta1-win32dll.zip. (Note: we don't have a C++ interface here).
Whether you get the pre-built DLL or build your own, you'll then have to install it somewhere so that your other programs can find it and use it.
To install a DLL, you just have to leave it in some directory, and (possibly) tell your compiler in which directory to look for it.
A DLL is a library, and functions just like libraries under the Unix operating system. As with any library, the point of the netCDF DLL is to provide functions that you can call from your own code. When you compile that code, the linker needs to be able to find the library, and then it pulls out the functions that it needs. In the Unix world, the -L option tells the compiler where to look for a library. In Windows, library search directories can be added to the project's property dialog.
Similarly, you will need to put the header file, netcdf.h, somewhere that you compiler can find it. In the Unix world, the -I option tells the compiler to look in a certain directory to find header files. In the Windows world, you set this in the project properties dialog box of your integrated development environment.
Therefore, installing the library means nothing more than copying the DLL somewhere that your compiler can find it, and telling the compiler where to look for them.
The standard place to put DLLs is Windows\System32 folder (for Windows2000/XP) or the Windows\System folder (for Windows 98/ME). If you put the DLL there, along with the ncgen and ncdump executables, you will be able to use the DLL and utilities without further work, because compilers already look there for DLLs and EXEs.
Instead of putting the DLL and EXEs into the system directory, you can leave them wherever you want, and every development project that uses the dll will have to be told to search the netCDF directory when it's linking, or, the chosen directory can be added to your path.
On the .NET platform, you can also try to use the global assembly cache. (To learn how, see MSDN topic “Global Assembly Cache”, at www.msdn.microsoft.com).
Following Windows conventions, the netCDF files belong in the following places:
| File(s) | Description | Location
|
| netcdf.dll | C and Fortran function in DLL | Windows\System (98/ME) or Windows\System32 (2000/XP)
|
| netcdf.lib | Library file | Windows\System (98/ME) or Windows\System32 (2000/XP)
|
| ncgen.exe, ncdump.exe | NetCDF utilities | Windows\System (98/ME) or Windows\System32 (2000/XP)
|
| netcdf-3 | netCDF source code | Program Files\Unidata
|
When using the netCDF DLL, you should set the preprocessor flag DLL_NETCDF. Do this in the properties window for your project in visual studio.
To use the netcdf.dll:
1. Place these in your include directory: netcdf.h C include file netcdf.inc Fortran include file
2a. To use the Dynamic Library (shared) version of the netcdf library: Place these in a directory that's in your PATH: netcdf.dll library dll ncgen.exe uses the dll ncdump.exe uses the dll
Place this in a library directory to link against: netcdf.lib library
2b. Alternatively, to use a static version of the library
Place this in a library directory to link against: netcdfs.lib library
Place these in a directory that's in your PATH: ncgens.exe statically linked (no DLL needed) ncdumps.exe statically linked (no DLL needed)
To build the netCDF dll with VC++.NET open the win32/NET/netcdf.sln file with Visual Studio. Both Debug and Release configurations are available - select one and build.
The resulting netcdf.dll file will be in subdirectory Release or Debug.
The netCDF tests will be built and run as part of the build process. The Fortran 77 interface will be built, but not the Fortran 90 or C++ interfaces.
The quick_large_files test program is provided as an extra project, however it is not run during the build process, but can be run from the command line or the IDE. Note that, despite its name, it is not quick. On Unix systems, this program runs in a few seconds, because of some features of the Unix file system apparently not present in Windows. Nonetheless, the program does run, and creates (then deletes) some very large files. (So make sure you have at least 15 GiB of space available). It takes about 45 minutes to run this program on our Windows machines, so please be patient.
Load-time linking to the DLL is the most straightforward from C++. This means the netcdf.lib file has to end up on the compile command line. This being Windows, that's hidden by a GUI.
In Visual Studio 2003 this can be done by modifying three of the project's properties.
Open the project properties window from the project menu. Go to the linker folder and look at the general properties. Modify the property “Additional Library Directories” by adding the directory which contains the netcdf.dll and netcdf.lib files. Now go to the linker input properties and set the property “Additional Dependencies” to netcdf.lib.
Finally, still within the project properties window, go to the C/C++ folder, and look at the general properties. Modify “Additional Include Directories” to add the directory with the netcdf.h file.
Now use the netCDF functions in your C++ code. Of course any C or C++ file that wants to use the functions will need:
#include <netcdf.h>
When using the netCDF DLL, you should set the preprocessor flag DLL_NETCDF. Do this in the properties window for your project in visual studio.
The netCDF package is designed to build and install on a wide variety of platforms, but doesn't always. It's a crazy old world out there, after all.
Why not take the easy way out if you can?
Pre-compiled binaries for many platforms can be found at http://www.unidata.ucar.edu/software/netcdf/binaries.html. Click on your platform, and copy the files from the bin, include, lib, and man directories into your own local equivalents (Perhaps /usr/local/bin, /usr/local/include, etc.).
If you are trying to get the configure or build to work, make sure you start with a clean distribution for each attempt. If netCDF failed in the “make” you must clean up the mess before trying again. To clean up the distribution:
make distclean
At NetCDF World Headquarters (in sunny Boulder, Colorado), as part of the wonderful Unidata organization, we have a wide variety of computers, operating systems, and compilers. At night, house elves test netCDF on all these systems.
Output for the netCDF test platforms can be found at http://www.unidata.ucar.edu/software/netcdf/builds.
Compare the output of your build attempt with ours. Are you using the same compiler? The same flags? Look for the configure output that lists the settings of CC, FC, CXX, CFLAGS, etc.
On some systems you have to set environment variables to get the configure and build to work.
For example, for a 64-bit IRIX install of the netCDF-3.6.2 release, the variables are set before netCDF is configured or built. In this case we set CFLAGS, CXXFLAGS, FCFLAGS, and FFLAGS.
flip% uname -a IRIX64 flip 6.5 07080050 IP30 mips flip% setenv CFLAGS -64 flip% setenv CXXFLAGS -64 flip% setenv FFLAGS -64 flip% setenv FCFLAGS -64 flip% make distclean;./configure;make check
If your platform isn't listed on the successful build page, see if another friendly netCDF user has sent in values for environment variables that are reported to work: (http://www.unidata.ucar.edu/software/netcdf/other-builds.html).
If you build on a system that we don't have at Unidata (particularly if it's something interesting and exotic), please send us the settings that work (and the entire build output would be nice too). Send them to<EMAIL_ADDRESS>For netCDF to build correctly, you must be able to compile C from your environment, and, optionally, Fortran 77, Fortran 90, and C++. If C doesn't work, netCDF can't compile.
What breaks a C compiler? Installation or upgrade mistakes when the C compiler was installed, or multiple versions or compilers installed on top of each other. Commercial compilers frequently require some environment variables to be set, and some directories to appear ahead of others in your path. Finally, if you have an expired or broken license, your C complier won't work.
If you have a broken C compiler and a working C compiler in your PATH, netCDF might only find the broken one. You can fix this by explicitly setting the CC environmental variable to a working C compiler, and then trying to build netCDF again. (Don't forget to do a “make distclean” first!)
If you can't build a C program, you can't build netCDF. Sorry, but that's just the way it goes. (You can get the GNU C compiler - search the web for “gcc”).
If netCDF finds a broken Fortran 90, Fortran 77, or C++ compiler, it will report the problem during the configure, and then drop the associated API. For example, if the C++ compiler can't compile a very simple test program, it will drop the C++ interface. If you really want the C++ API, set the CXX environment variable to a working C++ compiler.
If none of the above help, try our troubleshooting section: See Troubleshooting.
Also check to see of your problem has already been solved by someone else (see Finding Help).
If you still can't get netCDF to build, report your problem to Unidata, but please make sure you submit all the information we need to help (see Reporting Problems).
If the ./configure; make check fails, it's a good idea to turn off the C++ and Fortran interfaces, and try to build the C interface alone. All other interfaces depend on the C interface, so nothing else will work until the C interface works. To turn off C++ and Fortran, set environment variables CXX and FC to NULL before running the netCDF configure script (with csh: setenv FC ”;setenv CXX ”).
Turning off the Fortran and C++ interfaces results in a much shorter build and test cycle, which is useful for debugging problems.
If the netCDF configure fails, most likely the problem is with your development environment. The configure script looks through your path to find all the tools it needs to build netCDF, including C compiler and linker, the ar, ranlib, and others. The configure script will tell you what tools it found, and where they are on your system. Here's part of configure's output on a Linux machine:
checking CPPFLAGS...  For example the GNU tools may not inter-operate well with vendor tools. If you're using a vendor compiler, use the ar, nm, and ranlib that the vendor supplied.
As configure runs, it creates a config.log file. If configure crashes, do a text search of config.log for thing it was checking before crashing. If you have a licensing or tool compatibility problem, it will be obvious in config.log.
If the configure script runs, but the compile step doesn't work, or the tests don't complete successfully, the problem is probably in your CFLAGS or CPPFLAGS.
Frequently shared libraries are a rich source of problems. If your build is not working, and you are using the –enable-shared option to generate shared libraries, then try to build without –enable-shared, and see if the static library build works.
If you are planning on using large files (i.e. > 2 GiB), then you may wish to rerun configure with –enable-large-file-tests to ensure that large files work on your system.
The latest netCDF documentation (including this manual) can be found at http://www.unidata.ucar.edu/software/netcdf/docs.
The output of successful build and test runs for recent versions of netCDF can be found at http://www.unidata.ucar.edu/software/netcdf/builds.
A list of known problems with netCDF builds, and suggested fixes, can be found at http://www.unidata.ucar.edu/software/netcdf/docs/known_problems.html.
Reportedly successful settings for platforms unavailable for netCDF testing can be found at http://www.unidata.ucar.edu/software/netcdf/other-builds.html. If you build netCDF on a system that is not listed, please send your environment settings, and the full output of your configure, compile, and testing, to<EMAIL_ADDRESS>We will add the information to the other-builds page, with a credit to you.
The replies to all netCDF support emails are on-line and can be searched. Before reporting a problem to Unidata, please search this on-line database to see if your problem has already been addressed in a support email. If you are having build problems it's usually useful to search on your system host name. On Unix systems, use the uname command to find it.
The netCDF Frequently Asked Questions (FAQ) list can be found at http://www.unidata.ucar.edu/software/netcdf/faq.html.
To search the support database, see /search.jsp?support&netcdf.
The netCDF mailing list also can be searched; see /search.jsp?netcdfgroup.
To help us solve your problem, please include the following information in your email to<EMAIL_ADDRESS>Unfortunately, we can't solve build questions without this information; if you ask for help without providing it, we're just going to have to ask for it.
So why not send it immediately, and save us both the extra trouble?
Although responses to your email will be available in our support database, your email address is not included, to provide spammers with one less place to harvest it from.
--disable-compiler-recover
: Running the configure Script--disable-cxx
: Running the configure Script--disable-examples
: Running the configure Script--disable-extreme-numbers
: Running the configure Script--disable-f77
: Running the configure Script--disable-f90
: Running the configure Script--disable-flag-setting
: Running the configure Script--disable-fortran-compiler-check
: Running the configure Script--disable-fortran-type-check
: Running the configure Script--disable-largefile
: Running the configure Script--disable-utilities
: Running the configure Script--disable-v2
: Running the configure Script--enable-c-only
: Running the configure Script--enable-docs-install
: Running the configure Script--enable-large-file-tests
: Running the configure Script--enable-separate-fortran
: Running the configure Script--enable-shared
: Running the configure Script--prefix
: Running the configure Script--with-temp-large
: Running the configure Scriptautoconf
: NetCDF Sourceautomake
: NetCDF Sourceflex and yacc
: NetCDF Sourcelibtool
: NetCDF Sourcem4
: NetCDF Sourcemakeinfo
: NetCDF Sourcesed
: NetCDF Sourcetex
: NetCDF Source


{% extends "index.html" %} {% block body %}
coMD is a hybrid method with a VMD plugin designed for efficient simulations of conformational changes. ENM modes selected by a Monte Carlo/Metropolis algorithm are used for accelerating the MD trajectories (Gur et. al, 2013). CoMD can be used for estimating the conformational energy landscape (Gur et. al, 2015).
coMD can be used for
coMD plugin files can be obtained from Getting coMD.
References
Gur M, Madura DJ, Bahar I
Global Transitions of Proteins Explored by a Multiscale Hybrid Methodology: Application to Adenylate Kinase
2013 Biophys J 105(7):1643-1652.
Gur M, Zomot E, Cheng MH, Bahar I.
Energy Landscape of LeuT from Molecular Simulations.
2015 J Chem Phys 143(24):243134.


| | |
- builtins.object
-
- State
class State(builtins.object) |
| |
Data structure representing the general state of a set of qubits.
The state is represented via the amplitudes of each basis state.
With basis states (here) always refer to the computational basis.
The computational basis emerges from considering all individual settings
of the qubits. Each qubit can individually be on or off (up or down),
The total number of possible combinations is therefore 2 ^ qubit_count,
where qubit_count is the number of qubits. This would classically also be
the total number of possible configurations. Quantum mechanically, however,
the system can be in an arbitrary superposition of these states.
In the computational basis, we assign a number (label) to the
configurations, as one does in classical computing.
All states being down (off) corresponds to the value 0, the first bit up
and the rest down is 1, the second bit up and the rest down is 2, etc.
Example:
A system with 3 qubits has 2 ^ 3 = 8 basis states.
writing up as 1, down as 0 these states are
|0>|0>|0>, |0>|0>|1>, |0>|1>|0>, |0>|1>|1>, ...
(using order of computational basis)
For convenience we write |c>|b>|a> = |cba> where a, b, c in {0, 1}.
A basis state with label m in the computational basis is written |m>.
The basis states for our 3 qubit system are therefore
|000> = |0>, |001> = |1>, |010> = |2>
|011> = |3>, |100> = |4>, |101> = |5>
|110> = |6>, |111> = |7>.
This is exactly how numbers are represented in classical,
binary computers.
Generally, a state |..., n_1, n_0> = | (sum n_k * 2 ^ k) >,
where n_k in {0, 1} and k = 0, ..., qubit_count - 1.
Note that in the states of the computational basis, the values of different
qubits are not entangled. To represent a general state, including entangled
qubits, we must allow superpositions of these basis states.
Any state can be represented by specifying it's amplitudes regarding the
computational basis (linear algebra).
Example:
In a 2 qubit system (omitting a factor 1/sqrt(2) for normalization):
(|0> + |1>) |0> = |0> + |2>
would represented as State([s2, 0, s2, 0]) where s2 = 1/sqrt(2)
>>> s = State([1, 0, 1, 0]) # not normalized
>>> print(s)
1.000 |0> + 1.000 |2>
>>> s.prob_of_bs(1) # no chance of measuring system in state |1>
0.0
>>> s.prob_of_bs(0) # method automatically considers norm
0.5
>>> s.prob_of_state(State.from_basis_state(2, 0)) # same as above
0.5
>>> s = s / s.norm() # normalize state
>>> s.is_normalized()
True
>>> s.norm()
0.99999999999999989
In the last line, the limitation of this simulation become obvious:
The square root of two cannot be accurately be represented using floats.
This leads to a rounding error when calculating the norm.
To test equality in these cases, use np.close. |
| |
Methods defined here:
- __add__(self, state)
- Add the amplitudes of two states
:param state: the state object being added
:return: State object resulting from the addition
- __eq__(self, state)
- __getitem__(self, item)
- Return an amplitude of 1 basis state in the State object
:param item: The basis state (int) to get the amplitude of
(equivalent to the index in the array of amplitudes)
:return: The (complex) amplitude of the basis state
- __init__(self, initial_state, dtype=)
- Initialize state given a set of amplitudes.
Example:
>>> s = State([1, 0, 0, 0])
>>> s
array([ 1.+0.j, 0.+0.j, 0.+0.j, 0.+0.j])
>>> print(s)
1.000 |0>
:param initial_state: Iterable, specifying amplitude for
each basis state.
:param dtype: Numeric type to be used for amplitudes.
- __iter__(self)
- __len__(self)
- Prevent the implementation of len.
state must not implement len, otherwise multiplying a numpy data type
and a state will result in __mul__ being (successfully) called on the
numpy data type (which is possible because __getitem__ and __iter__ are
implemented by State). This, however returns a new numpy array of the
left hand data type, instead of a State (which is what we want).
By raising an error here, this case results in __rmul__ being called
on state, which is the correct behaviour.
>>> s = np.complex128(42) * State.from_basis_state(4, 0)
>>> type(s) == State # s must be a state, not (!) an ndarray
True
:return: Failure.
- __mul__(self, other)
- Multiply state and state or state and complex number
:param other: State or complex number.
:return: Depending on type of other:
complex number -> state with amplitudes element wise multiplied
state -> complex number <self|other>
- __neg__(self)
- The additive inverse of a State object (in terms of its amplitudes)
:return: State, with each amplitude element multiplied by -1
- __radd__(self, other)
- Support addition to zero (as neutral element).
Do not explicitly call this.
This method is needed to support the builtin sum method.
Adding a state to 0 will yield the state:
>>> s = State([0, 1])
>>> (0 + s) == s
True
Executing 'state + state' will always lead to __add__ being called.
Generally 'number + state' or 'state + number' is not supported,
as the meaning of these statements is ambiguous.
:param other: 0.
:return: State(self).
- __repr__(self)
- The representation
:return:
- __rmul__(self, number)
- Right multiplication of a state
Only implemented for a state and a number
:param number: Complex number being (right) multiplied by the state
:return: State object with amplitudes multiplied element-wise
- __setitem__(self, key, value)
- Set an amplitude of 1 basis state in the State object
:param key: The basis state (int) to set the amplitude of
(equivalent to the index in the array of amplitudes)
:param value: The (complex) value to set the amplitude to
:return: Nothing (modifies the State object being acted on)
- __str__(self)
- __sub__(self, state)
- Subtract the amplitudes of one state by the amplitudes of another state
:param state: the State object being subtracted by
:return: State resulting from the subtraction
- __truediv__(self, number)
- Divide a the amplitudes of a State object by a (complex) number, element-wise
:param number: The (complex) number dividing the amplitudes
:return: The State object, with it's amplitudes divided
- is_normalized(self)
- Checks if a State object is (close to being) normalized (sum of squared amplitudes == 1)
Uses the numpy function isclose
:return: Returns the Bool:
True if the object is close to being normalized
False if the object is not close to being normalized
- norm(self)
- Returns the sum of the squared amplitudes of the state.
:return: float, norm of the state vector
- prob_of_bs(self, bs, normalize=True)
- :param bs: The basis state of interest.
:param normalize: Normalize state before calculating amplitudes.
:return: The probability of the system being in the basis state
of interest.
- prob_of_state(self, state, normalize=True)
- The probability of a State being in particular State object (not necessarily a basis state)
:param state: The state of interest (does NOT have to be a basis state,
can be any State object)
:param normalize: Normalize state before calculating amplitudes.
:return: The probability of the system being in the state of interest
- random_measure_bs(self)
- Select a basis state with probabilities according to amplitudes.
Make a random choice on the basis states each weighted with
the probability of finding the system in that state
(i.e. amplitude squared).
To illustrate the implementation, consider the (2-qubit) state
with amplitudes [0.25, 0.25, 0, 0.5] = 0.25|0> + 0.25|1> + 0.5|3>.
The first step, conceptually, is to split the real numbers
between 0 and 1 into chunks with sizes according to the probabilities
of the basis states:
0.0 0.25 0.5 0.75 1.0
| | | | |
00000|11111||33333 33333
A random number (in [0, 1)) is generated and the basis state chosen
is the one to which the block belongs, the random number is found in.
By making blocks belonging to one basis state larger,
it gets more probable this basis state will be measured.
:return: The basis state which the state was measured to be in
- random_measure_qubit(self, qubit)
- Randomly get state of one qubit according to state's probabilities.
:type qubit: int
:param qubit: Index of qubit to measure.
:return: Either 0 or 1.
Class methods defined here:
- from_basis_state(qubit_count, basis_state, dtype=) from builtins.type
- Creates a State object that is a basis state, given its label.
:param qubit_count: Number of qubits in the state
:param basis_state: The basis state to create
:param dtype: Numeric type to use for amplitudes in state.
:return: State object in the basis state specified
Data descriptors defined here:
- __dict__
- dictionary for instance variables (if defined)
- __weakref__
- list of weak references to the object (if defined)
Data and other attributes defined here:
- __hash__ = None
| |


FileNameOptions Class Reference
Inherits Options.
Detailed Description
Options for examples with additional file name parameter.Definition at line 47 of file javascript.cc.
Public Member Functions | |
| FileNameOptions (const char *n) | |
| Initialize options for example with name n. | |
| virtual void | help (void) |
| Print help text. | |
| void | parse (int &argc, char *argv[]) |
| Parse options from arguments argv (number is argc). | |
| void | file (const char *f) |
| Set file name. | |
| const char * | file (void) const |
| Return file name. | |
Protected Attributes | |
| const char * | _file |
| File name value. |
Constructor & Destructor Documentation
| FileNameOptions::FileNameOptions | ( | const char * | n | ) |
Member Function Documentation
| void FileNameOptions::help | ( | void | ) | [virtual] |
| void FileNameOptions::parse | ( | int & | argc, | |
| char * | argv[] | |||
| ) |
Parse options from arguments argv (number is argc).
Reimplemented from Options.
Definition at line 83 of file javascript.cc.
| void FileNameOptions::file | ( | const char * | f | ) | [inline] |
| const char * FileNameOptions::file | ( | void | ) | const [inline] |
Member Data Documentation
const char* FileNameOptions::_file [protected] |
The documentation for this class was generated from the following file:
- examples/javascript.cc (Revision: 6002)


---
layout: layouts/base.html
title: News
---
{% include ./menu.html %}
{% include components/sections/pageheader.html, pageheader_title: 'Text page', pageheader_text: ' ', src: 'https://images.unsplash.com/photo-1429704658776-3d38c9990511?ixid=MnwxMjA3fDB8MHxzZWFyY2h8MTJ8fGxhbmRzY2FwZXxlbnwwfHwwfHw%3D&ixlib=rb-1.2.1&auto=format&fit=crop&w=1920&h=1080&q=60' %}
{% include components/sections/text.html, container_class: 'grid__container--xs' %}
{% include components/sections/image.html, container_class: 'grid__container--xs' %}
{% include components/sections/text.html, container_class: 'grid__container--xs' %}


We are witnessing the rise of contextual applications. In the past, applications, whether they were websites, desktop applications or otherwise, operated without regard to the circumstances of their users. Today, however, we are seeing a new generation of applications that react and respond dynamically to the context and circumstances of their users.
Contextual applications have the potential to interact with users in a more effective, efficient and authentic manner than ever before. Additionally, contextual applications can leverage a wider variety of user interfaces (such as voice and gestural control).
This trend towards contextual applications is driven by five forces identified by Robert Scoble and Shel Israel in their 2013 book The Age of Context.
The proliferation of mobile devices has embedded computing capabilities into a wide variety of real-world contexts. Using mobile phones, tablet computers, smart watches, Google Glass, etc., we are now building applications meant to be used while shopping, jogging, driving and so on. This is a far cry from the uniformity of application context historically, where an application designer could assume that the user was sitting at a desk in front of a computer.
The widespread adoption of social media such as Facebook, Twitter, LinkedIn and so forth has created a massive graph of human interaction data, enabling introspection into various behaviors and affinities of individuals as they interact with their peers. This data can form the basis of insights about users, to which applications can strategically respond.
The reduced cost of data collection and storage, combined with new techniques for analyzing data, have made automated insights into user circumstances, preferences and behavior more practical than ever before. The availability of user data makes dynamic responses by applications possible.
A significant force accompanying the proliferation of data and mobile devices is the ubiquity of sensors. GPS, micro-location, motion sensors, biometric sensors and, of course, cameras, all power the opportunity for passive collection of vast amounts of contextual data (Where is the user? Are they moving? Is their heart beating fast? e.g.) These sensors are becoming increasingly inexpensive, and they are everywhere.
Knowing a user's physical location is key to understanding their context. Whether a user is at work, at home, in transit, or performing an errand, their location implies much about their context. We now have significant amounts of metadata associated with geographical locations, which can be used to make contextual inferences.
A contextual application responds dynamically to user context. While the business case and the technology exists for the building of contextual applications, what is lacking is a design language in which to articulate them. To describe dynamic response to user context there have been various attempts to draft existing design and specification formats, such as heavily annotated wireframes, UML state diagrams and flowcharts, but none of these are optimized for contextual application design. The problem is exacerbated when trying to describe common modal functionality that can be expressed through multiple user interfaces, or when dealing with a purely contextual interface such as voice control, such as Siri or Google Now.
The lack of a language to articulate contextual applications creates a design bottleneck: the desire and capability to build such applications exists, but there is no way to describe them.
The best way to approach an abstract application design problem is to use a foundational metaphor upon which a system of interaction can be built. Some historical examples of foundational metaphors include the *desktop *metaphor in personal computing, and the web page. While there is nothing intrinsic in a computer operating system that requires the concept of a desktop, nor anything intrinsic in the networked exchange of files that requires the concept of a page, both metaphors are used to build an organizational model in the application designer's mind.
For contextual applications, the best foundational metaphor is the natural language conversation. A conversation conducted between two individuals is a perfect example of ongoing dynamic response to context. A conversational participant gathers context concerning their counterpart based both on explicitly communicated information as well as inferences that they make based on their counterpart's actions and circumstances. In response to this context, the participant dynamically alters their behavior in real time.
Describing how an application behaves as a participant in a two-way conversation is the best way to organize and specify the behavior of a contextual application.
CAVE is a visual design language for expressing the behavior of contextual applications. It uses the conversational metaphor to describe user context and application response.
Example: Bike App To provide a running example, CAVE will be used to describe an app for cyclists that warns them when rain is coming and guides them to shelter. It is envisioned as working on Google Glass-like smart glasses, in conjunction with the cyclist's cell phone.
CAVE is designed with the following goals in mind:
CAVE should adapt well to different formats as needed. It should look fine in highly polished documents or presentations in the boardroom, but at the same time be useful written on the back of a napkin. It should be practical to write CAVE drawings on a whiteboard while discussing application design. In other words, precise usage of CAVE is okay, but sloppy usage of CAVE is also okay.
CAVE is a language, not a methodology. CAVE isn't prescribing best practices for contextual application development, it's just providing a means of expressing them. Additionally, nothing in CAVE should prevent you from using your favorite methodology, nor should it interfere with other existing practices such as agile development or user-centered design.
CAVE should be suitable for sparing use, to describe a simple idea with minimal effort. At the same time you should also be able to use CAVE extensively, to describe large, complex systems, without encountering limitations in the language.
Contextual applications are built by teams of people with different skill sets. CAVE should serve everyone on the team, allowing each member to understand the application in the way they specifically need in order to do their job. CAVE drawings should connect the team, effectively acting as a canonical representation of the application.
CAVE is organized into three layers, each describing an aspect of a contextual application: data, context and modal response. Each layer builds on the previous one.
A contextual app has to deal with the collection, acquisition and processing of data. This is described in the Data Layer. It shows data and its origins, whether they are sensors, external data sources or user input. A CAVE data drawing should always answer the question, "Where does this data come from?"
From raw data, meaningful context can be inferred. The context layer builds upon the data identified in the data layer, and, through inferences, creates insights into user context. For example, a CAVE context drawing might show how an inference maps user behavioral data to an insight about a user's affinity.
A contextual application will observe user context and respond in a specific way. CAVE modal response drawings show a prioritized stack of target contexts is examined, each with a corresponding modal response.
Context starts with data, and one of the central issues of developing contextual applications is the identification, sourcing and processing of data. The Data Layer of CAVE facilitates the planning of data usage by the application.
Data doesn't spring out of nowhere. It needs to have an origin specified for it, such as a Sensor. Sensors are generally associated with Devices.
Tracing the origin of data from device, through sensor, to data
Sometimes applications use more than one device in conjunction, pulling capabilities from both devices. A common case is a wearable tech item working in conjunction with a smart phone, using Bluetooth. This is called a Device Federation.
Two devices working together
It's also possible that the application is using data that is provided by an external source, such as through the API of a social network.
Data can also originate from external data sources, such as APIs
Typically, a CAVE data layer drawing will show the association between data and its origins. This allows application developers to know what will be required in terms of integrations, device capabilities and so on.
Sometimes data can be processed to create more refined data. Typically the resulting data has additional information that has been extrapolated from the rawer input. This is called Processed Data.
Processed Data can be extracted directly from Data
Finally, there is a special type of data that is treated differently from all others: User Input.
User Input is explicit input created by the application user via a user interface. Unlike any other data, user input can be accessed directly in the Modal Response layer, it does not have to be processed into context first.
Example: Data for the Bike App
The bike app works as a federation between two devices, the user's smart glasses and his phone. This federation makes available a GPS Sensor, a Motion Sensor, and User Input methods to applications.
From the GPS Sensor, the bike app extracts the current location of the user and historical route data. The bike app notes how long it takes to bike the distance of historical routes over time, creating average times per route as Processed Data. From the Motion Sensor, the app can determine if the user is in motion.
The app also collects the locations of the user's home and work as explicit User Input.
Finally the app integrates with an external weather service API to pull local weather forecast and radar data, and with a social network API to get locations that are suitable rain shelters.
Once data is collected it needs to be interpreted in such a way so that the application knows what the data means. CAVE refers to the product of this interpretation as Context.
Context is comprised of several different kinds of elements, each of which mean slightly different things for an application.
A Persona represents an aspect of the user's personality, based on cues from her behavior. A Persona has a specific label, and user traffic is sorted into a handful of personas, effectively serving as behavioral segments.
Affinity represents the preferences of the user, either for specific content, products or other items, or for abstract metadata. Affinity is always as a variable placeholder: instead of meaning a specific, labeled affinity, it stands for whatever the affinity of the user happens to be.
A Goal represents something the user is trying to accomplish. It is used to represent immediate concrete goals, not something abstract or long-term. As such, Goals are treated as a stack, with one primary Goal for a user at a time. Only if the primary Goal is resolved will lower priority Goals be available.
A user's Environment is the circumstances that surround them while they interact with the application. Environment is a fairly open concept: it may represent the user's location, any sensor data such as motion, biometrics, etc., and the technology the user employs to interact with the application (device, software, etc.). Excluded from a user's Environment are global or widespread conditions that are not unique to the user. See State, below, for those.
Sentiment refers to the inferred emotional state of the user at the time of the interaction. Sentiment is generally categorized as either positive or negative, although more specific emotions can be used if the technical capability to assess them is available. At the modal response layer (see below) Sentiment is always used in an explicitly labeled format (positive, negative, angry, sad, etc.), however it may be either created in a labeled format in an inference, or simply be captured as a placeholder from processed data.
A State is a global or widespread condition (for example, the weather) that is significant to the application, but not specific to the user (meaning that it is not part of the user's Environment). Like User Context Elements, State can be created in the Context layer from raw data.
An inference processes raw data and produces meaningful context. It is represented by a set of square braces, with the input data associated.
An inference is made from data
For most inferences, there is a condition that must be met by the raw data in order for inference to fire and create the context.
An inference usually has a condition that must be met by the data
In this example, the inference will only fire if the motion data indicates that the user is in motion.
On the right side of the inference is the consequence if it fires. In this case, the inference will assign the label "In Motion" to the user's Environment (see the Environment context element, below) if the motion data indicates the user is in motion.
If the data meets the condition, the context element on the right side of the inference is associated with the user
A device migration is the act of a user changing from one device to another. This action can be used as a triggering condition that modifies a user's Environment.
If the user migrates from their tablet to their phone, their Environment context is modified accordingly
Example: Inferring Context for the Bike App
The bike app contains six inferences:
- If the motion data indicates that the user is in motion, they are associated with the Riding Environment.
- If the current location data and the historic route data indicate that the user's location is along a known route, they are associated with the En Route Environment.
- In the event that the average time per route Processed Data, the current location data and the weather forecast / radar data indicate that it's likely that it will rain before the destination is reached, the current user will be associated with the Rain Imminent Environment.
- If the current location data and the shelter locations data indicate that the user is approaching a rain shelter, the user will be associated with the Riding for Shelter Goal.
- If the current location data and the location of home user input indicate that the user is approaching home, they will be associated with the Riding for Home Goal.
- If the current location data and the location of work user input indicate that the user is approaching work, they will be associated with the Riding for Work Goal.
The defining characteristic of contextual applications is that, when faced with specific user context, they can change the way they work. In CAVE this dynamic behavior is defined in the Modal Response layer.
A Switch is a part of a contextual application that reacts to user context. An application may have just one switch or many. Multiple switches act independently of each other.
A Switch has a stack of Context rules, which are evaluated against the current user context in priority order. For each Context rule, there is a corresponding modal response from the Switch. At the bottom of the stack there is always a default response.
A switch shows which contexts trigger which modal responses. Context rules go on the left, modal responses in the middle, user interfaces on the right
A context rule consists of a number of context elements that the switch is seeking to match. If all of the elements of a user's context match the rule, then it will fire and the Switch will respond in the way dictated in the corresponding modal response. A Context Rule may contain specified Persona, Affinity, Goal, Environment and Sentiment elements.
In addition to user context a Context Rule may contain two other elements: a State (a required global condition) and explicit User Input.
If the user's context does not match the Context Rule, the Switch will continue to the next Context Rule in the stack, attempting to match it.
Even for applications for which, for a user, there is only one active Switch, it is often beneficial to subdivide a complicated application into multiple switches. Switch Migrations (see below) can be used to pass control from one Switch to another for a user.
Associated with a Context Rule is the Switch's modal response, which consists of a Modal Inventory. The inventory describes all the elements of the Modal Response to the specified context, with the goal of showing the product team what they need to do to implement that modal response.
A modal inventory may consist of any of the following element types:
Content is specific written copy, audio, video or some other format.
To indicate a general policy for content within the modal response, without specifying the exact content, a Content Policy element may be used. It could be labeled "related products" or “customer testimonials.”
Functionality indicates some interactive feature set of the application that is activated in this modal response.
A rule is a business rule that is active within the modal response. This frequently is used in conjunction with a Functionality element, modifying its behavior.
Style specifies the general timber and color of the modal response. It will be reflected in other aspects, such as content and the design of the user interface.
Instead of a modal response consisting of a mode inventory, a Context Rule may trigger a Switch Migration. A switch migration indicates that control for the user is being passed to another Switch. On firing a Switch Migration, the new Switch will immediately evaluate the user context starting at the top of its context stack.
A User Interface may be associated with a modal response. In the case of visual user interfaces, this could be a wireframe or mock-up: in the case of audio user interfaces this might be a card with an example of spoken word content.
The point of User Interfaces in CAVE is to show how they are associated with the modal response of an application.
Example: Bike App Modes - Initial Switch
The Bike App starts operating on its Initial Switch. At this Switch's highest priority, it is looking for the user to be associated with two Environments: Riding (meaning they are in transit) and Rain Imminent (meaning it's going to rain before they reach their destination).
If this rule is satisfied the Bike app will display the rain imminent warning content, calculate the route to the nearest shelter, and migrate to the Rain Imminent Switch.
Otherwise, the default behavior is to display weather information to the rider.
Example: Bike App Modes - Rain Imminent Switch
The highest priority on the Rain Imminent Switch to look for a user with the En Route Environment, the Rain Imminent Environment, who is also carrying a Ride for Shelter Goal. In this case the Bike App will display a Countdown to Rain Content Policy, the Rain Imminent warning, provide directions to the shelter, and carry an urgent style (red warnings, terse language etc.).
If the Environments are present, but the user is instead carrying a Goal of Ride for Work or Ride for Home, the app will migrate to the Beat the Weather Switch.
If neither rule applies, the default behavior for this Switch will be to restore control to the Initial Switch.
Example: Bike App Modes - Beat the Weather Switch
In the Beat the Weather Switch, the highest priority rule is looking for the En Route and Rain Imminent Environments, and either a Ride for Home or Ride for Work Goal. If this is matched, the app will respond with three Content Policies: some exciting music for the rider, a countdown to rain indicator and a countdown to destination indicator.
The second rule is in case the rider changes their mind and decides to find a shelter after all. In this case the two Environments are the same, but the Goal is now Ride for Shelter. This will cause the app to migrate back to the Rain Imminent Switch.
The default behavior, if neither rule fires, is to return control to the Initial Switch.


I am a User Experience Designer based in Toronto. My philosophy to design is to create research-centred experiences that enable humans to navigate a piece of technology as if it was an extension of the self.


You can improve the appearance and presentation of the Dependencies page by updating the tableDependCat.xml file.
First:
You can improve the title by changing the 'singular_name' and 'plural_name' elements.
Second:
You can change the order of columns, or choose to remove them from the display, by changing the 'col' element in 'display_columns'.
The two columns to remove are only used for backward compatibility with old versions of the DB2 server.
The other columns are rearranged into a more logical order.
Third:
You can change the column titles by updating the 'c_title' element in 'display_columns'.
Goal:
Clean up the appearance of the Dependencies page.
Steps to complete:
- Open the file '/var/www/tableDefinitions/tableDependCat' from gedit or open a terminal and run the following command:
- “gedit /var/www/tableDefinitions/tableDependCat.xml &”
- Make the changes as indicated on the right
- Save the file
- Do not close the file
The changes are indicated with the following:
- Indicated text has been removed
- Indicated text has been edited
- Indicated text has been added
- Indicated text is the source of a copy


Find out which track is right for you!
So, you are thinking about learning a programming language but you aren't sure which one to learn?
We'll help you out! Take this quiz to get some suggestions about which language you should start with.
It seems like you are interested in front-end development. In the CSS/Design track, you will learn how to make webpages and applications that work well and look great. You will learn about layouts, navigation, colors and design.
This track, like all the Epicodus tracks includes introductory training in HTML, CSS, JavaScript, jQuery, and the use of GitHub.
Remember, the most important thing is to get the basic principles of coding down, practice a lot, and be ready to change to another language if needed.
We see that you are interested in mobile developement. In this track you will learn one of the most popular programming languages in Java, as well as how to build Android user interfaces.
This track, like all the Epicodus tracks includes introductory training in HTML, CSS, JavaScript, jQuery, and the use of GitHub.
Remember, the most important thing is to get the basic principles of coding down, practice a lot, and be ready to change to another language if needed.
C# is one of the most popular coding languages among larger, established businesses and is often used for building internal software. This is a great choice because it is also one of the most in-demand languages in the job market! It is also commonly used in video game development.
This track, like all the Epicodus tracks includes introductory training in HTML, CSS, JavaScript, jQuery, and the use of GitHub.
Remember, the most important thing is to get the basic principles of coding down, practice a lot, and be ready to change to another language if needed.
PHP is the most popular back-end programming language today, and its versatility makes employment options numerous and diverse. You will be able to work with fast-paced agencies making websites for all types of clients, or work with government organizations in maintaining security and stability.
This track, like all the Epicodus tracks includes introductory training in HTML, CSS, JavaScript, jQuery, and the use of GitHub.
Remember, the most important thing is to get the basic principles of coding down, practice a lot, and be ready to change to another language if needed.
You seem to be interested in working in a fast-paced environment creating dynamic content. If so, the Ruby/Rails track is a great fit. It is most popular with startups and smaller companies who are looking to build their product quickly.
This track, like all the Epicodus tracks includes introductory training in HTML, CSS, JavaScript, jQuery, and the use of GitHub.
Remember, the most important thing is to get the basic principles of coding down, practice a lot, and be ready to change to another language if needed.


Author | Gavin F
It is my sworn duty to go on the mighty crusade of removing the thots and fortnite characters from this world.


Skills progress
LONG-TERM GOALS & SKILL TRACK
Artificial Intelligence
Blockchain Technology
Robotics & Automation
Quantum Computing
Reverse Engineering
3D Modeling
Data Visualisation
Circuit Design
Networking and IT
App&Game development
Design Sprint
Hardware programming
SHORT-TERM GOALS
VIM
Tailing VM (bspwm)
LATEX
Containers
NixOS & NixShell
ROS2.0
Unreal Engine
Home Assistant
*when an entry of short term goal enters baking phase (when i feel that i know more thn 80% what i think is essential), gets removed from the short-term goals list and gets acumulated to long-term goals list in the one of the generalized topics.
Finished skills
VIM
Tailing VM (bspwm)
LATEX
Containers
NixOS & NixShell
ROS2.0
Unreal Engine
Home Assistant


Overview of the template, its contents, and how to get started with the template.
Thank you for purchasing our template. If you have any questions that are beyond the scope of this help file, you can sign up to our support forums with your purchase code and start a ticket, and please rate the template on themeforest if you liked it. Thanks so much!
- Pixelwars Team
Any questions that are beyond the scope of this help file, use support forums.
Follow us on themeforest and don't miss new upcoming premium themes.
If you liked the theme you can rate it on themeforest in your downloads menu.
We assume you have basic knowledge of HTML / CSS and JS. In this doc you will not learn how to code but you will learn how to setup, use and customize the theme. Before you begin make sure you have a code editor, you can use Dreamweaver or any other editor like Notepad++ will be enough.
Within the download you'll find the following file structure, logically groupped common assets.
Once downloaded, unzip the compressed folder to see the structure of th theme. You'll see something like this:
Impose/ ├── css/ ├── js/ ├── images/ └── index.html └── other html files
In this template you will find all HTML files in well formatted and highly commented. Most of the markup is self explanatory with comments. So i will only explain the parts where the markup needs more attention.
Uses plain HTML5 Doctype
<!DOCTYPE html>
Head tags contains meta tags, font / css and some script files, other script files are added just before the closing tag of the body.
Here are meta tags and title. You can edit them as you want except the viewport meta tag, it preserves responsive layout.
<meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <meta name="description" content="Impose - Responsive HTML5 Template"> <meta name="keywords" content="personal, blog, html5"> <meta name="author" content="Pixelwars">
Here are favicon and apple touch icon (196x196 pixels .png format);
 <link rel="shortcut icon" href="images/ico/favicon.ico"> <link rel="apple-touch-icon" href="images/ico/apple-touch-icon.png"/>
Here are fonts. Fonts by Google Webfonts
 <link href="https://fonts.googleapis.com/css?family=Lato:400,700|Noto+Sans:400,400i,700,700i|Poppins:300,400,500,600,700" rel="stylesheet">
Initial scripts in the head.

Here are css files.
 <link rel="stylesheet" type="text/css" href="css/bootstrap.min.css"> <link rel="stylesheet" type="text/css" href="css/fonts/fontello/css/fontello.css"> <link rel="stylesheet" type="text/css" href="js/jquery.magnific-popup/magnific-popup.css"> <link rel="stylesheet" type="text/css" href="js/jquery.fluidbox/fluidbox.css"> <link rel="stylesheet" type="text/css" href="js/owl-carousel/owl.carousel.css"> <link rel="stylesheet" type="text/css" href="js/selection-sharer/selection-sharer.css"> <link rel="stylesheet" type="text/css" href="css/rotate-words.css"> <link rel="stylesheet" type="text/css" href="css/align.css"> <link rel="stylesheet" type="text/css" href="css/main.css"> <link rel="stylesheet" type="text/css" href="js/shortcodes/shortcodes.css"> <link rel="stylesheet" type="text/css" href="css/768.css"> <link rel="stylesheet" type="text/css" href="css/992.css">
All other script files are located at the end of the body tag. These are the general script files used over all files.

This template contains 2 types of header: Header Small and Header Classic
To use header small, firstly header-small
class should be added to html
tag.

Here is the markup for header small;

   Haley Dust

 <form method="get" class="search-form" action="#"> Search Here <input type="search" id="search-field" placeholder="type and hit enter" name="s">  <input type="submit" class="search-submit" value="Search"> </form>

See index.html
for live preview of header small.
To use header classic, firstly header-classic
class should be added to html
tag.

Here is the markup for header small;

 <form method="get" class="search-form" action="#"> Search Here <input type="search" id="search-field" placeholder="type and hit enter" name="s">  <input type="submit" class="search-submit" value="Search"> </form>

   Haley Dust

just living the life as it goes by

See blog-regular-with-sidebar.html
for live preview of header classic.
This template is based on Bootstrap 's solid responsive 12 column grid system.
Here is a simple example of using grid to crate a 3 column layout;

column 4/12

column 4/12

column 4/12

Note that: columns must be wrapped by a row
container. This is a simple usage of the grid system. Bootstrap grid sytems has more powerfull features, check out Bootstrap Doc to learn more about the grid system.
This template uses 1 font icon set. They are all font icons(vector) and can be styled easily with css. They are also easy to drop in anywhere as you will see in some part of this template.

1-) You can change mail subject in form's html markup;
 <input type="hidden" name="subject" id="subject" value="You have a new message">
Change only the value="You have a new message."
to your desired subject.
2-) Edit send-mail.php
in a text editor,
// site owner $site_name = 'Impose HTML5 Template'; $sender_domain =<EMAIL_ADDRESS>$to =<EMAIL_ADDRESS>$site_name
: this will be shown as sender name.$sender_domain
: this is required for some hosting like dreamhost. It should be like<EMAIL_ADDRESS>.$to
: This is the receiver e-mail address, your address.Here is a complete list of used css files in the theme and what thay stand for;
In this theme we have used font icons instead of png icons, because font icons are vector-scalable, ready for retina screens, saves bandwidth and easy to work with.
We are using jquery as javascipt framework.
Here is a complete list of used script files in the template and what thay stand for;
We designed this template for easy customization. You can customize the template easily to your needs in 3 general ways : Html Data Attributes / Html Classes and custom css .
Here are some classes you can add to html
tag for various customizations;
minimal-style
: adds minimal look to the site in generalflat-style
: adds flat look to the site in generalis-menu-fixed
: enables sticky menu (menu shows only when user scrolls up)is-menu-fixed is-always-fixed
: enables always sticky menu, menu is always visible.header-light
: enables light header (header is dark by default).header-small
: add when using small header.header-classic
: add when using classic header.is-selection-shareable
: enables selection-sharer script on posts.blog-animated
: makes blog pages animated.
data-effect
is the animation type when using blog animated. Available animations are; fadeIn - zoomIn - slideUp - slideInUp.
Here are some simple css code snippets to customize the essentials;
Change link colors;
/* Links */ a { color: #096; } a:hover { color: #5BCF80; }
Change text-selection color;
/* Text Selection */ ::selection { text-shadow: none; color: #333; background: #FFFFCF; } ::-moz-selection { text-shadow: none; color: #333; background: #FFFFCF; }
Change button hover color;
input[type=submit]:hover, input[type=button]:hover, button:hover, a.button:hover { color: #fff; background: #212933; }
Change menu background color;
.site-navigation { background: #212933; }
Change primary green color when using flat-style;
/* PRIMARY COLOR : #2BBE8D */ .flat-style .entry-meta .cat-links a, .flay-style .owl-theme .owl-dots .owl-dot.active span, .flat-style input[type=submit], .flat-style input[type=button], .flat-style button, .flat-style a.button, .flat-style .button, .flat-style .skill-unit .bar .progress span, .flat-style .event [class*="pw-icon-"], .flat-style .owl-theme .owl-dots .owl-dot.active span { background: #2BBE8D; } .flat-style .format-link .entry-content > p:first-child a:first-child, .flat-style .event.current:after, .flat-style input:not([type=submit]):not([type=button]):not([type=file]):not([type=radio]):not([type=checkbox]):focus, .flat-style textarea:focus, .flat-style select:focus { border-color: #2BBE8D; }
We included the fonts in this template from Google Webfonts which uses font-face technique for font embeeding.
Font declerations are at the head section;
 <link href="https://fonts.googleapis.com/css?family=Lato:400,700|Noto+Sans:400,400i,700,700i|Poppins:300,400,500,600,700" rel="stylesheet">
To change fonts, just go to Google Webfonts site, search and select a new font, click "Quick use" link, then copy the stylesheet code from Add this code to your website: / Standart section and paste the code into head
section. Then change the font family name in main.css starting from line:63. These font definitions in main.css are the only font definitions for the entire theme, once you have changed font-family in these lines, you are done!
/* ----- 1.2 FONTS ----- */ /* BODY */ body, input, textarea, select, button, .event h5, .event h6 { font-family: 'Noto Sans', sans-serif; } /* HEADINGS */ h1, h2, h3, h4, h5, h6, #search-field, .nav-single, .comment-meta .fn, .yarpp-thumbnail-title, .widget_categories ul li, .widget_recent_entries ul li, .tptn_title, .blog-simple .day, .intro .wp-caption-text { font-family: 'Poppins', sans-serif; } /* SITE TITLE */ .site-title { font-family: 'Poppins', sans-serif; } /* NAV MENU */ .nav-menu, .widget-title, .nav-single h4, .about-author h3, .share-links h3, .related-posts h3, .comments-area h3, .entry-title i { font-family: 'Lato', sans-serif; }


Set start now
Download
Get sql
Clear data
Place
Runner number
Obs.
Time
Position
Runner number
Obs.
Time


Functions
data
attribute e.g. $('#datetimepicker').datetimepicker(FUNCTION)
destroy
Destroys the widget and removes all attached event listeners
toggle
Shows or hides the widget
Emits
-
hide.datetimepicker
- if the widget is hidden after the toggle call -
show.datetimepicker
- if the widget is show after the toggle call -
change.datetimepicker
- if the widget is opened for the first time and the input element is empty andoptions.useCurrent != false
show
Shows the widget
Emits
-
show.datetimepicker
- if the widget was hidden before that call -
change.datetimepicker
- if the widget is opened for the first time and theuseCurrent
is set to true or to a granularity value and the input element the component is attached to has an empty value
hide
Hides the widget
Emits
hide.datetimepicker
- if the widget was visible before that call
disable
Disables the input element, the component is attached to, by adding a disabled="true"
attribute to it. If the widget was visible before that call it is hidden.
Emits
hide.datetimepicker
- if the widget was visible before that call
enable
Enables the input element, the component is attached to, by removing disabled
attribute from it.
clear
Clears the date picker by setting the value to null
viewDate
viewDate
Returns a moment
variable with the currently set options.viewDate
option.
viewDate(viewDate)
Takes a string, moment or Date
value.
This will change the viewDate
without changing or setting the selected date.