[MITgcm-devel] f_basic
Jean-Michel Campin
jmc at ocean.mit.edu
Fri Jul 7 12:33:39 EDT 2006
Hi Martin,
OK, as I can see, point 1 is not crutial (for a new user ...,
and a MITgcm_tutotials would have fit better);
i will implement point 2 (since it's useful to have this
option with testreport), and will not use "prepare_run"
as proposed in point 3 because of this nightmare issue.
And no changes in CVS modules for now.
Jean-Michel
On Fri, Jul 07, 2006 at 04:30:34PM +0200, Martin Losch wrote:
> Hi Jean-Michel,
>
> a thought from an "outside": the problem with having all verification
> experiments is not so much the testing itself (which can easily be
> restricted to just a few with testreport), but the downloading.
> That's something that you don't realize when you are at MIT, where
> the download speed is acceptable, but e.g. here at AWI I wait for up
> to one hour for the entire stuff to download. Therefore I certainly
> like to MITgcm_"light" versions (verif_basic, etc.)
>
> Martin
>
> On Jul 7, 2006, at 4:21 PM, Jean-Michel Campin wrote:
>
> >Hi,
> >
> >I propose to remove the following CVS modules:
> > MITgcm_verif_basic
> > MITgcm_verif_atmos
> > MITgcm_verif_ocean
> >and to add a new one:
> > MITgcm_verif_tutorials (or MITgcm_tutorials) with the code
> > and the tutorials only (without the other verification-
> >experiments)
> >
> >1) The main reason: for a new user point of view, I don't think that
> >downloading only few experiments is really useful:
> >-more difficult to update
> >-packages are documented with an illustrative verification exp.
> > that might be missing (e.g., zonal_filt with MITgcm_verif_ocean)
> >-only an expert cvs-user (not like me) knows what he will get
> > when using these modules (e.g., cvs co -P was giving me few
> > empty directories ???)
> >
> >2) And for us, to test a limited number of experiments (because
> > it's too long to test all of them), we can modify testreport.
> >
> >3) I would like to use "prepare_run" to reduce the size
> > of the MITgcm directory to download, by avoiding duplicated
> > files (e.g., grid-cs32 files): keep only one copy
> > (my preference, the one from a tutorial_*/input dir, if possible)
> > and use it in all the different experiments.
> > This will clarify which experiments use the same grid, and which exp.
> > use a different one (same thing for bathymetry files, forcing
> >fields ...)
> > We can certainly think of other (& better) ways to store shared
> >files,
> > but this way seems an easy first step toward a clearer situation.
> > Now, back to this cvs-modules issue, if we have plenty of experiment
> > sub-sets for downloading, changing from time to time, it's becoming
> > a nightmare to keep track of where to put a shared file.
> >
> >Suggestions ?
> >
> >Jean-Michel
> >_______________________________________________
> >MITgcm-devel mailing list
> >MITgcm-devel at mitgcm.org
> >http://mitgcm.org/mailman/listinfo/mitgcm-devel
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
More information about the MITgcm-devel
mailing list