How to move a rigid wall in lammps

hi everyone
i am trying to simulate the compression test for just one single granular particle.
I generate a ball then use fix wall/gran to generate walls at the bottom and top of this single particle:

boundary        p p f
fix 3 all wall/gran hooke/history 200000000.0 NULL 50.0 NULL 0.5 0 zplane 0.0 1.01

but then i do not know how to move the top wall so that i can compress the particle;

then i tried

fix 3 all wall/gran hooke/history 200000000.0 NULL 50.0 NULL 0.5 0 zplane 0.0 null
fix 4 all wall/gran hooke/history 200000000.0 NULL 50.0 NULL 0.5 0 zplane null 1.01 shear z -1.0e-2

so that I make this bottom wall constant and move the top wall; but i get the error,
“Invalid shear direction for fix wall/gran (…/fix_wall_gran.cpp:430)”
based on the documentation, it seems that I cannot move the zplane wall in the z direction. so does anyone has the idea how to move the top wall to compress this atom?
Thanks for your help and time !
any specific command?
I tried the fix deform, but it seems change the boundary of the box, not the wall.
if I understand this rightly. boundary and wall are two different things. right?

To do what you want directly would require modifications to the source code.
You can check if the “wiggle” option would work for you, if you make the frequency small enough, but that is not a linear function, rather one that is following a cosine function. check the docs.

Beyond that, you can break down the run into multiple parts with either an explicit loop or the “every” option of the “run” command, make the position of the wall a variable depending on the timestep value (say wallpos) and then use that expanded variable to reissue the wall fix command at an updated position via ${wallpos} in the input. That will change a continuous movement into discrete jumps (but you can theoretically reposition the wall fix in every step if you don’t mind the overhead).

thanks for your response and help. it is really helpful.
i am thinking that whether i can use a variable to define the position of the top wall, like

# Define a time-dependent variable for the moving wall position
variable zwall equal 10 - 0.1 * step

# Define walls
fix 1 all wall/gran hooke/history 1e5 0.5 0.1 50.0 0.0 zplane 0 NULL
fix 2 all wall/gran hooke/history 1e5 0.5 0.1 50.0 0.0 zplane NULL v_zwall 

actually this idea is from Chatgpt, do you think his idea is reasonable or not?

many thanks for your time

While many LAMMPS commands will take “v_”-variables as dynamic parameters, the command must be coded to handle such input. So users should assume such “v_”- variables won’t work unless the documentation explicitly says they will. (ChatGPT has unfortunately learned a pattern that is common but not universal.)

In this case, it makes sense that fix wall/gran has not implemented a fully variable wall position, since (from what I can tell) the imposed force depends on the wall’s velocity and history, and it would take quite a bit of extra code to implement that for a fully generalised variable position (an equal-style variable could represent just about any process, including stochastic variables).

You could just use wiggle – setting the period to twice your simulation length will give a wall that smoothly moves through the desired distance. The wall velocity will be almost constant for a significant middle part of the trajectory.

maybe i can try to create a rough wall based on the documentation, it may be ok, should i make sure that the atom used for wall small enough compared to the single particle?

thanks for your response and help, i have tried this variable way, and this did not work.
I believe that wiggle could be alternative method for me to compress the single particle, but I then face another problem about the force of wall. I wish to obtain the relationship between “generated force” and “displacement". I checked the doucmentation, i cited “If the contacts option is used, this fix generates a per-atom array with 8 columns as output”
but this command seems did not work well:

fix 3 all wall/gran hooke/history 200000000.0 NULL 50.0 NULL 0.5 0 zplane 0 NULL contacts
fix 4 all wall/gran hooke/history 200000000.0 NULL 50.0 NULL 0.5 0 zplane NULL 0.01 wiggle z 1 1 contacts

as suggested, I used wiggle in z direction to order to compress the single particle. but then i tried to get the force of the top wall by this

variable        wall_force_x_t equal -f_4[2] # x component of top wall
variable        wall_force_y_t equal -f_4[3] # y component of top wall
variable        wall_force_z_t equal -f_4[4] # z component of top wall
fix             5 all print 100 " ${wall_force_z_t} " file thermo_output.txt screen no

but i got the ERROR: Variable wall_force_z_t: Per-atom fix in equal-style variable formula (…/variable.cpp:1820).

if you are happy, would you mind share any idea for this siutation, how should i can the force and position of the wall ?

thanks for your time and help, hope you have a nice day

No. It is not what I suggested.

ChatGPT uses a method to solve problems that is similar to “free association”. That will result in answers that look reasonable (and it postulates them with undeserved confidence), but have no footing in reality. There is no alternative to reading and following the documentation.

This entire statement/question makes no sense and is seriously lacking context. Thus it is impossible to answer.

Again, you are getting errors because you don’t follow the documentation properly. The output from the fix is not global data (as your variable formula implies), but a per-atom array. You have to take than into account. If you want LAMMPS to work correctly, you have to be precise in what you use as input. To get something that looks right and seems reasonable is not sufficient.

The necessary code is available in fix wall/gran/region, which can have moving regions. So it is quite possible. Unfortunately, the necessary functionality is missing in region style plain, so somebody needs to implement that to have the equivalent of fix wall/gran with a location that is moving through a variable. Only very recently the necessary changes were contributed for region style block.

Dear akohlmey
many thanks for your response and help, but there is still not really clear;
the documentation say " If the contacts option is used, this fix generates a per-atom array with 8 columns as output, containing the contact information for owned particles (nlocal on each processor)".
so this “contacts” option is used to generate the information for the these contacting atoms? not the wall?
it seems that in fix wall/gran command page do not show how to obtain the force and position of the wall.
does this mean that lammps cannot obtain the force and position information of the “wall” ?

you are right, ChatGPT always makes mistakes

The fix command does what the documentation says it does. Nothing more, nothing less.
You are trying to access global information, where there is only per-atom information.
What you are asking for makes little sense unless you have only one particle. But since Newton’s third law applies, you can always reconstruct the global data from the per-atom data.

It is not really a “mistake”. The problem is the principle. Machine learning finds and records (weighted) correlations and then uses those to extrapolate answers. That works well for anything where you just need to get it approximately right, where details are vague and being a little off does not matter much. But for anything technical where you have to match details exactly, this kind of approach leads to disaster. If you look through the forum/mailing list archives you find many people asking questions about why certain commands don’t work and in a surprisingly large fraction, the problem is that they make invalid assumptions about how a feature would be implemented based on their expectations. However, for a software as complex as LAMMPS where there are contributions are made from many different people with different needs and different expectations, there is - by construction - not much of a chance of 100% consistency.

In fact, as the person managing maintenance on this software and desperately trying to maintain some level of consistency, I can assure you how much of a strain it sometimes is to get anywhere near that ideal point. So we often have to settle for compromises (so a contributed feature can be integrated without being entirely rewritten from scratch) and accept some inconsistencies.

Hi akohlmey

thanks for your reponse and time, so i can see that this fix gran/wall trys to get the information for all these atom; so it is really like something that i need to use dump command to obtain this information.

dump        2 all custom ${interval_dump} contacting_atom/dump*.atom  f_4[1]  f_4[2]  f_4[3] f_4[4]  f_4[5]  f_4[6]  f_4[7]  f_4[8] 

thanks for your help. i think i can try to obtain information for these contacting atoms and then try to get the global force information from the newton’s law.

thanks for your time and hope you have a nice day.