storage order for Hessian matrix

[Jindrich Kolorenc]

Hello!

I would like to try Pfaffian with einspline orbitals. To be able to
optimize such beasts, I suppose I need updateHessian() in the orbital
class. As far as I can see, MO_matrix_bspline has it implemented,
MO_matrix_einspline does not have it. Too bad I chose to go the
MO_matrix_einspline route some time ago.

I should be able to implement the missing updateHessian(). After all,
updateLap() seems to have all the numbers calculated already, it just
never uses them. But I am a bit puzzled by the order of the second
derivatives in the return array newvals. MO_matrix.h (line 151) says it
should be dxx,dyy,dzz,dxy,dxz,dyz, but MO_matrix_bspline seems to return
dxx,dxy,dxz,dyy,dyz,dzz (if I undestand correctly the loops in
MO_matrix_bspline.cpp, lines 522-524). I suppose the comment in
MO_matrix.h is correct, but just to be sure...

Thanks
Jindra

PS: I guess the most transparent way to add updateHessian() into
MO_matrix_einspline is to rename the current updateLap() to
updateHessian(), change the return array a little bit, and then
implement updateLap() as a wrapper to updateHessian().

[Lucas Wagner]

Jindra,

Thanks for the input. Adding updateHessian() is pretty trivial, as
you mentioned, and that seems like a good way to implement it. It's
definitely not worth it to go to bspline, since bspline has weird bugs
and also requires an incredible number of files. I plan to remove
bspline soon if no one has objections.

MO_matrix.h is correct, bspline is incorrect, if you're interpreting
it correctly.

Best,

Lucas

[Michal Bajdich]

Indeed,
looks like in Hessian of bspline
 for(int d1=0;d1<3;d1++)
      for(int d2=d1;d2<3;d2++)
    newvals(m,d++)=magnification_factor*multi_hess(mo)(d1,d2);
  }//m

is really the problem. This feature was not useded/tested before as far as I know. Every hessian routine returns, xx, yy, zz, xy, xz, yz. I cant comment on the claim of weird bugs where none were reported.

Michal

[Lucas Wagner]

Re the bugs, I found them, but I was rewriting bspline anyway to use
only one orb file and just for general cleanliness. I was under the
impression that no one has really been using bspline, is that correct?

Thanks,

Lucas

[Michal Bajdich]

I dont know who is using what. Using one file is fine with me. There are also converters which generate many files so they will be broken.
Michal

[Shuming Hu]

I was using bspline.
The version I pulled from maia01(ncsu) only has MO_matrix_bspline, not MO_matrix_einspline, if I remember correctly.
If the new version will be merged to maia, I hope it back supports the same gaussian cube format.

Thanks,
Shuming

[Lucas Wagner]

No, it doesn't support the many cube file format, because that format
ends up with 100's of cube files in your directory. That was one of
the major reasons for the rewrite. It wouldn't be hard to write a
converter from the cube files to the new format, though, since it's
pretty simple. The MO_matrix_einspline is available from Google code.

I rewrote the abinit converter as well; there is now an
abinit2qmc2.cpp converter. I'm sorry we had to do it, but anyway I
think the new version is improved, after working off the back of
Michal's stuff.

Cheers,

Lucas

[Jindrich Kolorenc]

Lucas> no one has really been using bspline, is that correct?

I guess that is the issue here. The einspline interface was implemented
for rather odd reasons and was probably never used in production. Hence
no feedback, no bugfixes, no tune-ups.

There are some obvious inefficiencies in these einspline interfaces, for
instance orb file as a text file is unnecessarily large which takes up
time and network bandwidth during initialization (of each consecutive
method!). Another thing is calculation of laplacian, which unnecessarily
evaluates off-diagonal derivatives (though this is probably limitation
of the einspline routines). I will possibly try to address some of this
eventually.

Shuming> I hope it back supports the same gaussian cube format.

I am also of the opinion that backward compatibility is an important
consideration. It does clutter the code somewhat but it is quite
inconvenient not to be able to rerun old(ish) input files.

Jindra

[Lucas Wagner]

On Wed, Oct 26, 2011 at 5:21 PM, Jindrich Kolorenc <kolo...@fzu.cz> wrote:
> Lucas> no one has really been using bspline, is that correct?
>
> I guess that is the issue here. The einspline interface was implemented for
> rather odd reasons and was probably never used in production. Hence no
> feedback, no bugfixes, no tune-ups.
>

That's basically the story. We were looking into using it for
production and found that from the original code
1) the converter doesn't work for latest abinit
2) the converter uses the CASINO code, which is fine in principle, but
does not work for parallel abinit, which is really inconvenient
3) there were segfaults occasionally that we never understood, and
sometimes infinities in the laplacian
4) it was written in a way that made it very difficult to make any
changes whatsoever
5) the cube files were out of hand for large systems

Given that, it seemed better to rewrite, using some basics from the
original implementation. I don't say all this to criticize anyone,
since I don't know the conditions under which it was developed. I'm
very glad that bspline was there, in fact. It was just time for a
rewrite.

> There are some obvious inefficiencies in these einspline interfaces, for
> instance orb file as a text file is unnecessarily large which takes up time
> and network bandwidth during initialization (of each consecutive method!).

This is correct, this should be improved.

> Another thing is calculation of laplacian, which unnecessarily evaluates
> off-diagonal derivatives (though this is probably limitation of the
> einspline routines). I will possibly try to address some of this eventually.
>

This is a limitation of einspline, since it requires an orthonormal
cell. I think it improves the efficiency overall, however.

> Shuming> I hope it back supports the same gaussian cube format.
>
> I am also of the opinion that backward compatibility is an important
> consideration. It does clutter the code somewhat but it is quite
> inconvenient not to be able to rerun old(ish) input files.
>

It would be easy to write a converter from the old style to the new
style; it would be an easy way for a student to contribute to the
code, hint hint.

Cheers,

Lucas