LIGGGHTS® - Developer Forum

Topics related to developing with LIGGGHTS® can be discussed here: discussion about implementation details, C++, MPI and debugging tools

spring-dashpot boundary

Submitted by JoshuaP on Wed, 02/18/2015 - 11:14

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?

fix wall/gran contact force handling

richti83's picture
Submitted by richti83 on Tue, 02/03/2015 - 15:44

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.

Rotation axis

Submitted by JoshuaP on Wed, 12/17/2014 - 14:55

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);

compiling but segmentation fault

Submitted by JoshuaP on Wed, 12/03/2014 - 11:08

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

Problem with "fix property/atom" and "compute property/atom"

Submitted by abehjatian on Sun, 09/28/2014 - 00:45

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 :

[SOLVED] About normal model hooke hysteresis

richti83's picture
Submitted by richti83 on Tue, 09/16/2014 - 09:39

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

Pages

Subscribe to RSS - LIGGGHTS® - Developer Forum