aiida-vasp / parsevasp

A general parser for VASP
MIT License
13 stars 13 forks source link

Adding the capability to parse the total magnetization from the OUTCAR #28

Closed JPchico closed 4 years ago

JPchico commented 4 years ago

I have added a function to parse the total magnetization per cell and per atom as found in the OUTCAR as it is not found in the .xml file for VASP 5.4.

Basically the function finds the first occurrence of the magnetization tag and then finds all the entries that contain the site magnetization and stores them in a dictionary in an orbital decomposed fashion. The same is done for the total cell magnetization.

A method to extract the magnetization via the get_magnetization function is also provided for consistency with the rest of the quantities extracted from the OUTCAR.

JPchico commented 4 years ago

Hello @espenfl ! I was wondering if there was an issue with this PR. I would gladly help to make sure that this is then passed over to the aiida-vasp repo via a PR if you think that this implementation is proper.

zhubonan commented 4 years ago

I would second this PR - at the moment there is no way to get the magnetisation which is essential when working with many materials.

@JPchico perhaps the other thing you can do is to add a test for the new functionality?

espenfl commented 4 years ago

@JPchico Thanks for this PR. Greatly appreciated. Can you please also add a test and then I will get back to accepting it right away. Sorry for not addressing it earlier.

JPchico commented 4 years ago

@zhubonan and @espenfl Absolutely I will add the test and make a new push =) Thanks for your quick reply

espenfl commented 4 years ago

That is great. Awesome, thanks a lot.

JPchico commented 4 years ago

So I have added a test for the magnetization and an extra OUTCAR with magnetization information. I notices that the magnetization is written out twice in the OUTCAR (unsure why) the parser picks up the first entry. If for some reason the second one is preferred I can change it in no time.

espenfl commented 4 years ago

@JPchico Thanks a lot. So I think we also would need the total magnetization in the unit cell as dumped in OSZICAR as the two differ (the one in OUTCAR is just the moments inside the spheres, which is not space filling). If we need both, I am not sure. Personally, I have not done that many magnetization calcs, but for the ones I have, the entries in OSZICAR has been the ones I have been using. This is also indicated here: https://www.vasp.at/wiki/index.php/Constraining_local_magnetic_moments

JPchico commented 4 years ago

Aha no problem I should be able to read those in from the OSZICAR. I have done mostly magnetic calculations in KKR methods so i'm not super familiarized with some of the VASP outputs so that is good to check. My guess is that it depends a bit on what one wants to do, if you are going to be doing some spin dynamics, monte carlo or magnetic GS determination the ones of the OUTCAR are the ones that you are after. If you just want an idea of the total magnetization of the cell the one of the OSZICAR would be fine.

Looking at that example it also raises the issue of what to do with non-collinear cases, as what I have done will work only for collinear cases.

espenfl commented 4 years ago

Great. Thanks for sharing.

As you probably know, the magnetization from OUTCAR, e.g. what is inside the spheres is not necessary correct (e.g. between the different spheres etc.). For a better division I guess one could do something like Bader decomposition and then project the moment onto that. But yes, maybe having access to both makes sense. We would also need non-collinear cases as this is pretty common to do, but as long as we do not break backwards compatibility (we have to start to consider that now that aiida-vasp is going into more of production release) I support adding functionality in a stepwise manner.

Running a few tests here now to check what is available.

JPchico commented 4 years ago

Absolutely I agree that a Bader decomposition would be best, but I wonder how should one do that? I guess that maybe as a postprocessing operation? I think that for d-electrons the RWIGS based approach works quite well, but for s and p it is indeed a problem.

zhubonan commented 4 years ago

That is a good point, in addition orbital resolved magnetization in OUTCAR is only there if it is requested using LORBIT and by default it is off.

A third-place where magnetisation is printed is that from the SCF cycles in the OUTCAR, like:

--------------------------------------- Iteration      1(  24)  ---------------------------------------

    POTLOK:  cpu time    0.2915: real time    0.5237
    SETDIJ:  cpu time    1.0455: real time    1.3883
     EDDAV:  cpu time   24.3065: real time   33.2732
       DOS:  cpu time    0.0076: real time    0.0077
    --------------------------------------------
      LOOP:  cpu time   26.9650: real time   36.8068

 eigenvalue-minimisations  : 11616
 total energy-change (2. order) :-0.4472477E-05  (-0.2566642E-05)
 number of electron     223.9999941 magnetization       0.0092526
 augmentation part       35.8246767 magnetization       0.0036791

But the values appear to be different from that in the OSZICAR - any idea why @espenfl ?

DAV:  23    -0.250005009231E+03   -0.12853E-04   -0.70796E-05 14456   0.286E-02    0.716E-03
DAV:  24    -0.250005013704E+03   -0.44725E-05   -0.25666E-05 11616   0.227E-02
   1 F= -.25000501E+03 E0= -.24998200E+03  d E =-.250005E+03  mag=     0.0061
JPchico commented 4 years ago

That is very puzzling @zhubonan in the example I'm running (Co) the magnetization present in the OSZICAR and OUTCAR are the same if I turn off LORBIT.

But it would be very good to know if one can use the value in the OUTCAR as there is no OSZICAR parser right now, so that would require a whole new implementation.

espenfl commented 4 years ago

The values in OUTCAR, e.g. the ones listed in the first line of the magnetization should match the one in OSZICAR I believe. That is what I get for the example here, also for non-collinear runs. I can have a look in the source code later to verify. Might be some subtle differences.

JPchico commented 4 years ago

So if you agree then what I will do is to parse the value of the magnetization from the OUTCAR (line that starts with number of electron) use that as the magnetization from the cell volume (without projection) and then make a dictionary structure like

magnetization = {
     'sphere' : {
        ....
    },
    'full cell': {
        ....
    }
}

where shpere would contain the dictionary that is currently being parsed.

Plus I would add up an internal x,y,z coordinate for the non-collinear cases. What do you think?

espenfl commented 4 years ago

Yes, this sounds like what we need. And then we can add the full_cell when we add a parser for OSZICAR.

JPchico commented 4 years ago

So I added the capability of parsing the magnetization for non-collinear cases via nested dictionaries when orbital decomposition is used. The parser also collects (as a vector) the 'full cell' magnetization as printed in the OUTCAR (can be eliminated if we decide that for some reason the one in the OSZICAR is better). The output has the following structure:

{
    'sphere':{
        'm_x': {
            'site_moment': {
                '1': {'s': -0.014, 'p': -0.051, 'd': 1.687, 'tot': 1.621},
                '2': {'s': -0.015, 'p': -0.052, 'd': 1.686, 'tot': 1.619},
                '3': {'s': -0.014, 'p': -0.053, 'd': 1.708, 'tot': 1.64},
                '4': {'s': -0.014, 'p': -0.053, 'd': 1.708, 'tot': 1.64}
            },
            'total_magnetization': {'s': -0.057, 'p': -0.21, 'd': 6.788, 'tot': 6.521}
        },
        'm_y': {'site_moment': {}, 'total_magnetization': {}},
        'm_z': {'site_moment': {}, 'total_magnetization': {}}
    },
    'full_cell': [6.4424922]
}
espenfl commented 4 years ago

Thanks a lot @JPchico.