I am a green hand in lammps. But from an amateur programmer’s point of view, lammps’ in.script is really hard to debug, especially multiple fixes are written together. So I think a basic debug function should be added into lammps’ commandline to ensure us to locate which line in the in.script went wrong easily.
The log file usually gives the error directly after the botched command. So if you have a bunch of fixes, one after the other, you can see which one lammps failed to parse.
Quoting ?? <[email protected]>:
the general idea is not bad, problem is to make it work
reliably. particularly since LAMMPS supports reading from
standard in or passing commands through the library interface
as simple strings. it would work fine, if using the -in flag
and the include statement would be the only ways to read
input (which has some appeal, particularly in parallel use).
in the current form, what should one do in this case?
cat part1.templ job1.in part2.templ | ./lmp_linux
The log file usually gives the error directly after the botched
command. So if you have a bunch of fixes, one after the other, you
can see which one lammps failed to parse.
...and as an additional help there is the age old
debugging technique of adding print statements to
your "program" (which the lammps parser supports)
and thus narrow down the problem.
If you run it as
lmp_foo -echo screen < in.script
you will see exactly what line generates an error.
The same info is in the log file.
(-echo log is the default, -echo both is also an option)
Thanks! It is exactly what I want.
I think ‘-echo both’ should be set as default. Or adding a debug section into the documentation is admirable.
I am sorry I never touched log.files because I thought it is just a copy of screen out.
I think “-echo both” is what I need.
“print” statement is also very useful but it is a little trival to add and delete them. Why not to add an option to print all “## comments” to the screen as a substitution of “print”. I mean when the option is turned on, all “## this is $v” can be translated as “print this is $v”. It sounds like very stupid, haha~~
doc/Section_errors.html, 9.1 "Common errors" is a debug section.
If you get an error message about an invalid command in your input
script, you can determine what command is causing the problem by
looking in the log.lammps file or using the echo command to see it on
Echo both is not going to be the default. I like uncluttered output.
Sorry, I simply treated Lammps as a programming script language. I just searched the docs using keyword “debug” and jumped the section you replied to me.
That's ok - no one reads the manual. I wrote it, and I don't read it.