Another possibility which will maximize flexibility is to have your
program read information necessary to run your simulation from the
command line. With this approach you can use a script to batch many
simulations and have complete control over the naming of input and
output files (and any other simulation parameters.)
Suppose your executable program is called 'SIMULATE.EXE', and suppose
that the input data for the simulation is in 'INPUT.DAT' (but it could
be any filename); and that you want the output data from your program to
go to the file 'OUTPUT.DAT' (again this could be any filename).
You could then execute your program from the command line as follows:
SIMULATE INPUT.DAT OUTPUT.DAT
Your program is required to read from the command line the name of the
input file and output file (in that order).
Following is a small test program (with only very limited error checking
/ reporting) that will do this. Please note, this is a demonstration - a
production program will provide appropriate management of error messaging.
You could also arrange for all necessary information necessary to run
your simulation to be stored in a configuration file. Your program would
then obtain the name of the configuration file from the command line. It
would open the configuration file and read its contents to determine how
to perform the simulation. In some ways this is a good solution because
it reduces command line clutter and for future reference your simulation
inputs are fully documented in the configuration file.
Hope this helps.
David.
------------------------------------------------------------
PROGRAM TESTARG
IMPLICIT NONE
INTEGER :: errorCode
CHARACTER (LEN = 2048) :: infile, outfile
errorCode = 0
CALL ProcessCommandLine(infile,outfile,errorCode)
IF (errorCode .NE. 0) GOTO 99
WRITE(*,*) 'INPUT FILE: ',TRIM(infile)
WRITE(*,*) 'OUTPUT FILE: ',TRIM(outfile)
! ... insert code to process input and output files
99 CONTINUE
IF (errorCode .NE. 0) THEN
STOP 'ERROR DETECTED'
ENDIF
CONTAINS
SUBROUTINE ProcessCommandLine(infile,outfile,errorCode)
CHARACTER (LEN = *), INTENT(OUT) :: infile, outfile
INTEGER, INTENT(OUT) :: errorCode
! ... Local variables
INTEGER :: NARG,length,status
errorCode = 0
NARG = COMMAND_ARGUMENT_COUNT ()
IF (NARG .LT. 2) THEN
WRITE(*,*) 'ERROR: number of command line arguments (',NARG,')
must be at least 2'
errorCode = -1
GOTO 99
ENDIF
CALL GET_COMMAND_ARGUMENT (1,infile,length,status)
IF (status .NE. 0) THEN
errorCode = -1
IF (status .EQ. -1) THEN
WRITE(*,*) 'ERROR: length of input file name (',length,') >
',LEN(infile)
ELSE
WRITE(*,*) 'ERROR: Failed to retrieve input file name'
ENDIF
GOTO 99
ENDIF
CALL GET_COMMAND_ARGUMENT (2,outfile,length,status)
IF (status .NE. 0) THEN
errorCode = -1
IF (status .EQ. -1) THEN
WRITE(*,*) 'ERROR: length of output file name (',length,')
> ',LEN(outfile)
ELSE
WRITE(*,*) 'ERROR: Failed to retrieve output file name'
ENDIF
GOTO 99
ENDIF
99 CONTINUE
END SUBROUTINE ProcessCommandLine
END PROGRAM TESTARG
When compiled and executed with the following command (under Windows):
testarg input.dat output.dat
The following expected output is produced:
INPUT FILE: input.dat
OUTPUT FILE: output.dat
On 15/11/2011 11:37 AM, Daniel Grimwood wrote:
> Similar to what John suggested, you could script it up to run in different directories whose name have an index appended, and then within each directory keep all the files the same as before. Saves doing any modifications to the program.
>
> Either a big single script that keeps increasing the index would work, or if you're using a queueing system just pass the index to the next script as an environment variable.
>
> Regards,
> Daniel.
>
>
> On Tue, 15 Nov 2011, you wrote:
>> I have a program for which the results are stochastic and I want to obtain many versions of the output to assess variability. Currently, everytime, I start a new run I need to change the filename and resave it. If there a simple way to modify the program so that I can have it run many times and record the output in each file seperately. i.e. create a loop so that the file name changes automatically after each run and then allow it do multiple runs automatically. I am getting tired of making a small change and then recompiling the program. it seems inefficient.
>
> ------------------------------------------------------------
> Dr. Daniel Grimwood
> iVEC Supercomputing Development and Applications Specialist
> 26 Dick Perry Avenue, Technology Park
> Kensington WA 6151
>
> Phone: +61 8 6436 8680
> Fax: +61 8 6436 8555
> Web: http://www.ivec.org/
> IM: [log in to unmask]
> Email: [log in to unmask]
|