Mesoscale modeling...

I am getting ready to setup a mesoscale model on one of my workstations, and I am not sure which one I want to try this go around...

I usually run the Workstation ETA (WS ETA) from the SOO/STRC, which is a very easy setup. They provide everything needed to run the model "out of the box". It automatically collects the needed data, converts it, and runs the model - the only thing the user needs to do is setup the config file in the beginning.

I have also been looking into the WRF model. It's alot more complicated than running the WS ETA, since it's not really automated (you have to program your own scripts to get the correct data, then apply each program). I assume the MM5 is run in a similar fashion.

I asked Dr. Greg Mann (our local NWS's SOO), and he actually recommended the WS ETA since it's alot easier to run, and since the current benefits of the WRF over the WS ETA aren't really all that great as of yet (in addition to the fact that mesoscale modeling is far from perfect anyway).

I'm thinking of sticking with the WS ETA... Anyone have experience with the WRF, or any significant reason to stray from the WS ETA and go with the WRF?
 
Anyone? With all the people with a met and/or college backround, no one has ever tried running the WRF or knows the advantages of the WRF over other mesoscale models? :x :lol:
 
WRF would be cool to run, so if you want to undertake the effort, let me know how it goes! I've been wanting to run the WS-ETA on my laptop since last winter, but I've been waiting for a good NTFS-on-Linux solution so I don't need to repartition my hard drive (read: wipe the hard drive clean). I suppose I could perhaps buy the Norton partition, but I'd hate to spend $70 on a program I'll use once. I haven't paid attn to the NTFS-on-linux effort lately, so perhaps there is a way yet that allows me to read my NTFS partition (which is the windows partition, and holds all data) while on the Linux side (FAT partitioned).
 
Quick question, exactly how do you run models on your own computer? GEMPAK or other programs?

It does sound like something I would like to do also when this semester ends.

Mick
 
The SOO/STRC WS ETA is by far the easiest to setup, provided you follow the instructions...

With the WRF - I always thought it had the ability to initialize using real-time data (nids, satellite, OBS, etc.) via a 3DVAR program? Looking through the user manual, I only see that the program accepts sounding/RAOB data. If I could find out how to add the other sources that I mentioned, then I would definitely try the WRF hands down.

As for your question Mick, Jeff posted some good resources. You would generally need to have a relatively fast Linux system (you can download Fedora for free at Redhat.com)... To view the data, GEMPAK is what is typically used for the WS ETA, but I'm not sure about the WRF. I think the output files are all in netCDF, which I have no experience with...
 
Thank guys. I really think I will take some time on the brake and get this up a going for next season. I have an extra machine in which I can use to run which ever model I choose to run. It is not the best machine but if I can get my hands on onther 512mb of RAM it may jsut do the job. Of course the Linux is in itself going to be a handfull by itself. I have not even messed with Linux. I have also wanted to get GEMPAK up and going to so that will part of that task also.

Thanks again...

Mick
 
Originally posted by Mickey Ptak
Thank guys. I really think I will take some time on the brake and get this up a going for next season. I have an extra machine in which I can use to run which ever model I choose to run. It is not the best machine but if I can get my hands on onther 512mb of RAM it may jsut do the job. Of course the Linux is in itself going to be a handfull by itself. I have not even messed with Linux. I have also wanted to get GEMPAK up and going to so that will part of that task also.

Thanks again...

Mick

The model takes advantage of higher processor speeds moreso than RAM size (not that more RAM wouldn't help!)... Here are some benchmarks: http://strc.comet.ucar.edu/model/wseta_benchmark.htm

I'm going to get it up and running on my machine which runs an Intel 670J 64-Bit processor at roughly 4.25GHz with 512MB DDR2 RAM (667). I'll post the results once I get everything setup...
 
The model takes advantage of higher processor speeds moreso than RAM size (not that more RAM wouldn't help!)... Here are some benchmarks: http://strc.comet.ucar.edu/model/wseta_benchmark.htm

I'm going to get it up and running on my machine which runs an Intel 670J 64-Bit processor at roughly 4.25GHz

Jesus Christ 4.25GHz. Wow!

Yeh I won't even be close to that. My machine would only have a P3 1.2GHz 512mb RAM. I think I could live with that though according to that link you gave me it would take 1 1/2 hour to run it (give or take).

Even if that won't work I still want GEMPAK.

Mick
 
Well, no WS ETA for me :?

The binary distribution available from SOO/STRC seems to be too outdated for Fedora Core 4 64-Bit.

I would build the WRF, but it requires an F90 or F95 compiler, which as far as I am aware costs alot of money (on the order of $500), and is NOT available for free.

I should just stop upgrading my O/S - it's nothing but troubles! :x
 
Well, no WS ETA for me :?

The binary distribution available from SOO/STRC seems to be too outdated for Fedora Core 4 64-Bit.
I had it running on FC4 x86-64 just the other day. What error is it throwing?

I would build the WRF, but it requires an F90 or F95 compiler, which as far as I am aware costs alot of money (on the order of $500), and is NOT available for free.
I think you can download the Intel compiler for free, non-commercial use. You have to register with them, but otherwise it should work. Of course working out which switches to use in compilation may be a real pain.
 
Well, no WS ETA for me :?

The binary distribution available from SOO/STRC seems to be too outdated for Fedora Core 4 64-Bit.
I had it running on FC4 x86-64 just the other day. What error is it throwing?

I would build the WRF, but it requires an F90 or F95 compiler, which as far as I am aware costs alot of money (on the order of $500), and is NOT available for free.
I think you can download the Intel compiler for free, non-commercial use. You have to register with them, but otherwise it should work. Of course working out which switches to use in compilation may be a real pain.

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'll keep you guys updated, since I know a few people here are interested in getting these things up and running...
 
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?
 
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