Possible funding of gfortran work

Possible funding of gfortran work

[Jerry DeLisle]

Hi all,

I found this message in my spam folder tonight.

Please look.  I also sent a note to Damian on this.

Maybe we can get someone to push forward on te native coarrays work?

Other thoughts?

Jerry

Re: Possible funding of gfortran work

[Bernhard Reutner-Fischer]

On 26 May 2023 06:34:52 CEST, Jerry DeLisle via Fortran <fortran@gcc.gnu.org> wrote:

>Maybe we can get someone to push forward on te native coarrays work?

It would be nice if someone could streamline the locking therein, as said.

Re: Possible funding of gfortran work

[Jerry D]

Sorry about my messages getting chopped.

On 5/25/23 9:34 PM, Jerry DeLisle via Fortran wrote:
> Hi all,
> 
> I found this message in my spam folder tonight.
> 
> Please look.  I also sent a note to Damian on this.
> 
> Maybe we can get someone to push forward on te native coarrays work?
> 
> Other thoughts?
> 
> Jerry
> 
  [awvwgk] 	awvwgk Regular
May 16

Hi Jerry,

we are currently securing funding for the Fortran community from the 
German government, see this thread:

     Application to the Sovereign Tech Fund Projects

     We recently had a meeting in Berlin with the Sovereign Tech Fund 
(STF) to evaluate the pilot round of their open source funding program 
which our community participated in. A big thanks to the people in who 
worked on the projects in our community. Now with the pilot round coming 
to an end soon, we have the chance to apply for further funding with the 
STF. Let’s have a look through our community and identity the projects 
with the largest impact on Fortran. A couple of suggestions to get the …

I would like to discuss with the GFortran developer community whether 
there is interest to setup a joint project to pay somebody to work on 
GFortran full time. We have funding available for 18 months with 600k 
EUR starting mid of June (please do not share this numbers publicly 
yet), but we can also ask the fund for more money if needed. What do you 
think? Is it worth to bring this up on the GFortran mailing list or 
mattermost server?

Best,
Sebastian

Visit Message or reply to this email to respond to awvwgk.

Re: Possible funding of gfortran work

[Thomas Koenig]

On 26.05.23 23:22, Jerry D via Fortran wrote:
> Sorry about my messages getting chopped.
> 
> On 5/25/23 9:34 PM, Jerry DeLisle via Fortran wrote:
>> Hi all,
>>
>> I found this message in my spam folder tonight.
>>
>> Please look.  I also sent a note to Damian on this.
>>
>> Maybe we can get someone to push forward on te native coarrays work?


I think the native coarrays are a good field. General bug fixing would
also be a good idea.

[quoting for the mail]

> I would like to discuss with the GFortran developer community whether 
> there is interest to setup a joint project to pay somebody to work on 
> GFortran full time. We have funding available for 18 months with 600k 
> EUR starting mid of June (please do not share this numbers publicly 
> yet), but we can also ask the fund for more money if needed. What do you 
> think? Is it worth to bring this up on the GFortran mailing list or 
> mattermost server?

It is really good so finally see a source of gfortran funding.

For hiring somebody full-time for a year, I am not sure who would be
available full-time, I think most people who have experience working
on gfortran have other commitments.  We would have to see if somebody
has the free time.

What would be great would be a possibility for people to work on
an hourly basis on certain, well-defined projects.  This is probably
something that contributors could fit in much better, and would provide
an additional incentive to take up gfortran work again :-)

Do you know if this is, in fact, a possibility?

Best regards

	Thomas

Re: Possible funding of gfortran work

[Andre Vehreschild]

Hi Thomas,

working full-time on a gfortran engagement would be possible for me. Given that
my company is Germany based and we have some capacity, that would be feasible
for us. We also have some knowledge about how to invoice authorities, which can
be a bit difficult sometimes. 

So I regard coarray work as a good starting point. I am also in contact with
Damian about some of his ideas. What else could we tackle?

Regards,
	Andre

On Sat, 27 May 2023 10:08:56 +0200
Thomas Koenig via Fortran <fortran@gcc.gnu.org> wrote:

> On 26.05.23 23:22, Jerry D via Fortran wrote:
> > Sorry about my messages getting chopped.
> > 
> > On 5/25/23 9:34 PM, Jerry DeLisle via Fortran wrote:  
> >> Hi all,
> >>
> >> I found this message in my spam folder tonight.
> >>
> >> Please look.  I also sent a note to Damian on this.
> >>
> >> Maybe we can get someone to push forward on te native coarrays work?  
> 
> 
> I think the native coarrays are a good field. General bug fixing would
> also be a good idea.
> 
> [quoting for the mail]
> 
> > I would like to discuss with the GFortran developer community whether 
> > there is interest to setup a joint project to pay somebody to work on 
> > GFortran full time. We have funding available for 18 months with 600k 
> > EUR starting mid of June (please do not share this numbers publicly 
> > yet), but we can also ask the fund for more money if needed. What do you 
> > think? Is it worth to bring this up on the GFortran mailing list or 
> > mattermost server?  
> 
> It is really good so finally see a source of gfortran funding.
> 
> For hiring somebody full-time for a year, I am not sure who would be
> available full-time, I think most people who have experience working
> on gfortran have other commitments.  We would have to see if somebody
> has the free time.
> 
> What would be great would be a possibility for people to work on
> an hourly basis on certain, well-defined projects.  This is probably
> something that contributors could fit in much better, and would provide
> an additional incentive to take up gfortran work again :-)
> 
> Do you know if this is, in fact, a possibility?
> 
> Best regards
> 
> 	Thomas
> 
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

Re: Possible funding of gfortran work

[Paul Richard Thomas]

[-- Attachment #1: Type: text/plain, Size: 4008 bytes --]

Hi Andre,

It's good to hear from you.

I would suggest the following:
(i) Complete F2003 compliance - Now that finalization is within a whisker
of compliance, this mostly leaves putting PDTs right. The framework is all
there, it just needs revamping. I can provide guidance or a statement of
work here. Associate still has some problems that I am working through but
I expect that there will be one or two of the more difficult ones left (eg.
Derived type, sibling function selectors that have not yet been parsed).
(ii) Complete F2008/F2018 compliance - we have owed Ian Chivers and Jane
Sleightholme this information for quite a while. Perhaps we should divide
the forms between us and attempt to fill them out? Or better, perhaps, this
could be the first stage of the work. I am sure that we will find lots of
this like, for example, partial coverage of do concurrent.
(iii) Finishing Nicolas's work on native (did we agree not to call it
that?) co-arrays would also be excellent.
(iv) Finally, a thorough and systematic attack on the PRs would be great,
starting with the meta-bugs.

However, an agreement, as Vladimir Illyich put it, an "What is to be done"
is an important first step.

I can only repeat Thomas's questions about whether or not your company
could provide the administrative framework and, perhaps, some project
management?

Could Sebastian please provide us with information on what is required for
the grant application?

Finally,

Regards

Paul



On Sat, 27 May 2023 at 12:24, Andre Vehreschild via Fortran <
fortran@gcc.gnu.org> wrote:

> Hi Thomas,
>
> working full-time on a gfortran engagement would be possible for me. Given
> that
> my company is Germany based and we have some capacity, that would be
> feasible
> for us. We also have some knowledge about how to invoice authorities,
> which can
> be a bit difficult sometimes.
>
> So I regard coarray work as a good starting point. I am also in contact
> with
> Damian about some of his ideas. What else could we tackle?
>
> Regards,
>         Andre
>
> On Sat, 27 May 2023 10:08:56 +0200
> Thomas Koenig via Fortran <fortran@gcc.gnu.org> wrote:
>
> > On 26.05.23 23:22, Jerry D via Fortran wrote:
> > > Sorry about my messages getting chopped.
> > >
> > > On 5/25/23 9:34 PM, Jerry DeLisle via Fortran wrote:
> > >> Hi all,
> > >>
> > >> I found this message in my spam folder tonight.
> > >>
> > >> Please look.  I also sent a note to Damian on this.
> > >>
> > >> Maybe we can get someone to push forward on te native coarrays work?
> >
> >
> > I think the native coarrays are a good field. General bug fixing would
> > also be a good idea.
> >
> > [quoting for the mail]
> >
> > > I would like to discuss with the GFortran developer community whether
> > > there is interest to setup a joint project to pay somebody to work on
> > > GFortran full time. We have funding available for 18 months with 600k
> > > EUR starting mid of June (please do not share this numbers publicly
> > > yet), but we can also ask the fund for more money if needed. What do
> you
> > > think? Is it worth to bring this up on the GFortran mailing list or
> > > mattermost server?
> >
> > It is really good so finally see a source of gfortran funding.
> >
> > For hiring somebody full-time for a year, I am not sure who would be
> > available full-time, I think most people who have experience working
> > on gfortran have other commitments.  We would have to see if somebody
> > has the free time.
> >
> > What would be great would be a possibility for people to work on
> > an hourly basis on certain, well-defined projects.  This is probably
> > something that contributors could fit in much better, and would provide
> > an additional incentive to take up gfortran work again :-)
> >
> > Do you know if this is, in fact, a possibility?
> >
> > Best regards
> >
> >       Thomas
> >
> >
>
>
> --
> Andre Vehreschild * Email: vehre ad gmx dot de
>


-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein

Re: Possible funding of gfortran work

[Nicolas König]

Hi everyone,

I think I can offer to pick up the work again. There were some strange
details about pointers and coarrays which had me thinking that the
approach taken for the native coarrays was doomed to failure (which is why
I didn't continue the work), but I now think that the Fortran standard
took these limitations into account and made, albeit in a somewhat cursed
way, the problematic programmes illegal. I also think I can do it in a
timeframe so it could be merged as an experimental feature for gcc 14.

Regarding funding: I will not be able to meaningfully spend 600 K :)
so maybe a division of work could be done? Andre's company does general
Fortran conformance and bug fixing, and they contract with me for the
native coarrays?

Best regards

   Nicolas


On 27/05/2023 18:19, Paul Richard Thomas via Fortran wrote:
> 
> Hi Andre,
> 
> It's good to hear from you.
> 
> I would suggest the following:
> (i) Complete F2003 compliance - Now that finalization is within a whisker
> of compliance, this mostly leaves putting PDTs right. The framework is all
> there, it just needs revamping. I can provide guidance or a statement of
> work here. Associate still has some problems that I am working through but
> I expect that there will be one or two of the more difficult ones left (eg.
> Derived type, sibling function selectors that have not yet been parsed).
> (ii) Complete F2008/F2018 compliance - we have owed Ian Chivers and Jane
> Sleightholme this information for quite a while. Perhaps we should divide
> the forms between us and attempt to fill them out? Or better, perhaps, this
> could be the first stage of the work. I am sure that we will find lots of
> this like, for example, partial coverage of do concurrent.
> (iii) Finishing Nicolas's work on native (did we agree not to call it
> that?) co-arrays would also be excellent.
> (iv) Finally, a thorough and systematic attack on the PRs would be great,
> starting with the meta-bugs.
> 
> However, an agreement, as Vladimir Illyich put it, an "What is to be done"
> is an important first step.
> 
> I can only repeat Thomas's questions about whether or not your company
> could provide the administrative framework and, perhaps, some project
> management?
> 
> Could Sebastian please provide us with information on what is required for
> the grant application?
> 
> Finally,
> 
> Regards
> 
> Paul
> 
> 
> 
> On Sat, 27 May 2023 at 12:24, Andre Vehreschild via Fortran <
> fortran@gcc.gnu.org> wrote:
> 
>> Hi Thomas,
>>
>> working full-time on a gfortran engagement would be possible for me. Given
>> that
>> my company is Germany based and we have some capacity, that would be
>> feasible
>> for us. We also have some knowledge about how to invoice authorities,
>> which can
>> be a bit difficult sometimes.
>>
>> So I regard coarray work as a good starting point. I am also in contact
>> with
>> Damian about some of his ideas. What else could we tackle?
>>
>> Regards,
>>          Andre
>>
>> On Sat, 27 May 2023 10:08:56 +0200
>> Thomas Koenig via Fortran <fortran@gcc.gnu.org> wrote:
>>
>>> On 26.05.23 23:22, Jerry D via Fortran wrote:
>>>> Sorry about my messages getting chopped.
>>>>
>>>> On 5/25/23 9:34 PM, Jerry DeLisle via Fortran wrote:
>>>>> Hi all,
>>>>>
>>>>> I found this message in my spam folder tonight.
>>>>>
>>>>> Please look.  I also sent a note to Damian on this.
>>>>>
>>>>> Maybe we can get someone to push forward on te native coarrays work?
>>>
>>>
>>> I think the native coarrays are a good field. General bug fixing would
>>> also be a good idea.
>>>
>>> [quoting for the mail]
>>>
>>>> I would like to discuss with the GFortran developer community whether
>>>> there is interest to setup a joint project to pay somebody to work on
>>>> GFortran full time. We have funding available for 18 months with 600k
>>>> EUR starting mid of June (please do not share this numbers publicly
>>>> yet), but we can also ask the fund for more money if needed. What do
>> you
>>>> think? Is it worth to bring this up on the GFortran mailing list or
>>>> mattermost server?
>>>
>>> It is really good so finally see a source of gfortran funding.
>>>
>>> For hiring somebody full-time for a year, I am not sure who would be
>>> available full-time, I think most people who have experience working
>>> on gfortran have other commitments.  We would have to see if somebody
>>> has the free time.
>>>
>>> What would be great would be a possibility for people to work on
>>> an hourly basis on certain, well-defined projects.  This is probably
>>> something that contributors could fit in much better, and would provide
>>> an additional incentive to take up gfortran work again :-)
>>>
>>> Do you know if this is, in fact, a possibility?
>>>
>>> Best regards
>>>
>>>        Thomas
>>>
>>>
>>
>>
>> --
>> Andre Vehreschild * Email: vehre ad gmx dot de
>>
> 
> 

Re: Possible funding of gfortran work

[Thomas Koenig]

Hi everybody,

there is also another aspect.  Could this Sovereign Tech Fund
also include travel allowances to go to a GNU Cauldron or
a WG5 meeting?

This could be quite interesting, I think.  What is the largest
number of gfortran contributers who ever met in one place?
Manchester, a few years ago, where it was Toon, Paul, Nicolas
and myself?

Best regards

	Thomas

Re: Possible funding of gfortran work

[Mikael Morin]

Hello,

I would like to apply for 60% of my work time if there is funding for it.

These are the projects that I would like to push (in no particular order):
  - Simplify scalarizer API and usage,
  - Create internal APIs (basically split gfortran.h and/or trans.h to 
different pieces) and add unit testing for them,
  - Move code from class.cc to a trans-class.cc and get rid of the class 
artifacts around the class descriptor and vtable in the whole frontend.
  - Defer all work done at parsing time to resolution time, so that the 
parser's job reduces to just recognizing and recording statements,
  - Avoid simplifying intrinsics before checking they are valid,
  - Improve module loading (there is PR98426, possibly a few others),
  - Array descriptor reform (does it still apply?).

The above are, I think, long and/or difficult, and a bit unrewarding as 
they have virtually no user-visible impact, and it's unlikely to get 
funding for them.  But maybe we could apply for a package project 
including user-visible changes and less visible ones.

The projects proposed by Paul all seem worth pursuing.  If there is only 
one, my vote goes for fixing the PDTs.

Cheers.
Mikael

Re: Possible funding of gfortran work

[Jerry D]

On 5/28/23 12:25 PM, Mikael Morin wrote:
> Hello,
> 
> I would like to apply for 60% of my work time if there is funding for it.
> 
> These are the projects that I would like to push (in no particular order):
>   - Simplify scalarizer API and usage,
>   - Create internal APIs (basically split gfortran.h and/or trans.h to 
> different pieces) and add unit testing for them,
>   - Move code from class.cc to a trans-class.cc and get rid of the class 
> artifacts around the class descriptor and vtable in the whole frontend.
>   - Defer all work done at parsing time to resolution time, so that the 
> parser's job reduces to just recognizing and recording statements,
>   - Avoid simplifying intrinsics before checking they are valid,
>   - Improve module loading (there is PR98426, possibly a few others),
>   - Array descriptor reform (does it still apply?).
> 
> The above are, I think, long and/or difficult, and a bit unrewarding as 
> they have virtually no user-visible impact, and it's unlikely to get 
> funding for them.  But maybe we could apply for a package project 
> including user-visible changes and less visible ones.
> 
> The projects proposed by Paul all seem worth pursuing.  If there is only 
> one, my vote goes for fixing the PDTs.
> 
> Cheers.
> Mikael

The original person who contacted me at FortranDiscourse already 
submitted a proposal for something to do with Fortran-Lang and is 
offering to assist with a gfortran proposal. I asked for a direct email 
address so I could relay this to you if you do not have it.  I also gave 
saveral of your emails to him asking to contact you directly.

Regards,

Jerry

Re: Possible funding of gfortran work

[Andre Vehreschild]

Hi all,

thank you for all your input. I have read the funding requirements and checked
out the application form. We have to agree on a project goal and describe why
it is critical to fund this project.

Let me try a first shot on this:

- Title:

GFortran-Improvement

- Abstract:

Enable the free gfortran compiler to support contemporary language paradigms.

- Dependencies (on the project as well as projects that depend on the
  technology)

Does any one have a convincing project that uses contemporary Fortran? 

Project goal (max 900 words!):

* Complete language intrinsic parallel programming paradigm coarrays. This
  includes completing native coarray support (thread based). As well as
  refactoring of the library based  coarray approach to support coarrays in
  modules. I.e. research on how to support the use of coarrays in modules that
  are not aware of coarrays (not compiled with its support enabled).

* Complete standard compliance from Fortran 2003 onwards. Esp. fixing
  finalization of partially derived types (PDTs) and issues in the associate
  command.

* Ensure maintainability of gfortran by cleaning up/refactoring APIs including
  the scalarizer. Improve the single responsibility pattern's (SRP) use by,
  e.g., ensuring the parser does no longer parts of the resolve stage. The goal
  is not only to separate responsibilities but also to get clearer error
  messages and with that improve user-friendliness.

Why is it critical to fund this project (300 words max)?

Improving the freely available gfortran compiler to support state of the art
parallelism and language paradigms as well as removing bugs and ensuring
standard compliance will allow existing codes to be compiled more reliably.
Furthermore is the lack of support for the newer language paradigms preventing
the use of Fortran in current projects. Developing in contemporary Fortran needs
commercial compilers (that support these paradigms already), which leads to
dependencies on those.

----

This is what I propose for a start. I welcome everyone to participate and make
the goal or the reasoning more elaborate. We may propose the funding request in
English or in German. When no one participates, I am tempted to propose it in
German, as that being my first language, I feel more confident in it.

The company Badger Systems GmbH, Cologne, DE, I am working for will support in
project and bureaucratic management and is willing to act as the proposer of
this funding request. We of course will be profiting from this.

Any input is welcome. Feel free to ask, comment, agree, disagree (only when you
propose something better) or just acknowledge.

Regards,
	Andre

On Sun, 28 May 2023 13:53:04 -0700
Jerry D <jvdelisle2@gmail.com> wrote:

> On 5/28/23 12:25 PM, Mikael Morin wrote:
> > Hello,
> > 
> > I would like to apply for 60% of my work time if there is funding for it.
> > 
> > These are the projects that I would like to push (in no particular order):
> >   - Simplify scalarizer API and usage,
> >   - Create internal APIs (basically split gfortran.h and/or trans.h to 
> > different pieces) and add unit testing for them,
> >   - Move code from class.cc to a trans-class.cc and get rid of the class 
> > artifacts around the class descriptor and vtable in the whole frontend.
> >   - Defer all work done at parsing time to resolution time, so that the 
> > parser's job reduces to just recognizing and recording statements,
> >   - Avoid simplifying intrinsics before checking they are valid,
> >   - Improve module loading (there is PR98426, possibly a few others),
> >   - Array descriptor reform (does it still apply?).
> > 
> > The above are, I think, long and/or difficult, and a bit unrewarding as 
> > they have virtually no user-visible impact, and it's unlikely to get 
> > funding for them.  But maybe we could apply for a package project 
> > including user-visible changes and less visible ones.
> > 
> > The projects proposed by Paul all seem worth pursuing.  If there is only 
> > one, my vote goes for fixing the PDTs.
> > 
> > Cheers.
> > Mikael  
> 
> The original person who contacted me at FortranDiscourse already 
> submitted a proposal for something to do with Fortran-Lang and is 
> offering to assist with a gfortran proposal. I asked for a direct email 
> address so I could relay this to you if you do not have it.  I also gave 
> saveral of your emails to him asking to contact you directly.
> 
> Regards,
> 
> Jerry


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

Re: Possible funding of gfortran work

[Thomas Koenig]

On 30.05.23 15:32, Andre Vehreschild wrote:
> Hi all,
> 
> thank you for all your input. I have read the funding requirements and checked
> out the application form. We have to agree on a project goal and describe why
> it is critical to fund this project.
> 
> Let me try a first shot on this:
> 
> - Title:
> 
> GFortran-Improvement
> 
> - Abstract:
> 
> Enable the free gfortran compiler to support contemporary language paradigms.
> 
> - Dependencies (on the project as well as projects that depend on the
>    technology)
> 
> Does any one have a convincing project that uses contemporary Fortran?

CP2K is an example, it's open source and written in Fortran.

https://www.cp2k.org/


> Project goal (max 900 words!):
> 
> * Complete language intrinsic parallel programming paradigm coarrays. This
>    includes completing native coarray support (thread based). As well as
>    refactoring of the library based  coarray approach to support coarrays in
>    modules. I.e. research on how to support the use of coarrays in modules that
>    are not aware of coarrays (not compiled with its support enabled).

The current work is process-based, and there is no problem that we see
about library code.

What about this?

* Fortran has a safe and intuitive method for parallel execution,
   coarrays. There is currently no efficient implementation for
   multi-core CPUs on a freely available compiler.  The goal is to bring
   the existing, process-based shared memory implementation on a branch
   into gfortran mainline as an experimental, but useful feature.

I also would not promise complete coarray support by project's end.
This would include teams, which are scary :-)

Having a useful

(There is Intel, which is dog-slow, and there is NAG, which costs
money).

> * Complete standard compliance from Fortran 2003 onwards. Esp. fixing
>    finalization of partially derived types (PDTs) and issues in the associate
>    command.

Again, we should not promise what we cannot deliver.

> * Ensure maintainability of gfortran by cleaning up/refactoring APIs including
>    the scalarizer. Improve the single responsibility pattern's (SRP) use by,
>    e.g., ensuring the parser does no longer parts of the resolve stage. The goal
>    is not only to separate responsibilities but also to get clearer error
>    messages and with that improve user-friendliness.
> 
> Why is it critical to fund this project (300 words max)?

> Improving the freely available gfortran compiler to support state of the art
> parallelism and language paradigms as well as removing bugs and ensuring
> standard compliance will allow existing codes to be compiled more reliably.
> Furthermore is the lack of support for the newer language paradigms preventing
> the use of Fortran in current projects. Developing in contemporary Fortran needs
> commercial compilers (that support these paradigms already), which leads to
> dependencies on those.

Fortran remains one of the premier language for science, especially for
high-performance computing and fields like quantum chemistry or
computational fluid dynamics.

gfortran is the default Fortran compiler on Linux systems, and lack of
features and bugs in in gfortran hinder adoption of more modern, safer
and more efficient language features. The project has been almost
entirely volunteer-driven so far, but is currently suffering from
a lack of active developers.  Funding will motivate experienced
gfortran developers who have reduced their contributions to return
to the project and advance it substantially.


> This is what I propose for a start. I welcome everyone to participate and make
> the goal or the reasoning more elaborate. We may propose the funding request in
> English or in German. When no one participates, I am tempted to propose it in
> German, as that being my first language, I feel more confident in it.

Make it English, all people here on the list should be able to follow.

> The company Badger Systems GmbH, Cologne, DE, I am working for will support in
> project and bureaucratic management and is willing to act as the proposer of
> this funding request. We of course will be profiting from this.
> 
> Any input is welcome. Feel free to ask, comment, agree, disagree (only when you
> propose something better) or just acknowledge.

One thing I did not find at a cursory glance is how the project funding
would be distributed, and under which conditions.

Did you find anything on the website?

Best regards

	Thomas

Re: Possible funding of gfortran work

[Benson Muite]

On 5/30/23 23:08, Thomas Koenig via Fortran wrote:
> On 30.05.23 15:32, Andre Vehreschild wrote:
>> Hi all,
>>
>> thank you for all your input. I have read the funding requirements and
>> checked
>> out the application form. We have to agree on a project goal and
>> describe why
>> it is critical to fund this project.
>>
>> Let me try a first shot on this:
>>
>> - Title:
>>
>> GFortran-Improvement
>>
>> - Abstract:
>>
>> Enable the free gfortran compiler to support contemporary language
>> paradigms.
>>
>> - Dependencies (on the project as well as projects that depend on the
>>    technology)
>>
>> Does any one have a convincing project that uses contemporary Fortran?
> 
> CP2K is an example, it's open source and written in Fortran.
> 
> https://www.cp2k.org/
> 
> 
>> Project goal (max 900 words!):
>>
>> * Complete language intrinsic parallel programming paradigm coarrays.
>> This
>>    includes completing native coarray support (thread based). As well as
>>    refactoring of the library based  coarray approach to support
>> coarrays in
>>    modules. I.e. research on how to support the use of coarrays in
>> modules that
>>    are not aware of coarrays (not compiled with its support enabled).
> 
Is distributed memory support for co-arrays of interest as well? There
is a lot of code that uses MPI (for which there is some push for using
more modern Fortran features), and there are also other libraries such
as GASPI.
> The current work is process-based, and there is no problem that we see
> about library code.
> 
> What about this?
> 
> * Fortran has a safe and intuitive method for parallel execution,
>   coarrays. There is currently no efficient implementation for
>   multi-core CPUs on a freely available compiler.  The goal is to bring
>   the existing, process-based shared memory implementation on a branch
>   into gfortran mainline as an experimental, but useful feature.
> 
> I also would not promise complete coarray support by project's end.
> This would include teams, which are scary :-)
> 
> Having a useful
> 
> (There is Intel, which is dog-slow, and there is NAG, which costs
> money).
Is this also expected in Flang? See:
https://crd.lbl.gov/divisions/amcr/computer-science-amcr/class/research/caffeine/
https://crd.lbl.gov/divisions/amcr/computer-science-amcr/class/research/caffeine/
Probably good to make a case for two open source compilers.
> 
>> * Complete standard compliance from Fortran 2003 onwards. Esp. fixing
>>    finalization of partially derived types (PDTs) and issues in the
>> associate
>>    command.
> 
> Again, we should not promise what we cannot deliver.
> 
>> * Ensure maintainability of gfortran by cleaning up/refactoring APIs
>> including
>>    the scalarizer. Improve the single responsibility pattern's (SRP)
>> use by,
>>    e.g., ensuring the parser does no longer parts of the resolve
>> stage. The goal
>>    is not only to separate responsibilities but also to get clearer error
>>    messages and with that improve user-friendliness.
>>
>> Why is it critical to fund this project (300 words max)?
> 
>> Improving the freely available gfortran compiler to support state of
>> the art
>> parallelism and language paradigms as well as removing bugs and ensuring
>> standard compliance will allow existing codes to be compiled more
>> reliably.
>> Furthermore is the lack of support for the newer language paradigms
>> preventing
>> the use of Fortran in current projects. Developing in contemporary
>> Fortran needs
>> commercial compilers (that support these paradigms already), which
>> leads to
>> dependencies on those.
> 
> Fortran remains one of the premier language for science, especially for
> high-performance computing and fields like quantum chemistry or
> computational fluid dynamics.
> 
> gfortran is the default Fortran compiler on Linux systems, and lack of
> features and bugs in in gfortran hinder adoption of more modern, safer
> and more efficient language features. The project has been almost
> entirely volunteer-driven so far, but is currently suffering from
> a lack of active developers.  Funding will motivate experienced
> gfortran developers who have reduced their contributions to return
> to the project and advance it substantially.
> 
> 
Any possibilities for new contributors to participate?
>> This is what I propose for a start. I welcome everyone to participate
>> and make
>> the goal or the reasoning more elaborate. We may propose the funding
>> request in
>> English or in German. When no one participates, I am tempted to
>> propose it in
>> German, as that being my first language, I feel more confident in it.
> 
> Make it English, all people here on the list should be able to follow.
> 
>> The company Badger Systems GmbH, Cologne, DE, I am working for will
>> support in
>> project and bureaucratic management and is willing to act as the
>> proposer of
>> this funding request. We of course will be profiting from this.
>>
>> Any input is welcome. Feel free to ask, comment, agree, disagree (only
>> when you
>> propose something better) or just acknowledge.
> 
> One thing I did not find at a cursory glance is how the project funding
> would be distributed, and under which conditions.
> 
> Did you find anything on the website?
> 
> Best regards
> 
>     Thomas
> 

Re: Possible funding of gfortran work

[Thomas Koenig]

On 31.05.23 05:46, Benson Muite wrote:
 > On 5/30/23 23:08, Thomas Koenig via Fortran wrote:


 >>> * Complete language intrinsic parallel programming paradigm coarrays.
 >>> This
 >>>     includes completing native coarray support (thread based). As 
well as
 >>>     refactoring of the library based  coarray approach to support
 >>> coarrays in
 >>>     modules. I.e. research on how to support the use of coarrays in
 >>> modules that
 >>>     are not aware of coarrays (not compiled with its support enabled).
 >>
 > Is distributed memory support for co-arrays of interest as well? There
 > is a lot of code that uses MPI (for which there is some push for using
 > more modern Fortran features), and there are also other libraries such
 > as GASPI.

We already support OpenCoarrays via -fcoarray=lib, which is MPI-based
(or at least can use MPI).  I guess that OpenCoarrays could be modified
to use GASPI, but this would likely be a separate (if related) project.

We would have to check about license requirements, though - I'm not sure
if the implementation of GASPI is free enough for the Soverereign Tech
Fund (at least Wikipedia claims it's "pay for commercial users",
which would be consistent with the business model of the Fraunhofer
Institutes.)


 >> (There is Intel, which is dog-slow, and there is NAG, which costs
 >> money).
 > Is this also expected in Flang? See:
 > 
https://crd.lbl.gov/divisions/amcr/computer-science-amcr/class/research/caffeine/
 > 
https://crd.lbl.gov/divisions/amcr/computer-science-amcr/class/research/caffeine/
 > Probably good to make a case for two open source compilers.

We're concerned with gfortran here.  A lot of work and money has gone
into flang that I sometimes think would have been better spent on
gfortran, then we would be in a better position overall today.

But I am hoping that this initiative can cure at least part of that.

 >> Fortran remains one of the premier language for science, especially for
 >> high-performance computing and fields like quantum chemistry or
 >> computational fluid dynamics.
 >>
 >> gfortran is the default Fortran compiler on Linux systems, and lack of
 >> features and bugs in in gfortran hinder adoption of more modern, safer
 >> and more efficient language features. The project has been almost
 >> entirely volunteer-driven so far, but is currently suffering from
 >> a lack of active developers.  Funding will motivate experienced
 >> gfortran developers who have reduced their contributions to return
 >> to the project and advance it substantially.
 >>
 >>
 > Any possibilities for new contributors to participate?

We should avoid bringing people in who spend all the money just
familiarizing themselves with the compiler, producing no useful
output in the end.

I think that contributors should have demonstrated that they are
capable of working productively with gfortran, and the best way
to demonstrate that is to already have a track record of accepted
patches (preferably gfortran, but also gcc in general). That does not
mean that this track record needs to be years or decades old, but it
should exist.

Also, people recommended by a current contributor should be able
to participate; but we should probably discuss people who apply
on a case-by-case basis.

(The above is my personal opinion, please discuss if anybody has
a different opinion).

Best regards

	Thomas

Re: Possible funding of gfortran work

[Benson Muite]

On 5/31/23 09:08, Thomas Koenig wrote:
> On 31.05.23 05:46, Benson Muite wrote:
>> On 5/30/23 23:08, Thomas Koenig via Fortran wrote:
> 
> 
>>>> * Complete language intrinsic parallel programming paradigm coarrays.
>>>> This
>>>>     includes completing native coarray support (thread based). As
> well as
>>>>     refactoring of the library based  coarray approach to support
>>>> coarrays in
>>>>     modules. I.e. research on how to support the use of coarrays in
>>>> modules that
>>>>     are not aware of coarrays (not compiled with its support enabled).
>>>
>> Is distributed memory support for co-arrays of interest as well? There
>> is a lot of code that uses MPI (for which there is some push for using
>> more modern Fortran features), and there are also other libraries such
>> as GASPI.
> 
> We already support OpenCoarrays via -fcoarray=lib, which is MPI-based
> (or at least can use MPI).  I guess that OpenCoarrays could be modified
> to use GASPI, but this would likely be a separate (if related) project.
> 
Ok.  One of the large use cases for Fortran is high performance
computing.  Other distributed memory efforts include:
http://dvm-system.org/en/
https://xcalablemp.org/
MPI seems like it will evolve to use many new Fortran features so that
Fortran and C bindings are similar, though it maybe the case that most
Fortran codes will evolve to use co-arrays.

GPU and other accelerator support may also be worth improving.

> We would have to check about license requirements, though - I'm not sure
> if the implementation of GASPI is free enough for the Soverereign Tech
> Fund (at least Wikipedia claims it's "pay for commercial users",
> which would be consistent with the business model of the Fraunhofer
> Institutes.)
> 
> 
>>> (There is Intel, which is dog-slow, and there is NAG, which costs
>>> money).
>> Is this also expected in Flang? See:
>>
> https://crd.lbl.gov/divisions/amcr/computer-science-amcr/class/research/caffeine/
>>
> https://crd.lbl.gov/divisions/amcr/computer-science-amcr/class/research/caffeine/
>> Probably good to make a case for two open source compilers.
> 
> We're concerned with gfortran here.  A lot of work and money has gone
> into flang that I sometimes think would have been better spent on
> gfortran, then we would be in a better position overall today.
> 
> But I am hoping that this initiative can cure at least part of that.
May need to convince reviewers why Flang alone is insufficient.
> 
>>> Fortran remains one of the premier language for science, especially for
>>> high-performance computing and fields like quantum chemistry or
>>> computational fluid dynamics.
>>>
>>> gfortran is the default Fortran compiler on Linux systems, and lack of
>>> features and bugs in in gfortran hinder adoption of more modern, safer
>>> and more efficient language features. The project has been almost
>>> entirely volunteer-driven so far, but is currently suffering from
>>> a lack of active developers.  Funding will motivate experienced
>>> gfortran developers who have reduced their contributions to return
>>> to the project and advance it substantially.
>>>
Maybe worth mentioning tools like R which use many Fortran libraries.
Most use Fortran 77 though.
>>>
>> Any possibilities for new contributors to participate?
> 
> We should avoid bringing people in who spend all the money just
> familiarizing themselves with the compiler, producing no useful
> output in the end.
> 
> I think that contributors should have demonstrated that they are
> capable of working productively with gfortran, and the best way
> to demonstrate that is to already have a track record of accepted
> patches (preferably gfortran, but also gcc in general). That does not
> mean that this track record needs to be years or decades old, but it
> should exist.
> 
> Also, people recommended by a current contributor should be able
> to participate; but we should probably discuss people who apply
> on a case-by-case basis.
This is ok. But many new developers are looking at Julia and Python,
comfortably retired developers may not be as motivated to return by
funding, but might mentor in critical areas.
> 
> (The above is my personal opinion, please discuss if anybody has
> a different opinion).
> 
> Best regards
> 
>     Thomas

