• After witnessing the continued decrease of involvement in the SpotterNetwork staff in serving SN members with troubleshooting issues recently, I have unilaterally decided to terminate the relationship between SpotterNetwork's support and Stormtrack. I have witnessed multiple users unable to receive support weeks after initiating help threads on the forum. I find this lack of response from SpotterNetwork officials disappointing and a failure to hold up their end of the agreement that was made years ago, before I took over management of this site. In my opinion, having Stormtrack users sit and wait for so long to receive help on SpotterNetwork issues on the Stormtrack forums reflects poorly not only on SpotterNetwork, but on Stormtrack and (by association) me as well. Since the issue has not been satisfactorily addressed, I no longer wish for the Stormtrack forum to be associated with SpotterNetwork.

    I apologize to those who continue to have issues with the service and continue to see their issues left unaddressed. Please understand that the connection between ST and SN was put in place long before I had any say over it. But now that I am the "captain of this ship," it is within my right (nay, duty) to make adjustments as I see necessary. Ending this relationship is such an adjustment.

    For those who continue to need help, I recommend navigating a web browswer to SpotterNetwork's About page, and seeking the individuals listed on that page for all further inquiries about SpotterNetwork.

    From this moment forward, the SpotterNetwork sub-forum has been hidden/deleted and there will be no assurance that any SpotterNetwork issues brought up in any of Stormtrack's other sub-forums will be addressed. Do not rely on Stormtrack for help with SpotterNetwork issues.

    Sincerely, Jeff D.

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