- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I currently write my fortran modules using a text editor and compile on the command line in OS X terminal (new bash fixed). However I noticed something strange. Even if I save my f90 file with modifications then often when I compile and link I notice that any fixes to errors are not immediately picked up as though the compiler is using a cached copy of my old code. However if I type the unix command "ls -alt" then compile then my my edits appear to be read immediately. I use command S to save from my text editor
Normally in an IDE I would instigate a clean and build if not sure - is there an equivalent compiler flag or am I imagining things, bug in my editor, bash shell ?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would venture to suggest that this behavior is not related to the intel fortran compiler.
A few questions:
Can you give us more information about your build process?
Are you using Makefile(s)?
Might there be some additional tool like f90cache hidden in an alias so that you’re not actually directly invoking ifort? (You can check this with `type -a ifort`)
Can you give us details about your file system?
It sounds like compilation is happening in the wrong order and/or there is a problem with your file system/disk.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Zaak
Yes, I was precluding that this may be a caching problem with my editor since it was a bit strange, my curiosity was aroused by the fact I was reading Metcalf's Modern Fortran which has a section at the back about compilation cascades
Anyway, answering your question. I write my code in sublime text v3, I then do a save (cmd S). Then in terminal I will use the unix stored history command by repeating a previous command via the up arrow key. If everything compiles OK then things are as I expect.
Issues arise if I make a typo or bug which the compiler then flags up, I then go back to the external editor, do the fix and cmd+S. However, repeating the compilation using the up arrow history + return doesn't always pick up the change, the compiler often shows the old text including typo
If I then hit return in terminal with a blank command line followed by 'ls ' return then do up arrow history the change I made is picked up
Before I noticed this I was looking for non-existent bugs ;-)
I'm not using a make file, using cocoa I would normally just xcode clean and build after a change. Since I'm using MKL libs there are lots of compiler created modules created automatically
File system is basic HFS Plus OS X 10.9.5 with the latest mac security bash shell fix
Since all my code is in a single file at the moment I'm not using make, haven't used a hand made make file in over 20 years (I'm not a pro developer - just a hobbiest, my last job was software architect so I'm just enjoying doing what interests me)
diskutility is not reporting any probs; type -a ifort gives
ifort is /opt/intel/composer_xe_2015.0.077/bin/intel64/ifort
ifort is /usr/bin/ifort
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I just observed when writing a new program that includes MKL, but has not yet auto generated loads of __genmod files (only source and mkl*mod files I'm not getting the same undesirable behaviour . So I wonder if it is these compiler created files that is the issue ? eg sparselinearsolver__genmod.f90 ??
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The __genmod files are from -warn interface
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks
This is how I would typically compile - I may occasionally remove the -g -warn depending on the message, some of the the other options chosen are 'experimental', that is I just try what gets a performance improvement
ifort levenbergMarquardt.f90 -fp-model strict -i8 -openmp -I$MKLROOT/include/ilp64 -I$MKLROOT/include $MKLROOT/lib/libmkl_blas95_ilp64.a $MKLROOT/lib/libmkl_intel_ilp64.a $MKLROOT/lib/libmkl_core.a $MKLROOT/lib/libmkl_intel_thread.a -unroll-aggressive -lpthread -lm -march=native -g -warn -o levenberg
If all else fails I can do a manual 'refresh' or use xcode assuming clean works, just that I've developed a liking for using the command line
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you are using makefiles, you'd need to have rules for .mod files dependent on .f90 and make your .f90 sources that uses modules dependent on the .mod files. The compiler doesn't have the concept of a "cached copy". It sounds to me like a typical makefile correctness issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is very puzzling to me. I’m curious, since you’re writing all the code in one file, are you using modules etc? I think the compilation order will be the order that the compiler sees in your source listing, so perhaps you need to reorder the program units in your source file to satisfy dependencies?
Can you do a test where you make a change that fixes a bug, but rather than trying to compile it right away, issue `ls ` first and then try to compile it? Also, try compiling it and when it fails try again immediately without changing anything? If the first suggestion works but not the second then there is certainly an issue with either your editor or your file system or your hard drive. If the second works but not the first, then I suspect there is a dependency resolution issue. If this is the case, try adding ‘-nogen-interfaces’ to the compile line—it’s conceivable that the __gen_mod files are messing you up somehow.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Zaak
I probably should look at this soon, its more of an annoyance than an issue but there is something strange going on, it may well be my shell?
I was just playing with some 3d arrays of 10000 32 bit integers and I got an out of memory error from my allocate and reading from two bigendian files was causing an issue ( it was reading the first fine but reading the second incorrectly)
I killed my terminal and opened a new one and everything worked fine including the troublesome bigendian read. Maybe I killed a canary or two?
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page