Firefly and PC GAMESS-related discussion club

Learn how to ask questions correctly  
We are NATO-free zone



Dear Professor Granovsky,

Thank you again.

>I have examined your output and found that what was constrained
>in your input file and during Firefly execution was not a torsion
>(coordinate type 3) but rather the out of plane bend (coordinate type 4).
>Note, these two coordinate types are not the same!

I have noticed that, but because the Z-matrix was automatically
generated so that there was an out-of-plane bend instead of torsion
for a coordinate of interest, I figured out that it is necessary
to freeze this coordinate.

Best wishes,
Dawid Grabarek

On Wed Mar 29 '17 11:17pm, Alex Granovsky wrote
>Dear Dawid,

>I have examined your output and found that what was constrained
>in your input file and during Firefly execution was not a torsion
>(coordinate type 3) but rather the out of plane bend (coordinate type 4).
>Note, these two coordinate types are not the same!

>There is a trivial typo in your input. Instead of



>there should be



>If you look into output, you'll see that this out of plane bend
>stays perfectly constrained at 22.3313384 degrees during optimization.
>Search output file for strings like:


     1 PLA.BEND    3    2    6    7                 0.3897554      22.3313384

>Hope this helps.

>All the best,
>Alex Granovsky
>On Wed Mar 29 '17 10:38am, Dawid wrote
>>Dear Prof. Granovsky,

>>Thank you for your kind answer and explaining precisely how to
>>use multithreading in my case.

>>Nevertheless, I have double checked the actual geometries during
>>optimization and even though I have constrained my torsion, it
>>slightly varies during optimization, however by up to ca. 0.5 degree.
>>So I have figured out that this is a something like a numerical
>>echo from my optimization. I am attaching the output from
>>calculations that I have concerned to be correct in terms of
>>constraints even though the dihedral somehow varies. I had to
>>however delete some output with MCHF natural orbitals. Otherwise,
>>the file size was too large.

>>Best wishes,
>>Dawid Grabarek

>>On Tue Mar 28 '17 9:34pm, Alex Granovsky wrote
>>>Dear Dawid,

>>>I'm sorry for delay with my reply. Indeed, the use of DLCs for
>>>geometry optimization (with or without constrains, this does not
>>>matter) is the recommended way with Firefly. It is good you have
>>>already figured this out.

>>>As to torsion angle variations you observed, I'm sure that
>>>there are no variations in frozen torsion at the geometries
>>>along the energy optimization path itself. Please double check this.
>>>At the same time, at distorted intermediate geometries used to
>>>compute numerical gradients, violation of constrains is indeed
>>>possible and is even required.

>>>On a separate note, I have a comment concerning your use of XP mode
>>>with Firefly. Upon examination of your previously posted input and
>>>output (from system-blows-up.tar.gz archive) it seems to me you do
>>>not use XP mode optimally. Indeed, the job was running in parallel
>>>using 12 processes on a single host wn0361. There is nothing wrong
>>>with this so far. However, np variable in $smp group was set to 24
>>>and you requested plain XP mode.

>>>As you can find in the output:


     Switching to XP mode with    12 groups of processes.
     Maximum size of group is      1 process(es).

>>>This means that there were 12 XP groups and hence 12 XP master
>>>processes. As requested, each XP master used 24 threads during
>>>summation of XMCQDPT2 series, i.e., 288 threads in aggregate.
>>>At the same time, there were only 56 cores available (again, this
>>>number can be found in output). Use of 256 threads simultaneously
>>>caused severe resource oversubscription resulting in serious
>>>performance degradation. It would be much better to run this job
>>>in parallel using e.g., 14 processes and requesting plain XP mode
>>>with np=4 in $smp group. This would lead to 14*4 = 56 threads in
>>>aggregate hence avoiding oversubscription and resulting in better
>>>overall performance.

>>>Hope this helps.

>>>Kind regards,
>>>Alex Granovsky
>>>On Wed Mar 22 '17 11:15am, Dawid wrote
>>>>Dear All,

>>>>I have figured out how to do it.
>>>>I attach my input file, so that others who struggle with this
>>>>have a working example.

>>>>By the way, I noticed that while the constraints generally work,
>>>>the constrained dihedral somehow varies during optimization
>>>>by less than 0.5 degrees. Is that related to the way the Z-matrix
>>>>was automatically generated?

>>>>Best wishes,
>>>>Dawid Grabarek

>>>>On Mon Mar 13 '17 11:49am, Dawid wrote
>>>>>Dear Alex,

>>>>>Thank you for helping me out with this.

>>>>>Nevertheless, after all I have decided to do my constrained
>>>>>optimization somehow different.
>>>>>I'd like to provide the coordinates in XYZ format and constrain
>>>>>one dihedral angle (torsion). My system blows up and I get
>>>>>warnings on the singularity (if I understand it correctly) of the
>>>>>G matrix.
>>>>>Could you have one more look at my input and output, please?

>>>>>Best wishes,
>>>>>Dawid Grabarek
>>>>>On Sat Mar 11 '17 8:30pm, Alex Granovsky wrote
>>>>>>Dear Dawid,

>>>>>>there are two errors in your original input file, the first is an
>>>>>>extra line in the $DATA group and the second is too long input line
>>>>>>in the $ZMT group (current limit is 80 symbols per line).

>>>>>>I have attached fixed input file for your reference.

>>>>>>Kind regards,
>>>>>>Alex Granovsky
>>>>>>On Thu Mar 9 '17 10:31pm, Dawid wrote
>>>>>>>Dear Firefly Users,

>>>>>>>I encounter issues with z-matrix definition in Firefly. I attach
>>>>>>>my input and output files. Could you explain why I get this error,

>>>>>>>Best wishes,

[ Previous ] [ Next ] [ Index ]           Thu Mar 30 '17 9:38am
[ Reply ] [ Edit ] [ Delete ]           This message read 566 times