home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.apollo
- Path: sparky!uunet!wupost!gumby!destroyer!terminator!pisa.citi.umich.edu!rees
- From: rees@pisa.citi.umich.edu (Jim Rees)
- Subject: problem with writing large files from Fortran
- Message-ID: <5a8e0403.1bc5b@pisa.citi.umich.edu>
- Sender: news@terminator.cc.umich.edu (Usenet Owner)
- Reply-To: Antonio Hernandez <AVH@IBMA.ipp-garching.mpg.de>
- Organization: University of Michigan IFS Project
- Date: Fri, 14 Aug 1992 12:56:47 GMT
- Lines: 61
-
- Can anyone help this guy?
-
- Date: Thu, 13 Aug 92 14:09:14 EST
- From: Antonio Hernandez <AVH@IBMA.ipp-garching.mpg.de>
- To: Jim Rees <JIM.REES@UMICH.EDU>
- Message-Id: <9208140700.AA03976@umich.edu>
- Subject: question
-
- Dear Mr.Rees: I have a question Which I would like to formulate to the
- Apollo world. If this is not the appropriate channel please forgive me
- and let me know how to proceed. Thanks: Antonio Hernandez.
- from: Antonio Hernandez
- e-mail: avh at ibma.mpa.ipp-garching.mpg.de
- subject: question to the apollo world
-
- Question: I have an Apollo DN10000 at the Simon Bolivar University
- (USB) in Caracas-Venezuela. It runs under SR.10.2.p and has one
- multidisk (w0:0+w1:0) comprising two 700Mb units in a sector-striped
- configuration plus a second multidisk (w0:1+w1:1) of two 370Mb units
- with the same sector-striped configuration. It also has two processors
- and 64Mbytes of RAM: Let's call this machine "USB" (Fortran Compiler
- ftn.v.10.8p).
- I also work with a DN10000 at the Max Planck Institute for Astro-
- physics in Munich Germany in a colaboration project. This station,
- which we can call "MPA", is a one processor machine with a multidisk
- (w0:0+w0:1) of two 700Mb units in a cylinder-striped configuration,
- with 32Mb RAM and running under SR.10.1.p. (Fortran Comp.:ftn.v.10.7p)
- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=======>
- The problem is as follows: I run MUNICH code (fortran code for
- molecular calculations) on the MPA station without any trouble. This
- particular code opens a large file for reading (about 100MB)and
- simultaneously opens a file for writing the processed data: this
- second file will be also very big at the end of the program (some
- 200MB). The MPA mchine does mostly I/O and expends little CPU time on
- this molecular code.
- --When I run the same code on the USB machine, a strange thing happens
- when half of the output file is written: You can hear large disk
- activity but the size of the output file doen not change, i.e, the
- machine is writing data to some temporal file (swapping area?) and
- from there to god knows where!, but it never writes the final data
- to the output file. It seems like there is a limit on the number of
- blocks this machine can move, or it lost the address of the last
- record read on the first file. Both read and write files are sequential
- unformatted with a record length of 1400 integer words.---
- I have tried recompiling but when the size of the problem is small the
- code runs without problems (small input output files of about 40Mb) and
- when the size increases (input output files of about 80Mb) it breaks.
- Once I could make it run by running the code on the first multidisk
- (I/O also in the first multidisk) and I move all paging (swapping) to
- the second multidisk: On other words, I keep the operating system and
- the code running on the first multidisk and turn off paging there by
- changing the name of the swapping device on /dev directory, and
- define new OS paging area only on the on the second multidisk with the
- /etc/swap command.
- All this is very strange because here in Germany I do not seem to have
- any problem with the size of the problem: Right now I am running a
- very large case that handles I/O files of 300Mb each!. Is there a
- problem with the RS.10.2.p operating system? or with the way it
- handles swapping, because the /etc/swap command do not even exist under
- RS.10.1.p operating system at the MPA machine. Is there a hardware probl
- ****PLEASE HELP****Antonio Hernandez.
-