August 2000 Houston/Beaumont Ozone Episode

Modeling Log

 

John Nielsen-Gammon

Texas A&M University

979-862-2248

n-g@tamu.edu

 

Work sponsored by the Texas Commission for Environmental Quality

(This document has not been reviewed by TCEQ  for form or content)

 

This page describes modeling activities conducted for TCEQ by Texas A&M University on the August 2000 Southeast Texas ozone episode.  The log is posted in inverse chronological order.  Prior to the creation of the results page, the log was updated with regular reports.  Now the results page has links to output from all model runs and to reports that document them.

 

Sat Feb 16 PM: Status report:

                                 New report to TNRCC, on the performance of selected runs, including the MCNC runs.  Click here for a copy or here for a summary.

 

                                 I continue to generate graphics from various model runs to compare to observations, accessible from the link listed on Nov. 2, below.  The graphics now include soundings and time-height cross sections.  Also, a selection of links can be found on my newly-created results page.

 

                                 The quest continues for the right nighttime wind structure.  The low-level jet winds seem to be better within the nighttime boundary layer than above it.  This suggests there might be too much vertical diffusion in the free atmosphere.  Fuqing Zhang and I examine the MRF PBL scheme as implemented in the MM5, and learn that the vertical diffusion has been increased over the published parameterization in Hong and Pan (1996).  Plugging in the numbers, the diffusion at O(1) Richardson numbers has been increased by an order of magnitude.  Therefore, two new runs: feb9grid4 (with the original Hong and Pan scheme) and feb11grid4 (with the original Hong and Pan mixing length only).  It doesn’t match observations yet, but feb9grid4 has a superior nighttime evolution of the winds above the PBL at night.  There’s some funny stuff going on, too, with layer-to-layer shear at one extreme and nighttime well-mixed layers aloft at the other extreme.  Which run is the winner?  Still not sure.

 

                                 The airsonde soundings, in particular, indicate very shallow nighttime inversions are developing.  Also, as the sea breeze comes in to Lamarque during Regime 2, it takes the form of a very shallow well-mixed layer capped by a very shallow inversion.  With some concern that higher PBL resolution may be necessary to resolve the shallow sea breeze, and may help the nighttime temperatures and winds too, I do a run with double the vertical resolution in the lowest 500 m or so: feb16grid4. 

 

Thu Jan 24 PM: Status report:

                                 One additional model run completed: dec30grid4.  This features the same soil moisture as dec16grid4, but uses the MRF PBL rather than the Gayno-Seaman PBL.  With this run, I finally achieve surface maximum temperatures that are too warm. 

 

Most recent time has been spent focusing on the diurnal wind cycle, in particular the nighttime low-level jet.  If the model can simulate the nighttime low-level jet properly, it should be able to simulate other aspects of the diurnal wind cycle properly too, since they are less sensitive to the model parameterizations.  This has entailed a close look at the data as well as the model.  So far, I have found more problems with the data than with the model.  ETL will be correcting the lidar wind profile heights and will have another look at daytime profiler winds.  When I nudge to the observations, it will be nice if the observations reflect reality.

 

Wed Dec 19 AM: Status report:

                                 If you want a serious status report, our interim report to TNRCC has been submitted. Click here for a copy.

                                

A few new model runs have been completed.  They are as follows:

                                    dec6grid4: High surface resolution test.  A new sigma layer is added at 0.996; the rest of the model simulation is unchanged from oct25grid4.  To perform this simulation, it was necessary to reduce the time step on the outer three grids from three times the grid spacing (in km) to 1.2 times the grid spacing.  At the coarser time step, the model would blow up.  Such a reduced time step may detrimentally affect the horizontal diffusion, which in MM5 is tied to the time step, but fortunately it was not necessary to alter the time step on the 4 km grid.

                                    dec7grid4: Gayno-Seaman PBL run, otherwise identical to dec6grid4.

                                    dec14grid4: Gayno-Seaman with default soil moisture availability.

                                    dec16grid4: Gayno-Seaman with very low soil moisture availability.

                                   

 

