ramirezfranciscof
commented
9 years ago The idea would be that each "main" folder compiles into its own library?
I agree with separating the "interface" with amber from the calculation procedures of lio. I think it will make it easier if we want to include lio as a lib for other packages.
Regarding the scheme proposed, if I understand it correctly, the idea would be to store the code that is used in all the separate type of runs (and not specific of one) inside of common so that each other folder has independent code (and all of them depend on common). I think this would result in a lot of files that are not very related going into common (memory pools and timer along with all the int subs) and just a couple of files in each of the other folders. Moreover, if I am not mistaken, qmmm is not a separate type of run like SCF and TD but is something that is used by all of them.
Personally, I'm more inclined to a scheme more similar to the one I am trying to use now, where I leave the main files loose in the main folder and then organize procedures that are related inside subfolders which compile into single modules. Something like this:
LIO --Loose Files: Makefile, README --lioamber/interfaces --tests --postprocessing --src ----Loose Files: dip.f, dipmem.f, ehrenfest.f, init.f, finalize.f, liomain.f, magnus.f, mulliken.f, SCF.f, TD.f (among others, like a .mk) ----mathsubs ----integrals ----qmmm* etc.
- This is the difficult part because I don't have that great an idea of what is included in the g2g lib; if possible, I would prefer to create a module with "general" code to put stuff like the timers (and memory pools? I really don't know what are those), and the rest to be distributed in the corresponding already existing modules: for example, matrix multiplications in gpu would be inside of mathsubs, and since most procedures there are inside interfaces to "overload" them, I think we could just use ifdef like this:
interface basechange
ifdef GPU
module procedure basechange_d
module procedure basechange_c
module procedure basechange_z
#else
module procedure basechange_d_gpu
module procedure basechange_c_gpu
module procedure basechange_z_gpu
#endifend interface
If this is possible, I think that modules will be no problem for the gpu/cpu dualism; however it might not be as easy to do this neatly for the files that are loose in src, but I think this problem would also be present in the other scheme.
Anyway; is there a reason why this other scheme may not be advisable? Or why it might be worst than the one first proposed?
chopkins906
fedepedron
nanolebrero
As everybody is making tons of progress towards end of the year, and now that multiple branches are in place, it is time to step back and try to make changes that would simplify the code complexity a lot.
We've discussed a bit with @nanolebrero about separating the code in different sections that perform the various calculations. As of now, lioamber takes everything but the XC code and g2g is only about XC. A major issue would be how to deal with porting more and more things to CUDA (and Xeon Phi later on). This is very important, as @chopkins906 is making great progress on that front, as is @segmentat10nfault with CUBLAS port. The idea is to minimize code duplication and #ifdefs everywhere, that makes code hard to understand and hard to test.
A proposal to improve the current situation would be to split up the current folders into the different calculations when they become large enough (to be determined by the current maintainer).
This would be, as of now (considering @chopkins906 branch):
-lioamber/
-td/
-scf/ -- other/ -- xc/ ----cpu/ ----cuda/
-qmmm/ ---cpu/ ---cuda/
-common/ ---cpu/ ? ---cuda/ ?
-generated_libs/
The idea would be mostly to break up lioamber/ into the different calculations that make up SCF, and to leave in lioamber/ the few things needed to actually connect to AMBER.
Also, since most of what was needed to do QMMM easily was on the g2g folder, that code would be moved to a common folder (things like Matrix, Timers, vec_types, memory pools). That would greatly simplify both g2g (now xc) and QMMM, making it more concise and unified. I think that most of the work @ramirezfranciscof is doing on Fortran could also go into this folder, it might benefit the C code too (not sure on how that might be done).
Of course this will be a mess of Makefiles at first, but I am confident this will be positive in the long run, as to reduce the amount of code duplication and complexity would lower the barrier of entry for everybody in the long run.
As I am not aware of everything done by LIO, I am requesting input from all of you. The proposed schema is just a first thought and in no way a fixed decision. If anyone has any ideas on this, let's share them so we can discuss them and make a better product.