Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Core: add optional disorder/mixing for atoms of basis #143

Closed
GPMueller opened this issue Mar 8, 2017 · 8 comments
Closed

Core: add optional disorder/mixing for atoms of basis #143

GPMueller opened this issue Mar 8, 2017 · 8 comments

Comments

@GPMueller
Copy link
Member

In the input, for each basis atom, optionally specify

type, percentage

so that the whole input becomes

position, magn. moment, type, percentage

Of course the pairs for such a case need to contain all possible combinations for each interaction pair (for two possible types on each site that means 4 combinations).

i, j, type_i, type_j, interaction constants...
@GPMueller
Copy link
Member Author

This would require (on the example of exchange pairs) something along the lines of

if (atom_types[ispin] == exchange_pairs[ipair].type_i)
{
    // calculate ...
}

which would automatically incorporate defects, which could be encoded as atom_types[ispin]=-1, but I expect all these if statements would be very costly unless the loops were parallelized...

@GPMueller
Copy link
Member Author

Implemented a first defects implementation with 05d651d.
the cmake option SPIRIT_ENABLE_DEFECTS is OFF by default to prevent performance loss when not using defects.

Missing:

  • Hamiltonian_Neighbours update
  • Input parser for defects
  • corresponding updates of Hamiltonians' constructors

@GPMueller
Copy link
Member Author

Since 763c977, it is possible to implement disorder in terms of vacancies. To implement multiple atom types, a little more work would be needed.

@GPMueller
Copy link
Member Author

GPMueller commented Jun 17, 2017

This should probably be the design:

  • when no atom_types are specified, all atoms are of type 0
  • when e.g. atom_types 3 is specified, 3 following lines are read in
  • one atom type line should contain atom index (within the basis), atom type (simply another int) and concentration (each basis index should in summation have concentration 1, otherwise it will be between atom types 0 and the specified)
  • Open Question: the atom type lines may need to also contain mu_s in order to have site- and atom-type-dependent magnetic moments
  • atom types don't need to be sequential or start at 0, but pair-wise input needs to correspond to the specified atom types in order to work as expected

Example 1:

Single atom basis with 50% chance of containing one of two atom types (0 or 1)

# iatom  atom_type  concentration
atom_types 1
    0        1          0.5

Example 2:

Two-atom basis where the first atom is type 0 and the second atom is 70% type 1 and 30% type 2

# iatom  atom_type  concentration
atom_types 2
    1        1           0.7
    1        2           0.3

Pair input:

This should have the following form:
i, j, type_i, type_j, interaction constants...
If either type_i or type_j is not contained in the header, both should be set to zero.

@GPMueller GPMueller changed the title Core: add disorder for multi-atom basis Core: add optional disorder/mixing for atoms of basis Dec 5, 2017
@GPMueller
Copy link
Member Author

GPMueller commented Feb 2, 2018

As soon as atom_types, i.e. disorder, is specified mu_s needs to be given per site and type. For two sites and types this would look like

# iatom  atom_type  mu_s
mu_s
    0        1           2.2
    0        2           3.2
    1        1           2.4
    1        2           3.4

Alternatively, mu_s could be specified together with percentages, as an additional column, in atom_types.

@GPMueller
Copy link
Member Author

Now that #364 has been implemented, the representation of mu_s can also be re-thought.
Probably, the Geometry should generate a full list of mu_s for all spins, which could include disorder etc. - this list could be re-generated or adapted when the system size is changed.

@GPMueller
Copy link
Member Author

GPMueller commented Jul 8, 2018

With 978682a, mu_s and cell_mu_s are now distinguished.

Note that - in the current design - cell_mu_s and cell_atom_types somewhat lose their meaning when there is disorder across the lattice. Can this somehow be remedied?

One option here would be to implement #421 and allow the disorder to create a large basis cell, instead of a lattice. Togehter with #420, this would probably be the most efficient way (in terms of calculation time).

@GPMueller
Copy link
Member Author

Refactored cell_mu_s and cell_atom_types into a Basis_Cell_Composition struct and added disorder input parameters with 524413f.

The Basis_Cell_Composition contains everything that is needed to reconstruct an ordered or disordered geometry when parameters are changed.
The input is for example

# iatom  atom_type  mu_s  concentration
atom_types 2
    0        0       1.0      1
    1        1       2.5     0.7
    1        2       2.3     0.3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant