Working as a library

[GoogleCodeExporter]

There is an ongoing discussion, whether ADDA could (and should) be used as a 
library (either statically or dynamically linked). See, e.g., discussion at 
http://groups.google.com/d/msg/adda-discuss/pZfeBjS4eL0/wsaNcifA_54J

My current thoughts are the following:
1) I am still not aware of a case, where such functionality is strictly 
necessary. In most cases it will remove some overhead, but total speed 
improvement would be relatively insignificant. However, it may add some 
convenience in using ADDA and building wrappers for it.

2) It is in principle possible but not trivial at all. In particular, the 
problem is that ADDA heavily uses global variables (both really global - see 
vars.c/h - and static inside source files). It has some advantages, but it 
causes a lot of problems in using ADDA functions. So it is hard to get anything 
useful out of these functions (as library calls) without significant additional 
efforts. 

3) Another problem is the license, which was recently pointed by Irwin Zaid. 
ADDA is currently under GPL, and the latter can't be changed to anything less 
restrictive, such as LGPL. That is because it uses (links against) FFTW3, which 
is licensed under GPL (http://www.fftw.org/doc/License-and-Copyright.html). 
Similar limitation (GPL license) is related to IGT routines 
(fort/propaesplibreintadda.f) that were contributed several years ago by other 
researchers. There are also a number of routines, which license is not 
specified - see, e.g., another FFT routines fort/cfft99D.f or those in misc/ 
folder.

The license becomes relevant if any commercial (or not GPL) software wants to 
use ADDA. The situation is somewhat ambiguous, but I think that it can run ADDA 
(as is now) from the command line, but can't link to it as a library.

Original issue reported on code.google.com by yurkin on 10 Jul 2014 at 4:48

[GoogleCodeExporter]

Is there a way to have adda compute only one polarization when working from the 
command line? In my cases I know the incident polarization and don't need the 
full scattering matrix, so I think there could be an easy factor of two speedup 
if I could avoid the double solution.

Original comment by triplepo...@gmail.com on 10 Jul 2014 at 11:45

[GoogleCodeExporter]

Tom, see issue 30. Not yet implemented as it should, but there already exist a 
workaround. Please let me know if that is fine for you workflow.

Original comment by yurkin on 10 Jul 2014 at 11:52

[GoogleCodeExporter]

Fast and dirty approach will be to write a wrapper class with a priviate method 
RunADDA() with almost the same content as main function. The purpose ot the 
class is just to compile agrv_ from private data and pass it to RunADDA(). 
Class will also provide several public methods like 
SetParticlesPositions(std::vector<std::vector<double> > coord) and 
SetParticlesSize(std::vector<double> size)

Any recommendation, so it can be contributed to the project? There is a student 
project here, so there is a high chance that it would be implemented someway.

https://groups.google.com/forum/#!topic/adda-discuss/aU-Vx_oTWSM

Original comment by kostyfi...@gmail.com on 17 Dec 2014 at 10:59

[GoogleCodeExporter]

Konstantin, as a separate project, you are welcome to do as you wish. A 
relevant question is whether you want also to get some data out of ADDA, or 
will it be enough to get the standard output files? 

Concerning the contribution to ADDA - there are several possible options. 
First, this can be done in misc/ folder, but then it should be possible to 
compile it separate from the main ADDA code. For instance, you may create a 
separate C++ program (with all public methods you want, it can even contain 
GUI) that would prepare a command line and/or input files and run ADDA through 
the system call. Then the program can parse the output.

Second option is to make a separate ADDA branch with possible future 
incorporation in the main (trunk) code. But that requires additional 
discussion. It boils down to what are changes/complications to the code (trunk 
version) vs. the expected gains. As I understand (I have very limited knowledge 
of C++), such wrapper would change the whole compilation mode to C++, wouldn't 
it? It seems not justified, concerning that it doesn't add a lot of usability 
compared to the wrapper described above. Is it possible to make it in C and so 
that it would be turned on only by a special flag during compilation?

Original comment by yurkin on 17 Dec 2014 at 5:10

[GoogleCodeExporter]

I thank that misc/ section is a good starting point. I hope C++ can be rather 
isolated from the other sections of the code. For ease of the maintains it can 
be needed to add
#ifdef __cplusplus
extern "C" {
#endif 
and closing bracket section to some of original adda files.  This way it should 
be possible to 
1) Compile ADDA with C compiler (may be we should start with only gcc support).
2) Compile C++ part of the code with g++
3) Link it with C++ linker.
So the first step will be to implement ADDAmain.cc to compile and link with 
C++, and obtain the exactly same behaviour as from ADDAmail.c 

Taking out the final results from the ADDA seems to be a little bit harder 
task, however, I suppose we can mange it too.

Original comment by kostyfi...@gmail.com on 17 Dec 2014 at 11:08

[GoogleCodeExporter]

I hope that as a final result ADDA will be compiled with only C and Fortran 
compiler as it happends now. For those who need C++ interface additional make 
commands are needed. So it shoulbe just an additional make command, like "make 
cppapi".  Except of contribution to our own project i suppose that such a C++ 
interface can be useful for implementing python interface. Or, e.g. it will 
become much easier to write self-contained tests for adda.

Original comment by kostyfi...@gmail.com on 17 Dec 2014 at 11:20

[GoogleCodeExporter]

OK, sounds good. So please continue with your project and try to make a working 
something with as little changes to the main ADDA code as possible.

Original comment by yurkin on 19 Dec 2014 at 6:51

[GoogleCodeExporter]

See attached file, uncompress it to misc/ ,then  cd adda/misc/cpp_api and run 
./dev-compile.sh
this will call make seq in add/src, copy file from misc, compile and link with 
c++.

The problem is that at the moment ADDAmain.c do not use ADDA as a library 
itself, so I had created the it`s copy and renamed it as run-adda.c 

The only change inside - I renamed main(...) to RunAdda(...), so I can call it 
from my C++ code. The resulting binary ./adda-cpp seems to produce exactly the 
same results.

adda/src/seq$ ./adda-cpp > test-cpp
adda/src/seq$ ./adda > test-c
adda/src/seq$ diff test-cpp test-c
1c1
< all data is saved in 'run004_sphere_g16_m1.5'
---
> all data is saved in 'run005_sphere_g16_m1.5'

Is it possible to add this run-adda.c to the source tree, and change main() of 
ADDAmain.c to has the only function call? After that i can continue with 
writing a C++ API in misc.

Original comment by kostyfi...@gmail.com on 25 Dec 2014 at 4:26

[GoogleCodeExporter]

attach for the previous comment

Original comment by kostyfi...@gmail.com on 25 Dec 2014 at 4:27

Attachments:

• cpp_api.tar.gz

[losVorwaerts]

这是来自QQ邮箱的自动回复邮件。您好，我已收到，会尽快回复。

[losVorwaerts]

这是来自QQ邮箱的自动回复邮件。您好，我已收到，会尽快回复。