I am programming a Fortran module, which is linked to external main program. I can only alter the subroutine. I have to detail a lot of data, but always the same. It takes too much time to do this on every call of the subroutine. How can I initialise the data only at the first call?
Currently, this is the subroutine:
subroutine sdvini(statev,coords,nstatv,ncrds,noel,npt,layer,kspt)
implicit none
integer imdat(100,100,50)
imdat(1,1,1:33)=(/1,8,13,24,48,72,111,148,156,165,182&
&,189,194,207,210,216,236,247,254,270,311,319,339,343,367,376&
&,393,397,421,438,447,473,492/)
.
. lots of data
.
do something
return
end
This setting of values on the first call to a procedure and retaining the values can be performed by explicit initialization. We often use the term initialization, as in this question, to mean an assignment as part of a setting up process. However, initialization means something more precise in Fortran terms.
An explicit initialization suitable for this question would be something like the very simple case
integer, save :: i=1 ! SAVE attribute would be implied, but made explicit
This is like having the assignment applied the first time the procedure is entered.
We can also use a data statement:
integer, save :: i
data i /1/
The SAVE attribute is what ensures that the value persists between entries to the procedure.
For arrays the idea is the same, perhaps using array constructors and reshape.
For very large arrays it is impractical to use data statements or initializers. Further, there are restrictions on what may appear in initializing a saved local variable. However, another idiom would be like
subroutine sub
logical, save :: firsttime=.TRUE.
integer, save :: obj(100,100,50)
if (firsttime) then
obj = ... ! Setting the value somehow, maybe even with a read
firsttime = .FALSE.
end if
end subroutine
Related
I want to create a dynamic variable name using Fortran.
The variable name will be obtained by concatenating a string and another string/integer. Then I want to use this variable name to store a value or another variable.
e.g.
! assign values to 2 variables
my_string = h
my_integer = 1
! perform concatenation resulting in the dynamic variable name, h1
! Set the value of variable h1 to another integer value
h1 = 5
I fear that you will not be able to do this. Fortran requires that variables have names and types at compile time. You (or other SOers) may come up with some kludge to simulate what you want, but it will be a kludge.
Why do you want to do this in Fortran ? There are plenty of languages around which do permit this sort of variable declaration.
EDIT
Well, I thought about it some more, and here's a kludge, unfinished. First a UDT for 'dynamic' variables:
type dynamic_var
character(len=:), allocatable :: label
class(*), allocatable :: value
end type
declare some space for such variables:
type(dynamic_var), dimension(:), allocatable :: run_time_vars
and, working with your original data
allocate(run_time_vars(10)) ! No error checking, reallocate if necessary
! lots of code
write(run_time_vars(1)%label,'(a1,i1)') my_string, my_integer
allocate(run_time_vars(1)%value, source = my_value)
This compiles, but doesn't run and I'm not going to stay long enough to fix it, I'll leave that as an exercise to anyone who cares.
The write to the label field isn't right.
The sourced allocation to the value field doesn't seem to work correctly. Might need to write a 'decode' function to use like this:
allocate(run_time_vars(1)%value, source = decode(my_value))
Like I said, it's a kludge.
I think you want to use a data structure. If you have pairs or groups of values that go together, then create a derived data type which can hold both. There's an explanation on this page:
http://web.mse.uiuc.edu/courses/mse485/comp_info/derived.html
If you have a list of these pairs (like your string and int above), then you can create an array of these types. Example code below taken from the page linked above:
type mytype
integer:: i
real*8 :: a(3)
end type mytype
type (mytype) var
Array:
type (mytype) stuff(3)
var%i = 3
var%a(1) = 4.0d0
stuff(1)%a(2) = 8.0d0
An significant benefit of doing this is that you can pass the pairs/groups of items to functions/subroutines together. This is an important programming principle called Encapsulation, and is used extensively in the Object Oriented programming paradigm.
No, this is not possible in Fortran.
For more information, look into Reflection (computer programming).
Clearly, for reasons given above, this is not legit Fortran (and thus you're going into trouble ...). You may use smart (congrats guys!) kludges, but ...
Instead of using variables h concatenated with 1, 2 or whatever number, why not creating array h(1:N) where N does not have to be known at compilation time : you just have to declare array h as a allocatable.
This is, I think, the legit way in Fortran 90+.
I would like to use deferred-length character strings in a "simple" manner to read user input. The reason that I want to do this is that I do not want to have to declare the size of a character string before knowing how large the user input will be. I know that there are "complicated" ways to do this. For example, the iso_varying_string module can be used: https://www.fortran.com/iso_varying_string.f95. Also, there is a solution here: Fortran Character Input at Undefined Length. However, I was hoping for something as simple, or almost as simple, as the following:
program main
character(len = :), allocatable :: my_string
read(*, '(a)') my_string
write(*,'(a)') my_string
print *, allocated(my_string), len(my_string)
end program
When I run this program, the output is:
./a.out
here is the user input
F 32765
Notice that there is no output from write(*,'(a)') my_string. Why?
Also, my_string has not been allocated. Why?
Why isn't this a simple feature of Fortran? Do other languages have this simple feature? Am I lacking some basic understanding about this issue in general?
vincentjs's answer isn't quite right.
Modern (2003+) Fortran does allow automatic allocation and re-allocation of strings on assignment, so a sequence of statements such as this
character(len=:), allocatable :: string
...
string = 'Hello'
write(*,*)
string = 'my friend'
write(*,*)
string = 'Hello '//string
write(*,*)
is correct and will work as expected and write out 3 strings of different lengths. At least one compiler in widespread use, the Intel Fortran compiler, does not engage 2003 semantics by default so may raise an error on trying to compile this. Refer to the documentation for the setting to use Fortran 2003.
However, this feature is not available when reading a string so you have to resort to the tried and tested (aka old-fashioned if you prefer) approach of declaring a buffer of sufficient size for any input and of then assigning the allocatable variable. Like this:
character(len=long) :: buffer
character(len=:), allocatable :: string
...
read(*,*) buffer
string = trim(buffer)
No, I don't know why the language standard forbids automatic allocation on read, just that it does.
Deferred length character is a Fortran 2003 feature. Note that many of the complicated methods linked to are written against earlier language versions.
With Fortran 2003 support, reading a complete record into a character variable is relatively straight forward. A simple example with very minimal error handling below. Such a procedure only needs to be written once, and can be customized to suit a user's particular requirements.
PROGRAM main
USE, INTRINSIC :: ISO_FORTRAN_ENV, ONLY: INPUT_UNIT
IMPLICIT NONE
CHARACTER(:), ALLOCATABLE :: my_string
CALL read_line(input_unit, my_string)
WRITE (*, "(A)") my_string
PRINT *, ALLOCATED(my_string), LEN(my_string)
CONTAINS
SUBROUTINE read_line(unit, line)
! The unit, connected for formatted input, to read the record from.
INTEGER, INTENT(IN) :: unit
! The contents of the record.
CHARACTER(:), INTENT(OUT), ALLOCATABLE :: line
INTEGER :: stat ! IO statement IOSTAT result.
CHARACTER(256) :: buffer ! Buffer to read a piece of the record.
INTEGER :: size ! Number of characters read from the file.
!***
line = ''
DO
READ (unit, "(A)", ADVANCE='NO', IOSTAT=stat, SIZE=size) buffer
IF (stat > 0) STOP 'Error reading file.'
line = line // buffer(:size)
! An end of record condition or end of file condition stops the loop.
IF (stat < 0) RETURN
END DO
END SUBROUTINE read_line
END PROGRAM main
Deferred length arrays are just that: deferred length. You still need to allocate the size of the array using the allocate statement before you can assign values to it. Once you allocate it, you can't change the size of the array unless you deallocate and then reallocate with a new size. That's why you're getting a debug error.
Fortran does not provide a way to dynamically resize character arrays like the std::string class does in C++, for example. In C++, you could initialize std::string var = "temp", then redefine it to var = "temporary" without any extra work, and this would be valid. This is only possible because the resizing is done behind the scenes by the functions in the std::string class (it doubles the size if the buffer limit is exceeded, which is functionally equivalent to reallocateing with a 2x bigger array).
Practically speaking, the easiest way I've found when dealing with strings in Fortran is to allocate a reasonably large character array that will fit most expected inputs. If the size of the input exceeds the buffer, then simply increase the size of your array by reallocateing with a larger size. Removing trailing white space can be done using trim.
You know that there are "complicated" ways of doing what you want. Rather than address those, I'll answer your first two "why?"s.
Unlike intrinsic assignment a read statement does not have the target variable first allocated to the correct size and type parameters for the thing coming in (if it isn't already like that). Indeed, it is a requirement that the items in an input list be allocated. Fortran 2008, 9.6.3, clearly states:
If an input item or an output item is allocatable, it shall be allocated.
This is the case whether the allocatable variable is a character with deferred length, a variable with other deferred length-type parameters, or an array.
There is another way to declare a character with deferred length: giving it the pointer attribute. This doesn't help you, though, as we also see
If an input item is a pointer, it shall be associated with a definable target ...
Why you have no output from your write statement is related to why you see that the character variable isn't allocated: you haven't followed the requirements of Fortran and so you can't expect the behaviour that isn't specified.
I'll speculate as to why this restriction is here. I see two obvious ways to relax the restriction
allow automatic allocation generally;
allow allocation of a deferred length character.
The second case would be easy:
If an input item or an output item is allocatable, it shall be allocated unless it is a scalar character variable with deferred length.
This, though, is clumsy and such special cases seem against the ethos of the standard as a whole. We'd also need a carefully thought out rule about alloction for this special case.
If we go for the general case for allocation, we'd presumably require that the unallocated effective item is the final effective item in the list:
integer, allocatable :: a(:), b(:)
character(7) :: ifile = '1 2 3 4'
read(ifile,*) a, b
and then we have to worry about
type aaargh(len)
integer, len :: len
integer, dimension(len) :: a, b
end type
type(aaargh), allocatable :: a(:)
character(9) :: ifile = '1 2 3 4 5'
read(ifile,*) a
It gets quite messy very quickly. Which seems like a lot of problems to resolve where there are ways, of varying difficulty, of solving the read problem.
Finally, I'll also note that allocation is possible during a data transfer statement. Although a variable must be allocated (as the rules are now) when appearing in input list components of an allocated variable of derived type needn't be if that effective item is processed by defined input.
NOTE: I'm still investigating this issue - please don't look into it yet - the mistake may be elsewhere
I would like an argument to a subroutine to be OPTIONAL, but that argument also happens to be an assume shape array. When I try to compile the module containing this subroutine, I get the following error:
PGF90-S-0189-Argument number 3 to (routine): association of scalar actual argument to array dummy argument (location)
The routine looks like this:
SUBROUTINE EXAMPLE(A, B, C)
IMPLICIT NONE
INTEGER, INTENT(IN) :: A, B
INTEGER, OPTIONAL, DIMENSION(:), INTENT(IN) :: C
INTEGER :: TEST
IF (PRESENT(C)) THEN
TEST=C(1)
PRINT *,TEST
ELSE
PRINT *,A,B
ENDIF
END SUBROUTINE EXAMPLE
It is contained within a module. I get the error when I try to call it with only two arguments from a subroutine which is USEing the module.
I have only found one possibly related question on the Portland Group forums here:
http://www.pgroup.com/userforum/viewtopic.php?t=624&sid=d76fdf8ca2bf4fc3109f4f49b1de0ad7
The answer boils down to the user using an optional argument which has not been allocated - I don't know if this applies in my case as I'm not using 'C' outside of the IF(PRESENT(C)) block, but could there be an implicit allocation going on when defining a variable as assumed shape, which cannot be carried out when it is not passed in the first place?
This problem is now resolved - you can indeed use assumed shape arrays as optional arguments. As pointed out in the comments - the error stemmed from an old version of a source file which was not being regenerated by a pre-processing step due to a bug. As a result, the call was not what I thought it was - it actually contained a single integer as the third argument.
Thanks for the help all.
I hope everyone's doing good. I presently have a project at work and I'm having a hard time dealing with some programming techniques.
To summarize my project, I have to modify some codes on Fortran so that it can be adapted to be used on a simulation software called PRO/II. All the functions and subroutines have already been written.
However, to make the codes compatible with PRO/II, I have to change the way of assigning some input data (input by the user himself) on Fortran. In fact, before, the user entered the data on a text file which was then read by a fortran subroutine.
However, now, the data is input in the simulation software directly. I managed to write a code to record all the input data in a subroutine. But when the simulation is ran on PRO/II, it only attributes the input data to the "MAIN SUBROUTINE". The values are not accessible to any functions or subroutines outside the main subroutine. In fact, PRO/II gives the values to the arguments of my main subroutine only.
As from there, when a function is called from the main subroutine, there's no problem. It's the function that calls other functions or subroutines that are the issues. I'll try to make myself as clear as possible. So let's say I have a subroutine X and many functions and subroutines as follows:
Subroutine X
End Subroutine
Function A(variables)
Uses Functions B and C
End Function
Function B(variables)
Uses Function D and E
End Function
Function C(variables)
Uses functions D and E
End Function
Function D(variables)
End function
Function D(variables)
End Function
Function E(variables)
End Function
So, the problem is that the values I calculated in my main subroutine or the values I input in PRO/II which are transmitted to the Fortran program are not accessible to functions D and E. So, I tried copying all the values needed to a text file from the main subroutine and reading all the values each time by the different functions and subroutines. But it's taking forever for the simulation to run by PRO/II. I have like 80 functions and 20 subroutines, and each time they are called, they open the text file to read the values.
Is there a way for me to have the values read by all functions and subroutines without having to read from the text file? In other words, is there a way to make all the variables I've calculated in my main subroutine to every function and subroutine in my program?
I'm really having a hard time figuring that out.
If you guys don't understand the problem or have any questions, please let me know.
Thanks in advance for your help guys.
You could put your values into variables in a module, and use that module in all functions and subroutines, as well as in the main program!
Here is a small example:
module globVar
implicit none
integer :: var1
end module
module calculus
contains
function doStuff(input)
use globVar, only: var1
implicit none
integer,intent(in) :: input
integer :: doStuff
doStuff = input*var1
end function
end module calculus
program test
use globVar
use calculus
implicit none
write(*,*) 'Enter "var1"'
read *,var1
write(*,*) doStuff(2)
end program
I'm working with fortran subroutines of a finite element analysis program. I have to share variables between the two subroutines so I'm using COMMON blocks (EDIT: module is better). The problem is that only some of the variables are passed to the other subroutine, others are not.
My code is like this:
First subroutine:
real knom, krot
COMMON /kVAR/ kmom, krot
SAVE /kVAR/
Second subroutine I use the same syntax. I'm controlling the results by writing kmom and krot values in each subroutine to a txt file:
write(6,*) 'I am in URDFIL', or 'I am in UFIELD'
1 KINC, kmom, krot
The results are:
I am in URDFIL 1 -16700 -2.3857285E-03
I am in UFIELD 2 -16700 -1155769886
So the value of krot is lost. Any advise is most welcome.
João
Solved:
module shared_var
implicit none
real*8 kmom, krot
save
end module shared_var
And in each subroutine:
use shared_var
Did you include the declaration of knom, krot in the second routine? Probably you are getting implicit typing and krot is being output as an integer. And it appears that you have a typo: knom versus kmom. That is why kmom is output as an integer in both cases -- implicit typing as an integer since knom is the real. If implicit typing is in effect these variables will be integers since they begin with "k". My strong recommendation is to not use implicit typing unless it is too much work to remove from legacy code. It is highly recommended to use "implicit none" so that the compiler will warn you if you forget to type a variable or make a typo in a variable name. Most compilers have options that are equivalent to "implicit none".