[Q-e-developers] Something wrong due to the esm module

[Minoru Otani]

Dear Andrea,

Thank you for pointing out my misunderstanding. 

Let me explain more precisely. My understanding of this problem is the following. 
The nesting structure of the cft_1z results in a destruction of the fft plan used in 
the ESM routine. Because cft_1z makes own fft plans for each OMP threads.This
procedure destroys the fft plan in the ESM. 

To avoid this, we added the following part in the esm.f90 (version 5.1.1) to make 
sufficient number of plans for cft_1z.

---- 
! Workaround for initialization of "planes" fw_planz and bw_planz in cft_1z
! These planes are shared among OpenMP threads. We need to make a plane outside
! OpenMP parallelization to avoid unexpected destroy and generation of planes

  ALLOCATE(vg2_in(dfftp%nr3x),vg2(dfftp%nr3x))
  vg2_in(:) = 0d0
  vg2(:) = 0d0
  CALL cft_1z(vg2_in,1,dfftp%nr3x,dfftp%nr3x,-1,vg2)
  DEALLOCATE(vg2_in,vg2)
----

This is a temporary workaround. So we make esm_cft.

Best regards,
Minoru

> On Nov 2, 2015, at 5:36 PM, Andrea Ferretti <andrea.ferretti at nano.cnr.it> wrote:
> 
> 
> 
> Hi all,
> 
>> 
>> Regarding the latest your modification (esm.f90 at October 28), we should not move the esm_cft
>> to cft_1z. Because in the ESM, I did OMP parallelization outside the g_parallel loop (see lines from
>> 439 to 481, I’m referring the file at October 29). When we use FFTW and OPENMP, the cft_1z
>> is parallelized again inside the subroutine. Thus this structure is nested by OpenMP parallelization.
> 
> 
> just a side question: my understanding of nested openmp loops is that if omp_nested is set to false (call omp_set_nested(.false.)) inner loops are disregarded...
> is this correct ? if so, couldn't one rely on this to sort out the problem above ?
> 
> take care
> Andrea
> 
>> A few years ago, somebody experienced an error originated from this nesting structure. So I made
>> a new 1D FFT routine in which all calculations will be done by serial process.
>> 
>> Best regards,
>> Minoru
>> 
>> On Oct 28, 2015, at 7:09 PM, Paolo Giannozzi <p.giannozzi at gmail.com> wrote:
>> 
>>> 
>>> 
>>> On Mon, Oct 26, 2015 at 11:30 PM, Filippo SPIGA <filippo.spiga at quantum-espresso.org> wrote:
>>> 
>>> I confirm the files compiles
>>> 
>>> ... but it doesn't work. Here attached a version that compiles and doesn't use "esm_cft" but the same cft_1z of all other codes. The example seems to work. Minoru, could you please verify if it works in some realistic case and if there are any problems with FFT initialization,and openmp? (I remember that the previous version of ESM had a different logic for OpenMP parallelization of FFT with respect to the one used in all other codes, but it seems to me that now it uses the same logic)
>>> 
>>> Paolo
>>> 
>>> --
>>> Paolo Giannozzi, Dept. Chemistry&Physics&Environment,
>>> Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
>>> Phone +39-0432-558216, fax +39-0432-558222
>>> <esm.f90>_______________________________________________
>>> 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
>> 
>> 
> 
> -- 
> Andrea Ferretti, PhD
> S3 Center, Istituto Nanoscienze, CNR
> via Campi 213/A, 41125, Modena, Italy
> Tel: +39 059 2055322;  Skype: andrea_ferretti
> URL: http://www.nano.cnr.it
> _______________________________________________
> Q-e-developers mailing list
> Q-e-developers at qe-forge.org
> http://qe-forge.org/mailman/listinfo/q-e-developers