I have a fortran program like this,
program test
integer,parameter :: f=selected_real_kind(20)
Real(kind=f)::b1,b2,c1,v,xd,xe,res
b1=1._f
b2=0.5_f
v=1._f/3._f
c1=0.25_f
xd=0.2_f
xe=1._f/6._f
res= "extremely large expressions"
write(*,*) res
end program
res is just a very large expression, which is more than 50000 lines. And I cannot compile this program using gfortran compiler. The error reason is, out of memory allocating 65536 bytes
Any suggestions are welcome. Thanks!
Related
I'm extremely new to both working on Linux and Fortran, so apologies if this is a basic question.
I am trying to firstly use fwrite to save a 60x150 array that I've produced in MATLAB as a binary file, which I am then attempting to load and read in Fortran as a 60x150 array again.
In Matlab, I have used the following code to save the array. In this case the name of the array in the workspace is VP, and I'm saving it to a file also called 'VP':
>> fileID = fopen('VP','w');
>> fwrite(fileID,VP,'real*8');
>> fclose(fileID)
Next, I am copying the file over from Windows to a linux ssh server (I'm not sure if this is relevant, but thought it's worth including anything that might help).
Now, in my Fortran code, I've got:
REAL(KIND=kind(1.0D0)), DIMENSION(60,150) :: VP
...
open(unit, file="LOCATION/VP", access = "stream", form = "unformatted", iostat = stat)
if(stat /= 0) labort("Failed to open input file")
print *, wl
DO inx2=1,60
DO inx=1,150
print *,inx
READ(unit,*) VP(inx2,inx)
ENDDO
ENDDO
print *,VP(1:10,1)
Now, when I compile this there are no errors. However, when I run it, it gets to exactly the first "READ(unit,*) VP(inx2,inx)" before failing (you can tell from the print just before it).
I get the error:
forrtl: severe (257): formatted I/O to unit open for unformatted transfers, unit 111, file LOCATION/VP
Obviously I would like my actual result to be the function running and ending up with the same values in the array.
Now I've seen the question before, specifically for this error message, but that was answered by including access="stream" which I have already. Basically I am not sure at what point I am getting something wrong in this process, any help would be appreciated.
Note some things I have tried is changing the precision in fwrite, and swapping the inx2 and inx values around (but it fails on the first one so I don't believe that's the error).
Again this might be just a fundamental issue with my understanding of Fortran because I've been thrown in the deep end a bit with a project I'm working on (most of the code I'm running was produced by someone else, I'm just trying to edit a small part of it).
Edit:
Okay, thank you so much francescalus! He found the solution was to edit the line to READ(unit) VP(inx2,inx) in order to get it to run. However, the values I get by running the next line of code:
print *,VP(1:10,1)
Only the first value matches the first value in my original matlab array. Displaying VP(1:5,1:5) of the matlab array there aren't any other matching values. I might be able to figure this out on my own but as I'm already here I might as well ask as I haven't fully completed the original question (although got over a big hurdle!).
Edit 2:
Okay the next bit I've managed to figure out for myself. If anyone is searching though it was simply a case of swapping the DO loops. ie
DO inx=1,150
DO inx2=1,60
print *,inx
READ(unit,*) VP(inx2,inx)
ENDDO
ENDDO
Thanks for the help.
In the Fortran program, is it possible to read an expression including the variables ?
For example, the input file is （if necessary, we can change the input form of the expression,e.g.,the binary form）,
2(a-4b)
It should be noted that the input expression has a very simple form and it only contains integer or fraction or some variables,like the following in the list,
{0,232,-2/5a,3a-b,b/9}
Here 2a means 2*a
The Fortran program is
Program test
implicit none
real(kind=8)::a,b,exp
a=10.
b=3.
! open file and read the input expression
! that is, exp=2*(a-4*b)
write(*,*) exp ! we can get exp=-4.0
end program
For the complicated expressions, it is obviously not a good idea for Fortran. I just want to know, in this simple input expression case, is it possible to find a better way ?
A site with tests of three expression evaluators in Fortran is http://www.angelfire.com/ab5/extensao/report.htm . Only the link to the "Brazilian" one works.
There is also a Sourceforge project fparser http://fparser.sourceforge.net/ .
Fortran cannot do this unless you write code that can parse the arbitrary expression, substitute and solve, which is a bit of work (see the comment below for details). Fortran is compiled and there is no way to load source on the fly, compile and run it, which is essentially what you are asking. You might look into a language such as Lisp where doing this is should be somewhat trivial. Likewise any scripted language will have facilities to evaluate code, which can do what you are asking.
Is there a standard(ish) way for a Perl interpreter (aka "perl") to behave when it runs out of memory? Is it documented/specced-out in any way? Coded in some uniform way?
I'm especially interested in any standards which are expressed as covenant to Perl code being run - e.g., will die be called? Will END block be executed? Etc...
I'm fine with both an "theoretical" answer (e.g. some sort of generic "this is what perl code ought to do in general on out-of-memory" mission statement document from Larry/P5P/etc..., even if not 100% of malloc() calls follow this rule); or a "practical" statement (e.g. all malloc() calls in Perl are wrapped into a generic "allocate_memory" function which uniformly handles all failures).
It may be possible that the answer depends on what specifically causes out of memory (e.g. a request for more memory for Perl code's data structure vs. memory allocated by internal Perl code unrelated to explicit "need to store more data" logic in Perl program).
If the answer is extremely implementation dependent, assume perl for Solaris/Linux,and narrowing down to any recent stable version (5.8 to 5.16) is acceptable.
The question is limited to standard Perl interpreter, however you wish to define that as far as pre-compile configuration (e.g. perl that comes with a major Linux distribution, or one compiled with all defaults left alone, etc...).
NOTE: This question came out of Gilles's comment to another Q
Taking a look at the manual page for the various diagnostic warnings that Perl will issue when the "use diagnostics" pragma is enabled, you can see various different types of "out of memory" errors and what they mean.
So you can infer the "standard" behavior from these messages; the one with an exclamation point ("Out of memory!") sounds like the one you're asking about:
Out of memory!
(X) The malloc() function returned 0, indicating there was
insufficient remaining memory (or virtual memory) to satisfy the
request. Perl has no option but to exit immediately.
An "X" level error is labeled as "A very fatal error (nontrappable)."
However if it's a "large request" (for greater than 64K) it is trappable (I guess Perl assumes it'll have enough memory to shutdown cleanly).
I am new to the site, and this looks like it may be a place to get some tips and help if any.
I am learning about "C calling Fortran subroutine", I have knowledge with C but not too much with Fortran.
Plus side: I've looked at some examples, and was able to compile a few.
Negative side: I am somewhat lost. I have a main program which can be designed using C or Fortran 90, and print_matrix.f and print_matrix.c.
Within the main.c program,
- populate array of 1-9 of a matrix size 3 by 3
- call the c function
- call the fortran subrountine
I already have the populated side(it may not be accurate), but I am stuck on the subrountine. The output of fortran and C has to be the same which will output through the print_matrix.f90 and print_matrix.c using makefile. I need help with the calling subrountine part, I just don't know where to begin with that :(
I just need help, any will be appreciated.
Honestly, it's a little hard to tell exactly what your problem is. But here's an example that works on my linux machine:
callf.c:
#include<stdio.h>
int main(int argc, char **argv) {
int i=0;
increment_(&i);
printf("%d\n",i);
return;
}
increment.f90:
subroutine increment(n)
integer n
n=n+1
return
end subroutine
Compiled with:
gcc -c callf.c
gfortran -c increment.f90
gcc callf.o increment.o -lgfortran
Result:
> ./a.out
1
The two hard parts are 1) getting the exact name of the function call and 2) knowing what flags are needed to link the two codes. Re: 1) I knew to use "increment_" because, after compiling my FORTRAN code, I ran the "nm" utility on increment.o and found the name of the object was "increment_". On some systems, you might see "INCREMENT", "_increment", or all sorts of other things. Re: 2) Information should be available for whatever compiler you are using. It varies alot.
I was encountered with usage of function eval(expression) in somebody else's code in matlab:
for example:
for n = 1 : 4
sn = int2str( n) ;
eval( [ 'saveas( fig' sn ', [ sName' sn ' ], ''fig'' ) ' ] );
end
MathWorks stuff in Matlab Help pointed out that:
Many common uses of the eval function are less efficient and are more difficult to read and debug than other MATLAB functions and language constructs.
After this, I find usage of this function in many other program languages, so as Python, JavaScript, PHP.
So I have a few questions:
Will usage of this function be enfluenced on the performance of my code?
If it will slow down execution, why does it occur?
If it slow down execution every time when called, what reason for use this function in principle?
The eval function is dangerous and there are very few examples where you actually need it. For example, the code you gave can easily be rewritten if you store the figure handles in an array fig(1), fig(2) etc and write
for n = 1:4
filename = sprintf('sName%d', n);
saveas(fig(n), filename, 'fig');
end
which is clearer, uses fewer characters, can be analysed by the Matlab editor's linter, is more easily modifiable if (when) you need to extend the code, and is less prone to weird bugs.
As a rule of thumb, you should never use eval in any language unless you really know what you are doing (i.e. you are writing a complicated Lisp macro or something else equivalent to manipulating the AST of the language - if you don't know what that means, you probably don't need to use eval).
There are almost always clearer, more efficient and less dangerous ways to achieve the same result. Often, a call to eval can be replaced with some form of recursion, a higher-order function or a loop.
Using eval here will certainly be slower than a non-eval version, but most likely it won't be a bottleneck in you code. However, the performance is only one issue, maintenance (incl. debugging), as well as readability are other ones.
The slowdown occurs because Matlab uses a JIT compiler, and eval lines cannot be optimized.
Eval use is in most cases due to lack of knowledge about the Matlab functionality that would be appropriate instead. In this particular case, the issue is that the figure handles are stored in variable names called fig1 through fig4. If they had been stored in an array called fig, i.e. fig(1) etc, eval would have been unnecessary.
EDIT Here are two excellent articles by Loren Shure about why eval should be avoided in Matlab. Evading eval, and More on eval.
For the most part, the slowdown occurs because the string has to be parsed into actual code. This isn't such a major issue if used sparingly, but if you ever find yourself using it in code that loops (either an explicit loop or things like JavaScript's setInterval()) then you're in for a major performance drop.
Common uses I've seen for eval that could be done better are:
Accessing property names in the ignorance of [] notation
Calling functions based on an argument name, which could instead be done with a switch (safer, prevents risk of code injection)
Accessing variables named like var1, var2, var3 when they should be arrays instead
To be honest, I don't think I've ever encountered a single situation where eval is the only way to solve a problem. I guess you could liken it to goto in that it's a substitute for program structure, or useful as a temporary solution to test a program before spending the time making it work optimally.
Here is another implication:
When you compile a program that uses eval, you must put pragmas that tell the compiler that some functions are needed. For example:
This code will compile and run well:
foo()
But this one needs a pragma added:
%#function foo
eval('foo()')
Otherwise you will encounter a runtime problem.