Functional cannot be initialized in language X and used in language Y

bast commented 6 years ago

It seems to me that the Fortran and C interfaces do not share addresses and setting a functional in Fortran and trying to evaluate it in C seems to fail. It seems that currently mixing languages this way is not possible. The solution would be to provide a Fortran interface that talks to the C interface using iso_c_binding.

simensr commented 6 years ago

Hi Radovan, Thanks for the summary of the problem. Including it here for later reference:

After re-diving into the issue i see what the problem was which prevented me from finishing it in February: this is a limitation of XCFun actually that you cannot set the functional in Fortran and compute derivatives in C++. It works if you stay in Fortran. But XCint is C++.

This means that I have the following choices:

rewrite the Fortran interface in XCFun, quite some work

work around this problem on the LSDalton side, quite some work

not do anything but then you have to write some C code in LSDalton and I am not sure you are comfortable with that

parse the functional inside XCint, this is least work but maximum ugly from the library design perspective since we then parse it in two places, in LSDalton and in XCint but it has the advantage that the code calling XCint will not have to interact with XCFun at all

Before I can make any suggestion for a good choice here I will have to have look at how the C-interface works. Is there an example I can look at here?

bast commented 6 years ago

Here is an example: https://github.com/dftlibs/xcint/blob/radovan/half-baked/test/energy_spherical.cpp#L295-L300

simensr commented 6 years ago

I have looked a bit into this, and currently I am a bit puzzled as to why you cannot set the funcitonal in Fortran and use it in C. As far as I can see in LSDALTON all fortran interface routines calls the routines in fortran/xcfun_module.F90 that again call c-routines, like xc_get calling xcgets. The additional parsing on the lsdalton side is mainly for GGAKEY and for range-separated functionals...

It is my impression now that the only 'pointer' needed is the integer value of funid. But I am sure you have already looked at this and that it does not work that way @bast. Still I am puzzled as the fortran layer is tiny. All routines doing actual work is in C (which I btw. have not really worked on since 2004).

Any comments @bast?

bast commented 6 years ago

It's true that at the end it's all C code but in LSDalton you only interact through the Fortran interface and your handle to the functional is an integer. If you want to interact with the C interface, then your functional is a struct. And this is what fails for me. So IMO the solution would be to change the Fortran interface from an integer handle to a derived type which maps to the struct.

simensr commented 6 years ago

Perhaps you can simply extract the functional struct from fortran_functionals in src/fortran.c?

simensr commented 6 years ago

I forgot to include the @bast in the previous comment. Not sure you got an email, so including it here:-)

bast commented 6 years ago

Thanks, once I am part of a conversation (see participants to the right) you don't need to explicitly add a handle.

simensr commented 6 years ago

Oh, okay, thanks:-D