Re: Possible funding of gfortran work

[Andre Vehreschild]

Hi Thomas,

I have revamp the proposal a bit more. Thank you for your input. I took some of
it "as is", but I also rephrased some of it. I hope you are ok with that. Here
is what I have so far:

---
- Title:

GFortran-Improvement

- Abstract:

Enable the free gfortran compiler to support contemporary language paradigms.

- Dependencies (on the project as well as projects that depend on the
  technology; max 300 words)

CP2K https://www.cp2k.org/

- Why is it critical to fund this project (300 words max)?

Fortran remains one of the premier language for science, especially for
high-performance computing and fields like quantum chemistry or
computational fluid dynamics.

gfortran is the default Fortran compiler on many Linux systems, and lack of
features and bugs in gfortran hinder adoption of more modern, safer and more
efficient language features. The project has been almost entirely
volunteer-driven so far, but is currently suffering from a lack of active
developers for larger features. Funding will enable the project to pay some
gfortran experienced developers to implement some of missing/incomplete
features, that are too large to tackle for a single volunteer. Payed developers
are to contribute a significant part of the features.

- Target of the projects in the sense of users (max 300 words)

High-performance computing community, esp. but not limited to fluid and thermo
dynamics, wheater forecasting

- How was the project funded in the past (max 300 words)

- Project goal (max 900 words!):

* Fortran has a safe and intuitive method for parallel execution,
  coarrays. There is currently no complete and efficient implementation for
  multi-core CPUs on a freely available compiler. The goal is to bring
  the existing, process-based shared memory implementation on a branch
  into gfortran mainline as a feature for further evaluation and hardening.

* GFortran's coarrays for distributed memory lack support for data structures
  provided modules that have not been compiled with coarray support (or are
  distributed in binary form only). Research and prototypical implementation
  shall be conducted with the goal to find a general and well performing
  solution. This could become an outstanding feature for a free compiler.

* Enhance the support for teams in coarray to a level where it gets usable.
  Teams in coarrays allow for grouping workers logically. These then can
  colaborate without interference or the user needing to take care. The support
  is rather basic and shall be made usable to a level where the most popular
  calls work.

* Enhance standard compliance from Fortran 2003 onwards. Esp. fixing
  finalization of partially derived types (PDTs) and issues in the associate
  command.

* Ensure maintainability of gfortran by cleaning up/refactoring APIs including
  the scalarizer. Improve the single responsibility pattern's (SRP) use by,
  e.g., ensuring the parser does no longer parts of the resolve stage. The goal
  is not only to separate responsibilities but also to get clearer error
  messages and with that improve user-friendliness.

- How many FTEs are you requesting?

- What is the amount of funding you are requesting, approximately?

- In what timeframe will you perform the activities?

- Who (maintainer, contributor, organization) would be most qualified to
  implement this work/receive the support and why?

---

The questions in there are more or less the questions that have to be answered
for the proposal. The following is still open:

* I would be nice to have some more dependencies.
* Estimates for Nicolas and Mikael work would be good. (You can do them also as
  private mail if you like).
* Any polishing.

Feel free to comment.

- Andre

On Wed, 31 May 2023 08:08:49 +0200
Thomas Koenig <tkoenig@netcologne.de> wrote:

> On 31.05.23 05:46, Benson Muite wrote:
>  > On 5/30/23 23:08, Thomas Koenig via Fortran wrote:
>
>
>  >>> * Complete language intrinsic parallel programming paradigm coarrays.
>  >>> This
>  >>>     includes completing native coarray support (thread based). As
> well as
>  >>>     refactoring of the library based  coarray approach to support
>  >>> coarrays in
>  >>>     modules. I.e. research on how to support the use of coarrays in
>  >>> modules that
>  >>>     are not aware of coarrays (not compiled with its support enabled).
>  >>
>  > Is distributed memory support for co-arrays of interest as well? There
>  > is a lot of code that uses MPI (for which there is some push for using
>  > more modern Fortran features), and there are also other libraries such
>  > as GASPI.
>
> We already support OpenCoarrays via -fcoarray=lib, which is MPI-based
> (or at least can use MPI).  I guess that OpenCoarrays could be modified
> to use GASPI, but this would likely be a separate (if related) project.
>
> We would have to check about license requirements, though - I'm not sure
> if the implementation of GASPI is free enough for the Soverereign Tech
> Fund (at least Wikipedia claims it's "pay for commercial users",
> which would be consistent with the business model of the Fraunhofer
> Institutes.)
>
>
>  >> (There is Intel, which is dog-slow, and there is NAG, which costs
>  >> money).
>  > Is this also expected in Flang? See:
>  >
> https://crd.lbl.gov/divisions/amcr/computer-science-amcr/class/research/caffeine/
>  >
> https://crd.lbl.gov/divisions/amcr/computer-science-amcr/class/research/caffeine/
>  > Probably good to make a case for two open source compilers.
>
> We're concerned with gfortran here.  A lot of work and money has gone
> into flang that I sometimes think would have been better spent on
> gfortran, then we would be in a better position overall today.
>
> But I am hoping that this initiative can cure at least part of that.
>
>  >> Fortran remains one of the premier language for science, especially for
>  >> high-performance computing and fields like quantum chemistry or
>  >> computational fluid dynamics.
>  >>
>  >> gfortran is the default Fortran compiler on Linux systems, and lack of
>  >> features and bugs in in gfortran hinder adoption of more modern, safer
>  >> and more efficient language features. The project has been almost
>  >> entirely volunteer-driven so far, but is currently suffering from
>  >> a lack of active developers.  Funding will motivate experienced
>  >> gfortran developers who have reduced their contributions to return
>  >> to the project and advance it substantially.
>  >>
>  >>
>  > Any possibilities for new contributors to participate?
>
> We should avoid bringing people in who spend all the money just
> familiarizing themselves with the compiler, producing no useful
> output in the end.
>
> I think that contributors should have demonstrated that they are
> capable of working productively with gfortran, and the best way
> to demonstrate that is to already have a track record of accepted
> patches (preferably gfortran, but also gcc in general). That does not
> mean that this track record needs to be years or decades old, but it
> should exist.
>
> Also, people recommended by a current contributor should be able
> to participate; but we should probably discuss people who apply
> on a case-by-case basis.
>
> (The above is my personal opinion, please discuss if anybody has
> a different opinion).
>
> Best regards
>
> 	Thomas


--
Andre Vehreschild * Email: vehre ad gmx dot de

Re: Possible funding of gfortran work

[Damian Rouson]

