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 300MB of space
and the current project is about 3+MB; so I don't really envision
this to be a problem any time soon.
I predict these will be useful ... 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 (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).
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 -R g+s DART
On a CGD filesystem
This example presumes csh or tcsh syntax ...
setenv CVSROOT /home/thoar/CVS.REPOS
newgrp cgddart
cd /data/$USER/
cvs co DART
-- OR -- if you don't want the sandbox to live in a directory called
something other than DART
cvs co -d SomeOtherName DART
cvs update
cvs commit [-m "your message goes here"]
cd ..
On a remote filesystem
This presumes you have a valid account on goldhill and 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
cvs commit [-m "your message goes here"]
cd ..
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 three methods being explored at the moment. They all 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" ...
compile_it
There is a script compile_it that does the heavy lifting.
It is currently configured to be run from the work directory.
../compile_it ingests path_names_for_modules which has
(in addition to a bunch of PATHS) the compile directives for the project.
path_names_for_modules is fundamentally a menu. Uncomment the
chunks you want. As you explore new platforms, please update the compile options.
cd DART/work
vi path_names_for_modules ;# uncomment items
../compile_it seq_obs ;# for example
./seq_obs | tee seq_obs.log ;# if you want to get fancy
Jeff claims you can use any of the (case-insensitive) versions of any of the shell
variables in path_names_for_modules as the argument to compile_it.
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 |
DAI | Data Assimilation Initiative |
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