Basis set in GENBAS not found

For some work I'm doing, I want to make absolutely sure that I'm using the exact same basis set values across multiple runs using different codes. With this in mind, I'm attempting to provide basis set information explicitly to MRCC using a GENBAS file, rather than relying on the built-in library.

It's not clear to me if it's possible to completely disable the use of the basis set library; if so, I haven't worked out how. So in order to "guarantee" that MRCC doesn't accidentally end up falling back to a library basis set, I'm tagging a prefix onto the name of the basis set when stored in the GENBAS file, and requesting that in my MINP file. However, I'm seeing some odd behaviour, and it seems that I might be misunderstanding something or falling afoul of the logic that handles basis set naming. Consider the following two files, which should give a simple minimal example of this:

MINP:
GENBAS:
When I try and run this, MRCC errors out with "Basis set foo_aug-cc-pvdz not found!" Note that something odd is happening to the basis set name: both the GENBAS and MINP files refer to foo_aug-cc-pCvdz, not foo_aug-cc-pvdz.

Is this a bug, or am I seeing a side-effect of something expected and intended? Is there another way to achieve my goal, i.e. to completely remove any chance of a basis set being used that ISN'T given in the GENBAS file?

Please change foo_aug-cc-pcvdz to foo_aug-cc-pvdz in your GENBAS file. Core-valence basis sets do not exist for H, and mrcc automatically searches for the corresponding valence basis if a core-valence basis set is requested.

Thanks for the quick reply!

I understand the logic behind the specific behaviour here, but it actually demonstrates quite well just what I'm trying to avoid.

I think it's a nice feature of MRCC that the end user can just give a single label for a commonly-used basis set and get the "correct" result, up to and including the various transformations described in the manual for the `basis` keyword (like automatically adding diffuse
functions, etc.). But that involves a lot of hard-coded logic and assumptions, exactly like the kind you've described.

What I'm trying to do is to disable (or sidestep) that logic completely, so that I can be completely confident that the calculation output corresponds exactly and only to the basis set information I've provided, which may or may not (in my particular context) match the "standard" version. I would much rather that a calculation fails to start than that it runs with any(!) basis set information quietly drawn from the built-in library.

The trick of prepending each basis set label with "foo_" was intended to do this, but MRCC is clearly still inferring things based upon the label. It looks like I can defeat this by using a basis-set name that completely avoids the standard patterns (i.e. "my_nonstandard_set_34"), but that's unappealing because it will make it more or less impossible to trace backwards from my MINP files.

Is there a cleaner way of achieving this behaviour, ideally without having to second-guess MRCC's logic?

I try to never use the default basis sets given in any program. I always use my own GENBAS file:  github.com/HPQC-LABS/AI_ENERGIES/blob/master/GENBAS so that I'm 100% sure I know what basis set I'm using. Keep in mind that there's several aug-cc-pCVTZ basis sets out there, depending on who optimized the exponents and what version of the basis set the EMSL Basis Set Exchange had available at the time that it was downloaded.

As long as that GENBAS file is in your working directory, you can have full control over what basis set is being used.

For the majority of my MRCC calculations, I wanted to use the X2C Hamiltonian instead of the non-relativistic one, so I used CFOUR to calculate the integrals, and then MRCC to do the coupled cluster or CI calculations. If you're using the CFOUR interface, then just end your input file with something like the following (making sure that it does end with a blank line):
     
Here, I just listed the basis set name (from my own GENBAS file) for each atom in the geometry specification. Again you just have to have the GENBAS file in your working directory when you run CFOUR.