The way to do this in portable Fortran is by using “do concurrent” and possibly extend Fortran to specify memory layout for an array. It’s unclear to me if we also have to extend it to specify where the array lives (device/host), as the differences might be disappearing (unified memory, etc.).
The fact that you currently can’t do it is because Fortran compilers are not very good at taking advantage of what Fortran offers. But that is what we need to improve. Specifically, one should not (in my opinion) be using openmp/openacc and compiler directives. One should just be using native Fortran constructs. I agree that currently you essentially have to use openmp, but we need to improve the compilers.
I did not write that it is only doing well because of that. I didn’t even write “doing well”. The paragraph you quoted was part my post explaining why I think using “life support” is inaccurate. I don’t use the phrase “doing well” because it’s meaningless until you define what it means. So I’d rather just write how I see things concretely–as I did in the top-level post–than use vague metaphors as “life support” and “doing well” that are meaningless on their own and only confuse the conversation. It was my mistake to write a “poem”, and I apologize for it, which of course, when taken as black or white will be misunderstood.
Is a technology “doing well” because there’s no better solution for the problem? Maybe yes, maybe no. Until you define what you mean it’s impossible to tell.
Yes, you can call it lock-in and I can call it legacy value. If that’s the only value, it’s not good. But I never wrote that’s the only value. Many teams choose Fortran because it’s the optimal solution available for their problem. In that context I think lock-in and legacy are a very good thing.
Many people are also locked into Python. I certainly am. It’s been my daily workhorse since 2010. I don’t like Python, but I love that it has NumPy+SciPy+matplotlib+networking. Is this lock-in a bad thing? Maybe yes, maybe no. It’s good for Python. I’m not happy with Python but it gets my work done. I’ve tried Julia every year since 2012 and it hasn’t clicked for me just yet.
From my perception of my own field (and I can’t comment for others but trust everybody here about their perceptions of their own fields) I think that’s inaccurate. Specifically the “identical to other fields” part. In many fields where Fortran used to have a large share I hear from you and others here that that is rapidly shrinking. In weather, ocean, and climate modeling it is not, I estimate that it remains at > 99%. You can call this “doing well” or “not doing well”, but for me that’s not useful at all. I’d rather just say concretely what I see and how I see it (again, see my top-level post).
Thanks Milan for the clarification of your view points. I agree that “doing well” is subjective. That is what I like about it, as it helps to communicate whether the person saying it (say, myself) views the situation as needing help, or in good shape. So that is why I use it.
Around me I have subjectively determined that Fortran is not doing well (I have expanded many times on this site exactly what I mean by that, but I am happy to do it again if it is not clear). I’ve been trying to figure out if Fortran is “doing well” (in my own subjective definition) in your field, and I have still not figured it out. Your very first post I read as “not doing well” (in my own subjective definition), and your third post as “doing relatively well” (in my own subjective definition), so I am just personally confused.
Anyway, it’s not important, we can discuss it some other time. For now I am withholding judgement.
It’s both, and my two posts referred to two different things. The first post was about the WWC enterprise as a whole which is very broad. The third post is my second response to your question about “weather modeling” which is but a small subset and a number-crunching component of WWC. Perhaps that can explain the confusion in part or in whole.
Okay, great, I’m happy we cleared that up. @RobertPincus gave a very eloquent answer about Fortran in weather modeling, and my top-level post and the linked report addresses the whole WWC enterprise. And in weather modeling where Fortran remains >99% of source code and CPU time share and projects are being actively developed, the issues that I listed above (difficult to hire, difficult to port to different architectures) still remain.
The language preferred by recent graduates from college tends to be the one they were taught in their CS class. These days it’s Python. In previous years it has been Java, C++, Pascal, … for the same reasons. Next year it might be Julia.
For the process of developing a weather code, a language like Python has the drawback of being unstable (newer generations being not compatible with older ones), and also the risk of becoming another Pascal If you are choosing a language for a project that will last for decades, Fortran is a much better choice. Previously written code continues to work, and it is relatively easy to learn (especially for anyone you should be trusting with writing weather and climate codes).
