Problem displaying orbitals

Development
1

Let’s switch back to pow(). Jens, can you submit a patch?

No problem - I’ll do that tonight.

Jens

Scanned by iCritical.

2

Hi,

The orbital stuff stopped working for me recently and I’ve finally tracked it down to a problem with a function called apow that is called in:

libavogadro/src/extensions/surfaces/gaussianset.cpp

Specifically in initCalculation, where there are calls along the lines of:

m_gtoCN.push_back(m_gtoC[j] * apow(m_gtoA[j], 0.75) * 0.71270547);

Whatever apow is, it returns 0 on my system and if I replace it with a call to pow, then everything works as expected.

I can’t work out what apow is being resolved to and it doesn’t appear to be called from anywhere else in the code.

Is this a problem with the code or with my build environment?

Many thanks,

Jens

–
Scanned by iCritical.

3

m_gtoCN.push_back(m_gtoC[j] * apow(m_gtoA[j], 0.75) * 0.71270547);
Whatever apow is, it returns 0 on my system and if I replace it with a call to pow, then everything works as expected.

I can’t work out what apow is being resolved to and it doesn’t appear to be called from anywhere else in the code.

The “apow” code is for an approximate power function, which should be found in approxmath.h, along with an approximate exp() function. There wasn’t a huge speedup from apow() so if we want to revert to pow(), I’m OK with that.

I think we can probably find better optimizations from reorganizing the orbital code.

-Geoff

4

I have a similar problem in CentOS5.5: when trying to display an orbital,
the program seems to go into an infinite loop after displaying
“Attempting to render orbital …” and nothing appens.

It woks in MacOSX though. Compiler issue?

Louis

Le 24 août 2010 à 16:47, Geoffrey Hutchison a écrit :

m_gtoCN.push_back(m_gtoC[j] * apow(m_gtoA[j], 0.75) * 0.71270547);
Whatever apow is, it returns 0 on my system and if I replace it with a call to pow, then everything works as expected.

I can’t work out what apow is being resolved to and it doesn’t appear to be called from anywhere else in the code.

The “apow” code is for an approximate power function, which should be found in approxmath.h, along with an approximate exp() function. There wasn’t a huge speedup from apow() so if we want to revert to pow(), I’m OK with that.

I think we can probably find better optimizations from reorganizing the orbital code.

-Geoff

Sell apps to millions through the Intel(R) Atom™ Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d

Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

5

On Tue, Aug 24, 2010 at 10:47 AM, Geoffrey Hutchison
geoff.hutchison@gmail.com wrote:

m_gtoCN.push_back(m_gtoC[j] * apow(m_gtoA[j], 0.75) * 0.71270547);
Whatever apow is, it returns 0 on my system and if I replace it with a call to pow, then everything works as expected.

I can’t work out what apow is being resolved to and it doesn’t appear to be called from anywhere else in the code.

The “apow” code is for an approximate power function, which should be found in approxmath.h, along with an approximate exp() function. There wasn’t a huge speedup from apow() so if we want to revert to pow(), I’m OK with that.

I think we can probably find better optimizations from reorganizing the orbital code.

I’m somewhat interested in why it’s returning 0, though. Can you track
down where in apow things go wrong? What compiler/OS are you using?

Dave

6

On Tue, Aug 24, 2010 at 11:00 AM, Louis Ricard
louis.ricard@polytechnique.edu wrote:

I have a similar problem in CentOS5.5: when trying to display an orbital,
the program seems to go into an infinite loop after displaying
“Attempting to render orbital …” and nothing appens.

It woks in MacOSX though. Compiler issue?

Make sure you have a surface display type added. We should pop up a
warning in this case, but haven’t added that yet…

Dave

7

-----Original Message-----
From: David Lonie [mailto:loniedavid@gmail.com]
Sent: Tue 24/08/2010 16:31
To: Geoffrey Hutchison
Cc: Thomas, Jens (STFC,DL,CSE); avogadro-devel@lists.sourceforge.net
Subject: Re: [Avogadro-devel] Problem displaying orbitals.

On Tue, Aug 24, 2010 at 10:47 AM, Geoffrey Hutchison
geoff.hutchison@gmail.com wrote:

