Pre-evaluation and discussion on branches to be merged in the master

[andreamarini]

tech-master and tech-maintenance will be merged in the new release in less then a montb.

I opened this issue to start discussing and addressing the specific aspects (non general comments here) of the branches to be merged.

I start with two questions:

• why did you rename src/modules?
• why did you rename memory.h

I will post here more questions as soon as I analyze the source.

[sangallidavide]

The reason is that memory.h and libmodules.a are very general and present in the os.
So we wanted to be sure to avoid linking the wrong file.
On my machine for example it exist
/usr/include/memory.h

• memory.h --> y_memory.h renaming was done. But I think it never gave problems.
• libmodules.a --> libYmodules.a I think was done because it gave some problems at a certain point.
  @nicspalla might have more info

Anyway, I agree that we should carefully checked this before doing the changes.

As a side remark. It is a bad practice to have all modules in a folder, it would be better to have the modulse spread across the different folders, each one associated with the connected libxxx.a

[andreamarini]

The module library is present in Yambo from the very beginning (more than 20 years) and never gave a problem.

Moreover also in my machines there exists a memory.h. Actually there are many.

The problem is not in the existence of the file but in the path given at the linking trough -I.

So unless there are general arguments I would prefer to avoid these kind of global renaming.

[attacc]

Ciao

The problem is not in the existence of the file but in the path given at the linking trough -I.

Yes, but having different names makes the code less prone to linking errors. ciao Claudio

…

-- ========================================================== Mobile[FR]: +33662922897 Mobile[IT]: +393384315437 Fax: +33491418916 Address: CINaM Campus de Luminy 163 Avenue de Luminy, Case 913 13288 Marseille Cedex 9 Skype: claudioattaccalite Editor Fellow for: www.scipost.org web site: www.attaccalite.com ===========================================================

[andrea-ferretti]

I think the need to modify Modules -> YModules (as well memory.h in y_memory.h) came from compilation issues found on LUMI using the cray compiler and OpenMP-GPU. I think at the time we resorted to this as the only way to workaround the problem.
I see two options:

• we revert the change and find a workaround for compilation (without guarantee it would be trivial)
• we take this as an opportunity to make the code more robust against linking (as Claudio suggested).
• Ideally we did the same also for kind.h -> y_kind.h, that eventually I reverted since it was not blocking but involved ydriver (which I didn't want to mess up with)

[muralidhar-nalabothula]

#include <memory.h> has an implementation-defined behavior, meaning its behavior may vary depending on the compiler. For instance, gcc or clang might search the user-provided include path first and then the system headers, while the Cray C compiler might prioritize the system headers before the user-provided directories.

If you prefer to stick with the previous file names, here are some alternatives :

1. #include "../modules/memory.h": This method uses a relative path to the header, eliminating the need to specify linker options.
2. #include "modules/memory.h" or #include <modules/memory.h>: In this case, provide the include path using -I/path/to/yambo/src.

Each approach has its advantages and disadvantages.

[sangallidavide]

Thanks Murali.

Options such as #include "../modules/memory.h" would require anyway to change all code lines. So I'd go for #include <y_memory.h>

Since we are touching this part.
The file y_memory / memory.h contains these lines at the top

 use y_memory,     ONLY:MEM_err,MEM_msg,MEM_count,MEM_count_d,MEM_global_mesg,IPL
#if defined _OPENACC || defined _OPENMP_GPU
 use devxlib,      ONLY:devxlib_map,devxlib_unmap,devxlib_mapped,devxlib_memcpy_h2d
#endif
 implicit none

which forces its placement in the source.

I'd rather remove them
a) define a macro USE_MEMORY
b) put implicit none back into the source

Doing so the header can go in his correct place (e.g. as header of the subroutine), and (eventually) does not need to be repeated in the same file

#if defined _OPENACC || defined _OPENMP_GPU
define USE_MEMORY \
 use y_memory,     ONLY:MEM_err,MEM_msg,MEM_count,MEM_count_d,MEM_global_mesg,IPL NEWLINE \
 use devxlib,      ONLY:devxlib_map,devxlib_unmap,devxlib_mapped,devxlib_memcpy_h2d
#else
define USE_MEMORY \
 use y_memory,     ONLY:MEM_err,MEM_msg,MEM_count,MEM_count_d,MEM_global_mesg,IPL
#ednif

Not a fan of the NEWLINE thing that I invented ... but I do not have a better solution for multi-line macros.

[andreamarini]

Thanks Murali.

I personally like Murali's proposal.

Options such as #include "../modules/memory.h" would require anyway to change all code lines. So I'd go for #include <y_memory.h>

Same lines that are touched by changing memory.h into y_memory.h