Mesoscale modeling...

Well, that's a relief that it works on FC4 64-Bit... I don't recall the exact error, but I'm going to undue everything that I did and start fresh. I'll also look into the Intel F90 compilers and see what I can do with the WRF source code.
I did run the 32bit workstation Eta binary, however. I haven't tried the 64 bit one so maybe that's the problem?

I'm not sure... This is my error:

PGFIO-F-207/OPEN/unit=14/file is already connected to another unit.
File name = /usr1/worketa3.1/data/eta_prep/01041112000.ETA_TILE32

I have no clue what it means, and I doubt many will unless they actually wrote the code for the particular program that's failing (dutil.f)...

What processor are you running? Maybe I should try turning off some of the CPU features like Hyperthreading, CPU throttling, etc.. I'm pretty much stumped. I completely deleted the installation and started fresh - same problems :x

Maybe I should just move on to the WRF and compile it myself so that I know it's built around my machine.
 
I may be talking through my whatever, because I haven't messed with WSEta ... yet :roll:. However... sounds-like a problem I ran into now and then porting "standard" Fortran code into DEC VAX Fortran (from which Compaq and Intel implementations, I think, derive some of their "features").

There are somewhat variant compiler implementations of the parameters and defaults in a file OPEN statement. In particular the file in question may already have been opened for read-write, when it's only needed for read-only by multiple IO units. In that case it's locked and and can't be associated with another IO unit, i.e. unit 14. The error won't show up until run-time unless the filename was hard-coded.

The fix is to find the offending OPEN statement(s) in the code and make sure it marks the file for read-only. FWIW.
 
I may be talking through my whatever, because I haven't messed with WSEta ... yet :roll:. However... sounds-like a problem I ran into now and then porting "standard" Fortran code into DEC VAX Fortran (from which Compaq and Intel implementations, I think, derive some of their "features").

There are somewhat variant compiler implementations of the parameters and defaults in a file OPEN statement. In particular the file in question may already have been opened for read-write, when it's only needed for read-only by multiple IO units. In that case it's locked and and can't be associated with another IO unit, i.e. unit 14. The error won't show up until run-time unless the filename was hard-coded.

The fix is to find the offending OPEN statement(s) in the code and make sure it marks the file for read-only. FWIW.

I'll see what I can do, but it's the same file that has been working for years. The only thing different in this situation would be my new computer and core operating system (64 Bit versus 32 Bit). My thought was that the operating system is somehow splitting up the task, and thus "opening" the same file twice (Hyperthreading is usually seen as two processors by the operating system, even though there is physically only one).

I've started reading the WRF manual, and building/installing it seems to be the easy (well, easIER) part... Getting the correct data and piping it to the correct programs will be the tough part.
 
I'm looking to run some higher resolution models for the ocean (like the Southern Ocean). Is this possible? What about a high resolution nested grid?

What kind of investment/frustration factor would I have setting this up? As an alternative, are there any good free or subscription services for this type of data.
 
I would say it's possible, Bill. The model would probably initialize boundary conditions (and probably initial conditions) from the GFS.

I am still trying to get the WRF up and running. I get the entire stream of MADIS observational data, so I could initialize the WRF using real-time datasets that operational models don't even ingest (primarily because the datasets themselves aren't operational). The datasets include many mesonets, aircraft data, satellite derived winds, NEXRAD, etc..

But, none of that matters if you can't even get the thing compiled. I downloaded the latest Intel Fortran 90 compiler, but I can't get it to work with the WRF - I get TONS of errors (I probably don't have the compiler flags set right or something, and don't even know where to begin). There really isn't a "support center" for the WRF either, so no chance at getting any help that way. There are forums available, but the response time is usually about one month per reply - not exactly efficient.

For anyone looking to get involved with this kind of stuff... It is VERY confusing. It's not so much running the model that's confusing, it's getting the thing installed and configuring it for runtime. If you have little to no experience with *nix systems, you're looking at a nearly vertical learning curve.
 
Back
Top