LIGGGHTS® - Developer Forum

Hello,

Sorry for the offtopic, but you developers probably will know. The new Intel Xeon Phi coprocessors can be used for liggghts? I mean, each one of the 60 cores of one coproccesor is seen as one core by openMPI? can I use mpirun -np 60 liggghts < in.example?

Thanks in advance, and best regards.

Hey,

I've added a spring-dashpot boundary. Therefor I extended the fix move/mesh to constrain a mesh with a spring-dashpot. Now I need also to output the actual position of the mesh. The calculation of the position is already done inside the liggghts code, but how can I output it to use it in a input script of liggghts. First I thought to look for the servo walls of liggghts, but I would like to have the position directly in the fix move/mesh command and if possible not in the fix mesh/surface/stress. Does someone tried something like this maybe already?

A special question to the developer:
let's assume a single ball lies on a plane surface exactly at the corner of 6 triangles.
The expected force contribution for a single triangle would be 1/6*f_pw (m*g=sum(f_triangle)).
Now for comprehensible reasions Liggghts only handles the first contact and than checks for all other triangles if there was an allready handled contact with a coplanar neighbour-triangle. This leads to correct wall-ball behaviour and is OK.

Hi,

I have a question about the functions initial_integrate and final_integrate from fix_nve_sphere. Where is the difference in the functions? When are these function used?

Thanks
Joshua

Hey,

I'm trying to rotate and translate a mesh. But I want the mesh to move in z-direction in the rotated system and not in the inertia system. So I'm doing 3 rotations with

mesh_->rotate(totalPhix_,incrementalPhix,axisx_,reference_point);
vectorScalarMult3D(axisx_,omegax_,omegaVecx);
mesh_->rotate(totalPhiy_,incrementalPhiy,axisy_,reference_point);
vectorScalarMult3D(axisy_,omegay_,omegaVecy);
mesh_->rotate(totalPhiz_,incrementalPhiz,axisz_,reference_point);
vectorScalarMult3D(axisz_,omegaz_,omegaVecz);

hey,

in my script I needed the variable f_total_[0],f_total_[1], f_total_[2] which is protected: in fix_mesh_surface_stress.

My script is running fine as long as Im not trying to use this variable.
To get this variable I put in the header of fix_mesh_surface_stress
friend class myclass;

In the header of myclass I have
class FixMeshSurfaceStress *mymesh;

up to here no segmentation fault does occur, but if I want to get the variable now with

Dear all,
I saw in the file neigh_gran.cpp, in the ´void Neighbor::granular_bin_no_newton_ghost(NeighList *list)´ part, there is

Dear All,

in the public version liggghts, the overestimated mass doesn't discount for the fix rigid command. Has some one implement this?
If i want to adapt the codes, which source file should i look at?

Thank you very much.

Best regards,

Zyan

Hi,

I want to define a new atom property using "fix property/atom" and then access it in cpp files by "find_custom( char *name, int &flag)".
Is there any inconsistency between "fix property/atom" and "compute property/atom" in LIGGGHTS?
I want to use them together but I get an error. It works fine in LAMMPS.

In LIGGGHTS, I use:

fix 1 all property/atom d_watomc scalar yes no no 0.0
run 0
compute 1 all property/atom d_watomc

but I get : "ERROR: Compute property/atom integer vector does not exist"

In LAMMPS :

A student of mine improved the public normal model hysteresis because it seems not to be correct in all situations
(delta_max was not limited, so the k2 stiffnes was never used in compacting case (only in relaxing)).
See this plot for a comparison between new and old model for a two-particle-contact:
comparison_liggghts3.png
script: two.lmp

A patch can be found here:
http://www.richtisoft.de/transfer/normal_model_hooke_hysteresis.patch