[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