In Gaussian, the keyword Field=z+n adds an electric field 0.000n in the z direction of the "standard" orientation, which can be different from the "input" orientation. Is there a safe way to force Gaussian to use the input orientation instead? In a general case it is not easy to find a transformation from input to standard, and for sure it is not possible without performing a test calculation and analysing Cartesian coordinates for both orientations.
Greetings,
When I used the electric field, I had no issues with it because I remember the manual stating that you should input the electric field coordinates in the input coordinate system, and they would be transformed accordingly.
I also recall submitting three test jobs to verify this: I optimized a molecule in an electric field using the standard method (with internal coordinate transformation), then with opt=cartesian and nosymm to bypass the internal transformation, and finally without any electric field. The first two approaches yielded the same result, indicating that the electric field was correctly translated into internal coordinates, while the third produced a completely different outcome due to the absence of the electric field.
Is there something unusual happening in your calculation that might be preventing the electric field from being transformed correctly?
Lucas Gian Fachini To begin with, I am not doing the geometry optimization - just single-point calculations.
My input is:
#N CAM-B3LYP/SVP/auto Field=x+2 sp
and I see in the output the following lines:
The following finite field(s) will be applied:
An electric field of 0.0002 0.0000 0.0000
In input orientation: -1.37235821D-20 3.67394043D-20 2.00000000D-04
so, as you see, it mixes standard and input orientations (in this case it is easy to force the program to use the correct field by writing Field=z+2, but in my next case the reorientation to the standard orientation is more complicated and making a backtransformation is not so straightforward).
In the meantime I discovered that switching off symmetry (nosymm) prevents the reorientation (at least in all the cases I tested so far), but it is quite misleading that in a general case (with a possible reorientation), one cannot use the input orientation.
Tatiana Korona Thank you for sharing more information,
After re-running calculations on my systems, I observe the same trend. Notably, I did not encounter any rotation of the electric field, likely because I bypassed the symmetry check using nosymm.
In this context, it appears that Gaussian preserves both the molecular geometry and electric field orientation as expected when symmetry is disabled. However, when symmetry is enabled (leading to the generation of new internal coordinates) the software either mixes up the orientations or prints the electric field in a symmetry-rotated frame.
A possible explanation could be that the program modules execute in an unintended order. Alternatively, Gaussian might be printing the electric field in the "input" orientation after applying symmetry rotations and generating internal coordinates. This could mean that the internal symmetry-adapted coordinates are treated as the "input", making the software outputs the electric field in a symmetry-rotated frame that seems to not make sense.
While contacting Gaussian, Inc. could provide further clarification, I suspect they may not prioritize fixing this issue if it stems from a module mismatch or a minor bug, especially as they seem to be focusing on the next major release (the new gaussian software).
I apologize for not being able to offer a solution, but I hope these hypotheses are helpful anyways.
First align your molecule along a certain direction and then use the keyword "nosymmetry" in your Gaussian input.
- Badges
- Science method