Fortran Basics
in [Fortran]
|
From: mecej4 on 27 May 2010 07:57 baalzamon.moridin wrote: > There are some general shortcomings with the original code; output > format etc. > Today I shall look into mex stuff. If anything I shall recreate the > main program and some of the intial subroutines > in matlab and then call some of the horrid code in - like the one with > the assigns, as well as the routines such as > DAXPY etc. Ultimately, at the moment I use the fortran exe, which > generates text files, that I load into matlab for analysis. > Some of the results are mathematical realisations that are of no use > to me, as such I feel that by having the bulk of the > code in matlab, then calling these routines in the manner you have > mentioned, I could create arrays of data, that is > filtered according to a stle of my choosing. I hope that you are aware that you can also call Matlab from the Fortran code. One major factor in deciding whether to make a .mex out of the Fortran or to call Matlab from Fortran is the division of labor. If the Fortran routine does much less work than Matlab, it may be advantageous to have it call Matlab. The second issue is error handling. This is a non-trivial issue since there are two error contexts to worry about, and means for reporting Fortran errors in Matlab (or vice versa) need to be provided. If the .mex code is short, you can do your best to make it error free, and keep your fingers crossed. Otherwise, you have to do a good chunk of code writing to manage and report errors. -- mecej4
From: dpb on 27 May 2010 09:04 baalzamon.moridin wrote: > There are some general shortcomings with the original code; output > format etc. > Today I shall look into mex stuff. If anything I shall recreate the > main program and some of the intial subroutines > in matlab and then call some of the horrid code in - like the one with > the assigns, as well as the routines such as > DAXPY etc. Ultimately, at the moment I use the fortran exe, which > generates text files, that I load into matlab for analysis. > Some of the results are mathematical realisations that are of no use > to me, as such I feel that by having the bulk of the > code in matlab, then calling these routines in the manner you have > mentioned, I could create arrays of data, that is > filtered according to a stle of my choosing. Another alternative if the point is simply to analyze results from the code in Matlab rather than a "must have" of the whole system as a Matlab application would be to just look at the section of the code that is creating the output and modify it to suit -- you could, for example, neuter the output you don't want/use (or, of course, if it's factored well enough, not call that portion of the model). Also, you could easily enough change the output from text files to write binary files that could be loaded in Matlab w/ load() more quickly. You could make these files have any structure desired relatively easily I'd think. You would, need to use a compiler that supports "stream" output which wasn't a Standard component of Fortran until F2003, but virtually all compilers had extensions to do so; only a very few didn't. That way you could actually avoid the mex-ing thing altogether. Depending on your needs, you might also be able to use the ability of Matlab to spawn a process to make the interaction w/ the code from Matlab by using it to create input and execute that via the dos() command and friends then load the binary file when done. Saving, I'd think, quite a lot of effort in converting already-working code. Again, $0.02, etc., etc., etc., ... --
From: baalzamon.moridin on 27 May 2010 11:57 @dpb re: calling from binary file An interesting alternative, that I did once consider, however, with the large number of times I need to call this code text file generation is something i would like to avoid. As for surpressing the output, well that does sound good. I will go over the code later and see if the io code splits the task with the output code. As long as I could control the input and have the output going straight to an array in matlab that would be adequate. Though it would steal my spare time reallocation which I gave into the conversion.... By the By do I need an actual editor for writing fortran....or can I use notepad and save it with the correct extension? Notepad opens the file and shows no encrypted segments?
From: Gordon Sande on 27 May 2010 12:20 On 2010-05-27 12:57:11 -0300, "baalzamon.moridin" <baalzamon.moridin(a)gmail.com> said: > @dpb > > re: calling from binary file > An interesting alternative, that I did once consider, however, with > the large number of times I need to call this code text file > generation is something i would like to avoid. As for surpressing the > output, well that does sound good. I will go over the code later and > see if the io code splits the task with the output code. As long as I > could control the input and have the output going straight to an array > in matlab that would be adequate. Though it would steal my spare time > reallocation which I gave into the conversion.... > By the By do I need an actual editor for writing fortran....or can I > use notepad and save it with the correct extension? Notepad opens the > file and shows no encrypted segments? If you save as any type of formatted (in the word processing sense) file it is unlikely that a compiler will be able to deal with the formatting information. You must save as text. Do not rely on any automatic line wrapping as the text will be a very long line which may well exceed the compiler limit, to say nothing of the confusion of having all those Fortan statement on a single line. You must use lots of line ends which are othewise known as paragrph markers. And do a small test to see how hard it is to meet the requirements.
From: dpb on 27 May 2010 13:45
baalzamon.moridin wrote: > @dpb > > re: calling from binary file > An interesting alternative, that I did once consider, however, with > the large number of times I need to call this code text file > generation is something i would like to avoid. Well, the binary file eliminates the text file (which is why I suggested it) and unless the sizes of the data arrays are _quite_ large, I can't imagine performance would suffer noticeably, or at least to the point of being a real bottleneck. So, the question becomes, just how large of datasets are we talking about? > As for surpressing the > output, well that does sound good. I will go over the code later and > see if the io code splits the task with the output code. It doesn't matter whether it's separated or not; again that's why I'm making the suggestion. The effort required to find the write() statements to the specific file for the output which you want or don't would be minimal in comparison to the amount of time I'd imagine you've already spent in trying to read and convert the code to date. All you need to do is to either change the current OPEN statement from formatted write to stream and then replace the write(unit,fmt) variables lines w/ write(unit) variables and you're done. If it's full arrays and there are currently loops and/or implied-DOs to format the arrays for the text output it becomes even simpler--just replace w/ the array name and voila! you've written the entire array (in column major order, just like Matlab expects). > As long as I could control the input and have the output going > straight to an array in matlab that would be adequate. The above would be an intermediate step but I can't believe it would really be onerous overhead (see above comment on size). > Though it would steal my spare time > reallocation which I gave into the conversion.... I have no idea what this means unless you're saying doing this isn't converting the whole thing. My point is that unless there's some inviolate _requirement_ on the application itself being in Matlab, why do more than is necessary? > By the By do I need an actual editor for writing fortran....or can I > use notepad and save it with the correct extension? Notepad opens the > file and shows no encrypted segments? No, but you'll certainly do far better with a programmer's editor than a general text/word processor one. As Gordon says, w/ those tools you have to make certain you save as text and they have no help. There are of course endless discussions over good/better/best that are mostly religious. I use an old DOS no-longer-available one so I'll not mention any in particular; if you aren't aware at all I'd suggest either a google or another query of some suggestions from some of the regulars as I have to admit I know next to nothing about anything in that vein outside my old copy of Brief. I'm sure there are many that have language-sensitive features that they can recommend; Brief does and I've modified the built-in feature macros fairly extensively over the course of almost 30 years so as long as it continues to function I'll not be looking elsewhere; in fact given my essentially retired state I'm sure I'll simply quit rather than switch if it were ever to come to that (which I don't expect, anyway)... :) -- |