Data initialization commands. More...
|Tests if the system has been initialized. More...|
|Resets all hoomd_script variables. More...|
|Create an empty system. More...|
|Reads initial system state from an XML file. More...|
|Reads initial system state from a binary file. More...|
|Generates N randomly positioned particles of the same type. More...|
|Generates any number of randomly positioned polymers of configurable types. More...|
|Initializes the system from a snapshot. More...|
Data initialization commands.
Commands in the init package initialize the particle system. Initialization via any of the commands here must be done before any other command in hoomd_script can be run.
- See Also
- Quick Start Tutorial
Create an empty system.
N Number of particles to create box A 3-tuple of floats specifying the box lengths (Lx, Ly, Lz) (in distance units) n_particle_types Number of particle types to create n_bond_types Number of bond types to create n_angle_types Number of angle types to create n_dihedral_types Number of dihedral types to create n_improper_types Number of improper types to create
After init.create_empty returns, the requested number of particles will have been created but all of them will have DEFAULT VALUES and further initialization MUST be performed. See hoomd_script.data for full details on how such initialization can be performed.
Specifically, all created particles will be:
- At position 0,0,0
- Have velocity 0,0,0
- In box image 0,0,0
- Have the type 'A'
- Have charge 0
- Have a mass of 1.0
Furthermore, as a current limitation in the way create_empty works the defined particle type names are: 'A', 'B', 'C', ... up to n_particle_types types. An intuitive way for resetting these types to user-defined ones will come in a future enhancement.
- The resulting empty system must have its particles fully initialized via python code, BEFORE any other hoomd_script commands are executed. As as example of what might go wrong, if the pair.lj command were to be run before the initial particle positions were set, all particles would have position 0,0,0 and the memory initialized by the neighbor list would be so large that the memory allocation would fail.
- See Also
Generates N randomly positioned particles of the same type.
N Number of particles to create phi_p Packing fraction of particles in the simulation box (unitless) name Name of the particle type to create min_dist Minimum distance particles will be separated by (in distance units)
N particles are randomly placed in the simulation box. The dimensions of the created box are such that the packing fraction of particles in the box is phi_p. The number density n is related to the packing fraction by \(n = 6/\pi \cdot \phi_P\) assuming the particles have a radius of 0.5. All particles are created with the same type, given by name.
Generates any number of randomly positioned polymers of configurable types.
box BoxDim specifying the simulation box to generate the polymers in polymers Specification for the different polymers to create (see below) separation Separation radii for different particle types (see below) seed Random seed to use
Any number of polymers can be generated, of the same or different types, as specified in the argument polymers. Parameters for each polymer include bond length, particle type list, bond list, and count.
The syntax is best shown by example. The below line specifies that 600 block copolymers A6B7A6 with a bond length of 1.2 be generated.
Here is an example for a second polymer, specifying just 100 polymers made of 5 B beads bonded in a branched pattern
The polymers argument can be given a list of any number of polymer types specified as above. count randomly generated polymers of each type in the list will be generated in the system.
- bond_len defines the bond length of the generated polymers. This should not necessarily be set to the equilibrium bond length! The generator is dumb and doesn't know that bonded particles can be placed closer together than the separation (see below). Thus bond_len must be at a minimum set at twice the value of the largest separation radius. An error will be generated if this is not the case.
- type is a python list of strings. Each string names a particle type in the order that they will be created in generating the polymer.
- bond can be specified as "linear" in which case the generator connects all particles together with bonds to form a linear chain. bond can also be given a list if python tuples (see example above).
- Each tuple in the form of
(a,b) specifies that particle
aof the polymer be bonded to particle
b. These bonds are given the default type name of 'polymer' to be used when specifying parameters to bond forces such as bond.harmonic.
- A tuple with three elements (a,b,type) can be used as above, but with a custom name for the bond. For example, a simple branched polymer with different bond types on each branch could be defined like so:
- Each tuple in the form of
separation must contain one entry for each particle type specified in polymers ('A' and 'B' in the examples above). The value given is the separation radius of each particle of that type. The generated polymer system will have no two overlapping particles.
With all other parameters the same, create_random_polymers will always create the same system if seed is the same. Set a different seed (any integer) to create a different random system with the same parameters. Note that different versions of HOOMD may generate different systems even with the same seed due to programming changes.
- 1. For relatively dense systems (packing fraction 0.4 and higher) the simple random generation algorithm may fail to find room for all the particles and print an error message. There are two methods to solve this. First, you can lower the separation radii allowing particles to be placed closer together. Then setup integrate.nve with the limit option set to a relatively small value. A few thousand time steps should relax the system so that the simulation can be continued without the limit or with a different integrator. For extremely troublesome systems, generate it at a very low density and shrink the box with the command update.box_resize to the desired final size.
- 2. The polymer generator always generates polymers as if there were linear chains. If you provide a non-linear bond topology, the bonds in the initial configuration will be stretched significantly. This normally doesn't pose a problem for harmonic bonds (bond.harmonic) as the system will simply relax over a few time steps, but can cause the system to blow up with FENE bonds (bond.fene).
- 3. While the custom bond list allows you to create ring shaped polymers, testing shows that such conformations have trouble relaxing and get stuck in tangled configurations. If you need to generate a configuration of rings, you may need to write your own specialized initial configuration generator that writes HOOMD XML input files (see XML File Format). HOOMD's built-in polymer generator attempts to be as general as possible, but unfortunately cannot work in every possible case.
Tests if the system has been initialized.
Returns True if a previous init.create* or init.read* command has completed successfully and initialized the system. Returns False otherwise.
Reads initial system state from a binary file.
filename File to read
All particles, bonds, etc... are read from the binary file given, setting the initial condition of the simulation. Binary restart files also include state information needed to continue integrating time forward as if the previous job had never stopped. For more information see dump.bin.
After this command completes, the system is initialized allowing other commands in hoomd_script to be run.
The presence or lack of a .gz extension determines whether init.read_bin will attempt to decompress the data before reading it.
- init.read_bin is deprecated. It currently maintains all of its old functionality, but there are a number of new features in HOOMD-blue that it does not support.
- Triclinic boxes
- See Also
Initializes the system from a snapshot.
snapshot The snapshot to initialize the system from
Snapshots temporarily store system data. Snapshots contain the complete simulation state in a single object. They can be used to start or restart a simulation.
Example use cases in which a simulation may be started from a snapshot include user code that generates initial particle positions.
- Snapshots do not yet have a python API, so they can only be generated by C++ plugins. A future version of HOOMD-blue will allow fast access to snapshot data in python.
- See Also
Reads initial system state from an XML file.
filename File to read time_step (if specified) Time step number to use instead of the one stored in the XML file
All particles, bonds, etc... are read from the XML file given, setting the initial condition of the simulation. After this command completes, the system is initialized allowing other commands in hoomd_script to be run. For more details on the file format read by this command, see XML File Format.
All values are read in native units, see Units for more information.
If time_step is specified, its value will be used as the initial time step of the simulation instead of the one read from the XML file.
- See Also
Resets all hoomd_script variables.
- There is a very important memory management issue that must be kept in mind when using reset(). If you have saved a variable such as an integrator or a force for changing parameters, that saved object must be deleted before the reset() command is called. If all objects are not deleted, then a memory leak will result causing repeated runs of even a small simulation to eventually run the system out of memory. reset() will throw an error if it detects that this is the case.
- When using the python data access in hoomd scripts, iterators must also be deleted