Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Julian Schneider

Pages: 1 ... 6 7 [8] 9 10 11
106
The mixing of elements in EAM potentials is generally pretty good, although it always depends  on the particular element and potential. I don't see any principle reason why the EAM_Zhou_2004 should not not be suited to model the diffusion in such an array. But without knowing the exact elements, I would suggest that you make some benchmark calculations on a small test system against DFT, to see whether it works sufficiently well for your elements.  In general, EAM should be a lot better than Tersoff to simulate diffusion, as Tersoff (e.g., used for Carbon) can have unphysically large bond-breaking-barriers.

Yes, the approach to simulate diffusion into the deposited layer would be to couple the substrate to a thermostat and simulate the deposited atoms in NVE, as described in the vapor deposition tutorial.
If you don't see any diffusion into the deposited layer during the deposition simulation, you could separate the deposition and diffusion simulation, meaning that you stop the deposition when the layer has reached a sufficient thickness, and then you set up a constant temperature simulation where you couple the entire surface to a thermostat and run it for a long time.
However, practically, the time scale of MD might still be too short if the diffusion process is associated with high barriers. In that case you could try an adaptive kinetic Monte Simulation (AKMC).


107
General Questions and Answers / Re: VNL for LAMMPS
« on: April 7, 2016, 09:51 »
The problem is that in your log.lammps file, for some reason there are some steps missing between step 260 and 410.
It says

     200    834.82705   -445.10589   -5704.2444   -5488.5326
     210     879.3483   -172.38307   -5712.4813   -5485.2655
     220    922.65357    292.58809   -5720.4329   -5482.0275
     230    937.39042     -62.6088   -5721.3306   -5479.1173
     240    948.08463   -244.98762   -5721.6675    -5476.691
     250    966.14585    442.59564   -5724.4679   -5474.8245
     260    962.51755    581.39448   -5722.3955   -5473.6896      410    827.36123    -897.4114   -5746.4231   -5532.6403
     420    834.65009    31.459134   -5754.7381    -5539.072
     430    821.39706    887.94195   -5758.0841   -5545.8425
     440    777.86776   -258.69939   -5753.6548   -5552.6607

Then, of course the plugin can't find as many energy entries as snapshots in the trajectory, and that's why the error is raised.
I don't know why that happens, but maybe you ran several LAMMPS simulations simultaneously, which wrote to the same logfile.
Try and run the LAMMPS simulation again, and see if the error still persists.
I have attached the log file that I get when I run your simulation and with that logfile everything works fine.

108
I think the time step is not the problem here. You might try 0.5 fs, but even 1 fs might be ok for elements like these.
The wavy nature is probably visually enhanced by the thin dimension of the system, but it doesn't seem unusual at this temperature.

You can get a stable equilibration using the following approach (see attached script):
1. Geometry optimization at constant stress (the off-diagonal lattice components might be slightly non-zero afterwards, they should be reset to zero)
2. Langevin NVT MD at 1200 K
3. NPT simulation at 1200 K


109
I would not recommend the approach to start from 0K, and then use a large coupling constant to slowly increase the temperature, especially not for Nose-Hoover-based thermostats, such as NPT-Melchionna. The problem with these thermostats is that the temperature does not approach the target temperature exponentially, but instead oscillates around the target temperature with an amplitudes that is, at least in the beginning, proportional to the difference between actual temperature (i.e. 0K) and target temperature (i.e. 1200 K). That means the temperature might at some point overshoot the target temperature by a considerable amount, which can destabilize the system. Instead, I recommend to use the NVT-Nose-Hoover-Chain-thermostat where you can set an initial and a final temperature, which linearly changes the target temperature from one to the other value during the simulation (while keeping the thermostat_timescale reasonably low at ~100 fs). Unfortunately, this is currently only possible for NVT and not NPT (in ATK-2016 it will be possible for all thermostats and barostats).
The error message that you encounter, though, has nothing to do with this. This might be a problem that we sometimes encounter if the trajectory is saved too often. You can try increasing the log_interval parameter to, say 500 steps and check if the problem still persists.

