Add a non-blocking version of gs

[thilinarmtb]

Add a non-blocking version of gs for pairwise and all_reduce modes. Currently they pass the tests in gslib/gs_test.c and gslib/gs_unique_test.c;

Also, tests were added for both blocking and non-blocking versions.

TODO

• [x] Add gs_many, gs_vec support
• [x] Add tests for gs_many and gs_vec
• [x] Add Fortran interface
• [x] Test Fortran interface

[thilinarmtb]

@stgeke : I think this is good for merging as it is. Let me know if you have additional feedback. We should decide on how to expose the non-blocking API to the user.

[stgeke]

Let’s add the user API (C and Fortran) before merging. What do you suggest as API?

On 19 Jan 2018, at 14:23, Thilina Rathnayake <notifications@github.com mailto:notifications@github.com > wrote:

@stgeke : I think this is good for merge as it is. Let me know if you have additional feedback. We should decide on how to expose the non-blocking API to the user.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[thilinarmtb]

@stgeke : How does a707a01 looks like? Any comments?

[thilinarmtb]

We can add one more level of indirection (using double pointers) so that we can free individual entries of the array nblkng_dict, which is also an option.

[thilinarmtb]

e4c138e is the solution using another level of indirection.

[thilinarmtb]

@stgeke : Added the interfaces for gs_vec and gs_many. Will add tests as well. Are you fine with the API for these two?

[stgeke]

• Do we really seperate wait routines for gs, gs_vec and gs_many?
• Can you also test pw (instead of just allreduce) in gstest
• Before merging we should also get the Fortran interface in place

[thilinarmtb]

• We can get rid of the three separate waits (as well as non-blocking calls to gs, gs_many, gs_vec) by asking user to pass the mode which can be mode_plain, mode_vec and mode_many. If we don't want user to pass these, we will need three separate calls to gs_* and gs_wait as there is no way of knowing which type of non-blocking call user issued before. What do you think?
• I will add tests for pw.
• Yes, I will add the Fortran interface as well.

[stgeke]

I guess the three separate wait() functions are ok.

[stgeke]

Now as I am thinking of it .. why can't we use the request handle to differentiate between the modes?

[thilinarmtb]

Ahha, Yes we can. I will update the API.

[thilinarmtb]

I made the change, now we can use a single gs_wait. There is another small issue. gs_many takes a void *const *u as the first argument while gs and gs_vec uses void *u. It might be a problem as we use the same structure to store arguments. I will add tests to confirm. Currently, it gives compiler warnings.

[stgeke]

You can use gs_setup_pick().

-----Original message-----

From:Thilina Rathnayake notifications@github.com Sent: Thursday 3rd May 2018 20:45 To: gslib/gslib gslib@noreply.github.com Cc: Stefan K. stgeke@gmail.com; Mention mention@noreply.github.com Subject: Re: [gslib/gslib] [WIP] Add a non-blocking version of gs (#11)

@thilinarmtb commented on this pull request.

In tests/fortran/f-igs.f https://github.com/gslib/gslib/pull/11#discussion_r185900860:

• call mpi_comm_rank(mpi_comm_world,me,ierror)
• count=1
• if(me.gt.0) then
• id(count)=me
• count=count+1
• endif
• id(count)=me+1
• count=count+1
• if(me.lt.(np-1)) then
• id(count)=me+2
• count=count+1
• endif
• neighbors=count-1
• call gs_setup(handle,id,neighbors,mpi_comm_world,np) We might have to change the Fortran interface to come up with a workaround. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gslib/gslib/pull/11#discussion_r185900860, or mute the thread https://github.com/notifications/unsubscribe-auth/ARumfyFxZNjY7Fo9m6p6hvSwjGgcZ5tiks5tu1AvgaJpZM4QdyAg.

[thilinarmtb]

Thanks @stgeke ! I fixed it. I am okay with merging this PR now.

[thilinarmtb]

@stgeke Thanks for merging !!