[-- Attachment #1: Type: text/plain, Size: 6101 bytes --]

Thanks for working on this, guys.  I made a few suggestions below.

Damian

On Wed, May 31, 2023 at 5:25 AM Andre Vehreschild via Fortran <
fortran@gcc.gnu.org> wrote:

>
> - Dependencies (on the project as well as projects that depend on the
>   technology; max 300 words)
>
> CP2K https://www.cp2k.org/


Coarray codes:

ICAR: https://github.com/ncar/icar
FEATS: https://github.com/sourceryinstitute/feats
FAVOR*:
https://www.nrc.gov/reading-rm/doc-collections/nuregs/staff/sr1795/index.html

* This is a closed-source project that will feature parallel execution with
coarrays in an upcoming release.

For additional coarray codes, check out these references:

Mozdzynski, G., Hamrud, M., & Wedi, N. (2015) A Partitioned Global Address
Space implementation of the European Centre for Medium Range Weather
Forecasts Integrated Forecasting System. International Journal of High
Performance Computing Applications.

Garain, S., Balsara, D. S., & Reid, J. (2015) Comparing Coarray Fortran
(CAF) with MPI for several structured mesh PDE applications. Journal of
Computational Physics.

Preissl, R., Wichmann, N., Long, B., Shalf, J., Ethier, S., & Koniges, A.
(2011) Multithreaded global address space communication techniques for
gyrokinetic fusion applications on ultra-scale platforms. In Proceedings of
2011 International Conference for High Performance Computing, Networking,
Storage and Analysis (p. 78). ACM.

Other important Fortran codes that don't necessarily use coarrays:

NWChem computational chemistry software
FUN3D computational fluid dynamics software from NASA
MSC NASTRAN structural engineering software from MSC Software
WRF weather forecasting software from NCAR
FAST nuclear fuel performance software from the U.S. Nuclear Regulatory
Commission (NRC)



> - Why is it critical to fund this project (300 words max)?
>
> Fortran remains one of the premier language for science, especially for
> high-performance computing and fields like quantum chemistry or
> computational fluid dynamics.
>

If you want some usage data, I can provide PDF slides, but I don't think
the gfortran mailing list takes attachments so you'll have to contact me
directly.


> gfortran is the default Fortran compiler on many Linux systems, and lack of
> features and bugs in gfortran hinder adoption of more modern, safer and
> more
> efficient language features. The project has been almost entirely
> volunteer-driven so far, but is currently suffering from a lack of active
> developers for larger features. Funding will enable the project to pay some
> gfortran experienced developers to implement some of missing/incomplete
> features, that are too large to tackle for a single volunteer. Payed
> developers
> are to contribute a significant part of the features.
>
> - Target of the projects in the sense of users (max 300 words)
>
> High-performance computing community, esp. but not limited to fluid and
> thermo
> dynamics, wheater forecasting
>

I would mention the worldwide impact of weather and climate models, all of
which are Fortran codes.  I would also mention nuclear energy.  All of the
codes developed by the U.S. Nuclear Regulatory Commission and used for
licensing power plants are Fortran codes. Also aerospace, e.g., FUN3D
developed by NASA and used by SpaceX and several aircraft manufcaturers.
And automotive engineering (mention NASTRAN developed by MSC Software and
used by several automotive companies).


>
> - How was the project funded in the past (max 300 words)
>

If you don't mind mentioning that the foundational work on the front-end
was partly funded by Sourcery Institute with the remainder being the work
of volunteers, that would be appreciated.  Of course, none of the work on
the shared-memory library was funded by Sourcery Institute so maybe the
Sourcery Institute is not relevant.  Your call.


>
> - Project goal (max 900 words!):
>
> * Fortran has a safe and intuitive method for parallel execution,
>   coarrays. There is currently no complete and efficient implementation for
>   multi-core CPUs on a freely available compiler. The goal is to bring
>   the existing, process-based shared memory implementation on a branch
>   into gfortran mainline as a feature for further evaluation and hardening.
>

This is good.  I think I saw an earlier version without the "on a freely
available compiler" text.  This version is accurate.

>
> * GFortran's coarrays for distributed memory lack support for data
> structures
>   provided modules that have not been compiled with coarray support (or are
>   distributed in binary form only). Research and prototypical
> implementation
>   shall be conducted with the goal to find a general and well performing
>   solution. This could become an outstanding feature for a free compiler.
>

Will this work also require working inside OpenCoarrays?  If so, that would
be great and it's probably important to mention OpenCoarrays directly here
because it's separate software with a different license.


>
> * Enhance the support for teams in coarray to a level where it gets usable.
>   Teams in coarrays allow for grouping workers logically. These then can
>   colaborate without interference or the user needing to take care. The
> support
>   is rather basic and shall be made usable to a level where the most
> popular
>   calls work.
>

This is exciting.  I recommend also mentioning support for the features
related to failed images.  In the most commonly envisioned use case for
failed images, teams are essential.  On the other hand, getting failed
images right is going to be hard and might not fit within the available
funding.


>
> * Enhance standard compliance from Fortran 2003 onwards. Esp. fixing
>   finalization of partially derived types (PDTs) and issues in the
> associate
>   command.
>

I'm especially excited about improved support for the associate statement
(which is already quite good and better than some other compilers).

Damian

Re: Possible funding of gfortran work

[Andre Vehreschild]

Hi Damian, all,

thank you for your input. I have incorporated most of it. Due to Germany
stepping out of nuclear use, I have reduced the cites on these to a minimum. I
don't know anything about the people evaluating the proposal and don't want to
be rejected just because of ideological reasons. Here is the proposal so far.
Has any one a good url for the FAST project?

---
- Title:

GFortran-Improvement

- Abstract:

Enable the free gfortran compiler to support contemporary language paradigms.

- Dependencies (on the project as well as projects that depend on the
  technology; max 300 words)

Exemplarily these codes make use of language paradigms or want to, but can not
due to lack of support in gfortran:

CP2K: https://www.cp2k.org/ -- Quantum chemistry and solid state physics
ICAR: https://github.com/ncar/icar -- Simplified atmospheric model
FEATS: https://github.com/sourceryinstitute/feats -- Asynchronous task
scheduling framework FAVOR:
https://www.nrc.gov/reading-rm/doc-collections/nuregs/staff/sr1795/index.html
-- Reactor security NWChem: https://www.nwchem-sw.org/ -- Computational
chemistry software FUN3D: https://fun3d.larc.nasa.gov/ -- Computational fluid
dynamics software from NASA MSC NASTRAN:
https://simulatemore.mscsoftware.com/category/products/msc-nastran/ --
Structural engineering software from MSC Software WRF:
https://www.mmm.ucar.edu/models/wrf -- Weather forecasting software from NCAR
FAST: ??? -- Nuclear fuel performance software from the U.S. Nuclear Regulatory
Commission (NRC)

Some references:

Mozdzynski, G., Hamrud, M., & Wedi, N. (2015) A Partitioned Global Address
Space implementation of the European Centre for Medium Range Weather
Forecasts Integrated Forecasting System. International Journal of High
Performance Computing Applications.

Garain, S., Balsara, D. S., & Reid, J. (2015) Comparing Coarray Fortran
(CAF) with MPI for several structured mesh PDE applications. Journal of
Computational Physics.

Preissl, R., Wichmann, N., Long, B., Shalf, J., Ethier, S., & Koniges, A.
(2011) Multithreaded global address space communication techniques for
gyrokinetic fusion applications on ultra-scale platforms. In Proceedings of
2011 International Conference for High Performance Computing, Networking,
Storage and Analysis (p. 78). ACM.

- Why is it critical to fund this project (300 words max)?

Fortran remains one of the premier language for science, especially for
high-performance computing and fields like quantum chemistry or
computational fluid dynamics.

gfortran is the default Fortran compiler on many Linux systems, and lack of
features and bugs in gfortran hinder adoption of more modern, safer and more
efficient language features. The project has been almost entirely
volunteer-driven so far, but is currently suffering from a lack of active
developers for larger features. Funding will enable the project to pay some
gfortran experienced developers to implement some of the missing/incomplete
features, that are too large to tackle for a single volunteer. Payed developers
are to contribute a significant part of the features.

- Target of the projects in the sense of users (max 300 words)

This project targets the high-performance computing community, esp. but not
limited to fluid and thermo dynamics, wheater forecasting and climate models.
Most if not all of those are Fortran codes. Maintaining them using explicit
parallelism is tedious and deviates from the domain to address. Other users are
aerospace, e.g. NASA or SpaceX, as well as aircraft and automotive
manufacturers.

- How was the project funded in the past (max 300 words)

Foundational work on the coarray implementation was funded by Sourcery
Institute. Small extensions and selected bug fixes have been donated by
companies having a minor impact only. Most of the work was done on a
voluntary basis.

- Project goal (max 900 words!):

* Fortran has a safe and intuitive method for parallel execution,
  coarrays. There is currently no complete and efficient implementation for
  multi-core CPUs on a freely available compiler. The goal is to bring
  the existing, process-based shared memory implementation on a branch
  into gfortran mainline as a feature for further evaluation and hardening.

* GFortran's coarrays for distributed memory lack support for data structures
  provided by modules that have not been compiled with coarray support (or are
  distributed in binary form only). Research and prototypical implementation
  in gfortran and the OpenCoarrays library shall be conducted with the goal to
  find a general and well performing solution. This could become an outstanding
  feature for a free compiler.

* Enhance the support for teams and failed images in coarrays to a level where
  it gets usable. Teams in coarrays allow for grouping workers logically. These
  then can colaborate without interference or the user needing to take care.
  The support is rather basic and shall be made usable to a level where the
  most popular calls work. The failed images concept allows a program to react
  on one of its processes failing without terminating the program. The present
  support shall be extended to enable the restart of the process instead of
  just reporting the fail and then having to quit anyway as it is currently.

* Enhance standard compliance from Fortran 2003 onwards. Esp. fixing
  finalization of partially derived types (PDTs) and issues in the associate
  command.

* Ensure maintainability of gfortran by cleaning up/refactoring APIs including
  the scalarizer. Improve the single responsibility pattern's (SRP) use by,
  e.g., ensuring the parser does no longer parts of the resolve stage. The goal
  is not only to separate responsibilities but also to get clearer error
  messages and with that improve user-friendliness.

- How many FTEs are you requesting?

- What is the amount of funding you are requesting, approximately?

- In what timeframe will you perform the activities?

- Who (maintainer, contributor, organization) would be most qualified to
  implement this work/receive the support and why?
---

Any input welcome.

Regards,
	Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de

Re: Possible funding of gfortran work

[Bernhard Reutner-Fischer]

On 1 June 2023 11:18:08 CEST, Andre Vehreschild via Fortran <fortran@gcc.gnu.org> wrote:
>Hi Damian, all,
>
>thank you for your input. I have incorporated most of it. Due to Germany
>stepping out of nuclear use, I have reduced the cites on these to a minimum. I
>don't know anything about the people evaluating the proposal and don't want to
>be rejected just because of ideological reasons. Here is the proposal so far.

Good point.
There must be a ton fortran code running near ITER, maybe someone knows if any of that uses coarrays or would be inclined to do so if it would be improved?

Just a thought..

Re: Possible funding of gfortran work

[Mikael Morin]

Hello,

some more comments below:

Le 01/06/2023 à 11:18, Andre Vehreschild a écrit :
> Hi Damian, all,
> 
> thank you for your input. I have incorporated most of it. Due to Germany
> stepping out of nuclear use, I have reduced the cites on these to a minimum. I
> don't know anything about the people evaluating the proposal and don't want to
> be rejected just because of ideological reasons. Here is the proposal so far.
> Has any one a good url for the FAST project?
> 
> ---
> - Title:
> 
> GFortran-Improvement
> 
> - Abstract:
> 
> Enable the free gfortran compiler to support contemporary language paradigms.
> 
> - Dependencies (on the project as well as projects that depend on the
>    technology; max 300 words)
> 
> Exemplarily these codes make use of language paradigms or want to, but can not
> due to lack of support in gfortran:
> 
> CP2K: https://www.cp2k.org/ -- Quantum chemistry and solid state physics
> ICAR: https://github.com/ncar/icar -- Simplified atmospheric model
> FEATS: https://github.com/sourceryinstitute/feats -- Asynchronous task
> scheduling framework FAVOR:
> https://www.nrc.gov/reading-rm/doc-collections/nuregs/staff/sr1795/index.html
> -- Reactor security NWChem: https://www.nwchem-sw.org/ -- Computational
> chemistry software FUN3D: https://fun3d.larc.nasa.gov/ -- Computational fluid
> dynamics software from NASA MSC NASTRAN:
> https://simulatemore.mscsoftware.com/category/products/msc-nastran/ --
> Structural engineering software from MSC Software WRF:
> https://www.mmm.ucar.edu/models/wrf -- Weather forecasting software from NCAR
> FAST: ??? -- Nuclear fuel performance software from the U.S. Nuclear Regulatory
> Commission (NRC)
> 
> Some references:
> 
> Mozdzynski, G., Hamrud, M., & Wedi, N. (2015) A Partitioned Global Address
> Space implementation of the European Centre for Medium Range Weather
> Forecasts Integrated Forecasting System. International Journal of High
> Performance Computing Applications.
> 
> Garain, S., Balsara, D. S., & Reid, J. (2015) Comparing Coarray Fortran
> (CAF) with MPI for several structured mesh PDE applications. Journal of
> Computational Physics.
> 
> Preissl, R., Wichmann, N., Long, B., Shalf, J., Ethier, S., & Koniges, A.
> (2011) Multithreaded global address space communication techniques for
> gyrokinetic fusion applications on ultra-scale platforms. In Proceedings of
> 2011 International Conference for High Performance Computing, Networking,
> Storage and Analysis (p. 78). ACM.
> 
> - Why is it critical to fund this project (300 words max)?
> 
> Fortran remains one of the premier language for science, especially for
> high-performance computing and fields like quantum chemistry or
> computational fluid dynamics.
> 
> gfortran is the default Fortran compiler on many Linux systems, and lack of
> features and bugs in gfortran hinder adoption of more modern, safer and more
> efficient language features. The project has been almost entirely
> volunteer-driven so far, but is currently suffering from a lack of active
> developers for larger features. Funding will enable the project to pay some
> gfortran experienced developers to implement some of the missing/incomplete
> features, that are too large to tackle for a single volunteer. Payed developers
> are to contribute a significant part of the features.
> 
The latter paragraph seems more an answer to the question "why is it 
critical for gfortran to get funding" than "why is it critical for a 
funding body to choose gfortran"?

One idea about the latter question:
so that there is always a free solution:
  - for engineers to make best usage of the hardware available to them 
without hassle and spend their time at what they are best: making science
  - for decades-old proven science codes to be adapted to current 
parallel computing architectures

> - Target of the projects in the sense of users (max 300 words)
> 
> This project targets the high-performance computing community, esp. but not
> limited to fluid and thermo dynamics, wheater forecasting and climate models.
> Most if not all of those are Fortran codes. Maintaining them using explicit
> parallelism is tedious and deviates from the domain to address. Other users are
> aerospace, e.g. NASA or SpaceX, as well as aircraft and automotive
> manufacturers.
> 
> - How was the project funded in the past (max 300 words)
> 
> Foundational work on the coarray implementation was funded by Sourcery
> Institute. Small extensions and selected bug fixes have been donated by
> companies having a minor impact only. Most of the work was done on a
> voluntary basis.
> 
There is also Siemens (Tobias, etc) working on OMP and OpenACC.  Not 
sure whether it should me mentioned here.

> - Project goal (max 900 words!):
> 
> * Fortran has a safe and intuitive method for parallel execution,
>    coarrays. There is currently no complete and efficient implementation for
>    multi-core CPUs on a freely available compiler. The goal is to bring
>    the existing, process-based shared memory implementation on a branch
>    into gfortran mainline as a feature for further evaluation and hardening.
> 
I'm not very found of the last part of the sentence, which sounds like 
the project is targetting half-unfinished state.  I understand Thomas 
not willing to engage to something without being sure it can be 
delivered on time.  But the goal is always to be somehow successful; I 
mean, delivering something that doesn't happen to be useful can't be a goal.

I propose this instead:
The goal is to improve and extend on the previous work on a 
process-based shared memory coarray implementation, so that the feature 
can be made available in the next release of gfortran.

This is a goal, not a promise of succes.  And remember that reallocation 
on assignment was made available behind a flag for quite some time 
before being enabled by default.  We could do the same here if the 
feature is not ready yet, so the above is not a great commitment.

> * GFortran's coarrays for distributed memory lack support for data structures
>    provided by modules that have not been compiled with coarray support (or are
>    distributed in binary form only). Research and prototypical implementation
>    in gfortran and the OpenCoarrays library shall be conducted with the goal to
>    find a general and well performing solution. This could become an outstanding
>    feature for a free compiler.
> 
> * Enhance the support for teams and failed images in coarrays to a level where
>    it gets usable. Teams in coarrays allow for grouping workers logically. These
>    then can colaborate without interference or the user needing to take care.
>    The support is rather basic and shall be made usable to a level where the
>    most popular calls work. The failed images concept allows a program to react
>    on one of its processes failing without terminating the program. The present
>    support shall be extended to enable the restart of the process instead of
>    just reporting the fail and then having to quit anyway as it is currently.
> 
> * Enhance standard compliance from Fortran 2003 onwards. Esp. fixing
>    finalization of partially derived types (PDTs) and issues in the associate
>    command.
> 
> * Ensure maintainability of gfortran by cleaning up/refactoring APIs including
>    the scalarizer. Improve the single responsibility pattern's (SRP) use by,
>    e.g., ensuring the parser does no longer parts of the resolve stage. The goal
>    is not only to separate responsibilities but also to get clearer error
>    messages and with that improve user-friendliness.
> 
> - How many FTEs are you requesting?
> 
> - What is the amount of funding you are requesting, approximately?
> 
> - In what timeframe will you perform the activities?
> 
> - Who (maintainer, contributor, organization) would be most qualified to
>    implement this work/receive the support and why?
> ---
> 
> Any input welcome.
> 
> Regards,
> 	Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de

Regarding the time estimates, it's a bit difficult as we can't foresee 
at this stage the amount of regressions that will need to be fixed, and 
how difficult they will be.  I'm not even sure that the process of 
picking one regression and fixing it will eventually converge to a 
zero-regression state.  It doesn't mean much, but I expect to spend 
between 3 and 6 months on every item I have proposed.  But I expected 
those items to be discussed, prioritized, and either acknowledged or 
refused by the contributors before.

Mikael

Re: Possible funding of gfortran work

[Thomas Koenig]

On 01.06.23 12:59, Mikael Morin wrote:
>>
> The latter paragraph seems more an answer to the question "why is it 
> critical for gfortran to get funding" than "why is it critical for a 
> funding body to choose gfortran"?

Good point :-)

