Ceilidh ... Re^5: Error about RSURFACE:GRADIENT OUT OF RANGE

Firefly and PC GAMESS-related discussion club

Learn how to ask questions correctly

We are NATO-free zone

Re^5: Error about RSURFACE:GRADIENT OUT OF RANGE

Sorry for the late reply.
I experienced the following in a job last month.
When NONVDW (1) = 1, 9, this job ended abnormally.
ERROR: UNABLE TO PROJECT DLC!

However, when NONCDW (1) = 1, 9, 1, 10, 10, 47, abnormal termination did not occur.
From this I was able to understand your comment.　Thanks.

F. mohri

On Thu Jul 26 '18 2:59pm, Alex Granovsky wrote
----------------------------------------------
>Dear Prof. Fumihito Mohri,

>I'm sorry for delay with my reply.

>Indeed, 5,6,6,16 was an overkill, though overkill of that type should
>not negatively impact scan process.
>Normally, it is better to define a bit more vdW pairs than actually
>needed rather than define a bit less than needed. I do this just in case,
>to avoid aborts during scan process due to lack of internal variables.
>
>
>As to AUTOFV option, it is indeed required by scans.
>Because this option is turned on by default, it is not necessary
>to specify it explicitly.
>
>
>Hope this helps.
>
>
>Kind regards,
>Alex Granovsky
>
>
>
>

>On Thu Jul 19 '18 8:59am, Fumihito Mohri wrote
>----------------------------------------------
>>Dear Prof. Granovsky

>>Thank you for your comment and the attached files. I found that the calculation for test.inp which has nonvdw(1)=3,6,5,6,6,16 reached at normal end. But, a new file, tets2.inp with nonvdw(1)=3,6 gave the same result as test.inp. Could you tell me
>>why you added 5,6,6,16 to nonvdw(1).
>>One more question, there is no AUTOFV in test.inp. Is this keyword really not necessary?

>>Kind regards,
>>F. Mohri

>>On Tue Jul 17 '18 11:02am, Alex Granovsky wrote
>>-----------------------------------------------
>>>Dear Professor Fumihito Mohri,

>>>I'd strongly recommend you to recast your test job as a scan in DLC coordinates.
>>>DLc scans are much more numerically stable and this is recommended way
>>>of doing scans with modern versions of Firefly.

>>>Attached to this post please find modified input and output files for
>>>your system

>>>Hope this helps.

>>>Kind regards,
>>>Alex Granovsky
>>>
>>>
>>>
>>>
>>>
>>>On Mon Jul 16 '18 5:52pm, Fumihito Mohri wrote
>>>----------------------------------------------
>>>>I found a new fact for the input file of input.zmt

>>>>A revised file with HESS=CALC (IFREEZ(1)=10,VECT1(10)=1) do not give GRADIENT OUT OF RANGE
>>>>and runs normally. This job is very time consuming. On the other hand, Hartee-Fock calculation with HESS=CALC (i.e.DFTTYP=B3LYP1 is deleted) is not time consuming, due to that RECONDITIONED CONJUGATED GRADIENT SOLVER works.

>>>>F. Mohri
>>>>--------------------------------------------------------

>>>>On Sat Jul 14 '18 3:05pm, Fumihito Mohri wrote
>>>>----------------------------------------------
>>>>>Dear Firefly users

>>>>>I have tried RSURFACE calculation, using a sample file of input.zmt downloaded from
>>>>>the following site.

>>>>>This calculation gave extremely large gradient and then stopped abnormally(Firefly version is 8.20).

>>>>> MAXIMUM GRADIENT = 29.2097047 RMS GRADIENT = 4.6972733
>>>>> OPTIMIZATION ABORTED.
>>>>> -- GRADIENT OUT OF RANGE
>>>>> -- MAXIMUM ALLOWED FORCE (FMAXT) = 10.000

>>>>> ADDRESS 0x0077D6E1 HAS INITIATED PROGRAM ABORT BECAUSE OF FATAL ERROR(S)

>>>>>This error occurred at C5 and C6 which configure the variable of VECT1.

>>>>>Next, I added $SCF line written as;

>>>>> $SCF DIIS=.T. SOSCF=.F. dirscf=.t. damp=.t. $END

>>>>>But, the same error as above occurred.

>>>>>Could you tell me how I can resolve the above problem.

>>>>>Best regards,
>>>>>F. Mohri

Sat Aug 4 '18 11:29am

This message read 397 times