A problem with the file named by variable used to define loop

LAMMPS LAMMPS Mailing List Mirror
1

Hi all lammps makers and users,

There is a problem with the file naming generated in LAMMPS. Latest version of COMB potential (lammps-29Jun12) was used.

In the input, loops are used to generate different ‘a’ value which will be used to name the file. The following is the input:

variable x loop 30
variable a equal 2.00+$x0.001
…
dump 1 all cfg 1 $a..cfg

The file name generated is expected to be

2.001
2.002
2.003
…

However, in fact, they are

2.0009999999999998899.0.cfg
2.0019999999999997797.0.cfg
2.0030000000000001137.0.cfg
…
(star symbol in input “*” will name the files according to the timestep. In this simulation, there is no ‘run’, so * is just .0.cfg)

It is obviously a problem of floating. I used the same input before and this problem did not occur and the file name could be generated properly at that time.

Does the linux OS matter? Is there anybody else who suffered from this problem?

Best regards,

2

Hi all lammps makers and users,

There is a problem with the file naming generated in LAMMPS. Latest version
of COMB potential (lammps-29Jun12) was used.

In the input, loops are used to generate different 'a' value which will be
used to name the file. The following is the input:

variable x loop 30
variable a equal 2.00+$x*0.001
...
dump 1 all cfg 1 $a.*.cfg

The file name generated is expected to be

2.001
2.002
2.003
...

However, in fact, they are

2.0009999999999998899.0.cfg
2.0019999999999997797.0.cfg
2.0030000000000001137.0.cfg
...
(star symbol in input "*" will name the files according to the timestep. In
this simulation, there is no 'run', so * is just .0.cfg)

It is obviously a problem of floating. I used the same input before and this
problem did not occur and the file name could be generated properly at that
time.

Does the linux OS matter? Is there anybody else who suffered from this
problem?

this has nothing to do with linux. the precision of the
expansion of variables was changed a while ago.
the problem is, that the numbers you generate are
not exactly representable floating point. with the
lower precision output, it would have been rounded,
with the higher precision now not anymore.

axel.