I am running with the stable July 22, 2025, release version of LAMMPS, and I was encountering a bug with the fix print command.
Per the website: fix print command — LAMMPS documentation, the fix print optional command “screen” is supposed to take “yes” or “no” options, but after digging into the source code, I found that the screen option takes the “0” or “1” option to work.
I am not sure if this is a bug from my end or if this is an issue in the source code, but when I try to use “screen no” nothing gets printed to my text file. When I switched to “screen 0,” the executed perfectly.
Please provide a minimal input deck (e.g. by adding your fix print command to the “melt” or “peptide” example) confirming your observation, so that we can verify your claim.
Please explain how you conclude this? When I look at the source code, I see this:
The utils::logical() function will accept ‘yes’, ‘1’, ‘on’, or ‘true’ as positive argument and ‘no’, ‘0’, ‘off’, or ‘false’ as negative, so there should be no difference between using ‘yes’ or ‘1’:
int rv = 0;
if ((buf == "yes") || (buf == "on") || (buf == "true") || (buf == "1")) {
rv = 1;
} else if ((buf == "no") || (buf == "off") || (buf == "false") || (buf == "0")) {
rv = 0;
} else {
std::string msg("Expected boolean parameter instead of '");
msg += buf + "' in input script or data file";
Attached are my files. Note that I compiled LAMMPS with Intel oneAPI 2025, so this could also be the culprit. There were a few warnings in the MakeCache file, but it was not attributed to the fix print command.
Sorry, but I didn’t ask for your files, I have asked for a simple reproducer with a simple/fast input that only has your fix print command added. This will make debugging massively easier.
That line is not properly quoted and thus unreadable (have you looked? does is look like what your input has?). Please see the forum guidelines for details.
I know and the explanation is in the guidelines post. We put it there, so we don’t have to explain it to people over and over again.
I have created my own test inputs and cannot confirm your report.
As stated, the screen keyword takes those various different arguments that I mentioned and produces the expected behavior. I tested with the current development version and the latest update to the stable version. This part of the code has been unchanged since March 2024.
units lj
atom_style atomic
lattice fcc 0.5
region box block 0 5 0 5 0 5
create_box 1 box
create_atoms 1 box
mass * 1.0
velocity all create 3.0 2131513 loop geom
pair_style lj/cut 2.5
pair_coeff * * 1.0 1.0
neighbor 0.3 bin
neigh_modify every 10 delay 0 check no
variable temp equal temp
fix 1 all print 10 "$(step) ${temp}" file heatflux.txt title "Step Temp" screen no
fix 2 all nve
thermo 20
run 100
Thanks for checking for me. Maybe it is due to the way I compiled LAMMPS with Intel oneAPI. Hopefully this will work as a temporary solution in the interim, but I am going to review the compilation warnings in greater detail to ensure other aspects of program won’t be affected from my end.
Once again, much appreciated for your time and help, Axel! Have a wonderful day as well.
Actually, I noticed that the source cpp code that I have is also different. So now I am confused. I do not see the “yes” line at all. Attached is the source cpp that I have.
My apologies for misunderstanding, Axel. Yes, I have the same exact utils.cpp function and the exact fix_print.cpp command as well. So I guess this issue is with the way I compiled LAMMPS. But nonetheless, I have no issues with using 0 has a placeholder for the time being.
If your compiler/compilation settings mess up such a simple thing, how can you trust that executable for anything??? What if it also messes up something else? Something that relates to the correctness of your results.
Yes, I am using 0 as a placeholder for the time being, but I am working to troubleshoot the compilation. There were no errors produced by utils.cpp and fix_print.cpp.
But warnings appeared in pppm_disp_intel.cpp and npair_bin_intel.cpp. I looked through all the lines of the compilation, but encountered no visible errors or warnings besides those in pppm_disp_intel and npair_bin_intel.
I am not certain that it is attributed to the compilation anymore. However, it could be that the .restart files were produced from a different compilation of LAMMPS, so I must confer with a colleague about this.
Thank you once again for the heads up and warning messages. I will be taking into account of your suggestion.
I wanted to give you an update regarding this issue. It was due to the restart file having a different compilation of the July 22, 2025 version, which did not have the correct CMAKE CXX and C flags.
I am not sure why either, but I was able to run a complete simulation (producing the restart from my own compilation) using the print command with “screen no,” which worked from my end.
If it is truly a compilation issue, then it cannot be associated with the Intel MKL or how I compiled LAMMPS because I produced no errors (only two warnings for packages irrelevant to fix print). I used the following command to compile:
Compilers don’t advertise their bugs by printing warnings or errors, they just create incorrect assembly code.
That is not helping unless you also provide the settings that were creating the incompatible restart.
Given your inconsistent reporting thus far, I will only believe what I can reproduce myself.
So please take the minimal input example I posted and make it write a restart and then manufacture a second input that continues from the restart and then let me know the exact steps and compiler flags (and compiler versions) that I have to use to re-create the restart issue. Since the input does not require any packages, compilation can be fairly simple and fast.