[Q-e-developers] introduce a parallel communicator derived data type ?

[Carlo Cavazzoni]

Ciao Stefano,

I don't see any drawback in moving forward with data encapsulation,
basically we will have less "pass through" scope extensions and data 
dependencies coming from the
use of keyword "use", and more explicit dependencies from variables 
passed as an argument
to subroutines. These are good software engineering practices that 
should make the code
easier to develop and maintain .

Regarding the structure you propose, and pushing encapsulation even further,
I'm wondering if it is not the case to wrap the MPI communicator with a 
basic communicator type,
so to have an enforced hierarchical structure, remove ambiguities with 
names, and
generalize the usage to other comm geometries rather than groups created 
with comm_split.
Something like:

type basic_comm
    INTEGER :: comm = MPI_COMM_NULL
    INTEGER :: npes = 0
    INTEGER :: mype = 1
end type

TYPE comm_group
    CHARACTER(len=35) :: label ! the name of this parallelization level
    TYPE basic_comm :: parent_comm ! the parent communicator from which 
it originates
    TYPE basic_comm :: intra_comm ! intra group communicator
    TYPE basic_comm :: inter_comm ! inter group communicator
    INTEGER :: ngroups = 1 ! number of created groups parent communicator
    INTEGER :: my_group_id = 0 ! which of the created groups this proc 
belongs to
    INTEGER :: root_group_id = 0 ! the group_id of the root group (it's 
always 0 as root is the first by def)
END TYPE comm_group


TYPE comm_XYZ
    ...
END TYPE comm_XYZ



Il 06/08/2017 17:55, stefano de gironcoli ha scritto:
> Dear All,
>
>     I would like to in introduce a Parallel Communicator derived data type.
>
>     The aim would be to make the information associated to the different
> parallelization levels more structured and uniform. They already look
> all the same (see intra_image_comm/inter_image_comm,
> intra_pool_comm/inter_pool_comm, intra_bgrp_comm/inter_bgrp_comm,...)
> but this is obtained by quite bit of code duplication and if a
> new/different parallelization level is desired one needs to write more
> almost identical code and double check in many places.
>
>     The parallel communicator data type would allow, in future, to pass
> the communicator as argument of the routines so making the
> parallelization level easily 'local' to the routine that would help
> disentangling the different parallelization levels and possibly
> introduce them when needed rather than all at the beginning.
>
>     I don't know how much this will be possible/desirable but with the
> current structure it is clearly impossible.
>
>     Anyhow, since this is going to have an impact on the distribution at
> all levels I would like to have a preliminary feedback.
>
>     In particular if you see compelling reasons NOT to take such a path !
>
>     best,
>
> stefano
>
>
> PS: the derived data type would look something like this
>
> TYPE pcomm_type
>        CHARACTER(len=35) :: label         ! the name of this
> parallelization level
>        INTEGER :: parent_comm = 0         ! the parent communicator from
> which it originates
>        INTEGER :: intra_comm = 0          ! intra group communicator
>        INTEGER :: inter_comm = 0          ! inter group communicator
>        INTEGER :: ngroups = 1             ! number of created groups
>        INTEGER :: nproc = 1               ! number of processors per group
>        INTEGER :: parent_nproc = 1        ! number of processors of the
> parent communicator
>        INTEGER :: my_group_id = 0         ! which of the created groups
> this proc belongs to
>        INTEGER :: mype = 0                ! the index (rank) of the
> processor inside its group
>        INTEGER :: mype_in_parent_comm = 0 ! should be clear by the name
>        INTEGER :: root_group_id  = 0      ! the group_id of the root
> group (it's always 0 as root is the first by def)
>        INTEGER :: root = 0                ! the index (rank) of the root
> processor inside the group (it's always 0)
>     END TYPE pcomm_type
>
> _______________________________________________
> Q-e-developers mailing list
> Q-e-developers at qe-forge.org
> http://qe-forge.org/mailman/listinfo/q-e-developers


-- 
Ph.D. Carlo Cavazzoni
SuperComputing Applications and Innovation Department
CINECA - Via Magnanelli 6/3, 40033 Casalecchio di Reno (Bologna)
Tel: +39 051 6171411  Fax: +39 051 6132198
www.cineca.it