Potential memory leak in MBTR

[braxtonowens]

Thanks for the awesome software and great documentation.

Out of curiosity, I wanted to see how well MBTR could represent a large pure grain boundary system(<10000 atoms on average).

I do not think MBTR is best suited for representing these types of systems, but nonetheless I thought it would be beneficial to see for myself.

I have 7034 unique aluminum grain boundaries stored as LAMMPS dump files. When trying to represent these as MBTRs I realized that my memory was blowing up a lot faster than anticipated.

Below is a script that represents a single grain boundary as a MBTR. Note the print statements of the (current,peak) memory and the size of my output.

I am ignorant to the exact method MBTR is calculated, is there something I am missing? Is this memory usage intentional?

Thanks.

[lauri-codes]

Hi @braxtonowens!

Thanks for the report. I will look into this when I get a chance. I think the test needs to run the create-function several times and see if the memory usage goes out of control even with the garbage collection kicking in.

[braxtonowens]

Just wondering about the state of this change.

Also, I thought you should know that when I try and describe materials with a large amount of atoms(~188,000), my nodes run out of available memory. Specifically, this was tested with SOAP and ACSF. I only mention this because quippy SOAP seemed to be able to handle that size.