compiling yambo without precompiler flags for projects

[sangallidavide]

Reorganization of sources in order to remove "project related pre-compiler" flags

Now make yambo_ph works without needing recompiling the source.
Still this needs to be extended to ypp_ph, and all other projects ...

2 preliminary actions
a) modules folder removed.
b) renamced "driver" --> "ymain"
(this to avoid confusion between "driver" and "src/driver")

I avoided taking specific decisions and duplicated some sources for now:
a) src/driver
b) src/interface
c) src/qp
d) ymain

Below the output of "make yambo_ph", done after "make yambo"
Setup is done, but it is not needed.

$ make yambo_ph
    [lib/qe_pseudo] qe_pseudo (setup)
    [lib/slatec] slatec (setup)
    [lib/math77] math77 (setup)
    [lib/local] local (setup)
    [src/driver_ph] driver_ph (setup)
    [src/el-ph] el-ph (setup)
    [src/interface_ph] interface_ph (setup)
    [src/qp_ph] qp_ph (setup)
    [src/driver_ph] launcher_ph
    [src/driver_ph] options_maker_ph
    [src/driver_ph] options_ypp_ph
    [src/driver_ph] lib_Y_driver_ph.a (lib)
    [src/el-ph] mod_ELPH
    [src/el-ph] FREQUENCIES_Green_Function_spectral
    [src/el-ph] mod_ELPH_intfcs
    [src/el-ph] variables_ELPH
    [src/el-ph] io_ELPH
    [src/el-ph] io_gFsq
    [src/el-ph] io_QP_and_GF_ph
    [src/el-ph] SET_defaults_ph
    [src/el-ph] ELPH_alloc
    [src/el-ph] ELPH_Sigma_c
    [src/el-ph] ELPH_Hamiltonian
    [src/el-ph] ELPH_simmetrize_and_distribute_gsqF
    [src/el-ph] Eval_Efermi_DbGd
    [src/el-ph] ELPH_gsqF_to_Sigma
    [src/el-ph] ELPH_Sigma_c_engine
    [src/el-ph] En_k_plus_q_interpolate
    [src/el-ph] get_ph_E_DbGd
    [src/el-ph] ELPH_databases_load
    [src/el-ph] ELPH_databases_check
    [src/el-ph] ELPH_databases_grids_map
    [src/el-ph] ELPH_databases_symmetrize
    [src/el-ph] ELPH_acoustic_phonon_properties
    [src/el-ph] lib_Y_el-ph.a (lib)
    [src/interface_ph] INIT_load_ph
    [src/interface_ph] INIT_ph
    [src/interface_ph] INIT_read_command_line_ph
    [src/interface_ph] INIT_check_databases_ph
    [src/interface_ph] INIT_activate_ph
    [src/interface_ph] INIT_q_points_ph
    [src/interface_ph] INIT_barriers_ph
    [src/interface_ph] lib_Y_interface_ph.a (lib)
    [src/qp_ph] QP_driver_ph
    [src/qp_ph] QP_newton_ph
    [src/qp_ph] QP_logicals_ph
    [src/qp_ph] QP_descriptions_ph
    [src/qp_ph] QP_report_and_write_ph
    [src/qp_ph] lib_Y_qp_ph.a (lib)
    [ymain_ph] yambo_ph (setup)
    [ymain_ph] yambo_ph (link)

[andrea-ferretti]

Hi Davide,

it looks all very nice !!!
I think the disentanglement of PH looks very good to me...

A couple of questions/comments:

• I see mod_X.F is ended up in src/matrices. Is this wanted ?
• ymain*: are these meant to become the entry point for each related source tree ?
  Another option would be to move the content inside src/driver* (why are the two kept separated ?)
  Anyway: this is housekeeping for later, all options are fine with me.

Minor points:

• in mod_X.F there is a missing var name at line 197 (DO_it, I guess)
• ./common_sc_rt/SET_defualts_comm.F: defualts -> defaults

I would merge ASAP and keep working there
A

[sangallidavide]

I converted this to a draft to stress that it is an ongoing work

A couple of questions/comments:

I see mod_X.F is ended up in src/matrices. Is this wanted ?

This is one of the points were decisions should be made. At present many modules are inter-dependent, and it is not possible to compile without putting them together. As a consequence I had to distribute them across the first folders which are compilerd.
parser memory matrices allocations
Some possible solutions / actions include:
a) changing the modules to make them less interdependent
For example mod_interfaces should be split into mod_BS_interfaces, mad_matrix_interfaces, etc ...
b) to keep some common-modules folder
c) to reduce the number of folders
d) to change the compilation order

ymain*: are these meant to become the entry point for each related source tree ?
Another option would be to move the content inside src/driver* (why are the two kept separated ?)
Anyway: this is housekeeping for later, all options are fine with me.

In the past there were driver and src/driver. I just rename driver --> ymain to minimize the changes. I'm also fine with just having src/driver. To check what would happen with the compilation scheme

[andreamarini]

Dear all, as you know in the next 3 weeks it will be impossible for me to check and work on the code.

As the procedure of disentangling the projects will enter very very deeply in the structure of the code I do think it must be done slowly and collegiality.

So, please, let's take all time needed. Step by step.

Also because we need to understand how to propagate such deep changes plus how to design the APIs and so on.

[andreamarini]

More specifically.

For the moment I would not rename/move anything.

I would split all routines/modules in common+project dependent parts.

Move the project specific somewhere else (eventually renaming).

But not change anything more.

Once this is ready we could proceed with a first merge in the personal branches.

Then we move to a new project.

Slowly. Otherwise it will be a pain

[sangallidavide]

Yeah, I'm trying to reduce the changes in order to minimize the conflicts in future merges.

Please notice that
i) moving / renaming a file or folder does not give conflics. git easily handle this.
ii) splitting a module or a subroutine is instead source of conflicts because git is not able to track this

This is way I'm avoiding as much as I can splitting subroutines

[sangallidavide]

I've restored src/modules with most of the modules inside.