forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Fortran 2003 and 2008 features
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9, 10
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Suggestions
View previous topic :: View next topic  
Author Message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7772
Location: Salford, UK

PostPosted: Wed Nov 30, 2022 2:11 pm    Post subject: Reply with quote

simon

The SOURCE keyword (Fortran 2003) for the ALLOCATE statement has now been implemented (for arrays only) and will included in the next release of FTN95.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7772
Location: Salford, UK

PostPosted: Mon Dec 05, 2022 9:47 am    Post subject: Reply with quote

All of the new 2003 and 2008 features that have been suggested on this thread have now been implemented (at least for the next release of FTN95) with the exception of ASSOCIATE.

Further suggestions are welcome so that the order of implementation can be prioritised, implementing first those features that our users would find most helpful.

Since this thread is now rather long, please start a new post for any further suggestions of this kind.

ASSOCIATE currently has a low priority. FTN95 users who understand and want to employ this feature should present a case for its early implementation.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2777
Location: South Pole, Antarctica

PostPosted: Tue Dec 06, 2022 12:28 am    Post subject: Reply with quote

So soon this compiler will join this six-pack list to compile this widely used F2003 code of your neighbor university? Here is its Makefile:


Code:
# Specify a particular compiler with "make COMPILER=pgi", etc.
# Specify debugging flags with "make MODE=debug"
# If floating-point consistency is required then set the flag "CONS=1"
# Alternatively, these options can be specified as environment variables
# eg. "export COMPILER=gfortran" can be added to $HOME/.bashrc

# Compiler specific flags

# PGI
# ===
ifeq ($(strip $(COMPILER)),pgi)
  FFLAGS = -r8 -fast -fastsse -O3 -Mipa=fast,inline -Minfo # Optimised

# Intel
# =====
ifeq ($(strip $(COMPILER)),intel)
  FFLAGS = -O3 -g -stand f03

# gfortran
# ========
ifeq ($(strip $(COMPILER)),gfortran)
  FFLAGS = -O3 -g -std=f2003

# g95
# ========
ifeq ($(strip $(COMPILER)),g95)
  FFLAGS = -O3

# IBM Bluegene
# ============
ifeq ($(strip $(COMPILER)),ibm)
  FFLAGS = -O5 -qhot -qipa # Optimised
  # IBM compiler needs a -WF to recognise preprocessor directives
  D = -WF,-D
endif

# ARCHER (also works for HECToR)
# ========
ifeq ($(strip $(COMPILER)),archer)
  FFLAGS = -O3 -hipa2

# The following are a list of pre-processor defines which can be added to
# the above line modifying the code behaviour at compile time.

# Set every pseudoparticle in a species to represent the same number of
# real particles.
#DEFINES += $(D)PER_SPECIES_WEIGHT

# Use second order particle weighting (default is third order).
#DEFINES += $(D)PARTICLE_SHAPE_TOPHAT

# Use fifth order particle weighting (default is third order).
#DEFINES += $(D)PARTICLE_SHAPE_BSPLINE3


https://github.com/Warwick-Plasma/epoch

I think the best way to decide which new Standard's features to add is to compile broadly used modern codes. Only this will widen the pool of new customers because it will ensure that the compiler is future proof and hence it will be appealing to the younger generation.

By the way all these compilers despite support of the 2003-2008 features either not heard of any debuggers in Linux or use debuggers which are not far from punchcards era . You waste 10x more time with them making your code working. With this code I started my attempts to modify it to my needs in January and only now succeeded with gFortran.

Due to the same problem of absence of good debuggers on all other compilers and the fact that FTN95 was not compiling another large and pretty brain breaking code which has exactly this ASSOCIATE feature i failed so far to get through this another PIC code. It is even not clear if this F2003 feature was really necessary but it was among things which stopped the code to compile.

https://gitlab.com/MD-CWI-NL/afivo-pic

With the debugger like SDBG you would just get through the running code step by step and get everything in one day. Without debuggers in some cases you will be getting stuck like in an encrypted web. And learning new complex language features without debuggers is a pure hell.

It is obvious that ALL 15 and 20 years old Standard's features have to be implemented. What the point to implement only part of existing Standards ? Imagine some arbitrary compiler which only supports part of F2018 Standard, part of F2008 Standard, part of F2003, part of F1995, part of F1977, part of F1966 then it will essentially run just the Fortran4 codes gathering around only appropriate declining legacy codes public.
Back to top
View user's profile Send private message
Kenneth_Smith



Joined: 18 May 2012
Posts: 682
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Thu Jan 05, 2023 12:42 pm    Post subject: Reply with quote

Paul, One to look at when you get the opportunity (a very minor issue).
Code:
complex z1
z1%re = 3.0 ; z1%im = 4.0
end

The Compiler says (Ver 8.95): "Warning 298 - Variable Z1 has been used without being given an initial value", which is not true in this case.
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7772
Location: Salford, UK

