Dawid
dawid.grabarek@pwr.edu.pl
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
>
$zmat ifzmat(1)=4,3,2,6,7 $end
>there should be
>
$zmat ifzmat(1)=3,3,2,6,7 $end
>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,
>>>>>>>please?
>>>>>>>Best wishes,
>>>>>>>Dawid