[Q-e-developers] QE-GPU and QE trunk, one step toward convergency

[Filippo Spiga]

Paolo,

as you probably noticed I've committed some changes between yesterday and today. I did all the tests I could reasonably perform to check that everything works, both QE and QE-GPU. If you see something weird or if you experience problem at compile time then feel free to revert back any change.

Cheers,
Filippo


On Apr 20, 2013, at 8:32 PM, Paolo Giannozzi <paolo.giannozzi at uniud.it> wrote:
> Hi Filippo
> 
> I admit that I never looked into the GPU stuff, and I never verify 
> the potential effects on it of my changes: I rely on you for this task!
> 
> I think that the solution you propose is a reasonable one.
> Asymptotically, if the CUDA version is going to stay, it has to 
> be more tightly integrated with the rest of the distribution. 
> There are many #ifdef's , notably  __MPI and __PARA that can 
> be removed, in case you feel guilty of aggravated #ifdeffing.
> 
> I do not know what Layla thinks, but I am quite confident that she 
> has a more urgent task these days!
> 
> Paolo
> 
>> due to on-going internal restructuring it is very difficult for me to
>> keep constantly aligned the plugin to the latest version of the trunk.
>> Despite I tried to put in place a set of naive scripts (not perfect
>> scripts, just something semi-automatic to help me figure out which
>> changes in the trunk may impact on the GPU code), I have to manually
>> look very often to the code and fix dependencies. Until now, my
>> philosophy was to completely let the trunk completely ignore the
>> existence of the QE-GPU plugin. However it is not practical from a
>> development point of view, not anymore. 
>> 
>> 
>> What I would like to do, is to let the code in the trunk (so the main
>> code) call eventually GPU routines if the plugin is used. This can be
>> easily achieved by isolate piece of code with a preprocessor macro
>> (__CUDA). 
>> 
>> 
>> Here an example of the changes I have in mind applied to
>> "PW/scr/addusdens.f90"):
>> 
>> 
>> !----------------------------------------------------------------------
>> SUBROUTINE addusdens(rho)
>>  !----------------------------------------------------------------------
>>  !
>>  USE realus,               ONLY : addusdens_r
>>  USE control_flags,        ONLY : tqr
>>  USE noncollin_module,     ONLY : nspin_mag
>>  USE fft_base,             ONLY : dfftp
>>  USE kinds,                ONLY : DP
>>  !
>>  IMPLICIT NONE
>>  !
>>  !
>>  REAL(kind=dp), intent(inout) :: rho(dfftp%nnr,nspin_mag)
>>  !
>>  IF ( tqr ) THEN
>>     CALL addusdens_r(rho,.true.)
>>  ELSE
>> #if defined(__CUDA)
>>     CALL addusdens_g_gpu(rho)
>> #else
>>     CALL addusdens_g(rho)
>> #endif
>>  END IF
>>  !
>>  RETURN
>>  !
>> END SUBROUTINE addusdens
>> 
>> 
>> 
>> 
>> The routine "addusdens_r_gpu" will be in a separate file called for
>> example "addusdens_gpu.f90" under the GPU directory. This file will be
>> compiled iff the proper Makefile.gpu (generated by
>> "GPU/install/configure") is used. From a generic non-GPU user
>> perspective, any piece of code or routine encapsulated by __CUDA will
>> be ignored. Simple but very effective.
>> 
>> 
>> I understand that introducing in several parts of the trunk the macro
>> __CUDA may look a dirty move but this will save a lot of my time and
>> it will simplify my job. Plus it might stimulate new people to develop
>> code for QE-GPU.
>> 
>> 
>> Paolo, Layla… any opinion?
>> 
>> 
>> If I can do that, I expect to commit all the changes by mid of this
>> week.
>> 
>> 
>> Cheers,
>> Filippo
>> 
>> 
>> --
>> Mr. Filippo SPIGA, M.Sc.
>> http://filippospiga.me ~ skype: filippo.spiga
>> 
>> «Nobody will drive us out of Cantor's paradise.» ~ David Hilbert
>> 
>> 
>> _______________________________________________
>> Q-e-developers mailing list
>> Q-e-developers at qe-forge.org
>> http://qe-forge.org/mailman/listinfo/q-e-developers
> 
> 
> _______________________________________________
> Q-e-developers mailing list
> Q-e-developers at qe-forge.org
> http://qe-forge.org/mailman/listinfo/q-e-developers

--
Mr. Filippo SPIGA, M.Sc.
http://filippospiga.me ~ skype: filippo.spiga

«Nobody will drive us out of Cantor's paradise.» ~ David Hilbert

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20130428/ad072760/attachment.html>