updating fix/mesh/gran every timestep

Submitted by evansmuts on Tue, 05/24/2011 - 11:38

Hi

I am trying to create a time-varying version of the "conveyor" feature of fix/mesh/gran. The most obvious way to do this is to update fix_mesh_gran.cpp every timestep. I have found the "time_depend" variable in fix_move_tri.cpp and other files. It seems to be a flag determining whether the function is time-dependent or not. Adding this to fix_mesh_gran does not seem to work - my programme is supposed to output to screen each timestep, but it doesn't. What else am I missing to make this work?

Is there a better way to change the wall velocity with time (other than updating fix/mesh/gran)?

Lastly, how do I get the current solution time (i.e. if I am running from 0 - 10 seconds, and I want some increment in between)? I see the time is usually calculated by working out how many timesteps (update->ntimestep) have elapsed and multiplying by the timestep size (dt). Is this the only way to do it? Is there not a single variable containing the current time?

Regards

Evan

Forums:

ckloss's picture

ckloss | Wed, 05/25/2011 - 14:35

Hi Evan,

time_depend prohibits a change of time step while such a fix is active, so this will not help here.
One possibility you have is to use variables as conveyor velocity - you can then make these variables time-dependent.
See e.g. fix addforce in a recent LAMMPS version for an idea how to code this

>>Is there not a single variable containing the current time?
Currently no - you can call it a design weakness but currently there is no absolute time in the Update class

Cheers,
Christoph

evansmuts | Thu, 06/09/2011 - 11:30

Hi Christoph

I have been giving this some more thought, but after looking at fix_addforce I could not see what you were getting at. Did you perhaps mean fix_ave_time or fix_aveforce?

When you talk about using a variable for the velocity and making it time dependent, do you mean defining the following in the input script:

variable velocity equal [some sort of time dependent equation]
run 100 every 1 "fix wall ... geometry.stl ... conveyor 0 0 ${velocity}

This will update the fix every timestep using the "every" keyword. The velocity variable will also be updated every time the fix is evaluated. This means that each time the fix is evaluated it will have a different velocity because the velocity variable will change with time.

I am currently using "every" in a similar way to the example above (though no variable) to update my fix every timestep. Even though it works, I am not sure if it would be a good solution for the long term. Do you have any comments on this? Is there a better way to do it?

My one concern is that it might increase computational cost as it has to evaluate the fix every timestep. However, I think there will always be an increase in computational time no matter how I update the velocity as the fix will always have to be re-evaluated with every new velocity? Am I correct, or is there a way to only assign the wall velocity and not have to read/move/scale the geometry as well? Or could I create a time dependent fix that only updates the velocity components of the fix? i.e. only over-write those specific wall velocity values which must be active during the entire simulation (vwall in fix_wall_gran.cpp).

Regards

Evan

ckloss's picture

ckloss | Thu, 06/09/2011 - 19:03

Hi Evan,

>>>run 100 every 1 "fix wall ... geometry.stl ... conveyor 0 0 ${velocity}
As you said yourself, this is not a perfect solution, as you will (a) be much slower (set-up every 100 time-steps) and, more dramatically (b) you will loose all the shear history information upon fixing/unfixing

I really meant fix_addforce (but the LAMMPS version) which allows for inputting variable force values - that's what you actually need. Or have a look at fix move, it's the same thing there

Cheers,
Christoph

evansmuts | Fri, 06/10/2011 - 12:44

Thanks for your comments. I thought I wasn't going to get it that easy, and I have now found that there are some other bugs with my method as well. It crashs/return an error when I use it with periodic boundaries. So that's not going to work.

fix_addforce: Sorry I was looking at the LIGGGHTS version, not the LAMMPS version (I assumed they were the same). I will read more carefully in the future.

Thinking along these lines, would it be worth creating a new move/mesh/gran (fix_move_tri.cpp) that calculates a new velocity when it gets updated every time step (which it must if the geometry is moving)? If I get that right, then I would like to make it only update the wall velocities and not actually calculate the new node positions as this is unnecessary. This seems more logical to me and easier to adapt to my needs than using fix_addforce or fix_move which works on the particles and not on the walls. Do you think this could work?

Thanks

Evan

evansmuts | Mon, 06/27/2011 - 16:57

An update on what I have done.

To create a wall velocity that updates every timestep with a new value, I took move/mesh/gran (fix_move_tri.cpp) and created a new fix called "surfVel/mesh/gran". It works just like the former, except that it doesn't handle the movement of the wall node positions at all. It only calculates the wall velocity (similar to "conveyor" in mesh/gran) and updates the wall velocity values.

As a result, I have a fix that initialises on the first step, then updates the wall velocity every timestep. It should be much faster that move/mesh/gran as it does not have to physically move the mesh geometry, it only assigns a wall velocity (I have not done extensive testing to confirm this though).

Evan