m_gtoCN.push_back(m_gtoC[j] * apow(m_gtoA[j], 0.75) * 0.71270547);
Whatever apow is, it returns 0 on my system and if I replace it with a call to pow, then everything works as expected.

I can’t work out what apow is being resolved to and it doesn’t appear to be called from anywhere else in the code.

The “apow” code is for an approximate power function, which should be found in approxmath.h, along with an approximate exp() function. There wasn’t a huge speedup from apow() so if we want to >revert to pow(), I’m OK with that.

I think we can probably find better optimizations from reorganizing the orbital code.

I’m somewhat interested in why it’s returning 0, though. Can you track
down where in apow things go wrong? What compiler/OS are you using?

This is on:

jmht@csevst1:~/Documents/AVOGADRO/avogadro/build> lsb_release -a
LSB Version: core-2.0-noarch:core-3.2-noarch:core-2.0-x86_64:core-3.2-x86_64:desktop-3.2-amd64:desktop-3.2-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.2-amd64:graphics-3.2-noarch
Distributor ID: SUSE LINUX
Description: openSUSE 11.1 (x86_64)
Release: 11.1
Codename: n/a
jmht@csevst1:~/Documents/AVOGADRO/avogadro/build> c++ --version
c++ (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]
Copyright (C) 2008 Free Software Foundation, Inc.

I tested apow with the following snippet:

#include

#ifndef APOW_CONST
#define APOW_CONST 1072632447
#endif
inline double apow(double a, double b) {
int tmp = (*(1 + (int *)&a));
std::cout << "tmp is " << tmp << std::endl;
int tmp2 = (int)(b * (tmp - APOW_CONST) + APOW_CONST);
std::cout << "tmp2 is " << tmp2 << std::endl;
double p = 0.0;
*(1 + (int * )&p) = tmp2;
return p;
}

int main(){
double a=2.0;
double b=4.0;

double c = apow(a,b);

std::cout << "c is " << c << std::endl;

return 0;

}

Compiled with the same flags used for avogadro:

c++ -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -fpermissive -O2 -g -Wnon-virtual-dtor -Wno-long-long -ansi -Wcast-align -Wchar-subscripts -Wall -Wextra -Wpointer-arith -Wformat-security -fno-check-new -fno-common -pedantic -o test test.cc

Which produces:

tmp is 0
tmp2 is -2147483648
c is 0

If I just compile with:

c++ -o test test.cc

I get:

tmp is 1073741824
tmp2 is 1077069955
c is 18.7832

It seems that it’s the -O2 that produces the problem. If I compile with no optimisation or -O1, I get 18.7832

Hth,

Jens

Scanned by iCritical.

8

It seems that it’s the -O2 that produces the problem. If I compile with no optimisation or -O1, I get 18.7832

Ah yes, it’s probably strict aliasing. We could compile approxmath.h into approxmath.o without optimization.

But the boost from apow() was really only a few percent. We’d get much better improvement if we went from double to float, and reorganized the code a bit. Let’s switch back to pow(). Jens, can you submit a patch?

Thanks,
-Geoff

9

Hi all

The reversion from apow to pow also resolve this issue in CentOS 5.5.

Cheers

Louis

Le 24 août 2010 à 17:00, Louis Ricard a écrit :

I have a similar problem in CentOS5.5: when trying to display an orbital,
the program seems to go into an infinite loop after displaying
“Attempting to render orbital …” and nothing appens.

It woks in MacOSX though. Compiler issue?

Louis

Le 24 août 2010 à 16:47, Geoffrey Hutchison a écrit :

m_gtoCN.push_back(m_gtoC[j] * apow(m_gtoA[j], 0.75) * 0.71270547);
Whatever apow is, it returns 0 on my system and if I replace it with a call to pow, then everything works as expected.

I can’t work out what apow is being resolved to and it doesn’t appear to be called from anywhere else in the code.

The “apow” code is for an approximate power function, which should be found in approxmath.h, along with an approximate exp() function. There wasn’t a huge speedup from apow() so if we want to revert to pow(), I’m OK with that.

I think we can probably find better optimizations from reorganizing the orbital code.

-Geoff

Sell apps to millions through the Intel(R) Atom™ Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d

Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

Sell apps to millions through the Intel(R) Atom™ Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d

Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options