Variable Special function min() finds incorrect minimum value in fix ave/spatial bin array column

LAMMPS LAMMPS Mailing List Mirror
#1

Hi,

I’m trying to find the minimum value in one of the columns of the bin array generated by the ave/spatial fix, using

variable minimum equal min(f_ID[J]) (with J = 2 in particular for the number of atoms in the bins)

I consistently get a value of zero when I print v_minimum along with the other thermal output.

However, when I use the max() special function to find the maximum in f_ID[J], it gives me the correct non-zero value.

I know that the minimum value is not zero because I write the data generated by the ave/spatial fix to an output file and the column in question contains no zero value on inspection.

I need to calculate this minimum value because I use it as a condition to jump to a different line of my Lammps input script. I’m running alternating contact formation and rupture simulations on metal input structures of various geometries and I would like contact formation to continue only to a certain minimum number of atoms in the contact region and then rupture the contact. Ideally, I want to repeat this process many cycles and so “mechanically anneal” the metal tips I bring into contact with each other.

I use the lmp_g++ executable on a server on which I don’t have sudo permissions, so if the solution to my question requires me to modify and reinstall lammps (difficult, server administrators are very busy), I would be grateful if anyone could suggest other ways of doing the repeated formation/rupture simulations.

Thanks in advance for any help and suggestions

Regards

Wynand

#2

  Hi,

I'm trying to find the minimum value in one of the columns of the bin
array generated by the ave/spatial fix, using

variable minimum equal min(f_ID[J]) (with J = 2 in
particular for the number of atoms in the bins)

I consistently get a value of zero when I print v_minimum along with the
other thermal output.

However, when I use the max() special function to find the maximum in
f_ID[J], it gives me the correct non-zero value.

I know that the minimum value is not zero because I write the data
generated by the ave/spatial fix to an output file and the column in
question contains no zero value on inspection.

​your observations are correct.​

​the problem is due to an implementation choice in fix ave/spatial, which
essentially lies about the dimensions of the allocated storage and then
returns a zero, when the request is out of bounds. you should have also
noticed a massive slowdown of the calculation when searching for the
max/min.

you can work around this for your case by adding one line​ to
fix_ave_spatial.cpp (marked by the + below) and recompile.

diff --git a/src/fix_ave_spatial.cpp b/src/fix_ave_spatial.cpp
index 67e1b6a..e9f1260 100644
--- a/src/fix_ave_spatial.cpp
+++ b/src/fix_ave_spatial.cpp
@@ -896,6 +896,7 @@ void FixAveSpatial::setup_bins()
     nbins *= nlayers[m];
     bin_volume *= delta[m]/prd[dim[m]];
   }
+ size_array_rows = nbins;

   // reallocate bin arrays if needed

need to calculate this minimum value because I use it as a condition to
jump to a different line of my Lammps input script. I'm running alternating
contact formation and rupture simulations on metal input structures of
various geometries and I would like contact formation to continue only to a
certain minimum number of atoms in the contact region and then rupture the
contact. Ideally, I want to repeat this process many cycles and so
"mechanically anneal" the metal tips I bring into contact with each other.

I use the lmp_g++ executable on a server on which I don't have sudo
permissions, so if the solution to my question requires me to modify and
reinstall lammps (difficult, server administrators are very busy), I would
be grateful if anyone could suggest other ways of doing the repeated
formation/rupture simulations.

​LAMMPS is a user level application and thus doesn't require any
administrator privilege to be compiled and used. many LAMMPS users compile
custom LAMMPS from source (especially on larger supercomputing resources)​,
where they have no superuser access at all.

​axel.​

#3

Dear Dr Kohlmeyer,

Thank you for your prompt reply.

I will add the line of code to fix_ave_spatial.cpp as you suggest and try to compile custom in my home directory on the cluster.

I did notice the slowdown you mention. Will this problem be resolved once I’ve added the line of code?

Thank you very much again.

Regards

Wynand

#4

Dear Dr Kohlmeyer,

Thank you for your prompt reply.

I will add the line of code to fix_ave_spatial.cpp as you suggest and try to compile custom in my home directory on the cluster.

I did notice the slowdown you mention. Will this problem be resolved once I’ve added the line of code?

Yes.

#5

yes, Axel’s addition is a better solution than the current implementation.

The issue the code was trying to address was that
the # of bins (and thus the length of the array) is
variable and not known until later in the setup.

However, some other commands (like thermo custom)
need to know the size of the array to do error checking.

So I also added an extra call to the code with Axel’s
addition to try to estimate this more accurately.

Will be in the next patch …

thanks,
Steve