experchange > fortran

Marcin Modrzejewski (01-06-19, 07:28 PM)
Dear all,

I'm looking into the following program which includes allocatable components of a coindexed derived-type variable. There are two variants of the coarray assignment, denoted "case 1" and "case 2" (see the example below). Depending on the code variant and compiler, the program doesn't compile or stopswith a segmentation fault. Is any of the code variants standard-conforming?

program test
implicit none
type tx
integer, dimension(:), allocatable :: x
end type tx
type(tx), allocatable :: y[:]

allocate(y[*])
allocate(y%x(3))
y%x = this_image()
sync all
if (this_image() == 2) then
y[1] = y ! case 1
! y = y[1] ! case 2
end if
sync all
print *, this_image(), "y%x=", y%x
end program test

Case 1: y[1] = y
================
ifort 19.0.1.144-> compiles, but program gives a bad result:
1 y%x= 1 1 1
2 y%x= 2 2 2
3 y%x= 3 3 3
4 y%x= 4 4 4

gfortran 7.3.0, OpenCoarrays 2.0.0-rc1 -> doesn't compile:
Error: Coindexed variable must not have an allocatable ultimate component in assignment at (1))

Case 2: y = y[1]
================
ifort -> compiles, but program stops with a segmentation fault
gfortran -> compiles, but program stops with a segmentation fault

Regards,
Marcin
FortranFan (01-06-19, 07:42 PM)
On Sunday, January 6, 2019 at 12:28:14 PM UTC-5, Marcin Modrzejewski wrote:

> .. Is any of the code variants standard-conforming?


I don't think so: I think your instruction at line 10 needs to be as follows to prevent allocation-on-assignment of allocatable objects:
y%x(:) = this_image()

Also, I'm not completely up-to-speed on intrinsic assignments of derived types when coindexed objects are involved: my hunch is in the absence of defined assignments, you may need to do the same as above with the subsequent assignments:

program test
implicit none
type tx
integer, dimension(:), allocatable :: x
end type tx
type(tx), allocatable :: y[:]

allocate(y[*])
allocate(y%x(3))
y%x(:) = this_image()
sync all
if (this_image() == 2) then
y[1]%x(:) = y%x(:) ! case 1
! y%x(:) = y[1]%x(:) ! case 2
end if
sync all
print *, this_image(), "y%x=", y%x
end program test

Good luck,
Marcin Modrzejewski (01-06-19, 11:01 PM)
On Sunday, January 6, 2019 at 6:42:09 PM UTC+1, FortranFan wrote:
(...)
> I think your instruction at line 10 needs to be as follows to prevent allocation-on-assignment of allocatable objects:
> y%x(:) = this_image()


I don't understand why the assignment of a scalar (rhs) to an array (lhs) at line 10 would be problematic. First, according to the F2008 standard, therhs is treated as an array of the same shape as the lhs (N1830, 7.2.1.3 Interpretation of intrinsic assignments):

If expr is a scalar and the variable is an array, the expr is treated as ifit were an array of the same shape as the variable with every element of the array equal to the scalar value of expr.

I think that the above rule implies that there's no reallocation on assignment: the rhs and lhs have (formally) the same shape.

Second, even if there were reallocation on assignment, even hypothetically,would that be an issue? Note that it would be a local allocation, i.e., not done in a remote image's memory.

Still, there's apparently an issue with the assignments "y[1] = y" and "y= y[1]". Why that would be illegal?

Cheers,
Marcin
FortranFan (01-07-19, 05:14 AM)
On Sunday, January 6, 2019 at 4:01:43 PM UTC-5, Marcin Modrzejewski wrote:

> ..
> I don't understand why the assignment of a scalar (rhs) to an array (lhs)at line 10 would be problematic. ..
> .. Why that would be illegal?


Hopefully others more knowledgeable about the standard when it comes to coarrays will guide you better feedback.

I'm likely mistaken, but it appears to me the standard leans toward limiting the situations involving synchronization of coarrays (and this would be understandable). Since ALLOCATE involves synchronization, the onus placed on the coder (with statements that have 'shall' in them) appears to limit instructions involving reallocation as in, say, intrinsic assignment where the standard has a paragraph in section 10.2.1.2 toward Fortran 2018:

21 2 If the variable in an intrinsic assignment statement is a coindexed object,
...
23 the variable shall not have an allocatable ultimate component,
...

This is what I had in mind and which is why I had suggested the modified code with the section subscript which then removes the 'allocatable' attribute, thereby making the instructions clearer for the compiler (and possibly for the readers of the code, including a future you!). Btw, did the modification I suggested work for you with the 2 compilers you have mentioned in the original post?

