About fix smd

Dear Developers & Users,

I am using fix smd, and have a little confused about the best choice of K constant and velocity.
Also, in the output terms, I wonder how is the “reference distance” is computed? and how does it differ from the “spring distance”?
Whether we should keep the “reference distance” closed to the “spring distance” during steered simulation? Or any practical way to check whether the choice of K and vel are reasonable based on the output quantity of fix smd?

Thank you so much for help

Please keep in mind that a software manual is often very similar to the operator’s manual you get with a car: it will tell you where all the knobs and switches are and how you operate them, but it will not (and cannot) teach you how to drive the car.

Same here, if you want to learn about what are good parameters and settings, you need to read up on the method and study the publication(s) describing its derivation or publications discussing applications of the method. Since steered MD is not exactly new there are likely also review articles summarizing best practices from other publications. The LAMMPS documentation usually contains some relevant references which are a good starting point.

The “spring distance R0” is a leftover from the fix spring code that fix smd is based on. Except for some very unusual cases, R0 should be set to 0.

Dear Prof. Axel,

Thank you so much for your reply.
I deeply understand what you are talking about “the operator’s manual”

I have read the papers listed in Lammps docs.
I also do some enhanced sampling simulations based on other methods (included smd), which based on the collective variable definition and realize the difference from what is implemented in LAMMPS.

So what I am asking for help is about the quantities are computed in LAMMPS.
From lammps docs:
" This fix computes a vector list of 7 quantities, which can be accessed by various output commands. The quantities in the vector are in this order: the x-, y-, and z-component of the pulling force, the total force in direction of the pull, the equilibrium distance of the spring, the distance between the two reference points, and finally the accumulated PMF (the sum of pulling forces times displacement)."

I am very confused about “the distance between the two reference points” and how it is computed? That is what I have written in the first post.

I also see the post from another person confusing the same quantity, and your reply from that post is not clear.

I appreciate your help very much. But please don’t respond like that I am intending to waste your time, please.

That means that you have not yet fully understood the method. There is not much that I can add to the available explanations. If you want to know more about the implementation details, you have to read the source code.

Please note that there are alternate implementations of steered MD in LAMMPS in the COLVARS and PLUMED packages. Perhaps their documentation is more accessible to you.

You are right, very logical. And that is why I am confused about the quantities computed LAMMPS, but I don’t see that quantity in other package. And that is why I need the help here.

That is what I wrote above.

Thank you.

It is technically not a computed quantity, it is part of the algorithm. Other implementations may not expose this value directly or call it differently. In a collective variable context this would be the “reference” of the distance collective variable. For consistency one should not be using the actual value, but the value marking the point to which the SMD spring is attached. Fix smd outputs it, so that one can easily plot the pulling force or the PMF versus the distance.

Not really. You were very vague. If you have already been using either of the two collective variable based packages, then it is not clear to my what you expect to gain from using fix smd. Both implement the same algorithm and do it in a well and actively maintained component of the software, while fix smd is mostly abandoned and not actively developed.
It predates integration of COLVARS and PLUMED into LAMMPS, but has been kept around for convenience of existing users.

I perform Steered MD using PLUMED as described here: PLUMED: MOVINGRESTRAINT

And the return result is very different to fix smd in LAMMPS.
That is why we have this conversation.

This statement is making me very angry, you could have stated this at the very beginning and avoided wasting my time worrying about irrelevant aspects.
The most likely explanation is that you may not have used either or both implementations correctly. There is not much that I can do from remote. I suggest that rather than comparing different implementations, you pick one (e.g. PLUMED or COLVARS) and set up and reproduce already published results. That is the best way to study how to correctly use new methodology.

Dear Prof. Axel,

I really don’t know why you are angry.

What I initially ask is about “the distance between the two reference points”, a quantity output from fix smd, this parameter may not well documented in literature or maybe my lack of knowledge as you said.
So if I understand exactly what it is in LAMMPS, then I hope for a reasonable setting.

I expected someone can help me with a simple explanation.

You can ignore my stupid question, so why do you have to respond with your anger?

Btw, thank you for your replies and sorry for your time.

Because the questions that you asked in your first post were misleading due to the lack of context.

While it may not appear as a problem to you, but it is very difficult to provide competent and suitable answers to specific questions without knowing the context. This is because you have knowledge of everything you did and you also may have some hypothesis of what knowledge you are missing, but a) I know only what you write in your post(s) and b) I have to content with the possibility that your hypothesis of why you are not getting the result you expect is wrong.

On top of that, the fact that you get different results from fix smd and fix plumed has obviously nothing to do with the choice of force constant and pulling velocity (which is what you were primarily asking about in your first post) since both implement the same algorithm and thus should be using the same parameters and settings, provided they use the same units. This entire confusion was avoidable, if you had provided the additional context in the beginning that you only revealed at the end. This is what I am upset about.

Or let me put this differently. If you notice a different behavior in features that should have the same (which is what we are discussing now), the proper way to address this and get help would be to a) provide a suitable, simple, fast to run example for both, b) explain why you believe that both input decks are equivalent and thus should produce the same result and c) describe what the expected result is and how you derived that.

Because I have the hope that you and others, who may be reading this later, can learn from it and will ask better questions later. Answering and investigating well posed questions and problems is enjoyable. Figuring out after multiple responses that the questions asked are not addressing the actual problem is frustrating. I like to enjoy myself while responding to questions.

You have to understand that because it is you that wants to have your problem solved, it is in your own best interest to pose questions in the most effective and easy to answer way and that usually requires to provide as much context and detail as possible. For a person answering it is much easier to skip over too much or irrelevant details than to have to guess missing information.

Dear all,

I finally found out what is “the ambiguity” of the output quantity called “the distance between the two reference points”. You will expect this output as a “real value” of a biased variable, but this is really not in Lammps. So be careful when referring to it.

You may want to use PLUMED, and it may a little time for the data transfer between the two engines.
I have limited resources so still want to use fix smd, and it still works well with a little ambiguity in its outputs, but now I can understand.