From watson.leela at ensco.com Fri Dec 4 15:11:41 2009 From: watson.leela at ensco.com (Watson.Leela) Date: Fri, 4 Dec 2009 16:11:41 -0500 Subject: [ARPSSUPPORT] support for OU-soil option? Message-ID: <9CCF5909C0BD8444A73AA400374C62DA030EF1FC18@mb-ex07.ensco.win> Hello, Is there a timeline on support for the OU-soil option (soilopt = 2) in arps4wrf? Thanks! Leela Watson ********************************************************* Leela R. Watson, Meteorologist ENSCO, Inc. / Applied Meteorology Unit 1980 N. Atlantic Ave., Suite 830 Cocoa Beach, FL 32931 Voice: (321) 853-8264 Fax: (321) 853-8415 Email: watson.leela at ensco.com ________________________________ The information contained in this email message is intended only for the use of the individual(s) to whom it is addressed and may contain information that is privileged and sensitive. If you are not the intended recipient, or otherwise have received this communication in error, please notify the sender immediately by email at the above referenced address and note that any further dissemination, distribution or copying of this communication is strictly prohibited. The U.S. Export Control Laws regulate the export and re-export of technology originating in the United States. This includes the electronic transmission of information and software to foreign countries and to certain foreign nationals. Recipient agrees to abide by these laws and their regulations -- including the U.S. Department of Commerce Export Administration Regulations and the U.S. Department of State International Traffic in Arms Regulations -- and not to transfer, by electronic transmission or otherwise, any content derived from this email to either a foreign national or a foreign destination in violation of such laws. From ywang at gcn.ou.edu Fri Dec 4 16:14:26 2009 From: ywang at gcn.ou.edu (Yunheng Wang) Date: Fri, 04 Dec 2009 16:14:26 -0600 Subject: [ARPSSUPPORT] support for OU-soil option? In-Reply-To: <9CCF5909C0BD8444A73AA400374C62DA030EF1FC18@mb-ex07.ensco.win> References: <9CCF5909C0BD8444A73AA400374C62DA030EF1FC18@mb-ex07.ensco.win> Message-ID: <4B1989C2.5010901@gcn.ou.edu> We still do not have needs for that capability. FYI, OU-soil scheme is not well-maintained and it is not recommended. Actually, it will be straight-forward to add that capability based on what has been done for arps2wrf. I will remember your request and add it as long as I have time. Yunheng Wang. Watson.Leela wrote: > Hello, > > Is there a timeline on support for the OU-soil option (soilopt = 2) in arps4wrf? > > Thanks! > > Leela Watson > > ********************************************************* > Leela R. Watson, Meteorologist > ENSCO, Inc. / Applied Meteorology Unit > 1980 N. Atlantic Ave., Suite 830 > Cocoa Beach, FL 32931 > Voice: (321) 853-8264 > Fax: (321) 853-8415 > Email: watson.leela at ensco.com > > > ________________________________ > The information contained in this email message is intended only for the use of the individual(s) to whom it is addressed and may contain information that is privileged and sensitive. If you are not the intended recipient, or otherwise have received this communication in error, please notify the sender immediately by email at the above referenced address and note that any further dissemination, distribution or copying of this communication is strictly prohibited. > > The U.S. Export Control Laws regulate the export and re-export of technology originating in the United States. This includes the electronic transmission of information and software to foreign countries and to certain foreign nationals. Recipient agrees to abide by these laws and their regulations -- including the U.S. Department of Commerce Export Administration Regulations and the U.S. Department of State International Traffic in Arms Regulations -- and not to transfer, by electronic transmission or otherwise, any content derived from this email to either a foreign national or a foreign destination in violation of such laws. > _______________________________________________ > ARPSSUPPORT mailing list > ARPSSUPPORT at caps.ou.edu > http://www.caps.ou.edu/mailman/listinfo/arpssupport > > From evans.randy at ensco.com Tue Dec 8 16:32:22 2009 From: evans.randy at ensco.com (Evans.Randy) Date: Tue, 8 Dec 2009 17:32:22 -0500 Subject: [ARPSSUPPORT] high wind speeds at model top Message-ID: I am running ARPS 5.11.2 and have noticed that the wind speeds at the top level of the model increase steadily over the length of my 14 day (336 hr) run and the only layer where they are really large is the very top level. The model was run with a grid spacing of 50km resolution for the month of January over Europe. When the run finished I ran ext2arps for a nested 10 km grid resolution. Below is the ARPS extracted sounding at the 336 hr point from that ext2arps run. My setting for the Rayleigh damping were as follows: &rayleigh_damping raydmp = 2, cfrdmp = 0.0005, zbrdmp = 12000.0, / I tried setting cfrdmp=0.00333 also but it did not make any difference. Any suggestions on what to try? The large speeds at the top of the model never cause the model to go unstable but the problem keeps getting worse (larger wind speeds in the top level) for subsequent nested model runs. Randy Evans ENSCO, Inc. ARPS extracted sounding at idiag,jdiag k pres hgt temp theta dewp u v dir spd 43 81. 17450. -63.0 431.6 -89.1 80.4 -5.8 196.0 80.6 42 92. 16651. -62.7 416.6 -86.4 5.5 -8.7 249.4 10.4 41 104. 15856. -61.9 403.1 -83.1 4.6 -9.3 255.2 10.4 40 118. 15065. -61.0 390.4 -80.4 5.3 -10.1 254.3 11.4 39 134. 14278. -60.1 378.0 -78.7 6.0 -11.5 254.3 12.9 38 152. 13497. -58.9 366.8 -77.4 6.2 -13.2 256.6 14.5 37 172. 12723. -57.7 356.2 -75.8 5.5 -15.0 261.7 16.0 36 195. 11957. -56.7 345.6 -73.4 4.2 -17.0 268.1 17.5 35 219. 11200. -55.5 335.8 -69.9 2.8 -19.4 273.7 19.6 34 246. 10454. -54.0 327.2 -65.7 1.5 -21.7 277.8 21.8 33 276. 9722. -51.0 321.0 -60.5 0.3 -23.3 281.2 23.3 32 308. 9005. -46.6 317.3 -54.2 -1.0 -23.9 284.2 23.9 31 342. 8306. -41.5 314.9 -47.6 -2.0 -23.6 286.7 23.7 30 377. 7628. -36.2 313.0 -41.4 -2.7 -22.9 288.4 23.1 29 414. 6972. -31.3 311.2 -36.5 -3.2 -22.3 289.9 22.5 28 452. 6343. -26.6 309.3 -33.1 -3.8 -21.8 291.8 22.1 27 491. 5742. -22.2 307.5 -31.3 -4.8 -21.3 294.6 21.8 26 530. 5173. -18.1 305.7 -30.0 -6.0 -20.6 298.0 21.4 25 569. 4637. -14.5 303.8 -27.4 -7.0 -19.6 301.3 20.8 24 608. 4137. -11.5 301.6 -24.2 -7.7 -18.4 304.5 19.9 23 646. 3675. -9.1 299.3 -21.9 -8.1 -16.9 307.4 18.7 22 682. 3250. -7.2 296.7 -21.7 -8.2 -15.4 310.0 17.4 21 717. 2862. -5.8 294.1 -24.2 -8.1 -13.9 312.1 16.1 20 749. 2512. -5.0 291.2 -29.6 -7.6 -12.4 313.5 14.6 19 780. 2198. -4.6 288.3 -37.7 -6.9 -10.9 314.1 12.9 18 808. 1917. -4.4 285.6 -44.1 -6.1 -9.5 314.4 11.3 17 834. 1668. -4.3 283.1 -39.3 -5.3 -8.2 314.8 9.8 16 858. 1447. -4.0 281.2 -31.5 -4.8 -7.2 315.4 8.6 15 879. 1253. -3.6 279.7 -25.6 -4.4 -6.5 315.9 7.9 14 899. 1081. -3.0 278.5 -21.4 -4.1 -6.1 316.1 7.3 13 916. 930. -2.4 277.6 -18.4 -3.8 -5.7 315.6 6.9 12 931. 797. -1.9 276.8 -16.2 -3.5 -5.5 314.3 6.5 11 945. 679. -1.4 276.2 -14.2 -3.2 -5.3 312.8 6.1 10 958. 575. -1.0 275.6 -12.2 -3.0 -5.1 312.4 5.9 9 969. 482. -0.7 274.9 -10.0 -3.2 -4.9 314.9 5.8 8 979. 398. -0.7 274.1 -8.0 -3.8 -4.8 320.3 6.1 7 988. 322. -0.8 273.2 -6.3 -4.6 -4.8 325.9 6.7 6 997. 253. -0.9 272.5 -4.3 -5.1 -4.8 328.6 7.1 5 1005. 190. -0.7 272.1 -2.4 -5.0 -4.8 327.7 6.9 4 1012. 131. -0.6 271.6 -1.3 -4.1 -4.5 323.8 6.1 3 1019. 76. -1.0 270.7 -1.3 -3.1 -4.2 318.1 5.2 2 1026. 25. -1.4 269.8 -1.6 -2.3 -3.9 312.9 4.5 1 1032. -25. -1.7 268.9 -2.0 -2.0 -3.7 310.1 4.2 ________________________________ The information contained in this email message is intended only for the use of the individual(s) to whom it is addressed and may contain information that is privileged and sensitive. If you are not the intended recipient, or otherwise have received this communication in error, please notify the sender immediately by email at the above referenced address and note that any further dissemination, distribution or copying of this communication is strictly prohibited. The U.S. Export Control Laws regulate the export and re-export of technology originating in the United States. This includes the electronic transmission of information and software to foreign countries and to certain foreign nationals. Recipient agrees to abide by these laws and their regulations -- including the U.S. Department of Commerce Export Administration Regulations and the U.S. Department of State International Traffic in Arms Regulations -- and not to transfer, by electronic transmission or otherwise, any content derived from this email to either a foreign national or a foreign destination in violation of such laws. From kwthomas at wizard.caps.ou.edu Tue Dec 8 16:56:21 2009 From: kwthomas at wizard.caps.ou.edu (Kevin W. Thomas) Date: Tue, 8 Dec 2009 16:56:21 -0600 Subject: [ARPSSUPPORT] high wind speeds at model top Message-ID: <200912082256.nB8MuLew016980@wizard.caps.ou.edu> >I am running ARPS 5.11.2 and have noticed that the wind speeds at the top level of the model increase steadily over the length of my 14 day (336 hr) run and the only layer where they are really large is the very top level. The model was run with a grid spacing of 50km resolution for the month of January over Europe. When the run finished I ran ext2arps for a nested 10 km grid resolution. Below is the ARPS extracted sounding at the 336 hr point from that ext2arps run. > >My setting for the Rayleigh damping were as follows: > > > &rayleigh_damping > raydmp = 2, > cfrdmp = 0.0005, > zbrdmp = 12000.0, > / > >I tried setting cfrdmp=0.00333 also but it did not make any difference. > >Any suggestions on what to try? The large speeds at the top of the model never cause the model to go unstable but the problem keeps getting worse (larger wind speeds in the top level) for subsequent nested model runs. > >Randy Evans >ENSCO, Inc. > > > > >ARPS extracted sounding at idiag,jdiag > k pres hgt temp theta dewp u v dir spd > 43 81. 17450. -63.0 431.6 -89.1 80.4 -5.8 196.0 80.6 You can safely *ignore* the data at the top level. The wind values aren't real data, and they aren't affecting anything. That's why nothing is crashing. > 42 92. 16651. -62.7 416.6 -86.4 5.5 -8.7 249.4 10.4 > 41 104. 15856. -61.9 403.1 -83.1 4.6 -9.3 255.2 10.4 Kevin W. Thomas Center for Analysis and Prediction of Storms University of Oklahoma Norman, Oklahoma Email: kwthomas at ou.edu From mxue at ou.edu Tue Dec 8 23:43:25 2009 From: mxue at ou.edu (Xue, Ming) Date: Wed, 9 Dec 2009 05:43:25 +0000 Subject: [ARPSSUPPORT] high wind speeds at model top In-Reply-To: <200912082256.nB8MuLew016980@wizard.caps.ou.edu> References: <200912082256.nB8MuLew016980@wizard.caps.ou.edu> Message-ID: <98A933070F0F8A42BFE4EE5770ED0156086DD5@it-lightning.sooner.net.ou.edu> Kevin is correct - u and v at k=nz is never used by the model. Please refer to chapter 6 of ARPS User Guide for ARPS grid setup. Also, it is strongly recommended that arpsintrp be used to prepare data for arps nested inside arps. Ext2arps can be problematic for this purpose. Ming Xue -----Original Message----- From: arpssupport-bounces at caps.ou.edu [mailto:arpssupport-bounces at caps.ou.edu] On Behalf Of Kevin W. Thomas Sent: 2009?12?8? 16:56 To: arpssupport; evans.randy at ensco.com Subject: Re: [ARPSSUPPORT] high wind speeds at model top >I am running ARPS 5.11.2 and have noticed that the wind speeds at the top level of the model increase steadily over the length of my 14 day (336 hr) run and the only layer where they are really large is the very top level. The model was run with a grid spacing of 50km resolution for the month of January over Europe. When the run finished I ran ext2arps for a nested 10 km grid resolution. Below is the ARPS extracted sounding at the 336 hr point from that ext2arps run. > >My setting for the Rayleigh damping were as follows: > > > &rayleigh_damping > raydmp = 2, > cfrdmp = 0.0005, > zbrdmp = 12000.0, > / > >I tried setting cfrdmp=0.00333 also but it did not make any difference. > >Any suggestions on what to try? The large speeds at the top of the model never cause the model to go unstable but the problem keeps getting worse (larger wind speeds in the top level) for subsequent nested model runs. > >Randy Evans >ENSCO, Inc. > > > > >ARPS extracted sounding at idiag,jdiag > k pres hgt temp theta dewp u v dir spd > 43 81. 17450. -63.0 431.6 -89.1 80.4 -5.8 196.0 80.6 You can safely *ignore* the data at the top level. The wind values aren't real data, and they aren't affecting anything. That's why nothing is crashing. > 42 92. 16651. -62.7 416.6 -86.4 5.5 -8.7 249.4 10.4 > 41 104. 15856. -61.9 403.1 -83.1 4.6 -9.3 255.2 10.4 Kevin W. Thomas Center for Analysis and Prediction of Storms University of Oklahoma Norman, Oklahoma Email: kwthomas at ou.edu _______________________________________________ ARPSSUPPORT mailing list ARPSSUPPORT at caps.ou.edu http://www.caps.ou.edu/mailman/listinfo/arpssupport -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 7536 bytes Desc: not available URL: From otem234 at gmail.com Wed Dec 9 09:33:58 2009 From: otem234 at gmail.com (Henry Wang) Date: Wed, 9 Dec 2009 09:33:58 -0600 Subject: [ARPSSUPPORT] Fwd: Running arpspltpost on Kraken In-Reply-To: <4B1DB840.1050000@gcn.ou.edu> References: <0E417849E655C145BFE45888043B2EA60EA5757C@it-monad.sooner.net.ou.edu> <4B1DB840.1050000@gcn.ou.edu> Message-ID: Sorry, this message was supposed to be sent the day before yesterday, but it was delayed because a wrong email configuration. Brett, Let me if you got this message or you have solved your problem. Please direct further questions to arpssupport at caps.ou.edu. Thanks. Yunheng. ---------- Forwarded message ---------- From: Yunheng Wang Date: Mon, Dec 7, 2009 at 8:21 PM Subject: Re: Running arpspltpost on Kraken To: "Roberts, Brett J." Cc: "arpssupport at caps.ou.edu" Need more details. Maybe you do not have enough memory for the second plot? Yunheng. Roberts, Brett J. wrote: > Yunheng, > > I am trying to run arpspltpost on kraken to produce graphics for two > high-resolution (100m and 50m) ARPS runs I recently completed. For some > reason, I'm able to plot for the 100m run without any problems, but cannot > successfully run arpsplt for the 50m run. After entering the following > command: > > ../../../arps5.2.11/bin/arpspltpost < arpsplt_0050m.input >! arpsplt.output > > I get a "Killed" message after several minutes. > > I'm using the exact same arpsplt.input file for this run as I am for the > one that can be successfully plotted. > > Do you have any ideas what may be causing this? > > Thanks, > Brett > From otem234 at gmail.com Wed Dec 9 09:36:26 2009 From: otem234 at gmail.com (Henry Wang) Date: Wed, 9 Dec 2009 09:36:26 -0600 Subject: [ARPSSUPPORT] Fwd: high wind speeds at model top In-Reply-To: <4B1EF295.7070300@gcn.ou.edu> References: <4B1EF295.7070300@gcn.ou.edu> Message-ID: This message was supposed to be send yesterday. It was delayed because wrong configuration with my email client at home. Sorry. Yunheng. ---------- Forwarded message ---------- From: Yunheng Wang Date: Tue, Dec 8, 2009 at 6:43 PM Subject: Re: [ARPSSUPPORT] high wind speeds at model top To: "Evans.Randy" Cc: "arpssupport at ou.edu" Hi Evans, For nesting runs, please use arpsintrp instead of ext2arps. We have found that ext2arps generates unrealistic hight wind speed at top level. Please read this file http://www.caps.ou.edu/ARPS/cgi-bin/cvsweb.cgi/arps5.2/input/arps.input?annotate=1.121about line 2900 for more details. Yunheng Wang. Evans.Randy wrote: > I am running ARPS 5.11.2 and have noticed that the wind speeds at the top > level of the model increase steadily over the length of my 14 day (336 hr) > run and the only layer where they are really large is the very top level. > The model was run with a grid spacing of 50km resolution for the month of > January over Europe. When the run finished I ran ext2arps for a nested 10 km > grid resolution. Below is the ARPS extracted sounding at the 336 hr point > from that ext2arps run. > > My setting for the Rayleigh damping were as follows: > > > &rayleigh_damping > raydmp = 2, > cfrdmp = 0.0005, > zbrdmp = 12000.0, > / > > I tried setting cfrdmp=0.00333 also but it did not make any difference. > > Any suggestions on what to try? The large speeds at the top of the model > never cause the model to go unstable but the problem keeps getting worse > (larger wind speeds in the top level) for subsequent nested model runs. > > Randy Evans > ENSCO, Inc. > > > > > ARPS extracted sounding at idiag,jdiag > k pres hgt temp theta dewp u v dir spd > 43 81. 17450. -63.0 431.6 -89.1 80.4 -5.8 196.0 80.6 > 42 92. 16651. -62.7 416.6 -86.4 5.5 -8.7 249.4 10.4 > 41 104. 15856. -61.9 403.1 -83.1 4.6 -9.3 255.2 10.4 > 40 118. 15065. -61.0 390.4 -80.4 5.3 -10.1 254.3 11.4 > 39 134. 14278. -60.1 378.0 -78.7 6.0 -11.5 254.3 12.9 > 38 152. 13497. -58.9 366.8 -77.4 6.2 -13.2 256.6 14.5 > 37 172. 12723. -57.7 356.2 -75.8 5.5 -15.0 261.7 16.0 > 36 195. 11957. -56.7 345.6 -73.4 4.2 -17.0 268.1 17.5 > 35 219. 11200. -55.5 335.8 -69.9 2.8 -19.4 273.7 19.6 > 34 246. 10454. -54.0 327.2 -65.7 1.5 -21.7 277.8 21.8 > 33 276. 9722. -51.0 321.0 -60.5 0.3 -23.3 281.2 23.3 > 32 308. 9005. -46.6 317.3 -54.2 -1.0 -23.9 284.2 23.9 > 31 342. 8306. -41.5 314.9 -47.6 -2.0 -23.6 286.7 23.7 > 30 377. 7628. -36.2 313.0 -41.4 -2.7 -22.9 288.4 23.1 > 29 414. 6972. -31.3 311.2 -36.5 -3.2 -22.3 289.9 22.5 > 28 452. 6343. -26.6 309.3 -33.1 -3.8 -21.8 291.8 22.1 > 27 491. 5742. -22.2 307.5 -31.3 -4.8 -21.3 294.6 21.8 > 26 530. 5173. -18.1 305.7 -30.0 -6.0 -20.6 298.0 21.4 > 25 569. 4637. -14.5 303.8 -27.4 -7.0 -19.6 301.3 20.8 > 24 608. 4137. -11.5 301.6 -24.2 -7.7 -18.4 304.5 19.9 > 23 646. 3675. -9.1 299.3 -21.9 -8.1 -16.9 307.4 18.7 > 22 682. 3250. -7.2 296.7 -21.7 -8.2 -15.4 310.0 17.4 > 21 717. 2862. -5.8 294.1 -24.2 -8.1 -13.9 312.1 16.1 > 20 749. 2512. -5.0 291.2 -29.6 -7.6 -12.4 313.5 14.6 > 19 780. 2198. -4.6 288.3 -37.7 -6.9 -10.9 314.1 12.9 > 18 808. 1917. -4.4 285.6 -44.1 -6.1 -9.5 314.4 11.3 > 17 834. 1668. -4.3 283.1 -39.3 -5.3 -8.2 314.8 9.8 > 16 858. 1447. -4.0 281.2 -31.5 -4.8 -7.2 315.4 8.6 > 15 879. 1253. -3.6 279.7 -25.6 -4.4 -6.5 315.9 7.9 > 14 899. 1081. -3.0 278.5 -21.4 -4.1 -6.1 316.1 7.3 > 13 916. 930. -2.4 277.6 -18.4 -3.8 -5.7 315.6 6.9 > 12 931. 797. -1.9 276.8 -16.2 -3.5 -5.5 314.3 6.5 > 11 945. 679. -1.4 276.2 -14.2 -3.2 -5.3 312.8 6.1 > 10 958. 575. -1.0 275.6 -12.2 -3.0 -5.1 312.4 5.9 > 9 969. 482. -0.7 274.9 -10.0 -3.2 -4.9 314.9 5.8 > 8 979. 398. -0.7 274.1 -8.0 -3.8 -4.8 320.3 6.1 > 7 988. 322. -0.8 273.2 -6.3 -4.6 -4.8 325.9 6.7 > 6 997. 253. -0.9 272.5 -4.3 -5.1 -4.8 328.6 7.1 > 5 1005. 190. -0.7 272.1 -2.4 -5.0 -4.8 327.7 6.9 > 4 1012. 131. -0.6 271.6 -1.3 -4.1 -4.5 323.8 6.1 > 3 1019. 76. -1.0 270.7 -1.3 -3.1 -4.2 318.1 5.2 > 2 1026. 25. -1.4 269.8 -1.6 -2.3 -3.9 312.9 4.5 > 1 1032. -25. -1.7 268.9 -2.0 -2.0 -3.7 310.1 4.2 > > ________________________________ > The information contained in this email message is intended only for the > use of the individual(s) to whom it is addressed and may contain information > that is privileged and sensitive. If you are not the intended recipient, or > otherwise have received this communication in error, please notify the > sender immediately by email at the above referenced address and note that > any further dissemination, distribution or copying of this communication is > strictly prohibited. > > The U.S. Export Control Laws regulate the export and re-export of > technology originating in the United States. This includes the electronic > transmission of information and software to foreign countries and to certain > foreign nationals. Recipient agrees to abide by these laws and their > regulations -- including the U.S. Department of Commerce Export > Administration Regulations and the U.S. Department of State International > Traffic in Arms Regulations -- and not to transfer, by electronic > transmission or otherwise, any content derived from this email to either a > foreign national or a foreign destination in violation of such laws. > _______________________________________________ > ARPSSUPPORT mailing list > ARPSSUPPORT at caps.ou.edu > http://www.caps.ou.edu/mailman/listinfo/arpssupport > > > From kwthomas at wizard.caps.ou.edu Wed Dec 9 09:50:00 2009 From: kwthomas at wizard.caps.ou.edu (Kevin W. Thomas) Date: Wed, 9 Dec 2009 09:50:00 -0600 (CST) Subject: [ARPSSUPPORT] Fwd: Running arpspltpost on Kraken Message-ID: <200912091550.nB9Fo07c018101@wizard.caps.ou.edu> >Sorry, this message was supposed to be sent the day before yesterday, but it >was delayed because a wrong email configuration. > >Brett, Let me if you got this message or you have solved your problem. >Please direct further questions to arpssupport at caps.ou.edu. > >Thanks. >Yunheng. Brett... This was likely the OOM ("Out Of Memory") killer that zapped your process. This means your job likely caused the system to use up all the memory. The choices become either kill off the offending job, or for the machine to crash. Before OOM software was developed, machines *would* crash. Are you running this on one of the login nodes? If so, this is very bad, and can get you nasty messages from Systems people. This job should be run on the compute nodes. The compute nodes have 16gb of memory, while the login nodes have 8gb. On the compute nodes, you'll have exclusive machine access. On the login nodes, you are competing with compiles, and other normal UNIX/Linux commands. If you still have OOM issues, you'll have to run the program MPI'd, though I suspect this won't be necessary. You might also consider "arpspltncar". It produces *MUCH* better quality graphics. Kevin Thomas >---------- Forwarded message ---------- >From: Yunheng Wang >Date: Mon, Dec 7, 2009 at 8:21 PM >Subject: Re: Running arpspltpost on Kraken >To: "Roberts, Brett J." >Cc: "arpssupport at caps.ou.edu" > > >Need more details. Maybe you do not have enough memory for the second plot? > >Yunheng. > > >Roberts, Brett J. wrote: > >> Yunheng, >> >> I am trying to run arpspltpost on kraken to produce graphics for two >> high-resolution (100m and 50m) ARPS runs I recently completed. For some >> reason, I'm able to plot for the 100m run without any problems, but cannot >> successfully run arpsplt for the 50m run. After entering the following >> command: >> >> ../../../arps5.2.11/bin/arpspltpost < arpsplt_0050m.input >! arpsplt.output >> >> I get a "Killed" message after several minutes. >> >> I'm using the exact same arpsplt.input file for this run as I am for the >> one that can be successfully plotted. >> >> Do you have any ideas what may be causing this? >> >> Thanks, >> Brett >> >_______________________________________________ >ARPSSUPPORT mailing list >ARPSSUPPORT at caps.ou.edu >http://www.caps.ou.edu/mailman/listinfo/arpssupport > From watson.leela at ensco.com Sat Dec 12 15:10:43 2009 From: watson.leela at ensco.com (Watson.Leela) Date: Sat, 12 Dec 2009 16:10:43 -0500 Subject: [ARPSSUPPORT] FW: bizzare output from ext2arps, adas Message-ID: <9CCF5909C0BD8444A73AA400374C62DA030EF1FFBC@mb-ex07.ensco.win> From: Watson.Leela Sent: Saturday, December 12, 2009 1:21 PM To: arpssupport at caps.ou.edu Subject: bizzare output from ext2arps, adas Hello, I am desperate for some help! I am running ext2arps and adas and getting some bizarre results. Attached are some files that show wind speed from the output of ext2arps (ext2arps_output.jpeg), from the raw RUC 13 km background model data (ruc13_200911250000.gif), and the adas output for the same time (adas_output.jpeg). 1) The output of surface wind speed from ext2arps is grossly different from the raw RUC data. It completely misses the wind speeds and it only outputs data over the Florida peninsula. Is this normal? I have also attached my input file for ext2arps (FL_ext2arps.input). 2) There are large bullseyes for surface winds around the radar locations in Florida in the output from adas. How can I resolve this issue? Leela Watson ********************************************************* Leela R. Watson, Meteorologist ENSCO, Inc. / Applied Meteorology Unit 1980 N. Atlantic Ave., Suite 830 Cocoa Beach, FL 32931 Voice: (321) 853-8264 Fax: (321) 853-8415 Email: watson.leela at ensco.com ________________________________ The information contained in this email message is intended only for the use of the individual(s) to whom it is addressed and may contain information that is privileged and sensitive. If you are not the intended recipient, or otherwise have received this communication in error, please notify the sender immediately by email at the above referenced address and note that any further dissemination, distribution or copying of this communication is strictly prohibited. The U.S. Export Control Laws regulate the export and re-export of technology originating in the United States. This includes the electronic transmission of information and software to foreign countries and to certain foreign nationals. Recipient agrees to abide by these laws and their regulations -- including the U.S. Department of Commerce Export Administration Regulations and the U.S. Department of State International Traffic in Arms Regulations -- and not to transfer, by electronic transmission or otherwise, any content derived from this email to either a foreign national or a foreign destination in violation of such laws. -------------- next part -------------- A non-text attachment was scrubbed... Name: ruc13_200911250000.gif Type: image/gif Size: 65098 bytes Desc: ruc13_200911250000.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FL_ext2arps.input Type: application/octet-stream Size: 125339 bytes Desc: FL_ext2arps.input URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ext2arps_output.jpeg Type: image/jpeg Size: 47303 bytes Desc: ext2arps_output.jpeg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: adas_output.jpeg Type: image/jpeg Size: 54005 bytes Desc: adas_output.jpeg URL: From kbrews at gcn.ou.edu Tue Dec 15 11:36:10 2009 From: kbrews at gcn.ou.edu (Keith Brewster) Date: Tue, 15 Dec 2009 11:36:10 -0600 Subject: [ARPSSUPPORT] FW: bizzare output from ext2arps, adas In-Reply-To: <9CCF5909C0BD8444A73AA400374C62DA030EF1FFBC@mb-ex07.ensco.win> References: <9CCF5909C0BD8444A73AA400374C62DA030EF1FFBC@mb-ex07.ensco.win> Message-ID: <000301ca7dad$17610950$46231bf0$@ou.edu> Due to some deadlines Monday I just had a chance to look at this. I agree something is not right. First realize that your dzmin is 500m so your first level is 250m above the ground. You are not using the sfc data from the model (extsfcopt=0) so you are only using the pressure level data. That said it seems to me you should still see some more structure in your wind fields over the ocean. Can you email me the RUC file that you used or put it on an ftp site and I will test it here. Regarding ADAS, you didn't send your ADAS input file, but 1) it seems you have too small a value for xyrange, 2) it is trying to correct problem with the background and apparently it only has data at that radar sites. -Keith -----Original Message----- From: arpssupport-bounces at caps.ou.edu [mailto:arpssupport-bounces at caps.ou.edu] On Behalf Of Watson.Leela Sent: Saturday, December 12, 2009 3:11 PM To: arpssupport at caps.ou.edu Subject: [ARPSSUPPORT] FW: bizzare output from ext2arps, adas From: Watson.Leela Sent: Saturday, December 12, 2009 1:21 PM To: arpssupport at caps.ou.edu Subject: bizzare output from ext2arps, adas Hello, I am desperate for some help! I am running ext2arps and adas and getting some bizarre results. Attached are some files that show wind speed from the output of ext2arps (ext2arps_output.jpeg), from the raw RUC 13 km background model data (ruc13_200911250000.gif), and the adas output for the same time (adas_output.jpeg). 1) The output of surface wind speed from ext2arps is grossly different from the raw RUC data. It completely misses the wind speeds and it only outputs data over the Florida peninsula. Is this normal? I have also attached my input file for ext2arps (FL_ext2arps.input). 2) There are large bullseyes for surface winds around the radar locations in Florida in the output from adas. How can I resolve this issue? Leela Watson ********************************************************* Leela R. Watson, Meteorologist ENSCO, Inc. / Applied Meteorology Unit 1980 N. Atlantic Ave., Suite 830 Cocoa Beach, FL 32931 Voice: (321) 853-8264 Fax: (321) 853-8415 Email: watson.leela at ensco.com ________________________________ The information contained in this email message is intended only for the use of the individual(s) to whom it is addressed and may contain information that is privileged and sensitive. If you are not the intended recipient, or otherwise have received this communication in error, please notify the sender immediately by email at the above referenced address and note that any further dissemination, distribution or copying of this communication is strictly prohibited. The U.S. Export Control Laws regulate the export and re-export of technology originating in the United States. This includes the electronic transmission of information and software to foreign countries and to certain foreign nationals. Recipient agrees to abide by these laws and their regulations -- including the U.S. Department of Commerce Export Administration Regulations and the U.S. Department of State International Traffic in Arms Regulations -- and not to transfer, by electronic transmission or otherwise, any content derived from this email to either a foreign national or a foreign destination in violation of such laws. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.716 / Virus Database: 270.14.107/2564 - Release Date: 12/14/09 01:37:00 From wm.wang at siat.ac.cn Tue Dec 15 21:06:52 2009 From: wm.wang at siat.ac.cn (Weimin Wang) Date: Wed, 16 Dec 2009 11:06:52 +0800 Subject: [ARPSSUPPORT] error with compile 88d2arps Message-ID: <6a88388a0912151906h66bd5ab9qd8d134d88cb148b6@mail.gmail.com> Hello, When I try to compile 88d2arps with pgf90 and pgcc, errors display as, Thank you for suggestions in advance. ./makearps -f pgf90 -c pgcc -io nohdf 88d2arps 88d2arps.o: In function `main': 88d2arps.c:(.text+0x810): undefined reference to `initpara' 88d2arps.c:(.text+0x1a9c): undefined reference to `get_from_namelist' 88d2arps.c:(.text+0x1d7d): undefined reference to `get_infilname' 88d2arps.c:(.text+0x1eb4): undefined reference to `get_gridxyzzp' 88d2arps.c:(.text+0x1ee4): undefined reference to `mapinit' 88d2arps.c:(.text+0x1f89): undefined reference to `radcoord' 88d2arps.c:(.text+0x2143): undefined reference to `rdenvprf' 88d2arps.c:(.text+0x2383): undefined reference to `readuvt' 88d2arps.c:(.text+0x2519): undefined reference to `extenvprf2' 88d2arps.c:(.text+0x25ab): undefined reference to `set_lbcopt' 88d2arps.c:(.text+0x327c): undefined reference to `initgrdvar' 88d2arps.c:(.text+0x3499): undefined reference to `radcoord' 88d2arps.c:(.text+0x3754): undefined reference to `extenvprf' 88d2arps.c:(.text+0x3f16): undefined reference to `ctim2abss' 88d2arps.c:(.text+0x4512): undefined reference to `ctim2abss' 88d2arps.c:(.text+0x4a2f): undefined reference to `ctim2abss' 88d2arps.c:(.text+0x4be1): undefined reference to `rmpinit' 88d2arps.c:(.text+0x4ca7): undefined reference to `despekl' 88d2arps.c:(.text+0x4e86): undefined reference to `volbuild' 88d2arps.c:(.text+0x4f40): undefined reference to `despekl' 88d2arps.c:(.text+0x50a6): undefined reference to `unfnqc' 88d2arps.c:(.text+0x51df): undefined reference to `volbuild' 88d2arps.c:(.text+0x5333): undefined reference to `volbuild' 88d2arps.c:(.text+0x5d5c): undefined reference to `rmpinit' 88d2arps.c:(.text+0x5e22): undefined reference to `despekl' 88d2arps.c:(.text+0x5f5b): undefined reference to `volbuild' 88d2arps.c:(.text+0x6008): undefined reference to `despekl' 88d2arps.c:(.text+0x617b): undefined reference to `unfnqc' 88d2arps.c:(.text+0x62b4): undefined reference to `volbuild' 88d2arps.c:(.text+0x6408): undefined reference to `volbuild' 88d2arps.o: In function `output_free_radar_volume': 88d2arps.c:(.text+0x732b): undefined reference to `apdetect' 88d2arps.c:(.text+0x73ef): undefined reference to `mkradfnm' 88d2arps.c:(.text+0x77ad): undefined reference to `remapvol' 88d2arps.c:(.text+0x79c2): undefined reference to `remap2dcts' 88d2arps.c:(.text+0x7c7b): undefined reference to `remap2d' 88d2arps.c:(.text+0x7e92): undefined reference to `quadfit' 88d2arps.c:(.text+0x7f40): undefined reference to `abss2ctim' 88d2arps.c:(.text+0x8159): undefined reference to `abss2ctim' 88d2arps.c:(.text+0x8474): undefined reference to `abss2ctim' 88d2arps.c:(.text+0x86ae): undefined reference to `abss2ctim' 88d2arps.c:(.text+0x89f6): undefined reference to `mkvadfnm' 88d2arps.c:(.text+0x8af3): undefined reference to `vadvol' 88d2arps.c:(.text+0x8b5c): undefined reference to `wtvadprf' 88d2arps.c:(.text+0x8efc): undefined reference to `remapvol' 88d2arps.c:(.text+0x910e): undefined reference to `remap2dcts' 88d2arps.c:(.text+0x93c7): undefined reference to `remap2d' 88d2arps.c:(.text+0x95d4): undefined reference to `wtradcol' 88d2arps.c:(.text+0x9772): undefined reference to `wrttilts' 88d2arps.c:(.text+0x98bb): undefined reference to `wrtgridtilt' make[1]: *** [/home/wmwang/soft/arps5.2.12/bin/88d2arps] Error 2 make[1]: Leaving directory `/home/wmwang/soft/arps5.2.12/src/88d2arps' make: *** [88d2arps] Error 2 From wmwang at gmail.com Wed Dec 16 08:54:14 2009 From: wmwang at gmail.com (Weimin Wang) Date: Wed, 16 Dec 2009 22:54:14 +0800 Subject: [ARPSSUPPORT] error with compile 88d2arps In-Reply-To: <6a88388a0912151906h66bd5ab9qd8d134d88cb148b6@mail.gmail.com> References: <6a88388a0912151906h66bd5ab9qd8d134d88cb148b6@mail.gmail.com> Message-ID: <6a88388a0912160654y635a3ce8ya0028c63f0f2ce5b@mail.gmail.com> hello, after compile all codes of arps, I have solved this problem. However, I get another question with using 88d2arps. I did not find adas.input, but arps.input. Which variables should I specify in arps.input for runing 88d2arps? On Wed, Dec 16, 2009 at 11:06 AM, Weimin Wang wrote: > Hello, > > When I try to compile 88d2arps with pgf90 and pgcc, errors display as, > > Thank you for suggestions in advance. > > ./makearps -f pgf90 -c pgcc -io nohdf 88d2arps > > 88d2arps.o: In function `main': > 88d2arps.c:(.text+0x810): undefined reference to `initpara' > 88d2arps.c:(.text+0x1a9c): undefined reference to `get_from_namelist' > 88d2arps.c:(.text+0x1d7d): undefined reference to `get_infilname' > 88d2arps.c:(.text+0x1eb4): undefined reference to `get_gridxyzzp' > 88d2arps.c:(.text+0x1ee4): undefined reference to `mapinit' > 88d2arps.c:(.text+0x1f89): undefined reference to `radcoord' > 88d2arps.c:(.text+0x2143): undefined reference to `rdenvprf' > 88d2arps.c:(.text+0x2383): undefined reference to `readuvt' > 88d2arps.c:(.text+0x2519): undefined reference to `extenvprf2' > 88d2arps.c:(.text+0x25ab): undefined reference to `set_lbcopt' > 88d2arps.c:(.text+0x327c): undefined reference to `initgrdvar' > 88d2arps.c:(.text+0x3499): undefined reference to `radcoord' > 88d2arps.c:(.text+0x3754): undefined reference to `extenvprf' > 88d2arps.c:(.text+0x3f16): undefined reference to `ctim2abss' > 88d2arps.c:(.text+0x4512): undefined reference to `ctim2abss' > 88d2arps.c:(.text+0x4a2f): undefined reference to `ctim2abss' > 88d2arps.c:(.text+0x4be1): undefined reference to `rmpinit' > 88d2arps.c:(.text+0x4ca7): undefined reference to `despekl' > 88d2arps.c:(.text+0x4e86): undefined reference to `volbuild' > 88d2arps.c:(.text+0x4f40): undefined reference to `despekl' > 88d2arps.c:(.text+0x50a6): undefined reference to `unfnqc' > 88d2arps.c:(.text+0x51df): undefined reference to `volbuild' > 88d2arps.c:(.text+0x5333): undefined reference to `volbuild' > 88d2arps.c:(.text+0x5d5c): undefined reference to `rmpinit' > 88d2arps.c:(.text+0x5e22): undefined reference to `despekl' > 88d2arps.c:(.text+0x5f5b): undefined reference to `volbuild' > 88d2arps.c:(.text+0x6008): undefined reference to `despekl' > 88d2arps.c:(.text+0x617b): undefined reference to `unfnqc' > 88d2arps.c:(.text+0x62b4): undefined reference to `volbuild' > 88d2arps.c:(.text+0x6408): undefined reference to `volbuild' > 88d2arps.o: In function `output_free_radar_volume': > 88d2arps.c:(.text+0x732b): undefined reference to `apdetect' > 88d2arps.c:(.text+0x73ef): undefined reference to `mkradfnm' > 88d2arps.c:(.text+0x77ad): undefined reference to `remapvol' > 88d2arps.c:(.text+0x79c2): undefined reference to `remap2dcts' > 88d2arps.c:(.text+0x7c7b): undefined reference to `remap2d' > 88d2arps.c:(.text+0x7e92): undefined reference to `quadfit' > 88d2arps.c:(.text+0x7f40): undefined reference to `abss2ctim' > 88d2arps.c:(.text+0x8159): undefined reference to `abss2ctim' > 88d2arps.c:(.text+0x8474): undefined reference to `abss2ctim' > 88d2arps.c:(.text+0x86ae): undefined reference to `abss2ctim' > 88d2arps.c:(.text+0x89f6): undefined reference to `mkvadfnm' > 88d2arps.c:(.text+0x8af3): undefined reference to `vadvol' > 88d2arps.c:(.text+0x8b5c): undefined reference to `wtvadprf' > 88d2arps.c:(.text+0x8efc): undefined reference to `remapvol' > 88d2arps.c:(.text+0x910e): undefined reference to `remap2dcts' > 88d2arps.c:(.text+0x93c7): undefined reference to `remap2d' > 88d2arps.c:(.text+0x95d4): undefined reference to `wtradcol' > 88d2arps.c:(.text+0x9772): undefined reference to `wrttilts' > 88d2arps.c:(.text+0x98bb): undefined reference to `wrtgridtilt' > make[1]: *** [/home/wmwang/soft/arps5.2.12/bin/88d2arps] Error 2 > make[1]: Leaving directory `/home/wmwang/soft/arps5.2.12/src/88d2arps' > make: *** [88d2arps] Error 2 > From otem234 at gmail.com Wed Dec 16 21:24:35 2009 From: otem234 at gmail.com (Yunheng Wang) Date: Wed, 16 Dec 2009 21:24:35 -0600 Subject: [ARPSSUPPORT] error with compile 88d2arps In-Reply-To: <6a88388a0912160654y635a3ce8ya0028c63f0f2ce5b@mail.gmail.com> References: <6a88388a0912151906h66bd5ab9qd8d134d88cb148b6@mail.gmail.com> <6a88388a0912160654y635a3ce8ya0028c63f0f2ce5b@mail.gmail.com> Message-ID: <4B29A473.6030603@gcn.ou.edu> There is not "adas.input". Both arps and adas use the same namelist template in "arps.input". Yunheng. Weimin Wang wrote: > hello, > > after compile all codes of arps, I have solved this problem. However, I get > another question with using 88d2arps. I did not find adas.input, but > arps.input. Which variables should I specify in arps.input for runing > 88d2arps? > > On Wed, Dec 16, 2009 at 11:06 AM, Weimin Wang wrote: > > >> Hello, >> >> When I try to compile 88d2arps with pgf90 and pgcc, errors display as, >> >> Thank you for suggestions in advance. >> >> ./makearps -f pgf90 -c pgcc -io nohdf 88d2arps >> >> 88d2arps.o: In function `main': >> 88d2arps.c:(.text+0x810): undefined reference to `initpara' >> 88d2arps.c:(.text+0x1a9c): undefined reference to `get_from_namelist' >> 88d2arps.c:(.text+0x1d7d): undefined reference to `get_infilname' >> 88d2arps.c:(.text+0x1eb4): undefined reference to `get_gridxyzzp' >> 88d2arps.c:(.text+0x1ee4): undefined reference to `mapinit' >> 88d2arps.c:(.text+0x1f89): undefined reference to `radcoord' >> 88d2arps.c:(.text+0x2143): undefined reference to `rdenvprf' >> 88d2arps.c:(.text+0x2383): undefined reference to `readuvt' >> 88d2arps.c:(.text+0x2519): undefined reference to `extenvprf2' >> 88d2arps.c:(.text+0x25ab): undefined reference to `set_lbcopt' >> 88d2arps.c:(.text+0x327c): undefined reference to `initgrdvar' >> 88d2arps.c:(.text+0x3499): undefined reference to `radcoord' >> 88d2arps.c:(.text+0x3754): undefined reference to `extenvprf' >> 88d2arps.c:(.text+0x3f16): undefined reference to `ctim2abss' >> 88d2arps.c:(.text+0x4512): undefined reference to `ctim2abss' >> 88d2arps.c:(.text+0x4a2f): undefined reference to `ctim2abss' >> 88d2arps.c:(.text+0x4be1): undefined reference to `rmpinit' >> 88d2arps.c:(.text+0x4ca7): undefined reference to `despekl' >> 88d2arps.c:(.text+0x4e86): undefined reference to `volbuild' >> 88d2arps.c:(.text+0x4f40): undefined reference to `despekl' >> 88d2arps.c:(.text+0x50a6): undefined reference to `unfnqc' >> 88d2arps.c:(.text+0x51df): undefined reference to `volbuild' >> 88d2arps.c:(.text+0x5333): undefined reference to `volbuild' >> 88d2arps.c:(.text+0x5d5c): undefined reference to `rmpinit' >> 88d2arps.c:(.text+0x5e22): undefined reference to `despekl' >> 88d2arps.c:(.text+0x5f5b): undefined reference to `volbuild' >> 88d2arps.c:(.text+0x6008): undefined reference to `despekl' >> 88d2arps.c:(.text+0x617b): undefined reference to `unfnqc' >> 88d2arps.c:(.text+0x62b4): undefined reference to `volbuild' >> 88d2arps.c:(.text+0x6408): undefined reference to `volbuild' >> 88d2arps.o: In function `output_free_radar_volume': >> 88d2arps.c:(.text+0x732b): undefined reference to `apdetect' >> 88d2arps.c:(.text+0x73ef): undefined reference to `mkradfnm' >> 88d2arps.c:(.text+0x77ad): undefined reference to `remapvol' >> 88d2arps.c:(.text+0x79c2): undefined reference to `remap2dcts' >> 88d2arps.c:(.text+0x7c7b): undefined reference to `remap2d' >> 88d2arps.c:(.text+0x7e92): undefined reference to `quadfit' >> 88d2arps.c:(.text+0x7f40): undefined reference to `abss2ctim' >> 88d2arps.c:(.text+0x8159): undefined reference to `abss2ctim' >> 88d2arps.c:(.text+0x8474): undefined reference to `abss2ctim' >> 88d2arps.c:(.text+0x86ae): undefined reference to `abss2ctim' >> 88d2arps.c:(.text+0x89f6): undefined reference to `mkvadfnm' >> 88d2arps.c:(.text+0x8af3): undefined reference to `vadvol' >> 88d2arps.c:(.text+0x8b5c): undefined reference to `wtvadprf' >> 88d2arps.c:(.text+0x8efc): undefined reference to `remapvol' >> 88d2arps.c:(.text+0x910e): undefined reference to `remap2dcts' >> 88d2arps.c:(.text+0x93c7): undefined reference to `remap2d' >> 88d2arps.c:(.text+0x95d4): undefined reference to `wtradcol' >> 88d2arps.c:(.text+0x9772): undefined reference to `wrttilts' >> 88d2arps.c:(.text+0x98bb): undefined reference to `wrtgridtilt' >> make[1]: *** [/home/wmwang/soft/arps5.2.12/bin/88d2arps] Error 2 >> make[1]: Leaving directory `/home/wmwang/soft/arps5.2.12/src/88d2arps' >> make: *** [88d2arps] Error 2 >> >> > _______________________________________________ > ARPSSUPPORT mailing list > ARPSSUPPORT at caps.ou.edu > http://www.caps.ou.edu/mailman/listinfo/arpssupport > > From watson.leela at ensco.com Thu Dec 17 11:16:26 2009 From: watson.leela at ensco.com (Watson.Leela) Date: Thu, 17 Dec 2009 12:16:26 -0500 Subject: [ARPSSUPPORT] FW: bizzare output from ext2arps, adas In-Reply-To: <000301ca7dad$17610950$46231bf0$@ou.edu> References: <9CCF5909C0BD8444A73AA400374C62DA030EF1FFBC@mb-ex07.ensco.win> <000301ca7dad$17610950$46231bf0$@ou.edu> Message-ID: <9CCF5909C0BD8444A73AA400374C62DA030F1739FA@mb-ex07.ensco.win> Kevin, I actually fixed the problem by switching the variable 'varout' from 0 to 1 in ext2arps. This then fixed the ADAS output as well. My question is why would we need to output perturbation fields? Is the model output wind data stored as steady state and perturbation fields and then total wind is computed from that? Also, I was getting grid errors when using the grid stretching option in ext2arps (strhopt=1, dz=450, dzmin=20), so I had to turn that option off. Can you please describe what the grid stretching option does? Lastly, as you mentioned, I am not using the surface data from the model (extsfcopt=0). Is this necessary to use if I am specifying a surface data set from arpssfc? Leela -----Original Message----- From: Keith Brewster [mailto:kbrews at gcn.ou.edu] Sent: Tuesday, December 15, 2009 12:36 PM To: Watson.Leela; arpssupport at caps.ou.edu Subject: RE: [ARPSSUPPORT] FW: bizzare output from ext2arps, adas Due to some deadlines Monday I just had a chance to look at this. I agree something is not right. First realize that your dzmin is 500m so your first level is 250m above the ground. You are not using the sfc data from the model (extsfcopt=0) so you are only using the pressure level data. That said it seems to me you should still see some more structure in your wind fields over the ocean. Can you email me the RUC file that you used or put it on an ftp site and I will test it here. Regarding ADAS, you didn't send your ADAS input file, but 1) it seems you have too small a value for xyrange, 2) it is trying to correct problem with the background and apparently it only has data at that radar sites. -Keith -----Original Message----- From: arpssupport-bounces at caps.ou.edu [mailto:arpssupport-bounces at caps.ou.edu] On Behalf Of Watson.Leela Sent: Saturday, December 12, 2009 3:11 PM To: arpssupport at caps.ou.edu Subject: [ARPSSUPPORT] FW: bizzare output from ext2arps, adas From: Watson.Leela Sent: Saturday, December 12, 2009 1:21 PM To: arpssupport at caps.ou.edu Subject: bizzare output from ext2arps, adas Hello, I am desperate for some help! I am running ext2arps and adas and getting some bizarre results. Attached are some files that show wind speed from the output of ext2arps (ext2arps_output.jpeg), from the raw RUC 13 km background model data (ruc13_200911250000.gif), and the adas output for the same time (adas_output.jpeg). 1) The output of surface wind speed from ext2arps is grossly different from the raw RUC data. It completely misses the wind speeds and it only outputs data over the Florida peninsula. Is this normal? I have also attached my input file for ext2arps (FL_ext2arps.input). 2) There are large bullseyes for surface winds around the radar locations in Florida in the output from adas. How can I resolve this issue? Leela Watson ********************************************************* Leela R. Watson, Meteorologist ENSCO, Inc. / Applied Meteorology Unit 1980 N. Atlantic Ave., Suite 830 Cocoa Beach, FL 32931 Voice: (321) 853-8264 Fax: (321) 853-8415 Email: watson.leela at ensco.com ________________________________ The information contained in this email message is intended only for the use of the individual(s) to whom it is addressed and may contain information that is privileged and sensitive. If you are not the intended recipient, or otherwise have received this communication in error, please notify the sender immediately by email at the above referenced address and note that any further dissemination, distribution or copying of this communication is strictly prohibited. The U.S. Export Control Laws regulate the export and re-export of technology originating in the United States. This includes the electronic transmission of information and software to foreign countries and to certain foreign nationals. Recipient agrees to abide by these laws and their regulations -- including the U.S. Department of Commerce Export Administration Regulations and the U.S. Department of State International Traffic in Arms Regulations -- and not to transfer, by electronic transmission or otherwise, any content derived from this email to either a foreign national or a foreign destination in violation of such laws. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.716 / Virus Database: 270.14.107/2564 - Release Date: 12/14/09 01:37:00 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.427 / Virus Database: 270.14.104/2560 - Release Date: 12/15/09 07:52:00 The information contained in this email message is intended only for the use of the individual(s) to whom it is addressed and may contain information that is privileged and sensitive. If you are not the intended recipient, or otherwise have received this communication in error, please notify the sender immediately by email at the above referenced address and note that any further dissemination, distribution or copying of this communication is strictly prohibited. The U.S. Export Control Laws regulate the export and re-export of technology originating in the United States. This includes the electronic transmission of information and software to foreign countries and to certain foreign nationals. Recipient agrees to abide by these laws and their regulations -- including the U.S. Department of Commerce Export Administration Regulations and the U.S. Department of State International Traffic in Arms Regulations -- and not to transfer, by electronic transmission or otherwise, any content derived from this email to either a foreign national or a foreign destination in violation of such laws. From mxue at ou.edu Thu Dec 17 11:26:30 2009 From: mxue at ou.edu (Xue, Ming) Date: Thu, 17 Dec 2009 17:26:30 +0000 Subject: [ARPSSUPPORT] FW: bizzare output from ext2arps, adas In-Reply-To: <9CCF5909C0BD8444A73AA400374C62DA030F1739FA@mb-ex07.ensco.win> References: <9CCF5909C0BD8444A73AA400374C62DA030EF1FFBC@mb-ex07.ensco.win> <000301ca7dad$17610950$46231bf0$@ou.edu> <9CCF5909C0BD8444A73AA400374C62DA030F1739FA@mb-ex07.ensco.win> Message-ID: <98A933070F0F8A42BFE4EE5770ED0156092C52@it-lightning.sooner.net.ou.edu> Leela, For your question 1, the time dependent ARPS history files contain the full fields, while the grdbas file contains the 'base-state' fields which are static and constructed as horizontally homogeneous (in terms of z) and vertically hydrostatic. Subroutine dtaread outputs base and perturbation fields for historical reasons - it constructs perturbations fields inside by subtracting base from total fields. Ming Xue > -----Original Message----- > From: arpssupport-bounces at caps.ou.edu [mailto:arpssupport-bounces at caps.ou.edu] On Behalf Of > Watson.Leela > Sent: 2009?12?17? 11:16 > To: Brewster, Keith A.; arpssupport at caps.ou.edu > Subject: Re: [ARPSSUPPORT] FW: bizzare output from ext2arps, adas > > Kevin, > > I actually fixed the problem by switching the variable 'varout' from 0 to 1 in ext2arps. This then fixed the ADAS > output as well. My question is why would we need to output perturbation fields? Is the model output wind data > stored as steady state and perturbation fields and then total wind is computed from that? > > Also, I was getting grid errors when using the grid stretching option in ext2arps (strhopt=1, dz=450, dzmin=20), > so I had to turn that option off. Can you please describe what the grid stretching option does? > > Lastly, as you mentioned, I am not using the surface data from the model (extsfcopt=0). Is this necessary to > use if I am specifying a surface data set from arpssfc? > > Leela > > -----Original Message----- > From: Keith Brewster [mailto:kbrews at gcn.ou.edu] > Sent: Tuesday, December 15, 2009 12:36 PM > To: Watson.Leela; arpssupport at caps.ou.edu > Subject: RE: [ARPSSUPPORT] FW: bizzare output from ext2arps, adas > > Due to some deadlines Monday I just had a chance to look at this. > I agree something is not right. First realize that your dzmin is 500m so > your first level is 250m above the ground. > You are not using the sfc data from the model (extsfcopt=0) so you are only > using the pressure level data. That said it seems to me you should still > see some more structure in your wind fields over the ocean. > > Can you email me the RUC file that you used or put it on an ftp site and I > will test it here. > > Regarding ADAS, you didn't send your ADAS input file, but 1) it seems you > have too small a value for xyrange, 2) it is trying to correct problem with > the background and apparently it only has data at that radar sites. > > -Keith > > -----Original Message----- > From: arpssupport-bounces at caps.ou.edu > [mailto:arpssupport-bounces at caps.ou.edu] On Behalf Of Watson.Leela > Sent: Saturday, December 12, 2009 3:11 PM > To: arpssupport at caps.ou.edu > Subject: [ARPSSUPPORT] FW: bizzare output from ext2arps, adas > > > > From: Watson.Leela > Sent: Saturday, December 12, 2009 1:21 PM > To: arpssupport at caps.ou.edu > Subject: bizzare output from ext2arps, adas > > Hello, > > I am desperate for some help! I am running ext2arps and adas and getting > some bizarre results. Attached are some files that show wind speed from the > output of ext2arps (ext2arps_output.jpeg), from the raw RUC 13 km background > model data (ruc13_200911250000.gif), and the adas output for the same time > (adas_output.jpeg). > > > 1) The output of surface wind speed from ext2arps is grossly different > from the raw RUC data. It completely misses the wind speeds and it only > outputs data over the Florida peninsula. Is this normal? I have also > attached my input file for ext2arps (FL_ext2arps.input). > > 2) There are large bullseyes for surface winds around the radar > locations in Florida in the output from adas. How can I resolve this issue? > > Leela Watson > > ********************************************************* > Leela R. Watson, Meteorologist > ENSCO, Inc. / Applied Meteorology Unit > 1980 N. Atlantic Ave., Suite 830 > Cocoa Beach, FL 32931 > Voice: (321) 853-8264 > Fax: (321) 853-8415 > Email: watson.leela at ensco.com > > > ________________________________ > The information contained in this email message is intended only for the use > of the individual(s) to whom it is addressed and may contain information > that is privileged and sensitive. If you are not the intended recipient, or > otherwise have received this communication in error, please notify the > sender immediately by email at the above referenced address and note that > any further dissemination, distribution or copying of this communication is > strictly prohibited. > > The U.S. Export Control Laws regulate the export and re-export of technology > originating in the United States. This includes the electronic transmission > of information and software to foreign countries and to certain foreign > nationals. Recipient agrees to abide by these laws and their regulations -- > including the U.S. Department of Commerce Export Administration Regulations > and the U.S. Department of State International Traffic in Arms Regulations > -- and not to transfer, by electronic transmission or otherwise, any content > derived from this email to either a foreign national or a foreign > destination in violation of such laws. > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.716 / Virus Database: 270.14.107/2564 - Release Date: 12/14/09 > 01:37:00 > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.427 / Virus Database: 270.14.104/2560 - Release Date: 12/15/09 07:52:00 > > The information contained in this email message is intended only for the use of the individual(s) to whom it is > addressed and may contain information that is privileged and sensitive. If you are not the intended recipient, or > otherwise have received this communication in error, please notify the sender immediately by email at the > above referenced address and note that any further dissemination, distribution or copying of this > communication is strictly prohibited. > > The U.S. Export Control Laws regulate the export and re-export of technology originating in the United States. > This includes the electronic transmission of information and software to foreign countries and to certain foreign > nationals. Recipient agrees to abide by these laws and their regulations -- including the U.S. Department of > Commerce Export Administration Regulations and the U.S. Department of State International Traffic in Arms > Regulations -- and not to transfer, by electronic transmission or otherwise, any content derived from this email > to either a foreign national or a foreign destination in violation of such laws. > > _______________________________________________ > ARPSSUPPORT mailing list > ARPSSUPPORT at caps.ou.edu > http://www.caps.ou.edu/mailman/listinfo/arpssupport From kbrews at gcn.ou.edu Thu Dec 17 11:42:19 2009 From: kbrews at gcn.ou.edu (Keith Brewster) Date: Thu, 17 Dec 2009 11:42:19 -0600 Subject: [ARPSSUPPORT] FW: bizzare output from ext2arps, adas In-Reply-To: <9CCF5909C0BD8444A73AA400374C62DA030F1739FA@mb-ex07.ensco.win> References: <9CCF5909C0BD8444A73AA400374C62DA030EF1FFBC@mb-ex07.ensco.win> <000301ca7dad$17610950$46231bf0$@ou.edu> <9CCF5909C0BD8444A73AA400374C62DA030F1739FA@mb-ex07.ensco.win> Message-ID: <000e01ca7f40$48370400$d8a50c00$@ou.edu> Yes, the data are specified as a horizontal mean plus a perturbation = total. varout should almost always be = 1. Glad your problem is solved. The grid stretching should work. What was the value of all the parameters in that namelist section? If you don't give a reasonable set of parameters it cannot fit the number of data points in the vertical to your specification. Regarding the surface data, the "surface" I was speaking about is really the low-level winds (e.g. 10 m winds) in the RUC data file. They are generally stored at a special array and that array is not processed if the extsfcout is not turned on. I am not as familiar with the RUC-13 as some of the other datasets. If the vertical resolution is high in the RUC output then it won't matter as much. -Keith -----Original Message----- From: Watson.Leela [mailto:watson.leela at ensco.com] Sent: Thursday, December 17, 2009 11:16 AM To: kbrewster at ou.edu; arpssupport at caps.ou.edu Subject: RE: [ARPSSUPPORT] FW: bizzare output from ext2arps, adas Kevin, I actually fixed the problem by switching the variable 'varout' from 0 to 1 in ext2arps. This then fixed the ADAS output as well. My question is why would we need to output perturbation fields? Is the model output wind data stored as steady state and perturbation fields and then total wind is computed from that? Also, I was getting grid errors when using the grid stretching option in ext2arps (strhopt=1, dz=450, dzmin=20), so I had to turn that option off. Can you please describe what the grid stretching option does? Lastly, as you mentioned, I am not using the surface data from the model (extsfcopt=0). Is this necessary to use if I am specifying a surface data set from arpssfc? Leela -----Original Message----- From: Keith Brewster [mailto:kbrews at gcn.ou.edu] Sent: Tuesday, December 15, 2009 12:36 PM To: Watson.Leela; arpssupport at caps.ou.edu Subject: RE: [ARPSSUPPORT] FW: bizzare output from ext2arps, adas Due to some deadlines Monday I just had a chance to look at this. I agree something is not right. First realize that your dzmin is 500m so your first level is 250m above the ground. You are not using the sfc data from the model (extsfcopt=0) so you are only using the pressure level data. That said it seems to me you should still see some more structure in your wind fields over the ocean. Can you email me the RUC file that you used or put it on an ftp site and I will test it here. Regarding ADAS, you didn't send your ADAS input file, but 1) it seems you have too small a value for xyrange, 2) it is trying to correct problem with the background and apparently it only has data at that radar sites. -Keith -----Original Message----- From: arpssupport-bounces at caps.ou.edu [mailto:arpssupport-bounces at caps.ou.edu] On Behalf Of Watson.Leela Sent: Saturday, December 12, 2009 3:11 PM To: arpssupport at caps.ou.edu Subject: [ARPSSUPPORT] FW: bizzare output from ext2arps, adas From: Watson.Leela Sent: Saturday, December 12, 2009 1:21 PM To: arpssupport at caps.ou.edu Subject: bizzare output from ext2arps, adas Hello, I am desperate for some help! I am running ext2arps and adas and getting some bizarre results. Attached are some files that show wind speed from the output of ext2arps (ext2arps_output.jpeg), from the raw RUC 13 km background model data (ruc13_200911250000.gif), and the adas output for the same time (adas_output.jpeg). 1) The output of surface wind speed from ext2arps is grossly different from the raw RUC data. It completely misses the wind speeds and it only outputs data over the Florida peninsula. Is this normal? I have also attached my input file for ext2arps (FL_ext2arps.input). 2) There are large bullseyes for surface winds around the radar locations in Florida in the output from adas. How can I resolve this issue? Leela Watson ********************************************************* Leela R. Watson, Meteorologist ENSCO, Inc. / Applied Meteorology Unit 1980 N. Atlantic Ave., Suite 830 Cocoa Beach, FL 32931 Voice: (321) 853-8264 Fax: (321) 853-8415 Email: watson.leela at ensco.com ________________________________ The information contained in this email message is intended only for the use of the individual(s) to whom it is addressed and may contain information that is privileged and sensitive. If you are not the intended recipient, or otherwise have received this communication in error, please notify the sender immediately by email at the above referenced address and note that any further dissemination, distribution or copying of this communication is strictly prohibited. The U.S. Export Control Laws regulate the export and re-export of technology originating in the United States. This includes the electronic transmission of information and software to foreign countries and to certain foreign nationals. Recipient agrees to abide by these laws and their regulations -- including the U.S. Department of Commerce Export Administration Regulations and the U.S. Department of State International Traffic in Arms Regulations -- and not to transfer, by electronic transmission or otherwise, any content derived from this email to either a foreign national or a foreign destination in violation of such laws. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.716 / Virus Database: 270.14.107/2564 - Release Date: 12/14/09 01:37:00 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.427 / Virus Database: 270.14.104/2560 - Release Date: 12/15/09 07:52:00 The information contained in this email message is intended only for the use of the individual(s) to whom it is addressed and may contain information that is privileged and sensitive. If you are not the intended recipient, or otherwise have received this communication in error, please notify the sender immediately by email at the above referenced address and note that any further dissemination, distribution or copying of this communication is strictly prohibited. The U.S. Export Control Laws regulate the export and re-export of technology originating in the United States. This includes the electronic transmission of information and software to foreign countries and to certain foreign nationals. Recipient agrees to abide by these laws and their regulations -- including the U.S. Department of Commerce Export Administration Regulations and the U.S. Department of State International Traffic in Arms Regulations -- and not to transfer, by electronic transmission or otherwise, any content derived from this email to either a foreign national or a foreign destination in violation of such laws. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.716 / Virus Database: 270.14.110/2568 - Release Date: 12/17/09 02:30:00 From watson.leela at ensco.com Thu Dec 17 12:06:09 2009 From: watson.leela at ensco.com (Watson.Leela) Date: Thu, 17 Dec 2009 13:06:09 -0500 Subject: [ARPSSUPPORT] FW: bizzare output from ext2arps, adas In-Reply-To: <000e01ca7f40$48370400$d8a50c00$@ou.edu> References: <9CCF5909C0BD8444A73AA400374C62DA030EF1FFBC@mb-ex07.ensco.win> <000301ca7dad$17610950$46231bf0$@ou.edu> <9CCF5909C0BD8444A73AA400374C62DA030F1739FA@mb-ex07.ensco.win> <000e01ca7f40$48370400$d8a50c00$@ou.edu> Message-ID: <9CCF5909C0BD8444A73AA400374C62DA030F173A0B@mb-ex07.ensco.win> Here are the grid parameters I am using for the grid stretching: &grid dx = 4000, dy = 4000, dz = 450, strhopt = 1, dzmin = 20, zrefsfc = 0.0, dlayer1 = 0.0, dlayer2 = 1.0e5, strhtune = 1.0, zflat = 1.0e5, ctrlat = 27.70, ctrlon = -81.00, crdorgnopt = 0, And to clarify, I am not getting grid errors when running ext2arps. It runs fine in ext2arps, adas, and then through arps4wrf. It is when I try to use that output in WRF that I get the following WRF error: -------------- FATAL CALLED --------------- FATAL CALLED FROM FILE: module_initialize_real.b LINE: 4812 probs with sfc p computation ------------------------------------------- If I turn off grid stretching, the WRF model runs fine. Leela -----Original Message----- From: Keith Brewster [mailto:kbrews at gcn.ou.edu] Sent: Thursday, December 17, 2009 12:42 PM To: Watson.Leela; kbrewster at ou.edu; arpssupport at caps.ou.edu Subject: RE: [ARPSSUPPORT] FW: bizzare output from ext2arps, adas Yes, the data are specified as a horizontal mean plus a perturbation = total. varout should almost always be = 1. Glad your problem is solved. The grid stretching should work. What was the value of all the parameters in that namelist section? If you don't give a reasonable set of parameters it cannot fit the number of data points in the vertical to your specification. Regarding the surface data, the "surface" I was speaking about is really the low-level winds (e.g. 10 m winds) in the RUC data file. They are generally stored at a special array and that array is not processed if the extsfcout is not turned on. I am not as familiar with the RUC-13 as some of the other datasets. If the vertical resolution is high in the RUC output then it won't matter as much. -Keith -----Original Message----- From: Watson.Leela [mailto:watson.leela at ensco.com] Sent: Thursday, December 17, 2009 11:16 AM To: kbrewster at ou.edu; arpssupport at caps.ou.edu Subject: RE: [ARPSSUPPORT] FW: bizzare output from ext2arps, adas Kevin, I actually fixed the problem by switching the variable 'varout' from 0 to 1 in ext2arps. This then fixed the ADAS output as well. My question is why would we need to output perturbation fields? Is the model output wind data stored as steady state and perturbation fields and then total wind is computed from that? Also, I was getting grid errors when using the grid stretching option in ext2arps (strhopt=1, dz=450, dzmin=20), so I had to turn that option off. Can you please describe what the grid stretching option does? Lastly, as you mentioned, I am not using the surface data from the model (extsfcopt=0). Is this necessary to use if I am specifying a surface data set from arpssfc? Leela -----Original Message----- From: Keith Brewster [mailto:kbrews at gcn.ou.edu] Sent: Tuesday, December 15, 2009 12:36 PM To: Watson.Leela; arpssupport at caps.ou.edu Subject: RE: [ARPSSUPPORT] FW: bizzare output from ext2arps, adas Due to some deadlines Monday I just had a chance to look at this. I agree something is not right. First realize that your dzmin is 500m so your first level is 250m above the ground. You are not using the sfc data from the model (extsfcopt=0) so you are only using the pressure level data. That said it seems to me you should still see some more structure in your wind fields over the ocean. Can you email me the RUC file that you used or put it on an ftp site and I will test it here. Regarding ADAS, you didn't send your ADAS input file, but 1) it seems you have too small a value for xyrange, 2) it is trying to correct problem with the background and apparently it only has data at that radar sites. -Keith -----Original Message----- From: arpssupport-bounces at caps.ou.edu [mailto:arpssupport-bounces at caps.ou.edu] On Behalf Of Watson.Leela Sent: Saturday, December 12, 2009 3:11 PM To: arpssupport at caps.ou.edu Subject: [ARPSSUPPORT] FW: bizzare output from ext2arps, adas From: Watson.Leela Sent: Saturday, December 12, 2009 1:21 PM To: arpssupport at caps.ou.edu Subject: bizzare output from ext2arps, adas Hello, I am desperate for some help! I am running ext2arps and adas and getting some bizarre results. Attached are some files that show wind speed from the output of ext2arps (ext2arps_output.jpeg), from the raw RUC 13 km background model data (ruc13_200911250000.gif), and the adas output for the same time (adas_output.jpeg). 1) The output of surface wind speed from ext2arps is grossly different from the raw RUC data. It completely misses the wind speeds and it only outputs data over the Florida peninsula. Is this normal? I have also attached my input file for ext2arps (FL_ext2arps.input). 2) There are large bullseyes for surface winds around the radar locations in Florida in the output from adas. How can I resolve this issue? Leela Watson ********************************************************* Leela R. Watson, Meteorologist ENSCO, Inc. / Applied Meteorology Unit 1980 N. Atlantic Ave., Suite 830 Cocoa Beach, FL 32931 Voice: (321) 853-8264 Fax: (321) 853-8415 Email: watson.leela at ensco.com ________________________________ The information contained in this email message is intended only for the use of the individual(s) to whom it is addressed and may contain information that is privileged and sensitive. If you are not the intended recipient, or otherwise have received this communication in error, please notify the sender immediately by email at the above referenced address and note that any further dissemination, distribution or copying of this communication is strictly prohibited. The U.S. Export Control Laws regulate the export and re-export of technology originating in the United States. This includes the electronic transmission of information and software to foreign countries and to certain foreign nationals. Recipient agrees to abide by these laws and their regulations -- including the U.S. Department of Commerce Export Administration Regulations and the U.S. Department of State International Traffic in Arms Regulations -- and not to transfer, by electronic transmission or otherwise, any content derived from this email to either a foreign national or a foreign destination in violation of such laws. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.716 / Virus Database: 270.14.107/2564 - Release Date: 12/14/09 01:37:00 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.427 / Virus Database: 270.14.104/2560 - Release Date: 12/15/09 07:52:00 The information contained in this email message is intended only for the use of the individual(s) to whom it is addressed and may contain information that is privileged and sensitive. If you are not the intended recipient, or otherwise have received this communication in error, please notify the sender immediately by email at the above referenced address and note that any further dissemination, distribution or copying of this communication is strictly prohibited. The U.S. Export Control Laws regulate the export and re-export of technology originating in the United States. This includes the electronic transmission of information and software to foreign countries and to certain foreign nationals. Recipient agrees to abide by these laws and their regulations -- including the U.S. Department of Commerce Export Administration Regulations and the U.S. Department of State International Traffic in Arms Regulations -- and not to transfer, by electronic transmission or otherwise, any content derived from this email to either a foreign national or a foreign destination in violation of such laws. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.716 / Virus Database: 270.14.110/2568 - Release Date: 12/17/09 02:30:00 The information contained in this email message is intended only for the use of the individual(s) to whom it is addressed and may contain information that is privileged and sensitive. If you are not the intended recipient, or otherwise have received this communication in error, please notify the sender immediately by email at the above referenced address and note that any further dissemination, distribution or copying of this communication is strictly prohibited. The U.S. Export Control Laws regulate the export and re-export of technology originating in the United States. This includes the electronic transmission of information and software to foreign countries and to certain foreign nationals. Recipient agrees to abide by these laws and their regulations -- including the U.S. Department of Commerce Export Administration Regulations and the U.S. Department of State International Traffic in Arms Regulations -- and not to transfer, by electronic transmission or otherwise, any content derived from this email to either a foreign national or a foreign destination in violation of such laws. From philippe.beaucage at gmail.com Mon Dec 21 14:08:53 2009 From: philippe.beaucage at gmail.com (Philippe Beaucage) Date: Mon, 21 Dec 2009 15:08:53 -0500 Subject: [ARPSSUPPORT] conversion of ARPS vegetation type to roughness Message-ID: <6433f67b0912211208u390b43ebr72a71ff47203457e@mail.gmail.com> Dear ARPS Support, I'm doing some validation of the near-surface wind speeds over the TX, OK and KS states at the mesoscale (30,12,4 km grid mesh). I simulated 36 case day sampled over a period of a year (24-hour simulation or hindcast). I get biases of 1 m/s and more when I compare against ASOS stations (10 m height a.g.l.) which means that ARPS has lower wind speeds. The other mesoscale model that I use as a benchmark doesn't show such high biases (close to 0 m/s). Both models use the same initial conditions (except for soil temperature, soil moisture, snow and ice). I looked at the land-use to surface roughness conversion in ARPS (.../src/arpssfc/arpssfclib.f90, routine getrfns) and found out that the roughness values are sometimes pretty different with the look-up table that the other mesoscale model is using. ARPS uses 14 classes whereas the other model uses the 96 classes based on Olson. ARPS Vegetation type Definition ARPS Roughness (cm) MODEL2 Roughness (cm) 1 Desert 1.1 1 2 Tundra 7.6 3 3 Grassland 7.5 3 4 Grassland_w/_shrub cover 23.8 10 5 Grassland_w/_tree cover 56.3 75 6 Deciduous_forest 82.6 150 7 Evergreen_forest 108.9 160 8 Rain_forest 265.3 200 9 Ice 1.1 0.3 10 Cultivation 7.5 10 11 Bog_or_marsh 10 20 12 Dwarf_shrub 85.6 7 13 Semidesert 6.5 3 14 Water 0.2 0.1 Over TX, OK and KS, the "grassland with shrub cover" class is frequently assign to grid cells within my simulation domain. I noticed that the "grassland with shrub cover" class used to correspond to a roughness length of 10 cm (i.e. in the ARPS v4.0 manual and in the source code) but it is now 23.8 cm. Do you keep track of these changes ? Or do you know the reasons for these changes ? I'm not an expert in land-surface models but a factor of 2 in the surface roughness length can lead to important differences in wind speeds near the surface through the drag coefficients that are applied in the first vertical level. Second question: there is no "urban" class in the ARPS vegetation classes. Is it taken care of in some other parts of the code ? Thanks in advance for your help. Philippe From philippe.beaucage at gmail.com Tue Dec 22 08:32:06 2009 From: philippe.beaucage at gmail.com (Philippe Beaucage) Date: Tue, 22 Dec 2009 09:32:06 -0500 Subject: [ARPSSUPPORT] conversion of ARPS vegetation type to roughness In-Reply-To: <6433f67b0912211208u390b43ebr72a71ff47203457e@mail.gmail.com> References: <6433f67b0912211208u390b43ebr72a71ff47203457e@mail.gmail.com> Message-ID: <6433f67b0912220632k741dc55fo31ba816ac7f1a807@mail.gmail.com> I just realized that the table in my last email has not kept the right format. For more convenience, I've attached the table as an image. Thanks. Philippe 2009/12/21 Philippe Beaucage > Dear ARPS Support, > > I'm doing some validation of the near-surface wind speeds over the TX, OK > and KS states at the mesoscale (30,12,4 km grid mesh). I simulated 36 case > day sampled over a period of a year (24-hour simulation or hindcast). I get > biases of 1 m/s and more when I compare against ASOS stations (10 m height > a.g.l.) which means that ARPS has lower wind speeds. The other mesoscale > model that I use as a benchmark doesn't show such high biases (close to 0 > m/s). Both models use the same initial conditions (except for soil > temperature, soil moisture, snow and ice). > > I looked at the land-use to surface roughness conversion in ARPS > (.../src/arpssfc/arpssfclib.f90, routine getrfns) and found out that the > roughness values are sometimes pretty different with the look-up table that > the other mesoscale model is using. ARPS uses 14 classes whereas the other > model uses the 96 classes based on Olson. > > ARPS Vegetation type Definition ARPS Roughness (cm) MODEL2 Roughness > (cm) > > > > 1 Desert 1.1 1 2 Tundra 7.6 3 3 Grassland 7.5 3 4 Grassland_w/_shrub > cover 23.8 10 5 Grassland_w/_tree cover 56.3 75 6 Deciduous_forest 82.6 > 150 7 Evergreen_forest 108.9 160 8 Rain_forest 265.3 200 9 Ice 1.1 0.3 > 10 Cultivation 7.5 10 11 Bog_or_marsh 10 20 12 Dwarf_shrub 85.6 7 13 > Semidesert 6.5 3 14 Water 0.2 0.1 > Over TX, OK and KS, the "grassland with shrub cover" class is frequently > assign to grid cells within my simulation domain. I noticed that the > "grassland with shrub cover" class used to correspond to a roughness length > of 10 cm (i.e. in the ARPS v4.0 manual and in the source code) but it is now > 23.8 cm. Do you keep track of these changes ? Or do you know the reasons for > these changes ? I'm not an expert in land-surface models but a factor of 2 > in the surface roughness length can lead to important differences in wind > speeds near the surface through the drag coefficients that are applied in > the first vertical level. > > Second question: there is no "urban" class in the ARPS vegetation classes. > Is it taken care of in some other parts of the code ? > > Thanks in advance for your help. > > Philippe > > -------------- next part -------------- A non-text attachment was scrubbed... Name: LCC2RGH_conversiontable.png Type: image/png Size: 20965 bytes Desc: LCC2RGH_conversiontable.png URL: From wmwang at gmail.com Wed Dec 23 03:28:02 2009 From: wmwang at gmail.com (Weimin Wang) Date: Wed, 23 Dec 2009 17:28:02 +0800 Subject: [ARPSSUPPORT] error with compile 88d2arps In-Reply-To: <4B29A473.6030603@gcn.ou.edu> References: <6a88388a0912151906h66bd5ab9qd8d134d88cb148b6@mail.gmail.com> <6a88388a0912160654y635a3ce8ya0028c63f0f2ce5b@mail.gmail.com> <4B29A473.6030603@gcn.ou.edu> Message-ID: <6a88388a0912230128s7db11ed4k11b730444b22cb21@mail.gmail.com> Hello, Dr. Wang, Thank you for your time response. I have some question on the usage of 88d2arps. Would you please give me a guide to set the parameters in arps.input to derive 88d2arps? There is so much parameters in arps.input. Best regards, Weimin On Thu, Dec 17, 2009 at 11:24 AM, Yunheng Wang wrote: > There is not "adas.input". Both arps and adas use the same namelist > template in "arps.input". > > Yunheng. > > Weimin Wang wrote: > >> hello, >> >> after compile all codes of arps, I have solved this problem. However, I >> get >> another question with using 88d2arps. I did not find adas.input, but >> arps.input. Which variables should I specify in arps.input for runing >> 88d2arps? >> >> On Wed, Dec 16, 2009 at 11:06 AM, Weimin Wang wrote: >> >> >> >>> Hello, >>> >>> When I try to compile 88d2arps with pgf90 and pgcc, errors display as, >>> >>> Thank you for suggestions in advance. >>> >>> ./makearps -f pgf90 -c pgcc -io nohdf 88d2arps >>> >>> 88d2arps.o: In function `main': >>> 88d2arps.c:(.text+0x810): undefined reference to `initpara' >>> 88d2arps.c:(.text+0x1a9c): undefined reference to `get_from_namelist' >>> 88d2arps.c:(.text+0x1d7d): undefined reference to `get_infilname' >>> 88d2arps.c:(.text+0x1eb4): undefined reference to `get_gridxyzzp' >>> 88d2arps.c:(.text+0x1ee4): undefined reference to `mapinit' >>> 88d2arps.c:(.text+0x1f89): undefined reference to `radcoord' >>> 88d2arps.c:(.text+0x2143): undefined reference to `rdenvprf' >>> 88d2arps.c:(.text+0x2383): undefined reference to `readuvt' >>> 88d2arps.c:(.text+0x2519): undefined reference to `extenvprf2' >>> 88d2arps.c:(.text+0x25ab): undefined reference to `set_lbcopt' >>> 88d2arps.c:(.text+0x327c): undefined reference to `initgrdvar' >>> 88d2arps.c:(.text+0x3499): undefined reference to `radcoord' >>> 88d2arps.c:(.text+0x3754): undefined reference to `extenvprf' >>> 88d2arps.c:(.text+0x3f16): undefined reference to `ctim2abss' >>> 88d2arps.c:(.text+0x4512): undefined reference to `ctim2abss' >>> 88d2arps.c:(.text+0x4a2f): undefined reference to `ctim2abss' >>> 88d2arps.c:(.text+0x4be1): undefined reference to `rmpinit' >>> 88d2arps.c:(.text+0x4ca7): undefined reference to `despekl' >>> 88d2arps.c:(.text+0x4e86): undefined reference to `volbuild' >>> 88d2arps.c:(.text+0x4f40): undefined reference to `despekl' >>> 88d2arps.c:(.text+0x50a6): undefined reference to `unfnqc' >>> 88d2arps.c:(.text+0x51df): undefined reference to `volbuild' >>> 88d2arps.c:(.text+0x5333): undefined reference to `volbuild' >>> 88d2arps.c:(.text+0x5d5c): undefined reference to `rmpinit' >>> 88d2arps.c:(.text+0x5e22): undefined reference to `despekl' >>> 88d2arps.c:(.text+0x5f5b): undefined reference to `volbuild' >>> 88d2arps.c:(.text+0x6008): undefined reference to `despekl' >>> 88d2arps.c:(.text+0x617b): undefined reference to `unfnqc' >>> 88d2arps.c:(.text+0x62b4): undefined reference to `volbuild' >>> 88d2arps.c:(.text+0x6408): undefined reference to `volbuild' >>> 88d2arps.o: In function `output_free_radar_volume': >>> 88d2arps.c:(.text+0x732b): undefined reference to `apdetect' >>> 88d2arps.c:(.text+0x73ef): undefined reference to `mkradfnm' >>> 88d2arps.c:(.text+0x77ad): undefined reference to `remapvol' >>> 88d2arps.c:(.text+0x79c2): undefined reference to `remap2dcts' >>> 88d2arps.c:(.text+0x7c7b): undefined reference to `remap2d' >>> 88d2arps.c:(.text+0x7e92): undefined reference to `quadfit' >>> 88d2arps.c:(.text+0x7f40): undefined reference to `abss2ctim' >>> 88d2arps.c:(.text+0x8159): undefined reference to `abss2ctim' >>> 88d2arps.c:(.text+0x8474): undefined reference to `abss2ctim' >>> 88d2arps.c:(.text+0x86ae): undefined reference to `abss2ctim' >>> 88d2arps.c:(.text+0x89f6): undefined reference to `mkvadfnm' >>> 88d2arps.c:(.text+0x8af3): undefined reference to `vadvol' >>> 88d2arps.c:(.text+0x8b5c): undefined reference to `wtvadprf' >>> 88d2arps.c:(.text+0x8efc): undefined reference to `remapvol' >>> 88d2arps.c:(.text+0x910e): undefined reference to `remap2dcts' >>> 88d2arps.c:(.text+0x93c7): undefined reference to `remap2d' >>> 88d2arps.c:(.text+0x95d4): undefined reference to `wtradcol' >>> 88d2arps.c:(.text+0x9772): undefined reference to `wrttilts' >>> 88d2arps.c:(.text+0x98bb): undefined reference to `wrtgridtilt' >>> make[1]: *** [/home/wmwang/soft/arps5.2.12/bin/88d2arps] Error 2 >>> make[1]: Leaving directory `/home/wmwang/soft/arps5.2.12/src/88d2arps' >>> make: *** [88d2arps] Error 2 >>> >>> >>> >> _______________________________________________ >> ARPSSUPPORT mailing list >> ARPSSUPPORT at caps.ou.edu >> http://www.caps.ou.edu/mailman/listinfo/arpssupport >> >> >> > >