Hello,
Is there a way to have LAMMPS output some form of progress it makes through the simulation? I am familiar with 'thermo N'
http://lammps.sandia.gov/doc/thermo.html
which reports a global view of data every N steps, however, I would prefer LAMMPS to output only the amount progress it has made without performing any additional work, e.g. '100 steps completed' instead of actually doing extra work collecting data from other ranks, creating new files for checkpointing or similar.
Thanks,
Alex
Alexander,
How about just adding "thermo_style custom step" after the thermo
command? It prints only time steps.
Ray
Hi Alex,
if I understood it correctly, you can generate an intermediate output file by redirecting:
lammps_executable <input_file > output_file
The output_file will contain the same information log.lammps will have eventually, but the latter is generated only after the run is completed. Thus one can know from the output_file how many timesteps the simulation has gone through.
– Abrar
Hi Ray,
Thanks for the quick response.
This suggestion does indeed give me incremental print outs of the steps it progresses through, but seems to still require me to enable the 'thermo' option. I do not need thermodynamic information, and only suggested it as it was the only option I came across which does something at specified intervals in the simulation.
To me, the documentation suggests that 'thermo' doesn't just print information, but actively involves computation and communication among ranks prior to reporting the actual thermodynamic info. If 'thermo_style custom step' is used, does that mean the ranks do not actually collect thermo information, or will it perform the work regardless, but just print out how many steps it has worked through?
Thanks,
Alex
Hello Abrar,
Thank you for the suggestion. I am not looking for a method to redirect the actual output of LAMMPS itself, but to change its behavior such that it tells me how far it is through the simulation, e.g. like a progress bar in a file download from a website. When I run my simulations, I tell LAMMPS exactly how many steps to perform before stopping, so knowing this information at the end of the simulation becomes redundant. Instead, I would like to know roughly how much progress it has made after some amount of time.
Thanks,
Alex
The overhead is negligible for printing only the time step. And particularly if it only happens infrequently. If you worry about these little perfor.ance savings, yhen there are a lot of other things to look at first.
Axel.
Your understanding is wrong and what you claim make no sense.
Axel.
Axel,
Thank you for clarifying, I understand the act of printing does not add overhead. I am not focused on increasing performance, nor am I focused on the efforts LAMMPS makes to just print something.
My goal is to simply have LAMMPS tell me its progress. I just happen to be mentioning 'thermo' as it is the only command I am familiar with which provides such a functionality. Is there a more appropriate command to do this (instead of asking LAMMPS to collect thermodynamics data from other ranks)?
-Alex
Axel,
Thank you for clarifying, I understand the act of printing does not add overhead.
please read the code and please read my answer properly. i didn't mean
the printing only, i did mean the whole process and said so. it is a
mistake to make assumptions about a code without knowing how it works
internally. ...and ray and i *do*.
I am not focused on increasing performance, nor am I focused on the efforts LAMMPS makes to just print something.
then why do you worry? you are not making much sense here.
My goal is to simply have LAMMPS tell me its progress. I just happen to be mentioning 'thermo' as it is the only command I am familiar with which provides such a functionality. Is there a more appropriate command to do this (instead of asking LAMMPS to collect thermodynamics data from other ranks)?
there is no more appropriate command and you are making the wrong
assumptions about how LAMMPS works. it is much smarter than what you
assume it is. if you have any doubts about ray's suggestion, use the
scientific method: make a test.
run the same simulation with different values of thermo (1, 10, 100,
1000, 10000, default) and see what difference it makes.
anyway, if you don't care about performance, what does it matter?
axel.
Axel,
Thank you for clarifying, I understand the act of printing does not add overhead.
please read the code and please read my answer properly. i didn't mean
the printing only, i did mean the whole process and said so. it is a
mistake to make assumptions about a code without knowing how it works
internally. ...and ray and i *do*.
I never made a claim like this nor assumed you do not know what you are talking about. It was also not an intention of mine for it to be interpreted as such, either. I apologize.
I am not focused on increasing performance, nor am I focused on the efforts LAMMPS makes to just print something.
then why do you worry? you are not making much sense here.
I do not run simulations primarily for the purposes of doing natural science.
LAMMPS is a very useful application I use for doing systems-level (i.e. hardware, operating system, distributed runtime) studies on large-scale clusters. My goals are to focus on measurements and analysis of how applications run in the environments I provide them with.
The reason I stated 'I am not focused on performance' was to suggest (albeit poorly) that my end goal is in new systems-level understandings that can benefit HPC applications, and not to primarily optimize LAMMPS itself.
My goal is to simply have LAMMPS tell me its progress. I just happen to be mentioning 'thermo' as it is the only command I am familiar with which provides such a functionality. Is there a more appropriate command to do this (instead of asking LAMMPS to collect thermodynamics data from other ranks)?
there is no more appropriate command and you are making the wrong
assumptions about how LAMMPS works. it is much smarter than what you
My questions have been phrased such that I try to convey I am not wanting to make assumptions. The entire reason I have been emailing this list is for someone to correct me in the first place.
assume it is. if you have any doubts about ray's suggestion, use the
I never had such doubts. I just wanted to clarify that we were at the same understanding in the conversation...
You can turn thermo output off (thermo 0) and use
the fix print command to print a message (whatever you like)
every N steps.
Steve
I am wondering why Axel Kohlmeyer is always ‘angry’ (In an educated forum like this, communications should be more polite). Maybe my understanding is wrong again!
– Abrar
It makes sense, at least for me, because that is the way I look at the intermediate results during my simulations. Now I see a suggestion from Steve which says to use ‘fix print’ to print a message after a desired no. of time steps. That’s the way you inform things, not just by saying ‘what you claim make no sense’.
Thanks.
– Abrar
It makes sense, at least for me, because that is the way I look at the
intermediate results during my simulations. Now I see a suggestion from
it makes no sense, because there is no intermediate storage. this is a
wrong explanation and you have not presented any explanation that can
back it up. also, it was not addressing the question that was asked.
the statements that create output to the log file and to the screen
are *always* right next to each other. just read the source code.
that you do not see the log file being written to immediately, is a
machine specific thing and most likely the result of caching. either
from the stdio library or form the (networked) file server that is
hosting the file system. output to the screen is typically line
buffered instead of block buffered like file i/o. have a look at the
thermo_modify documentation and look for the flush keyword to find a
way to beat the OS based block buffering (you cannot beat the NFS (or
similar) buffering, since that is set by the server).
Steve which says to use 'fix print' to print a message after a desired no.
of time steps. That's the way you inform things, not just by saying 'what
you claim make no sense'.
i *did* answer to the person and tell him that his concerns were
misguided and that ray's suggestion was good (which it still is). it
is equally good as steve's suggestion in terms of how it affects the
performance of the simulation.
if you cannot handle that somebody tells you are wrong, you may be in
for some bad surprises in the future. i have made the experience, that
when people are polite is often much more insulting.
axel.
Abrar,
I have to be fair and jump in to say that your previous statement,
attached below, is incorrect in many ways:
1. "output_file" does not contain the same information as log.lammps
does. What " > output_file" simply does is printing screen output to
a file, which is different and more terse than the detailed log.lammps
output file.
2. "output_file", just like screen outputs, are written *during* the
run, not after the run is completed.
3. Your statement of "Thus one can know from the output_file how many
timesteps the simulation has gone through." makes even less sense
because if you claim that output_file is only written after the run is
completed, how can one know of the progress of the run by looking at
the output_file?
Cheers,
Ray
A word of advice here:
Do not take things personally and focus on benefiting from the advice you’re given. Email is pretty bad when it comes to guessing somebody else’s mood. Leave to the moderators judge when a commenter has gone out of boundaries. The phrase “Your understanding is wrong and what you claim make no sense” certainly does not aim to pamper you, but I would not call it offensive. Remember that our culture also reflects in our writing, etc.
Ultimately, if the guy is always angry (I have never met Axel thus couldn’t comment on this), who cares?, You don’t have to leave with him 
Carlos
I am wondering why Axel Kohlmeyer is always 'angry' (In an educated forum
like this, communications should be more polite). Maybe my understanding is
wrong again!
a) i am not angry, i am sometimes aggressive. that is not the same
b) i tell things like i see it. most people prefer this over being me
being polite and letting them waste their time by believing something
that is not correct.
c) if you notice carefully, you will see that my degree of
aggressiveness is very much correlated with the degree of usefulness
that somebody's contribution to a discussion. if you look through the
mailing list archive, you will see many cases, where i am very helpful
and polite. but that is in response to people that pose well
formulated problems and provide sufficient information, so that it
doesn't take asking 20 questions until it is possible to *really*
solve the problem
to explain a bit further, you have to realize that all answers given
here are by people that volunteer their time. so i consider it the
duty of everybody that is *asking* for help, to make a significant
effort to make it easy to provide the help. giving bad advice or not
providing incomplete information is distracting from that and usually
requires spending more time on something that is not worth it. but for
the most part it is the "most valuable time", i.e. the time that would
otherwise be spent on improving things. specifically people with
little experience in research often feel offended by the rough tone,
however, that is long before they been cheated, deceived, lied to,
stabbed in the back and whatnot by their colleagues, when the compete
for the same resources (i.e. money or people). at that point at the
latest, you will prefer dealing with somebody that is blunt and
straight rather then somebody that worries about your personal
feelings first, even if you are wrong.
give it a bit of time, observe, and don't take it personal.
you'll likely see things differently.
axel.
Hi Ray,
I really appreciate your answer. I wrote: “The output_file will contain the same information log.lammps will have eventually, but the latter is generated only after the run is completed”.
I didn’t say that ‘output_file’ is generated after the run is completed, I meant the log.lammps (‘the latter’). Yes, it is true that log.lammps has more details, and perhaps I should not have been written ‘contain the same info’, but I thought that difference wasn’t important since the discussion was how to know how much progress lammps has made. Later Alex has clarified in a nice way what his goal was, and so far Steve’s solution seems to be the best work-around (doesn’t invoke ‘thermo’).
Best regards.
– Abrar
Axel,
Thank you for clarifying, I understand the act of printing does not add overhead.
please read the code and please read my answer properly. i didn't mean
the printing only, i did mean the whole process and said so. it is a
mistake to make assumptions about a code without knowing how it works
internally. ...and ray and i *do*.I never made a claim like this nor assumed you do not know what you are talking about. It was also not an intention of mine for it to be interpreted as such, either. I apologize.
apology accepted.
I am not focused on increasing performance, nor am I focused on the efforts LAMMPS makes to just print something.
then why do you worry? you are not making much sense here.
I do not run simulations primarily for the purposes of doing natural science.
LAMMPS is a very useful application I use for doing systems-level (i.e. hardware, operating system, distributed runtime) studies on large-scale clusters. My goals are to focus on measurements and analysis of how applications run in the environments I provide them with.
The reason I stated 'I am not focused on performance' was to suggest (albeit poorly) that my end goal is in new systems-level understandings that can benefit HPC applications, and not to primarily optimize LAMMPS itself.
ok. here we have the source of the entire misunderstanding. it always
helps to clearly state your goals. so far, i only recall one other
case of a person with similar goals posting on a mailing list like
this one (and i'm following several mailing lists for quite a while),
so you have to accept that people will assume that you are "just
another user". your question was quite legit and meaningful and - as
an aside - there are quite a few LAMMPS users that go too far into the
other direction, that is they compute and print out lots of "thermo"
output that they don't need (often at significant expense) and on top
of that force the output to be synchronous, i.e. have additional
penalties due to syncing data to the file system.
indeed, your "progress bar" suggestion might be an interesting feature
to add (albeit in text mode and perhaps in combination with an
"estimated time to finish this run" output, like other MD codes do it.
[...]
there is no more appropriate command and you are making the wrong
assumptions about how LAMMPS works. it is much smarter than what youMy questions have been phrased such that I try to convey I am not wanting to make assumptions. The entire reason I have been emailing this list is for someone to correct me in the first place.
well, lets leave it at that. you have two good suggestions to achieve
what you want to get and you may have inspired a new feature.
ciao,
axel.
Hi Ray,
I really appreciate your answer. I wrote: "The output_file will contain the
same information log.lammps will have eventually, but the latter is
generated only after the run is completed".
I didn't say that 'output_file' is generated after the run is completed, I
meant the log.lammps ('the latter'). Yes, it is true that log.lammps has
more details, and perhaps I should not have been written 'contain the same
what you see in log.lammps and what on the screen or whether you see
anything at all, is completely configurable. have a look at the echo
command and/or the -echo command line flag.
axel.