On Sun, 2011-04-10 at 16:13 -0500, Laurence Marks wrote:
> Another quick one: line 1766 of install/configure.ac nulls out
> scalapack_libs and the lines below look like they are special tests,
> which seems to be inconsistent with line 150 and standard protocols of
> letting the user define input
Type: configure.ac:306 (not 30).
On Wed, Apr 13, 2011 at 8:32 AM, Laurence Marks
wrote:
> Agreed. One could (maybe) write a macro for this but it would be way
> too specialized. Just removing the over-ride should enable the user to
> specify it; most cluster sysadmins should have this posted or o
Agreed. One could (maybe) write a macro for this but it would be way
too specialized. Just removing the over-ride should enable the user to
specify it; most cluster sysadmins should have this posted or one can
use the ifort linking guide.
N.B., I would test myself, but at least on the cluster wher
On Sun, 2011-04-10 at 16:13 -0500, Laurence Marks wrote:
> Another quick one: line 1766 of install/configure.ac nulls out
> scalapack_libs and the lines below look like they are special tests,
> which seems to be inconsistent with line 150 and standard protocols of
> letting the user define input
It has been there for some time, didn't seem to have any relevant effect.
do you have evidence of the contrary?
stefano
On 04/11/2011 05:25 PM, Laurence Marks wrote:
> Thanks.
>
> Another question if I may. From the looks of PW/mix_rho.f90 you do not
> use the weights in the Johnson paper, just a
The renormalization will only matter if the inverse of betamix is
regularized. I am not that familiar with how the Johnson algorithm behaves
for bad problems to know if regularization helps in practice, or does matter
for a multisecant method.
On Apr 12, 2011 1:41 AM, "Stefano de Gironcoli" wrote:
Correction, I did not notice that you are not renormalizing. With
#define __NORMALIZE_BETAMIX it should be more like
if(iter_used .gt. 1)betamix(i,i)=betamix(i,i) + 2.0D-5
which, interestingly, is almost exactly the same regularization as
used elsewhere.
On Mon, Apr 11, 2011 at 10:25 A
in my previous post
reminder -> remainder
stefano
On 04/11/2011 11:57 AM, Stefano de Gironcoli wrote:
> dear Laurence Marks
>
> thank you for contributing this patch for bfgs !
>> A quick question. In the ion optimization it looks like you are
>> starting from some iterpolation of the new
dear Laurence Marks
thank you for contributing this patch for bfgs !
> A quick question. In the ion optimization it looks like you are
> starting from some iterpolation of the new density (i.e. "NEW-OLD
> atomic charge density approx. for the potential"), what is it?
if i remember correctly
Thanks.
Another question if I may. From the looks of PW/mix_rho.f90 you do not
use the weights in the Johnson paper, just a straight inverse of
betamix (what would be called Y^T Y in the optimization literature) at
lines 289-295? Have you considered a regularization, e.g. adding after
line 278 som
For completeness, added proper comments.
On Sun, Apr 10, 2011 at 4:13 PM, Laurence Marks
wrote:
> A very minor bug that you probably known: some of the routines in
> S3DE/iotk/src have lines such as "# 1 "iotk_write_interf.spp" ". Most
> sensible preprocessors will ignore these and just give warn
A very minor bug that you probably known: some of the routines in
S3DE/iotk/src have lines such as "# 1 "iotk_write_interf.spp" ". Most
sensible preprocessors will ignore these and just give warnings.
A more serious bug. Your bfgs code does not have curvature failure
conditions trapped. Not to get
12 matches
Mail list logo
