Dear developers,
I am concerned about the time taken to do the heat flux calculation via “compute heat/flux”. Let’s say I have two groups: “all” and “all/2”. The group “all” is what it is with all the atoms in the simulation box and “all/2” has half of the atoms in the simulation box. Does heat flux calculation for both of the groups take the same time? I experienced that it takes the same time though logically, the heat flux calculation for the group “all/2” should take less time. Your valuable insight is much appreciated
Thank you very much.
Chamara
the time spent on compute heat/flux is usually negligible compared to the time it takes to do the simulation of the system, especially to compute the forces.
if you still believe there is some unexplained discrepancy, you have to provide more specific details on what you are exactly comparing to what.
Dear Axel,
Thanks for the immediate response. My goal is to calculate the heat flux in a specific region of the simulation box. But I’m concerned about the time taken and trying to reduce the heat flux calculation time by selecting a small region inside the original region and then performing the heat flux calculation. But it seems whether I’m choosing the whole region or a small part of that, the time taken is almost similar.
However, the frequency I’m taking out the heat flux calculation does really affect the performance. When it is for each and every timestep the performance is like 23ns/day and when the frequency increased 10 times (heat flux calculation per 10 timesteps), performance increased up to about 42ns/day which is almost two times. Then it convers out as frequency further increased.
Thank you very much.
Chamara
Dear Axel,
Thanks for the immediate response. My goal is to calculate the heat flux in a specific region of the simulation box. But I’m concerned about the time taken and trying to reduce the heat flux calculation time by selecting a small region inside the original region and then performing the heat flux calculation. But it seems whether I’m choosing the whole region or a small part of that, the time taken is almost similar.
I already explained why this is the case.
However, the frequency I’m taking out the heat flux calculation does really affect the performance. When it is for each and every timestep the performance is like 23ns/day and when the frequency increased 10 times (heat flux calculation per 10 timesteps), performance increased up to about 42ns/day which is almost two times. Then it convers out as frequency further increased.
This makes no sense unless there are also other changes in your input and/or other issues that limit your preformance. As I already mentioned the heat flux computation part should be a negligible fraction of your total time, regardless of the size of the region you are applying it to.
It is impossible to discuss this in such generality. There likely is some other issue with your input or how you run it that just has some unexpected side effects.
Dear Axel,
I was talking cluelessly and pardon me for that. Here are my case details,
Lammps 24-Dec-2020 in windows with OPENMP multi threading (8 threads). (lmp_serial -in argon.in -pk omp 8 -sf omp)
System consists of simple LJ argon at 40K temperature. (Input script attached: argon.in)
After the equilibration run, I’m just calculating the heat flux via “compute heat/flux” and taking it out via “fix ave/time”. When I change the Nfreq of the time averaging fix, the simulation performance changes significantly as follows.
time averaging fix: “fix AVE all ave/time 1 1 Nfreq c_Hflux[1] c_Hflux[2] c_Hflux[3] ave one file Hflux_AVE.out”
It seems like, when the Nfreq is reduced beyond 50, the pair calculation time and modify time (from the MPI task time break down summary in the log) increases significantly affecting the overall performance. However, after around Nfreq=100, the performance converges as follows.
It is clear that when Nfreq is changed from 1 to 10, the performance gain is more than 2 times. Is this normal or am I doing something wrong? Your kind advice is really appreciated. I have attached the relevant log files as well for the cases of Nfreq=1,2,4,7, and 10.
Thank you. Regards.
Chamara
argon.in (1.84 KB)
log_Nfreq-1.lammps (5.51 KB)
log_Nfreq-4.lammps (5.51 KB)
log_Nfreq-7.lammps (5.51 KB)
log_Nfreq-2.lammps (5.51 KB)
log_Nfreq10.lammps (5.51 KB)
Ok, now here is why there was a misunderstanding.
You wrote that you “increased the frequency” of collecting heat/flux data, but in fact by increasing the value of “nfreq” you are decreasing the frequency.
That in turn makes perfect sense. For computing the heat/flux data you also need to compute the per-atom stress data. This is normally not done during the force computation for efficiency reasons and if needed only on those timesteps where this data is accessed. So by sampling the per-atom stress less frequently, you are speeding up the computation in the pair style by having to compute and collect the per-atom stress data less frequently. Of course, the savings will decrease if you raise the value of nfreq further.
As mentioned before, the main cost is for computing the forces (and the stress from them) and not compute heat/flux in itself, even if it may seem to you like it, because the compute is only post-processing data accumulated during the force computation.
Oh, that’s my bad. I went upside down on the term “frequency”. Thank you very much for your detailed explanation.
Best Regards.
Chamara