PostPosted: Thu Jan 05, 2023 1:53 pm    Post subject: Reply with quote

OK. Thanks.
Back to top
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1840

PostPosted: Thu Jan 05, 2023 4:24 pm    Post subject: Reply with quote

There is at least one more situation where a similar spurious warning is given -- parts of expressions wherein a variable name is required by the language rules but only the type of the variable matters. Here is an example:

Code:
program test

REAL    :: R4
Integer :: I4R

data I4R/Z'3F800000'/

print *,transfer(I4R,R4)

end program


The compiler warns that R4 is used without being given an initial value.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7772
Location: Salford, UK

PostPosted: Thu Jan 05, 2023 5:34 pm    Post subject: Reply with quote

mecej4

I will make a note of this.
Back to top
View user's profile Send private message AIM Address
simon



Joined: 05 Jul 2006
Posts: 268

PostPosted: Mon Feb 06, 2023 7:06 pm    Post subject: Reply with quote

I was pleased to see that Source= has become available for the allocate statement. But when I get a rather unclear error message for the following code:

Code:
Module m
   Integer, Dimension(:), Allocatable :: a
   Integer, Dimension(5)              :: b
End Module m
!
Program p
   Use m
   Allocate (a, Source=b)
End Program p


When the documentation qualifies "for arrays only" what exactly does that mean?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7772
Location: Salford, UK

PostPosted: Tue Feb 07, 2023 8:51 am    Post subject: Reply with quote

Simon

Your code reveals a bug in the new FTN95 feature. At the moment it doesn't work when the arrays are declared in a module. I will log this as a bug that needs fixing.

The new feature has not yet been programmed for scalars so the following code will fail at runtime.

Code:
   integer,allocatable::a
   integer::b
   b = 7
   Allocate(a, source=b)
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7772
Location: Salford, UK

PostPosted: Tue Feb 07, 2023 9:28 am    Post subject: Reply with quote

Simon

The failure for arrays declared in a module has now been fixed for the next release of FTN95.
Back to top
View user's profile Send private message AIM Address
simon



Joined: 05 Jul 2006
Posts: 268

PostPosted: Tue Feb 28, 2023 9:06 pm    Post subject: Reply with quote

Could we please get Nint, Aint and Anint added to the list of intrinsic functions that can be used in an initialisation expression.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7772
Location: Salford, UK

PostPosted: Wed Mar 01, 2023 9:07 am    Post subject: Reply with quote

Simon

Thanks. These have now been added for the next release of FTN95.
Back to top
View user's profile Send private message AIM Address
Kenneth_Smith



Joined: 18 May 2012
Posts: 682
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Fri Mar 24, 2023 12:42 pm    Post subject: Reply with quote

Earlier in this discussion we talked about exactly what the ASSOCIATE construct does.

Following its recent addition to FTN95, the program below which uses the trapezoidal method to integrate a set of data points can now be compiled successfully and run.

I find the *three* lines of code that define the trapezoidal method rather mind blowing!

An very interesting and educational example, which I thought was worth sharing.

Code:
  program p
  implicit none
  integer, parameter :: n = 101
  double precision x(n), y(n), r1(n), omega
  integer i
  omega = 2.d0*4.d0*atan(1.d0)*50.d0
  forall (i=1:n) x(i)  = (i-1)/5000.d0                  ! x
  forall (i=1:n) y(i)  = cos(omega*x(i))                ! f(x)
  forall (i=1:n) r1(i) = integrate(x(1:i),y(1:i))       ! Integral of f(x).dx
  r1 = omega*r1                                         ! Normalise integral
  i  = winio@('%pl[native,frame,x_array,n_graphs=1,width=2,y_max=1,Title="f(x)"]&', 600,300,n,x,y)
  i  = winio@('%ff&')
  i  = winio@('%pl[native,frame,x_array,n_graphs=1,width=2,y_max=1,Title="Omega * Integral of f(x)"]', 600,300,n,x,r1)
 
  contains
 
    pure function integrate(x, y) result(r)
    !! Calculates the integral of an array y with respect to x using the trapezoid
    !! approximation. Note that the mesh spacing of x does not have to be uniform.
    !!
    !! Source: https://fortranwiki.org/fortran/show/integration
    !!
    double precision, intent(in)  :: x(:)         !! Variable x
    double precision, intent(in)  :: y(size(x))   !! Function y(x)
    double precision              :: r            !! Integral y(x)dx
    ! Integrate using the trapezoidal rule
    associate(n => size(x))
      r = sum((y(1+1:n-0) + y(1+0:n-1))*(x(1+1:n-0) - x(1+0:n-1)))/2.d0
    end associate
  end function
 
  end program p
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Suggestions All times are GMT + 1 Hour
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9, 10
Page 10 of 10

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group