Wed Nov 7 PM: Status report:

                                 Format and quality assure meteorological data: The NOAA/ETL quality control of the profiler data has been completed and that data set is now available.  I plan to examine all the data and identify data points which appear to be suspect; ETL will affix quality control flags to these data and put together a second version of the data set.  ETL will not be finished with the GPS sonde quality control until next week.  The airsonde data has been quality controlled by PNNL and has been delivered to TNRCC; a copy will be sent to me next week.  The surface meteorological data set has been delivered to TNRCC and UT and the ten-day episode period has been quality-controlled.  Tom Tesche has offered to convert all the data to a format suitable for his model validation software; we will accept this offer.

 

                                 Develop 3D analysis fields: Since the TexAQS data set is not quite complete, we have utilized the NCEP EDAS analyses.  As described below, results with nudging on the 12 km grid are quite promising and we recommend continued use of the EDAS grids for all episode modeling.

 

                                 Second round of modeling: The model runs to date are described below, as are procedures for accessing images and model output.

 

Fri Nov 2 PM: Ah, disk space is a wonderful thing.  A few more runs have been completed and comparison of output has begun.  Meanwhile, I’m going over the qc’d profiler winds to look for anomalies; soon we’ll have a complete data set to compare with the model!

                                

                                 Four complete model runs are in the bag.  They are as follows:

                                    aug31: Control run.  Standard two-way nesting, with nudging to EDAS (3-hourly Eta Data Analysis System) grids on the 108 km and 36 km grids.

                                    sept24grid4: One-way nest test.  Same as Control, but with one-way nesting of grids 3 and 4 with hourly boundary condition updating.

                                    oct26grid4: Analysis nudging test.  Same as One-way nest test, but with nudging to EDAS on the 12 km grid as well as the 108 km and 36 km grids.

                                    oct31grid5: High-resolution test.  Same as Analysis nudging test, but with a 1 km innermost grid with boundary conditions updated hourly.

                                 The names correspond to the output data directories on the TNRCC computer typhoon (in /met/ngammon/output).  They also correspond to quick-look output maps which have now been posted on the Texas A&M web site at http://www.met.tamu.edu/temp/mfs1.  Comparison of the runs is underway; the oct26grid4 run, in particular, looks very promising.

 

                                 Since oct26grid4 seems the best performing run so far, I am placing links to the namelist, configuration, and deck files here.  If run as is, mm5.deck will produce output for only the outer two grids, but it can be modified in the standard ways to run on inner nests too.  The files are in http://www.met.tamu.edu/temp/mfs1/oct25grid4decks.

 

                                 Along the way, I encountered a bug in MM5 which caused MM5 to erroneously estimate elapsed time, with consequences for radiation and for output frequency.  (That’s why the sept25grid4 images are generally not at regular hours.)  The bug was a consequence of numerical precision errors for extended runs with short time steps.  The problem has been fixed, or at least managed, through implementation of a patch I developed.  NCAR has also looked at the problem, and will be implementing a fix for version 3.5.

 

