Overview/General.
The rough specifications for the
observation set.
The draft version of the task schedule.
Rough pseudo-code calling sequence for ensemble filter.
Rough draft of User's Guide Overview.
Flowchart of intended User's Views.
I have named the project repository DART so when you check
out the repository, your sandbox will be installed in a directory also
called DART. You can sue me later. At this point, it is in
my home directory, we will move it when the RAID array is operational.
[That should be a momentary inconvenience.] Since it is in my home
directory, I would ask that you not add any large files to the repository,
such as object or data files. At this time, I have about 200 MB of free space
and the current project is about 34+MB.
I predict this will be useful for those of us with multiple "groups".
Sometimes it is terribly useful to have the entire project under the SAME
unix group, this can be accomplished by setting the "sticky" information
for the entire DART sandbox. In this example, I am presuming you want to
change the DART project so that all the members of the group "cgddart"
(which must include yourself) be allowed to peruse the project.
You have to be positioned just before the DART directory for the ones
that specifically reference DART.
I set the group sticky bit on the repository, so everything added to
the repository will inherit the repository group attributes (including
... group). To set the sticky
bit in your sandbox (assuming the project already has the right attributes):
setting the sticky bit for your personal sandbox is a good thing.
The current "tag" of the project is rel-0-0 .
We need to come up with a policy regarding when to "commit" a
sandbox to the repository. (i.e. does it need to pass a test suite...)
Really want to explore/use
autoconf
to generate the makefile and such ... after I understand the
status quo "build" procedure. All in good time ...
As I build on more NCAR platforms, I'll generate more platform-specific
files (the BLUE argument below). At this point, I
am using the following naming convention:
mkmf.platform[.prod]
(to differentiate between production and development compiler settings)
I am exploring Brian Eaton's perl scripts (
mkSrcfiles, and
mkDepends)
to facilitate the build. A (Gnu) makefile contains the logic on how to
build for specific platforms and runs both scripts to build the targets and
dependencies. One of the caveats is that the modules and the files containing
the modules are necessarily named the same.
The mkSrcfiles utility assumes the existence of an input file
./Filepath, and writes an output file ./Srcfiles that
contains the names of all the files that match the patterns *.F90, *.F,
and *.c in all the directories from ./Filepath plus ./. The files are
listed one per line. At this point, I need to modify
the scripts to recognize .f or I need to rename all files to .F
To create a local version of the project ... a "sandbox"
For the purpose of simplicity, I am assuming you will be creating your
DART sandbox on a machine that need not be in CGD. It the
machine IS inside CGD, the directions do not change
(but this is a bit of overkill).
On a remote filesystem
This necessitates a valid account on goldhill and presumes you are running csh,tcsh
on a remote machine.
Creating some ssh keys (
ssh-keygen ) is a great way to avoid botching your password every time you issue a
cvs command when using ssh.
setenv CVS_RSH ssh
setenv CVSROOT :ext:goldhill.cgd.ucar.edu:/home/thoar/CVS.REPOS
cvs co DART
The first two commands can be (should be) put in your dotfiles.
If you are using multiple CVS repositories, you can obviate the need
to keep switching your CVSROOT variable by using this alternate form of the
"checkout" command:
setenv CVS_RSH ssh
cvs -d :ext:goldhill.cgd.ucar.edu:/home/thoar/CVS.REPOS co DART
cvs update -dRP
cvs commit [-m "your message goes here"]
cd ..
One more thing ...
newgrp cgddart ;# change default group
cd DART ;# get to DART sandbox
cd .. ;# want to be above sandbox
chgrp -R cgddart DART ;# recursively change group for entire sandbox
cd DART ;# get to DART sandbox
chmod g+s `find . -type d` ;# recursively set group sticky bit for all directories
chgrp -R cgddart DART
chmod g+s `find DART -type d`
Coding Standards all of which are worth beer
I can think of no reason why the
CCM4 Coding Standard should not work for us. I don't want
to keep making cosmetic changes to the code, so we might as well
do it the same way from the start.
Additionally, I prefer to
Build
There are two methods being explored at the moment. They require a
list of source code as input. Creating the custom list of source code for
each particular build is "left as an exercise for the interested reader" ...
mkmf
"make makefile"
Given a file containing a list of source code filenames
(mkmf_targets
in the example below) and a file containing platform-specific environment
customizations (e.g. mkmf.sun.devel),
mkmf makes a makefile.
I have mkmf installed in my /home/thoar/scripts directory,
so if you add that to your CGD PATH ...
newgrp cgddart
cd DART/work
vi mkmf_targets ;# create list
mkmf -t mkmf.sun.devel mkmf_targets
make
./a.out | tee seq_obs.log
The CAM method
mkDepends [-t dir] [-w] Filepath Srcfiles
option | value | meaning |
---|---|---|
-t | dir | Target directory. If this option is set the .o files that are targets in the dependency rules have the form dir/file.o. |
-w |   | Print warnings to STDERR about files or dependencies not found. |
arguments | ||
Filepath | the name of a file containing the directories (one per line) to be searched for dependencies. | |
Srcfiles | the name of a file containing the names of files (one per line) for which dependencies will be generated. Usually the result of running mkSrcfiles. |
newgrp cgddart cd DART/work vi Filepath ;# create list gmake -f Makefile.CAM ./a.out | tee seq_obs.log
Alphabet Soup     | Description |
---|---|
CVS | Concurrent Versions System |
DA | Data Assimilation |
DAReS | Data Assimilation Research Section |
DART | Data Assimilation Research Testbed |
DODS | Distributed Oceanographic Data System |
EAKF | Ensemble Adjustment Kalman Filter |
EnKF | Ensemble Kalman Filter |
ESMF | Earth System Modeling Framework |
L96 | the Lorenz 96 model |
NetCDF | Network Common Data Format |
OSSE | Observing System Simulation Experiment |
PE | Primitive Equations |
RMS | Root Mean Square (Error) |
RMSE | Root Mean Square Error |
TLM | Tangent Linear Model |
WRF | Weather Research and Forecasting Model |
Document: Related Links
Last modified:
Tim Hoar - thoar@ucar.edu