Merge remote-tracking branch 'lammps-ro/master' into lammps-icms

Resolved Conflicts:
	doc/Manual.html
	doc/Manual.txt
This commit is contained in:
Axel Kohlmeyer
2015-02-05 10:36:13 -05:00
232 changed files with 18621 additions and 5962 deletions

BIN
doc/Eqs/fix_ttm_blast.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 4.3 KiB

13
doc/Eqs/fix_ttm_blast.tex Normal file
View File

@ -0,0 +1,13 @@
\documentclass[12pt]{article}
\begin{document}
$$
{\vec F}_i = - \partial U / \partial {\vec r}_i + {\vec F}_{langevin} - \nabla P_e/n_{ion}
$$
\end{document}

BIN
doc/Eqs/fix_ttm_blast1.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 8.5 KiB

View File

@ -0,0 +1,13 @@
\documentclass[12pt]{article}
\begin{document}
$$
\nabla_x P_e = \left[\frac{C_e{}T_e(x)\lambda}{(x+\lambda)^2} + \frac{x}{x+\lambda}\frac{(C_e{}T_e)_{x+\Delta x}-(C_e{}T_e)_{x}}{\Delta x} \right]
$$
\end{document}

BIN
doc/Eqs/fix_ttm_ce.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 7.3 KiB

13
doc/Eqs/fix_ttm_ce.tex Normal file
View File

@ -0,0 +1,13 @@
\documentclass[12pt]{article}
\begin{document}
$$
C_e = C_0 + (a_0 + a_1 X + a_2 X^2 + a_3 X^3 + a_4 X^4) \exp (-(AX)^2)
$$
\end{document}

BIN
doc/Eqs/fix_ttm_mod.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 9.9 KiB

15
doc/Eqs/fix_ttm_mod.tex Normal file
View File

@ -0,0 +1,15 @@
\documentclass[12pt]{article}
\begin{document}
$$
C_e \rho_e \frac{\partial T_e}{\partial t} =
\bigtriangledown (\kappa_e \bigtriangledown T_e) -
g_p (T_e - T_a) + g_s T_a' + \theta (x-x_{surface})I_0 \exp(-x/l_{skin})
$$
\end{document}

View File

@ -1,7 +1,7 @@
<HTML>
<HEAD>
<TITLE>LAMMPS-ICMS Users Manual</TITLE>
<META NAME="docnumber" CONTENT="30 Jan 2015 version">
<META NAME="docnumber" CONTENT="4 Feb 2014 version">
<META NAME="author" CONTENT="http://lammps.sandia.gov - Sandia National Laboratories">
<META NAME="copyright" CONTENT="Copyright (2003) Sandia Corporation. This software and manual is distributed under the GNU General Public License.">
</HEAD>
@ -22,7 +22,7 @@
<CENTER><H3>LAMMPS-ICMS Documentation
</H3></CENTER>
<CENTER><H4>30 Jan 2015 version
<CENTER><H4>4 Feb 2014 version
</H4></CENTER>
<H4>Version info:
</H4>

View File

@ -1,7 +1,7 @@
<HEAD>
<TITLE>LAMMPS-ICMS Users Manual</TITLE>
<TITLE>LAMMPS Users Manual</TITLE>
<META NAME="docnumber" CONTENT="30 Jan 2015 version">
<META NAME="docnumber" CONTENT="4 Feb 2014 version">
<META NAME="author" CONTENT="http://lammps.sandia.gov - Sandia National Laboratories">
<META NAME="copyright" CONTENT="Copyright (2003) Sandia Corporation. This software and manual is distributed under the GNU General Public License.">
</HEAD>
@ -19,7 +19,7 @@
<H1></H1>
LAMMPS-ICMS Documentation :c,h3
30 Jan 2015 version :c,h4
4 Feb 2014 version :c,h4
Version info: :h4

View File

@ -410,9 +410,9 @@ g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
<TR ALIGN="center"><TD ><A HREF = "fix_qeq.html">qeq/dynamic</A></TD><TD ><A HREF = "fix_qeq.html">qeq/point</A></TD><TD ><A HREF = "fix_qeq.html">qeq/shielded</A></TD><TD ><A HREF = "fix_qeq.html">qeq/slater</A></TD><TD ><A HREF = "fix_reax_bonds.html">reax/bonds</A></TD><TD ><A HREF = "fix_recenter.html">recenter</A></TD><TD ><A HREF = "fix_restrain.html">restrain</A></TD><TD ><A HREF = "fix_rigid.html">rigid (o)</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_rigid.html">rigid/nph (o)</A></TD><TD ><A HREF = "fix_rigid.html">rigid/npt (o)</A></TD><TD ><A HREF = "fix_rigid.html">rigid/nve (o)</A></TD><TD ><A HREF = "fix_rigid.html">rigid/nvt (o)</A></TD><TD ><A HREF = "fix_rigid.html">rigid/small (o)</A></TD><TD ><A HREF = "fix_rigid.html">rigid/small/nph</A></TD><TD ><A HREF = "fix_rigid.html">rigid/small/npt</A></TD><TD ><A HREF = "fix_rigid.html">rigid/small/nve</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_rigid.html">rigid/small/nvt</A></TD><TD ><A HREF = "fix_setforce.html">setforce (c)</A></TD><TD ><A HREF = "fix_shake.html">shake (c)</A></TD><TD ><A HREF = "fix_spring.html">spring</A></TD><TD ><A HREF = "fix_spring_rg.html">spring/rg</A></TD><TD ><A HREF = "fix_spring_self.html">spring/self</A></TD><TD ><A HREF = "fix_srd.html">srd</A></TD><TD ><A HREF = "fix_store_force.html">store/force</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_store_state.html">store/state</A></TD><TD ><A HREF = "fix_temp_berendsen.html">temp/berendsen (c)</A></TD><TD ><A HREF = "fix_temp_csvr.html">temp/csvr</A></TD><TD ><A HREF = "fix_temp_rescale.html">temp/rescale (c)</A></TD><TD ><A HREF = "fix_thermal_conductivity.html">thermal/conductivity</A></TD><TD ><A HREF = "fix_tmd.html">tmd</A></TD><TD ><A HREF = "fix_ttm.html">ttm</A></TD><TD ><A HREF = "fix_tune_kspace.html">tune/kspace</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_vector.html">vector</A></TD><TD ><A HREF = "fix_viscosity.html">viscosity</A></TD><TD ><A HREF = "fix_viscous.html">viscous (c)</A></TD><TD ><A HREF = "fix_wall.html">wall/colloid</A></TD><TD ><A HREF = "fix_wall_gran.html">wall/gran</A></TD><TD ><A HREF = "fix_wall.html">wall/harmonic</A></TD><TD ><A HREF = "fix_wall.html">wall/lj1043</A></TD><TD ><A HREF = "fix_wall.html">wall/lj126</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_wall.html">wall/lj93</A></TD><TD ><A HREF = "fix_wall_piston.html">wall/piston</A></TD><TD ><A HREF = "fix_wall_reflect.html">wall/reflect</A></TD><TD ><A HREF = "fix_wall_region.html">wall/region</A></TD><TD ><A HREF = "fix_wall_srd.html">wall/srd</A>
<TR ALIGN="center"><TD ><A HREF = "fix_store_state.html">store/state</A></TD><TD ><A HREF = "fix_temp_berendsen.html">temp/berendsen (c)</A></TD><TD ><A HREF = "fix_temp_csvr.html">temp/csvr</A></TD><TD ><A HREF = "fix_temp_rescale.html">temp/rescale (c)</A></TD><TD ><A HREF = "fix_tfmc.html">tfmc</A></TD><TD ><A HREF = "fix_thermal_conductivity.html">thermal/conductivity</A></TD><TD ><A HREF = "fix_tmd.html">tmd</A></TD><TD ><A HREF = "fix_ttm.html">ttm</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_tune_kspace.html">tune/kspace</A></TD><TD ><A HREF = "fix_vector.html">vector</A></TD><TD ><A HREF = "fix_viscosity.html">viscosity</A></TD><TD ><A HREF = "fix_viscous.html">viscous (c)</A></TD><TD ><A HREF = "fix_wall.html">wall/colloid</A></TD><TD ><A HREF = "fix_wall_gran.html">wall/gran</A></TD><TD ><A HREF = "fix_wall.html">wall/harmonic</A></TD><TD ><A HREF = "fix_wall.html">wall/lj1043</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_wall.html">wall/lj126</A></TD><TD ><A HREF = "fix_wall.html">wall/lj93</A></TD><TD ><A HREF = "fix_wall_piston.html">wall/piston</A></TD><TD ><A HREF = "fix_wall_reflect.html">wall/reflect</A></TD><TD ><A HREF = "fix_wall_region.html">wall/region</A></TD><TD ><A HREF = "fix_wall_srd.html">wall/srd</A>
</TD></TR></TABLE></DIV>
<P>These are additional fix styles in USER packages, which can be used if
@ -425,7 +425,7 @@ package</A>.
<TR ALIGN="center"><TD ><A HREF = "fix_lb_rigid_pc_sphere.html">lb/rigid/pc/sphere</A></TD><TD ><A HREF = "fix_lb_viscous.html">lb/viscous</A></TD><TD ><A HREF = "fix_meso.html">meso</A></TD><TD ><A HREF = "fix_meso_stationary.html">meso/stationary</A></TD><TD ><A HREF = "fix_nh_eff.html">nph/eff</A></TD><TD ><A HREF = "fix_nh_eff.html">npt/eff</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_nve_eff.html">nve/eff</A></TD><TD ><A HREF = "fix_nh_eff.html">nvt/eff</A></TD><TD ><A HREF = "fix_nvt_sllod_eff.html">nvt/sllod/eff</A></TD><TD ><A HREF = "fix_phonon.html">phonon</A></TD><TD ><A HREF = "fix_pimd.html">pimd</A></TD><TD ><A HREF = "fix_qeq_reax.html">qeq/reax</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_qmmm.html">qmmm</A></TD><TD ><A HREF = "fix_reax_bonds.html">reax/c/bonds</A></TD><TD ><A HREF = "fix_reaxc_species.html">reax/c/species</A></TD><TD ><A HREF = "fix_smd.html">smd</A></TD><TD ><A HREF = "fix_temp_rescale_eff.html">temp/rescale/eff</A></TD><TD ><A HREF = "fix_ti_rs.html">ti/rs</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "fix_ti_spring.html">ti/spring</A>
<TR ALIGN="center"><TD ><A HREF = "fix_ti_spring.html">ti/spring</A></TD><TD ><A HREF = "fix_ttm.html">ttm/mod</A>
</TD></TR></TABLE></DIV>
<HR>
@ -479,11 +479,11 @@ KOKKOS, o = USER-OMP, t = OPT.
<TR ALIGN="center"><TD ><A HREF = "pair_none.html">none</A></TD><TD ><A HREF = "pair_hybrid.html">hybrid</A></TD><TD ><A HREF = "pair_hybrid.html">hybrid/overlay</A></TD><TD ><A HREF = "pair_adp.html">adp (o)</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_airebo.html">airebo (o)</A></TD><TD ><A HREF = "pair_beck.html">beck (go)</A></TD><TD ><A HREF = "pair_body.html">body</A></TD><TD ><A HREF = "pair_bop.html">bop</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_born.html">born (go)</A></TD><TD ><A HREF = "pair_born.html">born/coul/long (cgo)</A></TD><TD ><A HREF = "pair_born.html">born/coul/msm (o)</A></TD><TD ><A HREF = "pair_born.html">born/coul/wolf (go)</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_brownian.html">brownian (o)</A></TD><TD ><A HREF = "pair_brownian.html">brownian/poly (o)</A></TD><TD ><A HREF = "pair_buck.html">buck (cgo)</A></TD><TD ><A HREF = "pair_buck.html">buck/coul/cut (cgo)</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_brownian.html">brownian (o)</A></TD><TD ><A HREF = "pair_brownian.html">brownian/poly (o)</A></TD><TD ><A HREF = "pair_buck.html">buck (cgko)</A></TD><TD ><A HREF = "pair_buck.html">buck/coul/cut (cgo)</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_buck.html">buck/coul/long (cgo)</A></TD><TD ><A HREF = "pair_buck.html">buck/coul/msm (o)</A></TD><TD ><A HREF = "pair_buck_long.html">buck/long/coul/long (o)</A></TD><TD ><A HREF = "pair_colloid.html">colloid (go)</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_comb.html">comb (o)</A></TD><TD ><A HREF = "pair_comb.html">comb3</A></TD><TD ><A HREF = "pair_coul.html">coul/cut (gko)</A></TD><TD ><A HREF = "pair_coul.html">coul/debye (go)</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_coul.html">coul/dsf (go)</A></TD><TD ><A HREF = "pair_coul.html">coul/long (go)</A></TD><TD ><A HREF = "pair_coul.html">coul/msm</A></TD><TD ><A HREF = "pair_coul.html">coul/wolf (o)</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_dpd.html">dpd (o)</A></TD><TD ><A HREF = "pair_dpd.html">dpd/tstat (o)</A></TD><TD ><A HREF = "pair_dsmc.html">dsmc</A></TD><TD ><A HREF = "pair_eam.html">eam (cgot)</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_coul.html">coul/dsf (gko)</A></TD><TD ><A HREF = "pair_coul.html">coul/long (go)</A></TD><TD ><A HREF = "pair_coul.html">coul/msm</A></TD><TD ><A HREF = "pair_coul.html">coul/wolf (ko)</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_dpd.html">dpd (o)</A></TD><TD ><A HREF = "pair_dpd.html">dpd/tstat (o)</A></TD><TD ><A HREF = "pair_dsmc.html">dsmc</A></TD><TD ><A HREF = "pair_eam.html">eam (cgkot)</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_eam.html">eam/alloy (cgot)</A></TD><TD ><A HREF = "pair_eam.html">eam/fs (cgot)</A></TD><TD ><A HREF = "pair_eim.html">eim (o)</A></TD><TD ><A HREF = "pair_gauss.html">gauss (go)</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_gayberne.html">gayberne (gio)</A></TD><TD ><A HREF = "pair_gran.html">gran/hertz/history (o)</A></TD><TD ><A HREF = "pair_gran.html">gran/hooke (co)</A></TD><TD ><A HREF = "pair_gran.html">gran/hooke/history (o)</A></TD></TR>
<TR ALIGN="center"><TD ><A HREF = "pair_hbond_dreiding.html">hbond/dreiding/lj (o)</A></TD><TD ><A HREF = "pair_hbond_dreiding.html">hbond/dreiding/morse (o)</A></TD><TD ><A HREF = "pair_kim.html">kim</A></TD><TD ><A HREF = "pair_lcbop.html">lcbop</A></TD></TR>