Wed Sept 26 PM: At some point next week, I’ll need more disk space.  I’d like, at a minimum, to be able to retain output from two model runs while performing a third.  My current disk space usage is as follows, in Gb:

                                    1.8 Raw Edas analyses (probable duplication of some stuff in bcd’s directory

                                    1.6 Pregrid output, for model ic, bc, and nudging

                                    1.6 Miscellaneous (mm5 code, gempak code, surface data)

                                    15.1 Output from aug 31 two-way run (7.1 can be deleted soon)

                                    15.8 Output from sept 24 one-way run

                                    3.6 Ic and bc for one-way inner nest

                                    (9.0) Space required for inner nest output

                                 So presently, if I squeeze hard, I can make one more model run.  But on the entire 143.4 disk, only 3.3 remains.  Presumably other users will also want to write to disk soon.

 

Wed Sept 26 PM: The 4 km run was successful over the weekend.  At first glance, there’s no major difference between the two runs.  I’m going to spend the next few days working up some programs to do model comparison and validation.

 

Fri Sept 21 PM: The 12 km run completed semi-successfully.  The only catch was that the model output didn’t quite coordinate itself to occur on the hour; there was a slight drift so that by day 10 the output was about 2.5 minutes late.  This may introduce slight biases when the one-way and two-way nests are compared; I’ll watch for this once I get to grid 4.  Meanwhile, Nestdown choked on the output because the output was more than a time step off from the top of the hour.  I modified nestdown.F to relax this criterion, and the generation of boundary conditions for the 4 km nest is proceeding smoothly.

 

Thu Sept 20 PM: Back in business!  While others here start looking at model output, I’m running a one-way nest version of the entire period.  If the comparison between one-way and two-way is favorable, I can do experiments on one-way nests and save lots of computer time.  So far, I’ve run grids 1 and 2, with hourly output, sent grid 2 through Nestdown to get initial and boundary conditions for grid 3, and am running grid 3.  For reference, grids 1 and 2 took 80 minutes to execute on eight processors.  Grid 3 looks like it will take about 8 hours.

 

Fri Aug 30 PM: Model finishes at 6:45 PM.  Hurray, beat the deadline!  Output looks quite good.  In order to avoid having to transfer large amounts of data over the network, I have installed GEMPAK on typhoon (in my /met/ngammon/gempak subdirectory).  I had to fiddle with shells and switches, but once I got it going it compiled smoothly.  Thanks go to Shannon Minto for leaving the gempak5.6 tar file on /met. 

 

                                 I have compared the output to the previous 12 km run (which had unaltered soil moisture characteristics) and to the observations.  The model run seems pretty nice.  I think the biggest difficulty will be possible erroneous thundershower placement, especially on the 25th.  Most of the inland precip does not reach the ground on the 25th, but it does cool the boundary layer as it evaporates and produces a divergent outflow.  Here is a 4-panel image of rainwater at the 0.765 sigma level showing the distribution of showers during the day.

 

                                 I have prepared two sets of images for quick-look purposes.  The first set covers parts of August 25 and 26, and consists of 2 m temperatures and 10 m winds from the base case run and the 12 km test run.  Images are available from 25/18Z, 25/21Z, 26/00Z, 26/12Z, and 26/15Z.  Notice that the temperatures are more realistically warm in the 4 km nest, which used reduced soil moisture availability.  The urban heat island is not significantly suppressed, although it would be expected to be stronger in the 4 km than the 12 km grid if all other things were equal.  Also noticeable are small-scale divergence signatures over land.  They are manifestations of the evaporating precipitation discussed in the previous paragraph.

 

                                 The second set of images consists of 2 m temperatures and lowest sigma layer winds from August 29 and 30.  The images show the entire 4 km domain; for clarity, winds are shown only at intervals of 8 km.  Images are available from 29/15Z, 29/18Z, 29/21Z, 30/00Z, 30/12Z, 30/15Z, 30/18Z, 30/21Z, 31/00Z, and 31/12Z.  The fields for August 29 look very good.  At first glance, the fields for August 30 seem a little too strong with the northwesterly wind in the morning.  Both days appear to be plausible representations of the wind distribution in the Houston area.

                                

 

Thu Aug 30 PM:  One more MM5 job stops, but it was executing anomalously slowly anyway.  Bright Dornblaser helps me with a technique for making my mm5 runs immune to network troubles, and also may have solved the ‘slow model’ problem.  Model restarted with 12 processors; 3 more are expected to become available in the evening.  At its current rate of progress, the model will finish its run at 11:00 PM Friday!  I have developed an Excel spreadsheet (here's the html version) to convert from elapsed seconds to simulation times.

 

Thu Aug 30 AM:  MM5 run stopped last night around midnight for unknown reasons.  Restarted this morning at hour 36.  At present, it’s running at about 60% of normal speed.

 

Wed Aug 29 PM: Time to take stock of the choices made in the MM5 run, especially those which merit further testing.

                                 Nesting: Two-way nests might be expected to yield fewer artifacts along the margins of grids and possibly a better representation of the large-scale sea breeze.  One-way nests allow for different model configurations (upper boundary condition, soil moisture, etc.) on different grids, coherent outer-nest simulations, and the ability to run only the inner nest for sensitivity studies (a potential time savings of 15%-20%).  Base run is two-way nest.

                                 Spinup: I’ve started the model at 12 UTC August 23.  Starting the model earlier or later will have a random, unpredictable impact (maybe better, maybe worse) on the simulation.  Probably not worth testing unless model errors are found to change significantly with time.

                                 Analysis Nudging: I am nudging on the 108 km and 36 km grids.  Nudging on the 12 km grid would smooth small-scale features but slightly reduce model drift at 4 km.  Probably not worth testing.  Also unexplored: nudging in boundary layer (I’m doing winds but not temps).

                                 Analysis Nudging Coefficients: I am using the default values of the nudging coefficients.  Based on comparisons between the analyses and forecasts, different coefficients may be desirable.

                                 Parameterizations: No particular reason to mess with these, but model performance deficiencies may merit a closer look.

                                 Upper Boundary Condition: May use radiation boundary condition on finer grids if we go with one-way nesting.

                                 Then there are the longer-range issues: How can we obtain the optimal land surface conditions?  OSU LSM with modified input data?  Soil model with modified input data?  New land use categories?  Satellite assimilation or hydrologic modeling?  Another issue: what is the best way to incorporate TexAQS 2000 special data into the simulations?  Analysis nudging?  Grid nudging?  Model error analysis nudging?  Ah well, the fall is long.

                                

 

Wed Aug 29 PM: So far the model has run for 1 hour (clock time) and has made it 6 hours into the simulation.  At this rate, the simulation will take about 40 hours and finish around 8 AM Friday.  I’m saving restart files every 12 hours and recording output data every hour.  The output files are being split into five two-day chunks.

 

Wed Aug 29 PM: The base case run begins!  I have figured out how to request the number of processors of my choice (the ‘export’ command in mm5.deck) and am running on 12 processors.  I decided to make one change from the previous 12 km test run: I reduce the soil moisture difference between urban and surrounding areas.  This is an important change, motivated by the following: (1) the urban/rural temperature difference was about 1 to 1.5 degrees (about 50%) too large in last year’s real time runs when comparing Wharton and Downtown; (2) late August was generally a drought in Texas, culminating in record high temperatures in early September; (3) the daytime convergent wind fields induced by the heat island are not clearly apparent in the surface observations; and (4) the wind fields in the vicinity of Houston are more important to get right than any other aspect of the simulation.  I would have liked to test this change first, but alas, I’m out of time.  The changes to moisture availability for land use categories common to central and eastern Texas were as follows:

                                 Category 1: Urban (interior Houston) – keep at 0.10

                                 Category 2: Dryland Cropland and Pastureland (eastern Texas non-woodlands)– reduce from 0.30 to 0.20

                                 Category 5: Cropland/Grassland Mosaic (central Texas) – reduce from 0.25 to 0.15

                                 Category 7: Grassland (western Texas, northern Mexico) – reduce from 0.15 to 0.10

                                 Category 11: Deciduous Broadleaf (eastern Texas river bottoms) – leave at 0.30

                                 Category 14: Evergreen Needleleaf (eastern Texas Piney Woods) – reduce from 0.30 to 0.20

                                 Where these land use types occur in the 36 km and 108 km grids, I hope that the analysis nudging will compensate for any too-dry soil moisture specification in non-drought areas.

 

Wed Aug 29 PM: The output looks good.  The rainiest days are the first two, consistent with the observations.  Temperatures seem too warm at night and too cool during the day.  Plus, there’s a rather strong effect (at 12 km) from the urban heat island during the day.  Finally, the boundary-layer winds seem to tend to take on diagonal banded structures – a problem with the upper boundary, perhaps?

 

Wed Aug 29 AM: Output files transferred to TAMU.  Had no choice but to do it during the day.  Data moves at the rate of 0.5 Gb/hour.  I’ll need to find a solution to this issue.  One possibility: do all analysis work on TNRCC computers.  Ultimately, this would mean I & TNRCC would have to allow access to everyone here that’s working on the project.  Another possibility: test the transfer speeds in two hops: TNRCC to UT, UT to here.  Other solutions also are possible.

 

Tue Aug 28 PM: I run the preprocessors.  I’m in the middle of copying the preprocessor output to archival directories when the /met partition runs out of disk space.  I’m using 20 Gb myself, but the major increase in disk usage over the past few days appears to have come from mchenry and ataqm.  I delete previous preprocessor output.  I try compressing some preprocessor stuff, but the disk savings is only 10% so it’s not worth it.  Eventually I end up with 3.5Gb available.  This is not enough space for the base case output, but it lets me run 3 domains and write output every 3 hours (estimated disk usage: 2.5 Gb).  This will do for overnight.  The model, with three domains, runs at 24x real time, so the ten-day run should take ten hours.  If all goes well overnight and disk space appears tomorrow, there’ll be time to run the full four grids.  They should take two days on eight processors.  If the output is half-hourly for the ten day period, it would require approximately 35 Gb of disk space.

 

Tue Aug 28 AM: The network connection is back.  I run a few single-nest tests with MM5 and learn (1) it’s not the nesting, (2) it’s not the nudging; (3) it IS the upper boundary condition.  With the four nests, I had been using a radiative upper boundary condition.  According to the documentation, this is recommended for 50 km and below (to allow topographically and convectively generated gravity waves to escape) but is not recommended for grid spacings above 50 km.  The alternative is a rigid upper lid.  The rigid lid allows the single domain to execute for the full two-day period of the test without a blowup.  I’d like to try it with all four domains, but time is short, so I’m going to move to the base case period.

 

Mon Aug 27 PM: Still unable to connect to TNRCC.  After learning that John McHenry has no difficulty connecting to TNRCC, I try reaching the TNRCC web page and find it unaccessible too.  Strange, because I can reach other external sites.  We discuss the problem with the TAMU network people.  They come back and report that a router is down in the TAMU System building.  It’s expected to be up by 7:30 in the evening.

 

Sun Aug 26 PM: In the office to try some diagnostic runs with one nest and with two nests, but the TNRCC computer doesn’t respond at any time between 12:30 PM and 4:30 PM.  I’ll have to wait another day.

 

Fri Aug 24 PM: Model crashes at same time as before.  Decide to run 2-way nests to see if I get different behavior.  This entails going all the way back to the terrain preprocessor, since the orography on the inner nests is different if the nesting is 2-way.  Set up the model to run in the evening; it crashes at the three-hour point again!

 

Fri Aug 24 PM: Why there is a nesting problem is a mystery to me, since I am running with 1-way nesting.  The outer nest should not even know that the inner nests exist!  Just in case I’ve set things up wrong and I’m actually running 2-way nests, I decide to rerun the model with IFEED = 4 instead of 3.  This should delay or prevent the blowup if it’s two-way nests.

 

Fri Aug 24 PM: The model survived until the 3-hour mark before blowing up this time; I guess that’s progress.  Now, instead of the surface data being a problem, the blowup occurs first near the upper boundary.  Fortunately, since the model survived three hours, I have the 3-hour output to examine.  The output suggests a nesting problem: massive 2-delta-x noise on grid 1 where it overlaps with grid 2; noise on grid 2 where it overlaps with grid 3.  Here is an example. 

 

Fri Aug 24 AM: Further inspection of model fields suggests that the preprocessors are having trouble with the input surface fields.  I decide to switch to the MM5 simple soil model, because the fields that would be used as input for it look fine.  The model is restarted.

 

Thu Aug 23 PM: Most development time was spent writing conversion programs for preprocessor output.  I’d erroneously specified the CCM2 radiation package rather than the RRTM; fixing my specification delayed the blowup to 20 minutes into the simulation.  All the preprocessor stuff I examined looked fine; I’ll have to dig around in more detail.  In the 4km grid, the initial 2m temperature looked fine as well.  I had the model generate output at 10-minute intervals so I could watch it “blow up”; here’s what the 2m temperature (K) looked like after ten minutes!  Clearly, I have a few things to look at tomorrow.  Multiprocessor problem? OSU LSM problem? User error?  If I don’t find something soon, I’ll switch to the simple soil model and see how it does.

 

Thu Aug 23 AM: Segmentation violation error in MM5.  Isolate error to entry to subroutine solve.  Bright Dornblaser advises that the problem can be cured by issuing the command limit stacksize unlimited.  That does the trick.  Now I’m getting a CFL blowup after 72 seconds.  Time to inspect the preprocessor grids.

 

Wed Aug 22 N: The mm5.deck command loop for generating fdda files in the Run subdirectory doesn’t seem to work properly.  It generates MMINPUT2_DOMAIN%, where % appears as a black square on my screen.  So I commented out the copy command and generated MMINPUT2_DOMAIN1 and MMINPUT2_DOMAIN2 on my own.

 

Wed Aug 22 N: Copied preprocessor files to TAMU, set up mm5.deck, and tried running the model.  Found that inner nest grid configuration from protocol (135x150) won’t work because grid dimensions are not 3n+1 and grid does not line up with grid of mother domain.  Expanded the inner domain to 136x151 and reran all the preprocessors for the new inner domain.

 

Wed Aug 22 PM: Configure.user: allowing analysis nudging and setting up the parameterizations.

                                 (a) IMPHYS=4: Simple Ice.  Appropriate for tall clouds I don’t care much about.

                                 (b) MPHYSTBL = 1: Look-up table for Simple Ice.  Appropriate for tall clouds I really don’t care much about, when speed is an issue.  Consider changing this to 0 for the final run.

                                 (c) ICUPA=3,3,3,1,1.  Use Grell on 12 km and above.  Slight departure from our real-time and retro runs, where Grell was confined to 36 km and above.  Reason for change: current 12 km grid is much larger, so poor handling of moist convection would have a bigger impact on the 4 km grid.

                                 (d) IBLTYP=5: MRF.  Performs well in tests and allows use of OSU LSM.

                                 (e) FRAD=

                                 (e) ISOIL=2.  Will test this later.

                                 (f) ISHALLO=1,1,1,1,0.  May not need it on 1 km grid, if we get that fine.

 

Wed Aug 22 PM: Question referred to Bright Dornblaser, who pointed me to /met/benchmark_test.  I’ll use the same basic computer setup as in there, except I’ll call MM5env.csh as the first line of mm5.deck (it’s cleaner that way).

 

Wed Aug 22 PM: Ran interpf on all times for all four grids, just to have them available.  Seems like it might be useful to run mm5 now, even though I haven’t had a chance to look at the preprocessor output.  So I’ve fired off an email to Weining Zhao to find out what processor environment the SGI is set up to use.

 

Wed Aug 22 PM: More interpf.  Must specify the atmospheric basic state.  While the model run should be insensitive to small variations of these parameters, large departures of the model simulation from the hydrostatic basic state can cause problems.  To develop a basic state, I have taken the output from the retro run at Galveston at 21Z on Aug 25-Sept 1 and overlaid the temperature profiles onto a single image.  The vertical axis is labeled in sigma * 10,000; p0=100,000 Pa and ptop = 5000 Pa.  I choose 21Z Galveston because I want conditions which represent a transition between marine and continental weather.  A typical sea-level temperature is 30 C, and a few quick calculations demonstrate that a typical lapse rate (dT/dlnp) is 45.  This would yield a temperature of –57 C at 100 mb, which looks pretty good to me.  I’ll fine-tune things by increasing the sea level pressure to 1013 mb (to agree better with conditions during that period) and by increasing the sea level temperature to 304 K.  For the isothermal stratosphere, it looks like 200 K would be a good, round number.

 

Wed Aug 22 PM: On to interpf.  Must specify vertical levels.  For initial run, will use the same vertical levels as with the 35-day retrospective run: 1.0 .99 .98 .97 .96 .95 .94 .93 .92 .91 .895 .88 .865 .85 .825 .8 .775 .75 .72 .69 .66 .63 .6 .57 .54 .51 .475 .44 .405 .37 .33 .29 .25 .21 .175 .145 .115 .09 .065 .045 .025 .01 .0  As in the retro run, model top will be 50 mb.  Wouldn’t want it any lower than 70 mb for the subtropical summertime.

 

Wed Aug 22 PM: Next step: rawins or little-r?  I don’t think so.  Analyses are high enough resolution that there’s not much point in “enhancing” the analysis with rawinsonde data – in fact, applying unsophisticated univariate analyses to the original Eta analyses would degrade them.  I don’t expect to do nudging on the finer grids, and the two days’ spinup time means that any higher-resolution analysis information would vanish anyway.

 

Wed Aug 22 PM: Pregrid and regridder run (apparently) successfully on Sept 5-7 case.  Will not download data back to TAMU because exceeds daytime transfer size limits.

 

Wed Aug 22 PM: Pregrid program does not handle EDAS files properly, extracting only 12-hourly analyses even though the data set contains 3-hourly analyses.  This is because within each 12-hour time window the analyses are arranged in inverse chronological order.  Will sidestep the problem by untarring the files and deleting the 12-hour-old analyses.  Why delete the 12-hour old analyses?  See http://dss.ucar.edu/datasets/ds609.2/docs/awip212.html.

 

Wed Aug 22 AM: Discovered that the August surface file I retrieved from NCAR was actually a set of 3-hour intermediate forecasts.  Missed the correct file number by one digit.  Am obtaining the correct file from NCAR MassStore.  Will not be able to copy it to TNRCC computer until 6PM this evening, per system manager’s request regarding large data transfers.  Do not know the working definition of  “large” in this context, but will assume it to mean >100Mb.  Meanwhile, I’ll take the remaining preprocessor programs out for a spin with the September data.

 

Wed Aug 22 AM: Ran pregrid.  Source EDAS data is missing 12Z Aug 31 2000.  Pregrid should be able to linearly interpolate from adjoining analyses, but it is core dumping.  Am beginning the debug process. 

 

Tue Aug 21: No activity on modeling front today.  I tried to connect late in the day (5:50 PM) but could not get through to typhoon after several tries.  No harm, though, wouldn’t have been able to do much at this late hour.  A few notes from yesterday: First, when running terrain, it seems in the job deck that it is possible to specify the directory of the input files.  It’s not.  The terrain program assumes that files will be found in the Data subdirectory.  Second, I am examining output using GEMPAK.  Until now, there only existed a version 2 to gempak converter, but I’m writing a version 3 converter as I go.

 

Mon Aug 20 PM: Terrain program run successful.  Generated quadruple-nest output.  Output looks fine, except the land-water mask grid does not include Galveston Island.  Land use, etc., look okay.  Will have to figure out how/whether the land-water mask is used.

 

Mon Aug 20 PM: Setting up the terrain job deck, following make terrain.deck command.  Considerations:

                                 (a) Grid sizes: the dimensions in Table 7 of the draft modeling protocol refer to “grid cells”.  MM5 requires specification of the grid corners, and a check of the corner locations in the table confirms that they include the “cross points”, not the “dot points”.  Therefore, I’ll specify each nest in terrain one grid point larger in each direction than Table 7.

                                 (b) Nesting: using one-way nesting because it is better suited to experimentation.  First, it constrains all changes to impact only the nest in which they occur, and second, it allows one to run only the nest of interest.

                                 (c) I’m assuming that the default values for the true latitudes of the Lambert projection are appropriate.

                                 (d) Input data resolution: choosing resolution comparable to or smaller than the grid spacing for each nest.

 

Mon Aug 20 PM: Learned that Bright Dornblaser has run terrain previously.  He’s got the terrain input files in his own directory, except that there are no 2-minute files.

 

Mon Aug 20 PM: Emailing TNRCC (Shannon Minto) to see if MM5 has already been configured (terrain at least) for the episode modeling.

 

Mon Aug 20 AM: Completed transfer of September files.  Suspect the September surface file may be incomplete because some grib decoder errors were encountered when running sample pregrid.  Am now transferring from TAMU to TNRCC the land use and other files necessary for a terrain run.  Our files are two years old, so it would be better to get the data from NCAR directly.  I plan to run terrain first with the transferred data.  If it is successful, I’ll try setting it up to obtain the data from NCAR’s ftp site.

 

Fri Aug 17 PM: August files transferred successfully.  September files will have to wait til the weekend because our computers are being shut down temporarily because of a planned air conditioning outage.

 

Fri Aug 17 AM: Overnight ftp to TAMU worked fine; files readable by pregrid.  Am FTPing files to TNRCC.

 

Thu Aug 16 PM: Attempted trial run of pregrid on Eta data; attempt failed.   Dug around a bit more in the online documentation and found http://www.mmm.ucar.edu/mm5/mm5v3/tutorial/regrid/how_to_get_data.html, which says that I must use the –f BI flag when retrieving data from the MassStore system.  This contradicts http://dss.ucar.edu/datasets/common/advice/MM5.html, which claims that only the global data must be un-COS-blocked.

 

Thu Aug 16 PM: File transfer from NCAR to TAMU going much faster; estimate 35 minutes for 800 Mb file.

 

Thu Aug 16 PM: Session timeout on typhoon, but the ftp connection to NCAR remained for about three hours.  Had received about 240 Mb of the first 800 Mb file.  Will attempt file transfer from NCAR to TAMU, with the idea of then transferring the files from TAMU in to TNRCC.

 

Thu Aug 16 AM-PM: Copied EDAS 3-d and surface analyses from NCAR MassStore system onto temporary disk space at NCAR.  Initiated transfer via ftp to typhoon.  Transfer is proceeding very slowly; am concerned about session timeout with telnet session to typhoon.

 

Thu Aug 16 AM: Located available data sets at NCAR using the following web pages: http://dss.ucar.edu/datasets/common/advice/MM5.html http://dss.ucar.edu/pub/gcip/ http://dss.ucar.edu/pub/gcip/gcip_suarch.html ftp://ncardata.ucar.edu/datasets/ds609.2/inventories/eta.inv

 

Thu Aug 16 AM: Copied MM5 and preprocessor tar files from /met/mm5v3.4 directory on typhoon to /met/ngammon/mm53.4 directory.  Uncompressed (if necessary) and untarred TERRAIN, REGRID, INTERPF, INTERPB, RAWINS, and MM5.

 

Wed Aug 15 AM: Attempted to establish remote connections with typhoon.  Telnet did not work on n-g and rsh did not work on cg.  Communicated with TNRCC; problem fixed at their end by next morning.