A bug was discovered that affects output to the MMOUT files when the code is run with the MPP_IO_NODE=1 in the namelist, but okay when MPP_IO_NODE=0. This option causes makes node-0 be an I/O server only -- it doesn't do any work -- so that MM5 history can be output asynchronously. One needs to allocate one extra processor. This is just background, not the bug. The bug and a resulting fix is described in the email thread below. Thanks and parallel tips of the ROTANG head-fringe to Jennifer Cram and Brent Shaw.
Asynchronously yours,
Rotang
Oct. 18, 2002
-----Original Message----- From: Jennifer Cram [mailto:cram@atmet.com] Sent: Wednesday, May 08, 2002 8:31 AM To: michalak@ucar.edu Subject: Re: MPP_IO_NODE Works great! Thanks. Jennifer John Michalakes wrote: > Hi, > > I found it and have a fix for you (I hope). Download the file: >> http://www2.mmm.ucar.edu/mm5/mpp/write_fieldrec.F
> > (also attached to this email). Copy the file into domain/io (overwriting the > file that's there) and then make mpp. The dataset generated with MPP_IO_NODE > set to 1 should now be readable. > > Thanks, > > John > > > > >>-----Original Message----- >>From: cram@skolai.atmet.net [mailto:cram@skolai.atmet.net]On Behalf Of >>Jennifer Cram >>Sent: Wednesday, January 30, 2002 5:16 PM >>To: michalak@ucar.edu >>Subject: MPP_IO_NODE >> >> >>John, >>Again, running on a linux pc cluster. >> >>When I run with MPP_IO_NODE=1 the job appears to run correctly (on the >>processors I tell it to) and in the right amount of time (same as when >>MPP_IO_NODE=0). However, the MMOUT files are unreadable by RIP (ripdp) >> >>from the MPP_IO_NODE=1 run - I assume that means they're incorrect in > >>general. The file size appears the same as in an MPP_IO_NODE=0 run. I >>rerun with MPP_IO_NODE=0 and there isn't any problem. >> >>I changed the print in ripdp to print out the flag where it aborts - >>flag should be 0. >> >>MM5 V3 data does not begin with a big header 1099956224 >> >>Jennifer >> >> >>As always,
Rotang
September 6, 2002