Information will be added here are questions are generated and answered.
I'll add to this list as I think of things:
There are two kinds of test data: non-image and image data. The non-image test cases are located in http://www.cs.rit.edu/usr/local/pub/ncs/parallel/Fortran/TestCases/. The image test cases are located in the sub-directories of http://www.cs.rit.edu/usr/local/pub/ncs/parallel/Fortran/ImageFiles/.
Remember that contin analyzes the data Y(i) at each T(i). The Y's are the experimental data, the T's are the times at which the experimental data is "clocked". The image files are read one record at a time into an integer*2 type variable. That value should ultimately be stored in Y(i), a real. The value for the same pixel in each image file should be stored in the Y(i) related to the T(i) read from the times file.
There is some processing after the y's and t's are read that happens in READYT that you'll need to add to your subroutine(s) that reads the y's. See the readts.f95 file in the http://www.cs.rit.edu/usr/local/pub/ncs/parallel/Fortran/AuxiliaryCode/ for guidance.
I ran into a similar problem which I tracked to a need to reset the grid values (G) for EACH pixel. The G values are set in SETGRD, called from contin.f95. I'm not sure why/where the G values get altered, but they seemed to be off by a very little after the first run was finished. This generates tons of diff output making it very hard to debug.
I found it easiest to write my debugging output to a completely different file, OUT. (Use an unused unit number, say 300 and write to it). So, for example, to debug the problem identified above, I would execute both the FAKE and the textImage data thru the new version of contin and diff the two OUT files.
I also found that for debugging with MPI, that moving around a couple of statements:
CALL MPI_FINALIZE(ierr)was useful in getting the output buffers flushed when I wanted them to be. Other things I tried were less successful. For example, if I would close the file I was writing to and there was later writing to that file, I would lose what was there to begin with. It may be possible to open the file in append mode, but then you need to make sure that you delete it/them each time before you run your tests.
Also, it is important to be conscious of line length. I seem to remember 136 or 142 characters per line in free form Fortran. If you extend beyond that, particularly in output statements, you may get misleading results. I spent several hours tracking a problem that didn't exist because my output line was too long.
Yes, use status='unknown'. Be aware though that this will allow you to overwrite your own files.
Fortran will create a file named fort.the_unit_number.
Although I did not find it documented anywhere, the limit seems to be 175.
Not until execution time with a criptic "BAD ADDRESS" message. There MAY be some environment variables that can be set to alleviate this problem.
Yes, but I would suggest instead that you ADD your own labeled commons. It is a good idea to separate out the variables by type. I read somewhere, for example, that any character data must go in its own separately labeled common. I think this is a memory layout issue, but am not certain.
Different computer systems store integers (e.g.) in different orders. Some put the high order byte on the left of the word, others do it in reverse. Therefor, the input data may be prepared on a machine uses a different format than the one contin is being used on.
All image input AND the mask will have a 1 written in pixel[1,1]. Then when read, if pixel[1,1] is 256 (1 shifted left 8 bits, i.e., written by a machine that stores the data in reverse), contin can modified to determine that it needs to swap image bytes as it is read. This will work regardless of where that data is being read.
contin can be modified to handle it internally:
NOTE: In all cases, the mask file's format is identical to the image file format, i.e., 16 bits per pixel. You will NOT process the pixels for which the 16 bit reads from the mask file show a zero,i.e. there is no need to read these pixel values from the image files at all.
See the output specifications for (hopefully) complete information. Be sure to add a .raw extension to the name. ReadTimesFile will show you how to do this. Also, IF you needed to swap the bytes in the input images, be sure to swap the bytes in the scaled YLYFIT's before you write them to the output images!. See the examples in the Auxiliary Code directory for examples of how to do this.
I ran into a similar (the same?) problem broadcasting the input image file names. I have 513 of them of length 40 characters. In order to do them properly I had to
character*40 imageFilename(512) ! array to hold imageFilenamesNote that the length had to be set to the product of the number of filenames and the length of each.
character*40 outName ! base for output image filename
common /charImageData/ imageFilename, outName
equivalence( CIEQUIV(1), imageFilename(1))
call MPI_BCAST( CIEQUIV, 513*40, MPI_CHARACTER, 0, MPI_COMM_WORLD, ierr )
Do a man mpirun when on parasite or paranoia. The ones that stand out are:
You might check out /opt/SUNWhpc/include/mpif.h and take a look at the examples in http://www.cs.rit.edu/usr/local/pub/ncs/parallel/Fortran/MPIFortranExamples/. Also, there is list of routines (given the C call order) at http://www.mpi-forum.org/docs/mpi-20-html/node306.htm. Just remember that you need to use Fortran MPI constants and add an error return value as the last parameter (See http://www.mpi-forum.org/docs/mpi-20-html/node19.htm.