Missing atoms

343 views
Skip to first unread message

Milton Persson

unread,
May 5, 2020, 10:07:51 AM5/5/20
to Vampire Users
Hi all!

I was just tring to create a multilayer system with random alloys, but according to the log file 3 out of the 7 materials (making up 20% of the thickness of the sample) are missing:

28-04-2020 [18:33:40] Calculating alloy properties of system
28-04-2020 [18:33:40] Determining atomic composition
28-04-2020 [18:33:40] Material 1 Ni makes up 23.5347% of all atoms.
28-04-2020 [18:33:40] Material 2 Fe makes up 6.09491% of all atoms.
28-04-2020 [18:33:40] Material 3 Ni makes up 27.9051% of all atoms.
28-04-2020 [18:33:40] Material 4 Cu makes up 42.4653% of all atoms.
28-04-2020 [18:33:40] Material 5 Ni makes up 0% of all atoms.
28-04-2020 [18:33:40] Material 6 Fe makes up 0% of all atoms.
28-04-2020 [18:33:40] Material 7 FeHard makes up 0% of all atoms.

Honestly the data in the output file seems reasonable and it might be that the only problem is in the log file.

I have attached the material file, input file and log file. Is there anyone who recognizes this? Anyone who could please tell me what's going on?

input
Py-NiCu-Py-FM.mat
log

Luke Elliott

unread,
May 6, 2020, 8:17:23 AM5/6/20
to Vampire Users
Hi Milton,

Just looking over your material file, you have most of the materials set to max/min height of 0 with only three nickel layers and FeHard given heights (materials 1,3,5,7). It would be better to explicitly set the heights for each material. You can also have a 'background' material set across the whole system by setting min-max 0 to 1.

So stating material heights explicitly should be a good starting point.

Hope that helps,
Luke

Milton Persson

unread,
May 14, 2020, 9:05:01 AM5/14/20
to Vampire Users
Thanks for your reply Luke!

The materials 1, 3, and 5 are host materials for three random alloys with material 2, 4, and 6 being the respective donor materials. Are donor materials not always supposed to have max/min height of 0, as in the tutorial on random alloys?
Anyway I tried what you suggested and Vampire did not complain. The log file still looks strange, but different, and it still looks like atoms are missing:

11-05-2020 [16:39:32] Calculating alloy properties of system
11-05-2020 [16:39:32] Determining atomic composition
11-05-2020 [16:39:32] Material 1 Ni makes up 0% of all atoms.
11-05-2020 [16:39:32] Material 2 Fe makes up 10% of all atoms.
11-05-2020 [16:39:32] Material 3 Ni makes up 0% of all atoms.
11-05-2020 [16:39:32] Material 4 Cu makes up 70% of all atoms.
11-05-2020 [16:39:32] Material 5 Ni makes up 0% of all atoms.
11-05-2020 [16:39:32] Material 6 Fe makes up 10% of all atoms.
11-05-2020 [16:39:32] Material 7 FeHard makes up 10% of all atoms.


The results are different and honestly those from using max/min height of 0 make more sense.

Thanks anyway, and if you've got any other ideas please let me know.

Luke Elliott

unread,
May 14, 2020, 9:39:45 AM5/14/20
to Vampire Users
Hi Milton,

My mistake, I misunderstood the random alloys part of your question and thought you were doing a standard multilayer stack - admittedly probably because that's what I do in my own work!

In this case your material file looks correct as far as setting up your geometry. I just did a quick run with your inputs but only one step to generate the crystal using config:atoms and the generated structure looks to be correct.

crystal.png


This is usually the most reliable way to check your generated structures. Do a time-series run with one timestep and the config:atoms flag. Then the structure can be visualsed using VDC and any crystal viewer, e.g. JMOL.

I also noticed you're using sim:enable-dipole-fields. I'm guessing you're using the master branch? You may find it useful to move over to the develop branch if you're using VAMPIRE regularly, it's master is primarily for tracking major releases but develop has a lot of quality of life improvements, like improved VDC, and new features like different dipole solvers.

If you do move then you'll need to switch sim:enable-dipole-fields to dipole:solver = tensor as a starting point.

Sorry for the initial confusion, hope this has laid your mind to rest!

All the best,
Luke

Milton Persson

unread,
May 20, 2020, 11:03:37 AM5/20/20
to Vampire Users
Alright, thanks! I'll try to move over to the develop branch. Since it looks fine I guess it's possible for the problem to be with the generation of the log file and nothing else.

By the way, when you create multilayers do you run into the problem of not getting precisely the number of monolayers you ask for? For example, if I want 2 monolayers of material 1, 11 monolayers of material 2, and 2 monolayers of material 3, then in the material file I would write:

material[1]:minimum-height = 0.0
material[1]:maximum-height = 0.13333333333
material[2]:minimum-height = 0.13333333333
material[2]:maximum-height = 0.86666666667
material[3]:minimum-height = 0.86666666667
material[3]:maximum-height = 1.0
(see crystal_old.xyz)

this, however, gives me 2 monolayers of material 1, 12 monolayers of material 2, and only 1 monolayer of material 3. To get the desired structure the lines in the material file have to be changed to

material[1]:minimum-height = 0.0
material[1]:maximum-height = 0.13333333333
material[2]:minimum-height = 0.13333333333
material[2]:maximum-height = 0.86666666666
material[3]:minimum-height = 0.86666666666
material[3]:maximum-height = 1.0
(see crystal.xyz)

i.e. I have to truncate the decimal representation of (2+11)/15 = 0.866... instead of rounding off. Is it a general rule that one should always truncate these numbers instead of rounding them off, or is there some other way around this problem?
crystal.xyz
crystal_old.xyz

Luke Elliott

unread,
May 21, 2020, 6:57:54 AM5/21/20
to Vampire Users
Yeah I think it's fair to say that's an issue with the log file.

In terms of system generation, I did have issues getting exactly the structure I wanted in the way you describe. This is a natural limitation of system generation, i.e. not VAMPIRE specific, as your dimensions are unlikely to line up perfectly and some materials will have to take precedence over others.

My solution is to set the overall system size to a clear multiple of unit cell size, in my case my z system size is 20 x unit cell size so each 0.05 is one unit cell, then I don't allow the heights in my UCF to overlap, e.g I would use material[1]:maximum-height = 0.8 and material[2]:minimum-height = 0.81, then visually inspect any generated structures before use.

Hope that's useful!
Reply all
Reply to author
Forward
0 new messages