View File

@ -558,6 +558,7 @@ g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
"temp/berendsen (c)"_fix_temp_berendsen.html,
"temp/csvr"_fix_temp_csvr.html,
"temp/rescale (c)"_fix_temp_rescale.html,
"tfmc"_fix_tfmc.html,
"thermal/conductivity"_fix_thermal_conductivity.html,
"tmd"_fix_tmd.html,
"ttm"_fix_ttm.html,
@ -610,7 +611,8 @@ package"_Section_start.html#start_3.
"smd"_fix_smd.html,
"temp/rescale/eff"_fix_temp_rescale_eff.html,
"ti/rs"_fix_ti_rs.html,
"ti/spring"_fix_ti_spring.html :tb(c=6,ea=c)
"ti/spring"_fix_ti_spring.html,
"ttm/mod"_fix_ttm.html :tb(c=6,ea=c)
:line
@ -730,7 +732,7 @@ KOKKOS, o = USER-OMP, t = OPT.
"born/coul/wolf (go)"_pair_born.html,
"brownian (o)"_pair_brownian.html,
"brownian/poly (o)"_pair_brownian.html,
"buck (cgo)"_pair_buck.html,
"buck (cgko)"_pair_buck.html,
"buck/coul/cut (cgo)"_pair_buck.html,
"buck/coul/long (cgo)"_pair_buck.html,
"buck/coul/msm (o)"_pair_buck.html,
@ -740,14 +742,14 @@ KOKKOS, o = USER-OMP, t = OPT.
"comb3"_pair_comb.html,
"coul/cut (gko)"_pair_coul.html,
"coul/debye (go)"_pair_coul.html,
"coul/dsf (go)"_pair_coul.html,
"coul/dsf (gko)"_pair_coul.html,
"coul/long (go)"_pair_coul.html,
"coul/msm"_pair_coul.html,
"coul/wolf (o)"_pair_coul.html,
"coul/wolf (ko)"_pair_coul.html,
"dpd (o)"_pair_dpd.html,
"dpd/tstat (o)"_pair_dpd.html,
"dsmc"_pair_dsmc.html,
"eam (cgot)"_pair_eam.html,
"eam (cgkot)"_pair_eam.html,
"eam/alloy (cgot)"_pair_eam.html,
"eam/fs (cgot)"_pair_eam.html,
"eim (o)"_pair_eim.html,

View File

@ -189,7 +189,6 @@ commands)
<LI> rigid body constraints
<LI> SHAKE bond and angle constraints
<LI> Monte Carlo bond breaking, formation, swapping
<LI> Monte Carlo atom swapping
<LI> atom/molecule insertion and deletion
<LI> walls of various kinds
<LI> non-equilibrium molecular dynamics (NEMD)
@ -258,8 +257,8 @@ molecular dynamics options:
<LI><A HREF = "fix_atc.html">atom-to-continuum coupling</A> with finite elements
<LI>coupled rigid body integration via the <A HREF = "fix_poems.html">POEMS</A> library
<LI><A HREF = "fix_qmmm.html">QM/MM coupling</A>
<LI><A HREF = "fix_ipi.html">path-integral molecular dynamics (PIMD)</A>
<LI><A HREF = "fix_gcmc.html">grand canonical Monte Carlo</A> insertions/deletions
<LI><A HREF = "fix_ipi.html">path-integral molecular dynamics (PIMD)</A> and <A HREF = "fix_pimd.html">this as well</A>
<LI>Monte Carlo via <A HREF = "fix_gcmc.html">GCMC</A> and <A HREF = "fix_tfmc.html">tfMC</A> and <A HREF = "fix_swap.html">atom swapping</A>
<LI><A HREF = "pair_dsmc.html">Direct Simulation Monte Carlo</A> for low-density fluids
<LI><A HREF = "pair_peri.html">Peridynamics mesoscale modeling</A>
<LI><A HREF = "fix_lb_fluid.html">Lattice Boltzmann fluid</A>

View File

@ -190,7 +190,6 @@ Ensembles, constraints, and boundary conditions :h4
rigid body constraints
SHAKE bond and angle constraints
Monte Carlo bond breaking, formation, swapping
Monte Carlo atom swapping
atom/molecule insertion and deletion
walls of various kinds
non-equilibrium molecular dynamics (NEMD)
@ -256,8 +255,8 @@ molecular dynamics options:
"atom-to-continuum coupling"_fix_atc.html with finite elements
coupled rigid body integration via the "POEMS"_fix_poems.html library
"QM/MM coupling"_fix_qmmm.html
"path-integral molecular dynamics (PIMD)"_fix_ipi.html
"grand canonical Monte Carlo"_fix_gcmc.html insertions/deletions
"path-integral molecular dynamics (PIMD)"_fix_ipi.html and "this as well"_fix_pimd.html
Monte Carlo via "GCMC"_fix_gcmc.html and "tfMC"_fix_tfmc.html and "atom swapping"_fix_swap.html
"Direct Simulation Monte Carlo"_pair_dsmc.html for low-density fluids
"Peridynamics mesoscale modeling"_pair_peri.html
"Lattice Boltzmann fluid"_fix_lb_fluid.html

View File

@ -508,4 +508,7 @@ available backend programming models. Specifically, Kokkos requires
extensive C++ support from the Kernel language. This is expected to
change in the future.
</P>
<P>Kokkos must be built with a C++11 compatible compiler. For example,
gcc 4.7.2 or later.
</P>
</HTML>

View File

@ -504,3 +504,6 @@ Currently Kokkos does not support AMD GPUs due to limits in the
available backend programming models. Specifically, Kokkos requires
extensive C++ support from the Kernel language. This is expected to
change in the future.
Kokkos must be built with a C++11 compatible compiler. For example,
gcc 4.7.2 or later.

View File

@ -59,13 +59,17 @@ second term uses components of the virial tensor:
<CENTER><IMG SRC = "Eqs/pressure_tensor.jpg">
</CENTER>
<P>If no extra keywords are listed, the entire equations above are
calculated which include a kinetic energy (temperature) term and the
calculated. This includes a kinetic energy (temperature) term and the
virial as the sum of pair, bond, angle, dihedral, improper, kspace
(long-range), and fix contributions to the force on each atom. If any
extra keywords are listed, then only those components are summed to
compute temperature or ke and/or the virial. The <I>virial</I> keyword
means include all terms except the kinetic energy <I>ke</I>.
</P>
<P>Details of how LAMMPS computes the virial efficiently for the entire
system, including the effects of periodic boundary conditions is
discussed in <A HREF = "#Thompson">(Thompson)</A>.
</P>
<P>The temperature and kinetic energy tensor is not calculated by this
compute, but rather by the temperature compute specified with the
command. If the kinetic energy is not included in the pressure, than
@ -140,4 +144,10 @@ stress/atom</A>,
</P>
<P><B>Default:</B> none
</P>
<HR>
<A NAME = "Thompson"></A>
<P><B>(Thompson)</B> Thompson, Plimpton, Mattson, J Chem Phys, 131, 154107 (2009).
</P>
</HTML>

View File

@ -55,13 +55,17 @@ second term uses components of the virial tensor:
:c,image(Eqs/pressure_tensor.jpg)
If no extra keywords are listed, the entire equations above are
calculated which include a kinetic energy (temperature) term and the
calculated. This includes a kinetic energy (temperature) term and the
virial as the sum of pair, bond, angle, dihedral, improper, kspace
(long-range), and fix contributions to the force on each atom. If any
extra keywords are listed, then only those components are summed to
compute temperature or ke and/or the virial. The {virial} keyword
means include all terms except the kinetic energy {ke}.
Details of how LAMMPS computes the virial efficiently for the entire
system, including the effects of periodic boundary conditions is
discussed in "(Thompson)"_#Thompson.
The temperature and kinetic energy tensor is not calculated by this
compute, but rather by the temperature compute specified with the
command. If the kinetic energy is not included in the pressure, than
@ -135,3 +139,8 @@ stress/atom"_compute_stress_atom.html,
"thermo_style"_thermo_style.html,
[Default:] none
:line
:link(Thompson)
[(Thompson)] Thompson, Plimpton, Mattson, J Chem Phys, 131, 154107 (2009).

View File

@ -75,6 +75,18 @@ listed, only those terms are summed to compute the tensor. The
<P>Note that the stress for each atom is due to its interaction with all
other atoms in the simulation, not just with other atoms in the group.
</P>
<P>Details of how LAMMPS computes the virial for individual atoms for
either pairwise or manybody potentials, and including the effects of
periodic boundary conditions is discussed in <A HREF = "#Thompson">(Thompson)</A>.
The basic idea for manybody potentials is to treat each component of
the force computation between a small cluster of atoms in the same
manner as in the formula above for bond, angle, dihedral, etc
interactions. Namely the quantity R dot F is summed over the atoms in
the interaction, with the R vectors unwrapped by periodic boundaries
so that the cluster of atoms is close together. The total
contribution for the cluster interaction is divided evenly among those
atoms.
</P>
<P>The <A HREF = "dihedral_charmm.html">dihedral_style charmm</A> style calculates
pairwise interactions between 1-4 atoms. The virial contribution of
these terms is included in the pair virial, not the dihedral virial.
@ -153,4 +165,8 @@ options.
<P><B>(Sirk)</B> Sirk, Moore, Brown, J Chem Phys, 138, 064505 (2013).
</P>
<A NAME = "Thompson"></A>
<P><B>(Thompson)</B> Thompson, Plimpton, Mattson, J Chem Phys, 131, 154107 (2009).
</P>
</HTML>

View File

@ -72,6 +72,18 @@ listed, only those terms are summed to compute the tensor. The
Note that the stress for each atom is due to its interaction with all
other atoms in the simulation, not just with other atoms in the group.
Details of how LAMMPS computes the virial for individual atoms for
either pairwise or manybody potentials, and including the effects of
periodic boundary conditions is discussed in "(Thompson)"_#Thompson.
The basic idea for manybody potentials is to treat each component of
the force computation between a small cluster of atoms in the same
manner as in the formula above for bond, angle, dihedral, etc
interactions. Namely the quantity R dot F is summed over the atoms in
the interaction, with the R vectors unwrapped by periodic boundaries
so that the cluster of atoms is close together. The total
contribution for the cluster interaction is divided evenly among those
atoms.
The "dihedral_style charmm"_dihedral_charmm.html style calculates
pairwise interactions between 1-4 atoms. The virial contribution of
these terms is included in the pair virial, not the dihedral virial.
@ -147,3 +159,6 @@ The per-atom array values will be in pressure*volume
:link(Sirk)
[(Sirk)] Sirk, Moore, Brown, J Chem Phys, 138, 064505 (2013).
:link(Thompson)
[(Thompson)] Thompson, Plimpton, Mattson, J Chem Phys, 131, 154107 (2009).

View File

@ -11,6 +11,8 @@
<H3>fix langevin command
</H3>
<H3>fix langevin/kk command
</H3>
<P><B>Syntax:</B>
</P>
<PRE>fix ID group-ID langevin Tstart Tstop damp seed keyword values ...
@ -268,6 +270,29 @@ generates an average temperature of 220 K, instead of 300 K.
</P>
<HR>
<P>Styles with a <I>cuda</I>, <I>gpu</I>, <I>intel</I>, <I>kk</I>, <I>omp</I>, or <I>opt</I> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <A HREF = "Section_accelerate.html">Section_accelerate</A>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
</P>
<P>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
KOKKOS, USER-OMP and OPT packages, respectively. They are only
enabled if LAMMPS was built with those packages. See the <A HREF = "Section_start.html#start_3">Making
LAMMPS</A> section for more info.
</P>
<P>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <A HREF = "Section_start.html#start_7">-suffix command-line
switch</A> when you invoke LAMMPS, or you can
use the <A HREF = "suffix.html">suffix</A> command in your input script.
</P>
<P>See <A HREF = "Section_accelerate.html">Section_accelerate</A> of the manual for
more instructions on how to use the accelerated styles effectively.
</P>
<HR>
<P><B>Restart, fix_modify, output, run start/stop, minimize info:</B>
</P>
<P>No information about this fix is written to <A HREF = "restart.html">binary restart

View File

@ -7,6 +7,7 @@
:line
fix langevin command :h3
fix langevin/kk command :h3
[Syntax:]
@ -256,6 +257,29 @@ generates an average temperature of 220 K, instead of 300 K.
:line
Styles with a {cuda}, {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section_accelerate"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
KOKKOS, USER-OMP and OPT packages, respectively. They are only
enabled if LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section_accelerate"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart

168
doc/fix_tfmc.html Normal file
View File

@ -0,0 +1,168 @@
<HTML>
<CENTER><A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A>
</CENTER>
<HR>
<H3>fix tfmc command
</H3>
<P><B>Syntax:</B>
</P>
<PRE>fix ID group-ID tfmc Delta Temp seed keyword value
</PRE>
<UL><LI>ID, group-ID are documented in <A HREF = "fix.html">fix</A> command
<LI>tfmc = style name of this fix command
<LI>Delta = maximal displacement length (distance units)
<LI>Temp = imposed temperature of the system
<LI>seed = random number seed (positive integer)
<LI>zero or more keyword/arg pairs may be appended
<LI>keyword = <I>com</I> or <I>rot</I>
<PRE> <I>com</I> args = xflag yflag zflag
xflag,yflag,zflag = 0/1 to exclude/include each dimension
<I>rot</I> args = none
</PRE>
</UL>
<P><B>Examples:</B>
</P>
<PRE>fix 1 all tfmc 0.1 1000.0 159345
fix 1 all tfmc 0.05 600.0 658943 com 1 1 0
fix 1 all tfmc 0.1 750.0 387068 com 1 1 1 rot
</PRE>
<P><B>Description:</B>
</P>
<P>Perform uniform-acceptance force-bias Monte Carlo (fbMC) simulations,
using the time-stamped force-bias Monte Carlo (tfMC) algorithm
described in <A HREF = "#Mees">(Mees)</A> and <A HREF = "#Bal">(Bal)</A>.
</P>
<P>One successful use case of force-bias Monte Carlo methods is that they
can be used to extend the time scale of atomistic simulations, in
particular when long time scale relaxation effects must be considered;
some interesting examples are given in the review by <A HREF = "#Neyts">(Neyts)</A>.
An example of a typical use case would be the modelling of chemical
vapour deposition (CVD) processes on a surface, in which impacts by
gas-phase species can be performed using MD, but subsequent relaxation
of the surface is too slow to be done using MD only. Using tfMC can
allow for a much faster relaxation of the surface, so that higher
fluxes can be used, effectively extending the time scale of the
simulation. (Such an alternating simulation approach could be set up
using a <A HREF = "jump.html">loop</A>.)
</P>
<P>The initial version of tfMC algorithm in <A HREF = "#Mees">(Mees)</A> contained an
estimation of the effective time scale of such a simulation, but it
was later shown that the speed-up one can gain from a tfMC simulation
is system- and process-dependent, ranging from none to several orders
of magnitude. In general, solid-state processes such as
(re)crystallisation or growth can be accelerated by up to two or three
orders of magnitude, whereas diffusion in the liquid phase is not
accelerated at all. The observed pseudodynamics when using the tfMC
method is not the actual dynamics one would obtain using MD, but the
relative importance of processes can match the actual relative
dynamics of the system quite well, provided <I>Delta</I> is chosen with
care. Thus, the system's equilibrium is reached faster than in MD,
along a path that is generally roughly similar to a typical MD
simulation (but not necessarily so). See <A HREF = "#Bal">(Bal)</A> for details.
</P>
<P>Each step, all atoms in the selected group are displaced using the
stochastic tfMC algorithm, which is designed to sample the canonical
(NVT) ensemble at the temperature <I>Temp</I>. Although tfMC is a Monte
Carlo algorithm and thus strictly speaking does not perform time
integration, it is similar in the sense that it uses the forces on all
atoms in order to update their positions. Therefore, it is implemented
as a time integration fix, and no other fixes of this type (such as
<A HREF = "fix_nve.html">fix nve</A>) should be used at the same time. Because
velocities do not play a role in this kind of Monte Carlo simulations,
instantaneous temperatures as calculated by <A HREF = "compute_temp.html">temperature
computes</A> or <A HREF = "thermo_style.html">thermodynamic
output</A> have no meaning: the only relevant
temperature is the sampling temperature <I>Temp</I>. Similarly, performing
tfMC simulations does not require setting a <A HREF = "timestep.html">timestep</A>
and the <A HREF = "thermo_style.html">simulated time</A> as calculated by LAMMPS is
meaningless.
</P>
<P>The critical parameter determining the success of a tfMC simulation is
<I>Delta</I>, the maximal displacement length of the lightest element in
the system: the larger it is, the longer the effective time scale of
the simulation will be (there is an approximately quadratic
dependence). However, <I>Delta</I> must also be chosen sufficiently small
in order to comply with detailed balance; in general values between 5
and 10 % of the nearest neighbor distance are found to be a good
choice. For a more extensive discussion with specific examples, please
refer to <A HREF = "#Bal">(Bal)</A>, which also describes how the code calculates
element-specific maximal displacements from <I>Delta</I>, based on the
fourth root of their mass.
</P>
<P>Because of the uncorrelated movements of the atoms, the center-of-mass
of the fix group will not necessarily be stationary, just like its
orientation. When the <I>com</I> keyword is used, all atom positions will
be shifted (after every tfMC iteration) in order to fix the position
of the center-of-mass along the included directions, by setting the
corresponding flag to 1. The <I>rot</I> keyword does the same for the
rotational component of the tfMC displacements after every iteration.
</P>
<P>IMPORTANT NOTE: the <I>com</I> and <I>rot</I> keywords should not be used if an
external force is acting on the specified fix group, along the
included directions. This can be either a true external force (e.g.
through <A HREF = "fix_wall.html">fix wall</A>) or forces due to the interaction
with atoms not included in the fix group. This is because in such
cases, translations or rotations of the fix group could be induced by
these external forces, and removing them will lead to a violation of
detailed balance.
</P>
<HR>
<P><B>Restart, fix_modify, output, run start/stop, minimize info:</B>
</P>
<P>No information about this fix is written to <A HREF = "restart.html">binary restart
files</A>.
</P>
<P>None of the <A HREF = "fix_modify.html">fix_modify</A> options are relevant to this
fix.
</P>
<P>This fix is not invoked during <A HREF = "minimize.html">energy minimization</A>.
</P>
<P><B>Restrictions:</B>
</P>
<P>This fix is part of the MC package. It is only enabled if LAMMPS was
built with that package. See the <A HREF = "Section_start.html#start_3">Making
LAMMPS</A> section for more info.
</P>
<P>This fix is not compatible with <A HREF = "fix_shake.html">fix shake</A>.
</P>
<P><B>Related commands:</B>
</P>
<P><A HREF = "fix_gcmc.html">fix gcmc</A>, <A HREF = "fix_nh.html">fix nvt</A>
</P>
<P><B>Default:</B>
</P>
<P>The option default is com = 0 0 0
</P>
<HR>
<A NAME = "Bal"></A>
<P><B>(Bal)</B> K. M Bal and E. C. Neyts, J. Chem. Phys. 141, 204104 (2014).
</P>
<A NAME = "Mees"></A>
<P><B>(Mees)</B> M. J. Mees, G. Pourtois, E. C. Neyts, B. J. Thijsse, and
A. Stesmans, Phys. Rev. B 85, 134301 (2012).
</P>
<A NAME = "Neyts"></A>
<P><B>(Neyts)</B> E. C. Neyts and A. Bogaerts, Theor. Chem. Acc. 132, 1320
(2013).
</P>
</HTML>

152
doc/fix_tfmc.txt Normal file
View File

@ -0,0 +1,152 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix tfmc command :h3
[Syntax:]
fix ID group-ID tfmc Delta Temp seed keyword value :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
tfmc = style name of this fix command :l
Delta = maximal displacement length (distance units) :l
Temp = imposed temperature of the system :l
seed = random number seed (positive integer) :l
zero or more keyword/arg pairs may be appended :l
keyword = {com} or {rot} :l
{com} args = xflag yflag zflag
xflag,yflag,zflag = 0/1 to exclude/include each dimension
{rot} args = none :pre
:ule
[Examples:]
fix 1 all tfmc 0.1 1000.0 159345
fix 1 all tfmc 0.05 600.0 658943 com 1 1 0
fix 1 all tfmc 0.1 750.0 387068 com 1 1 1 rot :pre
[Description:]
Perform uniform-acceptance force-bias Monte Carlo (fbMC) simulations,
using the time-stamped force-bias Monte Carlo (tfMC) algorithm
described in "(Mees)"_#Mees and "(Bal)"_#Bal.
One successful use case of force-bias Monte Carlo methods is that they
can be used to extend the time scale of atomistic simulations, in
particular when long time scale relaxation effects must be considered;
some interesting examples are given in the review by "(Neyts)"_#Neyts.
An example of a typical use case would be the modelling of chemical
vapour deposition (CVD) processes on a surface, in which impacts by
gas-phase species can be performed using MD, but subsequent relaxation
of the surface is too slow to be done using MD only. Using tfMC can
allow for a much faster relaxation of the surface, so that higher
fluxes can be used, effectively extending the time scale of the
simulation. (Such an alternating simulation approach could be set up
using a "loop"_jump.html.)
The initial version of tfMC algorithm in "(Mees)"_#Mees contained an
estimation of the effective time scale of such a simulation, but it
was later shown that the speed-up one can gain from a tfMC simulation
is system- and process-dependent, ranging from none to several orders
of magnitude. In general, solid-state processes such as
(re)crystallisation or growth can be accelerated by up to two or three
orders of magnitude, whereas diffusion in the liquid phase is not
accelerated at all. The observed pseudodynamics when using the tfMC
method is not the actual dynamics one would obtain using MD, but the
relative importance of processes can match the actual relative
dynamics of the system quite well, provided {Delta} is chosen with
care. Thus, the system's equilibrium is reached faster than in MD,
along a path that is generally roughly similar to a typical MD
simulation (but not necessarily so). See "(Bal)"_#Bal for details.
Each step, all atoms in the selected group are displaced using the
stochastic tfMC algorithm, which is designed to sample the canonical
(NVT) ensemble at the temperature {Temp}. Although tfMC is a Monte
Carlo algorithm and thus strictly speaking does not perform time
integration, it is similar in the sense that it uses the forces on all
atoms in order to update their positions. Therefore, it is implemented
as a time integration fix, and no other fixes of this type (such as
"fix nve"_fix_nve.html) should be used at the same time. Because
velocities do not play a role in this kind of Monte Carlo simulations,
instantaneous temperatures as calculated by "temperature
computes"_compute_temp.html or "thermodynamic
output"_thermo_style.html have no meaning: the only relevant
temperature is the sampling temperature {Temp}. Similarly, performing
tfMC simulations does not require setting a "timestep"_timestep.html
and the "simulated time"_thermo_style.html as calculated by LAMMPS is
meaningless.
The critical parameter determining the success of a tfMC simulation is
{Delta}, the maximal displacement length of the lightest element in
the system: the larger it is, the longer the effective time scale of
the simulation will be (there is an approximately quadratic
dependence). However, {Delta} must also be chosen sufficiently small
in order to comply with detailed balance; in general values between 5
and 10 % of the nearest neighbor distance are found to be a good
choice. For a more extensive discussion with specific examples, please
refer to "(Bal)"_#Bal, which also describes how the code calculates
element-specific maximal displacements from {Delta}, based on the
fourth root of their mass.
Because of the uncorrelated movements of the atoms, the center-of-mass
of the fix group will not necessarily be stationary, just like its
orientation. When the {com} keyword is used, all atom positions will
be shifted (after every tfMC iteration) in order to fix the position
of the center-of-mass along the included directions, by setting the
corresponding flag to 1. The {rot} keyword does the same for the
rotational component of the tfMC displacements after every iteration.
IMPORTANT NOTE: the {com} and {rot} keywords should not be used if an
external force is acting on the specified fix group, along the
included directions. This can be either a true external force (e.g.
through "fix wall"_fix_wall.html) or forces due to the interaction
with atoms not included in the fix group. This is because in such
cases, translations or rotations of the fix group could be induced by
these external forces, and removing them will lead to a violation of
detailed balance.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html.
None of the "fix_modify"_fix_modify.html options are relevant to this
fix.
This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix is part of the MC package. It is only enabled if LAMMPS was
built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
This fix is not compatible with "fix shake"_fix_shake.html.
[Related commands:]
"fix gcmc"_fix_gcmc.html, "fix nvt"_fix_nh.html
[Default:]
The option default is com = 0 0 0
:line
:link(Bal)
[(Bal)] K. M Bal and E. C. Neyts, J. Chem. Phys. 141, 204104 (2014).
:link(Mees)
[(Mees)] M. J. Mees, G. Pourtois, E. C. Neyts, B. J. Thijsse, and
A. Stesmans, Phys. Rev. B 85, 134301 (2012).
:link(Neyts)
[(Neyts)] E. C. Neyts and A. Bogaerts, Theor. Chem. Acc. 132, 1320
(2013).

View File

@ -11,30 +11,51 @@
<H3>fix ttm command
</H3>
<H3>fix ttm/mod command
</H3>
<P><B>Syntax:</B>
</P>
<PRE>fix ID group-ID ttm seed C_e rho_e kappa_e gamma_p gamma_s v_0 Nx Ny Nz T_infile N T_outfile
<PRE>fix ID group-ID ttm seed C_e rho_e kappa_e gamma_p gamma_s v_0 Nx Ny Nz T_infile N T_outfile
fix ID group-ID ttm/mod seed init_file Nx Ny Nz T_infile N T_outfile
</PRE>
<UL><LI>ID, group-ID are documented in <A HREF = "fix.html">fix</A> command
<LI>ttm = style name of this fix command
<LI>seed = random number seed to use for white noise (positive integer)
<LI>C_e = electronic specific heat (energy/(electron*temperature) units)
<LI>rho_e = electronic density (electrons/volume units)
<LI>kappa_e = electronic thermal conductivity (energy/(time*distance*temperature) units)
<LI>gamma_p = friction coefficient due to electron-ion interactions (mass/time units)
<LI>gamma_s = friction coefficient due to electronic stopping (mass/time units)
<LI>v_0 = electronic stopping critical velocity (velocity units)
<LI>Nx = number of thermal solve grid points in the x-direction (positive integer)
<LI>Ny = number of thermal solve grid points in the y-direction (positive integer)
<LI>Nz = number of thermal solve grid points in the z-direction (positive integer)
<LI>T_infile = filename to read initial electronic temperature from
<LI>N = dump TTM temperatures every this many timesteps, 0 = no dump
<LI>T_outfile = filename to write TTM temperatures to (only needed if N > 0)
<UL><LI>ID, group-ID are documented in <A HREF = "fix.html">fix</A> command
<LI>style = <I>ttm</I> or <I>ttm_mod</I>
<LI>seed = random number seed to use for white noise (positive integer)
<LI>remaining arguments for fix ttm:
<PRE> C_e = electronic specific heat (energy/(electron*temperature) units)
rho_e = electronic density (electrons/volume units)
kappa_e = electronic thermal conductivity (energy/(time*distance*temperature) units)
gamma_p = friction coefficient due to electron-ion interactions (mass/time units)
gamma_s = friction coefficient due to electronic stopping (mass/time units)
v_0 = electronic stopping critical velocity (velocity units)
Nx = number of thermal solve grid points in the x-direction (positive integer)
Ny = number of thermal solve grid points in the y-direction (positive integer)
Nz = number of thermal solve grid points in the z-direction (positive integer)
T_infile = filename to read initial electronic temperature from
N = dump TTM temperatures every this many timesteps, 0 = no dump
T_outfile = filename to write TTM temperatures to (only needed if N > 0)
</PRE>
<LI>remaining arguments for fix ttm/mod:
<PRE> init_file = file with the parameters to TTM
Nx = number of thermal solve grid points in the x-direction (positive integer)
Ny = number of thermal solve grid points in the y-direction (positive integer)
Nz = number of thermal solve grid points in the z-direction (positive integer)
T_infile = filename to read initial electronic temperature from
N = dump TTM temperatures every this many timesteps, 0 = no dump
T_outfile = filename to write TTM temperatures to (only needed if N > 0)
</PRE>
</UL>
<P><B>Examples:</B>
</P>
<PRE>fix 2 all ttm 699489 1.0 1.0 10 0.1 0.0 2.0 1 12 1 initialTs 1000 T.out
fix 2 all ttm 123456 1.0 1.0 1.0 1.0 1.0 5.0 5 5 5 Te.in 1 Te.out
fix 2 all ttm 123456 1.0 1.0 1.0 1.0 1.0 5.0 5 5 5 Te.in 1 Te.out
fix 2 all ttm/mod 34277 parameters.txt 5 5 5 T_init 10 T_out
</PRE>
<P><B>Description:</B>
</P>
@ -52,6 +73,14 @@ and <A HREF = "#Rutherford">(Rutherford)</A>. They used this algorithm in casca
simulations where a primary knock-on atom (PKA) was initialized with a
high velocity to simulate a radiation event.
</P>
<P>The description in this sub-section applies to both fix ttm and fix
ttm/mod. Fix ttm/mod adds options to account for external heat
sources (e.g. at a surface) and for specifying parameters that allow
the electronic heat capacity to depend strongly on electronic
temperature. It is more expensive computationally than fix ttm
because it treats the thermal diffusion equation as non-linear. More
details on fix ttm/mod are given below.
</P>
<P>Heat transfer between the electronic and atomic subsystems is carried
out via an inhomogeneous Langevin thermostat. This thermostat differs
from the regular Langevin thermostat (<A HREF = "fix_langevin.html">fix
@ -91,15 +120,13 @@ as that in equation 6 of <A HREF = "#Duffy">(Duffy)</A>, with the exception that
electronic density is explicitly reprensented, rather than being part
of the the specific heat parameter.
</P>
<P>Currently, this fix assumes that none of the user-supplied parameters
will vary with temperature. This assumption can be relaxed by
modifying the source code to include the desired temperature
dependency and functional form for any of the parameters. Note that
<A HREF = "#Duffy">(Duffy)</A> used a tanh() functional form for the temperature
dependence of the electronic specific heat, but ignored temperature
dependencies of any of the other parameters.
<P>Currently, fix ttm assumes that none of the user-supplied parameters
will vary with temperature. Note that <A HREF = "#Duffy">(Duffy)</A> used a tanh()
functional form for the temperature dependence of the electronic
specific heat, but ignored temperature dependencies of any of the
other parameters. See more discussion below for fix ttm/mod.
</P>
<P>This fix requires use of periodic boundary conditions and a 3D
<P>These fixes requires use of periodic boundary conditions and a 3D
simulation. Periodic boundary conditions are also used in the heat
equation solve for the electronic subsystem. This varies from the
approach of <A HREF = "#Rutherford">(Rutherford)</A> where the atomic subsystem was
@ -138,14 +165,122 @@ the electronic subsystem. The ordering of the Nx*Ny*Nz columns is
with the z index varing fastest, y the next fastest, and x the
slowest.
</P>
<P>This fix does not change the coordinates of its atoms; it only scales
their velocities. Thus a time integration fix (e.g. <A HREF = "fix_nve.html">fix
<P>These fixes do not change the coordinates of its atoms; they only
scales their velocities. Thus a time integration fix (e.g. <A HREF = "fix_nve.html">fix
nve</A>) should still be used to time integrate the affected
atoms. This fix should not normally be used on atoms that have their
atoms. Th fixes should not normally be used on atoms that have their
temperature controlled by another fix - e.g. <A HREF = "fix_nh.html">fix nvt</A> or
<A HREF = "fix_langevin.html">fix langevin</A>.
</P>
<P>This fix computes 2 output quantities stored in a vector of length 2,
<P>IMPORTANT NOTE: The current implementation of these fixes creates a
copy of the electron grid that overlays the entire simulation domain,
for each processor. Values on the grid are summed across all
processors. Thus you should insure that this grid is not too large,
else your simulation could incur high memory and communication costs.
</P>
<HR>
<P><B>Additional details for fix ttm/mod</B>
</P>
<P>Fix ttm/mod uses the heat diffusion equation with possible external
heat sources (e.g. laser heating in ablation simulations):
</P>
<CENTER><IMG SRC = "Eqs/fix_ttm_mod.jpg">
</CENTER>
<P>where I_0 is the (absorbed) laser pulse intensity for ablation
simulations, l_skin is the depth of skin-layer, and all other
designations have the same meaning as in the former equation.
</P>
<P>Fix ttm/mod also allows users to specify the dependencies of C_e and
kappa_e on the electronic temperature. The specific heat is expressed
as
</P>
<CENTER><IMG SRC = "Eqs/fix_ttm_ce.jpg">
</CENTER>
<P>where <I>X</I> = T_e/1000, and the thermal conductivity is defined as
kappa_e = D_e*rho_e*C_e, where D_e is the thermal diffusion
coefficient.
</P>
<P>Electronic pressure effects are included in the TTM model to account
for the blast force acting on ions because of electronic pressure
gradient (see <A HREF = "Chen">(Chen)</A>, <A HREF = "#Norman">(Norman)</A>). The total force
acting on an ion is:
</P>
<CENTER><IMG SRC = "Eqs/fix_ttm_blast.jpg">
</CENTER>
<P>where F_langevin is a force from Langevin thermostat simulating
electron-phonon coupling, and nabla P_e/n_ion is the electron blast
force.
</P>
<P>The electronic pressure is taken to be P_e = B*rho_e*C_e*T_e
</P>
<P>The current fix ttm/mod implementation allows TTM simulations with a
vacuum. The vacuum region is defined as the grid cells with zero
electronic temperature. The numerical scheme does not allow energy
exchange with such cells. Since the material can expand to previously
unoccupied region in some simulations, the vacuum border can be
allowed to move. It is controlled by the <I>surface_movement</I> parameter
in the <I>init_file</I>. If it is set to 1, then "vacuum" cells can be
changed to "electron-filled" cells with the temperature <I>T_e_min</I> if
atoms move into them (currently only implemented for the case of
1-dimensional motion of flat surface normal to the X axis). The
initial borders of vacuum can be set in the <I>init_file</I> via <I>lsurface</I>
and <I>rsurface</I> parameters. In this case, electronic pressure gradient
is calculated as
</P>
<CENTER><IMG SRC = "Eqs/fix_ttm_blast1.jpg">
</CENTER>
<P>where lambda is the electron mean free path (see <A HREF = "#Norman">(Norman)</A>,
<A HREF = "#Pisarev">(Pisarev)</A>)
</P>
<P>The fix ttm/mod parameter file <I>init_file</I> has the following syntax/
Every line with the odd number is considered as a comment and
ignored. The lines with the even numbers are treated as follows:
</P>
<PRE>a_0, energy/(temperature*electron) units
a_1, energy/(temperature^2*electron) units
a_2, energy/(temperature^3*electron) units
a_3, energy/(temperature^4*electron) units
a_4, energy/(temperature^5*electron) units
C_0, energy/(temperature*electron) units
A, 1/temperature units
rho_e, electrons/volume units
D_e, length^2/time units
gamma_p, mass/time units
gamma_s, mass/time units
v_0, length/time units
I_0, energy/(time*length^2) units
lsurface, electron grid units (positive integer)
rsurface, electron grid units (positive integer)
l_skin, length units
tau, time units
B, dimensionless
lambda, length units
n_ion, ions/volume units
surface_movement: 0 to disable tracking of surface motion, 1 to enable
T_e_min, temperature units
</PRE>
<HR>
<P><B>Restart, fix_modify, output, run start/stop, minimize info:</B>
</P>
<P>These fixes writes the state of the electronic subsystem and the
energy exchange between the subsystems to <A HREF = "restart.html">binary restart
files</A>. See the <A HREF = "read_restart.html">read_restart</A> command
for info on how to re-specify a fix in an input script that reads a
restart file, so that the operation of the fix continues in an
uninterrupted fashion.
</P>
<P>Because the state of the random number generator is not saved in the
restart files, this means you cannot do "exact" restarts with this
fix, where the simulation continues on the same as if no restart had
taken place. However, in a statistical sense, a restarted simulation
should produce the same behavior.
</P>
<P>None of the <A HREF = "fix_modify.html">fix_modify</A> options are relevant to these
fixes.
</P>
<P>Both fixes compute 2 output quantities stored in a vector of length 2,
which can be accessed by various <A HREF = "Section_howto.html#howto_15">output
commands</A>. The first quantity is the
total energy of the electronic subsystem. The second quantity is the
@ -159,45 +294,23 @@ energy. As a result of this, users may notice slight fluctuations in
the sum of the atomic and electronic subsystem energies reported at
the end of the timestep.
</P>
<P>The vector values calculated by this fix are "extensive".
<P>The vector values calculated are "extensive".
</P>
<P>IMPORTANT NOTE: The current implementation creates a copy of the
electron grid that overlays the entire simulation domain, for each
processor. Values on the grid are summed across all processors. Thus
you should insure that this grid is not too large, else your
simulation could incur high memory and communication costs.
</P>
<P><B>Restart, fix_modify, output, run start/stop, minimize info:</B>
</P>
<P>This fix writes the state of the electronic subsystem and the energy
exchange between the subsystems to <A HREF = "restart.html">binary restart
files</A>. See the <A HREF = "read_restart.html">read_restart</A> command
for info on how to re-specify a fix in an input script that reads a
restart file, so that the operation of the fix continues in an
uninterrupted fashion.
</P>
<P>Because the state of the random number generator is not saved in the
restart files, this means you cannot do "exact" restarts with this
fix, where the simulation continues on the same as if no restart had
taken place. However, in a statistical sense, a restarted simulation
should produce the same behavior.
</P>
<P>None of the <A HREF = "fix_modify.html">fix_modify</A> options are relevant to this
fix. No global or per-atom quantities are stored by this fix for
access by various <A HREF = "Section_howto.html#howto_15">output commands</A>. No
parameter of this fix can be used with the <I>start/stop</I> keywords of
the <A HREF = "run.html">run</A> command. This fix is not invoked during <A HREF = "minimize.html">energy
minimization</A>.
<P>No parameter of the fixes can be used with the <I>start/stop</I> keywords
of the <A HREF = "run.html">run</A> command. The fixes are not invoked during
<A HREF = "minimize.html">energy minimization</A>.
</P>
<P><B>Restrictions:</B>
</P>
<P>This fix is part of the MISC package. It is only enabled if LAMMPS
was built with that package. See the <A HREF = "Section_start.html#start_3">Making
LAMMPS</A> section for more info.
<P>Fix <I>ttm</I> is part of the MISC package. It is only enabled if LAMMPS
was built with that package. Fix <I>ttm/mod</I> is part of the USER-MISC
package. It is only enabled if LAMMPS was built with that package.
See the <A HREF = "Section_start.html#start_3">Making LAMMPS</A> section for more
info.
</P>
<P>This fix can only be used for 3d simulations and orthogonal
simlulation boxes. You must use periodic <A HREF = "boundary.html">boundary</A>
conditions with this fix.
<P>These fixes can only be used for 3d simulations and orthogonal
simlulation boxes. You must also use periodic
<A HREF = "boundary.html">boundary</A> conditions.
</P>
<P><B>Related commands:</B>
</P>
@ -217,4 +330,19 @@ conditions with this fix.
<P><B>(Rutherford)</B> A M Rutherford and D M Duffy, J. Phys.:
Condens. Matter, 19, 496201-496210 (2007).
</P>
<A NAME = "Chen"></A>
<P><B>(Chen)</B> J Chen, D Tzou and J Beraun, Int. J. Heat
Mass Transfer, 49, 307-316 (2006).
</P>
<A NAME = "Norman"></A>
<P><B>(Norman)</B> G E Norman, S V Starikov, V V Stegailov et al., Contrib.
Plasma Phys., 53, 129-139 (2013).
</P>
<A NAME = "Pisarev"></A>
<P><B>(Pisarev)</B> V V Pisarev and S V Starikov, J. Phys.: Condens. Matter, 26,
475401 (2014).
</P>
</HTML>

View File

@ -7,31 +7,44 @@
:line
fix ttm command :h3
fix ttm/mod command :h3
[Syntax:]
fix ID group-ID ttm seed C_e rho_e kappa_e gamma_p gamma_s v_0 Nx Ny Nz T_infile N T_outfile :pre
fix ID group-ID ttm seed C_e rho_e kappa_e gamma_p gamma_s v_0 Nx Ny Nz T_infile N T_outfile
fix ID group-ID ttm/mod seed init_file Nx Ny Nz T_infile N T_outfile :pre
ID, group-ID are documented in "fix"_fix.html command
ttm = style name of this fix command
seed = random number seed to use for white noise (positive integer)
C_e = electronic specific heat (energy/(electron*temperature) units)
rho_e = electronic density (electrons/volume units)
kappa_e = electronic thermal conductivity (energy/(time*distance*temperature) units)
gamma_p = friction coefficient due to electron-ion interactions (mass/time units)
gamma_s = friction coefficient due to electronic stopping (mass/time units)
v_0 = electronic stopping critical velocity (velocity units)
Nx = number of thermal solve grid points in the x-direction (positive integer)
Ny = number of thermal solve grid points in the y-direction (positive integer)
Nz = number of thermal solve grid points in the z-direction (positive integer)
T_infile = filename to read initial electronic temperature from
N = dump TTM temperatures every this many timesteps, 0 = no dump
T_outfile = filename to write TTM temperatures to (only needed if N > 0) :ul
ID, group-ID are documented in "fix"_fix.html command :ulb,l
style = {ttm} or {ttm_mod} :l
seed = random number seed to use for white noise (positive integer) :l
remaining arguments for fix ttm: :l
C_e = electronic specific heat (energy/(electron*temperature) units)
rho_e = electronic density (electrons/volume units)
kappa_e = electronic thermal conductivity (energy/(time*distance*temperature) units)
gamma_p = friction coefficient due to electron-ion interactions (mass/time units)
gamma_s = friction coefficient due to electronic stopping (mass/time units)
v_0 = electronic stopping critical velocity (velocity units)
Nx = number of thermal solve grid points in the x-direction (positive integer)
Ny = number of thermal solve grid points in the y-direction (positive integer)
Nz = number of thermal solve grid points in the z-direction (positive integer)
T_infile = filename to read initial electronic temperature from
N = dump TTM temperatures every this many timesteps, 0 = no dump
T_outfile = filename to write TTM temperatures to (only needed if N > 0) :pre
remaining arguments for fix ttm/mod: :l
init_file = file with the parameters to TTM
Nx = number of thermal solve grid points in the x-direction (positive integer)
Ny = number of thermal solve grid points in the y-direction (positive integer)
Nz = number of thermal solve grid points in the z-direction (positive integer)
T_infile = filename to read initial electronic temperature from
N = dump TTM temperatures every this many timesteps, 0 = no dump
T_outfile = filename to write TTM temperatures to (only needed if N > 0) :pre
:ule
[Examples:]
fix 2 all ttm 699489 1.0 1.0 10 0.1 0.0 2.0 1 12 1 initialTs 1000 T.out
fix 2 all ttm 123456 1.0 1.0 1.0 1.0 1.0 5.0 5 5 5 Te.in 1 Te.out :pre
fix 2 all ttm 123456 1.0 1.0 1.0 1.0 1.0 5.0 5 5 5 Te.in 1 Te.out
fix 2 all ttm/mod 34277 parameters.txt 5 5 5 T_init 10 T_out :pre
[Description:]
@ -49,6 +62,14 @@ and "(Rutherford)"_#Rutherford. They used this algorithm in cascade
simulations where a primary knock-on atom (PKA) was initialized with a
high velocity to simulate a radiation event.
The description in this sub-section applies to both fix ttm and fix
ttm/mod. Fix ttm/mod adds options to account for external heat
sources (e.g. at a surface) and for specifying parameters that allow
the electronic heat capacity to depend strongly on electronic
temperature. It is more expensive computationally than fix ttm
because it treats the thermal diffusion equation as non-linear. More
details on fix ttm/mod are given below.
Heat transfer between the electronic and atomic subsystems is carried
out via an inhomogeneous Langevin thermostat. This thermostat differs
from the regular Langevin thermostat ("fix
@ -88,15 +109,13 @@ as that in equation 6 of "(Duffy)"_#Duffy, with the exception that the
electronic density is explicitly reprensented, rather than being part
of the the specific heat parameter.
Currently, this fix assumes that none of the user-supplied parameters
will vary with temperature. This assumption can be relaxed by
modifying the source code to include the desired temperature
dependency and functional form for any of the parameters. Note that
"(Duffy)"_#Duffy used a tanh() functional form for the temperature
dependence of the electronic specific heat, but ignored temperature
dependencies of any of the other parameters.
Currently, fix ttm assumes that none of the user-supplied parameters
will vary with temperature. Note that "(Duffy)"_#Duffy used a tanh()
functional form for the temperature dependence of the electronic
specific heat, but ignored temperature dependencies of any of the
other parameters. See more discussion below for fix ttm/mod.
This fix requires use of periodic boundary conditions and a 3D
These fixes requires use of periodic boundary conditions and a 3D
simulation. Periodic boundary conditions are also used in the heat
equation solve for the electronic subsystem. This varies from the
approach of "(Rutherford)"_#Rutherford where the atomic subsystem was
@ -135,14 +154,122 @@ the electronic subsystem. The ordering of the Nx*Ny*Nz columns is
with the z index varing fastest, y the next fastest, and x the
slowest.
This fix does not change the coordinates of its atoms; it only scales
their velocities. Thus a time integration fix (e.g. "fix
These fixes do not change the coordinates of its atoms; they only
scales their velocities. Thus a time integration fix (e.g. "fix
nve"_fix_nve.html) should still be used to time integrate the affected
atoms. This fix should not normally be used on atoms that have their
atoms. Th fixes should not normally be used on atoms that have their
temperature controlled by another fix - e.g. "fix nvt"_fix_nh.html or
"fix langevin"_fix_langevin.html.
This fix computes 2 output quantities stored in a vector of length 2,
IMPORTANT NOTE: The current implementation of these fixes creates a
copy of the electron grid that overlays the entire simulation domain,
for each processor. Values on the grid are summed across all
processors. Thus you should insure that this grid is not too large,
else your simulation could incur high memory and communication costs.
:line
[Additional details for fix ttm/mod]
Fix ttm/mod uses the heat diffusion equation with possible external
heat sources (e.g. laser heating in ablation simulations):
:c,image(Eqs/fix_ttm_mod.jpg)
where I_0 is the (absorbed) laser pulse intensity for ablation
simulations, l_skin is the depth of skin-layer, and all other
designations have the same meaning as in the former equation.
Fix ttm/mod also allows users to specify the dependencies of C_e and
kappa_e on the electronic temperature. The specific heat is expressed
as
:c,image(Eqs/fix_ttm_ce.jpg)
where {X} = T_e/1000, and the thermal conductivity is defined as
kappa_e = D_e*rho_e*C_e, where D_e is the thermal diffusion
coefficient.
Electronic pressure effects are included in the TTM model to account
for the blast force acting on ions because of electronic pressure
gradient (see "(Chen)"_Chen, "(Norman)"_#Norman). The total force
acting on an ion is:
:c,image(Eqs/fix_ttm_blast.jpg)
where F_langevin is a force from Langevin thermostat simulating
electron-phonon coupling, and nabla P_e/n_ion is the electron blast
force.
The electronic pressure is taken to be P_e = B*rho_e*C_e*T_e
The current fix ttm/mod implementation allows TTM simulations with a
vacuum. The vacuum region is defined as the grid cells with zero
electronic temperature. The numerical scheme does not allow energy
exchange with such cells. Since the material can expand to previously
unoccupied region in some simulations, the vacuum border can be
allowed to move. It is controlled by the {surface_movement} parameter
in the {init_file}. If it is set to 1, then "vacuum" cells can be
changed to "electron-filled" cells with the temperature {T_e_min} if
atoms move into them (currently only implemented for the case of
1-dimensional motion of flat surface normal to the X axis). The
initial borders of vacuum can be set in the {init_file} via {lsurface}
and {rsurface} parameters. In this case, electronic pressure gradient
is calculated as
:c,image(Eqs/fix_ttm_blast1.jpg)
where lambda is the electron mean free path (see "(Norman)"_#Norman,
"(Pisarev)"_#Pisarev)
The fix ttm/mod parameter file {init_file} has the following syntax/
Every line with the odd number is considered as a comment and
ignored. The lines with the even numbers are treated as follows:
a_0, energy/(temperature*electron) units
a_1, energy/(temperature^2*electron) units
a_2, energy/(temperature^3*electron) units
a_3, energy/(temperature^4*electron) units
a_4, energy/(temperature^5*electron) units
C_0, energy/(temperature*electron) units
A, 1/temperature units
rho_e, electrons/volume units
D_e, length^2/time units
gamma_p, mass/time units
gamma_s, mass/time units
v_0, length/time units
I_0, energy/(time*length^2) units
lsurface, electron grid units (positive integer)
rsurface, electron grid units (positive integer)
l_skin, length units
tau, time units
B, dimensionless
lambda, length units
n_ion, ions/volume units
surface_movement: 0 to disable tracking of surface motion, 1 to enable
T_e_min, temperature units :pre
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
These fixes writes the state of the electronic subsystem and the
energy exchange between the subsystems to "binary restart
files"_restart.html. See the "read_restart"_read_restart.html command
for info on how to re-specify a fix in an input script that reads a
restart file, so that the operation of the fix continues in an
uninterrupted fashion.
Because the state of the random number generator is not saved in the
restart files, this means you cannot do "exact" restarts with this
fix, where the simulation continues on the same as if no restart had
taken place. However, in a statistical sense, a restarted simulation
should produce the same behavior.
None of the "fix_modify"_fix_modify.html options are relevant to these
fixes.
Both fixes compute 2 output quantities stored in a vector of length 2,
which can be accessed by various "output
commands"_Section_howto.html#howto_15. The first quantity is the
total energy of the electronic subsystem. The second quantity is the
@ -156,45 +283,23 @@ energy. As a result of this, users may notice slight fluctuations in
the sum of the atomic and electronic subsystem energies reported at
the end of the timestep.
The vector values calculated by this fix are "extensive".
The vector values calculated are "extensive".
IMPORTANT NOTE: The current implementation creates a copy of the
electron grid that overlays the entire simulation domain, for each
processor. Values on the grid are summed across all processors. Thus
you should insure that this grid is not too large, else your
simulation could incur high memory and communication costs.
[Restart, fix_modify, output, run start/stop, minimize info:]
This fix writes the state of the electronic subsystem and the energy
exchange between the subsystems to "binary restart
files"_restart.html. See the "read_restart"_read_restart.html command
for info on how to re-specify a fix in an input script that reads a
restart file, so that the operation of the fix continues in an
uninterrupted fashion.
Because the state of the random number generator is not saved in the
restart files, this means you cannot do "exact" restarts with this
fix, where the simulation continues on the same as if no restart had
taken place. However, in a statistical sense, a restarted simulation
should produce the same behavior.
None of the "fix_modify"_fix_modify.html options are relevant to this
fix. No global or per-atom quantities are stored by this fix for
access by various "output commands"_Section_howto.html#howto_15. No
parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command. This fix is not invoked during "energy
minimization"_minimize.html.
No parameter of the fixes can be used with the {start/stop} keywords
of the "run"_run.html command. The fixes are not invoked during
"energy minimization"_minimize.html.
[Restrictions:]
This fix is part of the MISC package. It is only enabled if LAMMPS
was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
Fix {ttm} is part of the MISC package. It is only enabled if LAMMPS
was built with that package. Fix {ttm/mod} is part of the USER-MISC
package. It is only enabled if LAMMPS was built with that package.
See the "Making LAMMPS"_Section_start.html#start_3 section for more
info.
This fix can only be used for 3d simulations and orthogonal
simlulation boxes. You must use periodic "boundary"_boundary.html
conditions with this fix.
These fixes can only be used for 3d simulations and orthogonal
simlulation boxes. You must also use periodic
"boundary"_boundary.html conditions.
[Related commands:]
@ -211,3 +316,15 @@ conditions with this fix.
:link(Rutherford)
[(Rutherford)] A M Rutherford and D M Duffy, J. Phys.:
Condens. Matter, 19, 496201-496210 (2007).
:link(Chen)
[(Chen)] J Chen, D Tzou and J Beraun, Int. J. Heat
Mass Transfer, 49, 307-316 (2006).
:link(Norman)
[(Norman)] G E Norman, S V Starikov, V V Stegailov et al., Contrib.
Plasma Phys., 53, 129-139 (2013).
:link(Pisarev)
[(Pisarev)] V V Pisarev and S V Starikov, J. Phys.: Condens. Matter, 26,
475401 (2014).

View File

@ -15,6 +15,8 @@
</H3>
<H3>pair_style buck/gpu command
</H3>
<H3>pair_style buck/kk command
</H3>
<H3>pair_style buck/omp command
</H3>
<H3>pair_style buck/coul/cut command

View File

@ -9,6 +9,7 @@
pair_style buck command :h3
pair_style buck/cuda command :h3
pair_style buck/gpu command :h3
pair_style buck/kk command :h3
pair_style buck/omp command :h3
pair_style buck/coul/cut command :h3
pair_style buck/coul/cut/cuda command :h3

View File

@ -13,6 +13,8 @@
</H3>
<H3>pair_style coul/cut/gpu command
</H3>
<H3>pair_style coul/cut/kk command
</H3>
<H3>pair_style coul/cut/omp command
</H3>
<H3>pair_style coul/debye command
@ -25,6 +27,8 @@
</H3>
<H3>pair_style coul/dsf/gpu command
</H3>
<H3>pair_style coul/dsf/kk command
</H3>
<H3>pair_style coul/dsf/omp command
</H3>
<H3>pair_style coul/long command
@ -39,6 +43,8 @@
</H3>
<H3>pair_style coul/wolf command
</H3>
<H3>pair_style coul/wolf/kk command
</H3>
<H3>pair_style coul/wolf/omp command
</H3>
<H3>pair_style tip4p/cut command

View File

@ -8,12 +8,14 @@
pair_style coul/cut command :h3
pair_style coul/cut/gpu command :h3
pair_style coul/cut/kk command :h3
pair_style coul/cut/omp command :h3
pair_style coul/debye command :h3
pair_style coul/debye/gpu command :h3
pair_style coul/debye/omp command :h3
pair_style coul/dsf command :h3
pair_style coul/dsf/gpu command :h3
pair_style coul/dsf/kk command :h3
pair_style coul/dsf/omp command :h3
pair_style coul/long command :h3
pair_style coul/long/omp command :h3
@ -21,6 +23,7 @@ pair_style coul/long/gpu command :h3
pair_style coul/msm command :h3
pair_style coul/msm/omp command :h3
pair_style coul/wolf command :h3
pair_style coul/wolf/kk command :h3
pair_style coul/wolf/omp command :h3
pair_style tip4p/cut command :h3
pair_style tip4p/long command :h3

View File

@ -15,6 +15,8 @@
</H3>
<H3>pair_style eam/gpu command
</H3>
<H3>pair_style eam/kk command
</H3>
<H3>pair_style eam/omp command
</H3>
<H3>pair_style eam/opt command

View File

@ -9,6 +9,7 @@
pair_style eam command :h3
pair_style eam/cuda command :h3
pair_style eam/gpu command :h3
pair_style eam/kk command :h3
pair_style eam/omp command :h3
pair_style eam/opt command :h3
pair_style eam/alloy command :h3

70
lib/kokkos/Makefile.lammps Normal file → Executable file
View File

@ -1,71 +1,54 @@
# This Makefile is intended to be included in an application Makefile
# It will append the OBJ variable with objects needed for building with Kokkos
# This Makefile is intended to be include in an application Makefile.
# It will append the OBJ variable with objects which need to be build for Kokkos.
# It also will produce a KOKKOS_INC and a KOKKOS_LINK variable which must be
# appended to the compile and link flags in the application Makefile
# appended to the compile and link flags of the application Makefile.
# Note that you cannot compile and link at the same time!
# If you want to include dependencies (i.e. trigger a rebuild
# of the application object files when Kokkos files change,
# you can include KOKKOS_HEADERS in your dependency list)
# This potion of the Makefile defines defaults for sevearl variables
# they can be overridden on the make commandline
# or in the application Makefile prior to including this Makefile
# Directory path to the Kokkos source directory
# this could be the kokkos directory in the Trilinos git repository
# If you want to include dependencies (i.e. trigger a rebuild of the application
# object files when Kokkos files change, you can include KOKKOS_HEADERS in your
# dependency list.
# The Makefile uses a number of variables which can be set on the commandline, or
# in the application Makefile prior to including this Makefile. These options set
# certain build options and are explained in the following.
# Directory path to the Kokkos source directory (this could be the kokkos directory
# in the Trilinos git repository
KOKKOS_PATH ?= ../../lib/kokkos
# Directory paths to libraries potentially used by Kokkos
# if the corresponding options are chosen
# Directory paths to libraries potentially used by Kokkos (if the respective options
# are chosen)
CUDA_PATH ?= /usr/local/cuda
HWLOC_PATH ?= /usr/local/hwloc/default
# Device options: enable Pthreads, OpenMP and/or CUDA device
# if none is enabled the Serial device will be used
# Device options: enable Pthreads, OpenMP and/or CUDA device (if none is enabled
# the Serial device will be used)
PTHREADS ?= yes
OMP ?= yes
CUDA ?= no
# Build for Debug mode: add debug flags and enable boundschecks within Kokkos
DEBUG ?= no
# Code generation options:
# use AVX instruction set
# build for Xeon Phi (MIC)
# use reduced precision math (sets compiler flags like --fast_math)
# Code generation options: use AVX instruction set; build for Xeon Phi (MIC); use
# reduced precision math (sets compiler flags such --fast_math)
AVX ?= no
MIC ?= no
RED_PREC ?=no
# Optional Libraries:
# use hwloc for thread affinity
# use librt for timers
# Optional Libraries: use hwloc for thread affinity; use librt for timers
HWLOC ?= no
LIBRT ?= no
# CUDA specific options:
# use UVM (requires CUDA 6+)
# use LDG loads instead of texture fetches
# compile for relocatable device code (function pointers)
# CUDA specific options: use UVM (requires CUDA 6+); use LDG loads instead of
# texture fetches; compile for relocatable device code (function pointers)
CUDA_UVM ?= no
CUDA_LDG ?= no
CUDA_RELOC ?= no
# Settings for replacing generic linear algebra kernels of Kokkos
# with vendor libraries
# Settings for replacing generic linear algebra kernels of Kokkos with vendor
# libraries.
CUSPARSE ?= no
CUBLAS ?= no
# Typically nothing should be changed after this point
#Typically nothing should be changed after this point
KOKKOS_INC = -I$(KOKKOS_PATH)/core/src -I$(KOKKOS_PATH)/containers/src -I$(KOKKOS_PATH)/algorithms/src -I$(KOKKOS_PATH)/linalg/src -I../ -DKOKKOS_DONT_INCLUDE_CORE_CONFIG_H
@ -131,12 +114,8 @@ KOKKOS_INC += -Xcompiler -fopenmp
else
KOKKOS_INC += -fopenmp
endif
ifeq ($(CUDA), yes)
KOKKOS_LINK += -Xcompiler -fopenmp
else
KOKKOS_LINK += -fopenmp
endif
endif
ifeq ($(HWLOC),yes)
KOKKOS_INC += -DKOKKOS_HAVE_HWLOC -I$(HWLOC_PATH)/include
@ -171,9 +150,8 @@ KOKKOS_LINK += --relocatable-device-code=true
endif
endif
ifeq ($(CXX11), yes)
# Must build with C++11
KOKKOS_INC += --std=c++11 -DKOKKOS_HAVE_CXX11
endif
OBJ_KOKKOS_TMP = $(SRC_KOKKOS:.cpp=.o)
OBJ_KOKKOS = $(OBJ_KOKKOS_TMP:.cu=.o)

0
lib/kokkos/README Normal file → Executable file
View File

View File

View File

@ -0,0 +1,9 @@
SET(LIB_REQUIRED_DEP_PACKAGES)
SET(LIB_OPTIONAL_DEP_PACKAGES)
SET(TEST_REQUIRED_DEP_PACKAGES)
SET(TEST_OPTIONAL_DEP_PACKAGES)
SET(LIB_REQUIRED_DEP_TPLS)
# Only dependency:
SET(LIB_OPTIONAL_DEP_TPLS CUDA)
SET(TEST_REQUIRED_DEP_TPLS )
SET(TEST_OPTIONAL_DEP_TPLS )

0
lib/kokkos/TPL/cub/block/block_discontinuity.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/block/block_exchange.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/block/block_histogram.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/block/block_load.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/block/block_radix_rank.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/block/block_radix_sort.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/block/block_raking_layout.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/block/block_reduce.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/block/block_scan.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/block/block_store.cuh Normal file → Executable file
View File

View File

View File

View File

View File

View File

0
lib/kokkos/TPL/cub/cub.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/device/block/block_histo_tiles.cuh Normal file → Executable file
View File

View File

View File

View File

View File

0
lib/kokkos/TPL/cub/device/block/block_reduce_tiles.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/device/block/block_scan_tiles.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/device/block/scan_tiles_types.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/device/device_histogram.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/device/device_radix_sort.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/device/device_reduce.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/device/device_reduce_by_key.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/device/device_reorder.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/device/device_scan.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/grid/grid_barrier.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/grid/grid_even_share.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/grid/grid_mapping.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/grid/grid_queue.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/host/spinlock.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/thread/thread_load.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/thread/thread_operators.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/thread/thread_reduce.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/thread/thread_scan.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/thread/thread_store.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/util_allocator.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/util_arch.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/util_debug.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/util_device.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/util_iterator.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/util_macro.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/util_namespace.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/util_ptx.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/util_type.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/util_vector.cuh Normal file → Executable file
View File

View File

View File

View File

View File

0
lib/kokkos/TPL/cub/warp/warp_reduce.cuh Normal file → Executable file
View File

0
lib/kokkos/TPL/cub/warp/warp_scan.cuh Normal file → Executable file
View File

202
lib/kokkos/algorithms/src/Kokkos_Random.hpp Normal file → Executable file
View File

@ -46,9 +46,6 @@
#include <Kokkos_Core.hpp>
#ifdef KOKKOS_HAVE_CUDA
#include <Kokkos_Cuda.hpp>
#endif
#include <cstdio>
#include <cstdlib>
#include <cmath>
@ -288,49 +285,161 @@ namespace Kokkos {
template<class Generator>
struct rand<Generator,unsigned int> {
KOKKOS_INLINE_FUNCTION
static unsigned int max(){return Generator::MAX_URAND;}
static unsigned int max () {
return Generator::MAX_URAND;
}
KOKKOS_INLINE_FUNCTION
static unsigned int draw(Generator& gen)
{return gen.urand();}
static unsigned int draw (Generator& gen) {
return gen.urand ();
}
KOKKOS_INLINE_FUNCTION
static unsigned int draw(Generator& gen, const unsigned int& range)
{return gen.urand(range);}
static unsigned int draw(Generator& gen, const unsigned int& range) {
return gen.urand (range);
}
KOKKOS_INLINE_FUNCTION
static unsigned int draw(Generator& gen, const unsigned int& start, const unsigned int& end)
{return gen.urand(start,end);}
static unsigned int
draw (Generator& gen, const unsigned int& start, const unsigned int& end) {
return gen.urand (start, end);
}
};
template<class Generator>
struct rand<Generator,int64_t> {
struct rand<Generator,long> {
KOKKOS_INLINE_FUNCTION
static int64_t max(){return Generator::MAX_RAND64;}
static long max () {
// FIXME (mfh 26 Oct 2014) It would be better to select the
// return value at compile time, using something like enable_if.
return sizeof (long) == 4 ?
static_cast<long> (Generator::MAX_RAND) :
static_cast<long> (Generator::MAX_RAND64);
}
KOKKOS_INLINE_FUNCTION
static int64_t draw(Generator& gen)
{return gen.rand64();}
static long draw (Generator& gen) {
// FIXME (mfh 26 Oct 2014) It would be better to select the
// return value at compile time, using something like enable_if.
return sizeof (long) == 4 ?
static_cast<long> (gen.rand ()) :
static_cast<long> (gen.rand64 ());
}
KOKKOS_INLINE_FUNCTION
static int64_t draw(Generator& gen, const int64_t& range)
{return gen.rand64(range);}
static long draw (Generator& gen, const long& range) {
// FIXME (mfh 26 Oct 2014) It would be better to select the
// return value at compile time, using something like enable_if.
return sizeof (long) == 4 ?
static_cast<long> (gen.rand (static_cast<int> (range))) :
static_cast<long> (gen.rand64 (range));
}
KOKKOS_INLINE_FUNCTION
static int64_t draw(Generator& gen, const int64_t& start, const int64_t& end)
{return gen.rand64(start,end);}
static long draw (Generator& gen, const long& start, const long& end) {
// FIXME (mfh 26 Oct 2014) It would be better to select the
// return value at compile time, using something like enable_if.
return sizeof (long) == 4 ?
static_cast<long> (gen.rand (static_cast<int> (start),
static_cast<int> (end))) :
static_cast<long> (gen.rand64 (start, end));
}
};
template<class Generator>
struct rand<Generator,uint64_t> {
struct rand<Generator,unsigned long> {
KOKKOS_INLINE_FUNCTION
static uint64_t max(){return Generator::MAX_URAND64;}
static unsigned long max () {
// FIXME (mfh 26 Oct 2014) It would be better to select the
// return value at compile time, using something like enable_if.
return sizeof (unsigned long) == 4 ?
static_cast<unsigned long> (Generator::MAX_URAND) :
static_cast<unsigned long> (Generator::MAX_URAND64);
}
KOKKOS_INLINE_FUNCTION
static uint64_t draw(Generator& gen)
{return gen.urand64();}
static unsigned long draw (Generator& gen) {
// FIXME (mfh 26 Oct 2014) It would be better to select the
// return value at compile time, using something like enable_if.
return sizeof (unsigned long) == 4 ?
static_cast<unsigned long> (gen.urand ()) :
static_cast<unsigned long> (gen.urand64 ());
}
KOKKOS_INLINE_FUNCTION
static uint64_t draw(Generator& gen, const uint64_t& range)
{return gen.urand64(range);}
static unsigned long draw(Generator& gen, const unsigned long& range) {
// FIXME (mfh 26 Oct 2014) It would be better to select the
// return value at compile time, using something like enable_if.
return sizeof (unsigned long) == 4 ?
static_cast<unsigned long> (gen.urand (static_cast<unsigned int> (range))) :
static_cast<unsigned long> (gen.urand64 (range));
}
KOKKOS_INLINE_FUNCTION
static uint64_t draw(Generator& gen, const uint64_t& start, const uint64_t& end)
{return gen.urand64(start,end);}
static unsigned long
draw (Generator& gen, const unsigned long& start, const unsigned long& end) {
// FIXME (mfh 26 Oct 2014) It would be better to select the
// return value at compile time, using something like enable_if.
return sizeof (unsigned long) == 4 ?
static_cast<unsigned long> (gen.urand (static_cast<unsigned int> (start),
static_cast<unsigned int> (end))) :
static_cast<unsigned long> (gen.urand64 (start, end));
}
};
// NOTE (mfh 26 oct 2014) This is a partial specialization for long
// long, a C99 / C++11 signed type which is guaranteed to be at
// least 64 bits. Do NOT write a partial specialization for
// int64_t!!! This is just a typedef! It could be either long or
// long long. We don't know which a priori, and I've seen both.
// The types long and long long are guaranteed to differ, so it's
// always safe to specialize for both.
template<class Generator>
struct rand<Generator, long long> {
KOKKOS_INLINE_FUNCTION
static long long max () {
// FIXME (mfh 26 Oct 2014) It's legal for long long to be > 64 bits.
return Generator::MAX_RAND64;
}
KOKKOS_INLINE_FUNCTION
static long long draw (Generator& gen) {
// FIXME (mfh 26 Oct 2014) It's legal for long long to be > 64 bits.
return gen.rand64 ();
}
KOKKOS_INLINE_FUNCTION
static long long draw (Generator& gen, const long long& range) {
// FIXME (mfh 26 Oct 2014) It's legal for long long to be > 64 bits.
return gen.rand64 (range);
}
KOKKOS_INLINE_FUNCTION
static long long draw (Generator& gen, const long long& start, const long long& end) {
// FIXME (mfh 26 Oct 2014) It's legal for long long to be > 64 bits.
return gen.rand64 (start, end);
}
};
// NOTE (mfh 26 oct 2014) This is a partial specialization for
// unsigned long long, a C99 / C++11 unsigned type which is
// guaranteed to be at least 64 bits. Do NOT write a partial
// specialization for uint64_t!!! This is just a typedef! It could
// be either unsigned long or unsigned long long. We don't know
// which a priori, and I've seen both. The types unsigned long and
// unsigned long long are guaranteed to differ, so it's always safe
// to specialize for both.
template<class Generator>
struct rand<Generator,unsigned long long> {
KOKKOS_INLINE_FUNCTION
static unsigned long long max () {
// FIXME (mfh 26 Oct 2014) It's legal for unsigned long long to be > 64 bits.
return Generator::MAX_URAND64;
}
KOKKOS_INLINE_FUNCTION
static unsigned long long draw (Generator& gen) {
// FIXME (mfh 26 Oct 2014) It's legal for unsigned long long to be > 64 bits.
return gen.urand64 ();
}
KOKKOS_INLINE_FUNCTION
static unsigned long long draw (Generator& gen, const unsigned long long& range) {
// FIXME (mfh 26 Oct 2014) It's legal for long long to be > 64 bits.
return gen.urand64 (range);
}
KOKKOS_INLINE_FUNCTION
static unsigned long long
draw (Generator& gen, const unsigned long long& start, const unsigned long long& end) {
// FIXME (mfh 26 Oct 2014) It's legal for long long to be > 64 bits.
return gen.urand64 (start, end);
}
};
template<class Generator>
@ -543,6 +652,19 @@ namespace Kokkos {
init(seed,DeviceType::max_hardware_threads());
}
Random_XorShift64_Pool(const Random_XorShift64_Pool& src):
locks_(src.locks_),
state_(src.state_),
num_states_(src.num_states_)
{}
Random_XorShift64_Pool operator = (const Random_XorShift64_Pool& src) {
locks_ = src.locks_;
state_ = src.state_;
num_states_ = src.num_states_;
return *this;
}
void init(unsigned int seed, int num_states) {
num_states_ = num_states;
@ -552,7 +674,8 @@ namespace Kokkos {
typename state_data_type::HostMirror h_state = create_mirror_view(state_);
typename lock_type::HostMirror h_lock = create_mirror_view(locks_);
Random_XorShift64<Kokkos::Serial> gen(seed,0);
// Execute on the HostMirror's default execution space.
Random_XorShift64<typename state_data_type::HostMirror::execution_space> gen(seed,0);
for(int i = 0; i < 17; i++)
gen.rand();
for(int i = 0; i < num_states_; i++) {
@ -747,7 +870,7 @@ namespace Kokkos {
};
template<class DeviceType = Kokkos::Impl::ActiveExecutionMemorySpace::execution_space >
template<class DeviceType = Kokkos::DefaultExecutionSpace>
class Random_XorShift1024_Pool {
private:
typedef View<int*,DeviceType> int_view_type;
@ -773,6 +896,21 @@ namespace Kokkos {
init(seed,DeviceType::max_hardware_threads());
}
Random_XorShift1024_Pool(const Random_XorShift1024_Pool& src):
locks_(src.locks_),
state_(src.state_),
p_(src.p_),
num_states_(src.num_states_)
{}
Random_XorShift1024_Pool operator = (const Random_XorShift1024_Pool& src) {
locks_ = src.locks_;
state_ = src.state_;
p_ = src.p_;
num_states_ = src.num_states_;
return *this;
}
inline
void init(unsigned int seed, int num_states) {
num_states_ = num_states;
@ -784,7 +922,9 @@ namespace Kokkos {
typename state_data_type::HostMirror h_state = create_mirror_view(state_);
typename int_view_type::HostMirror h_lock = create_mirror_view(locks_);
typename int_view_type::HostMirror h_p = create_mirror_view(p_);
Random_XorShift64<Kokkos::Serial> gen(seed,0);
// Execute on the HostMirror's default execution space.
Random_XorShift64<typename state_data_type::HostMirror::execution_space> gen(seed,0);
for(int i = 0; i < 17; i++)
gen.rand();
for(int i = 0; i < num_states_; i++) {

View File

@ -0,0 +1,486 @@
/*
//@HEADER
// ************************************************************************
//
// Kokkos
// Manycore Performance-Portable Multidimensional Arrays
//
// Copyright (2012) Sandia Corporation
//
// Under the terms of Contract DE-AC04-94AL85000 with Sandia Corporation,
// the U.S. Government retains certain rights in this software.
//
// Redistribution and use in source and binary forms, with or without
// modification, are permitted provided that the following conditions are
// met:
//
// 1. Redistributions of source code must retain the above copyright
// notice, this list of conditions and the following disclaimer.
//
// 2. Redistributions in binary form must reproduce the above copyright
// notice, this list of conditions and the following disclaimer in the
// documentation and/or other materials provided with the distribution.
//
// 3. Neither the name of the Corporation nor the names of the
// contributors may be used to endorse or promote products derived from
// this software without specific prior written permission.
//
// THIS SOFTWARE IS PROVIDED BY SANDIA CORPORATION "AS IS" AND ANY
// EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
// IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
// PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL SANDIA CORPORATION OR THE
// CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
// EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
// PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
// PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
// LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
// NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
// SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
//
// Questions? Contact H. Carter Edwards (hcedwar@sandia.gov)
//
// ************************************************************************
//@HEADER
*/
#ifndef KOKKOS_SORT_HPP_
#define KOKKOS_SORT_HPP_
#include <Kokkos_Core.hpp>
#include <algorithm>
namespace Kokkos {
namespace SortImpl {
template<class ValuesViewType, int Rank=ValuesViewType::Rank>
struct CopyOp;
template<class ValuesViewType>
struct CopyOp<ValuesViewType,1> {
template<class DstType, class SrcType>
KOKKOS_INLINE_FUNCTION
static void copy(DstType& dst, size_t i_dst,
SrcType& src, size_t i_src ) {
dst(i_dst) = src(i_src);
}
};
template<class ValuesViewType>
struct CopyOp<ValuesViewType,2> {
template<class DstType, class SrcType>
KOKKOS_INLINE_FUNCTION
static void copy(DstType& dst, size_t i_dst,
SrcType& src, size_t i_src ) {
for(int j = 0;j< (int) dst.dimension_1(); j++)
dst(i_dst,j) = src(i_src,j);
}
};
template<class ValuesViewType>
struct CopyOp<ValuesViewType,3> {
template<class DstType, class SrcType>
KOKKOS_INLINE_FUNCTION
static void copy(DstType& dst, size_t i_dst,
SrcType& src, size_t i_src ) {
for(int j = 0; j<dst.dimension_1(); j++)
for(int k = 0; k<dst.dimension_2(); k++)
dst(i_dst,j,k) = src(i_src,j,k);
}
};
}
template<class KeyViewType, class BinSortOp, class ExecutionSpace = typename KeyViewType::execution_space,
class SizeType = typename KeyViewType::memory_space::size_type>
class BinSort {
public:
template<class ValuesViewType, class PermuteViewType, class CopyOp>
struct bin_sort_sort_functor {
typedef ExecutionSpace execution_space;
typedef typename ValuesViewType::non_const_type values_view_type;
typedef typename ValuesViewType::const_type const_values_view_type;
Kokkos::View<typename values_view_type::const_data_type,typename values_view_type::array_layout,
typename values_view_type::memory_space,Kokkos::MemoryTraits<Kokkos::RandomAccess> > values;
values_view_type sorted_values;
typename PermuteViewType::const_type sort_order;
bin_sort_sort_functor(const_values_view_type values_, values_view_type sorted_values_, PermuteViewType sort_order_):
values(values_),sorted_values(sorted_values_),sort_order(sort_order_) {}
KOKKOS_INLINE_FUNCTION
void operator() (const int& i) const {
//printf("Sort: %i %i\n",i,sort_order(i));
CopyOp::copy(sorted_values,i,values,sort_order(i));
}
};
typedef ExecutionSpace execution_space;
typedef BinSortOp bin_op_type;
struct bin_count_tag {};
struct bin_offset_tag {};
struct bin_binning_tag {};
struct bin_sort_bins_tag {};
public:
typedef SizeType size_type;
typedef size_type value_type;
typedef Kokkos::View<size_type*, execution_space> offset_type;
typedef Kokkos::View<const int*, execution_space> bin_count_type;
typedef Kokkos::View<typename KeyViewType::const_data_type,
typename KeyViewType::array_layout,
typename KeyViewType::memory_space> const_key_view_type;
typedef Kokkos::View<typename KeyViewType::const_data_type,
typename KeyViewType::array_layout,
typename KeyViewType::memory_space,
Kokkos::MemoryTraits<Kokkos::RandomAccess> > const_rnd_key_view_type;
typedef typename KeyViewType::non_const_value_type non_const_key_scalar;
typedef typename KeyViewType::const_value_type const_key_scalar;
private:
const_key_view_type keys;
const_rnd_key_view_type keys_rnd;
public:
BinSortOp bin_op;
offset_type bin_offsets;
Kokkos::View<int*, ExecutionSpace, Kokkos::MemoryTraits<Kokkos::Atomic> > bin_count_atomic;
bin_count_type bin_count_const;
offset_type sort_order;
bool sort_within_bins;
public:
// Constructor: takes the keys, the binning_operator and optionally whether to sort within bins (default false)
BinSort(const_key_view_type keys_, BinSortOp bin_op_,
bool sort_within_bins_ = false)
:keys(keys_),keys_rnd(keys_), bin_op(bin_op_) {
bin_count_atomic = Kokkos::View<int*, ExecutionSpace >("Kokkos::SortImpl::BinSortFunctor::bin_count",bin_op.max_bins());
bin_count_const = bin_count_atomic;
bin_offsets = offset_type("Kokkos::SortImpl::BinSortFunctor::bin_offsets",bin_op.max_bins());
sort_order = offset_type("PermutationVector",keys.dimension_0());
sort_within_bins = sort_within_bins_;
}
// Create the permutation vector, the bin_offset array and the bin_count array. Can be called again if keys changed
void create_permute_vector() {
Kokkos::parallel_for (Kokkos::RangePolicy<ExecutionSpace,bin_count_tag> (0,keys.dimension_0()),*this);
Kokkos::parallel_scan(Kokkos::RangePolicy<ExecutionSpace,bin_offset_tag> (0,bin_op.max_bins()) ,*this);
Kokkos::deep_copy(bin_count_atomic,0);
Kokkos::parallel_for (Kokkos::RangePolicy<ExecutionSpace,bin_binning_tag> (0,keys.dimension_0()),*this);
if(sort_within_bins)
Kokkos::parallel_for (Kokkos::RangePolicy<ExecutionSpace,bin_sort_bins_tag>(0,bin_op.max_bins()) ,*this);
}
// Sort a view with respect ot the first dimension using the permutation array
template<class ValuesViewType>
void sort(ValuesViewType values) {
ValuesViewType sorted_values = ValuesViewType("Copy",
values.dimension_0(),
values.dimension_1(),
values.dimension_2(),
values.dimension_3(),
values.dimension_4(),
values.dimension_5(),
values.dimension_6(),
values.dimension_7());
parallel_for(values.dimension_0(),
bin_sort_sort_functor<ValuesViewType, offset_type,
SortImpl::CopyOp<ValuesViewType> >(values,sorted_values,sort_order));
deep_copy(values,sorted_values);
}
// Get the permutation vector
KOKKOS_INLINE_FUNCTION
offset_type get_permute_vector() const { return sort_order;}
// Get the start offsets for each bin
KOKKOS_INLINE_FUNCTION
offset_type get_bin_offsets() const { return bin_offsets;}
// Get the count for each bin
KOKKOS_INLINE_FUNCTION
bin_count_type get_bin_count() const {return bin_count_const;}
public:
KOKKOS_INLINE_FUNCTION
void operator() (const bin_count_tag& tag, const int& i) const {
bin_count_atomic(bin_op.bin(keys,i))++;
}
KOKKOS_INLINE_FUNCTION
void operator() (const bin_offset_tag& tag, const int& i, value_type& offset, const bool& final) const {
if(final) {
bin_offsets(i) = offset;
}
offset+=bin_count_const(i);
}
KOKKOS_INLINE_FUNCTION
void operator() (const bin_binning_tag& tag, const int& i) const {
const int bin = bin_op.bin(keys,i);
const int count = bin_count_atomic(bin)++;
sort_order(bin_offsets(bin) + count) = i;
}
KOKKOS_INLINE_FUNCTION
void operator() (const bin_sort_bins_tag& tag, const int&i ) const {
bool sorted = false;
int upper_bound = bin_offsets(i)+bin_count_const(i);
while(!sorted) {
sorted = true;
int old_idx = sort_order(bin_offsets(i));
int new_idx;
for(int k=bin_offsets(i)+1; k<upper_bound; k++) {
new_idx = sort_order(k);
if(!bin_op(keys_rnd,old_idx,new_idx)) {
sort_order(k-1) = new_idx;
sort_order(k) = old_idx;
sorted = false;
} else {
old_idx = new_idx;
}
}
upper_bound--;
}
}
};
namespace SortImpl {
template<class KeyViewType>
struct DefaultBinOp1D {
const int max_bins_;
const double mul_;
typename KeyViewType::const_value_type range_;
typename KeyViewType::const_value_type min_;
//Construct BinOp with number of bins, minimum value and maxuimum value
DefaultBinOp1D(int max_bins, typename KeyViewType::const_value_type min,
typename KeyViewType::const_value_type max )
:max_bins_(max_bins+1),mul_(1.0*max_bins/(max-min)),range_(max-min),min_(min) {}
//Determine bin index from key value
template<class ViewType>
KOKKOS_INLINE_FUNCTION
int bin(ViewType& keys, const int& i) const {
return int(mul_*(keys(i)-min_));
}
//Return maximum bin index + 1
KOKKOS_INLINE_FUNCTION
int max_bins() const {
return max_bins_;
}
//Compare to keys within a bin if true new_val will be put before old_val
template<class ViewType, typename iType1, typename iType2>
KOKKOS_INLINE_FUNCTION
bool operator()(ViewType& keys, iType1& i1, iType2& i2) const {
return keys(i1)<keys(i2);
}
};
template<class KeyViewType>
struct DefaultBinOp3D {
int max_bins_[3];
double mul_[3];
typename KeyViewType::non_const_value_type range_[3];
typename KeyViewType::non_const_value_type min_[3];
DefaultBinOp3D(int max_bins[], typename KeyViewType::const_value_type min[],
typename KeyViewType::const_value_type max[] )
{
max_bins_[0] = max_bins[0]+1;
max_bins_[1] = max_bins[1]+1;
max_bins_[2] = max_bins[2]+1;
mul_[0] = 1.0*max_bins[0]/(max[0]-min[0]);
mul_[1] = 1.0*max_bins[1]/(max[1]-min[1]);
mul_[2] = 1.0*max_bins[2]/(max[2]-min[2]);
range_[0] = max[0]-min[0];
range_[1] = max[1]-min[1];
range_[2] = max[2]-min[2];
min_[0] = min[0];
min_[1] = min[1];
min_[2] = min[2];
}
template<class ViewType>
KOKKOS_INLINE_FUNCTION
int bin(ViewType& keys, const int& i) const {
return int( (((int(mul_[0]*(keys(i,0)-min_[0]))*max_bins_[1]) +
int(mul_[1]*(keys(i,1)-min_[1])))*max_bins_[2]) +
int(mul_[2]*(keys(i,2)-min_[2])));
}
KOKKOS_INLINE_FUNCTION
int max_bins() const {
return max_bins_[0]*max_bins_[1]*max_bins_[2];
}
template<class ViewType, typename iType1, typename iType2>
KOKKOS_INLINE_FUNCTION
bool operator()(ViewType& keys, iType1& i1 , iType2& i2) const {
if (keys(i1,0)>keys(i2,0)) return true;
else if (keys(i1,0)==keys(i2,0)) {
if (keys(i1,1)>keys(i2,1)) return true;
else if (keys(i1,1)==keys(i2,2)) {
if (keys(i1,2)>keys(i2,2)) return true;
}
}
return false;
}
};
template<typename Scalar>
struct min_max {
Scalar min;
Scalar max;
bool init;
KOKKOS_INLINE_FUNCTION
min_max() {
min = 0;
max = 0;
init = 0;
}
KOKKOS_INLINE_FUNCTION
min_max (const min_max& val) {
min = val.min;
max = val.max;
init = val.init;
}
KOKKOS_INLINE_FUNCTION
min_max operator = (const min_max& val) {
min = val.min;
max = val.max;
init = val.init;
return *this;
}
KOKKOS_INLINE_FUNCTION
void operator+= (const Scalar& val) {
if(init) {
min = min<val?min:val;
max = max>val?max:val;
} else {
min = val;
max = val;
init = 1;
}
}
KOKKOS_INLINE_FUNCTION
void operator+= (const min_max& val) {
if(init && val.init) {
min = min<val.min?min:val.min;
max = max>val.max?max:val.max;
} else {
if(val.init) {
min = val.min;
max = val.max;
init = 1;
}
}
}
KOKKOS_INLINE_FUNCTION
void operator+= (volatile const Scalar& val) volatile {
if(init) {
min = min<val?min:val;
max = max>val?max:val;
} else {
min = val;
max = val;
init = 1;
}
}
KOKKOS_INLINE_FUNCTION
void operator+= (volatile const min_max& val) volatile {
if(init && val.init) {
min = min<val.min?min:val.min;
max = max>val.max?max:val.max;
} else {
if(val.init) {
min = val.min;
max = val.max;
init = 1;
}
}
}
};
template<class ViewType>
struct min_max_functor {
typedef typename ViewType::execution_space execution_space;
ViewType view;
typedef min_max<typename ViewType::non_const_value_type> value_type;
min_max_functor (const ViewType view_):view(view_) {
}
KOKKOS_INLINE_FUNCTION
void operator()(const size_t& i, value_type& val) const {
val += view(i);
}
};
template<class ViewType>
bool try_std_sort(ViewType view) {
bool possible = true;
size_t stride[8];
view.stride(stride);
possible = possible && Impl::is_same<typename ViewType::memory_space, HostSpace>::value;
possible = possible && (ViewType::Rank == 1);
possible = possible && (stride[0] == 1);
if(possible) {
std::sort(view.ptr_on_device(),view.ptr_on_device()+view.dimension_0());
}
return possible;
}
}
template<class ViewType>
void sort(ViewType view, bool always_use_kokkos_sort = false) {
if(!always_use_kokkos_sort) {
if(SortImpl::try_std_sort(view)) return;
}
typedef SortImpl::DefaultBinOp1D<ViewType> CompType;
SortImpl::min_max<typename ViewType::non_const_value_type> val;
parallel_reduce(view.dimension_0(),SortImpl::min_max_functor<ViewType>(view),val);
BinSort<ViewType, CompType> bin_sort(view,CompType(view.dimension_0()/2,val.min,val.max),true);
bin_sort.create_permute_vector();
bin_sort.sort(view);
}
/*template<class ViewType, class Comparator>
void sort(ViewType view, Comparator comp, bool always_use_kokkos_sort = false) {
}*/
}
#endif

6
lib/kokkos/containers/src/Kokkos_Bitset.hpp Normal file → Executable file
View File

@ -44,12 +44,8 @@
#ifndef KOKKOS_BITSET_HPP
#define KOKKOS_BITSET_HPP
#include <Kokkos_Macros.hpp>
#include <Kokkos_Core.hpp>
#include <Kokkos_Functional.hpp>
#include <Kokkos_View.hpp>
#include <Kokkos_Atomic.hpp>
#include <Kokkos_HostSpace.hpp>
#include <Kokkos_Pair.hpp>
#include <impl/Kokkos_Bitset_impl.hpp>

27
lib/kokkos/containers/src/Kokkos_DualView.hpp Normal file → Executable file
View File

@ -52,7 +52,7 @@
#ifndef KOKKOS_DUALVIEW_HPP
#define KOKKOS_DUALVIEW_HPP
#include <Kokkos_View.hpp>
#include <Kokkos_Core.hpp>
#include <impl/Kokkos_Error.hpp>
namespace Kokkos {
@ -104,7 +104,7 @@ public:
typedef ViewTraits< DataType , Arg1Type , Arg2Type, Arg3Type > traits ;
//! The Kokkos Host Device type;
typedef typename traits::device_type::host_mirror_device_type host_mirror_device_type;
typedef typename traits::host_mirror_space host_mirror_space ;
//! The type of a Kokkos::View on the device.
typedef View< typename traits::data_type ,
@ -185,8 +185,8 @@ public:
//! \name Counters to keep track of changes ("modified" flags)
//@{
View<unsigned int,LayoutLeft,host_mirror_device_type> modified_device;
View<unsigned int,LayoutLeft,host_mirror_device_type> modified_host;
View<unsigned int,LayoutLeft,host_mirror_space> modified_device;
View<unsigned int,LayoutLeft,host_mirror_space> modified_host;
//@}
//! \name Constructors
@ -198,8 +198,8 @@ public:
/// default constructors. The "modified" flags are both initialized
/// to "unmodified."
DualView () :
modified_device (View<unsigned int,LayoutLeft,host_mirror_device_type> ("DualView::modified_device")),
modified_host (View<unsigned int,LayoutLeft,host_mirror_device_type> ("DualView::modified_host"))
modified_device (View<unsigned int,LayoutLeft,host_mirror_space> ("DualView::modified_device")),
modified_host (View<unsigned int,LayoutLeft,host_mirror_space> ("DualView::modified_host"))
{}
/// \brief Constructor that allocates View objects on both host and device.
@ -226,8 +226,8 @@ public:
#else
, h_view (create_mirror_view (d_view)) // without UVM, host View mirrors
#endif
, modified_device (View<unsigned int,LayoutLeft,host_mirror_device_type> ("DualView::modified_device"))
, modified_host (View<unsigned int,LayoutLeft,host_mirror_device_type> ("DualView::modified_host"))
, modified_device (View<unsigned int,LayoutLeft,host_mirror_space> ("DualView::modified_device"))
, modified_host (View<unsigned int,LayoutLeft,host_mirror_space> ("DualView::modified_host"))
{}
//! Copy constructor (shallow copy)
@ -252,8 +252,8 @@ public:
DualView (const t_dev& d_view_, const t_host& h_view_) :
d_view (d_view_),
h_view (h_view_),
modified_device (View<unsigned int,LayoutLeft,host_mirror_device_type> ("DualView::modified_device")),
modified_host (View<unsigned int,LayoutLeft,host_mirror_device_type> ("DualView::modified_host"))
modified_device (View<unsigned int,LayoutLeft,host_mirror_space> ("DualView::modified_device")),
modified_host (View<unsigned int,LayoutLeft,host_mirror_space> ("DualView::modified_host"))
{
Impl::assert_shapes_are_equal (d_view.shape (), h_view.shape ());
}
@ -280,15 +280,16 @@ public:
/// \endcode
/// and if you want to get the host mirror of that View, do this:
/// \code
/// typedef typename Kokkos::Cuda::host_mirror_device_type host_device_type;
/// typedef typename Kokkos::HostSpace::execution_space host_device_type;
/// typename dual_view_type::t_host hostView = DV.view<host_device_type> ();
/// \endcode
template< class Device >
KOKKOS_INLINE_FUNCTION
const typename Impl::if_c<
Impl::is_same<typename t_dev::memory_space,
typename Device::memory_space>::value,
t_dev,
t_host>::type view () const
t_host>::type& view () const
{
return Impl::if_c<
Impl::is_same<
@ -668,7 +669,7 @@ deep_copy (DualView<DT,DL,DD,DM> dst, // trust me, this must not be a reference
dst.template modify<typename DualView<DT,DL,DD,DM>::device_type> ();
} else {
deep_copy (dst.h_view, src.h_view);
dst.template modify<typename DualView<DT,DL,DD,DM>::host_mirror_device_type> ();
dst.template modify<typename DualView<DT,DL,DD,DM>::host_mirror_space> ();
}
}

Some files were not shown because too many files have changed in this diff Show More