Tweeting Fortran

21

I have revived @FortranTip after letting it be dormant since June 2022 and plan to tweet at a frequency between daily and weekly. Several tweets have been “ripped from the [Fortran Discourse] headlines”. If you think a Fortran project would be of wide interest and has not been mentioned yet, please post here or message me. For example, projects for plotting, automatic differentiation, numerical optimization, and machine learning could be covered.

Before I was mostly tweeting about features of the Fortran language, but I need to learn about newer features like coarrays before tweeting about them. It will be fun to post about Fortran 2023 features as they become available in compilers.

9 Likes
22

I choose not to give any more cycles to Xitter than are absolutely necessary. There’s quite a sizable Fortran/HPC community on Mastodon, with the mast.hpc.social server being popular.

4 Likes
24

(Redacted)

4 Likes
25

Twitter now is very hard to use if you’re not logged in. I dont know if it’s common knowledge or not: you can replace twitter.com with nitter.net and get a mirror that works better, ie https://nitter.net/fortrantip

4 Likes
26

Thanks a lot!

Indeed, I think the bird has lost a lot of visibility (a shoot in the foot…).

Nice black hole simulation on top! Good Fortran imagery…

27

May I recommend the modernised *pack packages by @jacobwilliams and PRIMA? Thank you.

2 Likes
28

Very useful. Thanks for creating this collection of tips. It would have saved me countless hours.
Here are my two cents to the topic. Among the tips that would have been useful to me I can site:

  • Variable initialization and default save (these refs were very useful Gotchas and Better save than sorry)
  • UDDTIO
  • Reshaping with pointers (the example is not from me but I found it very clear)
integer, parameter :: N = 3
integer, target :: dat(N*N)
integer, pointer :: mat(:,:)
integer, pointer :: diag(:)
dat = [( i, i=1,size(dat) )]
mat(1:N,1:N) => dat
diag => dat(1::N+1)
print *, "Matrix:"
do i = 1, size(mat,dim=1)
  print "(*(g0,1x))", mat(:,i)
end do
diag => dat(1::N+1)
print *, "Diagonal elements: ", diag
  • Difference between type and class (here again a reference by @sblionel that was enlightening: Not my type)
  • Casting assumed rank to array using c_loc and c_f_pointer
integer(int32), intent(in), target, contiguous :: actual(..) 
integer(int32), pointer                        :: actual_array(:)
call c_f_pointer(c_loc(actual), actual_array, [size(actual)])
  • Null terminated string when binding with C
  • Safe size() with non allocataed array
merge(size(this%items), 0, allocated(this%items))
29

And I do not know if you consider preprocessing has an intrinsic part of the language, but I had a deep dive into fpp recently and here is what I found out:
Gotchas

  • Only named variables can be substituted:
#define f(x) sqrt(x)
f([1.0d0, 2.0d0]) !does not work
!but
x = [1.0d0, 2.0d0]
f(x) !works
  • Even commented defined macros are substituted:
!f(x) will be changed to !sqrt(x)

Trick
Macro can be used to simulate array accessor. Since arrays in fortran require all the elements to have the same size it is quite common to use a wrapper. The most common case is probably the use of array of deferred length strings:

type string_t
   character(:), allocatable :: string
end type

type(string_t), allocatable :: strings(:)
allocate(strings(2))
strings(1)%string = "string"
strings(2)%string = "another string"

Being familiar with other languages I would have love to see the possibility to overload array accessor of derived types (i.e. having strings(1) = “string”). It’s not perfect but this can be mimicked with a macro

#define s(i) strings(i)%string
30

I think this one is dangerous (and likely not standard conforming). If actual(..) is a non-contiguous array, then actual_array(:) won’t access the right elements.

31

I agree, it should come with a big warning (or not been discussed at all). But i still found it useful in my case because it transforms rank(0) to a rank(1)-array and then I only deal with arrays.

32

At least, actual(..) should be declared with the contiguous attribute to make this safer.

1 Like
33

This is very true. So, for those of us who are not (mandarin-pronounced) Xitting, why couldn’t the FortranTips appear also on our Discourse, as a separate topic, possibly w/o comments allowed, or very limited?

34

As I wrote earlier, many FortranTips will be based on discussions here, in which case it will be redundant to post them. Today I did tweet an independent tip –

John Levesque spoke about Using the HPE Cray Programming Environment to Port and Optimize Applications to a GPU environment, with slides here.

35

Sure, but having them together, with examples, in compact form, would IMHO be a bonus for non-Xitters.

36

@zmoon created the FortranTip — FortranTip Browser . The codes and an index of tweets are at the associated GitHub repo.

3 Likes
37

I’ve been there but the codes are not necessarily linked to particular tip, rather being linked to X

38

Some tools can be used to automatically redirect tweets to Mastodon:

Does it still work with all the events the blue bird endured in 2023? I don’t know.

39

I’m happy to repost Fortran Tips from my DoctorFortran Mastodon account, if that would be acceptable.

5 Likes
40

Please go ahead – thanks.

41

If anyone’s interested in giving Fortran a bit more presence on Bluesky, as another alternative to Xitter, I’ve got a few invite codes going spare…