Load a neighbor list via a text file

JF's picture
Submitted by JF on Tue, 11/02/2010 - 15:03

Hi all,

I have the objective to modify the neighbor class in order to load a neighbor list via a text file. I need your opinion to do this in compliance with the previous developments in LIGGGHTS. The interest is to extend LIGGGHTS to perform lattice beam simulations.

Therefore:
I am thinking to add a new style : enum{NSQ,BIN,MULTI,TXT} in the files : neighbor.cpp and neigh_list.cpp

I am thinking to add a new request: int latthistory in the file neigh_request.cpp

I am thinking to create a new class neigh_lattice.cpp in order to load a neighbor list via a text file and fill the neighbor list.

I am thinking to modifiy the neighbor.cpp to call the request that I defined previously.

Moreover, I would like to know if one of you is an expert on this part of the code (neighbor class) so as to ask him directly some advices during my next developments.

regards
JF

Forums:

ckloss's picture

ckloss | Tue, 11/02/2010 - 15:14

Hi JF,

>> The interest is to extend LIGGGHTS to perform lattice beam simulations.
This sounds like a field for a bonded-particle model?

what is the concrete reason for wanting to load neigh lists from a file? Maybe there is a less complicated way to establish what you want---? If your list comes from a file - is it a list that is not updated during the run (read once at startup) - or is it coming from another code you want to couple with?

One ad-hoc idea that also comes to my mind: Maybe you can also formulate your problem so that it works with the existing neigh list build exclusions (e.g. if the structure you have is "molecule"-like you could read molecule IDs instead of the neigh list itself). If not, it would maybe be far easier to modify the exclusions than to implement a new algorithm.

>>Moreover, I would like to know if one of you is an expert on this part of the code (neighbor class)
I did not write the code myself, but I have an idea how it works - so posting to this forum is a good idea. Also, you can post to http://sourceforge.net/mailarchive/forum.php?forum_name=lammps-users where the LAMMPS developers will answer

Cheers,
Christoph

JF's picture

JF | Tue, 11/02/2010 - 16:33

Hi Christoph,

This sounds like a field for a bonded-particle model?
Yes you are right, except that in the lattice beam model the interactions between spheres are created by a Delaunay triangulation. It means that the spheres can be bonded together even if they are not in contact. The Delaunay triangulation is important because we take its dual (Voronoï diagram) to define the section of each beam. This numerical method is intensively used to study crack propagation (1) or fragmentation process (2).

Therefore, I need to load these interactions defined by Delaunay triangulation only once. I thought a lot about your different suggestions but unfortunately I must implement a new algorithm to fill the list variables from my text file.

Thank Christoph for your reply and the link.
JF

(1) P.K. Nukala et al., Fracture roughness in three-dimensional beam lattice systems, Physical review E, 2010
(2) G. Timar et al., New Universality Class for the Fragmentation of Plastic Materials, Physical review letters, 2010

ckloss's picture

ckloss | Tue, 11/02/2010 - 22:33

Hi JF,

this method sounds very interesting - I agree that in this case the best idea would be to write a new neighlist style.

If you have some coding finished let me know if you want it to be in the public release - aside from the open source idea, this would have the advantage that you don't have to care about porting your code to newer versions.

And let me know if any questions arise

Cheers,
Christoph

JF's picture

JF | Thu, 11/04/2010 - 17:03

Hi Christoph,

I have a question concerning the neighbor.cpp file. I do not know if I must create a new subject (e.g., About the neighbor.cpp file) on the forum.

I chose to implement a new STYLE=TXT, my neighbor list for each CPU will be built only once. I understood the function choose_build() which enables to define the way to build the neighbor list. Unfortunately, I do not understand what is the stencil_create function. Can I skip this function in my case as it is done for the NSQ style ?

Regards
Jf

JF's picture

JF | Mon, 11/08/2010 - 11:59

Hi Christoph,

In the neighbor.cpp file, there is the request class with its parameters for example requests[i]->granhistory. I look for where the value of various parameters of request class is defined.

Please, can you help me to find where is defined requests[i]->granhistory = 1 or 0. I think that the variable i represents the number of lists == number of procs.

Regards
JF

JF's picture

JF | Mon, 11/08/2010 - 12:39

Hi Christoph,

I found where the variable granhistory for the request class is put to 1. It is in the pair_gran_hooke_history.cpp file, one of files where the normal and shear force is computed for each atom.

The strange thing in LAMMPS is that few pair files define the variables of request class. For example in the pair_yukawa.cpp file no requests are defined.

So now, I must develop a pair_lattice_history.cpp file similar to the pair_gran_hooke_history.cpp file where neighbor->requests[irequest]->latticehistory = 1.

JF

ckloss's picture

ckloss | Mon, 11/08/2010 - 12:40

JF,

you don't need a "latticehistory", please use the existing "granhistory" flag.
I can send you some code for this that might help... You will receive mail on the details

Christoph

JF's picture

JF | Mon, 11/08/2010 - 12:55

Hi Christoph,

Ah ??? ok !!! I will wait your details but you need to know that I cannot use the pair_gran_hooke _history because I need to use my own pair file with a shear history and compression history (this last option will be interesting to edit contact laws which take into account load-unload-reload).

Thank you for your reply.
Jf

ckloss's picture

ckloss | Mon, 11/08/2010 - 13:04

>>I cannot use the pair_gran_hooke _history
I know - but you can use the contact history logic that I sent you.

>>(this last option will be interesting to edit contact laws which take into account load-unload-reload).
that's exactly what we are aiming for...

Christoph

Alberto | Fri, 03/25/2016 - 14:05

Hi Jean!, my name is Alberto. im a mechanical engineer student, and with my friend (Felipe) are working to simulate the fracture of rock in a mining mill. Our firt mision is to simulate the fracture of a test tube. I know that the Lattice beam model is a great model for this study, but in Liggghts the module is not finished yet.
The cuestion is, can you share some information about the model and the module?. This module is very importany for us, thank for your time. Bye!