error :Divide by 0 in variable formula

Dear all,

I have been studying shock wave propagation in Ta. While running the simulation , generally the simulation stops at some time step depending on the parameter of the simulation giving an error
ERROR on proc 0: Divide by 0 in variable formula (…/variable.cpp:2778) . The LAMMPS manual says it is self-explanatory , but I cannot figure out the exact problem . I have attached my script with this mail.

Regards,

Anuradha

Tashock.in (5.21 KB)

Could be this line?

variable meanpress atom -(c_peratom[1]+c_peratom[2]+c_peratom[3])/3/c_vorvol[1]

if c_vorvol[1] is sometimes 0. The easiest workaround is to do /(c_vorvol[1]+1e-99)

Jan

BTW the debugging will be much easier if the error message indicates the line in the input script instead of the line in the source code (../variable.cpp:2778)

Jan

BTW the debugging will be much easier if the error message indicates the
line in the input script instead of the line in the source code
(../variable.cpp:2778)

​if you can figure out a way to do it, please let us know, and we'll
implement it. it is not as simple you might think. i've looked very hard
and i cannot think of a way that can be done without a complete rewrite of
how input is read in LAMMPS. the best i could come up with is to maintain a
copy of the current line of input, that is being processed and output that
in case of errors.

and it is doubly complicated for errors in variable definitions, as the
errors can happen at any time when the association with the input may be
long lost.

axel.

If you can output the line number being processed, that will be already very helpful. Of course, one has to manually look at the variables and computes used at that line, but it is much better to know, where in the script it happened.

I had many times a simple typo in the script, but it was very difficult
to find where. I had to place dummy prints in the script.

I'm not sure I can help a lot here, but if the input script parsing and
reporting of line numbers is expensive, it is not a big deal. You can
activate it with e.g. --debug switch only in case you see errors and use
the fast version without line number reporting for production runs.

In the --debug version you could simply add a dummy print on each line, exactly as I did manually.

Jan

BTW the debugging will be much easier if the error message indicates the
line in the input script instead of the line in the source code
(../variable.cpp:2778)

​if you can figure out a way to do it, please let us know, and we'll
implement it. it is not as simple you might think. i've looked very
hard and i cannot think of a way that can be done without a complete
rewrite of how input is read in LAMMPS. the best i could come up with
is to maintain a copy of the current line of input, that is being
processed and output that in case of errors.

and it is doubly complicated for errors in variable definitions, as
the errors can happen at any time when the association with the input
may be long lost.

If you can output the line number being processed, that will be already
very helpful. Of course, one has to manually look at the variables and
computes used at that line, but it is much better to know, where in the
script it happened.

​but that is what i was telling you is not as simple as it sounds.
processing of input goes through various stages. by the time, the input
parser gets told "parse this line", you can ​no longer tell assign a line
number, that matches a specific line in a file because:
- all lines with a continuation marker '&' have been merged into a single
line, comments and empty lines have been removed
- input may have come from a pipe (where you cannot seek back to the top
and count lines until you reach your current position in the file)
- input processing supports include files, but there is no simple way to
store a stack of per file line numbers.
- input processing will not know whether there is a loop.

basically, take an input with comments, empty lines, loops, jumps, includes
etc. and compare the contents of log.lammps with -echo none to the contents
of log.lammps with -echo log.
​things get even more complex, when you need to consider multi-partition
calculations. like i said, it is not quite as easy as you think. i've
looked this this for quite some time...

​...and that doesn't solve the issue about variables that the definition of
the variable is at a quite different location from where it is invoked.

I had many times a simple typo in the script, but it was very difficult
to find where. I had to place dummy prints in the script.

if you use a recent version of LAMMPS, then any time you have an error,
LAMMPS will print the line that was failing, e.g. like this:

print \{test\} ERROR on proc 0: Substitution for illegal variable test \(\.\./input\.cpp:535\) Last command: print {test}

adding -echo screen would give you the same information, but for all input.

I'm not sure I can help a lot here, but if the input script parsing and
reporting of line numbers is expensive, it is not a big deal. You can

​it is not about this being "expensive", it is about getting access to that
kind of information at all, when you cannot make certain assumptions and
when the parsing of input is done on something that may not be "counting"
input lines in the same way is it is read in.

axel.​