in fix_temp_rescale.cpp (l:137), an error

condition halts the program if the result of

t_current = temperature->compute_scalar();

is zero in "FixTempRescale::end_of_step()", which

will always happen if the number of atoms in the

fix temp/rescale group is zero.

In gcmc runs at very low density or at the start

of runs with zero "molecules of interest", this

condition might be met but should not be seen

as an error.

Therefore, with new builds for gcmc runs I modify

fix_temp_rescale.cpp

from

135: double t_current = temperature->compute_scalar();

if (t_current == 0.0)

error->all(FLERR,"Computed temperature for fix temp/rescale cannot be 0.0");

to:

135: double t_current = temperature->compute_scalar();

if (t_current == 0.0) {

error->warning(FLERR,"Computed temperature for fix temp/rescale cannot be 0.0");

return;

}

I tried to understand the program flow within FixTempRescale but

could not find any problems with this approach. So I'd like to

put this topic on display and ask for clarification: can such

a change be made permanent - maybe as an option? Or - is there

some drawback which I didn't see?

thanks & regards

M.

in fix_temp_rescale.cpp (l:137), an error

condition halts the program if the result of

t_current = temperature->compute_scalar();

is zero in "FixTempRescale::end_of_step()", which

will always happen if the number of atoms in the

fix temp/rescale group is zero.

In gcmc runs at very low density or at the start

of runs with zero "molecules of interest", this

condition might be met but should not be seen

as an error.

Therefore, with new builds for gcmc runs I modify

fix_temp_rescale.cpp

from

135: double t_current = temperature->compute_scalar();

if (t_current == 0.0)

error->all(FLERR,"Computed temperature for fix temp/rescale

cannot be 0.0");

to:

135: double t_current = temperature->compute_scalar();

if (t_current == 0.0) {

error->warning(FLERR,"Computed temperature for fix temp/rescale

cannot be 0.0");

return;

}

I tried to understand the program flow within FixTempRescale but

could not find any problems with this approach. So I'd like to

put this topic on display and ask for clarification: can such

a change be made permanent - maybe as an option? Or - is there

some drawback which I didn't see?

there is one problem with this approach: if you actually *have* atoms in

the selection and will try to rescale, you will get a devision by zero

error and then a crash or you have invalid numbers in your

velocities/positions, which will make the simulation meaningless.

the check should thus not be make on the base of the temperature being 0.0,

but on whether there are atoms in the associated group.

axel.

in fix_temp_rescale.cpp (l:137), an error

condition halts the program if the result of

t_current = temperature->compute_scalar();

is zero in "FixTempRescale::end_of_step()", which

will always happen if the number of atoms in the

fix temp/rescale group is zero.

In gcmc runs at very low density or at the start

of runs with zero "molecules of interest", this

condition might be met but should not be seen

as an error.

Therefore, with new builds for gcmc runs I modify

fix_temp_rescale.cpp

from

135: double t_current = temperature->compute_scalar();

if (t_current == 0.0)

error->all(FLERR,"Computed temperature for fix temp/rescale

cannot be 0.0");

to:

135: double t_current = temperature->compute_scalar();

if (t_current == 0.0) {

error->warning(FLERR,"Computed temperature for fix temp/rescale

cannot be 0.0");

return;

}

I tried to understand the program flow within FixTempRescale but

could not find any problems with this approach. So I'd like to

put this topic on display and ask for clarification: can such

a change be made permanent - maybe as an option? Or - is there

some drawback which I didn't see?

there is one problem with this approach: if you actually *have* atoms in

the selection and will try to rescale, you will get a devision by zero

error and then a crash or you have invalid numbers in your

velocities/positions, which will make the simulation meaningless.

the check should thus not be make on the base of the temperature being

0.0, but on whether there are atoms in the associated group.

actually, looking at the degrees of freedom in the temperature compute is

even better, as that is what affects the rescale. that same change should

be applied to all thermostats that use rescaling (temp/rescale,

temp/berendsen, temp/csvr, temp/csld)

please see the attached patch for an implementation of this, that i just

added to my LAMMPS-ICMS tree (and will forward to steve at the next

opportunity).

axel.

lammps-no-atoms-rescale-protect.diff.gz (727 Bytes)