-
Notifications
You must be signed in to change notification settings - Fork 1
/
README.install
106 lines (77 loc) · 4.05 KB
/
README.install
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
Written by:
Kevin J. Bowers, Ph.D.
Plasma Physics Group (X-1)
Applied Physics Divison
Los Alamos National Lab
March/April 2004 - Original version
===================================
Overview of how to install the code
===================================
Step 1: Run install
-------------------
For example, to build the code for the ss2.lanl.gov cluster (Pentium 4, V4
hardware acceleration enabled with LAM-MPI), from the directory where vpic
was unpacked, type:
./install ss2.lanl.gov
A list of supported machines can be found by typing:
ls machine
If your machine cannot be found in that directory, you can port the code by
writing a machine description file. See README.porting for details.
The install script assumes you have "imake" and GNU make ("gmake") on your
system. Once the install script is complete, there will be two files created:
libvpic.EXTENSION.a
build.EXTENSION
EXTENSION depends on the machine type. For ss2.lanl.gov, EXTENSION is ss2.
These two files consitute the code for that platform. There will also be a
file called "Makefile" created. This is the platform specific GNU Makefile
used to build the code.
Note: You can run the install script multiple times to install the code
for multiple platforms if you are so inclined.
Step 2 (optional): Copy build script into your path
---------------------------------------------------
You might want to copy (and rename) 'build.EXTENSION' to some convenient
directory in your path. So long as you do not move 'libvpic.EXTENSION.a', the
build script should work wherever it is put and wherever it is run.
Step 3 (optional): Run tests to verify the install is okay
----------------------------------------------------------
In the "sample/test" directory hierarchy, there are a number of input deck
tests to verify the low level functionality of vpic. In "sample/bench" there
are benchmark input decks to augment the above test suite. "sample" itself
contains a number of input decks to demonstrate physics capabilities.
======================================================
Other fun things the machine dependent makefile can do
======================================================
gmake clean -> Removes all object files and other junk from src code tree
Removes vpic library and build script for the current platform
gmake veryclean -> Removes all object files and other junk from src code tree
Removes vpic library and build scripts for all platforms
Removes the current platform "Makefile"
gmake preprocessed -> Runs the preprocessing step on the vpic library sources
This can be useful due to heavy macro usage in the code.
gmake asm -> Compiles vpic library sources to assembly language
This can be useful for finding performance saps.
===================
How to use the code
===================
Step 1: Write an input deck
---------------------------
Sample input decks are provided in the "sample" directory.
Step 2: Use "build" to convert the input deck into an executable
----------------------------------------------------------------
Run "build.EXTENSION my_input_deck". (Obviously, replace EXTENSION and
my_input_deck with the desired platform and filename.)
This will convert your input deck into an executable simulation named
"my_input_deck.EXTENSION" where EXTENSION depends on the platform you are
compiling for. For example, to build the "harris" sample input deck simulation
on ss2.lanl.gov, assuming the "build.ss2" script is in your path, type:
build.ss2 harris
To run the harris simulation on 16 processors, you would type:
mpirun -np 16 harris.ss2
Step 3: Analyze the results
---------------------------
Depending on the input deck diagnostics, all sorts of files will be dumped out.
The directory "interfaces" has MATLAB, IDL, FORTRAN and C routines to
manipulate dumped data. Also, the user has the ability to write out custom
diagnostics in the "diagnostics" section of the input deck. The dump format
here will depend on the user. Note: MATLAB currently has the most
fully-featured and debugged interface to this code.