[MITgcm-support] Odd .cvsignore

[Ed Hill]

On Tue, 2004-03-23 at 12:29, Alistair Adcroft wrote:
> Ed,
> 
> Is global_ocean.cs32x15/.cvsignore different from all the other .cvsignore's
> for a reason or can I change it? (You created it...)


Hi Alistair,

Yes, I did that because of the files/dirs created by testreport as part
of its multi-runs-per-verification-dir feature that JMC requested and I
recently implemented.

But I think its an ugly hack and we can (and should) do better.  The
current testreport would benefit from a ~50% re-write that cleans it up
and re-designs it to do multiple tests per test directory.  By multiple
tests I mean situations where:

 1) we use the same binary with slightly different sets of input 
    files (so no need to re-compile)

 2) we use the same inputs but with small code modifications 
    (thus requiring re-compiles)

 3) both -- modifications to code and inputs

If we can work out a sane directory and file naming convention then all
of the above can be done in the same manner that testreport currently
does it which is: "if the files exist, then run the tests".

So heres a proposal for the naming convention within verification:

  ${TEST}/code                 \
         /input                |==> current pattern
         /build                |
         /results/output.txt   /

         /code_XXX                     \
         /input_XXX                    |
         /input_XXX_yyy0               |
            ...                        |==> "extended pattern"
         /input_XXX_yyy7               |
         /results/output.txt_XXX_yyy0  |
            ...                        |
         /results/output.txt_XXX_yyy7  /

where the added strings mean:

 "_XXX" ==> designates a set of runs that requires code 
              modifications

 "_XXX_yyy" ==> designates different sets of additional inputs 
       that correspond to a single code configuration "_XXX"

and all of the contents of the various "_XXX_yyy" directories are used
in addition to (actually "hiding" as is done with genmake) the files
contained within the "base" (code, input) directories.  This way we can
share large binary inputs such as bathymetry.

So can anyone think of a better arrangement?  Any suggestions would be
appreciated.

Ed


-- 
Edward H. Hill III, PhD
office:  MIT Dept. of EAPS;  Room 54-1424;  77 Massachusetts Ave.
            Cambridge, MA 02139-4307
email:   eh3 at mit.edu,  ed at eh3.com
URL:     http://web.mit.edu/eh3/
phone:   617-253-0098
fax:     617-253-4464
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20040323/26bac07b/attachment.sig>