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

[Paolo Giannozzi]

I tried omp_set_nested, but it doesn't seem to work (or more likely, I do
not know how to make it work). So we have to keep a thread-safe version of
cft_1z without internal OpenMP parallelization. I had hoped to merge FFTs
used by esm.f90 with the general FFT, but it seems preferrable to postpone
any action and to wait for further develoments in FFTs+OpenMP.

Unless other problems emerge, I am going to commit the attached version,
which should solve compilation problems but not introduce OpenMP problems

Paolo

On Mon, Nov 2, 2015 at 9:36 AM, 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
>
>


-- 
Paolo Giannozzi, Dept. Chemistry&Physics&Environment,
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20151102/83d46cf2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: esm.f90
Type: text/x-lisp
Size: 201011 bytes
Desc: not available
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20151102/83d46cf2/attachment.bin>