[Feature] make it possible to generate grids without basis sets

[bast]

@robertodr do you have an idea how we can define a good default exponent range for atoms?

[bast]

Or in other words a default radial range.

[robertodr]

Maybe you can use van der Waals radii? Another solution would be to have a higher level API function that takes only the atomic centers and their charges and then calls the lower level API function where only the tightest and most diffuse basis functions from a Dunning basis set are retained for each atom. This could be done by table lookup, I think.

[bast]

Merging this with issue #17 discussion (suggested by @aspgomes):

• Provide possibly 3 different qualities of sets
• Use STO-6G and a Dyall set since they cover the entire periodic table
• Make it possible to request a tunable max radius that should be spanned by grid points for calculations which require diffuse functions

[bast]

@aspgomes so after some thinking and prototyping I will enable the higher-level API which calls the lower-level API:

context = numgrid.new_atom_grid(radial_precision,
                                min_num_angular_points,
                                max_num_angular_points,
                                proton_charges[center_index],
                                alpha_max[center_index],
                                max_l_quantum_numbers[center_index],
                                alpha_min[center_index])

So the higher level-API will not ask for alpha_max, max_l_quantum_numbers, and alpha_min and instead use table lookup.

I am unsure about:

• which basis sets to use for the lookup (I am gravitating towards cc-pVTZ and Dyall dyall.v3z).
• naming, perhaps new_atom_grid_ccpvtz and new_atom_grid_dyall_v3z?
• unsure how to enable tighter and more diffuse grids - but perhaps this can be postponed?

Your recommendations/thoughts will help me a lot to unblock the above. Programming-wise it's then trivial - I have code ready that extracts the data from basis sets and creates a table.

Of course one could imagine providing a basis set as argument but I don't want to have an entire basis set library in Numgrid. But one could imagine fetching this from the web but this is for later.

[aspgomes]

@bast for the basis sets, i would go for the dyall.v3z since these cover the whole of the periodic table.

now, you say you've implemented a table lookup, and that you have code that reads a basis set and creates a table that, if understood correctly, takes the place of alpha_max, max_l_quantum_numbers, and alpha_min.

from this, perhaps what can be done is to have this code as a method you can use from outside new_atom_grid (or its higher/lower-level analogue, see below). this way, you can use it to read any basis (and not have to story anything in numgrid, which i agree would be a mess), and then pass this table to new_atom_grid. what you'd then do with the dyall.v3z is to have it as bulit-in table, if nothing has been passed as (optional?) argument.

with a solution like this (pass a table - or any other object describing the basis - to new_atom_grid), you'd also be able to have methods that extend the tables towards the core or valence, but implement these later.

about the naming, unless it breaks too many things, perhaps keep new_atom_grid as the exposed api and rename the one which is wrapped ? otherwise i'm not good on ideas, but i probable wouldn't use a name of a basis set.

[bast]

Thanks for the input - I agree with dyall.v3z. I will brainstorm a bit more - quite busy before Friday but I plan to implement this over the weekend.

[bast]

@aspgomes I have finally implemented something: the code is on the tabulated-basis branch. It is using dyall.v3z under the hood.

Examples:

• https://github.com/dftlibs/numgrid/blob/tabulated-basis/test/test_tabulated.cpp#L45-L48
• https://github.com/dftlibs/numgrid/blob/tabulated-basis/test/test_tabulated.f90#L64-L67
• https://github.com/dftlibs/numgrid/blob/tabulated-basis/test/test.py#L122-L125

You can pip install using:

$ pip install git+https://github.com/dftlibs/numgrid.git@tabulated-basis

Few thoughts/issues:

• Not 100% sure about API naming, might change before I merge to master but wanted to collect your feedback first.
• Grid is "too good" for non-relativistic calculations since dyall.v3z contains very steep exponents which may be overkill for many applications and elements. Perhaps it would be good to offer different basis sets but I am unsure about the API aspect.
• Grid may be insufficient for diffuse properties, also here I am unsure what to offer API-wise.
• Ideally the library should fetch a basis from the web but this is for later, I really want to avoid tabulating "all" basis sets and also want to avoid parsing basis set files.

Let us test and sleep on it a bit. I would appreciate if you could test it on your end.

[bast]

Also I will experiment with https://github.com/MolSSI-BSE/basis_set_exchange which might solve all my problems (at least using the Python layer).

[bast]

I think I will go for https://github.com/MolSSI-BSE/basis_set_exchange which looks really nice. This will remove a lot of my code and give you a lot of flexibility so better don't test yet. I will generalize this in the coming two weeks.

[bast]

The BSE interface is now implemented: https://github.com/dftlibs/numgrid#avoiding-explicit-exponent-ranges. This is much nicer than the previous approach using tabulated sets.

[robertodr]

:+1: :octopus: