[J3] work on F202X at #217?

[Clune, Thomas L. (GSFC-6101)]

Hi Vipul,

A full use case would be more writing than I have time for at the moment.   But a use case for coarray teams would be something like:

I have a model that is couples two semi-independent subcomponents.    Say a climate model with atmosphere and ocean components to be concrete.    Each of those components can be run as a model on their own.    When coupled they can run mostly in parallel on separate sets of images.       At the very least some standard mechanism is needed to “notify" the components as to which subset of the images they are running on.     But more fundamentally,  each component should not be required to participate in coarray allocations/deallocation performed by the the other.   F2008 coarrays requires _all_ images to participate in all coarray allocations.      If the software for the atmospheric component evolves and adds an additional coarray, then the ocean component will also need to change to have a point where it can participate in the associated allocation.   Further, it probably has to declare a variable that is never used in the ocean at all.      While this can be made to work it violates separation of responsibilities that is very important for large complex systems.

Notice that the use case does not advocate for any particular solution.   It merely attempts to provide a plausible and motivating situation that is awkward/difficult to handle in the existing standard.   Ideally the use case resonates with similar issues faced by others on the committee.   If something is awkward/difficult for me, but it is also very peculiar to my source code, then a new feature is probably not warranted.

Hope this helps,



Cheers,

- Tom



> On Jul 25, 2018, at 5:57 PM, Vipul Parekh via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> Building upon Damian's questions, I'll suggest using a couple of new
> feature sections in Fortran 2018 themselves as basis for the examples.
> Meaning with Fortran 2008 as reference, imagine a couple of features
> to be proposed for the next standard revision i.e., Fortran 2018.
> Take one of the bigger feature introductions with "Additional parallel
> features in Fortran" and one or more of the smaller items in "Removal
> of deficiencies and discrepancies".  What would an "ideal paper"
> submission with *use cases" and "formal requirements"  look like,
> considering many on this distribution list should have benefit of
> 20/20 hindsight as well as considerable supporting information of all
> the work that led to these features getting added to Fortran 2018?
> 
> Thanks,
> Vipul Parekh
> 
> On Wed, Jul 25, 2018 at 1:52 PM Damian Rouson via J3
> <j3 at mailman.j3-fortran.org> wrote:
>> 
>> 
>> 
>> On Wed, Jul 25, 2018 at 5:57 AM, Malcolm Cohen via J3 <j3 at mailman.j3-fortran.org> wrote:
>>> 
>>> 
>>> 
>>> 2. formal requirements
>> 
>> 
>> Is there an example we can review to see what formal requirements look like?
>> 
>>> 
>>> 3. formal specifications
>> 
>> 
>> Same question as above. The first thing that came to my mind is EBNF, but that's used to describe syntax so I'm wondering if a formal spec is something else.
>> 
>> Damian