dump-atoms output size?

Hi everyone,

I am trying to port LAMMPS to use the ADIOS I/O library. One of the requirements is that you know how large your output arrays are. Right now, I’m just doing the dump_atoms stuff, but I can’t for the life of me figure out how large the buffer is.

I assume that each rank is outputting some number of atoms: what is this number of atoms? in dump.h there is an “nme” field. Also, for each atom, there are some number of additional fields defined, so I assume that’s the size_one field?

for example, in dump_atom.cpp:write_noimage, it accepts and integer n and a double* mybuff. I assume n here is the number of atoms each rank is trying to dump?

Thanks!
Josh

The number of atoms each MPI rank will contribute to the output is atoms->nlocal.
The atom style dump has multiple output modes. It can write one or multiple files.

The number of atoms in total and the number per process can change.
Same goes for the order.

If the file format does not support this, you better look at a dump style like dcd, where both has to be preserved and thus the data is collected and sorted on rank zero.

Axel.

I see. I am porting it to the ADIOS API for research purposes. I’m not sure if multifile or not is what I need. I guess I will have to look further.

I see. I am porting it to the ADIOS API for research purposes. I'm not sure
if multifile or not is what I need. I guess I will have to look further.

the question is whether you want parallel i/o or not. the native
lammps dump supports *both*, writing from rank 0 only and writing from
multiple ranks. in the second case, however, lammps doesn't have an
interface to parallel i/o and simply creates multiple files.
axel.

Okay, yes, I want each rank to basically output its atoms array… basically, I will need each rank to make the ADIOS calls.

You can look at the logic that gets invoked in dump
atom or dump custom when a % char is used in the filename.
In that mode, each proc writes its own output file. It
sounds like you want the ADIOS hook to do the
same thing.

Steve

Yes, that is exactly correct. I want ADIOS to hook into the same thing. Thanks!!

Hi All,

A month later, after putzing around with other stuff, I’m back to trying to port the dump routine to some RDMA I/O methods. Right now, i just want to start with something simple, get it working, and then incrementally add more.

For starters, I am looking at the header_item and dump_noimage routines in dump_atom.cpp (I am still using the 27jan13 build, so if things have changed drastically with respect to dump_atom, please let me know).

Here is my current understanding (so please correct me if I’m wrong):

header_item outputs some scalars. This part I have ported and working with no trouble.

With write_noimage, “n” seems to be the number of atoms, and mybuf seems to contain n * size_one elements, where size_one is found in dump.h and represents the number of doubles associated with each atom (so, 10 atoms, 5 elements each, mybuf should be sized 5 * 10 * sizeof(double)). I have it so that write_noimage is indeed called by each rank (which is indeed what I want).

Previously, it was mentioned that atoms->nlocal is what each rank will output, and from looking at atom.h, natoms is the total number across all ranks. Basically, when write_noimage is called, each rank will output the global_size (natoms), the size of it’s chunk, and the offset of this chunk in the global array. (which I can calculate using MPI_Scan and that sort of thing).

How do I make this information accessible in dump_atom.cpp (natoms)? I think then that atoms.h:nlocal ends up being passed in to write_noimage as n. Is the ndump variable of header_item “natoms”? I’m quite confused :slight_smile:

Sorry for reviving this a month later!

Josh

Ideally, once I’m done with this port, I’d like to make it available for reads and writes (molfile’s perhaps?) so others can use it and do some online analytics and that sort thing.

Josh

nevermind… stupid question… atom->natoms, atom->nlocal… as Axel already stated earlier.

sigh…

Josh