Fortran code in Matlab
이전 댓글 표시
I have a Fortran code which I need to simulate in Simulink. Before creating a C mex file, I am only compiling the Fortran code in Matlab using Intel Parallel Studio XE 2015. However, I get the following error when I compile it.
SUBG.f(1078): error #5078: Unrecognized token '&' skipped
* & /' large nromalization factor in fixvol.'
-----------^
And here is the snippet of the code where the error lies.
if (abs(1.0-xnormc).gt.0.05 .or. abs(1.0-xnormr).gt.0.05) then
write (lutty,1800) xnormc,xnormr
1800 format (/' *****Warning'\
& /' large nromalization factor in fixvol.'!In this line the problem lies
& /' for coal =',f8.2,' for rock =',f8.2)
endif
Moreover, I searched the internet for the said problem and found out that it mostly occurs when an
unknown character sneaks up in the code while copying-pasting it into Matlab.
Anywork around about this problem!
Thankyou.
댓글 수: 11
That's a problem of fixed format source code trying to be compiled as free form. It is perfectly valid Fortran code IF the first line snippet code actually starts in column 7 as I would presume it will in the actual Fortran source code fie.
I don't know the current state of the MATLAB mex Fortran compiler switches nor did you give the source code file extension being used (".f", ".for", ".F95" are common). Fortran compilers make different assumptions about the source code format depending upon the extension as their defaults.
You need to check the compiler doc for its convention and then use the -debug option to ensure the mex file is using appropriate options for your source code.
Of course, compiling it standalone outside MATLAB would be the first step to ensure all is well...
afaq ahmad
2021년 12월 2일
편집: afaq ahmad
2021년 12월 2일
dpb
2021년 12월 2일
"P.S: in orignal code IF starts at column 6."
That's wrong. Column 6 is continuation column. Fortran statements in fixed-source form start in column 7 (or past, blanks are immaterial). However, if that were true, it wouldn't compile in any compiler, so I'm not convinced of that. Of course, the '6' could be a typo in the post, too.
Microsoft Powerstation is 30 years obsolete.
All that matters is that it compiles under the same compiler and switches that you are telling mex to use; anything else is immaterial at best, confusing at worst if results aren't the same.
I still contend the same points I first made are the pertinent issues...and I don't have the Intel compiler and it's been far too long since I did to recall for certain enough to risk which way it uses for defaults.
afaq ahmad
2021년 12월 3일
편집: afaq ahmad
2021년 12월 3일
Walter Roberson
2021년 12월 3일
편집: Walter Roberson
2021년 12월 3일
No, I would be sure this is an issue of whether the code is being intepreted as fixed form or free form.
Note that mex might be passing in one of these flags even though you did not ask it to.
dpb
2021년 12월 3일
I had just looked for and found the link to Intel doc Walter posted above as a refresher ... it notes
"Files with an extension of .f90, .F90, or .i90 are free-format source files.
Files with an extension of .f, .for, .FOR, .ftn, .FTN, .fpp, .FPP, or .i are fixed-format files."
So, as I presumed but wasn't quite sure enough to posit without memory refresher, the above file should compile with .f as the filename extension.
If other files compile successfully, but this one doesn't with the same mex setup, that would indicate a potential that there is a hidden control character or such in the particular file at that location.
If the same file will compile with a .f extension but not with .for, that's almost certainly back again to the funky batch file/make file that MATLAB builds and mex uses. It has been in the past, far too complicated and fragile imo; it would be SO much simpler it TMW would simply tell us what options are needed and let us control and compile code without trying to hide it all. By trying to be simple, they in fact, make it much more difficult if anything at all goes wrong.
I've not tried to use mex in 10+ years now when support for the venerable 32-bit compiler I used ended--I couldn't justify Intel and afaict, they now no longer support the gnu Fortran compiler; I've not tried recently to see if could get it to work.
All in all, TMW would like to see Fortran disappear entirely and appears to be doing all they can to expunge its existence from MATLAB. This is, in my opinion, entirely wrong and a great disservice to the community. Current Fortran Standard is the best integrated language with coarray support and all that there is...but the C++ mindset overrides all.
"Could there possibly be some other reasons behind this error?"
The error is clearly one that the compiler confused that source line ... but w/o the actual command line passed to the compiler we can't tell what it assumed. Try it again but use the "-v" option as well to have the detailed build process commands/output echoed. Inspect it closely and you should be able to spot the problem.
If that doesn't let you solve it on your own, cut'n paste that output.
Attach the problematical file as it is; perhaps someone here with the Intel compiler can check it out...or other can look at it and see if they can spot a content issue.
afaq ahmad
2021년 12월 3일
편집: afaq ahmad
2021년 12월 3일
dpb
2021년 12월 3일
Well, to add insult to injury, what used to be a m file that dispatched a convoluted batch file that called a perl script that read a set of supported compiler text-file databases is now all builtin -- you can't see or touch anything to add another compiler beyond the blessed one from Intel. This is is "just plain rude!"
I've not got the time right now to see how one can still manage to compile/link from the command-line compiler tools or if they've managed to neuter things to the point it's impossible.
I gave up before when still running 32-bit compiler with MATLAB release that didn't have the specific compiler still supported. One could successfully compile/link to the previous compiler-specific libraries, but there was a poison pill internally that one could not, then, execute that .mex file in the newer MATLAB release--it would throw a version mismatch error.
Fortunately, for me, that was about when I retired from the active consulting gig and the client was satisfied with the results available earlier so it didn't become absolutely mandatory to move on...but I was a very unhappy camper at the time.
If they would just tell you how to compile and link to which libraries, if one can write, compile and execute Fortran code, one could then easily adapt to whatever compiler. If, on the rarest of outside chances, something really does break, simply a disclaimer that it is an unsupported compiler is sufficient to cover them, but with the existing user base for Gnu Fortran, that a fix wouldn't be available would seem highly unlikely, particularly when they are still supporting Gnu C++ and all Gnu Fortran is is the front end language interpreter in front of it.
James Tursa
2021년 12월 3일
편집: James Tursa
2021년 12월 3일
"Does this mean my Matlab handles both fixed and free format?"
Unfortunately, no it doesn't. MATLAB keeps putting the silly /fixed option in their mex build files, which forces the compiler to treat .f90 files as fixed format. I've been complaining to TMW for years about this but it never gets fixed. My advice to you is to edit the mex build files, find the COMPFLAGS (or similar) line, and delete the /fixed option from it. Then your compiler will understand .f90 free format files.
dpb
2021년 12월 3일
if (abs(1.0-xnormc).gt.0.05 .or. abs(1.0-xnormr).gt.0.05) then
write (lutty,1800) xnormc,xnormr
1800 format (/' *****Warning'\
& /' large nromalization factor in fixvol.'!In this line the problem lies
& /' for coal =',f8.2,' for rock =',f8.2)
endif
I wonder what it is expected for the above line of output to look like in the first place now that look at it in more depth.
It would seem funny to have
*****Warning large nromalization factor in fixvol.
for coal =',f8.2,' for rock =',f8.2)
if the succeeding \ and / do actually cancel each other.
*****Warning
large nromalization factor in fixvol.
for coal =',f8.2,' for rock =',f8.2)
might seem more like what might have been intended in which case just dumping the "\" would produce output.
*****Warning large nromalization factor in fixvol.
for coal =',f8.2,' for rock =',f8.2)
might be another choice in which case the FORMAT statement should look like--
1800 format (/' *****Warning large nromalization factor in fixvol.'
& /' for coal =',f8.2,' for rock =',f8.2)
or some variant thereof.
One notes as a nit the word "normalization" has a typo in the "r" and "o" are swapped.
채택된 답변
Try adding additional switch to handle the backlash edit descriptor James' keen eyes spotted (I used the DEC DVF/CVF compiler for so long that I got inured to it being an extension; there it was enabled by default).
Searching the Intel doc shows it is not enabled by default there.
Set
Compatibility > Use PowerStation I/O Format (
/fpscomp:ioformat
as additional switch to pass to the compiler from mex.
The link to the Intel doc -- if you have the compiler installed, you should have the help files local as well, but this is the option needed to get that specific extension recognized. <Documentation/fortran-compiler-compatibility-options/fpscomp>
Does seem like the compiler could have generated a more useful error message flagging the extension semantics in the FORMAT statement.
댓글 수: 10
afaq ahmad
2021년 12월 3일
I've not used mex in ages and at the present don't have a compiler installed, so can't check for sure what mex does now, but used to be
mex -fpscomp:ioformat filename.f
would do the trick.
Use the -v option again to see what it echoes back as the actual command line...
Of course, to prove the case, you can also use the Intel compiler at the command line or thru the IDE and set it there to see if then the file does compile successfully.
James Tursa
2021년 12월 4일
First thing I would do is change that backslash \ to a forward slash / to verify if that is indeed the problem.
dpb
2021년 12월 4일
If you're going that route, just delete it.
afaq ahmad
2021년 12월 4일
afaq ahmad
2021년 12월 4일
편집: afaq ahmad
2021년 12월 4일
dpb
2021년 12월 4일
The compiler should never have an internal error; that's a bug in the compiler that it failed to handle an error in the parsing. If the version you're using weren't so old, that would be worth reporting to Intel. Have you installed all updates to the version you do have? Any chance you can upgrade/update your compiler in case this has uncovered a bug in its parser?
On the second, we don't have the output of the -v option so we can't see for absolute certain the command line passed to the compiler for verification of what the switches were.
Q? Have you successfully compiled other files using the ampersand "&" as the line continuation character? I presume so, but just wondering if that is somehow an issue in compiler getting confused on fixed/freeform source parsing having seen the internal error above.
Try substituting another character in place of the "&" in column 6, by Fortran Standard any non-blank character other than 0 is acceptable.
Lastly,as I suggested earlier, attach the original source code file so folks here can see it in its entirety as it exists, not how it is represented on screen with the browser.
That way, others who do have a compiler installed can test it directly as well and see what different compilers/versions of Intel compiler think.
dpb
2021년 12월 4일
I reinstalled gfortran and turned the code snippet into a compilable program
C:\GCC\bin> gfortran -c \Users\Duane\Documents\MATLAB\Work\testfor.for
\Users\Duane\Documents\MATLAB\Work\testfor.for:8:34:
8 | 1800 format (/' *****Warning'\
| 1
Error: Unexpected element '\' in format string at (1)
\Users\Duane\Documents\MATLAB\Work\testfor.for:7:72:
7 | write (lutty,1800) xnormc,xnormr
| 1
Error: FORMAT label 1800 at (1) not defined
C:\GCC\bin>
It, as expected, doesn't like the backslash in a FORMAT statement, but it does say so, illustrating again one should always have more than one compiler because error messages can be different.
Removing the backslash lets the code compile successfully.
AFAICT, gfortran doesn't have a input switch for MS Powerstation compatibility; not surprising. The -DEC extensions switch doesn't include that particular perversion.
I also downloaded the Intel OneAPI compiler, but I don't have the licensed MS Visual Studio needed to run it in the IDE and I've not yet figured out all I need to do to run ifort at command line.
I don't follow the issue you noted of the code not compiling if you simply remove the backslash -- that would be indicative of something else in the file.
afaq ahmad
2021년 12월 5일
"Matlab compiled it successfully with the generic ''-c mex filename.f'' command"
That should be
mex -c filename.f
leading a command with a "-c" would be a syntax error.
"..., but Matlab won't tell me exactly."
This has essentially nothing to do with MATLAB -- it is the Fortran compiler being dispatched by the mex command that is all that matters here. All MATLAB is doing is hiding what is really going on by use of the mex function to build the make file it passes to the specific command toolset.
Again I tell you -- compile the file directly with the Intel compiler and you'll have full control to determine what it sees/doesn't see for input switches and all error messages.
And also again, attach the full file as it existed originally and somebody can compile it independently as well with multiple compilers which, as observed above, have different diagnostics and can be extremely helpful with odd syntax issues.
It is possible that if a closing quote on a string constant or closing parenthesis is missing or past column 72 and is thus skipped the compiler can get confused and then not flag an error until somewhere in the source code past that location. When that happens, however, it almost always will start a cascade of errors, not just a single error and the given line definitely has a syntax error in it unless the Intel compiler can handle the backslash edit descriptor extension as described earlier.
Unfortunately, so far after several hours of download and install time, I'm yet unable to manage to get a working version of the Intel compiler installed so i can't try to compile it here with that compiler.
추가 답변 (1개)
James Tursa
2021년 12월 3일
편집: James Tursa
2021년 12월 3일
0 개 추천
I'm trying to figure out the purpose of the backslash \. If this was the last character in the format statement then I would assume this is for the purpose of suppressing the newline. But you have it in the middle of the format statement, which means the compiler might interpret this as the start of an escape sequence, but there is no valid escape sequence character following this backslash. Maybe the compiler is trying to put the \& together as an escape sequence and then reports that the & is skipped because it isn't one of the valid escape sequence characters? Why is that backslash there? Why not a forward slash?
댓글 수: 3
Good catch, James!!!
I guess the \ preceding the / may have been intended to string the long line together. Dunno that it works that way or not; don't think ever tried that combination.
But, the backslash edit descriptor extension isn't enabled by default in the Intel compiler switches so it may be that's why it failed. Would also explain why was able to use MS Powerstation standalone and it compiled it successfully.
I'd say it's a good bet that's the problem --
Walter Roberson
2021년 12월 3일
Looks to me as if maybe it has to do with continuation, but it does not appear to be a standard representation.
"//" is the Fortran string catenation syntax; inside a FORMAT statement the "\" outside a quoted string can only be the DEC backslash edit descriptor extension.
But, while the Intel compiler supports it (and many others as well), it is NOT active by default so the Intel compiler barfs on it.
That's also why the MS Powerstation compiler didn't -- those extensions are all enabled by default in it.
We're going to know realsoonnow™ as OP is actively pursuing this track.
I'm pretty-much convinced this will prove to be it...now whether it should really be there where it is at all or not to produce the desired output string is another kettle o' carp! :)
카테고리
도움말 센터 및 File Exchange에서 Call MATLAB from Fortran에 대해 자세히 알아보기
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!
Translated by 
