# How to use fractional numbers as arguments for keywords in Gaussian input?

I have used both Gaussian09 and Gaussian16 and one thing that seemed unusual to me is that I was unable to enter any fractional number as one of the arguments for a keyword in the Gaussian input file.

For example, to control the step length of the optimization procedure, the keyword is maxstep. So I can enter something like this:

#n opt=(maxstep=1) freq b3lyp/6-31G  !Runs normally


Whereas Gaussian gives an error in reading the input file if I use a fractional number (float) as an argument of maxstep.

#n opt=(maxstep=0.5) freq b3lyp/6-31G  !Error


I have not seen this in any other softwares. For example, GAMESS and Orca both allow non-integer values for arguments to keywords that control the optimization step size.

Why does Gaussian not allow non-integer arguments to its keywords? (I haven't checked other keywords apart from maxstep, because most other keywords don't need floating point values, but the same problems seems to arise with maxstep for IRC)

All keywords in Gaussian (effectively) only accept integers as arguments. Keywords are all translated into IOps (Internal Options), which are written in the format IOp(overlay/option=value) where value is always an integer. This seems to have been an early design decision to only allow integer valued options and while Gaussian is open to adding/deprecating features, their design philosophy seems very hesitant about making (potentially breaking) changes to the existing interface.

As to why this decision was made, I'm not certain, but I can speculate about a few reasons.

• Implicit typing: Gaussian is written in Fortran 77 and its common in language to implicitly type any variables starting with (i,j,k,l,m,n) as integers. So including floats as options would have either required adding a separate variable where float options were stored or keeping track of which options within IOp were floats and explicitly retyping them whenever they were used.
• Parsing: Minor, but it may just have been more of a pain to parse IOps with floats, since the format allows you to specify multiple options in one IOp section, separated by commas. Combined with some regions using the opposite convention for decimal and thousands separators, they could have thought it was more work than necessary and the design choice stuck.
• Limiting flexibility: the developers have some sense of what range of options should produce reasonable results and so it can sometimes be advantageous to limit options to avoid faulty values that won't necessarily crash the program, but could give unreasonable results. This is especially true if you know the program could have users who aren't necessarily electronic structure experts. For a case like the step size, they might reason that the max step only needs to be in 0.01 Bohr increments, as more precision is not needed and a smaller magnitude could lead to problems. On the other hand, the specification of the short/long range HF exchange for a hybrid functional (IOp(3/119)=MMMMMNNNNN) needs more precision and so can be specified in increments of $$\frac{\text{MMMMM}}{10000}$$ and $$\frac{\text{NNNNN}}{10000}$$.
• Setting defaults: The IOp documentation mentions that any IOp set to 0 will take on the default value. It would be slightly trickier to set a sentinel default value for a float argument, as conceivably any float could be a possible input (this is not to say its impossible, it just makes the interface slightly more complicated).
• +1 But I don't agree with the first two points, because most of the code of GAMESS is also written in Fortran 77, and GAMESS can parse floating point arguments in its input. Jun 16 at 8:33
• @ShoubhikRMaiti I don't mean to suggest that they couldn't have had floats, just that after deciding to add options through this IOp mechanism (since most options are essentially bit fields or counts), it would have required some overhauling to allow floats. It is also worth noting that while Gaussian is now written in Fortran77, it started in previous version where both the code and input files had to be written on punchcard, so there was incentive to use space efficiently. So some of it also could be relics of the punchcard era.
– Tyberius
Jun 16 at 14:42

This is a weird quirk of the Gaussian input and I am unsure why it is implemented this way. The maxstep is given in a unit of 0.01 Bohr and it is presumed you do not wish to use a maxstep of less than 0.01 Bohr as this corresponds to about 0.005 angstroms.

While I think this is a weird limitation to exist, you may consider that this is such a small distance that no practical calculations should be done with a maxstep=1 or less.