Dear LAMMPS-users,
I have a problem when using the binary2txt tool from the "tools" folder in the LAMMPS distribution. In my simulations I produce binary dump files of style "custom", and the simulation runs without error.
I compile the binary2txt tool on the same machine as the simulation was run on, without any compilation errors. Yet, when I try to run the tool by writing a command like "binary2txt myDumpFile.bin", I get the following message on screen:
myDumpFile.bin: 14637248544768Segmentation fault
Does anyone have any idea about why this happens? I have tried compiling the binary2txt tool on our supercomputer as well, in order to extract binary files which were produced on that machine, but also here I got segfaults.
In the file binary2txt.cpp I can not see any sign of the new type of LAMMPS dump format, where the header "ITEM: ATOMS" also contains headers with the names of the properties. Could this be the problem - that binary2txt.cpp is not (yet) updated to the "new" LAMMPS dump file style? Or can you find other reasons for my segmentation faults?
I would be very thankful for any suggestions. We have some rather large simulations that have produced binary dump files, and it would be a lot of time wasted if we have to run them again.
Sincerely,
Christer H. Ersland.
dear christer,
Dear LAMMPS-users,
I have a problem when using the binary2txt tool from the "tools" folder in the LAMMPS distribution. In my simulations I produce binary dump files of style "custom", and the simulation runs without error.
I compile the binary2txt tool on the same machine as the simulation was run on, without any compilation errors. Yet, when I try to run the tool by writing a command like "binary2txt myDumpFile.bin", I get the following message on screen:
myDumpFile.bin: 14637248544768Segmentation fault
Does anyone have any idea about why this happens? I have tried compiling the binary2txt tool on our supercomputer as well, in order to extract binary files which were produced on that machine, but also here I got segfaults.
you can help to track down why this is happening. can you do the
following steps?
- compile binary2txt with the -g flag added to the compiler command line.
- type "ulimit -c unlimited" to enable coredumps
- run the new binary2txt and wait for the segfault. this will also
produce a file called core.###, with ### being some integer number
- now run: gdb binary2txt core.###
- and when that is started type: where
and report that output here.
thanks,
axel.
Dear Axel,
I tried to follow the steps, and at first I did not find any core.### file. After some searching I found it in the folder /cores on my machine (I'm on a Mac). With this I got the following from gdb:
(gdb) where
#0 0x00007fffffe00d3f in __memcpy ()
#1 0x00007fff5fbff030 in ?? ()
#2 0x00007fff88ff844d in fread ()
#3 0x0000000100001c4c in main ()
Hope that this makes some sense to you. Please let me know if you think I have done this wrong or if you need additional information.
Sincerely,
Christer H. Ersland.
I don't have any problem running the current version of binary2txt.
Try adding either of these lines to bench/in.lj, and then
using binary2txt on the dump file:
dump 1 all atom 50 tmp.dump.bin
dump 1 all custom 50 tmp.dump.bin id type x y z vx
Steve
Dear Axel,
I tried to follow the steps, and at first I did not find any core.### file. After some searching I found it in the folder /cores on my machine (I'm on a Mac). With this I got the following from gdb:
<sigh>macos x has become so much mutilated from the original BSD it
was based on,
that it is becoming as much a pain to work with than windows.</sigh>
(gdb) where
#0 0x00007fffffe00d3f in __memcpy ()
#1 0x00007fff5fbff030 in ?? ()
#2 0x00007fff88ff844d in fread ()
#3 0x0000000100001c4c in main ()
Hope that this makes some sense to you. Please let me know if you think I have done this wrong or if you need additional information.
this looks as if you didn't compile binary2txt with any debug info included,
so it is not providing any help. it may be, that on macos you need some
special gcc incantation to get that done. you have to find that out, i don't
know anything else by adding -g to the compiler flags.
axel.
Steve and Axel,
I tried Steve's suggestion, and made in.lj output a binary dump file. When running binary2txt on this file, it ended up in some kind of infinite loop (I stopped it when the txt file was about 2 GB big), but I got no error messages.
Regarding the gdb debugging I think there might be something strange with my version of gdb. I can not get it to work properly, but I will work more on this another day. I will report back if I get any useful data out of the debugging.
I will also try to run binary2txt on the supercomputer again, and hopefully be able to debug properly there.
Thank you very much for your help so far!
Christer.
At the top of binary2txt.cpp there is a setting for bigint that needs
to match whatever your LAMMPS box uses in src/lmptype.h. Can
you verify that is correct? E.g. that sizeof(bigint) = 8 in your binary2txt
executable? That would foul things up if it weren't the case.
If you're getting an infinite loop you ought to be able to put a few
print statements in binary2txt.cpp and see where it is hanging up.
Steve
Dear Steve, Axel and others,
I have now tested quite a lot with the binary2txt tool, and it is finally working for me. It seems like I might have used the binary2txt from a slightly older LAMMPS version than the version that produced the dump file I tried to convert. Silly mistake of me, but at least I know how it works now. When I use the correct version of binary2txt I am able to successfully convert binary dump files on both my Mac and on our supercomputer.
One more question though: could the binary2txt file be modified so that the resulting text dump files also contain the correct column headers (id type etc.), just as in regular dump files? Or is this information not saved in the binary dump file at all? In that case, could LAMMPS be modified as to save these headers to the binary dump file, or would this lead to other problems?
Thank you so much for your help on this.
Sincerely,
Christer H. Ersland.
One more question though: could the binary2txt file be modified so that the resulting text dump files also contain the correct column >headers (id type etc.), just as in regular dump files? Or is this information not saved in the binary dump file at all? In that case, could >LAMMPS be modified as to save these headers to the binary dump file, or would this lead to other problems?
That info is not in the binary file. It would have to be added by the
dump command, then decoded
by binary2txt.cpp.
Steve