https://www.jiscmail.ac.uk/cgi-bin/webadmin?RSS&L=COMP-FORTRAN-90&v=1.0COMP-FORTRAN-90 List
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=COMP-FORTRAN-90
COMP-FORTRAN-90 List Archives2015-03-18T01:09:26ZPowered by L-Soft's LISTSERV mailing list manager
http://www.lsoft.com/products/listserv-powered.asp
http://www.lsoft.com/images/listserv_small.gifRe: Finalization of arrays when type finalizer is recursive
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;c8c7fb3b.1503
<<<<br>"that is going to silently return the wrong answer if it gets called<br>recursively." But what can the silent wrong answer be in this case since the<br>context is finalization? That is, can it be anything besides a memory leak?<br>>>><br><br>The silent wrong answer could be anything, since there will be a single variable<br>shared between all the recursive instances, instead of one per instance. [...]
2015-03-18T09:09:19+09:00Malcolm Cohenhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;c8c7fb3b.1503Re: Finalization of arrays when type finalizer is recursive
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;216f92c5.1503
Malcolm,<br><br>Thanks much for your detailed comments. You state, "that is going to<br>silently return the wrong answer if it gets called recursively." But what<br>can the silent wrong answer be in this case since the context is<br>finalization? That is, can it be anything besides a memory leak?<br><br>Regards,<br><br>On Mon, Mar 16, 2015 at 8:04 PM, Malcolm Cohen <malcolm@nag-j.co.jp> wrote: [...]
2015-03-17T10:31:36-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;216f92c5.1503Re: Finalization of arrays when type finalizer is recursive
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;9562b81e.1503
Hi,<br><br><<<<br>"First, elemental implies pure -- elemental is all you need" - no, not with<br>Fortran 2008.<br>>>><br><br>As Neil commented, Fortran 2008 has not changed the meaning of the ELEMENTAL<br>keyword, so a Fortran 95/2003 program using ELEMENTAL has identical semantics,<br>i.e. in the absence of IMPURE, ELEMENTAL=>PURE.<br><br><<<<br>So how does NAg compiler in terms of -C=recursion (or -C=all)? Is that on by<br>default?<br>>>> [...]
2015-03-17T09:04:26+09:00Malcolm Cohenhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;9562b81e.1503Re: Finalization of arrays when type finalizer is recursive
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;61f8acc5.1503
Just a bit of background in the compiler conformance area.<br><br>Whilst the 'current' standard in force is the 2008 standard,<br><br>only one compiler supports this standard and only two<br><br>compilers fully support the 2003 standard.<br><br>Our compiler conformance table<br><br>http://www.fortranplus.co.uk/resources/fortran_2003_2008_compiler_support.pdf<br><br>has details.<br><br>this table appears in the ACM Fortran Forum<br><br>http://dl.acm.org/citation.cfm?id=J286<br><br>Ian Chivers<br><br>and<br><br>Jane Sleightholme<br><br>From: Fortran 90 List [mailto:COMP-FORTRAN-90@JISCMAIL.AC.UK] On Behalf Of Vipul Parekh<br>Sent: 16 March 2015 16:25<br>To: COMP-FORTRAN-90@JISCMAIL.AC.UK<br>Subject: Re: Finalization of arrays when type finalizer is recursive [...]
2015-03-16T17:09:09-00:00Ian Chivershttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;61f8acc5.1503Re: Finalization of arrays when type finalizer is recursive
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;4b36f965.1503
On Mon, Mar 16, 2015 at 10:25 AM, Vipul Parekh <parekhvs@gmail.com> wrote:<br><br>> "First, elemental implies pure -- elemental is all you need" - no, not<br>> with Fortran 2008.<br>><br><br>Fortran 2008 standard (draft): 12.8.1 #2: "An elemental subprogram is a<br>pure subprogram<br>unless it has the prefix-spec IMPURE."<br><br>So how does NAg compiler in terms of -C=recursion (or -C=all)? Is that on<br>> by default? And is there a way to turn it off? And when the check of<br>> "invalid recursion" (via -C=all or -C=recursion) is applied, is it checking<br>> against the current Fortran standard (which [...]
2015-03-16T11:05:13-06:00Neil Carlsonhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;4b36f965.1503Re: Finalization of arrays when type finalizer is recursive
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;f4c377a9.1503
"First, elemental implies pure -- elemental is all you need" - no, not with<br>Fortran 2008.<br><br>So how does NAg compiler in terms of -C=recursion (or -C=all)? Is that on<br>by default? And is there a way to turn it off? And when the check of<br>"invalid recursion" (via -C=all or -C=recursion) is applied, is it checking<br>against the current Fortran standard (which simply has an artificial<br>constraint) or a true systems problem where recursion can lead to stack<br>corruption, etc. If the former, then it is any good, of course it is going<br>to say the workaround is invalid [...]
2015-03-16T12:25:11-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;f4c377a9.1503Re: Finalization of arrays when type finalizer is recursive
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;facd5701.1503
<<<<br>in his example it is an allocatable array that is explicitly deallocated.<br>In my own testing the array is local to a subroutine called by main. If the<br>array type<br>has a final subroutine of a scalar argument, then it is not called when the<br>array<br>ceases to exist. One needs to have a final subroutine for a rank-1 array<br>argument,<br>rank-2 array, etc., or make it elemental. That's my understanding and my<br>observation<br>at least. Would you agree?<br>>>> [...]
2015-03-16T15:12:23+09:00Malcolm Cohenhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;facd5701.1503Re: Finalization of arrays when type finalizer is recursive
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;18019fe5.1503
Agreed, except in his example it is an allocatable array that is explicitly<br>deallocated.<br>In my own testing the array is local to a subroutine called by main. If<br>the array type<br>has a final subroutine of a scalar argument, then it is not called when the<br>array<br>ceases to exist. One needs to have a final subroutine for a rank-1 array<br>argument,<br>rank-2 array, etc., or make it elemental. That's my understanding and my<br>observation<br>at least. Would you agree? [...]
2015-03-15T19:55:42-06:00Neil Carlsonhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;18019fe5.1503Re: Finalization of arrays when type finalizer is recursive
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;fe8a951d.1503
Neil Carson writes:<br><<<<br>However if you modify your<br>main program to declare foo as an array -- even a size 1 array -- then it leaks<br>memory; the final subroutine is never called.<br>>>><br><br>That is probably because variables in a main program implicitly have the SAVE<br>attribute, and variables with the SAVE attribute are never finalised by<br>"going-out-of-scope". [...]
2015-03-16T10:43:17+09:00Malcolm Cohenhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;fe8a951d.1503Re: Finalization of arrays when type finalizer is recursive
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;967a1918.1503
Actually, your original program before your last changes suffers from<br>exactly<br>the same problem: an indirect recursive call into clean_note_t. In that<br>case<br>you can fix the error by declaring clean_node_t recursive, but then it can't<br>be elemental too, which is the issue I posed in my very first post.
2015-03-15T16:58:47-06:00Neil Carlsonhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;967a1918.1503Re: Finalization of arrays when type finalizer is recursive
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;ee186645.1503
On Sun, Mar 15, 2015 at 4:25 PM, Vipul Parekh <parekhvs@gmail.com> wrote:<br><br>> FWIW, if I change the finalizer attribute to "pure elemental" and apply<br>> pure to the recursive cleaner and comment out the write statement and run<br>> it with the code shown below using the latest Intel compiler, I can see in<br>> the debuggger the finalizer is indeed invoked and confirm there are no<br>> memory leaks. My hunch is there is a bug in NAg compiler.<br>> [...]
2015-03-15T16:45:33-06:00Neil Carlsonhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;ee186645.1503Re: Finalization of arrays when type finalizer is recursive
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;ceb007ee.1503
Thanks much for your testing.<br><br>FWIW, if I change the finalizer attribute to "pure elemental" and apply<br>pure to the recursive cleaner and comment out the write statement and run<br>it with the code shown below using the latest Intel compiler, I can see in<br>the debuggger the finalizer is indeed invoked and confirm there are no<br>memory leaks. My hunch is there is a bug in NAg compiler. [...]
2015-03-15T18:25:32-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;ceb007ee.1503Re: Finalization of arrays when type finalizer is recursive
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;9b2b14f2.1503
On Sat, Mar 14, 2015 at 6:20 PM, Vipul Parekh <parekhvs@gmail.com> wrote:<br><br>> [code snipped]<br>> Can you please check this code with NAg compiler and see if any errors get<br>> exposed that are not with the compilers I utilized.<br>><br><br>That works as intended with NAG; no memory leaks. However if you modify<br>your<br>main program to declare foo as an array -- even a size 1 array -- then it<br>leaks<br>memory; the final subroutine is never called.
2015-03-15T08:12:48-06:00Neil Carlsonhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;9b2b14f2.1503Re: Finalization of arrays when type finalizer is recursive
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;89ea27c3.1503
I think you need to check for associated status instead of allocated:<br><br>pure recursive subroutine aux (this)<br>type(list) :: this<br>if (associated(this%first)) deallocate(this%first) !.. associated<br>instead of allocated<br>end subroutine<br><br>Nonetheless, what I'd in mind is as shown below: it works fine gfortran 5.0<br>development trunk and Intel compiler - no memory leaks. Please note the<br>elemental and pure attributes in the finalization chain are commented out<br>simply to illustrate finalization execution; [...]
2015-03-14T20:20:23-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;89ea27c3.1503Re: Finalization of arrays when type finalizer is recursive
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;3d87786a.1503
On Fri, Mar 13, 2015 at 4:37 PM, Vipul Parekh <parekhvs@gmail.com> wrote:<br><br>> [...] One can also do a test where one temporarily turns off the<br>> elemental and pure attributes in the finalizer chain of procedures, add<br>> some print statements in them and run it with an ALLOCATE-DEALLOCATE step<br>> of the type.<br>> [...]
2015-03-14T08:20:49-06:00Neil Carlsonhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;3d87786a.1503Re: Finalization of arrays when type finalizer is recursive
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;1bad38f9.1503
A correction that you may have noticed: since the dummy argument of the<br>finalizer needs to be nonpolymorphic variable of the derived type being de<br>fined, it needs to invoke the other procedure directly:<br><br>elemental subroutine t_finalize(this)<br><br>type(t), intent(inout) :: this<br><br>call recursive_cleaner(this, ..) ! instead of call<br>this%recursive_cleaner(..)<br><br>end subroutine t_finalize<br><br>On Fri, Mar 13, 2015 at 1:42 PM, Neil Carlson <neil.n.carlson@gmail.com><br>wrote: [...]
2015-03-14T08:54:55-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;1bad38f9.1503Re: Finalization of arrays when type finalizer is recursive
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d4642a0d.1503
Glad if it was of some help.<br><br>Re: "With the Intel compiler it compiles and runs, but I have no way to<br>verify that the finalizer is actually being called; it doesn't yet support<br>the "impure elemental" feature of 2008, and has no equivalent of -mtrace<br>that I'm aware of.,"<br><br>if you create appropriate unit tests that invoke the finalizer, then you<br>can walk through all the finalization steps in a debug session with the<br>Intel compiler. One can also do a test where one temporarily turns off the<br>elemental and pure attributes in the finalizer chain of procedures, add<br> [...]
2015-03-13T18:37:27-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d4642a0d.1503Re: Finalization of arrays when type finalizer is recursive
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;7efa4b9b.1503
t_finalize needs to be elemental. However you were on the right track.<br>Make recursive_cleaner "pure recursive" and this appears to work with<br>the NAG compiler. There I can verify it with the -mtrace option or by<br>putting a print statement into t_finalize, which requires making it<br>"impure elemental". With the Intel compiler it compiles and runs, but<br>I have no way to verify that the finalizer is actually being called; it<br>doesn't yet support the "impure elemental" feature of 2008, and has<br>no equivalent of -mtrace that I'm aware of. [...]
2015-03-13T11:42:04-06:00Neil Carlsonhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;7efa4b9b.1503Re: Finalization of arrays when type finalizer is recursive
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;390a3af5.1503
Can you not simply have a type-bound procedure which is recursive and which<br>does the actions you need and then have the finalizer invoke this?<br><br>type t<br>..<br>contains<br>procedure .. :: recursive_cleaner<br>final : t_finalize<br>end type<br><br>contains<br><br>subroutine t_finalize(this)<br><br>type(t), intent(inout) :: this<br><br>call this%recursive_cleaner(..)<br><br>end subroutine t_finalize<br><br>recursive subroutine recursive_cleaner(this, ..)<br>class(t), intent(inout) :: this<br>..<br><br>end subroutine recursive_cleaner<br><br>end module ,,<br><br>Regards,<br>Vipul Parekh<br><br>On Fri, Mar 13, 2015 at 12:07 PM, Neil Carlson <neil.n.carlson@gmail.com><br>wrote: [...]
2015-03-13T13:06:50-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;390a3af5.1503Finalization of arrays when type finalizer is recursive
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;14f3cfe8.1503
I have a hierarchical data structure implemented as a type -- think linked<br>list if you'd like -- that has a recursive final subroutine. For reasons I<br>won't go into, a non-recursive final subroutine would be very unwieldy.<br>Things work great for scalars of this type, but arrays of this type are not<br>being finalized, presumably because the final subroutine is not elemental.<br>Unfortunately a subroutine is not allowed to be both elemental and<br>recursive. Any thoughts for a workaround?
2015-03-13T10:07:51-06:00Neil Carlsonhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;14f3cfe8.1503Re: fortran sum intrinsic question
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;f080bd8a.1501
On 1/21/2015 2:10 PM, Tobias Burnus wrote:<br>> Ian D Chivers wrote:<br>>> Jane and I are writing some new examples<br>>> for the next edition of the book<br>>> and have been benchmarking an openmp<br>>> summation example and comparing the timing<br>>> against the sum intrinsic.<br>>><br>>> are we likely to see parallel<br>>> versions of any of the intrinsics?<br>><br>> For coarrays, there is CO_SUM. Otherwise, there the big problem of<br>> when it is profitable to use thread parallelization and when the<br>> overhead is too big. (Besides the issue how many threads the [...]
2015-01-21T14:20:46-05:00Tim Princehttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;f080bd8a.1501Re: fortran sum intrinsic question
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;be85dc34.1501
Ian D Chivers wrote:<br>> Jane and I are writing some new examples<br>> for the next edition of the book<br>> and have been benchmarking an openmp<br>> summation example and comparing the timing<br>> against the sum intrinsic.<br>><br>> are we likely to see parallel<br>> versions of any of the intrinsics?<br><br>For coarrays, there is CO_SUM. Otherwise, there the big problem of when<br>it is profitable to use thread parallelization and when the overhead is<br>too big. (Besides the issue how many threads the user wants to have.) –<br>That's the general problem and the reason [...]
2015-01-21T20:10:20+01:00Tobias Burnushttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;be85dc34.1501Re: fortran sum intrinsic question
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;2ba3ba9a.1501
On 1/21/2015 9:05 AM, Bill Long wrote:<br>> On Jan 21, 2015, at 1:15 AM, Ian D Chivers <ian.chivers@CHIVERSANDBRYAN.CO.UK> wrote:<br>><br>>> Jane and I are writing some new examples<br>>> for the next edition of the book<br>>> and have been benchmarking an openmp<br>>> summation example and comparing the timing<br>>> against the sum intrinsic.<br>>><br>>> are we likely to see parallel<br>>> versions of any of the intrinsics?<br>> It depends on the implementation.<br>><br>> But, in general, routines that are BLAS 1 replacements will not be threaded (though very likely vectorized). Examples include SUM [...]
2015-01-21T09:52:39-05:00Tim Princehttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;2ba3ba9a.1501Re: fortran sum intrinsic question
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;681ee7b3.1501
On Jan 21, 2015, at 1:15 AM, Ian D Chivers <ian.chivers@CHIVERSANDBRYAN.CO.UK> wrote:<br><br>> Jane and I are writing some new examples<br>> for the next edition of the book<br>> and have been benchmarking an openmp<br>> summation example and comparing the timing<br>> against the sum intrinsic.<br>><br>> are we likely to see parallel<br>> versions of any of the intrinsics? [...]
2015-01-21T14:05:09+00:00Bill Longhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;681ee7b3.1501Re: fortran sum intrinsic question
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;50d54dc6.1501
On 1/21/2015 2:15 AM, Ian D Chivers wrote:<br>> Jane and I are writing some new examples<br>> for the next edition of the book<br>> and have been benchmarking an openmp<br>> summation example and comparing the timing<br>> against the sum intrinsic.<br>><br>> are we likely to see parallel<br>> versions of any of the intrinsics?<br>><br>> Ian Chivers<br>> Jane Sleightholme<br>When you say parallel, I assume you mean threading, as opposed to omp<br>simd reduction, which ought to be close to the sum intrinsic with<br>auto-vectorization. You would not want to give up the [...]
2015-01-21T08:48:46-05:00Tim Princehttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;50d54dc6.1501fortran sum intrinsic question
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d5f45e39.1501
Jane and I are writing some new examples<br>for the next edition of the book<br>and have been benchmarking an openmp<br>summation example and comparing the timing<br>against the sum intrinsic.<br><br>are we likely to see parallel<br>versions of any of the intrinsics?<br><br>Ian Chivers<br>Jane Sleightholme
2015-01-21T07:15:59-00:00Ian D Chivershttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d5f45e39.1501Re: TS18508 collectives: synchronisation and coarray vs noncoarray variables
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;9b920422.1501
On Jan 15, 2015, at 4:50 AM, Anton Shterenlikht <mexas@BRIS.AC.UK> wrote:<br><br>> It is not clear to me from TS18508<br>> whether synchronisation is required<br>> before and after the invocation<br>> of a collective subroutine.<br><br>Generally not.<br><br>> Note 7.4 mentions a "partial synchronisation<br>> of invocations of a collective subroutine".<br>> But I'm not sure if this answers my question. [...]
2015-01-15T22:02:26+00:00Bill Longhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;9b920422.1501TS18508 collectives: synchronisation and coarray vs noncoarray variables
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;b96d61ab.1501
It is not clear to me from TS18508<br>whether synchronisation is required<br>before and after the invocation<br>of a collective subroutine.<br>Note 7.4 mentions a "partial synchronisation<br>of invocations of a collective subroutine".<br>But I'm not sure if this answers my question.<br><br>Examples in A.3.1 are also confusing.<br><br>In the first example, why x and y are defined<br>as coarray variables? This fact seems to be<br>completely unused. [...]
2015-01-15T02:50:38-08:00Anton Shterenlikhthttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;b96d61ab.1501parallel coarray IO via Cray extension assign -m on: performance data
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d07c03c1.1501
A long mail for discussion.<br>Please advise if another mailing list is more appropriate.<br><br>On Archer I'm trying to use Cray extension "assign -m on"<br>to write coarray data in parallel to a shared direct access file.<br>There's only a single non-standard subroutine:<br><br>call asnfile( trim(fname), '-m on -F system', errstat )<br><br>which sets the assign environment for file specified<br>by the character variable "fname". The key flag is<br>"-m on", which allows the same file to be connected to multiple<br>images [1]. "-F system" specifies "No library buffering". [...]
2015-01-10T15:42:15-08:00Anton Shterenlikhthttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d07c03c1.1501Re: vacancies at Nag in the USA
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;18e226dc.1501
Thanks Phillip, I will.<br><br>-----Original Message-----<br>From: Fortran 90 List [mailto:COMP-FORTRAN-90@JISCMAIL.AC.UK] On Behalf Of<br>Phillip Helbig<br>Sent: 07 January 2015 22:23<br>To: COMP-FORTRAN-90@JISCMAIL.AC.UK<br>Subject: Re: vacancies at Nag in the USA<br><br>> I've just been contacted by Nag. They are increasing their technical<br>> support staff in the USA.<br>><br>> Here is an extract from the mail I received.<br>><br>><br>> If you know anyone who may be interested Could you please pass the<br>> details on. [...]
2015-01-08T10:12:15-00:00Ian Chivershttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;18e226dc.1501Re: vacancies at Nag in the USA
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;645c113.1501
> I've just been contacted by Nag. They are increasing<br>> their technical support staff in the USA.<br>><br>> Here is an extract from the mail I received.<br>><br>><br>> If you know anyone who may be interested<br>> Could you please pass the details on.<br><br>Perhaps you should post it to comp.lang.fortran?
2015-01-07T23:23:19+01:00Phillip Helbighttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;645c113.1501vacancies at Nag in the USA
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;fa6177cf.1501
I've just been contacted by Nag. They are increasing<br><br>their technical support staff in the USA.<br><br>Here is an extract from the mail I received.<br><br>If you know anyone who may be interested<br><br>Could you please pass the details on.<br><br>Maybe a happy new year for a couple of people in the US!<br><br>Cheers<br><br>Ian Chivers<br><br>About NAG [...]
2015-01-07T15:50:29-00:00Ian Chivershttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;fa6177cf.1501