spirit-code / spirit Goto Github PK

This is due to the need for two build targets, but this can be circumvented somehow.

This needs to be verified for other Linux Systems, since OSX and Windows are not affected.

When pressing one of the configuration Buttons, the renderers produce OpenGL errors in their respective updateSpins functions (e.g. SphereSpinRenderer l. 75).

It is unclear why this happens.
The initialisation is fine, simulations can be run as well.
Only the changing of the current state and subsequent update of the renderers crashes the program. It might thus be related to the update call coming from SettingsWidget.

Since alt+mouse1 may be a system keybind which interferes with the program, it would make sense to be able to move the camera using just mouse2, analogous to camera rotation with mouse1.

The axis is hidden when the background and the axis are both white.
Maybe there should be a small (e.g. circular) background behind the coordinate cross in this case? or maybe thicker gray lines placed behind the colored lines?

It needs to be checked wether the vectorfields etc. are immediately allocated on device, or only if they are passed into a kernel...
If all datasets use vectorfield etc. instead of std::vector, this might become a memory problem on the GPU...

We need a proper surface mode for 3D systems. Features should include:

• contour surfaces (z slider)
• planar cut of the system
• block cut of the system

This is the only Optimizer which needs extra backend functions.

The Hamiltonians do not properly exhibit the following structure:

• Energy Contributions per spin should be calculated per spin and saved in a scalarfield
• Energy Contributions should be calculated by contracting the per_spin arrays
• Energy should be calculated as the sum of contributions

The last point should be done in the base class.
By using scalarfields, the functions can be nicely ported to CUDA.

Should improve support for different spin file formats (CSV, table, with and without spin position). Better Energy file output would also be nice

Maybe this is not so doable currently.

The C++17 Filesystem TS might be a possibility...

Since #4 is done, the behaviour of the surface visualisation needs improvement:

• The surface is a regular s_z=0 isosurface on startup (function needs to be set before first draw)
• The function for the isovalue now needs to be improved such that the surface can be moved more gradually and up to the bounding box.

The following screenshot shows the latter problem

This would be analogous to switching to climbing/falling, but it would mean the image is not moved at all, acting as a new boundary inside the chain.

For these options a new enum class { normal, climbing, falling, stationary} should be created.

The Anisotropic is the first Hamiltonian which should receive a CUDA backend.

Examples of Classes or Namespaces which (I think) format strings separate from each-other:

• Optimizer
• Method
• IO_Configwriter
• Logging
• IO_Filedump

It would be quite nice to have an output file which contains ALL the necessary parameters which were important to do the calculations:

• input parameters from the .cfg
• interaction parameters
• spin dynamic relevant stuff (e.g. algorithm or whatever you can choose) ...

With this you are one the one hand able to check whether you choose the good parameters (which can be confusing as the parameters are only read once at the start of the program) and on the other hand it's easier to reproduce data.

The file should somehow have the same time stamp as the corresponding log. It would of course be nice (but not mandatory), if this file would have a format which can be used to start directly calculations based on it ;)

The orthographic projection of the coordinate cross seems to change with the proportions of the window (in contrast to the other renderers). Two examples for non-quadratic windows:

The getters do not propagate the changes out of the function, as vec3(vector) creates a new instance, copying the values of vector.
Functions have to be rewritten such that the values are copied into the original array or list after the shared library function has been called.

For very large systems this becomes a big issue.
It is unclear how to optimize the first part.

The second part (verification that no two spins are on the same position can be easily made by checking the basis and checking for overlaps when translating the basis in any combination of the translation vectors.

Optimizers:

• SIB
• Heun
• VP

See also #2

Create option to auto-generate seed by DateTime? Otherwise multiple images which were initialized with Random exhibit the same configuration.

We should think about what should happen when a system is copied.

This should be done such that severe exceptions are logged and the code is ended as gracefully as possible.

Useful quantities for convergence plots:

• max_torque
• E_tot (LLG)
• M_z (LLG)

They should be implemented in the Method base class and they should be updated every log_steps

Before, the initial force that was displayed was sometimes nonsense.
Currently, it is not displayed at all.

An almost Fullscreen visualisation would suffice, but menu bar, dockwidgets and other controls should be hidden

Ideas are std::map or std::pair or std::touple.

This way, the difderent contributions can be labeled with strings, only adding those contributions which are nonzero. The file or console output could be nicer this way, as only the relevant contributions would be outpt

It appears that when the corresponding box is hidden, the contents is not read correctly and the simulation can thus not be started correctly.

This is an issue on the master branch: cd3e452 i.e. v1.1.0

Save Settings and load them at startup:

• controlWidget settings
• general settings
  • mode
  • miniview
  • coordinatecross
• background color
• camera
• arrow size and lod

Hamiltonian base class has FD gradient and Hessian.
The Hessian is most likely incorrect, the gradient might be too.

This function should probably be placed into Utilities

Energy per spin becomes imprecise when the number of spins grows large. In the file output it should thus be total energy (not per spin).
Maybe build a switch which one to use in console print?

• per spin
• per unit cell
• total

Numerical imprecision results in a flip of the camera if one quickly zooms into the origin

This would be useful, especially for skyrmions

The default input needs to be checked in terms of convergence parameters etc.
The UIs should use input.txt in order to make it easier for people to use.

• Energy
• max Torque
• total z magnetization

This needs intensive investigation...

Being able to create a relocatable .App for OSX would be a very useful feature.
If we would attach the resulting .App's to the GH releases, we would need to check license conditions first.

We need to decide wether to save the effective field or the force.

The Method::Post_Iteration function is where the data should be copied to the spin system. The Method should have a temporary data member for this.

In the case that we want to visualise e.g. the effective field or forces, we need the vectors to either scale their size or e.g. their transparancy (probably not so well possible) with the vector magnitude.

Hamiltonian_Anisotropic uses std::vector to store two ints!

Currently, due to alignment issues on Windows with std::vector<tetrahedron_t>, it is copied into an array and the pointer to that array (instead of a pointer to the first element of the vector) is passed out through the API.

Because this array is not deleted, the memory is leaked.

It might make sense to use something different than the tetrahedron_t struct...

This should be implemented after #14

Methods:

• LLG
• GNEB

These are needed for the Anisotropic Hamiltonian to be useable in a dynamic scenario.
Example: changing Jij in the Web UI (since the long-term goal is to remove the Isotropic Hamiltonian).

For z-range sliders, double sliders would be nicer than two coupled sliders.

Here is an example implementation: http://stackoverflow.com/a/26025796

The Hamiltonian should contain a switch between Neel and Bloch type DMI vector orientation

It would make sense for the code to save the list of neighbours or pairs for the dipole-dipole interaction. In the case of pairs, it should of course only save the pairs of one basis cell.
A keyword should be added indicating a file from which to read the neighbours/pairs on startup.