Added BoltztrapDosBuilder class

[fraricci]

I added a BoltztrapDosBuilder class to run boltztrap in the DOS run mode and get a
complete dos object as output.
Notes:

1. the DOS run mode works only if a patched version of boltztrap is run (@shyamd should already have it)
2. at the moment the bs on uniform grid saved in the gridfs do not contain projections. If BoltztrapDosBuilder is run now, only a total dos is returned.
   Since projections can be useful for other purpose then creating dos, my suggestion is to run a separate code to get the projs from the vaspruns and update the bs already stored. Upon the updated bs are ready, the BoltztrapDosBuilder works out-of-the-box generating a complete dos (meaning projections included)

[shyamd]

Hi Francesco,

Can you update this for the new BoltzTrap2 in pymatgen? Once we get that in, I'll go ahead and start running this as part of production. I'll also add in some code to push this for website soon.

[fraricci]

Hi Shyamd,

I'd like to perform some test on the DOS of some material and compare the results with bzt1.
Then I will update the builder.

[fraricci]

Here we are ;-)
It should work fine, I tested it with the Doses I got using boltztrap1.
About run timing, I did only a quick test on a structure with 28 atoms:
the full (all site and orbital projections) dos took ~10 min.
The process to get projected doses could be parallelized, if time is an issue.

I pushed in pymatgen a new version of the boltztrap2 interface.
It's needed to run correctly the builder.

There's still the issue of getting the projections, though.
Did you figure out a solution?

[shyamd]

Few comments:

• You don't have to explicitly consider gridfs anymore. There is a GridFS Store that the user will supply if they need to. Treat this like a regular Mongostore.
• Can you add a test to run the builder on one material. You can include test files in test_files. Here abstracting to the Store is useful because you can just store gzipped JSON files and then load them in via a JSON store in your test.

For the projections: it's an issue of what was calculated. The new database should have projections when they are actually there, but for a lot of the old calculations, it seems that there may have been issues in what VASP actually printed out.

[fraricci]

I am not sure how to fulfill the two points.
Please, suggest me an example of test and one about how to use mongostore.
thanks

[shyamd]

You can allow the user to supply a bandstructures store and then just query that:

def __init__(..... , bandstructures ...):
   self.bandstructures = bandstructures
...

def get_items():
....
    bs_task_id = mat.get("bandstructure",{}).get("uniform_task",None)
    if bs_task_id:
        bs_dict = self.bandstructures.query_one({self.bandstructures.key : bs_task_id})

This allows you to not worry where the bandstructures are stored, whether its gridfs or just a regular collection. The Store will take care of defining how they are stored. So we have a GridFSStore in maggma that you can query and query_one just as normal. It will take care of separating metadata and compression without the person writing the builder having to worry about that.

As for a test find a system that is easy for boltztrap2 to run on. Save the bandstructure as a gziped json and material. Make your builder with the appropriate stores, do get_items, process_items, and update_targets. Checking for errors in each of those steps.

[fraricci]

@shyamd could you please check if this is going in the right direction?
It should start working fine.
Let me know thanks

[shyamd]

@fraricci

I've made some updates to be compatible with the current Maggma.

The thing I was mentioning before is that in the Builder you don't need to worry about the store type. If that doesn't work because of a document too large error that is up to the person using it. All you need to do is query a store for the necessary info, get that data, process, and push.

[fraricci]

Hi @shyamd,
the energy_range has to be kept fixed to "np.inf".
A different energy_range needs to be implemented.
So I would keep "np.inf" hard coded.

[shyamd]

I was trying to make it so we could somehow fix the test which appears to be running too slow so Travis times out, but as you mentioned it doesn't work. Running this on my own comp the tests pass, im just now sure how to deal with Travis.

[fraricci]

I think get_dos(projection=True) takes the longest time.
You could reduce the npts_mu increasing the energy_grid.
But you need to change the data in the test_files.

[shyamd]

Is there a reason why npts_mu isn't used in the non-spin polarized case?

[fraricci]

no reason, I just forgot to put it there too, sorry :-)

[shyamd]

This passes even the skipped test on my linux machine. Thanks!

[fraricci]

Great news! So are we now ready to run it? ;-)
I made a pull request to pmg that solves a bug in case of bs without projection.
It's probably more safe to run with that pmg.

[shyamd]

Sounds good. I probably won't get a chance to finish this before January release, but I think we can shoot for Feb release of BoltzTrap interpolated DOSes.