[CP2K:455] Re: getting rid of hard-coded MPI_COMM_WORLD

[Fawzi Mohamed]

On Dec 5, 2007, at 4:59 PM, Axel wrote:

> On Dec 5, 4:17 am, Fawzi Mohamed <fa... at gmx.ch> wrote:
>
> hi fawzi,
>
>> I wrote the f77_interface trying to exactly achieve that.
>
> right. i should have mentioned, that i realized 99% of what
> i have in mind is already done (great job, BTW. it is always
> too easy to forget acknowledging that one is only worrying
> about a tiny detail).

thanks!

>> There are two routines to create force_envs one that recieves
>> explicitly a group (actually a communicator, in cp2k we have it
>> sistematically misnomed) and another that has no arguments (and
>> defaults to MPI_COMM_WORLD).
>> This is actually already used internally in cp2k and should work.
>> If it doesn't then it should definitly be fixed.
>
> yep. i'll look into it and will probably only find out, once
> i have a prototype code to try it out. my question was mainly
> intended to find out, whether there was a technical reason to
> do everything as it is done now.

as always it is a mix of technical an historical reasons.

An important point to keep in mind is that even if in cp2k we have  
tried avoid any global state, still there is some.
Mainly this is are default error/logging and performance/timing  
functions (global state that is constant like physical/units does not  
give problems) .

At the moment f77_interface maintains a list with this global stuff,  
also this global things have a stack like organization.

At the beginning all global initializations are performed and a first  
level of log/error,... is set up
This is what init_cp2k does.
Normally init_cp2k initializes the mpi environment, but I added a  
flag so that this can be avoided.

This first layer is basically never used.

Each force_env has its own default log/error/... and its calculations  
are done within it
The routines f_env_add_defaults, f_env_rm_defaults are those that  
swap the enviroment, so that each calculation has the correct setup.

Any routine in f77 has to call these two routines to have the correct  
environment, and basically all the error should happen inside these.

Note that this setup assumes that in one task there is only one  
active environment, no multithreading between force_envs!

>> Or you want to change the init routine (wich just defines a general
>> fallback in case of really bad errors)?
>
> yep. i'd also like to enter the init routine with a group
> communicator.
> i am thinking about working on a code that would control multiple
> MPI-parallelized codes, so the "supervisor" code would need to hog
> the world communicator, partition it into suitable groups and hand
> a group communicator to each code.

this is possible, and if you need it could be changed, but then you  
have to be *absolutely* sure that one never creates a force_env on  
processors that were not initialized or *bad* things will happen (no  
initialized constants, no safe fallback shell,...

So i there is not a strong reason to do it I would make a global init  
(the overhead should be small, some memory, but not too much) and  
then pass the sub communicators for the created force_env.

> that being said, the fact that cp2k _is_ already 99% independent of
> any hardcoded communicators is - apart from the features - the reason
> why we are considering it in the first place. ;-)
> [...]

great :)

ciao
Fawzi