ovilab / atomify Goto Github PK

Instead of MPI_COMM_WORLD, use another world to let LAMMPS run with a subset of all CPU's. Let the QML thread be mpi thread 0 maybe?
Search for how to do this: https://www.google.no/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=mpi%20qt%20gui

For instance, fix_ave_time.h (and the other average fixes) has a private FILE *fp that we want to access to replace the pointer with an output parser. If more changes are needed to LAMMPS, we might want a script that automatically does this for each new version of LAMMPS.

This way we can parse any command error and show in editor which line is faulty.

This will allow visualizing large data sets with nice performance.

This allows simpler usage where the user don't have to specify in QML how many properties a compute has. compute msd (mean square displacement) has 4 values for instance.

The CP "namespace" should contain wrappers of the internal LAMMPS objects (computes, fix etc) to objects easily accessible from c++ and QML.

If a line in the script ends with '&', the command is assumed to be continued on the next line.

This will then pause the simulation.

We should be able to open/save scripts

Tab_QMLTYPE_9 QVariant(Invalid) QRect(0,0 0x0)
Tab_QMLTYPE_9 QVariant(Invalid) QRect(0,0 0x0)
FocusFrame_QMLTYPE_27 QVariant(Invalid) QRect(0,0 0x0)
ScrollBar_QMLTYPE_20_QML_26 QVariant(Invalid) QRect(0,0 0x0)
ScrollBar_QMLTYPE_20_QML_25 QVariant(Invalid) QRect(0,0 0x0)
FocusFrame_QMLTYPE_27 QVariant(Invalid) QRect(0,0 0x0)
ScrollBar_QMLTYPE_20_QML_26 QVariant(Invalid) QRect(0,0 0x0)
ScrollBar_QMLTYPE_20_QML_25 QVariant(Invalid) QRect(0,0 0x0)
Tab_QMLTYPE_9 QVariant(Invalid) QRect(0,0 0x0)
Tab_QMLTYPE_9 QVariant(Invalid) QRect(0,0 0x0)
Tab_QMLTYPE_9 QVariant(Invalid) QRect(0,0 0x0)
Tab_QMLTYPE_9 QVariant(Invalid) QRect(0,0 0x0)
Tab_QMLTYPE_9 QVariant(Invalid) QRect(0,0 0x0)
Tab_QMLTYPE_9 QVariant(Invalid) QRect(0,0 0x0)
Tab_QMLTYPE_9 QVariant(Invalid) QRect(0,0 0x0)
Tab_QMLTYPE_9 QVariant(Invalid) QRect(0,0 0x0)

This will allow dump and other outputs.

Preferably two sliders for each coordinate direction that can select min/max coordinates of a domain where particles are to be drawn. Other particles should be invisible. This feature will be useful for instance to see cracks in the interior of a domain. (These cracks will otherwise be hidden behind particles).

Implementationwise, we will use one controller with flymode navigation as a mode.

• Add single QML controller
• Add flymode mode
• Add c++ class that handles mouse move in flymode navigation
• Add shortcut / icon in GUI
• Tune parameters so it feels right

Henrik Sveinsson said it felt weird that flymode navigation moves trackball viewcenter. I think I agree. We should consider having two different cameras (basically storing viewcenter, position and upvector for both cameras).

Both exit(1) and MPI_Finalize() are called in error.cpp.

For instance, we might want to use data generated from computes (log temperatures, energy, angles) and do statistical analysis on them live. Histograms, variance, correlations etc.

When writing a LAMMPS script, hovering over a command (or cmd/ctrl click) should open manual on that specific command.

List of js graphing libraries here: http://thenextweb.com/dd/2015/06/12/20-best-javascript-chart-libraries/

Explained here: http://vcg.isti.cnr.it/Publications/2006/TCM06/Tarini_FinalVersionElec.pdf
GPU accelerated on one of its citations.

Also figure out an easy way to use lammps package system.

Idea: each compute will be added to the thermo_style in LAMMPS. The output from LAMMPS is then parsed and values are extracted in a parser. The values will then be set on the computes c++/QML-objects so plotting etc is done easily in QML.

QObject::connect: signal not found in Visualizer

This is best solved by implementing SimVis billboards with geometry shaders.

Choose correct OpenGL profile like explained here:
http://codedivine.org/2014/05/24/specifying-opengl-version-to-qt-quick-2/

We can use the precomputed neighbor lists to on the fly compute neighbor pairs.
We need a renderable for this...

These should use fixes in LAMMPS when changes are done.

Like Qt Creator, we should try to parse the script whenever a new line of commands are written. If a command does not parse (syntax error), we should show this in the editor with the error message shown on hovering.

In library.cpp, there are already functions for extracting computes, variables etc.

LAMMPSController is now kind of messy. We want:

• move file handling and string parsing into another class
• create functions for extracting LAMMPS variables, computes, fixes etc
• fix so LAMMPSController works as an intuitive state machine where each tick() is more planned and less hacked

For instance: when we have output from worker thread, they are immediately parsed. These values are then set to the CPCompute objects updating QML objects (another thread) at the same time.