> One idea about the latter question:
> so that there is always a free solution:
>   - for engineers to make best usage of the hardware available to them 
> without hassle and spend their time at what they are best: making science
>   - for decades-old proven science codes to be adapted to current 
> parallel computing architecture

So gfortran remains a viable alternative to existing commercial
compilers.

Best regards

	Thomas

Re: Possible funding of gfortran work

[Andre Vehreschild]

Hi Mikael,

thanks for your valuable input. I have commented inline:

> The latter paragraph seems more an answer to the question "why is it 
> critical for gfortran to get funding" than "why is it critical for a 
> funding body to choose gfortran"?
> 
> One idea about the latter question:
> so that there is always a free solution:
>   - for engineers to make best usage of the hardware available to them 
> without hassle and spend their time at what they are best: making science
>   - for decades-old proven science codes to be adapted to current 
> parallel computing architectures

Agreed. Thank you very much. I have adapted and added it.

> There is also Siemens (Tobias, etc) working on OMP and OpenACC.  Not 
> sure whether it should me mentioned here.

Well, I mean we don't ask for funding on OMP or OpenACC development. So do we
need to confine ourself from these technologies?
 
> I'm not very found of the last part of the sentence, which sounds like 
> the project is targetting half-unfinished state.  I understand Thomas 
> not willing to engage to something without being sure it can be 
> delivered on time.  But the goal is always to be somehow successful; I 
> mean, delivering something that doesn't happen to be useful can't be a goal.
> 
> I propose this instead:
> The goal is to improve and extend on the previous work on a 
> process-based shared memory coarray implementation, so that the feature 
> can be made available in the next release of gfortran.

Taken w/o change. Thanks.
 
> This is a goal, not a promise of succes.  And remember that reallocation 
> on assignment was made available behind a flag for quite some time 
> before being enabled by default.  We could do the same here if the 
> feature is not ready yet, so the above is not a great commitment.

:thumbsup:

> Regarding the time estimates, it's a bit difficult as we can't foresee 
> at this stage the amount of regressions that will need to be fixed, and 
> how difficult they will be.  I'm not even sure that the process of 
> picking one regression and fixing it will eventually converge to a 
> zero-regression state.  It doesn't mean much, but I expect to spend 
> between 3 and 6 months on every item I have proposed.  But I expected 
> those items to be discussed, prioritized, and either acknowledged or 
> refused by the contributors before.

You mean, you will 3 to 6 month full-time for the scalarizer rework, the API
thingys and so on? Or is the estimate on how long it will take you to do the
things in total, i.e. not working full-time on them?

I am asking that specifically because we need to estimate the person days they
pay for and time boundary up to when the project will be done.

Regards,
	Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

Re: Possible funding of gfortran work

[Mikael Morin]

Le 05/06/2023 à 10:08, Andre Vehreschild a écrit :
>> Regarding the time estimates, it's a bit difficult as we can't foresee
>> at this stage the amount of regressions that will need to be fixed, and
>> how difficult they will be.  I'm not even sure that the process of
>> picking one regression and fixing it will eventually converge to a
>> zero-regression state.  It doesn't mean much, but I expect to spend
>> between 3 and 6 months on every item I have proposed.  But I expected
>> those items to be discussed, prioritized, and either acknowledged or
>> refused by the contributors before.
> 
> You mean, you will 3 to 6 month full-time for the scalarizer rework, the API
> thingys and so on? Or is the estimate on how long it will take you to do the
> things in total, i.e. not working full-time on them?
> 
The latter, 3-6 months delivery time each item at 60% working time.

> I am asking that specifically because we need to estimate the person days they
> pay for and time boundary up to when the project will be done.
> 
Yes, I don't like it but I understand the need for estimating.
I have looked at the evaluation criteria at [1]. There is among other 
things:
> Furthermore, we look at how well the planning for the project is laid out. Are the activities well-structured, appropriate and feasible?

I think we are far from having a "well laid out planning".  Even if it's 
difficult to estimate the amount of days of work, we should probably at 
least try to decompose the project into milestones, that is (small) 
steps proving progress toward the target.

[1] https://sovereigntechfund.de/en/applications/

Re: Possible funding of gfortran work

[Andre Vehreschild]

Hi Mikael,

...
> Yes, I don't like it but I understand the need for estimating.
> I have looked at the evaluation criteria at [1]. There is among other 
> things:
> > Furthermore, we look at how well the planning for the project is laid out.
> > Are the activities well-structured, appropriate and feasible?  
> 
> I think we are far from having a "well laid out planning".  Even if it's 
> difficult to estimate the amount of days of work, we should probably at 
> least try to decompose the project into milestones, that is (small) 
> steps proving progress toward the target.

I understand. I would have been happy in the past when a client had as much
knowledge and structure than we already have. Under "Project goal" we now have
about 300 words. So we could add more. What do you have in mind? Like adding
more bullet points to each item in the form of:
  - rebase existing implementation to current master
  - identify missing requirements
  - add tests for missing requirements
  - implement missing requirements to pass tests.
  ...

Or are your targeting a more time based approach like:
  Milestone 1: shared mem coarrays merge to master in week 2 of project
  Milestone 2: finish research on general way for doing remote coarray access
  in alien structures to finish in week 1 of project
  ...

Take the above as examples please, not as proposals.

In the meantime I have added something to the "Who section":
---
- Who (maintainer, contributor, organization) would be most qualified to
  implement this work/receive the support and why?

Maurice Ulrich @ Badger Systems GmbH -- Project management

Dr. Andre Vehreschild @ Badger Systems GmbH -- Contributed to distributed
  memory coarray, teams and failed images support. Has also worked on the
  associate command and several other standard compliance issues.

Mikael Morin @ ??? -- Maintained/Contributed to the scalarizer. Experienced in
  gfortran development and component dependencies.

Nicolas König @ ETH Zürich -- Implemented the first steps of the process-based
  shared memory coarray approach.
---

Our project manager is mostly there as a counting head. He will not do much, if
not asked explicitly, but I learned that it is good to have some one named.

I am curious to hear your input.

Regards,
	Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

Re: Possible funding of gfortran work

[Mikael Morin]

Hello,

Le 06/06/2023 à 15:06, Andre Vehreschild a écrit :
> Hi Mikael,
> 
> ...
>> Yes, I don't like it but I understand the need for estimating.
>> I have looked at the evaluation criteria at [1]. There is among other
>> things:
>>> Furthermore, we look at how well the planning for the project is laid out.
>>> Are the activities well-structured, appropriate and feasible?
>>
>> I think we are far from having a "well laid out planning".  Even if it's
>> difficult to estimate the amount of days of work, we should probably at
>> least try to decompose the project into milestones, that is (small)
>> steps proving progress toward the target.
> 
> I understand. I would have been happy in the past when a client had as much
> knowledge and structure than we already have. Under "Project goal" we now have
> about 300 words. So we could add more.
Well, It wouldn't be really part of the goal, more how to reach that 
goal.  The "timeframe" question is possibly where it should go.  Or if 
you consider that the planning is a goal itself, it could be put here.

> What do you have in mind?
Something that breaks a big, risky thing to a set of smaller, manageable 
ones.  Something showing that the main problems (or some of them at 
least) have been identified and that we have a path to solve them one by 
one.

> Like adding
> more bullet points to each item in the form of:
>    - rebase existing implementation to current master
>    - identify missing requirements
>    - add tests for missing requirements
>    - implement missing requirements to pass tests.
>    ...
Well, this is a bit too general to be useful.

> Or are your targeting a more time based approach like:
>    Milestone 1: shared mem coarrays merge to master in week 2 of project
>    Milestone 2: finish research on general way for doing remote coarray access
>    in alien structures to finish in week 1 of project
>    ...
Maybe, but I would not emphasize the time constraints that much.

I have done it below for the scalarizer simplification, which is what 
for which the picture is the most clear in my mind regarding what to do 
and how to do it.
Here it is, with the expected number of weeks (that's 3 days for me) to 
do it:
  - Add optional scalarization block. (1 week)
  - Setup multiple expression usage (in case of multiple loops) in a 
more clear way. (3 weeks)
  - Move array and loop bounds setup to an opaque "start scalarization" 
function (3 weeks)
  - Make scalarization independant on previous setup of array 
information and move setup code from "start scalarization" to "finish 
scalarization" (5 weeks)
  - Initialize array information inside the gfc_conv_expr* functions and 
remove preliminary walking of expressions (4 weeks)

I hope that's not too technical to be put in the application form.

> 
> Take the above as examples please, not as proposals.
> 
> In the meantime I have added something to the "Who section":
...
> Mikael Morin @ ??? -- Maintained/Contributed to the scalarizer. Experienced in
>    gfortran development and component dependencies.
> 
I'm not affiliated to any company, university or organization.  Just 
myself. :-)

