[MITgcm-support] "multiple tests" for testreport

heimbach at mit.edu heimbach at mit.edu
Mon Mar 15 10:04:53 EST 2004


I think I agree with Chris' notes below.
I've already checked in a few AD-specific setups
which follow this scheme, e.g. under
MITgcm/verification/global_ocean.90x40x15/

code
code_ad
code_ad_vecinv
input
input_ad
input_ad_vecinv
results
results_ad
results_ad_vecinv

-Patrick



Quoting Chris Hill <cnh at MIT.EDU>:

> 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
> > 
> 
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://dev.mitgcm.org/mailman/listinfo/mitgcm-support
> 






More information about the MITgcm-support mailing list