110
Currently, this is not possible in AKMC. There is no way to influence which path the system can take.
One may think of adding a bias potential for example, which pushes the atom inside the surface, but such things might be possible from the next ATK-release at earliest.

111
1) To what "published value" did you compare your results for the silver grain boundary? To the experimental value, to another simulation study for this particular system, or to the value for the silicon grain boundary?
2) The 2011 Sheng potential should generally work fine to describe the phononic part of the thermal conductivity. But you can make a check yourself by calculating the phonon bandstructure using the potential and compare to experiment or higher-level calculations.
3) Of course, ATK-Classical does not account for the electronic contribution to thermal transport, and, since the electronic contribution can make up a large part of the total thermal conductivity in metallic systems, the simulated value may be considerably lower than the experimental value of such a system.
You can calculate both phononic and electronic conductance using the NEGF-method, as explained in the tutorial http://docs.quantumwise.com/tutorials/thermoelectrics_cnt_isotope.html
4) In principle it is not suspicious, that your transferred energy is lower than in the silicon example. This value depends on the many factors, e.g. the cross-sectional-area of the system, and of course also the thermal conductance itself. You can try and tune it by changing the parameter "Exchange interval". By decreasing this parameter the transferred energy per time should increase.

112
Unfortunately, it looks like the ReaxFF-potentials are not suited for your system, so VNL does not provide a pre-defined potential for your system.
So, you'd either need to use DFT, or you could try searching the literature, to see if there is another potential, which may be suited for your system.
Then, we can check if this potential can easily be implemented in VNL, and in that case provide the potential as a script.

113
This is  a problem that sometimes occurs when you choose one the ReaxFF potentials in ATK-Classical.
Essentially, it means that some of the bonds in your configuration are not supported by the potential.
If possible, you should try selecting a different potential for your system, e.g. one of the Tersoff or EAM-potentials.

114
This method essentially does the same as the "Temperature Profile" analysis in the MDAnalyzer tool.
So if you set up your momentum-exchange-hook as

Code
momentum_exchange_hook = NonEquilibriumMomentumExchange(
    configuration=bulk_configuration,
    exchange_interval=100,
    heat_source='right',
    heat_sink='left',
    update_profile_interval=20,
    profile_resolution=2.0*Ang
)

To activate the calculation of the temperature profile make sure that the update_profile_interval is larger than zero, as this value determines how often the temperature profile is sampled.
Via the parameter profile_resolution the bin width of the temperature profile can be set.

Then, after the simulation has finished, you can query the temperature profile via

Code
(z_values, t_profile) = momentum_exchange_hook.temperatureProfile()

It will give you two PhysicalQuantity arrays z_values and t_profile, which you for example can plot it using pylab

Code
import pylab

pylab.plot(z_values.inUnitsOf(Ang), t_profile.inUnitsOf(Kelvin))
pylab.show()

or process the data in any other way you want.

However, I would recommend to use the corresponding feature in the MDAnalyzer, as this allows you to specify a start time which makes it easier to check for convergence of the profile.

115
The EAM potential used in the PRB paper you mention, is already implemented as EAM_Zhou_2004 .
The modified EAM (MEAM) potential will hopefully be implemented soon.

116
Could you maybe give a more specific example of what you are interested in?

For molecular compounds, if you already have an idea how the dissociation reaction will look like, you could perform an NEB calculation of this reaction using DFT.
Then you could use the harmonic transition state theory (HTST event) analysis to obtain the reaction rate at different temperatures and from that estimate the temperature at which the reaction becomes likely to occur.
But for solids it might be more complicated. In principle running a molecular dynamics simulation while slowly increasing the temperature until you see dissociation, might give you an idea about the dissociation temperature, although very likely a bit overestimated.
 However, to get the reactions right, you'd probably have to use DFT (unless you have a really good reactive potential that describes the specific reaction you are interested in), and that would severely limit the time scale of the simulation.

117
General Questions and Answers / Re: Molecular Dynamics Error
« on: January 26, 2016, 10:23 »

1) Langvin MD
 
In results i got one device configuration file and one MD trajectory file. In MD trajectory file I got following results, PFA. can you tell me what does it signify and what does it optimize?


