andeplane/lanvis

Large Atomic Numeriment Visualization

lanvis's Issues

Create LAMMPS Dump importer

The LAMMPS dump file format looks like this:

ITEM: TIMESTEP
0
ITEM: NUMBER OF ATOMS
500
ITEM: BOX BOUNDS pp pp pp
0.0000000000000000e+00 8.3979809569125372e+00
0.0000000000000000e+00 8.3979809569125372e+00
0.0000000000000000e+00 8.3979809569125372e+00
ITEM: ATOMS id type xs ys zs
... (atom positions
ITEM: TIMESTEP
1
...

Consider using files as "server"

For large systems, if atoms are already colored and divided into chunks, we could read the positions by jumping around in the file. If we have some sort of header (another file, i.e. json is fine), we could know exact positions in the file and number of particles and lod levels etc. Then we could navigate a big system.

Rewrite using uint_64 as index data types for very large simulations

Create full serializable class structure

• XYZImporter
• LAMMPSTextDumpImporter
• LAMMPSBinaryDumpImporter
• Importer

Merge all code into src and use qpm to build targets

Handle different time settings on server and client

If the server and client disagrees due to timezones or other reasons, it should still work.

Use low quality (low resolution, low everything) when camera is moving

Read JSON as settings file (slider values etc)

Implement better sorting algorithm

When moving the camera around, the chunks are being sorted so that they are usually almost sorted. According to https://www.toptal.com/developers/sorting-algorithms/, we should probably use insertion sort which is faster on random data and nearly sorted data.

Add mechanism to detect chemical reactons

This could be used to make the atoms flash when it happens.

Create general State class

The State class should be very general. It must have:

• Timestep
• List of particles (objects below)
• Number of particles
• Bonds (pair of indices)
• List of defined computes

Each particle has

• Position
• Type (number which can be mapped from a provided list: "Si": 1 etc)
• Radius
• Color
• N additional quantities

If radius is large, only copy from server when far away from sphere center

Create importers

• Base class ParticleImporter
• XYZImporter
• LAMMPSTextDumpImporter
• LAMMPSBinaryDumpImporter

Comments

The number of columns should be specified in the JSON file describing the importer.

Add message overlay (to show "dumped to /tmp/state.txt" etc)

Add atom id for following across timesteps

Let user show/hide particle types in GUI

Add "load all" option

If the server has a lot of memory and you want to watch time evolution, it can be nice to load all timesteps.

Add update frequency as parameter

Design communication system

Here we denote the simulation as #1, the post processing caching as #2 and the visualization client as #3.

#1 produces data. #1 and #2 communicates either through MPI (another world than COMM_WORLD) or through files. Whenever a new timestep is available, #2 reads that and places atoms in chunks.

Once it has done that, it writes to state.json with new date. The file it writes should be moved to another location after writing so that we don't get problems with writing to a file that we read from.

The client (a Python script) periodically reads the state.json. Once we see an update, we fetch the new file. Once the file is copied over, the state.json is written to client disk so we can update.

Use spirit X3 to parse text files

According to this post, parsing using Spirit X3 is much faster than sscanf or similar. Code here: http://boost-spirit.com/home/2015/05/16/spirit-3-0-0/

Add marching cubes visualization of scalar fields

If a compute measures a 3d scalar field, marching cubes could use this as input to produce iso scalar surfaces. This could be density, stress, whatever.

Add two types of client settings, immediate and non-immediate

Some client settings might take a lot of time on the server (resizing chunks and LOD levels), so some settings should need an apply mouse click.

These are:

• Chunk size

• lod levels

• LOD cutoff
• Server fileName (file to load)
• Server file type (LAMMPS binary, XYZ, etc)

Use octree chunks

Now there is only a single level of chunks. For the 270 million atom system, an ideal chunk size was ~100 Å, but then you get more particles than you want.

Ideally we should have at least three levels of chunk sizes with octrees so a large portion can quickly be sorted out as not relevant, and high resolution chunk sizes (small).

Add modifiers

Modifiers can modify any property of the particle. For instance slice, type coloring, property coloring etc.

Add dump to XYZ button

Add transparency to colors

Add computes which can act on subset or all particles