#8 NONE.folder has no trace counts

[seismick]

ICPS seems to create a file called NONE.folder, which looks like a job summary.
However, the trace counts for each process are blank.
--
x86_64_gfortran_mpich2
Centos 5.7 Java 1.6.027 fftw2.1.5 mpich2-1.2.1p1

[seismick]

This file also has no trace counts in i686_gfortran_mpich2 as well as x86_64_gfortran_mpich2

[seismick]

The subproject folder file also lacks traces counts under
platform x86_64_intel91_mpich2 built with:
Centos 6.0 Intel compilers 11.1 MPICH2 1.3 FFTW 2.1.5 JDK 6u35

[seismick]

Trace count is missing also in
platform i686_intel91_mpich2 built with:
Centos 5.8 Intel compilers 11.1 MPICH2 1.2.1p JDK 6u35

[Joe Rathoon]

I swear that this worked long ago. Do you remember the old big tarball
from cpseis.org? I got it twice back in 2009 or 2010. Only cfe and
icps worked in those, so I gave cpseis a rest for a few years .
It was installed under RHEL3.9, therefore a very old PC, which died.
I do still have the output files from those early trials archived on
a USB disk. Upon inspecting all the logs, I confirm the 2010 build
did print the trace counts in the .folder file. The 2009 build created an
empty .folder file, but it did print the trace counts in the history.
Now it appears that the subroutine cps_folder gets the trace counts by
scanning the history records for the word AFTER.
Next time I built cpseis (from subversion), those AFTER counts do not
appear in the icps output. I looked at a lot of icps logs, and see
that process HEADSUM prints trace count BEFORE. HEADSUM is the only
process which calls trscan. I assume that trscan still works, but
it is not being called by the icps job executor.
Regretably, I no longer have the old PC to look at that old source
code. Can no longer download that old tarball either.
Combing through the subversion revisions, I notice that a bug was
fixed relating to trscan at 2011-06-13, but I can not see that fix
causes this problem. Was something else changed before 2010-12-20,
the first entry in sourceforge?

[seismick]

Another bug is swatted, thanks to those clues. Actually, the revision to cps.f90 was the culprit.
A test was added in cps_post_process(), after calling timer_start()
and before calling trscan_print():
if (ntr > 0)
Now ntr may be -2 (NEED_TRACES) or 0 (NO_MORE_TRACES).
So the -2 was screened out to avoid negative array size allocation. However, blocking 0 will prevent the final calls to trscan, and that is enough to derail the writing of the result.
At the start of trscan_print, there is a test:
if (n < 0 ) return
Where n is the number of traces.
So for consistency, change the test in cps_post_process in cps.f90 to
if (ntr > -1)
Then trscan will put statistics into history, and subsequently be summarised in the subproject.folder file.

Note: to obtain the trace counts, JOB_DATA parameters should be set
Record Keeping = YES
History Option = not NONE (the default)
Sub-Project Name = something based on jobname
If left as NONE, it will be overwritten by every job.

[seismick]

This was fixed long ago, and can be closed.