You need to copy the list on reply.

Hello again,

-on Windows 7 Enterprise we have lmp_mpi dated to 15 May 15, on Linux Debian we have lmp_mpi dated to the latest version (11 Aug 17)

- calculating thermal conductivity of pure water with TIP5P rigid model
- on Windows we get 0.63 W/mK with a std of 0.02-0.03, on Linux we get 0.85 W/mK with a std of 0.02-0.03 (experimental value is 0.60 W/mK )
- sampling time is 20 ps and yes we can rule out them.

with another water models (TIP3P,etc.) which are not rigid, I get almost same results from both machines, so I’ve started to believe that there may be something different about the rigid algorithm of GK in two systems, but this is just my guess after checking everything.

Hello again,

-on Windows 7 Enterprise we have lmp_mpi dated to 15 May 15, on Linux

Debian we have lmp_mpi dated to the latest version (11 Aug 17)

There's a two year difference in those versions. Have you checked the

change log to see if a bug related to these calculations has been fixed,

changed have been made to the algorithm, etc?

- calculating thermal conductivity of pure water with TIP5P rigid model

- on Windows we get 0.63 W/mK with a std of 0.02-0.03, on Linux we get

0.85 W/mK with a std of 0.02-0.03 (experimental value is 0.60 W/mK )

It's hard to compare Windows vs. Linux if you are running two different

versions of LAMMPS.

- sampling time is 20 ps and yes we can rule out them.

with another water models (TIP3P,etc.) which are not rigid, I get almost

same results from both machines, so I've started to believe that there may

be something different about the rigid algorithm of GK in two systems, but

this is just my guess after checking everything.

TIP3P most certainly is a rigid water model unless you are specifying it

not to be.

Yes I’ve checked, and by the way the older version measures it much better than the latest version.

Yes I've checked, and by the way the older version measures it much better

than the latest version.

emir,

you seem to be mixing up two things here: getting the expected result and

getting the correct result for the model and method at hand.

i know from personal experience, how many bugs and problematic issues were

fixed in LAMMPS over the last 2 years since we started to systematically

use code analysis and code review tools. also, unless you compiled your

LAMMPS binaries yourself, please note, that the precompiled LAMMPS windows

binaries from two years ago were based on an experimental fork of LAMMPS

with additional changes and potentially additional bugs. current windows

binaries for LAMMPS are built from the *exact* same sources.

it is for certain a misguided approach to declare a version of a software

"better" solely based on how well its output agrees with your expectations.

moreover, the same version of the same software *has* to produce the *same*

results. mind you, that doesn't mean *identical*, but with the same

*statistical certainty*.

now, since you are using a statistical mechanical method, statistical

certainty is a key issue here.

i recall you mentioning a time span of 20ps somewhere. is that the total

simulation time? or the total time of data accumulation? or something else?

20ps would be rather short for total simulation time. it would even be

little for equilibration. as a rule of the thumb you can assume that for

typical bulk water systems, you need a space of the order of 1ps between

two configurations for them to be mostly statistically independent. if you

are looking at data collected more frequently (as is often needed), you

have to factor in, that your statistical relevance is reduced and the

statistical certainty much less than what a computed standard deviation

would suggest. to get a handle on that you need to review and compare

multiple independent and uncorrelated data sets.

this also means, that it is irrelevant for the statistical certainty (and

thus the reliability of your results), whether those results agree with

experiment. they must agree with what the model represents. especially in

the case of water, different models represent experiment different

thermodynamical properties differently well compared to experiment, so it

is quite possible that your "better" result is actually worse, i.e. if it

agrees better with the experimental result for the wrong reason and that

the "worse" result is in keeping with the model.

please also keep in mind, that codes using floating point math will

produce different trajectories due to floating point math being not

associative, i.e. the order of operations has an impact on the exact

(bitwise) result and then trajectories will be equivalent, but also

diverging exponentially. this can happen with having different OS,

hardware, number of parallel processes, code path (multi-thread vs. MPI vs.

GPU). all of these differences should eventually converge to the same

result, provided your trajectories contain a sufficiently representative

subset of the total phase space (i.e. you have achieved ergodicity).

so my recommendation is to reduce the degrees of freedom in what you are

looking at and pick one version and determine what the statistical

certainty (or relevance) of your results is and adapt your simulation time

and other sampling parameters until you can say with confidence, that your

numbers are sufficiently well converged.

only then, you can look into whether you find differences between different

versions of LAMMPS or between different platforms (that means, your

comparison of windows vs. linux is useless unless you have results of

comparable and meaningful quality for both versions of LAMMPS on both

platforms).

finally, you should hit the literature and research, if somebody has

already done a similar study to identify the same thermodynamic properties

for the same water models. it is more important to compare to those than to

compare to experiment. comparison to experiment should only be done, after

simulation results are confirmed beyond doubts. what you have told us so

far, does not provide that level of confirmation.

axel.

Also, I don’t know of a TIP5P water model in LAMMPS.

TIP4P yes, 5P no.

Steve

Also, I don't know of a TIP5P water model in LAMMPS.

