Hi Amol,

you could try to let the optimizer use the exact Hessian matrix (the second derivatives of the potential energy) of your frequency calculation as a starting point. Usually, the optimizer uses some much cheaper, but also far less accurate methods to obtain an estimate for that matrix, and that sometimes leads it astray.

If you have kept a checkpoint file from the frequency calculation, you can use the "opt=readfc" keyword in your input. If you don't have the chk file, you should do two things: 1. use "opt=calcfc" instead, and 2. always create and keep checkpoint files in the future! Otherwise you will just waste resources by redundant calculations in cases like this one.

This may or may not work. Just give it a try and let us know.

By the way, a small thing about terminology. You write "imaginary frequencies (negative frequencies)" - Note that there really are no "negative frequencies"! What happens is that you take the square root of a negative number to calculate the frequency, which of course gives an imaginary result. The minus sign that most programs use in their output is just a flag to indicate that. So the correct way would be to use the imaginary unit "i" instead of a minus sign, but for some reason, hardly anyone seems to do that.

The "moving atom" strategy is one of the few that usually work, but apparently not in this case. You can still try moving the atoms more (like a lot more), so they can't go back exactly to the state with imaginary freqs. Sometimes, opt=z-matrix or opt=cartesian help since the optimizer is using a different algorithm and usually ends up in a slightly different geometry (though opt=cartesian is around twice slower). 

If that doesn't help try a different method (if using any DFT functional, try a different one) and then reoptimize with your original method from the optimized structure.