You may also want to file support requests with the 2 compilers, particularly at Intel OSC and which may get you *better or correct* input on this matter sooner than these comments.
spectrum (01-07-19, 02:09 PM)
FWIW, the modified code (by FortranFan) is working as expected on my environment
(gfortran-8.2 + opencoarrays-2.3.1 + OpenMPI-3.1.3 on OSX10.11, installed via
Homebrew):

$ caf test.f90
$ cafrun -np 4 ./a.out

1 y%x= 2 2 2
2 y%x= 2 2 2
3 y%x= 3 3 3
4 y%x= 4 4 4

I guess "y[1] = y" may be problematic if y % x is allocated with
different sizes on different images (though I'm not sure if it is allowed by the standard...)
I guess explicitly specifying the range of elements to be copied may not have this
problem, like y[1] % x( 2:3 ) = y % x( 2:3 ) or y[1] % x = y % x (if size(x) is the same on different images).
Marcin Modrzejewski (01-07-19, 09:34 PM)
On Monday, January 7, 2019 at 4:14:32 AM UTC+1, FortranFan wrote:
> On Sunday, January 6, 2019 at 4:01:43 PM UTC-5, Marcin Modrzejewski wrote:
> Hopefully others more knowledgeable about the standard when it comes to coarrays will guide you better feedback.
> I'm likely mistaken, but it appears to me the standard leans toward limiting the situations involving synchronization of coarrays (and this would beunderstandable). Since ALLOCATE involves synchronization, the onus placedon the coder (with statements that have 'shall' in them) appears to limit instructions involving reallocation as in, say, intrinsic assignment where the standard has a paragraph in section 10.2.1.2 toward Fortran 2018:
> 21 2 If the variable in an intrinsic assignment statement is a coindexed object,
> ..
> 23 the variable shall not have an allocatable ultimate component,
> ..
> This is what I had in mind and which is why I had suggested the modified code with the section subscript which then removes the 'allocatable' attribute, thereby making the instructions clearer for the compiler (and possiblyfor the readers of the code, including a future you!). Btw, did the modification I suggested work for you with the 2 compilers you have mentioned inthe original post?
> You may also want to file support requests with the 2 compilers, particularly at Intel OSC and which may get you *better or correct* input on this matter sooner than these comments.


@FortranFan,

I've tried the code modifications which you suggested. Remarkably, the following variant, which looks perfectly ok, doesn't work with gfortran/OpenCoarrays (at least on my Ubuntu 18.04 setup):

program test
implicit none
type tx
integer, dimension(:), allocatable :: x
end type tx
type(tx), allocatable :: y[:]

allocate(y[*])
allocate(y%x(3))
y%x = this_image()
sync all
if (this_image() == 2) then
y%x(:) = y[1]%x(:)
end if
sync all
print *, this_image(), "y%x=", y%x
end program test

The program issues a warning message,

lib_caf_mpi::sendget_by_ref(): Warning ! sendget_by_ref() is mostly unfunctional due to a design error. Split up your statement with coarray refs on both sides of the assignment when the datatype transfered is non 4-byte-integer compatible.

and hangs up indefinitely.
Marcin Modrzejewski (01-07-19, 09:42 PM)
On Monday, January 7, 2019 at 8:34:12 PM UTC+1, Marcin Modrzejewski wrote:
[..]
> The program issues a warning message,
> lib_caf_mpi::sendget_by_ref(): Warning ! sendget_by_ref() is mostly unfunctional due to a design error. Split up your statement with coarray refs onboth sides of the assignment when the datatype transfered is non 4-byte-integer compatible.
> and hangs up indefinitely.


What's weird, the program compiled with gfortran/OpenCoarrays works ok whenthe assignment is done in the opposite direction, i.e.

program test
implicit none
type tx
integer, dimension(:), allocatable :: x
end type tx
type(tx), allocatable :: y[:]

allocate(y[*])
allocate(y%x(3))
y%x = this_image()
sync all
if (this_image() == 2) then
y[1]%x(:) = y%x(:)
end if
sync all
print *, this_image(), "y%x=", y%x
end program test
FortranFan (01-07-19, 10:52 PM)
On Monday, January 7, 2019 at 2:34:12 PM UTC-5, Marcin Modrzejewski wrote:

> ..
> I've tried the code modifications which you suggested. Remarkably, the following variant, which looks perfectly ok, doesn't work with gfortran/OpenCoarrays (at least on my Ubuntu 18.04 setup): ..


Bummer, your latest code looks alright, you may have noticed it works as you would expect with Intel Fortran 19.0.1 (I just tried).

Another visit to GCC Bugzilla site if you have the time and motivation :-(

Hope you will *continue* with your efforts and advance further in your field with *Fortran* notwithstanding all these compiler issues. All the best,
Michael Siehl (01-08-19, 12:15 AM)
Am Montag, 7. Januar 2019 20:34:12 UTC+1 schrieb Marcin Modrzejewski:
[..]
> The program issues a warning message,
> lib_caf_mpi::sendget_by_ref(): Warning ! sendget_by_ref() is mostly unfunctional due to a design error. Split up your statement with coarray refs onboth sides of the assignment when the datatype transfered is non 4-byte-integer compatible.
> and hangs up indefinitely.


I am able to compile and run that code successfully using OpenCoarrays 2.3.1, MPICH 3.2.1, and gfortran 9.0.0:

1 y%x= 1 1 1
2 y%x= 1 1 1
3 y%x= 3 3 3
4 y%x= 4 4 4

Regards
baf (01-08-19, 12:40 AM)
On 1/7/2019 11:34 AM, Marcin Modrzejewski wrote:
[..]
> The program issues a warning message,
> lib_caf_mpi::sendget_by_ref(): Warning ! sendget_by_ref() is mostly unfunctional due to a design error. Split up your statement with coarray refs on both sides of the assignment when the datatype transfered is non 4-byte-integer compatible.
> and hangs up indefinitely.

what version of gfortran? Likely pretty old if you have the default
version provided by Ubuntu.
Michael Siehl (01-08-19, 12:51 AM)
I can also confirm that OpenCoarrays does eventually compile and run my own simple test case here:

Remarkably, ifort and OpenCoarrays/gfortran do allow use of the intrinsics LBOUND and UBOUND for remote access:

IF (Coarray_Object[intImageNumber] % logAllocationStatus) THEN
intLowerBound = LBOUND (Coarray_Object[intImageNumber] % reaDataArray, 1)
intUpperBound = UBOUND (Coarray_Object[intImageNumber] % reaDataArray, 1)
ELSE
intLowerBound = 1
intUpperBound = 0
END IF

That code executes on image 1 with intImageNumber has value 2. The values received from LBOUND and UBOUND are those from the remote image 2.
Michael Siehl (01-08-19, 12:58 AM)
Am Montag, 7. Januar 2019 23:51:56 UTC+1 schrieb Michael Siehl:
> I can also confirm that OpenCoarrays does eventually compile and run my own simple test case here:
> Remarkably, ifort and OpenCoarrays/gfortran do allow use of the intrinsics LBOUND and UBOUND for remote access:
> IF (Coarray_Object[intImageNumber] % logAllocationStatus) THEN
> intLowerBound = LBOUND (Coarray_Object[intImageNumber] % reaDataArray, 1)
> intUpperBound = UBOUND (Coarray_Object[intImageNumber] % reaDataArray, 1)
> ELSE
> intLowerBound = 1
> intUpperBound = 0
> END IF
> That code executes on image 1 with intImageNumber has value 2. The values received from LBOUND and UBOUND are those from the remote image 2.


Isn't that Fortran specific? I mean that the bounds are part of the data? (It appears that way).

cheers
Michael Siehl (01-08-19, 04:00 AM)
In case someone is interested:

This could mark a breakthrough with OpenCoarrays. I am (or better said: I was) not a big fan of such non-symmetric coarrays, thus, I did no further testing lately using OpenCoarrays. The above here was my first successful test using current OpenCoarrays 2.3.1 (after several years of failing).

I did just some further testing and can also confirm that OpenCoarrays doesallow for non-symmetric coarrays as atomics and successful use with atomicsubroutines, which is an important requirement within my programming. (There appears to be a minor issue with the syntax yet, but standard conformingcoding did still work).

For the last several weeks I did develop a (poor, because of very slow runtime execution) strategy (within my programming) to circumvent the non-conforming runtime behavior (bug) using OpenCoarrays with allocatable coarrays at the team level (Fortran 2018 teams) : With the current runtime-behavior, the allocate statement of an allocatable coarray does (try to) synchronize with an(y) allocate statement on any image of the whole program but not within that team only.

But now, I think I can drop that strategy:

My further testing will be with non-symmetric coarrays at the team-level. Yet, the main advantage of a non-symmetric coarray could be it's allocate statement that does appear to not synchronize at all (if I am correct). From my testing so far, I can also confirm that the SYNC TEAM statement does seem to work properly with OpenCoarrays already.

The next few weeks and month will have to show, but I am somewhat confidentthat OpenCoarrays 2.3.1 could allow conforming Fortran 2018 coarray team programming/compiling at a very advanced level already.

Anyone, feel free to try coarray team programming at this early stage usingOpenCoarrays 2.3.1. (but be aware: there are quite a few issues to solve yet).

cheers
brooksj631 (01-14-19, 07:15 PM)
CONTACT US FOR Pain Pills,xanax ,Nembutal, Seconal ,Oxycotin, Dilaudid,Valium,Hydrocodone & Ritalin Online.
call or text +1(405)500-0724
website :
email me at cliffbudman237
Hello, we are suppliers of assorted pain killers and anxietay pain relief meds, and other research chemicals. Discount are also applicable for bulk buyers.The shipping is meticulously planned; packaging is done with professionalis.
We have the following meds below available in stock now for auction;
Pain/ Anxiety Pills
Seconal
Nembutal (Powder,Pills and Liquid form)
Oxycotin / Oxycodone 10,20 a,40 and 80 mg
Actavis Promethazine Codeine Purple Cough Syrup (16oz and 320z)
Hydrocodone 10500, 10325 ,7.5750 mg
Valium 10,15 and 20 mg
Xanax 1 and 2 mg
Dilaudid 2,4 and 8 mg
Ritalin 5,10, 20 mg
Percocet 7.5mg,5mg and 10mg
Opana 20mg and 40mg
Lorcet - (Hydrocodone Bitartrate/Acetaminophen) 10 mg/650 mg
Midazolam 3mg
Motrin 400mg and 600mg
Norco - ( Hydrocodone Bitartrate/Acetaminophen ) 5 mg/325 mg
Soma 350mg
Tramadol (Ultram) 50mg
Valium 2mg,5mg and 10mg
Valium Roche Brand 10mg
Voltaren 50mg and 100mg
Adderall,Anaprox,Ansaid,Acephen
Bupren , ex,Butrans
Percocet,Phrenilin,Percodan
Soma, , Subutex
Cataflam,Celebrex
Flexeril, Fentora ..,
Demerol,Daypro,Dilaudid
Endocet
Lorcet, L, ortab
Ibudone
Methadone,Morphine
Naprosyn , ,Norco
Oxycontin, Opana
Ritalin, Roxicodone®
Michael Siehl (01-18-19, 11:41 PM)
Am Dienstag, 8. Januar 2019 03:00:32 UTC+1 schrieb Michael Siehl:
> In case someone is interested:
> This could mark a breakthrough with OpenCoarrays. I am (or better said: Iwas) not a big fan of such non-symmetric coarrays, thus, I did no further testing lately using OpenCoarrays. The above here was my first successful test using current OpenCoarrays 2.3.1 (after several years of failing).
> I did just some further testing and can also confirm that OpenCoarrays does allow for non-symmetric coarrays as atomics and successful use with atomic subroutines, which is an important requirement within my programming. (There appears to be a minor issue with the syntax yet, but standard conforming coding did still work).
> For the last several weeks I did develop a (poor, because of very slow runtime execution) strategy (within my programming) to circumvent the non-conforming runtime behavior (bug) using OpenCoarrays with allocatable coarraysat the team level (Fortran 2018 teams) : With the current runtime-behavior, the allocatestatement of an allocatable coarray does (try to) synchronize with an(y) allocate statement on any image of the whole program but not within that team only.
> But now, I think I can drop that strategy:
> My further testing will be with non-symmetric coarrays at the team-level.Yet, the main advantage of a non-symmetric coarray could be it's allocate statement that does appear to not synchronize at all (if I am correct). From my testing so far, I can also confirm that the SYNC TEAM statement does seem to work properly with OpenCoarrays already.
> The next few weeks and month will have to show, but I am somewhat confident that OpenCoarrays 2.3.1 could allow conforming Fortran 2018 coarray teamprogramming/compiling at a very advanced level already.
> Anyone, feel free to try coarray team programming at this early stage using OpenCoarrays 2.3.1. (but be aware: there are quite a few issues to solveyet).
> cheers


After some further testing using such non-symmetric coarrays (a derived type coarray with an allocatable component) with a more sophisticated code, I think I will revert back to my original approach using standard (symmetric)coarrays (of derived type).
I got the codes compiled but run-time execution always failed at some point.. I can't even tell if there is still an issue with OpenCoarrays or if the code tries to access memory remotely (through such a non-symmetric coarray)that wasn't allocated previously. In principle, I would need to implement more sophisticated checking for this but then, the codes would get more andmore complicated. Without such checking, the codes are just to error prone: With non-symmetric coarrays the programmer has full responsibility to notaccess non-allocated memory through remote references. With standard (symmetric) coarrays, on the other hand, the runtime does allocate (and synchronize) on all images (of a team), which makes the programmers job much easierand the codes much less error-prone, I would say.

cheers
Similar Threads