[MITgcm-support] "multiple tests" for testreport

[Chris Hill]

Sounds good - except input/base|code/base sounds bad as its probably in a
lot of scripts and e-mail notes as input/|code/ and will cause headaches to
people if its is frivolously moved. However, as long as its done
consistently and everywhere **and well documented** we can make that change.

My code_alt/ checkins look like what you described. They use code/ as well
as code_alt/foo for the mods i.e. they work as

../../../genmake2 -mods="../code_alt/foo ../code"

That way you don't need duplicate pacakges_conf for experiments where just
tiling or forcing changes etc...

Chris 

> -----Original Message-----
> From: mitgcm-support-bounces at mitgcm.org 
> [mailto:mitgcm-support-bounces at mitgcm.org] On Behalf Of 
> Alistair Adcroft
> Sent: Monday, March 15, 2004 9:41 AM
> To: mitgcm-support at mitgcm.org
> Subject: RE: [MITgcm-support] "multiple tests" for testreport
> 
> I agree that we should allow code variants but I think we 
> should limit the code variants to not changing the "total" 
> SIZE of a configuration. Variants should allow for alternate 
> schemes, forcing or tiling but if we allow the total number 
> of grid-points to change then the meaningful association of 
> files under an experiment directory becomes tenuous, even if 
> labelled appropriately with sub-directory names.
> 
> Why bother keeping input/ and input_alt/ and not just replace 
> input/ with have input/base/?
> 
> 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 Chris Hill
> Sent: Sunday, March 14, 2004 11:54 AM
> To: mitgcm-support at mitgcm.org
> Subject: RE: [MITgcm-support] "multiple tests" for testreport
> 
> 
> All,
> 
> Sounds good - but we should be a little more structured:
> 
> We should use a tree structure for this otherwise it will get 
> illegible and like Dimitris I want code variants too. The 
> final structure should be something like.
> 
>  input/
>  input_alt/
>  input_alt/sea_mount_bathy
>  input_alt/shelf_bathy
>  input_alt/complex_forcing
> 
>  code/
>  code_alt/
>  code_alt/s192t_8x4
>  code_alt/s176t_8x4
>  code_alt/sea_mount_bathy
> 
>  results/
>  results_alt/sea_mount_bathy
>  results_alt/s192t_8x4/
> 
> 
>  If we don't do this at the top of an experiment level we 
> will end up with too many directories at the top and it will 
> look messy. 
> 
>  **NOTE** if we allow code_alt and input_alt arbitrarily 
> together we will have a combinatorial explostion! The 
> combinations exercised would therefore be limited to 
> {"matching_NAME_pair:matching_NAME_pair", 
> "nomatch_NAME:base", "base:nomatch_NAME"}, where NAME is a 
> subdirectory entry from [input_alt|results_alt] and "a:b" are 
> selections from input_alt:code_alt respectively. This means 
> that in results_alt/ we only need one name. 
> 
> Chris
> > -----Original Message-----
> > From: mitgcm-support-bounces at mitgcm.org 
> > [mailto:mitgcm-support-bounces at mitgcm.org] On Behalf Of Ed Hill
> > Sent: Thursday, March 11, 2004 10:14 PM
> > To: MITgcm-support
> > Subject: [MITgcm-support] "multiple tests" for testreport
> > 
> > 
> > Hi folks,
> > 
> > Based on discussions with JMC and AJA, I've modified testreport so 
> > that one can create multiple (similar) tests for each 
> directory within 
> > verification.  The idea is that input files can be shared between 
> > similar tests.
> > 
> > The way it works is that directories within verification will have 
> > multiple tests run if they meet the following criteria:
> > 
> >   1) the test dir must contain a "build" directory
> > 
> >   2) the test dir must contain one or more extra "input" 
> >      directories each with names of the format "input.*" 
> >      (eg. input.alt_bathy, input.alt_forcing, etc.)
> > 
> >   3) the test dir must contain one or more extra "output" 
> >      files in the format "results/output.txt.*" where the 
> >      extension on each file matches each of the extensions 
> >      on the input.* dir names
> > 
> > So an example would be:
> > 
> >   exp0/input                  <== standard/shared input files 
> >   exp0/input.ex               <== extra and/or modif inputs
> >   exp0/results/output.txt.ex  <== results for the ".ex" case
> > 
> > Please let me know if you have any ideas for improvements. 
> JMC said he 
> > would soon check in some examples to demonstrate it.  And 
> attached is 
> > an example of the output it generates.
> > 
> > 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
> > 
> 
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://dev.mitgcm.org/mailman/listinfo/mitgcm-support
> 
> 
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://dev.mitgcm.org/mailman/listinfo/mitgcm-support
>