Re: Possible funding of gfortran work

[Andre Vehreschild]

Hi Mikael,

please find my answers inline.

> > I understand. I would have been happy in the past when a client had as much
> > knowledge and structure than we already have. Under "Project goal" we now
> > have about 300 words. So we could add more.
> Well, It wouldn't be really part of the goal, more how to reach that
> goal.  The "timeframe" question is possibly where it should go.  Or if
> you consider that the planning is a goal itself, it could be put here.

The timeframe question accepts only a number. I.e. we can't plan there.

> > What do you have in mind?
> Something that breaks a big, risky thing to a set of smaller, manageable
> ones.  Something showing that the main problems (or some of them at
> least) have been identified and that we have a path to solve them one by
> one.
>
> > Like adding
> > more bullet points to each item in the form of:
> >    - rebase existing implementation to current master
> >    - identify missing requirements
> >    - add tests for missing requirements
> >    - implement missing requirements to pass tests.
> >    ...
> Well, this is a bit too general to be useful.

Mhh, I don't suppose that the planning will be evaluated by software
specialist. I therefore propose not to be too technical, but to stay on a
project manager level. So how about we enumerate the bullets so that we then
can put a project/milestone structure under each one like this (PD: person day):

1.M1 assess open issues and refine planning (1-3 PDs)
1.M2 rebase to current master and adapt to recent changes in gfortran (1-3 PDs)
1.M3 identify missing requirements ... I need input here from Nicolas as I
don't have an overview of what is needed. Therefore I am quite general.

>
> > Or are your targeting a more time based approach like:
> >    Milestone 1: shared mem coarrays merge to master in week 2 of project
> >    Milestone 2: finish research on general way for doing remote coarray
> > access in alien structures to finish in week 1 of project
> >    ...
> Maybe, but I would not emphasize the time constraints that much.

I understand. But for our own planning we need a rough estimate. Therefore
putting numbers to each milestone, will help a lot in planning.

> I have done it below for the scalarizer simplification, which is what
> for which the picture is the most clear in my mind regarding what to do
> and how to do it.
> Here it is, with the expected number of weeks (that's 3 days for me) to
> do it:
>   - Add optional scalarization block. (1 week)
>   - Setup multiple expression usage (in case of multiple loops) in a
> more clear way. (3 weeks)
>   - Move array and loop bounds setup to an opaque "start scalarization"
> function (3 weeks)
>   - Make scalarization independant on previous setup of array
> information and move setup code from "start scalarization" to "finish
> scalarization" (5 weeks)
>   - Initialize array information inside the gfc_conv_expr* functions and
> remove preliminary walking of expressions (4 weeks)
>
> I hope that's not too technical to be put in the application form.

:-) Removing technical speech is not the problem... But I like the plan
although I wouldn't know what to do in each case.

> > Mikael Morin @ ??? -- Maintained/Contributed to the scalarizer. Experienced
> > in gfortran development and component dependencies.
> >
> I'm not affiliated to any company, university or organization.  Just
> myself. :-)

Sorry, I did not mean any insult. What do you prefer? "not affiliated" or
"private", ...?

Regards,
	Andre

--
Andre Vehreschild * Email: vehre ad gmx dot de

Re: Possible funding of gfortran work

[Mikael Morin]

Le 14/06/2023 à 10:28, Andre Vehreschild a écrit :
> Hi Mikael,
> 
> please find my answers inline.
> 
>>> I understand. I would have been happy in the past when a client had as much
>>> knowledge and structure than we already have. Under "Project goal" we now
>>> have about 300 words. So we could add more.
>> Well, It wouldn't be really part of the goal, more how to reach that
>> goal.  The "timeframe" question is possibly where it should go.  Or if
>> you consider that the planning is a goal itself, it could be put here.
> 
> The timeframe question accepts only a number. I.e. we can't plan there.
> 
>>> What do you have in mind?
>> Something that breaks a big, risky thing to a set of smaller, manageable
>> ones.  Something showing that the main problems (or some of them at
>> least) have been identified and that we have a path to solve them one by
>> one.
>>
>>> Like adding
>>> more bullet points to each item in the form of:
>>>     - rebase existing implementation to current master
>>>     - identify missing requirements
>>>     - add tests for missing requirements
>>>     - implement missing requirements to pass tests.
>>>     ...
>> Well, this is a bit too general to be useful.
> 
> Mhh, I don't suppose that the planning will be evaluated by software
> specialist. I therefore propose not to be too technical, but to stay on a
> project manager level. So how about we enumerate the bullets so that we then
> can put a project/milestone structure under each one like this (PD: person day):
> 
> 1.M1 assess open issues and refine planning (1-3 PDs)
> 1.M2 rebase to current master and adapt to recent changes in gfortran (1-3 PDs)
> 1.M3 identify missing requirements ... I need input here from Nicolas as I
> don't have an overview of what is needed. Therefore I am quite general.
> 
OK, let's wait for Nicolas' input, as it sounds scary as is.
Identifying the missing requirements should be done before the 
submission, and saying that you have to do it as part of the project 
sounds very much like you don't know where you are going.
Same goes for the planning, it should already be clear enough beforehand.

I mean, counting the time spent in identifying the requirements etc can 
be done internally, because it's time spent working, but I think it 
should not be part of the planning submitted because it's time that will 
be already spent at the time the application form is submitted.


Regarding my own work, there was no additional discussion regarding the 
different items I proposed, so I will pick the two or three I'm most 
interested in (additionally to the scalarizer) and try to produce a plan 
for them as well.

>>> Mikael Morin @ ??? -- Maintained/Contributed to the scalarizer. Experienced
>>> in gfortran development and component dependencies.
>>>
>> I'm not affiliated to any company, university or organization.  Just
>> myself. :-)
> 
> Sorry, I did not mean any insult.

I didn't see any insult.  I was just trying to answer the three question 
marks (???).

> What do you prefer? "not affiliated" or
> "private", ...?
> 
Yes, that's fine.  Nothing.  Whatever.

Re: Possible funding of gfortran work

[Bernhard Reutner-Fischer]

On 14 June 2023 11:40:06 CEST, Mikael Morin <morin-mikael@orange.fr> wrote:

>> What do you prefer? "not affiliated" or
>> "private", ...?
>> 
>Yes, that's fine.  Nothing.  Whatever.

IMHO that usually would be not applicable / n/a

Re: Possible funding of gfortran work

[Benson Muite]

On 6/1/23 12:18, Andre Vehreschild wrote:
> Hi Damian, all,
> 
> thank you for your input. I have incorporated most of it. Due to Germany
> stepping out of nuclear use, I have reduced the cites on these to a minimum. I
> don't know anything about the people evaluating the proposal and don't want to
> be rejected just because of ideological reasons. Here is the proposal so far.
> Has any one a good url for the FAST project?
> 
> ---
> - Title:
> 
> GFortran-Improvement
> 
> - Abstract:
> 
> Enable the free gfortran compiler to support contemporary language paradigms.
> 
> - Dependencies (on the project as well as projects that depend on the
>   technology; max 300 words)
> 
> Exemplarily these codes make use of language paradigms or want to, but can not
> due to lack of support in gfortran:
> 
> CP2K: https://www.cp2k.org/ -- Quantum chemistry and solid state physics
> ICAR: https://github.com/ncar/icar -- Simplified atmospheric model
> FEATS: https://github.com/sourceryinstitute/feats -- Asynchronous task
> scheduling framework FAVOR:
> https://www.nrc.gov/reading-rm/doc-collections/nuregs/staff/sr1795/index.html
> -- Reactor security NWChem: https://www.nwchem-sw.org/ -- Computational
> chemistry software FUN3D: https://fun3d.larc.nasa.gov/ -- Computational fluid
> dynamics software from NASA MSC NASTRAN:
> https://simulatemore.mscsoftware.com/category/products/msc-nastran/ --
> Structural engineering software from MSC Software WRF:
> https://www.mmm.ucar.edu/models/wrf -- Weather forecasting software from NCAR
> FAST: ??? -- Nuclear fuel performance software from the U.S. Nuclear Regulatory
> Commission (NRC)
> 
Maybe add Quantum Espresso:
https://www.quantum-espresso.org/

R and Octave may also be good examples of use cases.
> Some references:
> 
> Mozdzynski, G., Hamrud, M., & Wedi, N. (2015) A Partitioned Global Address
> Space implementation of the European Centre for Medium Range Weather
> Forecasts Integrated Forecasting System. International Journal of High
> Performance Computing Applications.
> 
> Garain, S., Balsara, D. S., & Reid, J. (2015) Comparing Coarray Fortran
> (CAF) with MPI for several structured mesh PDE applications. Journal of
> Computational Physics.
> 
> Preissl, R., Wichmann, N., Long, B., Shalf, J., Ethier, S., & Koniges, A.
> (2011) Multithreaded global address space communication techniques for
> gyrokinetic fusion applications on ultra-scale platforms. In Proceedings of
> 2011 International Conference for High Performance Computing, Networking,
> Storage and Analysis (p. 78). ACM.
> 
> - Why is it critical to fund this project (300 words max)?
> 
> Fortran remains one of the premier language for science, especially for
> high-performance computing and fields like quantum chemistry or
> computational fluid dynamics.
Perhaps computational chemistry rather than just quantum chemistry.
> 
> gfortran is the default Fortran compiler on many Linux systems, and lack of
> features and bugs in gfortran hinder adoption of more modern, safer and more
> efficient language features. The project has been almost entirely
> volunteer-driven so far, but is currently suffering from a lack of active
> developers for larger features. Funding will enable the project to pay some
> gfortran experienced developers to implement some of the missing/incomplete
> features, that are too large to tackle for a single volunteer. Payed developers
> are to contribute a significant part of the features.
> 
> - Target of the projects in the sense of users (max 300 words)
> 
> This project targets the high-performance computing community, esp. but not
> limited to fluid and thermo dynamics, wheater forecasting and climate models.
wheater->weather
add computational chemistry as well
> Most if not all of those are Fortran codes. Maintaining them using explicit
> parallelism is tedious and deviates from the domain to address. Other users are
> aerospace, e.g. NASA or SpaceX, as well as aircraft and automotive
> manufacturers.
> 
Would expect for aerospace and automotive industry, it would mostly be
for in house codes. Maybe someone for DLR may have input on this?
Having end industry users involved in actively evaluating may be helpful
in sustaining future improvements since they may be willing to support
developer time.
> - How was the project funded in the past (max 300 words)
> 
> Foundational work on the coarray implementation was funded by Sourcery
> Institute. Small extensions and selected bug fixes have been donated by
> companies having a minor impact only. Most of the work was done on a
> voluntary basis.
> 
Some gfortran work has been done as company sponsored in that
individuals using the compiler needed it for company work and could work
on the compiler on company time.  If a large proportion is voluntary and
companies only sponsor small extensions and bug fixes, one might assume
that if the funding is given, once it is finished, the chances of
further work will be very limited.  Maybe one can tie into the GNU
compiler collection as well, emphasizing the longevity of the project
and usefulness of the funding in adding additional capabilities and
cleaning up code contributions. Then indicate that new parts that this
proposal addresses have primarily been voluntary because they are not
yet ready for production use, and this project would make them ready for
production use so that in future maintenance efforts can be made by the
community (both voluntary and sponsored).
> - Project goal (max 900 words!):
> 
> * Fortran has a safe and intuitive method for parallel execution,
>   coarrays. There is currently no complete and efficient implementation for
>   multi-core CPUs on a freely available compiler. The goal is to bring
>   the existing, process-based shared memory implementation on a branch
>   into gfortran mainline as a feature for further evaluation and hardening.
> 
> * GFortran's coarrays for distributed memory lack support for data structures
>   provided by modules that have not been compiled with coarray support (or are
>   distributed in binary form only). Research and prototypical implementation
>   in gfortran and the OpenCoarrays library shall be conducted with the goal to
>   find a general and well performing solution. This could become an outstanding
>   feature for a free compiler.
> 
> * Enhance the support for teams and failed images in coarrays to a level where
>   it gets usable. Teams in coarrays allow for grouping workers logically. These
>   then can colaborate without interference or the user needing to take care.
>   The support is rather basic and shall be made usable to a level where the
>   most popular calls work. The failed images concept allows a program to react
>   on one of its processes failing without terminating the program. The present
>   support shall be extended to enable the restart of the process instead of
>   just reporting the fail and then having to quit anyway as it is currently.
> 
> * Enhance standard compliance from Fortran 2003 onwards. Esp. fixing
>   finalization of partially derived types (PDTs) and issues in the associate
>   command.
> 
> * Ensure maintainability of gfortran by cleaning up/refactoring APIs including
>   the scalarizer. Improve the single responsibility pattern's (SRP) use by,
>   e.g., ensuring the parser does no longer parts of the resolve stage. The goal
>   is not only to separate responsibilities but also to get clearer error
>   messages and with that improve user-friendliness.
> 
> - How many FTEs are you requesting?
> 
> - What is the amount of funding you are requesting, approximately?
> 
> - In what timeframe will you perform the activities?
> 
> - Who (maintainer, contributor, organization) would be most qualified to
>   implement this work/receive the support and why?
> ---
> 
> Any input welcome.
> 
> Regards,
> 	Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de