MD does not optimize anything. It generates a number of snapshots drawn from a canonical ensemble. Note that different snapshots of the same MD simulation may yield different results for the same property. That means that a single snapshot from an MD trajectory not may be too meaningful, but it is rather the average over many snapshots that should be considered.
In your case you have simulated only over a very short time span and the system has very likely not had enough time to reach thermal equilibrium. This is the reason why the molecule looks a bit strange.
Please read the tutorial about MD simulations (www.docs.quantumwise.com/tutorials/md_basics.html) to learn more about how to equilibrate a system.


2) Geometry Optimization

In results i got two device configuration files and when i drag .nc file into stash it generated two device structure there. Then I checked their coordinates and i found that two device structures have different coordinates. Do you think that changed coordinates are geometry optimized one. Also I checked it for only 10 steps, do you think that increasing steps will give much better results.

The first of the two configuration is the initial structure of the device, whereas the second one is the structure after optimizing the geometry, i.e. minimizing the total energy. They should have different coordinates, as the atomic positions change during the optimization. That means the second configuration is the one to use.
In geometry optimization the decisive criteria is not the number of steps but the max. force parameter, which sets the threshold that the optimization stops as soon as the forces on all atoms are below this value. The default value of 0.05 eV/Ang is generally ok, for a very precise optimization it should be decreased, though.
The number of steps is only a parameter that prevents that an  optimization simulation runs forever if it for some reason doesn't manage to converge.

In your case, you should check at the end of the log file, if the optimization has converged, i.e. if all forces are below the specified max. force value. There will be a line which informs you about this.

118
General Questions and Answers / Re: Molecular Dynamics Error
« on: January 19, 2016, 15:14 »
Yes, you are right, you are using DFT so the forces are probably not totally wrong.
I made some tests, and it looks as if the problem is that you initially have quite large forces on the atoms of the molecule, as the molecule is a little compressed (it expands quite a bit if you optimize the molecule alone).
That means that in the beginning of your MD the large forces accelerate the atoms in the molecule away from the center of the molecule.
Then you use zero initial velocities (initial_velocities=None). As the average temperature is below the target temperature of 300K the thermostat additionally accelerates the atoms in order to reach the target temperature. This will cause that the atoms of the molecule will be driven apart even further, and for a moment it looks as if the bonds are broken.
However, remember that the bonds in the viewer are just a graphical representation based on the atom distance, and it doesn't necessarily mean that the bonds really are broken. If you'd continue the MD for longer times they'd very likely find their equilibrium bond lengths in the end.
To prevent this effect, I suggest you use the Langevin thermostat instead of the NVT Berendsen thermostat. The Langevin  thermostat couples each atom more tightly to the heat bath and the friction force prevents that atoms become accelerated to much (see the MD tutorial http://www.docs.quantumwise.com/tutorials/md_basics.html).

119
General Questions and Answers / Re: Molecular Dynamics Error
« on: January 14, 2016, 10:45 »
It is generally not recommended to perform MD simulations at constant pressure (i.e. NPT simulations) on DeviceConfigurations, especially not NPTBerendsen, (see last paragraph in the MD tutorial www.docs.quantumwise.com/tutorials/md_basics.html). You should use constant volume simulations (i.e. NVE or NVT) instead.
If you want to optimize the cell of the device with respect to the stress you should adopt the scheme outlined in the device relaxation tutorial (www.docs.quantumwise.com/tutorials/device_relaxation.html).
However, it should technically be possible to run NPT on a device configuration, and the error you see seems to be a bug, which we'll fix.

120
From the missing energy data in the MovieTool, I suppose the corresponding LabFloor item is a Trajectory instead of an MDTrajectory object, correct?

From the input file you posted everything looks ok, and the LAMMPS trajectory should be loaded as an MDTrajectory.
It is difficult to find the error without more information or the remaining files.
Is the original "pt-pd.data" file present in the current directory?
Are the atoms in the MovieTool displayed as the correct elements?
Did you rename any of the output files?



Pages: 1 ... 6 7 [8] 9 10 11