[MITgcm-support] Odd .cvsignore

[Alistair Adcroft]

Ed,

I replaced your .cvsignore but it should still work - we need all the
.cvsignores to be the same otherwise it is *impossible* to maintain them.

The proposal sounds good - you will obviously need a build_XXX to correspond
to the code_XXX otherwise you will need to re-compile for each test.

A.
--
Dr Alistair Adcroft            http://www.mit.edu/~adcroft
MIT Climate Modeling Initiative        tel: (617) 253-5938
EAPS 54-1523,  77 Massachusetts Ave,  Cambridge,  MA,  USA

-----Original Message-----
From: mitgcm-support-bounces at mitgcm.org
[mailto:mitgcm-support-bounces at mitgcm.org] On Behalf Of Ed Hill
Sent: Tuesday, March 23, 2004 1:47 PM
To: MITgcm-support
Subject: Re: [MITgcm-support] Odd .cvsignore


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