When it comes to HNEMD and NEMD examples in GPUMD example folder,
I found that the number of atoms in xyz.in file and the compute_shc command
of HNEMD and NEMD are different each other.
They do not need to be of the same size. This is just an example, and to
reduce the computation time of the HNEMD simulation, I used a smaller size
for it. I don't want the user to wait for a long time to get the results in
these tutorials.
NEMD -> compute_shc 2 250 1 1000 400.0 group 0 4
-> xyz.in 40400
HNEMD -> compute_shc 2 250 1 1000 400.0 group 0 0
-> xyz.in 24000
Here, in the NEMD simulation, what is important is that one should not
compute the SHC for group 0, which will be fixed. I choose group 4 because
it is close to the center of the sample. In the HNEMD simulation, no group
will be fixed, and one can choose any group to compute the SHC. One can
also define groups with non-uniform sizes. The important thing is that SHC
computation requires a significant amount of memory (similar to DOS
computation), but the memory usage in v2.5.1 is already
significantly reduced compared to v2.4.1. You can use nvidia-smi to check
the memory usage during your run.
Computing SHC for a smaller group can reduce memory usage and computation
time, but the statistical accuracy will be reduced due to less spatial
average. So you need to try it out to gain experiences about the "optimal"
group size.
Zheyong
On Fri, Oct 16, 2020 at 6:46 AM "소순성" <soonsung2001@xxxxxxxxxx> wrote:
Thank you for kind answer.
It will be really helpful comments for me!
I have another question.
When it comes to HNEMD and NEMD examples in GPUMD example folder,
I found that the number of atoms in xyz.in file and the compute_shc
command of HNEMD and NEMD are different each other.
NEMD -> compute_shc 2 250 1 1000 400.0 group 0 4
-> xyz.in 40400
HNEMD -> compute_shc 2 250 1 1000 400.0 group 0 0
-> xyz.in 24000
I wonder there are special reasons for that.
If the same logic can be applied to the large system I considered,
can I adjust 'compute_shc' command to 'group 0 0' in HNEMD to save
computational time?
--------- 원본 메일 ---------보낸사람 : Bruce Fan <brucenju@xxxxxxxxx>
받는사람 : <gpumd@xxxxxxxxxxxxx>
받은날짜 : 2020/Oct/15(Thu) 18:02:25
제목 : [gpumd] Re: Large size NEMD simulation.
1. Your results look reasonable. Within 10 nanosecond, your huge system is
far from reaching a steady state. It may require 100 nanosecond.
2. In the beginning, the rates of energy change in source and sink regions
can be different because the system is still in a transient state. The sink
part has larger rate of energy chage, because the local thermal
conductivity (or diffusivity) is larger there due to lower temperature.
3. You are calculating the SHC for group 0, which is fixed (freezed). This
is not a wise choice. You can make your groups smaller and number of groups
larger, and calculate SHC for any group other than group 0. You can
minimize the size of group 0, to minimize the waste of computing time.
4. Your other 8 groups are of the same size, with 4 micron for each. This
means you have 8 microns for source and sink regions and only 24 microns
for the "sample". You can make the source and sinl3 regions smaller to make
your "sample" longer.
5. You set the cutoff to 3 A and maximum neighbor to 10. This just wates
memory and time. Change them to 2.1 A and 3, repectively!
6. You are brave to consider this huge size. Good luck!
Zheyong
"소순성" <soonsung2001@xxxxxxxxxx> 于 2020年10月14日周三 07:13写道：
Thank you Zheyong Fan for using this good GPUMD program.
I have questions of this week.
I tested the NEMD calculation of very large size of graphene sheet,
(20nm x 30micro, about 22 million C atoms, x,z free boundary and y
periodic boundary, and biased in y direction.)
and found that the degree of energy of the thermostat coupling to the heat
sink region which is increasing is different with that to the sink region.
The absolute values of the slopes of the lines are different although
total energy seems stable.
It is my run.in file and I attached the part of information (It is
continuing because of very large size calculation!)
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
potential
/GPUMD-2.5.1/potentials/tersoff/Graphene_Lindsay_2010_modified.txt 0
velocity 300
ensemble nvt_ber 300 300 0.005
fix 0
time_step 0.5
dump_thermo 1000
run 2000000
# production
ensemble heat_lan 300 500 100 1 8
fix 0
compute 0 100 10 temperature
compute_shc 2 250 1 1000 500.0 group 0 0
dump_position 1000000
dump_thermo 1000
run 20000000
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Number of atoms is 22816728.
Maximum number of neighbors is 12.
Initial cutoff for neighbor list is 3 A.
Use orthogonal box.
Do not specify initial velocities here.
Have 1 grouping method(s).
Box lengths are
Lx = 1.9926000000e+02 A
Ly = 2.9999772000e+05 A
Lz = 3.3540000000e+00 A
Use free boundary conditions along x.
Use periodic boundary conditions along y.
Use free boundary conditions along z.
There are 9 groups of atoms in grouping method 0.
136728 atoms in group 0.
2835000 atoms in group 1.
2835000 atoms in group 2.
2835000 atoms in group 3.
2835000 atoms in group 4.
2835000 atoms in group 5.
2835000 atoms in group 6.
2835000 atoms in group 7.
2835000 atoms in group 8.
There is only one atom type.
22816728 atoms of type 0.
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
How can I interpret it? (Is it right simulation?)
Did the number of atoms in group 0 affect to the result?
Soonsung.
