Dear MM5 MPP Users, The following email exchange relates to a problem that a user encountered performing a set of custom software modifications to a couple of the MM5 routines that input LOWBDY_DOMAIN files in MM5v3 format. The specific issue for MPP is that only node zero actually is allowed to act on the files at run time, yet all processors must see relevant flags and exceptions. In this particular case, the user is looking for end of file on a LOWBDY_DOMAIN file so that the program (a regional climate application of MM5) can open up the next LOWBDY_DOMAIN file in the sequence. As originally written, the other processors did not get notification of the end-of-file exception on the I/O processor. The fix was to handle the end-of-file exception in such a way that it can be easily made known to the other processors. As a general note (but not to discourage): modifying the MM5 I/O mechanisms for MPP is considered an advanced topic. Your friendly MM5 answer beast, Rotang, January 23, 2001 PS: Since both of the correspondents below are named "John," I have edited this with [] in hopes of making it easier to follow. It was that or eat one of them. -R. ------------------------------------------------------------------- From: John G. Michalakes [michalak@mcs.anl.gov] Sent: Tuesday, January 23, 2001 4:09 PM To: John A Taylor; John Michalakes Subject: RE: MM5 MPP Complication Hi John, I think I may have found the problem. If you test for end of file on a read, note that only the process that actually does the reading will detect this, as with here: 100 CONTINUE IF(DM_IONODE())READ (IUNIT,ERR=9007,END=9008)FLAG CALL DM_BCAST_INTEGERS(FLAG,1) Only the monitor node will jump to 9008 -- nobody else knows anything about this. Instead, do this: IF ( DM_IONODE() ) THEN READ (IUNIT,IOSTAT=IER)FLAG ENDIF CALL DM_BCAST_INTEGERS(IER,1) IF(IER.NE.0)GOTO 9008 CALL DM_BCAST_INTEGERS(FLAG,1) Make sure there are no other instances of this in your code. -John Michalakes >..... John Taylor wrote: > >Hi John [Michalakes], > >I have tried a few more things but can't quiet spot the problem. If you >have a little time to take a quick look at the modifications I have made >you might spot something obvious. The code is located in:- > >/home/climate/jtaylor/WORKBENCH/denali/MM5V3.4/MM5/MPP/build/lbdyin.f > >my modifications are surrounded by 'cjat' comment lines. > >Thanks, > >John [Taylor] > > >At 09:32 AM 1/22/2001 -0700, John Michalakes wrote: >>John [Taylor], >> >>It sounds as though the other processors are getting out of sync with >>respect to the monitor processors. One must be very careful to make sure >>that (1) only the monitor process performs actual operations on the I/O unit >>and (2) any information that the monitor has that the other processors need >>to control their iteration through the series of MM5v3 records is broadcast. >>This sounds like an error along one or both of these lines in the code you >>have added/modified. >> >>-John [Michalakes] >> >>> -----Original Message----- >>> From: John A Taylor [mailto:jtaylor@mcs.anl.gov] >>> Sent: Sunday, January 21, 2001 5:01 PM >>> To: John Michalakes >>> Subject: MM5 MPP Complication >>> >>> >>> >>> Hi John [Michalakes], >>> >>> I have modified the MM5 code to read multiple data files, up to >>> 9999 files. >>> I have modified lbdyin.F and bdyin.F in MPP/build and added an >>> include file >>> and some initialization code in mm5.F >>> >>> I have succeeded in reading the first file and running MM5 for one month, >>> and seem to have read the second file on the 0 compute node:- >>> >>> ATTEMPT TO READ LOWBDY CONDITIONS FOR DOMAIN 1 >>> Open Low boundary file = LOWBDY_DOMAIN1_0002 >>> SKIP FIELD NAMED RES TEMP >>> FOUND INPUT FIELD SEAICE FOR 1986-02-01_00:00:00.0000 >>> FOUND INPUT FIELD TSEASFC FOR 1986-02-01_00:00:00.0000 >>> FOUND INPUT FIELD SNOWCOVR FOR 1986-02-01_00:00:00.0000 >>> FOUND LOWER BOUNDARY CONDITION AT MODEL TIME 1986-02-01_00:00:00 >>> >>> *** LOWER BDY CONDITIONS VALID BETWEEN 1986-02-01_00:00 - >>> 1986-02-01_06:00 >>> ARE READ IN AT TIME = 44640.00 MINUTES FOR DOMAIN 1 >>> Open file BDYOUT_DOMAIN1_0001 >>> >>> but am finding that it is generating an error message relating to the big >>> header on the remaining nodes:- >>> >>> FOUND INPUT FIELD SNOWCOVR FOR 1986-01-31_12:00:00.0000 >>> SKIP LOWER BOUNDARY CONDITION AT 1986-01-31_12:00:00 >>> SKIP FIELD NAMED RES TEMP >>> FOUND INPUT FIELD SEAICE FOR 1986-01-31_18:00:00.0000 >>> FOUND INPUT FIELD TSEASFC FOR 1986-01-31_18:00:00.0000 >>> FOUND INPUT FIELD SNOWCOVR FOR 1986-01-31_18:00:00.0000 >>> SKIP LOWER BOUNDARY CONDITION AT 1986-01-31_18:00:00 >>> Error reading big header from subs temp file >>> STOP: BARE STOP lbdyin >>> CALLING MPI_ABORT >>> >>> I have checked the big header on the files and can read them without >>> problems using readv3 so I suspect that there is, possibly, a subtle error >>> relating to the MPP version. >>> >>> The working directory that I am using is located on denali at:- >>> >>> /home/climate/jtaylor/WORKBENCH/denali/MM5V3.4/MM5/Run >>> >>> Any advice greatly appreciated! >>> >>> Best wishes, >>> >>> John [Taylor] >>> >>> >>> ____________________________________________________________________ >>> >>> John Taylor, PhD >>> Computational Scientist Phone: (630) >>> 252-7162 >>> Mathematics and Computer Science Fax: (630) 252-6104 >>> & Environmental Research Divisions E-mail: >>> jtaylor@mcs.anl.gov >>> Argonne National Laboratory Web: >>> http://www.mcs.anl.gov/~jtaylor >>> 9700 South Cass Avenue >>http://www-climate.mcs.anl.gov >>Building 221 >>Argonne, IL 60439-4844, USA > >