$Id: DART_ASP_Summer2003.html 10837 2016-12-23 20:51:05Z email@example.com $
Everything below here is for the NCAR DART Development team.
If you are working with the ASP code from above,
none of the following applies.
The rough specifications for the
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.
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).
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.
setenv CVS_RSH ssh setenv CVSROOT :ext:goldhill.cgd.ucar.edu:/home/thoar/CVS.REPOS cvs co DARTThe 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 .. <directory above sandbox> cvs release -d DART
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.
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
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):
chgrp -R cgddart DART chmod g+s `find DART -type d`
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 ...
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 ...
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)
newgrp cgddart cd DART/work vi mkmf_targets ;# create list mkmf -t mkmf.sun.devel mkmf_targets make ./a.out | tee seq_obs.log
I am exploring Brian Eaton's perl scripts (
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
mkDepends [-t dir] [-w] Filepath Srcfiles
|-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.|
|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
|CVS||Concurrent Versions System|
|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|
|RMS||Root Mean Square (Error)|
|RMSE||Root Mean Square Error|
|TLM||Tangent Linear Model|
|WRF||Weather Research and Forecasting Model|
DART software - Copyright 2004 - 2013 UCAR.
This open source software is provided by UCAR, "as is",
|Contact:||DART core group|
|Revision:||$Revision: 10837 $|
|Source:||$URL: https://svn-dares-dart.cgd.ucar.edu/DART/releases/Lanai/doc/html/history/DART_ASP_Summer2003.html $|
|Change Date:||$Date: 2016-12-23 13:51:05 -0700 (Fri, 23 Dec 2016) $|
|Change history:||try "svn log" or "svn diff"|