Thank you for your reply and patience.
I now realized that my arrays from coeff() are based on atom types. And I will probably just do a pairwise force with some minor modifications independent of time.
Also, I will have to define a region inside a curved pipe of uniform curvature to simulate curved blood vessel. However, I checked the region command and it seems like I could only use union to combine some spheres for an approximation of the shape I want, without changing the source code. Do you have any suggestions on this? If I must modify the source code, is it easily doable and which region source code should I start with?
Thank you very much,
Victor
Thank you for your reply and patience.
I now realized that my arrays from coeff() are based on atom types. And I will probably just do a pairwise force with some minor modifications independent of time.
unless you spend more time reading LAMMPS source code and understanding the inner workings for doing MD with domain decomposition, that is a realistic goal. before posting code in the future, however, you should at the very least make certain, that it can successfully compile. that is the absolute minimal requirement for getting something that works.
Also, I will have to define a region inside a curved pipe of uniform curvature to simulate curved blood vessel. However, I checked the region command and it seems like I could only use union to combine some spheres for an approximation of the shape I want, without changing the source code. Do you have any suggestions on this? If I must modify the source code, is it easily doable and which region source code should I start with?
i have no suggestions on this. the LAMMPS manual has a whole section about extending and modifying LAMMPS and that includes new region styles and what their requirements are. if you can find a way to describe your region in some mathematical expression and have sufficient C++ programming skills, this should be not too difficult. Region styles are among the easiest to do as an addition to LAMMPS.
Axel.
Hi,
I looked through fix property/atom and saw that custom per-atom values could be defined and accessed in pair style. However, my time-dependent force needs to store per-pair values and each value has to stick with the same pair. In this way I can track the time elapsed for two atoms within a close enough distance.
Could this be easily solved by defining a 2-D array based on per-atom vectors, or some source code must be modified?
Thank you,
Victor
tracking pairs of atoms is a complex and difficult to program feature.
using fix property/atom is not going to work, as that tracks per atom data, not per-pair. there are no provisions for multi-dimensional data and it would be a lot of programming effort (and need lots of memory and redundant communication. it would not be very different from option 1) below, only more complicated to implement).
i see two possible strategies, none of them is simple:
-
the more naive implementation would implement a new fix that holds one (or more) matrix of dimension natoms by natoms (not nlocal by nlocal or nlocal+nghost by nlocal+nghost). the fix would initialize this data and then the pair style grab a pointer to it (e.g. via an extract() method or simply enabling access to internal data and looking up and casting the fix accordingly) and would set or update the data after looking up the index through atom->tag. after each force computation, the updated data in the matrix/matrices would need to be updated across all MPI ranks, probably with some complex communication patterns, where the local atom data is broadcast to all other MPI ranks (the most naive implementation of that would have an natom number of broadcasts of natom matrix elements). as the description indicates, this would be very negatively affecting parallel performance, memory consumption, and performance. of course, individual steps could be implemented in more optimal ways, but that would make the programming increasingly complex and would require significant skill levels of parallel programming with MPI
-
the more efficient implementations would follow what has been implemented for granular models, where there is a fix tracking the neighbor list and storing per pair data and moving this data around with the neighbor list info. this would require significant low-level LAMMPS programming in C++, as it would require to implement some significant amount of complex code similar to what has been done for granular styles, unless your custom pair style would be rather similar to pair style gran/hooke/history or gran/hertz/history and thus could be implemented as a modification of those.
Axel.
Thank you for the detailed suggestions.
Right now I am testing the time-independent version of my pairwise force. I successfully compiled it, but it ended up with a “Signal: Segmentation fault” error when I tried to use it in the input script.
This pair style is a modified version of the dpd pair style. When I replaced this new pair style with dpd in my input script (with similar coefficients too), no error occurred. So I am guessing the problem comes from the new pair style’s source code.
I have attached the source code, input script and error message, could you please take a look?
Thank you very much,
Victor
pair_plat.cpp (9.33 KB)
in.melt (621 Bytes)
pair_plat.h (2.01 KB)
error message.txt (6.61 KB)
not going to happen. you wrote the code, you need to debug it yourself. i have so far been rather generous, given you already obvious display of limited programming skills, because the information i provided might also be of use for others that would search for solutions or background information to related problems in the mailing list archives. but what you are asking here is too much. if you don’t know how to debug such rather elementary things, you have to learn it. material for c/c++ programming debugging is plentiful and there is no point in modifying/writing c++ source code without having the rather basic debugging skills needed for resolving issues like this.
axel.