TIP4P yes, 5P no.

the tip4p styles are an optimization.

you can easily implement TIP4P or TIP5P and many other rigid water models

using the regular coulomb pair styles with fix rigid.

axel.

Hi Axel,

20 ps was dump interval of auto-correlation function (ACF) that we were using. It is the ‘d’ value of the sample code in the following link.

http://lammps.sandia.gov/doc/compute_heat_flux.html

However, we thought that there might be random noise associated with the ACF, and reduced dump interval to 1 ps by following the procedure of

Chen, Zhang, Baowen, “How to improve the accuracy of equilibrium molecular dynamics for computation of thermal conductivity?” Physics Letters (2010)

Now we use Green-Kubo (GK) parameters of s=2, p=500, d=1000 (w.r.t notation of the sample GK code above), and run preliminary simulations with 100 ps NPT equilibration + 100 ps NVE equilibration + 100 ps NVE production run. So the production run now includes 100 different ACFs, and corresponding thermal conductivity (k) values. We tested LAMMPS versions, machines, and number of processors(NoP) in the first place and surprisingly (at least for me), we observed significant effect of NoP for both machines with different versions. The k values are generally converging for the last 40 data (out of 100 in the production run), and giving standard deviation in the order of 0.01 after that).

We believe that we can solve issues for GK parameters by extending our literature analysis at some point, as you suggested (This may not be a LAMMPS topic anyways). However, first we need to resolve this problem (if you want to call it like this) about parallel computing as it may suppress any effect on GK that we may want to see. So we are curious about your comments about the table above, if it is a bug, or our mistake in implementation etc. Thanks for helping.

Emir

Hi Axel,

sorry for the delayed reply. busy days these days.

20 ps was dump interval of auto-correlation function (ACF) that we were

using. It is the 'd' value of the sample code in the following link.LAMMPS Molecular Dynamics Simulator

However, we thought that there might be random noise associated with the

ACF, and reduced dump interval to 1 ps by following the procedure ofChen, Zhang, Baowen, "How to improve the accuracy of equilibrium molecular

dynamics for computation of thermal conductivity?" Physics Letters (2010)Now we use Green-Kubo (GK) parameters of s=2, p=500, d=1000 (w.r.t

notation of the sample GK code above), and run preliminary simulations with

100 ps NPT equilibration + 100 ps NVE equilibration + 100 ps NVE production

run. So the production run now includes 100 different ACFs, and

corresponding thermal conductivity (k) values. We tested LAMMPS versions,

machines, and number of processors(NoP) in the first place and surprisingly

(at least for me), we observed significant effect of NoP for both machines

with different versions. The k values are generally converging for the last

40 data (out of 100 in the production run), and giving standard deviation

in the order of 0.01 after that).We believe that we can solve issues for GK parameters by extending our

literature analysis at some point, as you suggested (This may not be a

LAMMPS topic anyways). However, first we need to resolve this problem (if

you want to call it like this) about parallel computing as it may suppress

any effect on GK that we may want to see. So we are curious about your

comments about the table above, if it is a bug, or our mistake in

implementation etc. Thanks for helping.

i think you are - again - jumping to conclusions prematurely with too

little data to back it up. in particular:

- you have too few data points to draw any conclusions about a dependency

on the number of CPUs

- you don't have a large enough variety of the number of CPUs. if there was

a trend, you would do something like a sequence of 1, 2, 4, 8, 12, 16, 20,

24, 27, 32, 36, 42, 48, 64

- i am very irritated by the fact, that you switch from claiming, that

there is a problem on Linux to claiming, that there is a problem with

parallel runs without having even settled the first issue. as i have told

you, the very minimum to prove or to rule out a platform dependency is to

also run the old version on Linux and the new version on Windows.

- your observation about convergence strongly suggests, that your

simulation is not properly equilibrated. also, your descriptions seem to

suggest that you only are comparing data from within the same run, but not

between independent, decorrelated runs. these should be done from the same

input, but with different random number seeds and *before* running with NPT

(it is almost always a bad idea to run NPT first, if your system by chances

expands, it will expand too much and it can take *extremely* long to reach

the equilibrium density due to jamming), you should run initially for a

sufficient while at fixed volume with a dissipative thermostat like

temp/csld or langevin.

- in fact, in order to have reproducible results, you should not be running

at whatever volume is the final volume of the NPT run, but the average

volume after the NPT system is sufficiently equilibrated. for any dense

fluid, i would expect that rather small changes in volume can have a

measurable impact on its properties.

- with that in mind, i have to wonder, why running with NPT at all. it

would be sufficient to determine the equilibrium volume/density once and

then just set up simulations at that density with fixed volume. that'll

make it much easier to control the environment and obtain consistent

results. or else you'll have a much better argument that there may be a

problem.

in short,

1) you need to decide what you are trying to prove here

2) you need to be more diligent in testing for and obtaining equilibrium

3) you need to provide *much* more convincing data and specifically prove

that you get the same result from *indepenent* _and_ *decorrelated*

starting conditions (after equilibration).

axel.