search

xraypy / feff85exafs

Feff8L: Open Source theoretical EXAFS fitting standards
Other
15 stars 7 forks source link

ints vs long on 64-bit #24

Closed newville closed 7 years ago

newville commented 9 years ago

Vague Error Report Warning:

I think there is a problem with the C wrapper, and probably with other wrappers on 64-bit systems (including Darwin and Linux). I discovered this playing with the Python_ctypes wrapper, and compared the Fortran to C wrapper. Basically, the "ipot" and "iz" arrays in Fortran are "integers", but from C they are called "long". I think they need to be 32-bit integers, and that, as longs, they aren't correct in onepath.f.

I'm not sure what the right solution is....

bruceravel commented 9 years ago

Hmmm. I guess I would not have noticed this. The computer I am sitting at is a 32 bit machine.

So, will it better to explicitly type ipot and iz in onepath? Or to downgrade from long to int throughout feffpath?

newville commented 9 years ago

On Tue, Jan 13, 2015 at 8:28 AM, Bruce Ravel notifications@github.com wrote:

Hmmm. I guess I would not have noticed this. The computer I am sitting at is a 32 bit machine.

So, will it better to explicitly type ipot and iz in onepath? Or to downgrade from long to int throughout feffpath?

I think think latter, but I'm not completely sure. I'll try to look into this in more detail.

newville commented 9 years ago

an update: I did verify that changing all longs to ints in GENFMT/feffpath.h, GENFMT/feffpath.c, and the wrapper/C/*.c files did compile, run, and seem to do the right thing. I also verified this with the wrapper/python_ctypes wrapper, though that is not yet complete.

On a 64-bit linux machine, testing ran 60 tests, with 2 skipped tests and one failure related to XDI files. I think that means that all the Feff tests actually worked.

I do not know whether using int throughout will work on 32-bit systems. I would imagine we might actually need a #define block that ensures the integers passed to Fortran are 32-bit integers. Probably someone has solved this....

bruceravel commented 9 years ago

one failure related to XDI files

I think this should be fixed in https://github.com/xraypy/feff85exafs/commit/69b945b63691fa82269d07bd85d760a27b21637d

There was a mistake in Athena's XDI code that played very poorly with Larch's read_xdi

newville commented 9 years ago

On Wed, Jan 14, 2015 at 10:29 AM, Bruce Ravel notifications@github.com wrote:

one failure related to XDI files

I think this should be fixed in 69b945b https://github.com/xraypy/feff85exafs/commit/69b945b63691fa82269d07bd85d760a27b21637d

There was a mistake in Athena's XDI code that played very poorly with Larch's read_xdi

It was actually because I didn't correctly build / install the XDI dynamic library for linux64. With that correctly installed, I get 72 tests run (SKIP=2) all OK on 64-bit linux, with the changes as described above.

bruceravel commented 9 years ago

I just ran into the same int vs. long problem on one of my computers. Also not sure about 32 bit machines, but I agree that all the longs should be ints in feffpath.h and feffpath.c. In a few minutes, I will soon make a PR with that change.