Re: Possible funding of gfortran work

[Thomas Koenig]

On 01.06.23 13:12, Benson Muite via Fortran wrote:

> R and Octave may also be good examples of use cases.

More generally, Lapack is written in Fortran, and R uses Lapack
(as we found out the hard way with PR 90329).  And Lapack is really
a foundation of linear algebra, which is at the heart of a _lot_
of scientific software.

Re: Possible funding of gfortran work

[Andre Vehreschild]

Hi Thomas,

thanks for the idea. My doctor father will like it, because he is one of the
authors.

- Andre

On Sun, 4 Jun 2023 09:49:51 +0200
Thomas Koenig <tkoenig@netcologne.de> wrote:

> On 01.06.23 13:12, Benson Muite via Fortran wrote:
>
> > R and Octave may also be good examples of use cases.
>
> More generally, Lapack is written in Fortran, and R uses Lapack
> (as we found out the hard way with PR 90329).  And Lapack is really
> a foundation of linear algebra, which is at the heart of a _lot_
> of scientific software.


--
Andre Vehreschild * Email: vehre ad gmx dot de

Re: Possible funding of gfortran work

[Andre Vehreschild]

Hi Benson,

thank you for your input. Comments are inline:

> Maybe add Quantum Espresso:
> https://www.quantum-espresso.org/

done

> R and Octave may also be good examples of use cases.

Mhhh, both are not written in Fortran, right? I don't feel tempted to
include other programming languages into the references list. It feels odd to
me. Any thoughts, anyone?


> Some gfortran work has been done as company sponsored in that
> individuals using the compiler needed it for company work and could work
> on the compiler on company time.  If a large proportion is voluntary and
> companies only sponsor small extensions and bug fixes, one might assume
> that if the funding is given, once it is finished, the chances of
> further work will be very limited.  Maybe one can tie into the GNU
> compiler collection as well, emphasizing the longevity of the project
> and usefulness of the funding in adding additional capabilities and
> cleaning up code contributions. Then indicate that new parts that this
> proposal addresses have primarily been voluntary because they are not
> yet ready for production use, and this project would make them ready for
> production use so that in future maintenance efforts can be made by the
> community (both voluntary and sponsored).

I have added a paragraph about sponsoring of general gfortran work:

GFortran in general stems from a merge of projects that have been supported by
academic research, commercial needs and in large parts volunteers. Funding by
companies was mostly done by allowing employees to work on features required for
the company and donating the code.

Is that what you were trying to add?

Regards,
	Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de

Re: Possible funding of gfortran work

[Thomas Koenig]

On 05.06.23 12:07, Andre Vehreschild wrote:
>> R and Octave may also be good examples of use cases.
> Mhhh, both are not written in Fortran, right?

They are not, but at least R uses Lapack, which is written in Fortran.
And Lapack is about as central to scientific computing as you can
be.

Best regards

	Thomas

Re: Possible funding of gfortran work

[Andre Vehreschild]

I have referenced LAPACK now. I hope this is ok?

- Andre

On Mon, 5 Jun 2023 14:16:43 +0200
Thomas Koenig <tkoenig@netcologne.de> wrote:

> On 05.06.23 12:07, Andre Vehreschild wrote:
> >> R and Octave may also be good examples of use cases.
> > Mhhh, both are not written in Fortran, right?
>
> They are not, but at least R uses Lapack, which is written in Fortran.
> And Lapack is about as central to scientific computing as you can
> be.
>
> Best regards
>
> 	Thomas


--
Andre Vehreschild * Email: vehre ad gmx dot de

Re: Possible funding of gfortran work

[Benson Muite]

On 6/5/23 13:07, Andre Vehreschild wrote:
> Hi Benson,
> 
> thank you for your input. Comments are inline:
> 
>> Maybe add Quantum Espresso:
>> https://www.quantum-espresso.org/
> 
Another code:
https://github.com/openmopac/mopac
currently being supported by
https://molssi.org/

> done
> 
>> R and Octave may also be good examples of use cases.
> 
> Mhhh, both are not written in Fortran, right? I don't feel tempted to
> include other programming languages into the references list. It feels odd to
> me. Any thoughts, anyone?
> 
In addition to use of Lapack, many subroutines are written in Fortran.
They have many users in a variety of sectors.  Path to parallelization
is unclear, even multicore parallelization will benefit many users.
People in these projects may be willing to give input if asked.
> 
>> Some gfortran work has been done as company sponsored in that
>> individuals using the compiler needed it for company work and could work
>> on the compiler on company time.  If a large proportion is voluntary and
>> companies only sponsor small extensions and bug fixes, one might assume
>> that if the funding is given, once it is finished, the chances of
>> further work will be very limited.  Maybe one can tie into the GNU
>> compiler collection as well, emphasizing the longevity of the project
>> and usefulness of the funding in adding additional capabilities and
>> cleaning up code contributions. Then indicate that new parts that this
>> proposal addresses have primarily been voluntary because they are not
>> yet ready for production use, and this project would make them ready for
>> production use so that in future maintenance efforts can be made by the
>> community (both voluntary and sponsored).
> 
> I have added a paragraph about sponsoring of general gfortran work:
> 
> GFortran in general stems from a merge of projects that have been supported by
> academic research, commercial needs and in large parts volunteers. Funding by
> companies was mostly done by allowing employees to work on features required for
> the company and donating the code.
> 
> Is that what you were trying to add?
> 
That seems good. Maybe something like:

GFortran is a portion of the long lived GCC compiler suite and has
gotten contributions due to academic research needs, commercial needs
and volunteer interest.  Industry funding primarily enables employees to
work on features required by the company, for example to support new
processors or ensure performance in a critical company code section.
> Regards,
> 	Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de

Re: Possible funding of gfortran work

[Andre Vehreschild]

Hi Benson,

thanks for the input. I will incorporate it.

Regards,
	Andre

On Thu, 8 Jun 2023 08:34:54 +0300
Benson Muite <benson_muite@emailplus.org> wrote:

> On 6/5/23 13:07, Andre Vehreschild wrote:
> > Hi Benson,
> >
> > thank you for your input. Comments are inline:
> >
> >> Maybe add Quantum Espresso:
> >> https://www.quantum-espresso.org/
> >
> Another code:
> https://github.com/openmopac/mopac
> currently being supported by
> https://molssi.org/
>
> > done
> >
> >> R and Octave may also be good examples of use cases.
> >
> > Mhhh, both are not written in Fortran, right? I don't feel tempted to
> > include other programming languages into the references list. It feels odd
> > to me. Any thoughts, anyone?
> >
> In addition to use of Lapack, many subroutines are written in Fortran.
> They have many users in a variety of sectors.  Path to parallelization
> is unclear, even multicore parallelization will benefit many users.
> People in these projects may be willing to give input if asked.
> >
> >> Some gfortran work has been done as company sponsored in that
> >> individuals using the compiler needed it for company work and could work
> >> on the compiler on company time.  If a large proportion is voluntary and
> >> companies only sponsor small extensions and bug fixes, one might assume
> >> that if the funding is given, once it is finished, the chances of
> >> further work will be very limited.  Maybe one can tie into the GNU
> >> compiler collection as well, emphasizing the longevity of the project
> >> and usefulness of the funding in adding additional capabilities and
> >> cleaning up code contributions. Then indicate that new parts that this
> >> proposal addresses have primarily been voluntary because they are not
> >> yet ready for production use, and this project would make them ready for
> >> production use so that in future maintenance efforts can be made by the
> >> community (both voluntary and sponsored).
> >
> > I have added a paragraph about sponsoring of general gfortran work:
> >
> > GFortran in general stems from a merge of projects that have been supported
> > by academic research, commercial needs and in large parts volunteers.
> > Funding by companies was mostly done by allowing employees to work on
> > features required for the company and donating the code.
> >
> > Is that what you were trying to add?
> >
> That seems good. Maybe something like:
>
> GFortran is a portion of the long lived GCC compiler suite and has
> gotten contributions due to academic research needs, commercial needs
> and volunteer interest.  Industry funding primarily enables employees to
> work on features required by the company, for example to support new
> processors or ensure performance in a critical company code section.
> > Regards,
> > 	Andre
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
>


--
Andre Vehreschild * Email: vehre ad gmx dot de

Re: Possible funding of gfortran work

[Jerry D]

On 6/1/23 2:18 AM, Andre Vehreschild wrote:
> Hi Damian, all,
> 
> thank you for your input. I have incorporated most of it. Due to Germany
> stepping out of nuclear use, I have reduced the cites on these to a minimum. I
> don't know anything about the people evaluating the proposal and don't want to
> be rejected just because of ideological reasons. Here is the proposal so far.
> Has any one a good url for the FAST project?
> 

I found this qhich does use Fortran

https://github.com/OpenFAST/openfast/tree/main/modules/beamdyn/src

Is this the one you were referring to?

Also here:

https://www.nrel.gov/wind/nwtc/openfast.html

Re: Possible funding of gfortran work

[Andre Vehreschild]

Hi Jerry,

thanks. I switched from FAST to OpenFAST in the list of references. Strangely
my google search never pointed me to OpenFAST.

Regards,
	Andre

On Thu, 1 Jun 2023 17:53:21 -0700
Jerry D <jvdelisle2@gmail.com> wrote:

> On 6/1/23 2:18 AM, Andre Vehreschild wrote:
> > Hi Damian, all,
> >
> > thank you for your input. I have incorporated most of it. Due to Germany
> > stepping out of nuclear use, I have reduced the cites on these to a
> > minimum. I don't know anything about the people evaluating the proposal and
> > don't want to be rejected just because of ideological reasons. Here is the
> > proposal so far. Has any one a good url for the FAST project?
> >
>
> I found this qhich does use Fortran
>
> https://github.com/OpenFAST/openfast/tree/main/modules/beamdyn/src
>
> Is this the one you were referring to?
>
> Also here:
>
> https://www.nrel.gov/wind/nwtc/openfast.html
>


--
Andre Vehreschild * Email: vehre ad gmx dot de