Frequently Asked Questions for MCIP -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- MCIP Version 4.0 (9 September 2011) What are the changes in MCIPv4.0? The changes in MCIPv4.0 are summarized in the "ReleaseNotes" file and in greater detail in the "CHANGES" file. You will need to use I/O API v3.1 with this release, and you will use the netCDF F90 module rather than the netCDF F77 include. Do I need to update to MCIPv4.0? It is entirely up to you. Updating is strongly recommended if you are using ANY of the following: - WRF - polar stereographic projection - horizontal grid spacing of 8 km or smaller - new option for albedo in CMAQv5.0 that depends on sea ice array Do I need to update my script from MCIPv3.6 to MCIPv4.0? If you want to use MCIPv4.0, you need to use the new script because the input namelist has changed. There have also been some minor bug fixes in the script. Can I use netCDF 4 with MCIP? Yes. Will MCIP work on a Mac? Yes. It has been tested with Intel Fortran and gfortran. Can I still use MM5v3 data in MCIPv4.0? Yes. Do I need to update to MCIPv4.0 to use CMAQv5.0? Probably not, but it's a good idea. See comments about v4.0 update, above. If I run the two-way-coupled WRF-CMAQ system (available with CMAQv5.0), do I need to run MCIP? No. The functionality of MCIP is handled within the two-way-coupled WRF-CMAQ system in AQPREP. Why do I need I/O API v3.1 for MCIPv4.0? The I/O API include files PARMS3.EXT, FDESC3.EXT, and IODECL3.EXT have been encapsulated in the I/O API v3.1 module M3UTILIO. Using this module will reduce user errors that had been associated with changes to I/O API parameters in I/O API but not in the CMAQ system codes themselves. It helps protect users like you! Why do I need to use the netCDF F90 module instead of including the netCDF F77 include file? MCIP now relies on the F90 netCDF functions and routines rather than the F77 versions. Reading netCDF files under F90 is greatly simplified. Why did you change all of the error handling? The error messages from netCDF-related errors have been made more explicit to parrot back the text version of the error rather than the integer error code. In addition, removing line numbers was part of compliance with the Fortran 2003 standard. How can I find out what model/version/options/MCIP I used for my MCIP output? Check out the metadata that is included in the I/O API headers of MCIP output files. Use the command "ncdump -h ", and see the character field FILEDESC that is part of the I/O API header (near the end). That field has been filled for MCIP since MCIPv3.3. It is best viewed on a terminal of 80-character width. It is also echoed at the end of the MCIP log file. Do you take user suggestions? All user suggestions are considered, but not all are accepted. -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- MCIP Version 3.6 (19 March 2010) and Version 3.5 (29 October 2009) What are the changes in MCIPv3.6? The changes in MCIPv3.6 are listed briefly in the "ReleaseNotes" file and in greater detail in the "CHANGES" file. Please pay particular attention to the NOTEs in the "ReleaseNotes" file because they describe some of the future changes that are anticipated for MCIP. Do I need to update to MCIPv3.6? It is entirely up to you. If you are using WRFv3.1+, then updating to the new release of MCIP is strongly encouraged. Also, if you are using WRF nests or a projection in WRF other than Lambert conformal, then you should use the latest code. Do I need to update my script from MCIPv3.4 to MCIPv3.6? There are some new user options related to toggling on/off output fields and for choosing a reference latitude for WRF Lambert conformal grids. If those changes do not interest you, then you probably are OK with your previous script. Those new user options will just be assigned default values if you choose not to set them via the script/namelist. Can I use netCDF 4 with MCIP? It appears to be working with the version of I/O API 3 that was updated 28 October 2009. I'm using MM5 fields. Did anything change that affects my runs? Not in any appreciable way, unless you want to take advantage of the additional choices related to output fields. You may see small changes in rotated wind direction under very unique circumstances. Why did you make the C-staggered latitude, longitude, and map-scale factors show up in GRIDDOT2D for my MM5 runs when MM5 uses the B-staggered grid? Six 2D fields is a small price to pay. Can anything in CMAQ use the new, optional u- and v-component wind fields yet? Changes to CMAQv4.7.1 are expected in eddyx.F and edyintb.F. Do I need to output the u- and v-component winds on the C-staggered grid if I'm using MM5? No. Why do you need two sets of wind components right now? If you choose to output the C-staggered winds for your WRF domain, the B-staggered winds are still needed for plume rise. An update to use the C-staggered winds has not been reconciled in SMOKE or in the meteorologically dependent portion of the plume rise that has been included in CMAQ. Can anything in CMAQ use the new, optional potential vorticity field yet? Not in the released code. Does anything in CMAQ use the vertical velocity field predicted by the meteorological model (i.e., what happens if I turn it off)? Nothing in CMAQ uses WWIND. Your METCRO3D files will be smaller if you turn off WWIND. What extra fields do I need to turn on in the "wrfout" (history) file with the WRF Registry? MCIPv3.6 can make use of the following fields if they are available in the WRF output (and these fields are NOT part of the WRF output by default in WRFv3.1): fractional land use (LANDUSEF), aerodynamic resistance (RA), stomatal resistance (RS), vegetation fraction in the Pleim-Xiu LSM (VEGF_PX), roughness length (ZNT), and inverse Monin-Obukhov length (RMOL). I already have LANDUSEF in my "wrfout" (history) files. Do I need to also supply the GEOGRID file? No. The GEOGRID is a backup in case the user forgot to add LANDUSEF to the WRF history file via the WRF Registry. (This is handy for groups that are collaborating on meteorological and air quality simulations, where the WRF simulations have already been conducted.) Do I have to use the Pleim-Xiu land-surface model in MM5/WRF to run MCIP? No. Some of the MCIP/CMAQ physics probably work better with the Pleim-Xiu (PX) LSM than other land-surface models, but changes have been made to improve the use of MCIP and CMAQ for other LSMs. One thing to note is that the mixing within the planetary boudnary layer (PBL) can be more consistent between MM5/WRF and CMAQ if the Asymmetric Convective Model version 2 (ACM2), which is commonly used with the PX LSM, is used in MM5/WRF. Why is there a variable to specify the reference latitude for the WRF Lambert conformal simulations? The notion of a "center latitude" (which is required in the I/O API used by CMAQ) is not available in the WRF output. There is additional flexibility in how one can define simulation domains in WRF beyond what was available in MM5. Just going on what's available in the WRF output headers, it is impossible to "reconstruct" an existing MM5 domain that covers the same area under certain circumstances. Several users have inquired about matching MM5 and WRF domains and getting the I/O API headers consistent. (There are multiple ways of using the fields in the I/O API headers to represent the same domains.) Thus, the option for users to hand-pick the center (or reference) latitude was created in MCIP. Several users had access to this change in an unreleased code, MCIPv3.4.1.1, which was initially made available in December 2008. This change is formally released as part of MCIPv3.6. How can I find out what model/version/options/MCIP I used for my MCIP output? Check out the metadata that is included in the I/O API headers of MCIP output files. Use the command "ncdump -h ", and see the character field FILEDESC that is part of the I/O API header (near the end). That field has been filled for MCIP since MCIPv3.3. It is best viewed on a terminal of 80-character width. It is also echoed at the end of the MCIP log file. How can I visualize Mercator output from MCIP? It's not working in PAVE or IDV, You can try VERDI, IDL, R, or GoogleEarth. -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- MCIP Version 3.4.1 (4 December 2008) What are the changes in MCIPv3.4.1? The changes in MCIPv3.4.1 are listed briefly in the "ReleaseNotes" file and in greater detail in the "CHANGES" file. Please pay particular attention to the NOTEs in the "ReleaseNotes" file because they describe some of the future changes that are anticipated for MCIP. What was the problem with the Spatial Allocator that caused the change to GRIDDESC for WRF Lambert conformal between MCIPv3.4 and MCIPv3.4.1? In MCIPv3.4, the reference latitude for the GRIDDESC and the I/O API headers was selected arbitrarily (but conveniently) to be the first true latitude for Lambert conformal projections. In the Spatial Allocator, the GIS utility routine, PROJ4, gives the wrong result when the reference latitude is equal to the first true latitude; the details have not been thoroughly investigated. However, to work around this issue, the reference latitude for Lambert conformal was arbitrarily changed to the average of the true latitudes, and the tangent Lambert conformal case (which would have the average of the true latitudes equal to the true latitudes...because there is just one) was temporarily prevented in MCIP. Why can't you just stop changing the GRIDDESC file??? If there were an easy solution to map the WRF headers into the CMAQ system via the I/O API, we would have done it already! (Thanks for your patience.) -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- MCIP Version 3.4 (4 November 2008) What are the changes in MCIPv3.4? The changes in MCIPv3.4 are listed briefly in the "ReleaseNotes" file and in greater detail in the "CHANGES" file. Do I need MCIPv3.4 to run CMAQv4.7? Yes, particularly for the dry deposition velocity calculations in CMAQ and for the bi-direction flux option. Do I need MCIPv3.4 for WRFv3? Yes. Some minor changes were introduced to adjust to WRFv3. In addition, there are corrections in MCIP to the way the WRF grids are depicted in the MCIP output. There are also changes for new physics options in WRFv3 and added support for the NOAH land surface model. My GRIDDESC file for WRF data is different from my MM5 GRIDDESC for the same grid. Why? The WRF model offers additional flexibility in the way that grids are defined beyond what was available in MM5. The "center latitude" in the I/O API header that has commonly been associated with the center of the projection in MM5 is not a standard input in WRF...so it is not a standard output for WRF. In MCIPv3.3, an attempt was made to accommodate the flexibility in WRF's domain definitions, but there was an oversight that affected the downstream programs, so the method used in MCIPv3.3 is not correct for the CMAQ system and the I/O API utility routines. Thus, in MCIPv3.4, a completely different method was used for WRF grids such that the "center latitude" for Lambert conformal projections was chosen to be the first true latitude. This will make the YCENT different, as well as the XORIG and YORIG which are computed relative to the point at XCENT, YCENT. [NOTE: This solution was updated in MCIPv3.4.1 to use the average of the true latitudes rather than the first true latitude for the reference point.] I want to use my emissions from my MM5-based project with WRF data on the same grid, but SMOKE keeps crashing! What can I do? You have three options. (1) Edit the SMOKE routines to comment out the error- checking on the GRIDDESC variables YCENT, XORIG, and YORIG. (2) Use the I/O API utility "m3edhdr" to edit the headers of your MCIP output files to adjust YCENT, XORIG, and YORIG to the MM5-based projection's values. (3) Rerun the emissions with the WRF-based output. These options should be exercised *VERY* carefully! Dry deposition velocities can be computed in CMAQ. Do I need to compute them in MCIP anymore? No. The dry deposition velocity calculations were left in MCIP for this release cycle so that users can convince themselves that the methodology was implemented consistently in MCIP and CMAQ. Note: The dry deposition velocity calculations will be removed from MCIP in the next major release. -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- MCIP Version 3.3 (1 Aug 2007) What are the changes in MCIPv3.3? There are several scientific updates in the M3Dry dry deposition routine. In addition, legacy user options (RADMdry dry deposition, recalculation of PBL fields, recalculation of radiation fields, input using MM5v2 format) have been removed. A few minor bugs have been corrected, and some updates have been made for WRFv2.2. A metadata section was added to the MCIP output files to improve traceability of the MCIP version and the input data sets. Also, MCIP has been made more flexible with regard to near-surface fields so that land- surface models in addition to Pleim-Xiu (such as NOAH) can be better accommodated. A few new fields have been added to output (largely to support the forthcoming inline dry deposition calculations in the CCTM), while some have been removed (most notably the diagnosed 1.5-m and 10-m temperatures). Consult the ReleaseNotes and CHANGES files (and the code itself!) for more details. Do I need to update my script to run MCIPv3.3? Yes. The user definitions for the PBL and radiation options have been removed, and they are no longer valid namelist variables. What happened to the 1.5-m temperature and 10-m temperature fields? I need them for emissions! The diagnosed temperatures at 1.5 m and 10 m AGL were removed from the MCIP output in MCIPv3.3. These temperatures were diagnosed in MCIP using an algorithm that is unrelated to the PBL schemes used in the meteorological model, and differences between the 1.5-m temperature diagnosed in MCIP (with that algorithm) and the 2-m temperature diagnosed in the PBL model within the meteorological model can be very significant (e.g., ~5-6 deg C). In an effort to keep the meteorological and air quality models as consistent as possible, the MCIP-diagnosed temperatures were removed in favor of the 2-m temperature. Internal processes in MCIP (e.g., in the dry deposition model) now use 2-m temperature. While the 2-m temperature has become a somewhat standard output field in the meteorological models over the past few years, 2-m temperature is not available in "older" versions of some models; in that case, 2-m temperature is diagnosed in MCIP and made available in METCRO2D. Emissions should now use "TEMP2" rather than "TEMP1P5" and/or "TEMP10". Were other fields removed with MCIPv3.3? In addition to 1.5-m and 10-m temperature (TEMP1P5 and TEMP10, respectively), the inverse of the laminar boundary resistance (RBNDYI) and the total Jacobian at the surface have been removed because no downstream processes used those fields. Also, dry deposition velocities are no longer computed for two chlorine species (VD_ICL1 and VD_ICL2) because they are not required for CB05; those species are only used in CB-IV with chlorine extensions. Are there any new fields in the MCIPv3.3 output? Yes. If fractional land use is available in the input to MCIP, then the fractional land use (by category) is added to GRIDCRO2D. In addition, vegetation fraction (VEG) and leaf-area index (LAI) are output in METCRO2D for all runs. Lastly, soil moisture (SOIM1 and SOIM2), soil temperature (SOIT1 and SOIT2), soil type (SLTYP), and canopy wetness (WR) are output if they are available in the input meteorology (not just for PX runs); the five soil fields must all be available (as a package) to appear in the output. I have sensitivity tests with different meteorological model options, and I'm overwriting my MCIP output files. My metadata isn't changing, though. What's wrong? The metadata will appear in the first instance of an MCIP output file. It will not be updated if the file is overwritten. The easy solution is to move or delete the original files and just create new MCIP files with each run. I set LDDEP=0 to compute dry deposition velocities inline in CMAQ, but I can't figure out how to make it work in CMAQ. What's wrong? The option to compute dry deposition velocities inline in CMAQ is not released as of CMAQv4.6. It should be released in 2008. For now, set LDDEP=4, and run MCIP and CMAQ as you've always done it. My project really depends on {pick at least one of [RADMDry], [recalculated PBL parameters], [recalculated radiation parameters], [MM5v2-formatted data]}, but I want to use the latest MCIP. What can I do? The Release Notes that accompanied MCIPv3.2 (the previous release) indicated that these options had been targeted for removal in this release of MCIP. In the time that elapsed, no users protested to keep the options available, so the options were removed, as promised. You can either keep using the version of MCIP that you've been using, or transition to more recent science. I want to use the minimum Kz formulation in CMAQ that's been available since CMAQv4.5, and I'm using WRF input. Can I do it now? Yes, as long as your WRF output file includes the field LANDUSEF (fractional land use), which has been made available in WRFv2.2. My MM5 run used the NOAH LSM, and my MCIPv3.3 output is different from my MCIPv3.2 output. What's going on? Some new code has been added in MCIPv3.3 to better accommodate additional land-surface models, such as the NOAH LSM, for both MM5 and WRF. Some near-surface fields that were only captured for the Pleim-Xiu land-surface model are now captured and used in MCIP as long as they are available in the meteorological model output. Some of those fields are now in the MCIP output. It looks like MCIPv3.3 can accommodate the Pleim-Xiu land-surface model in WRF, but PX doesn't seem to be in my release of WRF. What's going on? The Pleim-Xiu land-surface model is being implemented in WRF, and it should be available in NCAR's release of WRFv3, targeted for spring 2008. My GRIDCRO2D file is MUCH bigger with MCIPv3.3 than it had been. Why? The fractional land use (by category) is now included in the GRIDCRO2D file to support the forthcoming inline dry deposition in CMAQ. The fractional land use for the urban area (LUFRAC_01) does not match the percent of urban area (PURB). Is there a bug? No. This is intentional. The fields represent slightly different quantities. LUFRAC_01 is the fraction of urban area compared to all other land use categories such that the sum of LUFRAC_{nn} is 1.0. PURB is the percentage of urban area related to the proportion of land within the cell. I'm not running CMAQ with chlorine or mercury, so I don't need those extra dry deposition species. Can I turn them off in the MCIP output to save some disk space? No. That option was eliminated in MCIPv3.3. You will just get six (it was eight before this release) additional dry deposition species in METCRO2D. CMAQ will ignore the extra fields. If conserving disk space is important. you can modify MCIP so that those fields are not written to the output, If we're already up to MCIP version 3 and beyond, then why are some of my directories (and other documentation) referencing "MCIP2"? This is an artifact of the developmental software configuration management archive in RTP. The entry for MCIP in the archive is called "MCIP2". It really does not have anything to do with the version number for the program. -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- MCIP Version 3.2 (26 Sept 2006) What are the changes in MCIPv3.2? There are several minor changes and updates for MCIPv3.2. Most notably, the I/O API header variable settings for meteorology fields from the WRF-ARW are modified to reflect the additional capability to have the center of the coarse domain located elsewhere than the center of the projection, which is an option that is not possible with MM5. With this change, applications of CMAQ that use WRF-ARW fields as input will no longer adhere to the "grid family" paradigm for the Models-3 I/O API, and a separate GRIDDESC file will be needed for each WRF-based domain. Another noteworthy change in MCIPv3.2 is a correction to the "last wet time" algorithm in the M3Dry dry deposition routine for applications that do not use the Pleim-Xiu land-surface model in the input meteorology. In addition, the polar stereographic and Mercator projection settings in the I/O API are updated again. One new field, land-water mask (LWMASK), is added to the GRIDCRO2D file to support future work. Finally, in MCIPv3.2, several legacy user options are tagged as obsolescent, and they are targeted for removal in the next release of MCIP. These obsolescent options include RADMDry dry deposition, PBL recalculation options, radiation recalculation options, and processing data in MM5v2 format. Several other minor changes have been made in MCIPv3.2; consult the ReleaseNotes and CHANGES files for additional details. I'm running the same domain for WRF and for MM5, and the GRIDDESC file has different numbers in it. What's wrong? Nothing. The different numbers will project the same domain. In GRIDDESC files for MM5-based data, the XORIG and YORIG are the location of the lower-left corner of the domain with respect to XCENT and YCENT at the center of the projection (using the "grid family" paradigm). For WRF-ARW-based data, XCENT and YCENT are the center of the *domain* (and not necessarily the center of the projection), and XORIG and YORIG are the lower-left corner with respect to that point. Can WRF-NMM data be processed through MCIP? Not at this time. There is no "mmheader" file with my WRF-based MCIP run. What's wrong? Nothing. The "mmheader" file contains the contents of the MM5 header. Because MM5 data are not in a "standard" format, "mmheader" is convenient. It's easier to put it in a separate file rather than clutter the MCIP log file. The contents of the WRF header can easily be viewed by using "ncdump -h ". Are there any options in WRF-ARW that are incompatible with CMAQ? So far, just one. The Eta/Ferrier microphysics lumps all hydrometeors into "total condensate", and that field is output using the same variable that is otherwise assigned to cloud water mixing ratio. CMAQ currently needs a breakdown of the hydrometeor components, so this scheme is currently blocked from being processed through MCIP. -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- MCIP Version 3.1 (27 Feb 2006) What are the changes in MCIPv3.1? There are several minor changes to the code for MCIPv3.1. The dry deposition velocity for elemental mercury was updated. Also, the automated calculations of some grid parameters were modified for WRF so that the center of the projection is not restricted to a cell corner. In addition, a minor correction was made for the I/O API header for data sets with Mercator projection. If I am using MCIPv3, do I need to upgrade to MCIPv3.1? Users do not need to upgrade from MCIPv3.0 to MCIPv3.1 unless the mercury option in CMAQ is going to be used. Users who have WRF-ARW (formerly WRF-EM) data should consider upgrading to MCIPv3.1 to take advantage of minor corrections in the code, but this is not required if MCIPv3.0 already runs with the user's WRF data set. Users who have data with Mercator projection (either MM5 or WRF) should upgrade to MCIPv3.1. New users should start with MCIPv3.1. If I ran MM5 (or WRF) without the Pleim-Xiu land-surface model, can I use the "M3Dry" dry deposition routine in MCIP? Yes. While "M3Dry" was specifically written to take advantage of fields that are available in the output from the Pleim-Xiu land-surface model, there is some code that creates those fields within MCIP for meteorology data sets that do not already have them. This code probably could be improved, but it is not an impediment to using "M3Dry". -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- MCIP Version 3.0 (19 Aug 2005) What were the major changes in MCIPv3.0? The major change was to allow meteorology fields to be input from either MM5 or WRF. There are also new optional dry deposition species for chlorine and mercury with the M3Dry scheme. There is also an option to use fractional land use in MCIP if it is imported from an MM5v3 pre-processing file. The detailed list of changes is in the file "CHANGES". I want to run MCIP with WRF model data. What do I need to do? There are a handful of things that need to be done in WRF to run MCIP with WRF data. 1. The WRF model must be WRFv2.0 or newer. 2. Must use the WRF-EM core. (WRF namelist variable dyn_opt=2. This is the default.) MCIPv3 does not support WRF-NMM (NCEP core). 3. Output must be in WRF I/O API (using NetCDF) format. (WRF namelist variable io_form_history=2. This is the default.) 4. Must use non-hydrostatic dynamics in WRF. (WRF namelist variable non_hydrostatic=.true. This is the default.) 5. WRF output should be hourly at most. (WRF namelist variable history_interval=60, or fewer, minutes. The default is 180 min.) 6. The following 2D variables need to be added to the WRF output (history) file: UST, ALBEDO, EMISS, and ZNT. Variables can be added to the history file by adding "h" in the 8th column of the WRF Registry on the line that describes the variable. Also, the water vapor mixing ratio and mixing ratios associated with the explicit moisture can go negative in WRF. This is a result of the mass conservation and the advection scheme used in WRF. Negative mixing ratios will cause problems in CMAQ. There are two namelist variables in WRF that eliminate negative mixing ratios (mp_zero_out and mp_zero_out_thresh), but they are not invoked by default. Users need to decide whether or not this should be controlled in WRF or downstream. Either way, MCIPv3 will not permit negative mixing ratios to be passed to CMAQ. In addition, a floor value of 1.0e-14 kg/kg has been set for water vapor mixing ratio in MCIP since negative mixing ratios are otherwise zeroed out in WRF. A positive water vapor mixing ratio is required for the aerosol model in CMAQ. Where do I need to specify if my dataset is from MM5 or WRF? The user does not need to indicate if the input meteorology files are from MM5 or WRF. MCIP automatically determines if the file is MM5 or WRF by trying to open the input file as a NetCDF file. If the file can be read as NetCDF, MCIP assumes the input is a WRF dataset. Otherwise, MM5 is assumed. When using MM5 data, it is normal to see a message in the MCIP log file that says, "NCOPN: : Not a netCDF file". Are there any new output fields in MCIPv3.0? One new output field is PURB, or percentage of urban area. This field appears in GRIDCRO2D if an additional input file that contains fractional land use information (e.g., MM5's TERRAIN file) is provided for input. PURB can only be generated currently for MM5v3-based MCIP runs. There are also optional dry deposition velocities in METCRO2D for 6 chlorine and 2 mercury species. Were any output fields eliminated in MCIPv3.0? No. I ran MCIP with WRF input data, and there is no GRIDCRO3D file. What happened? GRIDCRO3D contains reference height fields that are relevant for non-hydrostatic MM5, but not for WRF. GRIDCRO3D will not created for WRF. Older versions of SMOKE have a minor dependency on this file, but a change should have been made in the recent release to extract WRF layer heights from METCRO3D rather than from GRIDCRO3D for plume rise calculations. CMAQ does not require GRIDCRO3D. I want to run with MM5 data, and I'm having problems compiling some of the new routines with WRF. Can I just shut off the WRF part of MCIPv3? No. MCIPv3 is an integrated code for both MM5 and WRF. The locations of the NetCDF library and the file "netcdf.inc" need to be verified in the Makefile and the code must be compiled as a total package. I ran MCIP with the options for chlorine and mercury dry deposition, but I don't want to run those versions of CMAQ. Do I need to rerun MCIP? No. There will just be 6 extra chlorine species and 2 extra mercury species in METCRO2D. No other species dry deposition are affected if these options are turned on in MCIPv3. The chlorine and mercury species in METCRO2D will be ignored. I want to run with chlorine (and mercury) but I want to use RADMDry instead of M3Dry. Can I do this? No. MCIPv3 is only set up to generate chlorine and mercury dry deposition velocities using M3Dry. Do I need to change my script to use MCIPv3.0? Yes. There have been several changes to the MCIP script for MCIPv3.0. Most notably, the windowing variables I0 and J0 have been renamed Y0 and X0 to make MCIP more general. Also, the option to read the MM5 TERRAIN file has been added so that fractional land use can be processed. The names of the environment variables for the output files have also been modified, and the logic surrounding the number of input meteorology files has been generalized. In short, it is recommended that users start with a new script rather than trying to adapt their existing scripts to include the MCIP updates. I can't find my TERRAIN file. Can I use a different file to provide fractional land use? Since the fractional land use fields appear in all of the MM5v3 preprocessing output files, any of the TERRAIN, REGRID, RAWINS, LITTLE_R, and MMINPUT files can be read into MCIP to obtain fractional land use. I'm using MM5v3 input files, and I don't have the files to provide fractional land use. Can I still run CMAQ? Yes. This is not a problem for CMAQ. PURB supports an option to modify the minimum Kz in CMAQv4.5. PURB is not required; the minimum Kz calculation will otherwise revert to the method used in CMAQv4.4. I already have MCIP and emissions files created for CMAQ, but I want to take advantage of the new minimum Kz formulation in CMAQv4.5. Do I have to start over again since I don't have PURB in my GRIDCRO2D file? Fortunately, users can run MCIPv3 for one hour with the fractional land use input and the appropriate MM5 file to create a new GRIDCRO2D file that contains PURB. This new GRIDCRO2D file can be used in place of the old GRIDCRO2D files for applications that are already underway. For most users, the other five fields in GRIDCRO2D should be unaffected by this change. I ran WRF, and I want to use the new minimum Kz formulation in CMAQv4.5. Can I do this? [*** See update with MCIPv3.3 ***] No. As of now, WRF does not have fractional land use fields available in the output. MCIPv3 is not set up to use WRF output with an MM5 TERRAIN file (or other MM5 preprocessing file) to obtain the fractional land use information. I can't get I/O API 3 to work properly on my machine, and I need to run MCIP. What can I do? The subroutine ioparms3 (which is called from init_io.F) is the only dependency on I/O API 3 in MCIPv3. If you want to use I/O API 2.2 with MCIP, modify the routine init_io.F by commenting out the call to ioparms3 and the variable checks below it (starting with the comment "Verify that the I/O API library..."). Then recompile and run MCIPv3 with the I/O API 2.2 library. You should, however, ensure that your I/O API library and the parameters in MCIP are consistent (e.g., if the maximum number of species has been increased in your I/O API library, then parms3_mod.F in MCIP needs to be modified to reflect this change). I want to use the Intel compiler on Linux. What else do I need to do? In addition to the compiler options in the Makefile, it may be necessary to also set the following environment variables (noted in C-shell, below, but can be easily adjusted for KSH/BASH): To reverse the order of the bytes on reading MM5 files: setenv F_UFMTENDIAN big To find the shared-object file, libcxa.so.5: setenv LD_LIBRARY_PATH /path-to-your-Intel-compiler/lib To find file ifcore_msg.cat for debugging: setenv NLSPATH /path-to-your-Intel-compiler/lib/%N I don't know the layer structure of the MM5 file. How can I find out what it is? There is a new option in MCIPv3 to run with all of the MM5 layers without specifying the structure in the script. Users can run MCIP for the full MM5/WRF layer structure by setting the script variable CTMLAYs = "-1.0". If layer collapsing is desired, users can run MCIP for one hour with the previous setting for CTMLAYS to determine the structure (which will appear in the log file), then set the CMAQ layer structure based on the MM5/WRF structure. I set BTRIM = 0 to use the full extent of my MM5 files in CMAQ, but the output dimensions smaller by 3 in each dimension. What happened? Actually you are getting the full extent of your MM5 files if you set BTRIM = 0. The output in the METCRO2D and METCRO3D files is 3 smaller in each dimension, but that accounts for two things. First, the MM5 dimensions are in terms of dot points, while the CMAQ dimensions are in terms of scalar (or cross) points (i.e., cells). The dot point dimensions are inherently one larger than the scalar point (e.g., cell) dimensions, so that accounts for one of the three. The other two cells in each dimension are the one-cell picture-frame boundaries for CMAQ. Unlike MM5, the CMAQ files containing the full fields (i.e., GRIDCRO2D, GRIDCRO3D, METCRO2D, METCRO3D) do not include the boundary cells. The CMAQ boundary file (METBDY3D) contains the picture frame around METCRO3D, and METBDY3D was filled using MM5 fields. I heard there was an option to interpolate meteorological fields to finer horizontal grid spacing with MCIP. Is this true? Not anymore. The option existed as "hidden" code in MCIPv2.3 and prior releases, but it had some bugs in it. The code has been removed as of MCIPv3 in favor of some code optimizations. The preferred method of creating fine-scale meteorology is to run the meteorology model at the desired horizontal grid spacing, and then process through MCIP.