From kd5giv at MESH.NET Mon Dec 3 04:22:10 2001 From: kd5giv at MESH.NET (Michael) Date: Mon, 3 Dec 2001 4:22:10 Subject: Odd Grads plot question Message-ID: Hello, I hope it's ok to send a small image to you. It in png formate and Internet Explorer or Netscape can display it. It's 15k. I am asking if you know of what may be causing ARPS to forecast like this image shows for the 8000 meter qv (Water Vapor Mixing Ratio(g/kg)). This also happens on some other fields. One small thing I am thinking could be some kind of smoothing setting because running on the same ruc2 conditions at 90km it didn't do anything like that. The image was produced by Grads 1.8 on a 40km grid. The 90km grid run looks good and normal. It seems like the smaller the resolution the worse images, like this one attached, get. I hope I didn't break any rules by sending an image. -------------- next part -------------- The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: qv40km8000m.png Date: 3 Dec 2001, 4:09 Size: 14348 bytes. Type: Unknown -------------- next part -------------- A non-text attachment was scrubbed... Name: qv40km8000m.png Type: application/octet-stream Size: 14348 bytes Desc: not available URL: From tanaka at WRCS.DPRI.KYOTO-U.AC.JP Wed Dec 5 15:46:15 2001 From: tanaka at WRCS.DPRI.KYOTO-U.AC.JP (Tanaka Kenji) Date: Wed, 5 Dec 2001 15:46:15 Subject: Many questions from Kyoto Univ.(2) Message-ID: Dear Dr. Ming Xue, Hello!! Thank you very much for your kindly answer. >> We generally use microphysics (ice physics preferred with mphyopt=2) >> on all grids, and use it together with cumulus parameterization >> (Kain-Fritsch scheme) at relatively course resolutions ( dx>10km or so). I thought that cumulus parameterization works only when the grid size is much larger than the size of individual cloud. >> The other resolution dependent physics is the PBL parameterization >> (tmixopt=3, tkeopt=3), which is needed only when dx is several km >> and above. Otherwise, choose tkeopt=1. Thank you for this valuable information. I used tkeopt=3 for 16km grid, and tkeopt=1 for 4km grid, but tmixopt=4 for both cases. >> You are correct. ARPS AGRI does not support diferent terrain or >> land use/land cover on the nested grids. This is in the plan >> of furture upgrade. To use different physics on the nested grid, >> you will have to change the control parameters for the fine grids. OK. I will try to modify the arpsagri to utilize different surface dataset and different parameterization option. I have another question. As for the top boundary condition, may I use the radiation condition when applying externally boundary condition or nested grid value for lateral boundary? I'm attaching some input files(arps.input,) used in the one-way nest grid system. Would you please check the content of these files? But it may take much time. If there is not a problem, would you please show me your arps.input file used in your local weather forecast system? I want to know what kind of options are selected in the "real" forecasting. Sincerely, Kenji Tanaka ================================== Kenji Tanaka tanaka at wrcs.dpri.kyoto-u.ac.jp Water Resources Research Center, D.P.R.I. Kyoto Univ., Gokasho, Uji 611-0011, Japan Tel: +81-774-38-4246 Fax: +81-774-32-3093 -------------- next part -------------- A non-text attachment was scrubbed... Name: step1.input Type: application/octet-stream Size: 11404 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: step2.input Type: application/octet-stream Size: 11401 bytes Desc: not available URL: From mxue at OU.EDU Wed Dec 12 00:37:09 2001 From: mxue at OU.EDU (Ming Xue) Date: Wed, 12 Dec 2001 0:37:09 Subject: No subject In-Reply-To: Message-ID: > -----Original Message----- > From: De Ridder Koen [mailto:koen.deridder at vito.be] > Sent: Tuesday, December 11, 2001 8:14 AM > To: 'mxue at hoth.gcn.ou.edu' > Cc: Lefebre Filip > Subject: > > > Dear Ming, > > Please allow me to bother you with a few questions regarding ARPS. > > In BINREAD, the declaration states that x and y are defined > at the u resp. v points (staggered positions). However, at > the place in the code where the reading of x and y is done, > it says "Read in x,y and z at grid cell centers (scalar > points)". This is incorrect. We will correct it. > I would be inclined to believe that x and y are at > the u and v rather than at the scalar points, but I would > greatly appreciate if you could let me know which one it is. > > I have another question regarding running ARPS with initial > and lateral boundary conditions from external files (we use > ECMWF). The nesting itself works quite well, but I have a > little practical problem. Actually, when creating external > data files (exbcdmp=1 in arps.input), EXT2ARPS also > automatically generates initial data files at the same times > (eg 00, 06, 12, 18, ...). However, I only need 1 initial > file, and I can't find how to avoid the creation of multiple files. There is no way to avoid writing history dumps at initial time but not at other times. You will have to run two separate ext2arps jobs, one does one does not. You can turn off history file writing by setting hdmpfmt=0. Ming > > Regards > > > > Koen > > > > ---------------------------------------------------------------------- > Koen De Ridder > Flemish Institute for Technological Research (Vito) > Remote Sensing and Atmospheric Processes > Boeretang 200, B-2400 Mol, Belgium > > tel (32-14) 33 68 40 koen.deridder at vito.be > fax (32-14) 32 27 95 http://www.vito.be/bugs/ > ---------------------------------------------------------------------- > > > > From kd5giv at MESH.NET Thu Dec 13 06:08:00 2001 From: kd5giv at MESH.NET (Michael) Date: Thu, 13 Dec 2001 6:08:00 Subject: arps 4.5.2 questions Message-ID: Hello, I have 2 question about ARPS version 4.5.2. 1) In the arps.input file under grid tracking, it says grid tracking isn't implemented yet. Is that a mistake or does it still stand? 2) In the extdims.inc file it says the AVN grid 3 isn't implemented yet. Is this still true in ARPS 4.5.2 or just hasn't been changed yet? ___________________________________________________________ Michael Maxwell KD5GIV Storm Spotter, Not for idiots of Tarrant County but for me! Fort Worth, Texas 76116 From mxue at OU.EDU Sun Dec 16 01:04:18 2001 From: mxue at OU.EDU (Ming Xue) Date: Sun, 16 Dec 2001 1:04:18 Subject: arps 4.5.2 questions In-Reply-To: <3C1845C0.26037.1F5BB1@localhost> Message-ID: > -----Original Message----- > From: ARPS Support (CAPS) [mailto:ARPSSUPPORT at LISTS.OU.EDU] > On Behalf Of Michael > Sent: Thursday, December 13, 2001 6:08 AM > To: ARPSSUPPORT at LISTS.OU.EDU > Subject: arps 4.5.2 questions > > > Hello, > I have 2 question about ARPS version 4.5.2. > > 1) In the arps.input file under grid tracking, it says grid > tracking isn't implemented yet. Is that a mistake or does it > still stand? Nothing has changed with grid tracking in the past several years. It's an unsupported option. > > 2) In the extdims.inc file it says the AVN grid 3 isn't > implemented yet. Is this still true in ARPS 4.5.2 or just > hasn't been changed yet? It was added after 4.5.2, in our f90 version. Ming Xue > ___________________________________________________________ > Michael Maxwell > KD5GIV > Storm Spotter, Not for idiots of Tarrant County but for me! > Fort Worth, Texas 76116 > From _susin at INF.UFSC.BR Tue Dec 18 00:25:25 2001 From: _susin at INF.UFSC.BR (Giancarlo Susin) Date: Tue, 18 Dec 2001 0:25:25 Subject: No subject Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: README.MP3.scr Type: audio/x-wav Size: 29020 bytes Desc: not available URL: From mxue at OU.EDU Tue Dec 18 11:54:01 2001 From: mxue at OU.EDU (Ming Xue) Date: Tue, 18 Dec 2001 11:54:01 Subject: MSL Pressure for Grads output In-Reply-To: <3C1DC2DA.14863.D138B@localhost> Message-ID: Michael, Deduction of MSLP is not something that can be done in Grads script. It has to be calculated in the fortran program and written out into the Grads data file. The way it is deon can be found in ARPSPLT main program. Ming Xue > -----Original Message----- > From: ARPS Discussion Forum [mailto:ARPSFORUM at LISTS.OU.EDU] > On Behalf Of Michael > Sent: Monday, December 17, 2001 10:03 AM > To: ARPSFORUM at LISTS.OU.EDU > Subject: MSL Pressure for Grads output > > > Hello, > I am looking for a grads script to figure sea level pressure. > I have variables like (p for pressure) (pprt for pertubation > pressure) (pt for potential temperture in degrees K). > > Also, I have heard one can use potential temp and pressure to > figure the air temp then that would be nice too. I have never > been to school so, I don't the equations memorized. > > ARPS is on a terrain following grid and that is also how the > data is dumped. I really need the slp figured if nothing > else. ___________________________________________________________ > Michael Maxwell > KD5GIV > Storm Spotter, Not for idiots of Tarrant County but for me! > Fort Worth, Texas 76116 > > ____________________________________________________________________ > You receive this message because you are currently subscribed > to the ARPS FORUM mailing list. If you do no wish to remain > on the list, you can unsubscribe by sending, USING THE SAME > E-MAIL ADDRESS AS ON THE LIST, to the > listserv at listserv.ou.edu with a single line mail body UNSUB ARPSFORUM > > You can also go to web interface at > http://lists.ou.edu/cgi-bin/wa?SUBED1> =arpsforum&A;=1 > to > subscribe and unscribe. > > For further > question or problem, e-mail arpssupport at ou.edu. > > From tlericos at HUEY.MET.FSU.EDU Thu Dec 27 11:41:30 2001 From: tlericos at HUEY.MET.FSU.EDU (Todd Lericos) Date: Thu, 27 Dec 2001 11:41:30 Subject: Wind Profile/Boundary Problem Message-ID: Okay, I have problem that someone can hopefully solve. This is a tough one. I am running ARPS using a modified Weisman and Klemp sounding (meaning I changed a few parameters in the formulas in inibase3d.f). Anyway, that part initializes just fine. In viniopt=2 I have two methods of creating a wind profile to go with the sounding. The first involves a formula that calculates ubar based on the height (m) of a particular level. I am using zp(i) for the height in the formula. Here is a sample... IF(k.le.2)THEN ubar(i,j,k) = -17.50 ENDIF IF(k.gt.2)THEN if(zs(i,j,k).lt.2500.)then ubar(i,j,k) = 0.0075*zs(i,j,k)-18.75 else ubar(i,j,k) = 0.0 endif ENDIF I also use a different method of initializing the wind field whereby I calculate the above equation by hand and have a simple IF/THEN statement to input the data. Here is a piece of that code.... IF(k.eq.1)THEN ubar(i,j,k) = -17.50 ENDIF IF(k.eq.2)THEN ubar(i,j,k) = -17.50 ENDIF IF(k.eq.3)THEN ubar(i,j,k) = -14.81 ENDIF IF(k.eq.4)THEN ubar(i,j,k) = -12.18 ENDIF IF(k.eq.5)THEN ubar(i,j,k) = -9.56 ENDIF .......................and so on... Here comes the interesting part, bear with me here. Either of these methods create a sounding with EXACTLY the same wind profile in runname.sound. However, the model runs are completly different (by the way, these runs are 2D). I have traced the cause to a boundary problem. Whenever I use the equation (method 1) of creating a wind profile, unstabilities are created along the boundary that result in a -10 m/s wind moving into the domain along the right boundary. This does not occur when using the manual input (method 2). WHY? The wind profiles for both methods are the same. I can't figure out what is causing that instability along the boundary. Maybe it has to do with my use of zp(i) in the formula. However, the numbers in output.sound are correct. Weird, isn't it??? I have been working the problem for two weeks and I'm stumped. I certainly would appreciate any help on the matter. Thanks in advance. Todd Lericos **************************************************************** * Todd P. Lericos * e-mail: tlericos at met.fsu.edu * * Research Assistant * phone : (850) 644-6989 (office) * * Fuelberg Lab * (850) 644-1452 (Lab) * * Department of Meteorology * office: Love Bldg Rm 311 * * Florida State University * * * Tallahassee, FL 32306-3034 * * **************************************************************** * * * "We are not concerned with our hopes and fears, only with * * the truth as far as we can discover it." * * -Charles Darwin * **************************************************************** From tlericos at HUEY.MET.FSU.EDU Thu Dec 27 16:41:47 2001 From: tlericos at HUEY.MET.FSU.EDU (Todd Lericos) Date: Thu, 27 Dec 2001 16:41:47 Subject: Wind Profile/Boundary Problem (fwd) Message-ID: Just dropping a line to say I found the problem. I thought I would post to the group so that if anyone else encounters this problem they will be aware of what is happening. As stated earlier, I was using a formula to derive ubar in inabase3d.f. In that formula I was using zp(i,j,k). It appears that zp(i,j,k) is not defined at i=nx. Maybe an ARPS support person can chime in on this point. Because zp(i) was not defined at i=nx that column near the right boundary had ubar=0.0. This played havoc with the winds. Originally, I did not see because my arpsplt was too "zoomed out". Therefore, if any of you will ever use zp(i) to define a wind use the first element of i,j and leave k a variable. Like this .... ubar=0.007*zp(1,1,k) This will do the trick. Todd ---------- Forwarded message ---------- Date: Thu, 27 Dec 2001 11:41:30 -0500 (EST) From: Todd Lericos To: arpssupport at ou.edu Cc: arpsforum at listserv.ou.edu Subject: Wind Profile/Boundary Problem Okay, I have problem that someone can hopefully solve. This is a tough one. I am running ARPS using a modified Weisman and Klemp sounding (meaning I changed a few parameters in the formulas in inibase3d.f). Anyway, that part initializes just fine. In viniopt=2 I have two methods of creating a wind profile to go with the sounding. The first involves a formula that calculates ubar based on the height (m) of a particular level. I am using zp(i) for the height in the formula. Here is a sample... IF(k.le.2)THEN ubar(i,j,k) = -17.50 ENDIF IF(k.gt.2)THEN if(zs(i,j,k).lt.2500.)then ubar(i,j,k) = 0.0075*zs(i,j,k)-18.75 else ubar(i,j,k) = 0.0 endif ENDIF I also use a different method of initializing the wind field whereby I calculate the above equation by hand and have a simple IF/THEN statement to input the data. Here is a piece of that code.... IF(k.eq.1)THEN ubar(i,j,k) = -17.50 ENDIF IF(k.eq.2)THEN ubar(i,j,k) = -17.50 ENDIF IF(k.eq.3)THEN ubar(i,j,k) = -14.81 ENDIF IF(k.eq.4)THEN ubar(i,j,k) = -12.18 ENDIF IF(k.eq.5)THEN ubar(i,j,k) = -9.56 ENDIF .......................and so on... Here comes the interesting part, bear with me here. Either of these methods create a sounding with EXACTLY the same wind profile in runname.sound. However, the model runs are completly different (by the way, these runs are 2D). I have traced the cause to a boundary problem. Whenever I use the equation (method 1) of creating a wind profile, unstabilities are created along the boundary that result in a -10 m/s wind moving into the domain along the right boundary. This does not occur when using the manual input (method 2). WHY? The wind profiles for both methods are the same. I can't figure out what is causing that instability along the boundary. Maybe it has to do with my use of zp(i) in the formula. However, the numbers in output.sound are correct. Weird, isn't it??? I have been working the problem for two weeks and I'm stumped. I certainly would appreciate any help on the matter. Thanks in advance. Todd Lericos **************************************************************** * Todd P. Lericos * e-mail: tlericos at met.fsu.edu * * Research Assistant * phone : (850) 644-6989 (office) * * Fuelberg Lab * (850) 644-1452 (Lab) * * Department of Meteorology * office: Love Bldg Rm 311 * * Florida State University * * * Tallahassee, FL 32306-3034 * * **************************************************************** * * * "We are not concerned with our hopes and fears, only with * * the truth as far as we can discover it." * * -Charles Darwin * **************************************************************** From mxue at OU.EDU Thu Dec 27 20:23:47 2001 From: mxue at OU.EDU (Ming Xue) Date: Thu, 27 Dec 2001 20:23:47 Subject: Wind Profile/Boundary Problem (fwd) In-Reply-To: Message-ID: Todd, You are right that zp does not need to (an is not) defined at i=nx, hence the problem you ran into. Also, zp is defined at w point, not u point. The truly correct way is to use zp averaged to u point. There is at least one place in subroutine inibase that does so: CALL avgsu(zs,nx,ny,nz, 1,ny-1, 1,nz-1, zuv, ubar) ! ubar used as temp zuv is then used to defined ubar. Further, arpsplt does not plot points outside physical domain and *.sound file contains a sounding at the center of domain therefore the problem with ubar at i=nx is invisible with either. Ming Xue SOM/CAPS > -----Original Message----- > From: ARPS Discussion Forum [mailto:ARPSFORUM at LISTS.OU.EDU] > On Behalf Of Todd Lericos > Sent: Thursday, December 27, 2001 3:42 PM > To: ARPSFORUM at LISTS.OU.EDU > Subject: Wind Profile/Boundary Problem (fwd) > > > Just dropping a line to say I found the problem. I thought > I would post to the group so that if anyone else encounters this > problem they will be aware of what is happening. > > As stated earlier, I was using a formula to derive ubar > in inabase3d.f. In that formula I was using zp(i,j,k). It > appears that zp(i,j,k) is not defined at i=nx. Maybe an ARPS > support person can chime in on this point. Because > zp(i) was not defined at i=nx that column near the right > boundary had ubar=0.0. This played havoc with the winds. > Originally, I did not see because my arpsplt was too > "zoomed out". > > Therefore, if any of you will ever use zp(i) to define > a wind use the first element of i,j and leave k a variable. > > Like this .... > > ubar=0.007*zp(1,1,k) > > > This will do the trick. > > > Todd > > > > > > > ---------- Forwarded message ---------- > Date: Thu, 27 Dec 2001 11:41:30 -0500 (EST) > From: Todd Lericos > To: arpssupport at ou.edu > Cc: arpsforum at listserv.ou.edu > Subject: Wind Profile/Boundary Problem > > > > Okay, I have problem that someone can hopefully solve. > This is a tough one. I am running ARPS using a modified > Weisman and Klemp sounding (meaning I changed a few > parameters in the formulas in inibase3d.f). > > Anyway, that part initializes just fine. In viniopt=2 I have > two methods of creating a wind profile to go with the > sounding. The first involves a formula that calculates ubar > based on the height (m) of a particular level. I am using > zp(i) for the height in the formula. Here is a sample... > > IF(k.le.2)THEN > ubar(i,j,k) = -17.50 > ENDIF > > IF(k.gt.2)THEN > > if(zs(i,j,k).lt.2500.)then > ubar(i,j,k) = 0.0075*zs(i,j,k)-18.75 > else > ubar(i,j,k) = 0.0 > endif > > ENDIF > > I also use a different method > of initializing the wind field whereby I calculate the above > equation by hand and have a simple IF/THEN statement to > input the data. Here is a piece of that code.... > > > IF(k.eq.1)THEN > ubar(i,j,k) = -17.50 > ENDIF > IF(k.eq.2)THEN > ubar(i,j,k) = -17.50 > ENDIF > IF(k.eq.3)THEN > ubar(i,j,k) = -14.81 > ENDIF > IF(k.eq.4)THEN > ubar(i,j,k) = -12.18 > ENDIF > IF(k.eq.5)THEN > ubar(i,j,k) = -9.56 > ENDIF .......................and so on... > > > Here comes the interesting part, bear with me here. > Either of these methods create a sounding > with EXACTLY the same wind profile in runname.sound. > However, the model runs are completly different (by the way, > these runs are 2D). I have traced the cause to a boundary > problem. Whenever I use the equation (method 1) of creating > a wind profile, unstabilities are created along the boundary > that result in a -10 m/s wind moving into the domain along > the right boundary. This does not occur when using the > manual input (method 2). > > WHY? The wind profiles for both methods are the same. I > can't figure out what is causing that instability along the > boundary. Maybe it has to do with my use of zp(i) in the > formula. However, the numbers in output.sound are correct. > Weird, isn't it??? I have been working the problem for two > weeks and I'm stumped. > > I certainly would appreciate any help on the matter. > > Thanks in advance. > > Todd Lericos > > > > > > **************************************************************** > * Todd P. Lericos * e-mail: tlericos at met.fsu.edu * > * Research Assistant * phone : (850) 644-6989 (office) * > * Fuelberg Lab * (850) 644-1452 (Lab) * > * Department of Meteorology * office: Love Bldg Rm 311 * > * Florida State University * * > * Tallahassee, FL 32306-3034 * * > **************************************************************** > * * > * "We are not concerned with our hopes and fears, only with * > * the truth as far as we can discover it." * > * -Charles Darwin * > **************************************************************** > > ____________________________________________________________________ > You receive this message because you are currently subscribed > to the ARPS FORUM mailing list. If you do no wish to remain > on the list, you can unsubscribe by sending, USING THE SAME > E-MAIL ADDRESS AS ON THE LIST, to the > listserv at listserv.ou.edu with a single line mail body UNSUB ARPSFORUM > > You can also go to web interface at > http://lists.ou.edu/cgi-bin/wa?SUBED1> =arpsforum&A;=1 > to > subscribe and unscribe. > > For further > question or problem, e-mail arpssupport at ou.edu. > > From kd5giv at MESH.NET Sun Dec 30 14:35:58 2001 From: kd5giv at MESH.NET (Michael) Date: Sun, 30 Dec 2001 14:35:58 Subject: Arpstrn error message Message-ID: Hello, Could somebody tell me if there is any fixes too this error below from arpstrn. I used Red Hat Linux 7.0 and zxplot3 for Red Hat Linux 7.0. The error wasn't in Slackware 7.1. Also the output was done such as zxout.ps and runname.trndata. The name of this run is: dfw Input dx was 30000.000 meters Input dy was 30000.000 meters Input mapproj was 2 Input trulat1 was 60.000 degree North Input trulat2 was 30.000 degree North The latitude of the center of the model domain was 33.000 The longitude of the center of the model domain was -97.000 Input trulon was -97.000 degree East Input sclfct was 0.00000E+00 The sample internal in longitude dir. was set to 300 seconds. The sample internal in latitude dir. was set to 300 seconds. Finished reading namelist input file. jpole = 1 The cone constant is : 0.715566874 Map projection set to Lambert Conformal X origin, Y origin set to 0.,0. at the North Pole. Coordinate origin set to absolute x,y = -150000.00 -7529047.50 Latitude, longitude= 31.62 -98.60 dx,dy= 30000. 30000. lonmin, lonmax= -99.1728592 -94.8271408 latmin, latmax= 31.2085495 34.7798309 sw lat/lon, ne lat/lon= 31 -101 35 -94 imin,imax,jmin,jmax= -1211 -1127 661 709 hmin, hmax = 29. 869. hmin = 29.0000000000 at i= 82, j= 1 hmax = 869.000000000 at i= 1, j= 34 Finished reading terrain data. Min and max in the sampled terrain data array= 29.000 869.000 swlon_trn, swlat_trn= -101 31 lon_sample,lat_sample= 300 300 ARPSTRN: Great Lakes terrain ARPSTRN: Number of Great Lakes: 6 htrnmin = 74.7617874146 at i= 10, j= 2 htrnmax = 495.162292480 at i= 1, j= 2 Performing 9-point smoothing on input array Max/min in the analyzed terrain array was 445.827 99.092 ARPS format terrain file dfw.trndata created. PostScript output is in zxout.ps. Data IO unit 13 to be used for writing the PS file. m,m1,m2, n,n1,n2= 13 1 12 13 1 12 Min. terrain= 0.990923E+02, Max. terrain= 0.445827E+03 Number of contours < 10 ,Zinc is halved. Zinc= 0.125E+03 Number of contours < 10 ,Zinc is halved. Zinc= 0.625E+02 Number of contours < 10 ,Zinc is halved. Zinc= 0.312E+02 * Number of contours= 11 MIN= 0.9909E+02 MAX= 0.4458E+03 INC= 0.31250E+02 Work array xra and yra defined in XAREAFIL not large enough. Only 20000 number of pointed were used. Work array xra and yra defined in XAREAFIL not large enough. Only 20000 number of pointed were used. Work array xra and yra defined in XAREAFIL not large enough. Only 20000 number of pointed were used. Work array xra and yra defined in XAREAFIL not large enough. Only 20000 number of pointed were used. Work array xra and yra defined in XAREAFIL not large enough. Only 20000 number of pointed were used. Work array xra and yra defined in XAREAFIL not large enough. Only 20000 number of pointed were used. Work array xra and yra defined in XAREAFIL not large enough. Only 20000 number of pointed were used. Work array xra and yra defined in XAREAFIL not large enough. Only 20000 number of pointed were used. Work array xra and yra defined in XAREAFIL not large enough. Only 20000 number of pointed were used. Work array xra and yra defined in XAREAFIL not large enough. Only 20000 number of pointed were used. Work array xra and yra defined in XAREAFIL not large enough. Only 20000 number of pointed were used. Work array xra and yra defined in XAREAFIL not large enough. Only 20000 number of pointed were used. Work array xra and yra defined in XAREAFIL not large enough. Only 20000 number of pointed were used. Input was /usr/local/arps/data/arpsplt/us_spcounty.mapdata Input was /usr/local/arps/data/arpsplt/us_state.mapdata ___________________________________________________________ Michael Maxwell KD5GIV Storm Spotter, Not for idiots of Tarrant County but for me! Fort Worth, Texas 76116 From mxue at OU.EDU Sun Dec 30 18:12:08 2001 From: mxue at OU.EDU (Ming Xue) Date: Sun, 30 Dec 2001 18:12:08 Subject: Arpstrn error message In-Reply-To: <3C2F264E.25602.641D6@localhost> Message-ID: It's a warning message from ZXPLOT. It will not affect the terrain data output from arpstrn. You can try to get xpost3.f from ftp://ftp.caps.ou.edu/ZXPLOT3, increase npmax inside, and replace the original xpost3.o in zxplot package. Ming Xue > -----Original Message----- > From: ARPS Support (CAPS) [mailto:ARPSSUPPORT at LISTS.OU.EDU] > On Behalf Of Michael > Sent: Sunday, December 30, 2001 2:36 PM > To: ARPSSUPPORT at LISTS.OU.EDU > Subject: Arpstrn error message > > > Hello, Could somebody tell me if there is any fixes too this > error below from arpstrn. I used Red Hat Linux 7.0 and > zxplot3 for Red Hat Linux 7.0. The error wasn't in Slackware > 7.1. Also the output was done such as zxout.ps and runname.trndata. > > > The name of this run is: dfw > > > > Input dx was 30000.000 meters > > Input dy was 30000.000 meters > > Input mapproj was 2 > > Input trulat1 was 60.000 degree North > > Input trulat2 was 30.000 degree North > > The latitude of the center of the model domain > was 33.000 > > The longitude of the center of the model domain > was -97.000 > > Input trulon was -97.000 degree East > > Input sclfct was 0.00000E+00 > > The sample internal in longitude dir. was set to > 300 seconds. > > The sample internal in latitude dir. was set to > 300 seconds. > > Finished reading namelist input file. > > jpole = 1 > The cone constant is : 0.715566874 > Map projection set to Lambert Conformal > X origin, Y origin set to 0.,0. at the North > Pole. > > Coordinate origin set to absolute x,y = > -150000.00 -7529047.50 > Latitude, longitude= 31.62 > -98.60 > > dx,dy= 30000. 30000. > lonmin, lonmax= -99.1728592 -94.8271408 > latmin, latmax= 31.2085495 34.7798309 > sw lat/lon, ne lat/lon= 31 -101 35 -94 > imin,imax,jmin,jmax= -1211 -1127 661 709 > hmin, hmax = 29. 869. > hmin = 29.0000000000 at i= 82, j= > 1 hmax = 869.000000000 at i= 1, > j= 34 > > Finished reading terrain data. > > Min and max in the sampled terrain data array= > 29.000 869.000 > swlon_trn, swlat_trn= -101 31 > lon_sample,lat_sample= 300 300 > ARPSTRN: Great Lakes terrain > ARPSTRN: Number of Great Lakes: 6 > htrnmin = 74.7617874146 at i= 10, > j= 2 htrnmax = 495.162292480 at i= > 1, j= 2 > Performing 9-point smoothing on input array > > Max/min in the analyzed terrain array was > 445.827 99.092 > > ARPS format terrain file dfw.trndata created. > > > PostScript output is in zxout.ps. > Data IO unit 13 to be used for writing the PS > file. > > m,m1,m2, n,n1,n2= 13 1 12 13 1 12 > Min. terrain= 0.990923E+02, Max. terrain= > 0.445827E+03 > Number of contours < 10 ,Zinc is halved. Zinc= > 0.125E+03 > Number of contours < 10 ,Zinc is halved. Zinc= > 0.625E+02 > Number of contours < 10 ,Zinc is halved. Zinc= > 0.312E+02 > * Number of contours= 11 MIN= 0.9909E+02 > MAX= 0.4458E+03 INC= 0.31250E+02 > Work array xra and yra defined in XAREAFIL not > large enough. > Only 20000 > number of pointed were used. > > Work array xra and yra defined in XAREAFIL not > large enough. > Only 20000 > number of pointed were used. > > Work array xra and yra defined in XAREAFIL not > large enough. > Only 20000 > number of pointed were used. > > Work array xra and yra defined in XAREAFIL not > large enough. > Only 20000 > number of pointed were used. > > Work array xra and yra defined in XAREAFIL not > large enough. > Only 20000 > number of pointed were used. > > Work array xra and yra defined in XAREAFIL not > large enough. > Only 20000 > number of pointed were used. > > Work array xra and yra defined in XAREAFIL not > large enough. > Only 20000 > number of pointed were used. > > Work array xra and yra defined in XAREAFIL not > large enough. > Only 20000 > number of pointed were used. > > Work array xra and yra defined in XAREAFIL not large enough. > Only 20000 > number of pointed were used. > > Work array xra and yra defined in XAREAFIL not large enough. > Only 20000 > number of pointed were used. > > Work array xra and yra defined in XAREAFIL not large enough. > Only 20000 > number of pointed were used. > > Work array xra and yra defined in XAREAFIL not > large enough. > Only 20000 > number of pointed were used. > > Work array xra and yra defined in XAREAFIL not > large enough. > Only 20000 > number of pointed were used. > > Input was > /usr/local/arps/data/arpsplt/us_spcounty.mapdata > Input was > /usr/local/arps/data/arpsplt/us_state.mapdata > ___________________________________________________________ > Michael Maxwell > KD5GIV > Storm Spotter, Not for idiots of Tarrant County but for me! > Fort Worth, Texas 76116 > > From occlqf at HLAIRD.FREESERVE.CO.UK Sat Dec 15 09:15:11 2001 From: occlqf at HLAIRD.FREESERVE.CO.UK (Bernard Berry) Date: Sat, 15 Dec 2001 9:15:11 Subject: flexible tightfisted Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: inaccuracy.gif Type: image/gif Size: 12483 bytes Desc: not available URL: