change of fix move/mesh in 3.7

Submitted by Weijing on Thu, 07/20/2017 - 03:09

Hi everyone,

I just update liggghts into 3.7 from 3.6. I did a test with the same input file in both 3.6 and 3.7. however, the fix move/mesh gave me different result.

fix vibra all move/mesh mesh bottom viblin axis 0. 0. 1. order 1 amplitude 0.0025 phase 1.57 period 0.02

What is the motion produced by this command ?

According to the documentation, in 3.7, it seems this command has a different meaning. I can't remember the meaning in 3.6. In practice, 3.7 give the wiggle command to produce a sine motion of the mesh while 3.6 didn't (I think).

Thanks
Weijing

AttachmentSize
Binary Data f01post36.tar_.gz11.77 MB
arnom's picture

arnom | Thu, 07/20/2017 - 07:47

Hi,

the purpose of this command is exactly to produce a motion that is sinusoidal. You can see the description at: https://www.cfdem.com/media/DEM/docu/fix_move_mesh.html?highlight=viblin (just scroll down a bit, searching for viblin).

We did indeed change some things around the fix move/mesh. But that should only influence you if you have multiple fix move/mesh that apply to the same mesh. Please be more precise about the behaviour in 3.6 if you indeed think something is wrong.

Best,
Arno

DCS team member & LIGGGHTS(R) core developer

Weijing | Thu, 07/20/2017 - 09:29

Thanks, Arno

The command produces correct movement in 3.6. In 3.7 the mesh was moved to another position (along z direction) then vibrated after the command is read.

btw, if the restart file produced by 3.6 is read by 3.7, will there be some problems?

Regards
Weijing

arnom's picture

arnom | Fri, 07/21/2017 - 14:11

Can you please post a minimal test case that shows this behaviour? Please upload the case somewhere so that I can investigate this locally.

DCS team member & LIGGGHTS(R) core developer

Weijing | Sat, 07/22/2017 - 09:10

Thanks for your kind attention. I have uploaded the case in this discussion, including the input file, stl, and the result I got.

Regards
Weijing

arnom's picture

arnom | Thu, 08/03/2017 - 10:25

There was indeed a bug in the input reading (which should have been present in earlier versions as well).

To fix the bug copy the code below


diff --git a/src/mesh_mover_linear.cpp b/src/mesh_mover_linear.cpp
index 99c4ac5..7f65880 100644
--- a/src/mesh_mover_linear.cpp
+++ b/src/mesh_mover_linear.cpp
@@ -312,8 +312,8 @@ MeshMoverVibLin::MeshMoverVibLin(LAMMPS *lmp,AbstractMesh *_mesh, FixMoveMesh *_
//array transfer
for (int j=0;jnumeric(FLERR, arg[8+j]);
- ampl[j] = force->numeric(FLERR, arg[9+ord+j]);
+ ampl[j] = force->numeric(FLERR, arg[8+j]);
+ phi[j] = force->numeric(FLERR, arg[9+ord+j]);
omega[j] = 2.*M_PI/force->numeric(FLERR, arg[10+2*ord+j]);
}
}
diff --git a/src/mesh_mover_rotation.cpp b/src/mesh_mover_rotation.cpp
index d3ffa3a..3270aca 100644
--- a/src/mesh_mover_rotation.cpp
+++ b/src/mesh_mover_rotation.cpp
@@ -360,8 +360,8 @@ MeshMoverVibRot::MeshMoverVibRot(LAMMPS *lmp,AbstractMesh *_mesh, FixMoveMesh *_
//array transfer
for (int j=0;jnumeric(FLERR, arg[12+j]);
- ampl[j] = force->numeric(FLERR, arg[13+ord+j]);
+ ampl[j] = force->numeric(FLERR, arg[12+j]);
+ phi[j] = force->numeric(FLERR, arg[13+ord+j]);
omega[j] = 2.*M_PI/force->numeric(FLERR, arg[14+2*ord+j]);
}
}

into a file (let's name it patch.txt) and put that file into your LIGGGHTS-PUBLIC folder. Using the command line you can then cd to this folder and do

git apply patch.txt

Recompile your code and it should work. If you have any issues with the above let me know.

Best,
Arno

DCS team member & LIGGGHTS(R) core developer

uhelfenstein | Tue, 08/08/2017 - 14:23

Hi Arno

I found that the amplitude in viblin is replaced by the phase parameter.

I tried the patch but this massege came:

dem@DEM-Workstation:~/LIGGGHTS-PUBLIC$ git apply patch.txt
fatal: corrupt patch at line 7

How can I solve this.

Tks,
Urs