From: mecej4 on
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
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
@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
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
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)... :)

--