forked from GeoCarb/RtRetrievalFramework
-
Notifications
You must be signed in to change notification settings - Fork 0
/
pleiades_build.script
executable file
·110 lines (95 loc) · 3.25 KB
/
pleiades_build.script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
#!/bin/bash
# Build for Pleiades system
usage()
{
cat <<EOF
Usage $0 [options] <install directory> <absco directory> <merra directory>
This is used to build the Level 2 executable on Pleiades. Note that you need
to supply a "install" directory. This *must* be on one of the NFS systems
(e.g., you home directory). You should not have an executable run from the Lustre
file system (e.g. /nobackup). You can see the Pleiades documentation for a discussion
of this (http://www.nas.nasa.gov/hecc/support/kb/Lustre-Best-Practices_226.html),
but the summary is that they've encounted problems with executables on Lustre and
recommend that you don't run from there.
It is perfectly ok, and even recommended, to have the source and build on the
Lustre filesystem.
Because we aren't on the scf-srv machines, we also don't know where the absco
data is. You need to supply a top directory for this. Note that we need several
versions. Currently (B10.0) we use 3.3.0, v4.1.1_rescaled, and whatever version
we are currently running with (v5.1.0). This can be copied from the
scf-srv system at jpl from the base directory /groups/algorith/l2_fp/absco.
Note that the absco data should be on the Lustre system (e.g., /nobackup)
OPTIONS:
-h Show this message
-k Normally we strip out debugging symbols to rduce the space of
the install. This option keeps them. The code is still compiled
optimized, it just has the debugging symbols still available.
-t Include running tests
EOF
}
run_test=n
strip=y
while getopts “htk” OPTION; do
case $OPTION in
h)
usage
exit 1
;;
t)
run_test=y
;;
k)
strip=n
;;
?)
usage
exit
;;
esac
done
shift $((OPTIND-1))
if [ -z "$1" ]; then
usage
exit 1
fi
if [ -z "$2" ]; then
usage
exit 1
fi
if [ -z "$3" ]; then
usage
exit 1
fi
# Die on error
set -e
# Select a newer version of gcc and python
# Note if you change this, also change script/setup_fp_env.sh.in
if [ -e /usr/share/modules/init/bash ]; then
source /usr/share/modules/init/bash
module load gcc/4.9.4
module load /nasa/modulefiles/pkgsrc/sles12/python3/3.5.2
# This contains ruby 2.2.6p396
module load /nasa/modulefiles/pkgsrc/sles12/pkgsrc/2016Q4
# Needed to get ruby working. Not sure why
ulimit -Ss unlimited
fi
# Create a build directory
mkdir -p build
cd build
# Do configuration
../configure THIRDPARTY=build --prefix=$1 --with-absco=$2 --with-python-module --with-merra=$3
# The frontend system typically has 32 processors. We use 20 here, pretty much
# arbitrarily. This can be adjusted to whatever if needed.
(make -j 20 all || echo $?) 2>&1 | tee make_all.log
if [ "$run_test" == "y" ]; then
(make -j 20 long_check || exit $?) 2>&1 | tee long_check.log
(make -j 20 run_tests || exit $?) 2>&1 | tee run_tests.log
fi
# Note that we strip out debugging symbols here. This significanly reduces
# the size of what we install, which matters a lot on Pleiades. If we end up
# have particular issues, we can build and leave in the debugging symbols
if [ "$strip" == "y" ]; then
(make install-strip || exit $?) 2>&1 | tee install.log
else
(make install || exit $?) 2>&1 | tee install.log
fi